Виклик pthread_cond_signal без блокування mutex

Я десь читав, що нам слід заблокувати мьютекс перед викликом pthread_cond_signal і розблокувати мьютекс після його виклику:

Підпрограма pthread_cond_signal () використовується для сигналізації (або пробудження) чергового потоку, який очікує на змінну умови. Його слід викликати після того, як mutex заблоковано, і він повинен розблокувати мьютекс, щоб завершити процедуру 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, але процес А застряг, чекаючи на змінну умови - він пропустив сигнал пробудження. Якщо ми змінимо процес 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не маючи блокування mutex, - погана ідея. Але приклад кафе насправді не є підтвердженням цієї позиції; це просто доказ на підтримку набагато слабшої (практично самоочевидної) позиції, що поганою ідеєю є зміна спільного стану, захищеного мьютексом, якщо ви не заблокували цей мьютекс спочатку.

Хто-небудь може надати зразок коду, у якому виклик з pthread_cond_signalподальшим результатом pthread_mutex_unlockдає правильну поведінку, а виклик з pthread_mutex_unlockподальшим результатом pthread_cond_signalдає неправильну поведінку?