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.