Вызов pthread_cond_signal без блокировки мьютекса

Я где-то читал, что мы должны заблокировать мьютекс перед вызовом pthread_cond_signal и разблокировать мьютекс после его вызова:

Подпрограмма pthread_cond_signal () используется для сигнализации (или пробуждения) другого потока, который ожидает переменной условия. Он должен вызываться после того, как мьютекс заблокирован, и должен разблокировать мьютекс, чтобы процедура pthread_cond_wait () завершилась.

Мой вопрос: нельзя ли вызывать методы pthread_cond_signal или pthread_cond_broadcast без блокировки мьютекса?

Если вы не заблокируете мьютекс в пути кода, который изменяет состояние и сигналы, вы можете потерять пробуждение. Рассмотрим эту пару процессов:

Процесс А:

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, но процесс А застревают ожидания на переменном состоянии - это пропущенный сигнал пробуждения. Если мы изменим процесс 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().

Значение оператора предсказуемого расписания объяснил Дэйв Бутенхоф (автор книги « Программирование с помощью потоков POSIX» ) на comp.programming.threads и доступен здесь .

caf, в вашем примере кода процесс B модифицируется conditionбез предварительной блокировки мьютекса. Если бы процесс B просто заблокировал мьютекс во время этой модификации, а затем все еще разблокировал мьютекс перед вызовом pthread_cond_signal, не было бы проблем - я прав в этом?

Я интуитивно считаю, что позиция caf верна: вызов pthread_cond_signalбез блокировки мьютекса - плохая идея. Но пример caf на самом деле не является доказательством в поддержку этой позиции; это просто свидетельство в поддержку гораздо более слабой (практически самоочевидной) позиции о том, что изменение общего состояния, защищенного мьютексом, является плохой идеей, если вы сначала не заблокировали этот мьютекс.

Может ли кто-нибудь предоставить образец кода, в котором вызов, pthread_cond_signalза которым следует, pthread_mutex_unlockдает правильное поведение, но вызов, pthread_mutex_unlockза которым следует, pthread_cond_signalдает неправильное поведение?