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

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

Быстродействие мьютексов и условных переменных

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

При использовании мьютексов и условных переменных всегда пытаются обеспечить последовательность, которая считается обычным случаем: заблокировать мьютекс, получить доступ к общим данным и разблокировать мьютекс. Ожидание по условной переменной — относительно редкая ситуация. Например, при реализации блокировки чтения-записи коду, который получает блокировку чтения, обычно нужно лишь инкрементировать счетчик считывающих потоков (при взаимном исключении доступа). Вызывающий поток будет реально ожидать по условной переменной только тогда, когда уже существует активный записывающий поток. Поэтому эффективность операции синхронизации связана с «ценой» блокировки-разблокировки мьютекса, а не с ожиданием по условию. Обратите внимание на то, что в обычном случае переключения контекста не происходит.

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

Особенности мьютексов и условных переменных

Было предложено отделить захват и освобождение мьютекса от ожидания по условию. Но это предложение было отклонено, по причине «сборной природы» этой операции, которая в действительности упрощает реализации реального времени. Такие реализации могут незаметно перемещать высокоприоритетный поток между условной переменной и мьютексом, тем самым предотвращал излишние переключения контекстов и обеспечивал более детерминированное владение мьютексом при получении сигнала ожидающим потоком. Таким образом, вопросы равнодоступности и приоритетности могут быть решены непосредственно самой дисциплиной планирования. К тому же, широко распространенная операция ожидания по условию соответствует существующей практике.

Планирование поведения мьютексов и условных переменных

Примитивы (базовые элементы) синхронизации, которые могут противоречить используемой стратегии планирования путем установки «своего» правила упорядочения, считаются нежелательными. Выбор среди потоков, ожидающих освобождения мьютексов и условных переменных, происходит в порядке, который зависит именно от стратегии планирования, а не от какой-то другой дисциплины, устанавливающей некий фиксированный порядок (имеется в виду, например, 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);