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

В предположении, что требуется приостановить поток только один раз (после создания, но до запуска функции потока), можно воспользоваться 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]. Здесь я хотел бы показать, как исходный код (т.e. без применения ThreadRAII) может быть расширен для приостановки и последующего продолжения не одной задачи реакции, а нескольких. Это простое обобщение, поскольку ключом является применение std::shared_future вместо std::future в коде react. Как вы уже знаете, функция-член share объекта std::future передает владение его общим состоянием объекту std::shared_future, созданному share, а после этого код пишется почти сам по себе. Единственной тонкостью является то, что каждый поток реакции требует собственную копию std::shared_future, которая ссылается на общее состояние, так что объект std::shared_future, полученный от share, захватывается по значению лямбда-выражением, запускаемым в потоке реакции:

std::promise p;           // Как и ранее

void detect()                    // Теперь для нескольких
{                                // задач реакции
 auto sf=p.get_future().share(); // Тип sf -
                                 // std::shared_future

 std::vector vt;    // Контейнер для потоков
                                 // реакции

 for (int i = 0; i < threadsToRun; ++i) {
  // Ожидание локальной копии sf;
  // см. emplace_back в разделе 8.2:
  vt.emplace_back([sf]{ sf.wait();
  react(); });
 }
 …                               // detect "зависает", если
                                 // здесь генерируется
                                 // исключение!

 p.set_value();                  // Продолжение всех потоков
 …
 for (auto& t : vt) {            // Все потоки делаются
  t.join();                      // неподключаемыми;
 }                               // см. "auto&" в разделе 1.2
}

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

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

• Для простого сообщения о событии дизайн с применением переменных условия требует избыточных мьютексов, накладывает ограничения на относительное выполнение задач обнаружения и реакции и требует от задачи реакции проверки того, что событие в действительности имело место.

• Дизайн с использованием флага устраняет эти проблемы, но использует опрос, а не блокировку.

• Переменные условия и флаги могут быть использованы совместно, но получающийся механизм сообщений оказывается несколько неестественным.

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

7.6. Используйте >std::аtomic для параллельности, >volatile — для особой памяти

Бедный квалификатор volatile! Такой неверно понимаемый… Его даже не должно быть в этой главе, потому что он не имеет ничего общего с параллельным программированием. Но в других языках (например, в Java и С#) он полезен для такого программирования, и даже в С++ некоторые компиляторы перенасыщены volatile с семантикой, делающей его применимым для параллельного программирования (но только при компиляции этими конкретными компиляторами). Таким образом, имеет смысл обсудить