別の SO の質問では、バックグラウンド スレッドで同期リクエストを送信するのではなく、非同期ネットワーク リクエストを送信するようにアドバイスされました。糸を無駄にしないためでした。私はこれがどうしてそうなのかを理解しようとしています。
これがオリジナルのアプローチです。ここに 2 つのスレッドがあることは理解できます。1 つはメイン スレッド (1) で、もう 1 つは WCF 呼び出しを行うバックグラウンド スレッド (Task.Run) (2) です。
これは、提案されたアプローチの私のスケッチです。スレッドがどのように保存されるかを理解しようとしています。非同期 WCF 呼び出しの後、非同期 WCF 呼び出しからのコールバック用に別のスレッドが作成されませんか?
さらに考えてみると、コールバック処理が不要な場合は、1 つのスレッドしか使用されないのではないでしょうか。
WPF クライアントOnClickでは、クライアントのどこかにある可能性があります。クライアントがクリックされたかどうかを確認しているスレッドはどこですか?
OS自体がクリックをチェックし、メッセージをメッセージポンプに渡し、次に関数を呼び出すという答えです。WCF関数のコールバックはそのようなもので、OS自体が応答メッセージをリッスンしており、応答メッセージを取得すると、スレッドプールで空きスレッドを見つけてその時点でコールバックを実行するシグナルを送信します。
スレッドを同期的に保持することと、最後にコールバック メソッドにスレッドを生成させることの主な違いは、スレッド プールがプールであるという事実です。スレッド プール内のスレッドが作業を終了しても、そのスレッドは破棄されず、しばらく待機して、実行できる作業が他にあるかどうかを確認し、その新しい作業を行うために再利用されます。
というわけで選択肢は2つ
ThreadPool.GetMaxThreads()OS が、待っている場所が表示されたという情報を教えてくれたら、既に作業を終了した既存のスレッドを再利用します (または、待機していない場合は新しいスレッドを生成します)。コールバックを処理する短いタスクを与えます。次に、スレッドがプールに戻って、他のコールバックが入ってきたときに他の作業を行うようにします。