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

Объекты std::packaged_taskне копируются, так что когда ptпередается в конструктор std::thread, он должен быть приведен к rvalue (с помощью std::move; см. раздел 5.1):

std::thread t(std::move(pt)); // Выполнение pt потоком t

Этот пример дает некоторое представление о нормальном поведении деструкторов фьючерсов, но его легче увидеть, если собрать весь код вместе в одном блоке:

{ // Начало блока

std::packaged_task

pt(calcValue);

auto fut = pt.get_future();

std::thread t(std::move(pt));

… // См. Ниже

} // Конец блока

Наиболее интересный код скрывается за троеточием “ …” следующим за созданием объекта tтипа std:: threadи предшествующим концу блока. Имеются три основные возможности.

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

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

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

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

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

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

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

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

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