To sum up, parallelizing a simple loop is quite easy and only takes a couple of statements: First creating a List<IAsyncResult>, and then splitting a loop that processes each item synchronously into a pair of loops, one of which calls BeginInvoke, and the other of which calls EndInvoke.

This appears to create a thread per item, but a lot of threads is OK when the processing for each item involves a lot of blocking, and the ThreadPool limits memory consumption by limiting the number of pooled threads.

When the processing for each item does not involve a lot of blocking but instead involves a lot of computation, you should match the number of threads to the number of processors (which you can get from the Environment.ProcessorCount property). It is easy to use a Semaphore to match threads to processors: you lock the Semaphore in the first thread, before invoking another delegate asynchronously, and unlock the Semaphore before each background thread returns. This means that the first thread blocks as soon as it has the maximum number of agents running, and wakes up to spawn a new agent each time an existing agent finishes.

Please do notice that I have been carefully ambiguous when I've talked about matching threads to processors. You may not want to devote all the processors in a multiprocessor system to compute-intensive threads when you have a particularly compute intensive task to parallelize, such as generating and compiling a set of scripts; you may prefer to leave a processor for all the other threads. Conversely, when you have an only moderately compute intensive task to parallelize, like running a regex Match on each of a set of strings, you may even want to allow a few more threads than processors, so that there is always a thread waiting to run and the Semaphore overhead doesn't leave a processor idle for an significant amount of time.

Jon Shemitz is, most recently, the author of the new Apress book .NET 2.0 for Delphi Programmers, which is now at the printers, and will be in stores in June.