Почему pthread cond wait имеет ложные пробуждения?
чтобы процитировать man-страницу:
при использовании переменных условий всегда существует логический предикат, включающий общие переменные, связанные с каждым условием wait, которое истинно, если поток должен продолжаться. Могут возникать ложные пробуждения из функций pthread_cond_timedwait() или pthread_cond_wait (). Поскольку возврат из pthread_cond_timedwait() или pthread_cond_wait() ничего не означает о значении этого предиката, предикат должен быть повторно оценен после такого возвращения.
и pthread_cond_wait может вернуться, даже если вы не сигнализировали об этом. По крайней мере, на первый взгляд, это кажется довольно жестоким. Это было бы похоже на функцию, которая случайно вернула неправильное значение или случайно вернулась до того, как она фактически достигла правильного оператора возврата. Это похоже на серьезную ошибку. Но тот факт, что они решили задокументировать это в man-странице, а не исправить, казалось бы, указывает на то, что есть законная причина, почему pthread_cond_wait в конечном итоге просыпается ложно. Предположительно, есть что-то внутреннее в том, как это работает, что делает его таким, что с этим ничего не поделаешь. Вопрос в том, что.
почему тут pthread_cond_wait ложно вернуться? Почему он не может гарантировать, что он проснется только тогда, когда он будет правильно сигнализирован? Может кто-нибудь объяснить причину его ложного поведения?
3 ответов:
следующие объяснения Дэвид Р. Butenhof в "Программирование с потоками POSIX" (стр. 80):
ложные пробуждения могут звучать странно, но в некоторых многопроцессорных системах, делая условие пробуждения полностью предсказуемым, может существенно замедлить все операции с переменными условия.
в следующем comp.программирование.темы обсуждения, Он расширяет мышление за дизайн:
Patrick Doyle wrote: > In article , Tom Payne wrote: > >Kaz Kylheku wrote: > >: It is so because implementations can sometimes not avoid inserting > >: these spurious wakeups; it might be costly to prevent them. > >But why? Why is this so difficult? For example, are we talking about > >situations where a wait times out just as a signal arrives? > You know, I wonder if the designers of pthreads used logic like this: > users of condition variables have to check the condition on exit anyway, > so we will not be placing any additional burden on them if we allow > spurious wakeups; and since it is conceivable that allowing spurious > wakeups could make an implementation faster, it can only help if we > allow them. > They may not have had any particular implementation in mind. You're actually not far off at all, except you didn't push it far enough. The intent was to force correct/robust code by requiring predicate loops. This was driven by the provably correct academic contingent among the "core threadies" in the working group, though I don't think anyone really disagreed with the intent once they understood what it meant. We followed that intent with several levels of justification. The first was that "religiously" using a loop protects the application against its own imperfect coding practices. The second was that it wasn't difficult to abstractly imagine machines and implementation code that could exploit this requirement to improve the performance of average condition wait operations through optimizing the synchronization mechanisms. /------------------[ [email protected] ]------------------\ | Compaq Computer Corporation POSIX Thread Architect | | My book: http://www.awl.com/cseng/titles/0-201-63392-2/ | \-----[ http://home.earthlink.net/~anneart/family/dave.html ]-----/
есть по крайней мере две вещи "ложное пробуждение" может означать:
- поток, заблокированный в pthread_cond_wait, может вернуться из вызова, даже если вызов сигнала или широковещательной передачи по условию не произошел.
- поток, заблокированный в pthread_cond_wait, возвращается из-за вызова signal или 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, который включает в себя ложные пробуждения.
Comments