ThreadPool vs dedicated Thread - when to prefer wh

Question

Is there any way (apart form actual perfomance measurements which can be pretty hard to make them realistic) or rule of thumb when I should stop using the ThreadPool and use a dedicated Thread instead? I suppose for long running work it is better to use a dedicated Thread because it doesn't peramently steal one from the ThreadPool. For shorter work it is better use the the ThreadPool because creating threads and the thread itself consumes a lot of resources.

But where is the magic barrier? How do I decide which approach to use?

In simple applications it might not matter that much. But I am dealing with a custom .NET-based application framework where a single application can have a lot of plugins which in most cases need to do some work asynchonously. And I am thinking about introducing a policy for the plugin authors when to use which.

Answer 1

Use thread pool threads for short running tasks.

Use threads if you need a long running task or need to set some properties of the thread such as priority, foreground, culture etc.

If possible use the Task class in .NET 4. The default scheduler uses the thread pool, but you may provide your own scheduler and thus control exactly how tasks are mapped to threads.

Answer 2

One point not yet mentioned: code which sets thread-static class references should generally not run from thread-pool threads. Otherwise, if the thread gets recycled, the thread-static object reference might live indefinitely, preventing the object and all others it refers to, directly or indirectly, from every being eligible for garbage collection.

Answer 3

It is quantifiable. On my dual core laptop, the threadpool scheduler releases an extra tp thread twice a second if the running ones are not making progress. So "long" is more than half a second.

I do not know how this scales with beefier hardware. It is easy to test, just start 16 tp threads and have them write DateTime.Now and Sleep(8001).

Also, any thread that is very likely to block for extended periods, either on a lock or slow I/O should be a regular thread. Because no useful work will be done by the processor, the blocking thread is preventing other tp threads that might have useful work to do from running for at least that half second. Of course, that makes such a thread almost automatically qualify as a "long" thread.

Answer 4

If your application is going to use alot of threads you can increase the minimum number of threads in the ThreadPool to avoid a bottleneck there. I don't see any advantages of dedicated threads. The only thing that comes to mind is that you can abort a dedicated thread (which is not advisable anyway).

Performance should be the same. The task parallel library in the .NET 4.0 framework only uses the ThreadPool so it shouldn't be a problem for your project either.