Почему pthread_cond_wait имеет ложные пробуждения?

Чтобы процитировать man страницу:

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

Таким образом, pthread_cond_waitможете вернуться, даже если вы не сообщили об этом. По крайней мере, на первый взгляд это кажется довольно жестоким. Это было бы похоже на функцию, которая случайно вернула неправильное значение или вернула случайно, прежде чем она действительно достигла правильного оператора возврата. Это похоже на серьезную ошибку. Но тот факт, что они решили документировать это на странице руководства, а не исправлять это, похоже, указывает на то, что есть законная причина, по которой мы pthread_cond_waitвнезапно просыпаемся. Предположительно, есть что-то внутреннее в том, как это работает, что делает его таким, что с этим ничего не поделаешь. Вопрос в том, что.

Почему же pthread_cond_waitвернуться поддельно? Почему он не может гарантировать, что проснется только тогда, когда на него правильно подали сигналы? Кто-нибудь может объяснить причину его ложного поведения?

Следующее объяснение дано Дэвидом Р. Бутенхофом в «Программирование с помощью потоков POSIX» (стр. 80):

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

В следующем обсуждении comp.programming.threads он расширяет концепцию дизайна:

Патрик Дойл написал: 
> В статье Том Пейн писал: 
>> Каз Кылхеку писал: 
>>: Это так, потому что реализации иногда не могут избежать вставки 
>>: эти ложные пробуждения; это может быть дорогостоящим, чтобы предотвратить их.

>> Но почему? Почему это так сложно? Например, мы говорим о
>> ситуации, когда время ожидания истекает, когда поступает сигнал? 

> Вы знаете, мне интересно, использовали ли разработчики pthreads такую ​​логику: 
> пользователи условных переменных в любом случае должны проверять условие при выходе, 
> поэтому мы не будем возлагать на них никакого дополнительного бремени, если позволим 
> ложные пробуждения; и так как это возможно, что позволяет ложным
> пробуждения могут сделать реализацию быстрее, это может помочь, только если мы 
> Позволь им. 

> Возможно, они не имели в виду какую-то конкретную реализацию. 

Вы на самом деле совсем недалеко, за исключением того, что вы не продвинулись достаточно далеко. 

Намерение состояло в том, чтобы заставить корректный / устойчивый код, требуя циклов предикатов. Это было
движимый доказуемо корректным академическим контингентом среди 
рабочая группа, хотя я не думаю, что кто-то действительно не согласен с намерением 
однажды они поняли, что это значит. 

Мы следовали этому намерению с несколькими уровнями оправдания. Первое было
«религиозное» использование цикла защищает приложение от собственного несовершенства 
практика кодирования. Во-вторых, абстрактно представить было несложно.
машины и код реализации, который может использовать это требование для улучшения 
выполнение операций ожидания среднего состояния за счет оптимизации 
механизмы синхронизации. 
/ ------------------ [David.Buten ... @ compaq.com] ------------------ \ 
| Компьютерная корпорация Compaq POSIX Thread Architect |
| Моя книга: 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 только что удалил элемент из очереди и освободил мьютекс, и очередь теперь пуста. Поток делает все, что он делает с элементом, который он приобрел на некотором процессоре.
• Поток 2 пытается удалить из очереди элемент, но обнаруживает, что очередь пуста при проверке под мьютексом, вызовами pthread_cond_waitи блоками в вызове, ожидающем сигнал / трансляцию.
• Поток 3 получает мьютекс, вставляет новый элемент в очередь, уведомляет переменную условия и снимает блокировку.
• В ответ на уведомление от потока 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повторном вызове.