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

• Ctничего не происходит. В этом случае t в конце области видимости будет неподключаемым. Это приведет к завершению программы (см. раздел 7.3).

• Дляtвызывается функция-членjoin. В этом случае фьючерсу fut не требуется блокировать деструктор, так как вызов join уже имеется в вызывающем коде.

• Дляtвызывается функция-членdetach. В этом случае фьючерсу fut не требуется вызывать detach в деструкторе, поскольку вызывающий код уже сделал это.

Другими словами, когда у вас есть фьючерс, соответствующий общему состоянию, получившемуся из-за применения std::packaged_task, обычно не требуется принимать специальную стратегию деструкции, так как решение о прекращении выполнения программы, подключении или отключении потока принимается в коде, работающем с потоком std::thread, в котором выполняется std::packaged_task.

Следует запомнить

• Деструкторы фьючерсов обычно просто уничтожают данные-члены фьючерсов.

• Последний фьючерс, ссылающийся на общее состояние неотложенной задачи, запущенной с помощью std::async, блокируется до завершения этой задачи.

7.5. Применяйте фьючерсы >void для одноразовых сообщений о событиях

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

Очевидный подход заключается в применении переменной условия. Если назвать задачу, которая обнаруживает условие, задачей обнаружения, а задачу, которая на него реагирует, — задачей реакции, то выразить стратегию просто: задача реакции ожидает переменную условия, а поток задачи обнаружения выполняет ее уведомление при наступлении события. При

std::condition_variable cv; // Переменная условия события
std::mutex m;               // Мьютекс для использования с cv

код задачи обнаружения прост настолько, насколько это возможно:

…                 // Обнаружение события
cv.notify_one(); // Уведомление задачи реакции

Если требуется уведомить несколько задач реакции, можно заменить notify_one на notify_all, но пока что будем считать, что у нас только одна задача реакции.

Код задачи реакции немного сложнее, поскольку перед вызовом 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 (во многих языках программирования, не только в С++) не редкость ситуация, когда код, ожидающий переменную условия, может быть пробужден, даже если переменная условия не была уведомлена. Такое пробуждение называется ложным пробуждением