ミューテックスが解放されるのを待つように 3 つのスレッドを設定した場合、それらは要求した順序に基づいてキューを形成しますか、それとも未定義の動作ですか (つまり、どれが最初に取得するかわかりません)?
5 に答える
SDKの記事に明示的に記載されています。
複数のスレッドがミューテックスで待機している場合、待機中のスレッドが選択されます。先入れ先出し (FIFO) の順序を想定しないでください。カーネル モード APC などの外部イベントによって、待機順序が変更される場合があります。
この種のイベントは、完全に制御できません。したがって、「未定義の動作」はそれを説明する適切な方法です。
Mutex オブジェクトはほとんど公平です。APC ケースが発生する可能性がありますが、それほど一般的ではありません。特に、スレッドが I/O を実行していないか、完了ポートを使用して、または同期的に I/O を実行している場合。
ほとんどの Windows ユーザー モード ロック (SRWLock、CriticalSection) は、ブロックせずに取得できる場合は不公平ですが、カーネルでブロックする必要がある場合は公平です。このようにする理由は、ロックコンボイを避けるためです。公平なロックが競合する瞬間、すべての取得者は、ロックを取得する前にスケジューラとコンテキスト スイッチ パスを通過する必要があります。たまたま実行されているため、「先にスキップ」してロックを取得することはできません。したがって、キュー内の最後のスレッドのロック取得時間は、キュー内の前の各スレッドのスケジューリングおよびコンテキスト切り替え時間だけ増加します。これは安定した状態であるため、外部負荷がほとんど取り除かれるまで、システムはこの状態から回復しません。
パフォーマンスについては、前述のユーザー モード ロックのいずれかを使用することをお勧めします。これは、シナリオに適合する場合、カーネル ミューテックスよりもはるかに高速であるためです。
これについては非常に複雑な意見があり、明確な情報はどこにもありません。このスレッド: http: //us.generation-nt.com/answer/are-events-fair-help-38447612.html一部の人々は、イベントの公平性は優先順位を無視する単純なFIFOキューを使用して実装されることを示唆しているようですが、他の人は公平性を仮定すべきではないと言っています。
結論として、公平性に基づいてロジックを作成したり、公平性を保証する独自の実装でイベントをラップしたりしない方がよいと思います。
ウェイクアップの順序は定義されていません。
はい、1 つのスレッドのみがウェイクアップしてミューテックスをロックします。しかし、順序は未定義です。