Параллельное и распределенное программирование на С++

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

Семантика ожидания по условию

Важно от м етить, что, когда функции 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 или С++, причем здесь можно организовать отмену потоков с использованием встроенного в язык механизма исключительных ситуаций. Это правило гарантирует, что каждый обработчик исключения, защищающий критический раздел, всегда может безопасно отталкиваться от следующего факта: связанный мьютекс уже заблокирован, независимо от того, в каком именно месте критического раздела было сгенерировано исключение. Без этого правила обработчики исключительных ситуаций не могли бы единообразно выполнять свою работу в отношении блокировки, и поэтому кодирование стало бы весьма громоздким.

Следовательно, поскольку в случае, когда запрос на отмену приходит во время ожидания, в отношении состояния блокировки должна быть выполнена определенная инструкция, при этом должно быть выбрано такое определение, которое сделает кодирование приложения наиболее удобным и свободным от ошибок.