Advantage of using Thread.Start vs QueueUserWorkItem

Question

In multithreaded .NET programming, what are the decision criteria for using ThreadPool.QueueUserWorkItem versus starting my own thread via new Thread() and Thread.Start()?

Answer 1

One advantage of using Thread.Start() is, that you are able to intentionally abort the thread later. In the ThreadPool you have no means of controlling the thread execution after you enqueued it.

Answer 2

The thread pool is always available in .NET apps, regardless of what kind.

The cost for starting a thread from the thread pool via ThreadPool.QueueUserWorkItem will be no more than the cost of starting your own thread, and could be less.

If you just want a few threads for a short period, then use the thread pool. That's what it's for.

Answer 3

The ThreadPool is always there, however, there are a finite number of threads allocated to the pool based on the number of processors. For ASP.NET applications, it is generally a bad idea to use Threads unless you really are starting off an Async process and know that there won't be a large number of requests (remember that there are a finite number of threads in the ThreadPool which you share with everything running in your AppDomain and there is a realistic limit on the total number of threads you want to create using new Thread() as well).

For WinForms apps consider using the BackgroundWorker instead of using a Thread or the ThreadPool. It uses the ThreadPool, however, it makes communicating between threads easier on the multi-thread savvy programmer.

Updated

Avoid using ThreadPool.QueueUserWorkItem as your app pool could disappear at any time. Move this work outside or use WebBackgrounder if you must.

From Hanselman.com - "Checklist: What NOT to do in ASP.NET"