I discovered a deadlock in some code using the ThreadPool to do some database connectivity tests.  It turns out that some of the database code in the .NET framework uses the thread pool to get database connections.  This results in deadlocks when spawning too many threads trying to open database connections.

Microsoft needs to add a parameter to the QueueWorkItem method that specifies the approximate number of additional threads needed by a work item.  This could ensure that the appropriate number of threads were free before starting the item.

Looks like it’s back to the custom thread pool implementation again….

Read full post