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

(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;
bool flag(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 заблокирован)
}
…                                     // Продолжение реакции
                                      // (m разблокирован)

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