While getting my facts straight in an email conversation with a reader of this blog, I could not find where I had read about the new changes to the thread-pool threads in CLR 4.0 (why do I not know the code name for that, 10-4?) and the reason it proved so illusive is because its all in a Channel 9 interview with Erika Parsons and Eric Eilebrecht.
Here’s my para-bullet-pointing of the key information, from 12m0s in the video:
Previous Framework releases, years ago, started as a fixed amount and fairly low number then it was made per CPU and then in Orcas it was changed to "a frankly absurdly high limit to prevent a 'deadlock' like wait situation" – 250 x CPU count.
Potentially, this high amount could mean that on an 8-core machine you could use up all your virtual memory on your thread pool - potentially.
It’s changing again in 4.0: based on the amount of available virtual memory, it’ll only use half of it. Using this algo on 64-bit systems would end up with such a large number that the thread-tracking data structures used in the thread pool would overflow so its limited to 32,000ish.
This preparation for many-core is interesting given that the dispatcher and kernel locks in Windows 7 scale to (only) 256 cores.
Interesting link: http://blogs.technet.com/markrussinovich/archive/2008/07/21/3092070.aspxLabels: concurrency, programming