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

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

• ThreadRAII предоставляет функцию get, обеспечивающую доступ к соответствующему объекту std::thread. Это аналог функций get, предоставляемых стандартными интеллектуальными указателями и обеспечивающих доступ к их базовым обычным указателям. Предоставление get позволяет избежать необходимости дублировать в классе ThreadRAII весь интерфейс std::thread, а также означает, что объекты ThreadRAII могут использоваться в контекстах, где требуются объекты std::thread.

• Перед тем как деструктор ThreadRAII вызовет функцию-член объекта t типа std::thread, он проверяет, является ли этот объект подключаемым. Это необходимо, поскольку применение join или detach к неподключаемому объекту приводит к неопределенному поведению. Может быть так, что клиент создает std:: thread, затем создает из него объект ThreadRAII, использует функцию-член get для получения доступа к t, а затем выполняет перемещение из t или вызывает для него join или detach. Каждое из этих действий делает t неподключаемым.

if (t.joinable()) {
 if (action == DtorAction::join) {
  t.join();
 } else {
  t.detach();
 }
}

Если в приведенном фрагменте вас беспокоит возможность условия гонки из-за того, что между вызовами t.joinable() и join или detach другой поток может сделать t неподключаемым, то ваша интуиция заслуживает похвалы, но ваши опасения в данном случае беспочвенны. Объект std::thread может изменить состояние с подключаемого на неподключаемое только путем вызова функции-члена, например join, detach или операции перемещения. В момент вызова деструктора ThreadRAII никакие другие потоки не должны вызывать функцию-член для этого объекта. При наличии одновременных вызовов, определенно, имеется условие гонки, но не внутри деструктора, а в клиентском коде, который пытается вызвать одновременно две функции-члена объекта (деструктор и что-то еще). В общем случае одновременные вызовы функций-членов для одного объекта безопасны, только если все они являются константными функциями-членами (см. раздел 3.10).

Использование ThreadRAII в нашей функции doWork может выглядеть следующим образом:

bool doWork(std::function filter, // Как и ранее
            int maxVal = tenMillion)
{
 std::vector goodVals;                  // Как и ранее
 ThreadRAII t( // use RAII object
  std::thread([&filter, maxVal, &goodVals] {
   for (auto i = 0; i <= maxVal; ++i)
   { if (filter(i)) goodVals.push_back(i); }
  }),
  ThreaRAII::DtorAction::join                // Действие RAII
 );

 auto nh = t.get().native_handle();
 …
 if (conditionsAreSatisfied()) {
  t.get().join();
  performComputation(goodVals);
  return true;
 }
 return false;
}

В этом случае мы выбрали использование join для асинхронно выполняющегося потока в деструкторе ThreadRAII, поскольку, как мы видели ранее, применение detach может привести к настоящим кошмарам при отладке. Мы также видели ранее, что применение join может вести к аномалиям производительности (что, откровенно говоря, также может быть неприятно при отладке), но выбор между неопределенным поведением (к которому ведет detach), завершением программы (при использовании обычного std::thread) и аномалиями производительности предопределен — мы выбираем меньшее из зол.

Увы, раздел 7.5 демонстрирует, что применение ThreadRAII для выполнения join при уничтожении std::thread иногда может привести не к аномалии производительности, а к полному “зависанию” программы. “Правильным” решением этого типа проблем было бы сообщить асинхронно выполняющемуся лямбда-выражению, что в его услугах мы больше не нуждаемся и оно должно поскорее завершиться. Увы, С++11 не поддерживает прерываемые потоки. Их можно реализовать вручную, но данный вопрос выходит за рамки нашей книги[24].

В разделе 3.11 поясняется, что, поскольку ThreadRAII объявляет деструктор, в нем нет генерируемых компилятором перемещающих операций, но причин, по которым ThreadRAII не должен быть перемещаемым, тоже нет. Если бы компилятор генерировал такие функции, то они демонстрировали бы верное поведение, так что просто попросим компилятор их все же сгенерировать:

class ThreadRAII {
public:
 enum class DtorAction { join, detach };        // Как и ранее

 ThreadRAII(std::thread&& t, DtorAction a)      // Как и ранее
 : action(а), t(std::move(t)) {}
 ~ThreadRAII() {
  …                                             // Как и ранее
 }

 ThreadRAII(ThreadRAII&&) = default;            // Поддержка
 ThreadRAII& operator=(ThreadRAII&&) = default; // перемещения

 std::threads get() { return t; }               // Как и ранее

private:                                        // Как и ранее
 DtorAction action;
 std::thread t;
};

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

• Делайте std::thread неподключаемыми на всех путях выполнения.

• Применение join при уничтожении объекта может привести к трудно отлаживаемым аномалиям производительности.