condition_variable.notify_one() を呼び出す前にロックを取得する必要がある場合?

マルチスレッド プログラミングでは、condition_variables を使用して、待機中のスレッドに特定の条件が満たされました。 condition_variable.wait() を呼び出す前にロックを保持する必要がありますが、notify_one() を呼び出す前にもロックが必要かどうかについては不確実性があります。

Notify_one() の前にミューテックスをロックできますか? ) およびなぜ?

notify_one() の前にミューテックスをロックすることは必須ではありませんが、特定のシナリオでは有利な場合があります。通知スレッドがnotify_one()を呼び出す前にロックを解放すると、待機中のスレッドがすぐに実行を開始できるようになります。ただし、通知スレッドがロックを保持している場合、待機中のスレッドは続行する前にロックが解放されるのを待つ必要があります。この例では、最初のnotify_one()の後のクリティカルセクション内でi変数が変更されているため、それ以降のnotify_one()の呼び出しに対してロックが取得されます。これにより、実行を再開するときに待機中のスレッドが i の更新された値を監視するようになります。

起こり得る競合状態の回避

最初の実行中にロックを保持しないと主張する人もいるかもしれません。 notify_one() 呼び出しは、コンシューマー スレッドが途中で実行を再開し、通知を見逃す競合状態を引き起こす可能性があります。ただし、これは正当な懸念ではありません。

C 標準によれば、condition_variable::wait() は述語を継続的にチェックし、必要に応じて待機する内部ループのように動作します。この場合、述語は [] { return i == 1; です。 }。コンシューマ スレッドがチェックするときに i が 1 に等しくない場合、内部ループは単純に終了し、スレッドは実行を再開できません。したがって、コンシューマ スレッドがチェックする前にプロデューサ スレッドが notify_one() を呼び出したとしても、つまり、コンシューマー スレッドは通知を見逃すことはありません。

厳密には必須ではありませんが、ミューテックスをロックする前に特定のシナリオでは、condition_variable.notify_one() を呼び出すと有益な場合があります。これにより、待機中のスレッドがすぐに実行を再開できるようになり、待機中のスレッドが共有データ (この場合は i の値) の更新状態を確実に監視できるようになります。効果的なマルチスレッド プログラミングには、condition_variables の動作を理解し、ロックを使用してスレッドを適切に同期することが重要です。