pthread_cond_timedwait, pthread_cond_wait
Имя
pthread_cond_timedwait, pthread_cond_wait — функции ожидания условия.
Синопсис
THR
#include <pthread.h>
int pthread_cond_timedwait ( pthread_cond_t *restrict cond, pthread_mutex_t *restrict mutex, const struct timespec *restrict abstime);
int pthread_cond_wait (pthread_cond_t *restrict cond, pthread_mutex_t *restrict mutex);
Описание
Функции pthread_cond_timedwait() и pthread_cond_wait() используются для блокирования потоков по условной переменной. Они вызываются с использованием мьютекса mutex , блокируемого вызывающим потоком; в противном случае результирующее поведение не определено.
Эти функции автоматически освобождают мьютекс mutex и обеспечивают блокирование вызывающего потока по условной переменной cond; «автоматически» здесь означает «автоматический доступ к мьютексу со стороны другого потока с последующим доступом к условной переменной». Другими словами, если какой-то другой поток может получить мьютекс после его освобождения вызывающим потоком, то результат последующего вызова функции pthread_cond_broadcast () или pthread_cond_signal () в этом (другом) потоке будет таким, как если бы он имел место после блокирования вызывающего потока.
При успешном выполнении мьютекс будет заблокирован, а владеть им будет вызывающий поток.
При использовании условных переменных всегда существует булев предикат, совместно используемый этими переменными, которые связаны с каждым ожидаемым условием. Это условие становится истинным, если поток должен продолжать выполнение. При использовании функций pthread_cond_timedwait() или pthread_cond_wait () возможны фиктивные запуски. Поскольку возврат из этих функций не подразумевает ничего, кроме оценки значения упомянутого выше предиката, он должен вычисляться после каждого такого выхода из функции.
Результат использования нескольких мьютексов для параллельно выполняемых операций pthread_cond_timedwait () или pthread_cond_wait () по одной и той же условной переменной не определен; другими словами, условная переменная связывается с уникальным мьютексом, когда поток ожидает заданного значения условной переменной, и это (динамическое) связывание завершится вместе с завершением ожидания.
Ожидание условия (синхронизированное или нет) представляет собой «точку отмены». Если статус возможности аннулирования дл я потока соответствует значению PTHREAD_CANCEL_DEFERRED, побочным эффектом действий, выполняемых по запросу на аннулирование во время ожидания условия будет повторный захват мьютекса перед вызовом первого обработчика запроса на отмену. Другими словами, результат будет выглядеть так, как если бы поток был разблокирован и получил воз м ожность выполниться до точки выхода из вызова функции pthread_cond_timedwait() или pthread_cond_wait(), но в этой точке «обнаружил» запрос на от м ену и в м есто возврата к инициатору вызова функции pthread_cond_timedwait() или pthread_cond_wait() приступил к выполнению действий по аннулированию, которые включают вызов обработчиков этого запроса.
Поток, который был разблокирован по причине отмены в то время, пока он был заблокирован в вызове функции pthread_cond_timedwait() или pthread_cond_wait (), не будет использовать условный сигнал, который можно направить параллельно на условную переменную, если существуют другие потоки, заблокированные по этой условной переменной.
Функция pthread_cond_timedwait() эквивалентна функции pthread_cond_wait (), за исключением того, что она возвращает код ошибки, если абсолютное время, заданное пара м етро м abstime, наступит (т.е. системное время станет равным или превысит значение abstime) до того, как будет передано (с помощью сигнала) условие cond, или если абсолютное время, заданное параметром abstime, уже наступило в момент вызова.
C S Если поддерживается опция Clock Selection, условная переменная будет иметь атрибут часов, определяющий механизм, который предназначен для измерения времени, заданного параметром abstime . По истечении заданного времени функция pthread_cond_timedwait() освободит и снова захватит мьютекс, адресуемый параметром mutex . Функция pthread_cond_timedwait () также представляет собой точку отмены.
Если потоку, ожидающему значения условной переменной, передается сигнал, то при возврате из обработчика сигнала поток возобновит ожидание этой условной переменной (как будто не было никакого прерывания на обработку сигнала) или возвратит нуль вследствие фиктивного запуска.
Возвращаемые значения
За исключением кода ошибки [ETIMEDOUT], все проверки на наличие ошибок реализованы так, как если бы они были выполнены в самом начале работы каждой функции, и код ошибки в случае ее обнаружения возвращается до модификации состояния мьютекса, заданного пара м етро м mutex, или условной переменной, заданной параметром cond.
При успешном завершении возвращается нулевое значение; в противном случае — код ошибки, обозначающий ее характер.
Ошибки
Функция pthread_cond_timedwait () завершится неудачно, если:
[ETIMEDOUT] вре м я, заданное пара м етро м abstime, наступило.
Функции pthread_cond_timedwait() и pthread_cond_wait() м огут завершиться неудачно, если:
[EINVAL] значение, заданное хотя бы одни м из пара м етров cond, mutex или abstime, недействительно;
[EINVAL] для выполнения параллельных операций pthread_cond_timedwait() или pthread_cond_wait () по одной и той же условной пере м енной были задействованы различные мьютексы;
[EPERM] во вре м я вызова любой из функций мьютексом не владел текущий поток.
Эти функции не возвращают код ошибки [EINTR].
Примеры
Отсутствуют.
Замечания по использованию
Отсутствуют.
Логическое обоснование
Семантика ожидания по условию
Важно от м етить, что, когда функции pthread_cond_wait() и pthread_cond_timedwait() завершаются без ошибки, соответствую щ ий предикат может все еще иметь ложное значение. Аналогично, когда функция pthread_cond_timedwait() возвращается с ошибкой истечения времени ожидания, соответствующий предикат может иметь истинное значение из-за неизбежной «гонки» между истечением периода ожидания и изменением состояния предиката.
В некоторых реализациях, в частности мультипроцессорных, иногда возможно пробуждение сразу нескольких потоков, если сигнал об изменении состояния условной переменной генерируется одновременно на различных процессорах.
В общем случае при каждом завершении ожидания по условию поток должен оценивать значение предиката, связанного с ожиданием по условию, чтобы узнать, может ли он безопасно продолжать выполнение, ожидать или объявить тайм-аут. Возврат из состояния ожидания не означает, что соответствующий предикат имеет конкретное значение (ЛОЖЬ или ИСТИНА).
Поэтому рекомендуется ожидание по условию выражать в коде, эквивалентно м циклу «while», который выполняет проверку предиката.
Семантика ожидания по времени
Абсолютное время было выбрано для задания параметра лимита времени по двум причинам. Во-первых, несмотря на то, что измерение относительного времени нетрудно реализовать в начале функции, для которой задается абсолютное время, с заданием абсолютного времени в начале функции, которая определяет относительное время, связано условие «гонок». Предположим, например, что функция clock_gettime() возвращает текущее время, а функция cond_relative_timed_wait () использует относительное время.
clock_gettime(CLOCK_REALTIME, &now)
reltime = sleep_til_this_absolute_time -now;
cond_relative_timed_wait (с, m, &reltime);
Если поток выгружается между первой и последней инструкциями, поток блокируется слишком надолго. Однако блокирование несущественно, если используется абсолютное время. Кроме того, абсолютное время не нужно пересчитывать, если оно используется в цикле несколько раз.
Для случаев, когда системные часы работают дискретно, можно предполагать, что реализации обработают любые ожидания по времени, истекающие в промежутке между дискретными состояниями, так, как если бы нужное время уже наступило.
Аннулирование потока и ожидание по условию
Ожидание по условию, синхронизированное или нет, является точкой отмены (аннулирования) потока. Другими словами, функции pthread_cond_wait () или pthread_cond_timedwait () представляют собой точки, в которых обнаружен необработанный запрос на отмену. Дело в том, что в этих точках возможно бесконечное ожидание, т.е. какое бы событие ни ожидалось, даже при совершенно корректной программе оно может никогда не произойти; например, входные данные, получения которых ожидает программа, могут быть никогда не отправлены. Сделав же ожидание по условию точкой отмены, поток можно безопасно аннулировать и выполнить соответствующие обработчики даже в случае, если программа «увязнет» в бесконечном ожидании.
Побочный эффект обработки запроса на от м ену потока в случае, когда он заблокирован по условной переменной, состоит в повторном захвате мьютекса до вызова любого из обработчиков. Это позволяет гарантировать, что обработчик запроса на отмену выполняется в таком же статусе, который имеет критический код, расположенный до и после вызова функции ожидания по условию. Это правило также требуется соблюдать при взаимодействии с POSIX -потоками, написанными на таких языках программирования, как Ada или С++, причем здесь можно организовать отмену потоков с использованием встроенного в язык механизма исключительных ситуаций. Это правило гарантирует, что каждый обработчик исключения, защищающий критический раздел, всегда может безопасно отталкиваться от следующего факта: связанный мьютекс уже заблокирован, независимо от того, в каком именно месте критического раздела было сгенерировано исключение. Без этого правила обработчики исключительных ситуаций не могли бы единообразно выполнять свою работу в отношении блокировки, и поэтому кодирование стало бы весьма громоздким.
Следовательно, поскольку в случае, когда запрос на отмену приходит во время ожидания, в отношении состояния блокировки должна быть выполнена определенная инструкция, при этом должно быть выбрано такое определение, которое сделает кодирование приложения наиболее удобным и свободным от ошибок.
При выполнении действий, связанных с получение м запроса на от м ену потока в то вре м я, когда он заблокирован по условной пере м енной, реализация требует гарантии, что поток не будет использовать ни один из условных сигналов, направленных на условную переменную, если существуют другие потоки, ожидающие сигнала по этой условной переменной. Соблюдение этого правила позволяет избежать условий взаимоблокировки, которые могут возникнуть в случае, если два независимых запроса (один действует в потоке, а другой связан с условной переменной) не были обработаны независимо.
Быстродействие мьютексов и условных переменных
Предполагается, что мьютексы должны блокироваться только для нескольких инструкций. Такая практика почти автоматически вытекает из желания программистов избегать длинных последовательностей программных инструкций (которые способны снизить общую эффективность параллелизма).
При использовании мьютексов и условных переменных всегда пытаются обеспечить последовательность, которая считается обычным случаем: заблокировать мьютекс, получить доступ к общим данным и разблокировать мьютекс. Ожидание по условной переменной — относительно редкая ситуация. Например, при реализации блокировки чтения-записи коду, который получает блокировку чтения, обычно нужно лишь инкрементировать счетчик считывающих потоков (при взаимном исключении доступа). Вызывающий поток будет реально ожидать по условной переменной только тогда, когда уже существует активный записывающий поток. Поэтому эффективность операции синхронизации связана с «ценой» блокировки-разблокировки мьютекса, а не с ожиданием по условию. Обратите внимание на то, что в обычном случае переключения контекста не происходит.
Из вышесказанного отнюдь не следует, что эффективность ожидания по условию не важна. Поскольку существует потребность по крайней мере в одном переключении контекста на рандеву (взаимодействие между параллельными процессами), то эффективность ожидания по условию также важна. Цена ожидания по условной переменной должна быть намного меньше минимальной цены одного переключения контекста и времени, затрачиваемого на разблокировку и блокировку мьютекса.
Особенности мьютексов и условных переменных
Было предложено отделить захват и освобождение мьютекса от ожидания по условию. Но это предложение было отклонено, по причине «сборной природы» этой операции, которая в действительности упрощает реализации реального времени. Такие реализации могут незаметно перемещать высокоприоритетный поток между условной переменной и мьютексом, тем самым предотвращал излишние переключения контекстов и обеспечивал более детерминированное владение мьютексом при получении сигнала ожидающим потоком. Таким образом, вопросы равнодоступности и приоритетности могут быть решены непосредственно самой дисциплиной планирования. К тому же, широко распространенная операция ожидания по условию соответствует существующей практике.
Планирование поведения мьютексов и условных переменных
Примитивы (базовые элементы) синхронизации, которые могут противоречить используемой стратегии планирования путем установки «своего» правила упорядочения, считаются нежелательными. Выбор среди потоков, ожидающих освобождения мьютексов и условных переменных, происходит в порядке, который зависит именно от стратегии планирования, а не от какой-то другой дисциплины, устанавливающей некий фиксированный порядок (имеется в виду, например, FIFO-дисциплина или учет приоритетов). Таким образом, только стратегия планирования определяет, какой поток (потоки) будет запущен для продолжения работы.
Синхронизированное ожидание по условию
Функция pthread_cond_timedwait () позволяет приложению прервать ожидание наступления конкретного условия после истечения заданного интервала времени. Рассмотрим следующий пример.
(void) pthread_mutex_lock (&t. mn);
t.waiters++;
clock_gettime (CLOCK_REALTIME, &ts) ;
ts.tv_sec += 5;
rc = 0;
while (! mypredicate (&t) && rc == 0)
rc = pthread_cond_timedwait (&t.cond, &t.mn, &ts);
t.waiters--;
if (rc == 0) setmystate (&t);
(void) pthread_mutex_unlock (&t.mn);
Абсолютный параметр времени ожидания позволяет не пересчитывать его значение каждый раз, когда программа проверяет значение предиката блокирования. Если бы время ожидания было задано относительной величиной, соответствующий пересчет пришлось бы делать перед каждым вызовом функции. Это было бы особенно трудно сделать, поскольку такому колу пришлось бы учитывать возможность дополнительных запусков вследствие дополнительной сигнализации по условной переменной, которые могут происходить до того, как предикат станет истинным или истечет время ожидания.
Будущие направления
Отсутствуют.
Смотри также
pthread_cond_signal (), pthread_cond_broadcast (), том Base Definitions стандарта IEEE Std 1003.1-2001, <pthread.h>.
Последовательность внесения изменений
Функции впервые реализованы в выпуске Issue 5. Включены для согласования с расширением POSIX Threads Extension.
Issue 6
Функции pthread_cond_timedwait() и pthread_cond_wait() от м ечены как часть опции Threads.
К описанию прототипа функции pthread_cond_wait () был приложен список опечаток Open Group Corrigendum U021/9.
Для согласования со стандартом IEEE Std 1003.1j-2000 раздел «Описание» был отредактирован путем добавления семантики для опции Clock Selection.
В раздел «Ошибки» внесен еще один код ошибки [EPERM] в ответ на включение интерпретации IEEE PASC Interpretation 1003.1с #28.
В целях согласования со стандартом ISO/IEC 9899: 1999 в прототипы функций pthread_cond_timedwait() и pthread_cond_wait() было добавлено ключевое слово restrict.