views:

70

answers:

2

I am reading a C# 4.0 book which gives the following default values for the maximum thread limit for the threadpool.

  • 1023 in Framework 4.0 in a 32-bit environment
  • 32768 in Framework 4.0 in a 64-bit environment
  • 250 per core in Framework 3.5
  • 25 per core in Framework 2.0

Can anyone tell me what might might have prompted such a vast increase in the defaults, especially for 64 bit? Have the issues with context switching been solved?

In the past, we have set reasonable limits on the size of the threadpool because there seems to be a sweet-spot, after which our application slows down due to context switching. Naturally, we will stress test and re-benchmark after updating the target framework. But can anyone shed any light on what framework improvements have been made to enable a larger threadpool? Or is it just MS increasing the defaults to look impressive?

+3  A: 

Issues with context switching was not solved (due to its nature belongs to OS). But when you go right way (async) with ThreadPool context switches are not an issue. .NET ThreadPool scheduler was improved due new TPL and some other needs it have to solve.

Try to start with CLR 4.0 ThreadPool Improvements

Also check: Throttling Concurrency in the CLR 4.0 ThreadPool and this great video

Nick Martyshchenko
Thanks Nick. This was very helpful.
Daniel Dyson
Glad to help you
Nick Martyshchenko
+1  A: 

It was tweaked to work better on modern Big Iron. Machines with more than 64 CPU cores, that kind of hardware. Obviously they have less trouble with context switches. The feedback loop they added to the scheduler is interesting, gathering statistics to make better scheduling decisions. But this stuff doesn't kick in until you've got the major hardware first.

Hans Passant