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

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

• Если задача обнаружения уведомляет переменную условия до вызова 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(); // Сообщаем задаче реакции