pthread_cond_tを使用して、ミューテックスを関連付ける必要があります。条件を通知するときに、次のようなコードを確認しました。
pthread_mutex_lock(&mutex);
//code that makes condition true
pthread_cond_broadcast(&cond);
pthread_mutex_unlock(&mutex);
と
pthread_mutex_lock(&mutex);
//code that makes condition true
pthread_mutex_unlock(&mutex);
pthread_cond_broadcast(&cond);
どちらが適切な方法ですか？（それは重要ですか？）
シンク (およびその他のソース) が何をしているかによって異なります。
2 番目のコード サンプルでは、ロック解除とブロードキャストの間に、他のスレッドの束がやって来て、条件を再度 false にするいくつかの組み合わせを実行する可能性があります。その後、無意味にブロードキャストすることになります。また、条件を変更したときと同じウェイターのセットがあるとは限りません。これは、設計に影響する場合としない場合があります。
適切なシンクは、特にブロードキャストを使用している場合は、起こされて条件が false であっても気にしません。条件が「true」に変更されるたびに最終的にブロードキャストが続く限り、適切に作成されたシンクを使用すると、ロックの有無にかかわらず条件変数を無条件にブロードキャストできると確信しています。
なので、あまり関係ないと思いますが、個人的にはロックを掛けたまま配信したいと思います。「アトミックな変更と信号」は、「変更 ... しばらくして信号」と比較して、ホワイトボードの状態図を単純化する可能性があります。
どちらも適切ですが (許可されていないミューテックスなしで待機するのとは異なります)、2 番目のケースで失敗する可能性のある使用法を考え出すのはそれほど難しくないと思います。最初。ただし、おそらく、少し変わったことをしているウェイターを巻き込む必要があるでしょう.
仕様では、「予測可能なスケジューリング動作が必要な場合、そのミューテックスは pthread_cond_broadcast() または pthread_cond_signal() を呼び出すスレッドによってロックされる」とややこしく述べています。
http://www.opengroup.org/onlinepubs/009695399/functions/pthread_cond_signal.html