私の理解を訂正してください。TAP/TPLの前に、以前のスレッドプールモデルでスレッドプールを生成して戻すために、ブロック状態のワーカースレッドが使用されましたか?
タスクベースの非同期プログラミングモデルが導入される前は、.NET ThreadPoolの動作が異なりました。
1)古いシステムでは、スレッドがI/O完了ポートでブロックしていたときに、ブロッキング状態になっている間、そのOSのCPU時間スライスが得られましたか?
2)TPLに付属している新しいスレッドプールとタスクスケジューラの実装後、スレッド状態に入った直後にスレッドプールにスレッドが戻ることは間違いないと思いますか?
3)古いレジームでは、ブロックされたスレッドはスレッドプールに戻らず、回避されていた可能性のあるスレッドインジェクションの不要なオーバーヘッドが発生しましたか?
いいえ、ThreadPool実装もスケジューラも変更されていません。そしてThreadPool.SetMin/MaxThreads()は常に* completionPortThreads * 引数をとりました。また、I/Oの進行中にTPLはスレッドを占有しません。 TAPでは、コールバックメソッドを書くのがはるかに簡単になりました.C#コンパイラはこれをあなたのために書き込みます。 –
ありがとうございます。私は私の質問の大部分は次のようなものだと思います:以前は、スレッドプールスレッドがブロッキング状態にあったときに、別のものに使用されていた可能性がありますか?プールに戻った場合は、その実行コンテキストを他の場所にオフロードして、別の場所で使用されている可能性があります。そして、TPLは実際の費用をどのように節約しましたか?しかし、ブロックされている間何か他のものに使用できない場合、*タスク*抽象化に本当の利点があり、ユーザーがスレッドを作業単位として考える必要がないので、スレッドが他のスレッドを盗む可能性があります。 –
オペレーティングシステムアーキテクチャのいくつかの講義と、MSDNからManaged Threadingを読んだことで、この無骨で無教養の質問をしたり、傲慢さを抱いていた私自身の愚かさが明らかになりました(盲目的でないほど傲慢ではありませんでした)低レベルプログラミングのGuy de Maupassantのような@HansPassantと話をする。私は遠く離れて立っている。 –