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

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] Вы можете обратиться к книге Энтони Вильямса (Anthony Williams) С++ Concurrency in Action (Manning Publications, 2012), раздел 9.2. .

В разделе 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при уничтожении объекта может привести к трудно отлаживаемым аномалиям производительности.

• Применение detachпри уничтожении объекта может привести к трудно отлаживаемому неопределенному поведению.

• Объявляйте объекты std::threadв списке членов-данных последними.

В разделе 7.3 вы узнали, что подключаемый std::threadсоответствует базовому системному потоку выполнения. Фьючерс для неотложенной задачи (см. раздел 7.2) имеет схожую связь с системным потоком. А раз так, и объекты std::thread, и объекты фьючерсов можно рассматривать как дескрипторы (handles) системных потоков.