ThreadPool causing GUI to freeze (?)

Question

I'm noticing that, if the ThreadPool max thread count for my IO-intensive app is set too low (16), then my GUI will freeze. But if I set it considerable higher (250), it works just fine.

Can anyone explain this phenomenon?

Answer 1

Woah there! Don't mess with the ThreadPool count unless you know what you are doing - lots of essential .NET services may be using that, and relying on it not being saturated. You've almost certainly deadlocked some of the basic IO code through saturation.

I would imagine that it is the IO completion ports that are tripping you up in this particular case...

Joe Duffy (who knows more about threading than I ever will) has some thoughts on this here.

Re how to deadlock it through saturation - that is simple to reproduce in a thought experiment; assume you have a bit of worker code that needs to do 2 things... we'll push 1 of them onto the ThreadPool, and do one ourself; after doing our own work we'll Join() [or the ThreadPool equivalent] the second task so that we know both have finished.

Now imagine that we start this worker code on the last available ThreadPool thread: we do our own work, and then wait for a signal that the 2nd task has finished - but there are no threads available to do it on! And we can't release our own, as we're still waiting.

You can do the same with IO completion ports.