2016-04-25 5 views
0

私の理解を訂正してください。TAP/TPLの前に、以前のスレッドプールモデルでスレッドプールを生成して戻すために、ブロック状態のワーカースレッドが使用されましたか?

タスクベースの非同期プログラミングモデルが導入される前は、.NET ThreadPoolの動作が異なりました。

1)古いシステムでは、スレッドがI/O完了ポートでブロックしていたときに、ブロッキング状態になっている間、そのOSのCPU時間スライスが得られましたか?

2)TPLに付属している新しいスレッドプールとタスクスケジューラの実装後、スレッド状態に入った直後にスレッドプールにスレッドが戻ることは間違いないと思いますか?

3)古いレジームでは、ブロックされたスレッドはスレッドプールに戻らず、回避されていた可能性のあるスレッドインジェクションの不要なオーバーヘッドが発生しましたか?

+0

いいえ、ThreadPool実装もスケジューラも変更されていません。そしてThreadPool.SetMin/MaxThreads()は常に* completionPortThreads * 引数をとりました。また、I/Oの進行中にTPLはスレッドを占有しません。 TAPでは、コールバックメソッドを書くのがはるかに簡単になりました.C#コンパイラはこれをあなたのために書き込みます。 –

+0

ありがとうございます。私は私の質問の大部分は次のようなものだと思います:以前は、スレッドプールスレッドがブロッキング状態にあったときに、別のものに使用されていた可能性がありますか?プールに戻った場合は、その実行コンテキストを他の場所にオフロードして、別の場所で使用されている可能性があります。そして、TPLは実際の費用をどのように節約しましたか?しかし、ブロックされている間何か他のものに使用できない場合、*タスク*抽象化に本当の利点があり、ユーザーがスレッドを作業単位として考える必要がないので、スレッドが他のスレッドを盗む可能性があります。 –

+0

オペレーティングシステムアーキテクチャのいくつかの講義と、MSDNからManaged Threadingを読んだことで、この無骨で無教養の質問をしたり、傲慢さを抱いていた私自身の愚かさが明らかになりました(盲目的でないほど傲慢ではありませんでした)低レベルプログラミングのGuy de Maupassantのような@HansPassantと話をする。私は遠く離れて立っている。 –

答えて

2

1)スレッドは、I/O 完了ポートでブロックされた古いシステムの下では、それは阻止状態であったが、それはOS にCPU時間のそのスライスを得たのですか?

はい。基本的には完了ポートで同等の待機を呼び出します。 "WILL"に注意してください。これに関して何も変わっていません。

2)

、TPLに付属の新しいスレッド・プールとタスク スケジューラの実装後に正しい私の理解です何も新しいことは全くここに来ました。あなたはどこから妄想を得るのですか? TPLはトレッドプールの上に作られています。これを変更したり、カーネルレベルスケジューラーを魔法のように書き換えたりしませんでした。

3)そして、それは、旧体制では、ブロックされたスレッドがバック スレッドプールへ、ひいては行く が回避されている可能性があることスレッド注入の不要なオーバーヘッドが発生しませんでしたか?

これはまだこのようです。あなたはまだ標準APIを自由に使用できます。他のものは、APIをより簡単に呼び出すためにいくつかのコンパイラトリックを使って構築されていますが、何も変更されていません。古いAPIが優れている場合はまだあります。

その部分は間違っています。残りの部分は正しいです。スレッドがそこから返されるまで、スレッドはプールから使用できません。標準のスレッドAPIは返されません。新しいものも、スレッドは別のタスクでそれを使用するタスクスケジューラに返されますが、スレッドプール側からは何も変更されていません。

+0

ありがとうございます。 Jeffrey Richter(私が思う)は、.NET 4.5で、彼らが 'ThreadPool'クラスの実装を書き直していたChannel 9ビデオの1つについて言います。しかし、私は、仕事の盗み/ロードバランシング*などの新しい機能を暗示していました。以前は存在していなかったものの、あなたの言っていることが分かります。同じ古いインフラストラクチャを使用します。 –

+0

いいえ、スレッドプールをより効率的にするためにいくつかの作業を行いました。たとえば、スレッドはappdomain間で共有されます。しかし、スレッドプールなどでは、盗みなどは行われません。 TaskSchedulerは通常のスレッドの上に座ってタスクに割り当てます。スレッドの終わりには、スレッドはカーネルレベルのメカニズムです(少なくともWindowsの実装では)。 – TomTom

+0

もちろん、スケジューラによる作業窃盗は実行され、スレッドプールは依然として作業項目または管理されている最小スレッドと最大スレッドを待ち行列に入れ、オーバーサブスクリプションを予期し、処理します。私はスレッドプールがそのことを推測しませんでした。私はちょうどあなたが明確にしたスレッドプールも書き直したと思っていました。そして、あなたが言うように、新しいパラダイムに座るスレッドプールの再書き込み/リファクタリングは避けられませんでした。私はちょうど今ThreadPoolが劇的に異なった振る舞いをしたと考えました。説明をありがとう。 –

関連する問題