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

Альтернативный вариант заключается в том, чтобы избежать переменных условия, мьютексов и флагов с помощью вызова wait задачей реакции для фьючерса, установленного задачей обнаружения. Это может показаться странной идеей. В конце концов, в разделе 7.4 поясняется, что фьючерс представляет принимающий конец канала связи от вызываемой функции к (обычно асинхронной) вызывающей функции, а между задачами обнаружения и реакции нет отношений “вызываемая-вызывающая”. Однако в разделе 7.4 также отмечается, что канал связи, передающий конец которого представляет собой std::promise, а принимающий — фьючерс, может использоваться для большего, чем простой обмен информацией между вызываемой и вызывающей функциями. Такой канал связи может быть использован в любой ситуации, в которой необходима передача информации из одного места вашей программы в другое. В нашем случае мы воспользуемся им для передачи информации от задачи обнаружения задаче реакции, и информация, которую мы будем передавать, — о том, что произошло интересующее нас событие.

Проект прост. Задача обнаружения имеет объект std::promise (т.e. передающий конец канала связи), а задача реакции имеет соответствующий фьючерс. Когда задача обнаружения видит, что произошло ожидаемое событие, она устанавливает объект std::promise (т.e. выполняет запись в канал связи). Тем временем задача реакции выполняет вызов wait своего фьючерса. Этот вызов wait блокирует задачу реакции до тех пор, пока не будет установлен объект std::promise.

И std::promise, и фьючерсы (т.e. std::future и std::shared_ future) являются шаблонами, требующими параметр типа. Этот параметр указывает тип данных, передаваемый по каналу связи. Однако в нашем случае никакие данные не передаются. Единственное, что представляет интерес для задачи реакции, — что ее фьючерс установлен. Нам нужно указать для шаблонов std::promise и фьючерса тип, показывающий, что по каналу связи не будут передаваться никакие данные. Таким типом является void. Задача обнаружения, таким образом, будет использовать std::promise, а задача реакции — std::future или std::shared_future. Задача обнаружения устанавливает свой объект std::promise, когда происходит интересующее нас событие, а задача реакции ожидает с помощью вызова wait своего фьючерса. Даже несмотря на то, что задача реакции не получает никаких данных от задачи обнаружения, канал связи позволит задаче реакции узнать, что задача обнаружения “записала” void-данные с помощью вызова set_value своего объекта std::promise. Так что для данного

std::promise p;  // Коммуникационный канал

код задачи обнаружения тривиален:

…                      // Обнаружение события
p.set_value();         // Сообщение задаче реакции

Код задачи реакции не менее прост:

…                      // Подготовка к реакции
p.get_future().wait(); // Ожидание фьючерса,
                       // соответствующего p
…                      // Реакция на событие

Этот подход, как и использование флага, не требует мьютексов, работает независимо от того, устанавливает ли задача обнаружения свой объект std::promise до того, как задача реакции вызывает wait, и невосприимчива к ложным пробуждениям. (Этой проблеме подвержены только переменные условия.) Подобно подходу на основе переменных условия задача реакции оказывается истинно заблокированной после вызова wait, так что во время ожидания не потребляет системные ресурсы. Идеально, нет?

Не совсем. Конечно, подход на основе фьючерсов обходит описанные неприятности, но ведь есть и другие. Например, в разделе 7.4 поясняется, что между std::promise и фьючерсом находится общее состояние, а общие состояния обычно выделяются динамически. Поэтому следует предполагать, что данное решение приводит к расходам на динамическое выделение и освобождение памяти.

Вероятно, еще более важно то, что std::promise может быть установлен только один раз. Канал связи между std::promise и фьючерсом является одноразовым механизмом: он не может быть использован многократно. Это существенное отличие от применения переменных условия и флагов, которые могут использоваться для связи много раз. (Переменная условия может быть уведомлена неоднократно, а флаг может сбрасываться и устанавливаться вновь.)

Ограничение однократности не столь тяжкое, как можно подумать. Предположим, что вы хотите создать системный поток в приостановленном состоянии. То есть вы хотели бы заплатить все накладные расходы, связанные с созданием потока, заранее, с тем, чтобы как только вы будете готовы выполнить что-то в этом потоке, вы сможете делать это сразу, без задержки. Или, может быть, вы захотите создать поток в приостановленном состоянии с тем, чтобы можно было настроить его перед выполнением. Такая настройка может включать, например, установку приоритета. API параллельных вычислений С++ не предоставляет способ выполнить такие действия, но объекты std::thread предлагают функцию-член native_handle, результат которой призван предоставить доступ к API многопоточности используемой платформы (обычно потокам POSIX или Windows). Низкоуровневые API часто позволяют настраивать такие характеристики потоков, как приоритет или сродство.