Breaking Changes in the .NET ThreadPool

Posted by Jonathan Allen on May 13, 2008

Sections

Development,

Architecture & Design

Topics

Performance & Scalability ,

.NET

Tags

Multi-threading

When .NET 2.0 SP 1 was released with .NET 3.5, the thread pool underwent some significant changes. As Michael C. Kennedy discovered, not all were for the best.

The first change is increasing the default maximum number of threads from 25 per processor to 250 pre processor. This was done to address deadlocks in the thread-pool. These deadlocks were caused when too many threads were waiting on other tasks. Once all 25 threads were blocked, the tasks they are waiting on cannot be attached to a thread. While this change doesn't completely eliminate the possibility of deadlocks, it should make them far less likely.

The other change is actually a bug. Normally .NET allocates up to the minimum thread count in threads as soon as needed. From them on, no more than 2 threads per second are created until you reach the maximum thread count. If you know your application is going to need a lot of thread-pool threads right away, you can increase the minimum thread count.

Michael C. Kennedy discovered that in .NET 2.0 Service Pack 1, the minimum thread count is ignored. If an application needs an inordinate number of thread pool threads, it could take several seconds or even minutes before it fully starts.

According to Michael C. Kennedy, his Microsoft contacts say the fix will be included in .NET 2.0 SP 2. The release date for this is unknown.

 

• Older >