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

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

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

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

В предположении, что требуется приостановить поток только один раз (после создания, но до запуска функции потока), можно воспользоваться vоid-фьючерсом. Вот как выглядит эта методика.

std::promise p;

void react(); // Функция потока реакции

void detect() // Функция потока обнаружения

{

std::thread t([] // Создание потока

{

p.get_future().wait();// Приостановлен до

react(); // установки фьючерса

});

… // Здесь t приостановлен

// до вызова react

p.set_value();// Запуск t (и тем самым вызов react)

… // Выполнение дополнительной работы

t.join(); // Делаем t неподключаемым

} // (см. раздел 7.3)

Поскольку важно, чтобы поток tстал неподключаемым на всех путях выполнения, ведущих из detect, применение RAII-класса наподобие приведенного в раздела 7.3 класса ThreadRAIIвыглядит целесообразным. На ум приходит следующий код:

void detect()

{

ThreadRAII tr( // RAII-объект

std::thread([] {

p.get_future().wait();

react();

}),

ThreadRAII::DtorAction::join// Рискованно! (См. ниже)

);

… // Поток в tr приостановлен

p.set_value(); // Поток в tr разблокирован

}

Выглядит безопаснее, чем на самом деле. Проблема в том, что, если в первой области “ …” (с комментарием “Поток в trприостановлен”) будет сгенерировано исключение, для pникогда не будет вызвана функция set_value. Это означает, что вызов waitв лямбда- выражении никогда не завершится. А это, в свою очередь, означает, что поток, выполняющий лямбда-выражение, никогда не завершается, а это представляет собой проблему, поскольку RAII-объект trсконфигурирован для выполнения joinдля этого потока в деструкторе. Другими словами, если в первой области кода “ …” будет сгенерировано исключение, эта функция “зависнет”, поскольку деструктор trникогда не завершится.

Имеются способы решения и этой проблемы, но я оставлю их в священном виде упражнения для читателя [26] Разумной отправной точкой для начала изучения этого вопроса является запись в моем блоге от 24 декабря 2013 года в The View From Aristeia , “ThreadRAII + Thread Suspension = Trouble?” . Здесь я хотел бы показать, как исходный код (т.e. без применения ThreadRAII) может быть расширен для приостановки и последующего продолжения не одной задачи реакции, а нескольких. Это простое обобщение, поскольку ключом является применение std::shared_futureвместо std::futureв коде react. Как вы уже знаете, функция-член shareобъекта std::futureпередает владение его общим состоянием объекту std::shared_future, созданному share, а после этого код пишется почти сам по себе. Единственной тонкостью является то, что каждый поток реакции требует собственную копию std::shared_future, которая ссылается на общее состояние, так что объект std::shared_future, полученный от share, захватывается по значению лямбда-выражением, запускаемым в потоке реакции: