"await" を使用してタスクを UI スレッドからオフロードすることが優れていることは明らかです。その後、UI スレッドは Windows メッセージの処理に戻ることができます。
しかし、待っていた Task を Task.Run で開始するとします。これにより、ThreadPool からスレッドでコードが起動されます。そのコードで「待機」を行う価値はありますか (技術的にはそれを行うことさえできますか?)。
「いいえ」と言いたくなる。ThreadPool スレッドから作業をオフロードする必要があるのはなぜですか? 割り当てられた元のタスクを処理する以外に、他に何をしなければならないのでしょうか?
ここで、誰かが返信して、await を実行すると、ThreadPool スレッドが実際にプールに「解放」され、別の場所で使用される可能性があると言ったら、私は本当に感銘を受けます。
マイケル
技術的にそれはできますか？
はい。current がないため、結果の継続は (おそらく) 別の ThreadPool スレッドで実行されますSynchronizationContext。ただし、メカニズムはうまく機能します。
そのコードで「待機」を行う価値はありますか?
はいあります。下記参照。
ThreadPool スレッドから作業をオフロードする必要があるのはなぜですか? 割り当てられた元のタスクを処理する以外に、他に何をしなければならないのでしょうか?
スレッドを解放して他の作業を行うことができます。ThreadPool スレッドは限られた有限のリソースです。
ここで、誰かが返信して、await を実行すると、ThreadPool スレッドが実際にプールに「解放」され、別の場所で使用される可能性があると言われたら、私は本当に感銘を受けます..
はい、これは実際に起こることです。
タスクを解放できること以外に、これを行うことには別の大きな利点があります。ThreadPool にいる場合でも、同期コンテキストを持つスレッドにいる場合でも、同じコードで同じメソッドを使用できます。同じコードを再利用できることも非常に価値があります。