If you're using .NET 4.0, you should make use of the new Parallel Task Library.
If not, consider using the threadpool to do your work with ThreadPool.QueueUserWorkItem()
. Failing that, creating a new Thread
object is the way to go. Do not use BackgroundWorker
for this; only if you were trying to decouple long-running processor-intensive code from blocking the UI would you use the BackgroundWorker
.
There's a pretty good example of waiting for all the user workitems to complete here: http://msdn.microsoft.com/en-us/library/z6w25xa6.aspx. Essentially you pass a ManualResetEvent
object into each call that is Set()
when the async code completes. You put all the ManualResetEvent
objects in an array and call WaitHandle.WaitAll()
passing in that array to wait for all the waithandles to be set.
Another technique could be to have a controlled number of Thread
objects running that are waiting for items to appear in a Queue
. This is a fairly standard Producer/Consumer pattern that means you need less threads (and therefore resources) but can still decouple the request from the work by putting messages on a queue. If you need the queue to be durable you could use MSMQ (and you can go even further than that with an ESB).
As you can see, where you are considering multi-threading makes a massive difference on how you implement it. Windows Form multithreading would not be the same as a Windows Service's multithreading, and in turn neither would be the same as in an ASP.NET web application (where arguably threading isn't even a good idea due to resource management in IIS). If you update your question we can be more specific to your current needs.