CLR 4.0 ThreadPool Improvements: Part 2 (sort of...)

It's now been more than 16 months since I promised to post about the improvements we made in the ThreadPool's concurrency control algorithm for CLR 4.  Lesson: don't promise to write a series of articles unless you've got the time to do it!

Luckily, Erika Fuentes, who you may recognize from our Channel 9 video, has written an article on this topic for MSDN Magazine.  Lesson: lazyness works!

If you'd like to understand more about how the ThreadPool works, please do check out Erika's excellent article, Throttling Concurrency in the CLR 4.0 ThreadPool.  If you have any questions, feel free to post them as comments here, and I'll do my best to answer.

Comments

• Anonymous
  September 07, 2010
  Hi Eric, It seems for the pure CPU bound code it's ALWAYS good to set MaxDegreeOfParallelism = cpuCount; Otherwise threadpool wiil try to schedule more threads, trying to "see" if it will help. I actually verified this in practice. It's not a huge win when the loop body is small (timewise) but it's huge with the body is expensive. Just didn't see this recommendation, and wanted to see if you would agree

• Anonymous
  September 08, 2010
  In our testing, we do not typically observe a very large performance problem due to this probing.  If you have a scenario that demonstrates this, I'd be interested in hearing more.  What kind of processing are you doing?  How big of an impact do you observe due to the extra threads?

• Anonymous
  September 15, 2010
  I guess it's not a big deal, In my testing (4 cores) I am loosing 2-3%. Seems like specifying MaxDegreeOfParallelism is even a smaller deal to gain something :)