Чому pthread_cond_wait має помилкові пробудження?

Щоб процитувати сторінку людини:

При використанні змінних умов завжди є булевий предикат, що включає спільні змінні, пов'язані з кожною умовою очікування, що є істинним, якщо потік повинен продовжуватися. Можуть виникати помилкові пробудження функцій pthread_cond_timedwait () або pthread_cond_wait (). Оскільки повернення з pthread_cond_timedwait () або pthread_cond_wait () нічого не означає про значення цього предиката, предикат повинен бути повторно оцінений після такого повернення.

Отже, pthread_cond_waitможе повернутися, навіть якщо ви цього не сигналізували. Принаймні, на перший погляд, це здається досить жорстоким. Це було б як функція, яка випадковим чином повертає неправильне значення або випадково повертається до того, як фактично дійшла до правильного оператора return. Це здається великою помилкою. Але той факт, що вони вирішили задокументувати це на сторінці "man", а не виправляти, це, мабуть, свідчить про те, що є законна причина, чому в pthread_cond_waitкінцевому підсумку прокидаються неправдиво. Імовірно, є щось суттєве у тому, як це працює, що робить це таким чином, що це не може допомогти. Питання - що.

Чому ж pthread_cond_waitповернутися підроблено? Чому він не може гарантувати, що він прокинеться лише тоді, коли буде правильно сигналізовано? Чи може хтось пояснити причину своєї хибної поведінки?

Наступне пояснення дає Девід Р. Бутенхоф у "Програмуванні за допомогою ниток POSIX" (стор. 80):

Помилкові пробудження можуть здаватися дивними, але в деяких багатопроцесорних системах зробити так, що пробудження стану повністю передбачуване може істотно уповільнити всі операції зі змінною умовою.

У наступному обговоренні comp.programming.threads він розширює питання мислення, що стоїть за проектом:

Патрік Дойл написав: 
> У статті Том Пейн писав: 
>> Каз Кілхеку написав: 
>>: Це так тому, що іноді реалізація не може уникнути вставки 
>>: ці хибні пробудження; запобігти їх може бути дорого.

>> Але чому? Чому це так складно? Наприклад, чи говоримо ми
>> ситуації, коли очікує час очікування, як тільки надходить сигнал? 

> Знаєте, мені цікаво, чи дизайнери pthreads використовували таку логіку: 
> користувачі змінних умов повинні перевірити умову при виході, 
> тож ми не будемо покладати на них додаткового тягаря, якщо дозволимо 
> помилкові пробудження; і оскільки можливо, що допускати помилкові
> Пробудження може зробити реалізацію швидше, це може допомогти лише якщо ми 
> дозволити їх. 

> Вони, можливо, не мали на увазі якоїсь конкретної реалізації. 

Ти насправді зовсім не за горами, за винятком того, що ти не підштовхнув його досить далеко. 

Намір полягав у тому, щоб застосувати правильний / надійний код, вимагаючи предикатних циклів. Це було
керований напевно правильним академічним контингентом серед "основних ниток" в Росії 
Робоча група, хоча я не думаю, що хтось дійсно не погодився з наміром 
раз зрозуміли, що це означає. 

Ми дотримувалися цього наміру з кількома рівнями обґрунтування. Перше було те
"релігійно" за допомогою циклу захищає додаток від власного недосконалого 
практики кодування. Друге було те, що не важко було абстрактно уявити
машини та код реалізації, які могли б використовувати цю вимогу для вдосконалення 
виконання середніх умов очікування операцій через оптимізацію 
механізми синхронізації. 
/ ------------------ [David.Buten ... @ compaq.com] ------------------ \ 
| Compaq Computer Corporation POSIX Архітектор ниток |
| Моя книга: http://www.awl.com/cseng/titles/0-201-63392-2/ |
\ ----- [http://home.earthlink.net/~anneart/family/dave.html] ----- / 

Існують щонайменше дві речі, які «помилкові пробудження» можуть означати:

• Нитка, заблокована в, pthread_cond_waitможе повертатися з виклику, навіть якщо жодного дзвінка до pthread_call_signalабо pthread_cond_broadcastза умови не відбулося.
• Нитка, заблокована у pthread_cond_waitзворотах через виклик pthread_cond_signalабо pthread_cond_broadcast, однак після повторного придбання мютексу, виявляється, що основний предикат вже не відповідає дійсності.

Але останній випадок може мати місце, навіть якщо реалізація змінної умови не дозволяє колишній випадок. Розглянемо чергу споживачів-виробника та три нитки.

• Нитка 1 щойно видала елемент і випустила мютекс, і черга тепер порожня. Потік робить все, що робить з елементом, який він придбав на якомусь процесорі.
• Thread 2 намагається видалити елемент, але виявляє, що черга буде порожньою, коли вона перевіряється під mutex, дзвінками pthread_cond_waitта блоками в дзвінку, що очікує сигналу / трансляції.
• Нитка 3 отримує mutex, вставляє новий елемент у чергу, повідомляє змінну стану та звільняє замок.
• У відповідь на повідомлення з потоку 3 планується запустити потік 2, який чекав за умови.
• Однак перед тим, як потоку 2 вдається потрапити на процесор і захопити замок черги, потік 1 виконує своє поточне завдання і повертається до черги для більшої роботи. Він отримує блокування черги, перевіряє присудок і виявляє, що в черзі є робота. Він переходить до видалення елемента, у який вставлена ​​нитка 3, звільняє замок і робить все, що робиться з тим елементом, який запускається нитка 3.
• Нитка 2 тепер потрапляє на процесор і отримує блокування, але коли він перевіряє присудок, він виявляє, що черга порожня. Нитка 1 "вкрала" предмет, тому пробудження виявляється помилковим. Нитку 2 потрібно знову зачекати на умові.

Отже, оскільки вам уже завжди потрібно перевіряти присудок під циклом, це не має значення, якщо змінні, що лежать в основі, можуть мати інші види помилкових пробуджень.

У розділі "Кілька пробуджень за сигналом стану" в pthread_cond_signal є приклад реалізації pthread_cond_wait та pthread_cond_signal, який передбачає помилкові пробудження.

Хоча я не думаю, що це було розглянуто під час проектування, ось фактична технічна причина: У поєднанні з відміною нитки існують умови, за яких прийняти варіант прокинутися "неправдиво" може бути абсолютно необхідним, принаймні, якщо ви Ви готові накласти дуже сильні обмеження щодо можливих стратегій реалізації.

Ключова проблема полягає в тому, що якщо потік діє на скасування під час блокування pthread_cond_wait, побічні ефекти повинні бути такими, ніби він не споживає жодного сигналу змінної стану. Однак важко (і дуже обмежує) переконатися, що ви вже не споживали сигнал, коли ви починаєте діяти на скасування, і на цьому етапі неможливо "повторно" розмістити сигнал до змінної умови, оскільки ви можете опинитися в ситуації, коли абонент pthread_cond_signalвже виправданий, що зруйнував кондивар і звільнив пам'ять, в якій він проживав.

Допуск на помилкове пробудження дає вам легкий вихід. Замість того, щоб продовжувати діяти щодо скасування, коли він надходить, коли він заблокований на змінній стану, якщо ви, можливо, вже споживали сигнал (або якщо ви хочете лінуватися, незважаючи ні на що), ви можете оголосити, що натомість неправдива хвиля сталася, і повернутися з успіхом. Це зовсім не заважає операції скасування, тому що правильний абонент просто діятиме на очікуванні скасування наступного разу, коли він замикається та pthread_cond_waitповторюється.