Asynch calls versus multi-threading

I have a Windows Service in VB.NET that makes calls to several long running processes (regular subroutines, not web svc, remoting, or anything fancy) in sequence. I'm leary about trying to implement multithreading just because we've never done it before and this is mission crticial code. I had the thought of calling the routines asynchronously instead. I'm familiar with that and use it as part of some web services. Am I missing something? It seems like asynch calls is a "poor mans" way to avoid multithre开发者_StackOverflowading issues.

Asynch calls are usually better than regular multithreading because they leverages IO COmpletion Ports thread that is more effcient in term of CPU usage.

It seems like asynch calls is a "poor mans" way to avoid multithreading issues.

Not necessarily. Javascript (and server variations of Javascript like Node.js) run on a single thread, but utilise lots of asynchrony so that not much time is spent waiting on a long running operation to complete. It's a way of optimising a single thread, and can be a very powerful way of programming if you've the right mindset.

If you're comfortable with asynchronous programming, then go for it! There is no need to bring in a whole lot of threads just because a task CAN be parallelised.

However, if the tasks are CPU bound, then a single thread is going to choke, and asynchrony won't help you for obvious reasons. If the task is IO, then asynchrony is probably the way to go.

Edit:

Sorry I wasn't clear. What I meant by CPU bound, is that if a particular operation is using a lot of CPU, the thread will be constantly in use, and will not be available for other tasks.

For example:

// task
long sum = 0;
for (int i = 0; i < 1000000; i++)
    for (int j = 1000000; j > 0; j--)
         sum = i + j;

If you needed to run the above code two times, an asynchronous model using one thread is not going to help, because a single thread will be working constantly for the whole task. If you had two threads, both can execute at exactly the same time.

// task
List<string> urls = GetListOfUrls();
List<string> html = new List<string>();
foreach (var url in urls) 
{
    GetUrlAsync(url, callback: (data) => html.Add(data) );
}

The above task is an IO task. The majority of the time in that method would be spent waiting on HTTP requests, not using CPU. If this task was synchronous, a single thread will have the same symptoms as the first. If it was asynchronous, while waiting for a HTTP request to complete, the thread is available to do more work, like kick off another download of an URL.

So, if your tasks are going to be spending a lot of time waiting for an external process, use asynchrony. Is tasks are going to be burning cpu, use multiple threads.

I don't know what multithreading issues you expect to avoid by making asynchronous calls. Asynchronous calls are multithreading. The only real difference is that an async call is typically used for a relatively short-lived task whereas traditional multithreading (where you explicitly create a thread and start it running) is typically used for long-running tasks.

Either way, you still have the same concurrency issues.

You can use asynchronous calls for long-running tasks. In fact, the Task class has a constructor that lets you specify creation options, including TaskCreationOptions.LongRunning.

Managing your own threads using the Thread class is a little bit more complicated than using something like Task or ThreadPool.QueueUserWorkItem, but it also gives you slightly more control. Any way you do it, you have to deal with concurrency issues like race conditions and thread-safe data structures (if multiple threads are modifying a data structure). I wouldn't call asynchronous calls a "poor man's multithreading." The differences aren't that large. They're just two different ways to accomplish the same thing.