Скотт Мейерс - Эффективный и современный С++. 42 рекомендации по использованию С++11 и С++14

Код задачи реакции немного сложнее, поскольку перед вызовом waitдля переменной условия он должен блокировать мьютекс с помощью объекта std::unique_lock. (Блокировка мьютекса перед ожиданием переменной условия типична для многопоточных библиотек. Необходимость блокировки мьютекса с помощью объекта std::unique_lockявляется частью API С++11.) Вот как выглядит концептуальный подход:

… // Подготовка к реакции

{ // Открытие критического раздела

std::unique_lock

lk(m); // Блокировка мьютекса

cv.wait(lk);// Ожидание уведомления;

// неверно!

… // Реакция на событие

// (m заблокирован)

} // Закрытие критического раздела;

// разблокирование m с

// помощью деструктора lk

… // Продолжение реакции

// (m разблокирован)

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

Даже если пропустить этот вопрос, все равно остаются две проблемы, которым, определенно, следует уделить внимание.

• Если задача обнаружения уведомляет переменную условия до вызова wait задачей реакции, задача реакции “зависнет”. Чтобы уведомление переменной условия активизировало другую задачу, эта другая задача должна находиться в состоянии ожидания переменной условия. Если вдруг задача обнаружения выполняет уведомление до того, как задача реакции выполняет wait, эта задача реакции пропустит уведомление и будет ждать его вечно.

• Вызов wait приводит к ложным пробуждениям. В потоковых API (во многих языках программирования, не только в С++) не редкость ситуация, когда код, ожидающий переменную условия, может быть пробужден, даже если переменная условия не была уведомлена. Такое пробуждение называется ложным пробуждением (spurious wakeup). Корректный код обрабатывает такую ситуацию, проверяя, что ожидаемое условие в действительности выполнено, и это делается первым, немедленно после пробуждения. API переменных условия С++ делает это исключительно простым, поскольку допускает применение лямбда-выражений (или иных функциональных объектов), которые проверяют условие, переданное в wait. Таким образом, вызов waitв задаче реакции может быть записан следующим образом:

cv.wait(lk,

[]{ return Произошло ли событие ;});

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

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

Многие разработчики используют совместно используемый булев флаг. Изначально этот флаг имеет значение false. Когда поток обнаружения распознает ожидаемое событие, он устанавливает этот флаг:

std::atomic flag(false); // Совместно используем флаг;

// std::atomic см. в разделе 7.6

… // Обнаружение события

flag = true; // Сообщение задаче обнаружения

Со своей стороны поток реакции просто опрашивает флаг. Когда он видит, что флаг установлен, он знает, что ожидаемое событие произошло:

… // Подготовка к реакции

while (!flag);// Ожидание события

… // Реакция на событие

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

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

Распространено сочетание подходов на основе переменных условия и флагов. Флаг указывает, произошло ли интересующее нас событие, но доступ к флагу синхронизирован мьютексом. Поскольку мьютекс предотвращает параллельный доступ к флагу, не требуется, как поясняется в разделе 7.6, чтобы флаг был объявлен как std::atomic; вполне достаточно простого bool. Задача обнаружения в этом случае может имеет следующий вид:

std::condition_variable cv; // Как и ранее

std::mutex m;

boolflag(false); // Не std::atomic

… // Обнаружение события

{

std::lock_guard g(m);// Блокировка m

// конструктором g

flag = true; // Сообщаем задаче реакции

// (часть 1)

} // Снятие блокировки m

// деструктором g

cv.notify_one(); // Сообщаем задаче реакции

// (часть 2)

А вот задача реакции:

… // Подготовка к реакции

{ // Как и ранее

std: :unique_lock lk(m); // Как и ранее

cv.wait(lk, []{ return flag; }); // Применение лямбда-

// выражения во избежание

// ложных пробуждений

… // Реакция на событие

// (m заблокирован)