ミューテックスをロックせずにpthread_cond_signalを呼び出す

pthread_cond_signalを呼び出す前にミューテックスをロックし、呼び出した後にミューテキストのロックを解除する必要があることをどこかで読みました。

pthread_cond_signal（）ルーチンは、条件変数を待機している別のスレッドに信号を送る（またはウェイクアップする）ために使用されます。ミューテックスがロックされた後に呼び出す必要があり、pthread_cond_wait（）ルーチンを完了するためにミューテックスのロックを解除する必要があります。

私の質問は、ミューテックスをロックせずにpthread_cond_signalまたはpthread_cond_broadcastメソッドを呼び出しても大丈夫ではないかということです。

条件と信号を変更するコードパスでミューテックスをロックしないと、ウェイクアップが失われる可能性があります。このプロセスのペアを検討してください。

プロセスA：

pthread_mutex_lock(&mutex);
while (condition == FALSE)
    pthread_cond_wait(&cond, &mutex);
pthread_mutex_unlock(&mutex);

プロセスB（不正解）：

condition = TRUE;
pthread_cond_signal(&cond);

次に、命令のこの可能なインターリーブを検討します。ここで、次のようにcondition始まりますFALSE。

Process A                             Process B

pthread_mutex_lock(&mutex);
while (condition == FALSE)

                                      condition = TRUE;
                                      pthread_cond_signal(&cond);

pthread_cond_wait(&cond, &mutex);

condition今でTRUEはなく、プロセスAは、条件変数にこだわって待っている-それは、ウェイクアップ信号を逃しました。プロセスBを変更してミューテックスをロックする場合：

プロセスB（正しい）：

pthread_mutex_lock(&mutex);
condition = TRUE;
pthread_cond_signal(&cond);
pthread_mutex_unlock(&mutex);

...その場合、上記は発生しません。ウェイクアップを見逃すことはありません。

（実際には、の後に自分自身を移動できますが、これによりスレッドのスケジューリングが最適化されなくなる可能性があり、条件自体を変更するため、このコードパスにすでにあるミューテックスをロックする必要があります）。pthread_cond_signal()pthread_mutex_unlock()

このマニュアルによると：

pthread_cond_broadcast()または pthread_cond_signal()機能は 、それが現在所有しているミューテックスか否かのスレッドによって呼び出されるスレッドが呼び出していることpthread_cond_wait() やpthread_cond_timedwait()その待機時の条件変数に関連付けられているが、ただし、予測可能なスケジューリング動作が必要な場合、そのミューテックスはスレッド呼び出しpthread_cond_broadcast()または によってロックされます pthread_cond_signal()。

予測可能なスケジューリング動作ステートメントの意味は、comp.programming.threadsでDave Butenhof（POSIXスレッドを使用したプログラミングの作成者）によって説明されており、ここから入手できます。

caf、サンプルコードでは、プロセスBはcondition最初にミューテックスをロックせずに変更します。プロセスBがその変更中にミューテックスを単にロックし、それでも呼び出す前にミューテックスのロックを解除したpthread_cond_signal場合、問題はありません---私はそれについて正しいですか？

私は直感的にカフェの位置が正しいと信じています。pthread_cond_signalミューテックスロックを所有せずに呼び出すのは悪い考えです。しかし、cafの例は、実際にはこの立場を支持する証拠ではありません。ミューテックスを最初にロックしない限り、ミューテックスによって保護されている共有状態を変更することは悪い考えであるという、はるかに弱い（実際には自明の）立場を支持する単なる証拠です。

呼び出しのpthread_cond_signal後にpthread_mutex_unlock正しい動作が得られるが、呼び出しのpthread_mutex_unlock後にpthread_cond_signal誤った動作が生じるサンプルコードを誰かが提供できますか？