ThreadPool bug in CLR 2.0 SP1

Shortly after the release of CLR 2.0 SP1 (a.k.a. Orcas or .NET 3.5), several customers noticed some very odd behavior in the ThreadPool.  The ThreadPool is supposed to create threads as fast as possible, up to the current setting for MinThreads – but it turns out that if you queue workitems very quickly (like in a tight loop that just calls QueueUserWorkitem), the pool will expand very slowly – we’ll only create one thread every half second (which is the normal behavior once we’ve reached MinThreads).

Michael C. Kennedy’s blog has sample code and some perfmon graphs demonstrating this behavior.  He also posted our suggested workaround, which unfortunately boils down to “don’t queue the work items so quickly.” 

We plan to fix this in CLR 2.0 SP2 (i.e., .NET 3.5 SP1).  In the meantime, if you should encounter this, please try the workaround.

Comments (3)

  1. Hi Eric,

    Thanks for summing up the issue for everyone. I’m glad to hear that you guys are on top of the problem. We should emphasize that for "real" server applications like ASP.NET and WCF this problem is unlikely to manifest itself. I”m planning a follow up post on the details of the problem and why it won’t affect ASP.NET.

  2. Here’s a little more info on this issue:

    More on the ThreadPool Bug in .NET 2.0 SP1,guid,859d9d70-e822-418f-820c-ca91bed78dcf.aspx

    – Michael

  3. SP1 of .NET 3.5 is now available as a Beta release. This beta release has the fix for the ThreadPool