シナリオ 1: ミューテックスを解放してから待機する シナリオ 2: 待機してからミューテックスを解放する
それが何をするかを概念的に理解しようとしています。
呼び出し元のスレッドが条件変数で「ブロックされている」と見なされる前にミューテックスが解放された場合、別のスレッドがミューテックスをロックし、述語が基づいている状態を変更し、待機中のスレッドがウェイクアップするpthread_cond_signal
ことなく呼び出すことができます (そうではないため)。まだブロックされています)。それが問題です。
シナリオ 2、待ってからミューテックスを解放することは、必要な動作のアトミックな実装などがないため、実際の実装が内部的にどのように機能する必要があるかです。しかし、アプリケーションの観点からは、スレッドがブロックされたセットの一部であることを確認するには、mutex も解放されなければなりません。そのため、「抽象マシン」という意味ではアトミックです。
編集:より詳細に説明すると、条件変数待機の実際の実装は通常次のようになります。
したがって、「ブロッキング」の動作は 2 つのステップに分割されます。1 つはミューテックスがロック解除される前に発生し (ブロックされたセットのメンバーシップを取得する)、もう 1 つはミューテックスがロック解除された後に発生します (おそらくスリープ状態になり、他のプロセスに制御を譲ります)。スレッド)。抽象マシンで「条件待ち」操作を「アトミック」にできるのは、この分割です。