Compartilhar via

ThreadPool bug in CLR 2.0 SP1

  • Artigo

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

  • Anonymous
    March 17, 2008
    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.

  • Anonymous
    April 17, 2008
    Here's a little more info on this issue: More on the ThreadPool Bug in .NET 2.0 SP1 http://www.michaelckennedy.net/blog/PermaLink,guid,859d9d70-e822-418f-820c-ca91bed78dcf.aspx

  • Michael
  • Anonymous
    May 12, 2008
    SP1 of .NET 3.5 is now available as a Beta release. This beta release has the fix for the ThreadPool