ThreadPoolによりGUIがフリーズします（？）

Question

IO集中型アプリのThreadPoolの最大スレッドカウントが低すぎる（16）場合、GUIがフリーズすることに気付きました。しかし、かなり高く（250）設定すると、問題なく動作します。

誰でもこの現象を説明できますか？

Answer 1

うわあ！何をしているのかわからない限り、ThreadPoolの数を混乱させないでください。多くの重要な.NETサービスがそれを使用し、飽和していないことに依存している可能性があります。飽和によって基本的なIOコードのいくつかをほぼ確実にデッドロックしました。

この特定のケースであなたをつまずかせているのはIO完了ポートだと思います...

Joe Duffy（私はこれまで以上にスレッドについて詳しく知っています）は、このことについていくつかの考えを持っていますこちら。

飽和によってそれをデッドロックする方法について-思考実験で再現するのは簡単です; 2つのことを実行する必要があるワーカーコードが少しあると仮定します。そのうちの1つをThreadPoolにプッシュし、自分で1つ実行します。独自の作業を行った後、2番目のタスクをJoin（）[または同等のThreadPool]にして、両方が終了したことを確認します。

ここで、このワーカーコードを最後の利用可能なThreadPoolスレッドで開始すると想像してください。独自の作業を行い、2番目のタスクが終了したというシグナルを待ちますが、実行できるスレッドがありません！そして、私たちはまだ待っているので、自分自身をリリースすることはできません。

IO完了ポートでも同じことができます。