環境: Win32、C/C++
たとえば、スレッドが操作を完了したことを main() に通知するために、3 つすべてを使用できます。
しかし、信号の中で最も速いのはどれでしょうか?
うーん...
環境: Win32、C/C++
たとえば、スレッドが操作を完了したことを main() に通知するために、3 つすべてを使用できます。
しかし、信号の中で最も速いのはどれでしょうか?
うーん...
3 つのオプションはすべて、実際に受信スレッドにシグナルを送るために、スレッド コンテキスト スイッチを必要とします。コンテキスト スイッチのオーバーヘッドが、いずれかの API の処理コストの違いを上回る可能性が非常に高くなります。
この選択は、受信スレッドの性質 (たとえば、UI スレッドであるか、メッセージ ループを実行するか) によって最適に決定される可能性があります。とはいえ、いくつかの詳細には次のものが含まれます。
SendMessageは、受信スレッドが UI スレッドであり、メッセージ ループ内でチャーンしている場合に役立ちます。受信者がメッセージを処理するまで、送信スレッドはブロックされます。ただし、その間、キューに入れられていないメッセージを処理する場合があります。追加のコンテキスト スイッチが関与する可能性があり、SendMessage が 3 つの中で最も遅くなる可能性があるため、そのロジックは処理を遅くする可能性があります。
PostMessageは、受信者がメッセージ ループ内にいる場合にも役立ちます。SendMessage との違いは、受信者がメッセージを処理するのを待たないため、オーバーヘッドが少ないことです。
SetEventは、 WaitForSingleObject ()などを使用して、受信スレッドがイベント オブジェクトを待機できる場合に便利です。マーシャリングやメッセージ処理のオーバーヘッドが発生せず、他のものよりも迅速に応答する可能性があります。
SetEvent は断然最速で最も単純ですが、最小限の情報を運ぶこともできます。基本的に、それが言えることは、何かが起こった (イベントが通知された) ということだけです。
確認していませんが、(オブジェクトを待っている人がいると仮定して) SetEvent、SendMessage、最後に PostMessage と言います。
編集:上記の背後にある理由は、SendMessage が同期で PostMessage が非同期であることです。SetEvent についてはよくわかりませんが、メッセージ ポンプがメッセージを配信するのを待たずに、イベントを待っている何かをトリガーすると仮定します。送信または投稿について考えると、おそらく問題ではなく、送信側が待機するかどうかの問題です。内部処理はおそらく同じです。
ただし、通常、メッセージの投稿も送信も、別のスレッドにシグナルを送信するために使用するものではありません。
MsgWaitForMultipleObjects と WaitForMultipleObjects を比較すると、MsgWaitForMultipleObjects の最大待機オブジェクトが WaitForMultipleObjects よりも 1 少ないことがわかります。つまり、非表示の「メッセージ イベント」があるため、メッセージにはイベント + メッセージ パッシングのオーバーヘッドがあります。