Why does ThreadPool have 250 worker threads per processor by default?

Question

Adapted from Microsoft documentation:

By default, the thread pool has 250 worker threads for each available processor. You can change this parameter using the ThreadPool.SetMaxThreads method.

He also said it is widely known that there is some overhead:

Topics have some level of overhead. Therefore, if a computer has several processors and you split the processing into two threads, you will not see a 100 percent performance improvement.

Due to some experience and more from guessing, I would have something like 1 to 4 threads per processor, not 250 ! Does anyone know why 250? Is this some value that should give the best overall performance , or is it designed to have almost any task that you give this thread pool, be processed without waiting to perform other tasks?

Answer 1

Motivation is not productivity. As you mentioned, too many threads can lead to performance degradation (due to context switching, cache extraction, claims, etc.). The idea behind this magic number is to try to avoid deadlocks in user code. A developer can cause a deadlock if he queues many work items in a thread pool, which waits for other items that were also in the queue for the thread pool. If a situation arises when the thread pool uses its maximum number of threads (all of them are in the idle state), then you have a dead end .

Of course, there is nothing special in the number "250", and still there may be deadlocks if the developer insists on using such a problematic pattern of using a thread pool. However, this should reduce the likelihood of a dead end in such scenarios.

Joe Duffy explains this reasoning in more detail in his post: Why the CLR 2.0 SP1 threadpool default max thread count was increased to 250 / CPU .