Michael C. Kennedy's Weblog - More on the ThreadPool Bug in .NET 2.0 SP1

Thursday, April 17, 2008

More on the ThreadPool Bug in .NET 2.0 SP1

There appears to be some confusion about this .NET 2.0 SP1 ThreadPool bug I found. Can you believe someone might be wrong on the internet?

If you’ve been following the posts (1, 2, 3), then you’ll know I was in touch with the key guys at Microsoft and the root of the problem is that if you create asynchronous work faster than the ThreadPool can create threads, then that work "misses" the SetMinThreads command and are created more slowly.

That is why the Thread.Sleep(1) probably solves the issue for you. If it doesn’t, sleep slightly longer. It’s a timing issue.

With this insight, you’ll see that this does not really affect true servers such as ASP.NET and WCF but does affect things like Delegate.BeginInvoke and friends called in quick succession.

In short, if your server handles more than 1,000 requests per second, during the first second of startup, then your server may run into this problem (ok, ok, more precisely, if your server handles more than 1 request / millisecond).

Let me address a few common concerns out there:

Is the sky falling? No.
Is it great situation? No.
Will be fixed with .NET 2.0 SP2? Yes
When? Maybe this summer, maybe later - they aren’t sure.
Does this affect WCF and ASP.NET? Probably not. The bug, no. The new ThreadPool behavior, yes.
Is there a work around? Yes, create threads more slowly. This is automatic on the server.

DevelopMentor

posted on Thursday, April 17, 2008 11:31:28 AM (Eastern Standard Time, UTC-05:00)

Monday, June 09, 2008 10:36:41 AM (Eastern Standard Time, UTC-05:00)

Thanks for your efforts to track this bug down! I did apply to my app and I noticed a "Jumb" in my multi-threaded app performance:

Try1 (slow):
min threads set to 125
max threads set to 250 (more than what my machine can handle)
Time to wait between threads queueing: 0 milliseconds

By looking at the performance counter "# of curent logical threads" for my app: it maxed out at 76, and my app took about 10 minutes to finish the task.

Try2 (fast!):
min threads set to 125
max threads set to 250 (more than what my machine can handle)
Time to wait between threads queueing: 1 milliseconds

By looking at the performance counter "# of curent logical threads" for my app: it maxed out at 133, and my app took about a little under 5 minutes, that's less than half the time it took in try 1!!

so definilty this helped.

What sounds exciting (and concerning too) is the following:

http://msdn.microsoft.com/en-us/library/cc308561.aspx

With windows 2008, they have re-architected the whole thing for Thread Pools, now you can have multiple thread pools per process!! so I beleive what we are doing now will be re-coded differently to take advantage of the new api changes....

-Tamer

Tamer Yousef

Name
E-mail
Home page

	Remember Me
Comment (Some html is allowed: `a@href@title, b, blockquote@cite, em, i, strike, strong, sub, sup, u`) where the @ means "attribute." For example, you can use <a href="" title=""> or <blockquote cite="Scott">.
Enter the code shown (prevents robots):
Live Comment Preview