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

Мы бы предпочли воспользоваться советом из раздела 7.1 и программировать параллельность на основе задач, но предположим, что нам надо установить приоритет потока, выполняющего фильтрацию. Как пояснялось в разделе 7.1, для этого требуется системный дескриптор потока, а он доступен только через API std::thread; API задач (т.e. фьючерсы) такой возможности не предоставляет. Поэтому мы работаем с потоками, а не с задачами.

Мы могли бы начать с кода наподобие следующего:

// См. constexpr в разделе 3.9

constexpr auto tenMillion = 10000000;

// Возвращает значение, указывающее, были ли выполнены

// вычисления; std::function см. в разделе 2.1

bool doWork(std::function filter,

int maxVal = tenMillion) {

// Значения, удовлетворяющие фильтру:

std::vector goodVals;

// Заполнение goodVals:

std::thread t([&filter, maxVal, &goodVals] {

for (auto i = 0; i <= maxVal; ++i) {

if (filter(i)) goodVals.push_back(i); }

});

// Используем системный дескриптор потока для

// установки приоритета:

auto nh = t.native_handle();

if ( conditionsAreSatisfied() ) {

t.join(); // Завершаем t

performComputation(goodVals);

return true; // Вычисление выполнено

}

return false; // Вычисление не выполнено

}

Перед тем как пояснить, почему этот код проблематичен, я замечу, что инициализирующее значение tenMillionв С++14 можно сделать более удобочитаемым, воспользовавшись возможностью C++14 использовать апостроф для разделения цифр:

constexpr auto tenMillion = 10'000'000; // С++14

Замечу также, что установка приоритета tпосле его запуска напоминает забивание двери конюшни после того, как лошадь уже убежала. Лучше начинать с tв приостановленном состоянии (тем самым делая возможным изменение его приоритета до выполнения вычислений), но я не хочу отвлекать вас этим кодом. Потерпите до раздела 7.5, в нем показано, как начинать работать с потоками в приостановленном состоянии.

Вернемся к функции doWork. Если вызов conditionsAreSatisfied()возвращает true, все в порядке, но если он вернет значение falseили сгенерирует исключение, объект tбудет подключаемым в момент вызова деструктора при окончании работы doWork. Это приведет к завершению работы программы.

Вы можете удивиться, почему деструктор std::threadведет себя столь неподобающе. Да просто потому, что два других варианта, описанных далее, еще хуже.

• Неявный вызов join . В этом случае деструктор std::threadбудет ожидать завершения соответствующего асинхронного потока. Звучит разумно, но может привести к аномалиям производительности, которые будет трудно отследить. Например, было бы нелогичным, чтобы функция doWorkожидала применения фильтра ко всем значениям, если вызов conditionsAreSatisfied()уже вернул значение false.

• Неявный вызов detach . В этом случае деструктор std::threadразрывает связь между объектом std::threadи его потоком, отключая последний от объекта. Поток продолжает выполняться. Это звучит не менее разумно, чем применение join, но проблемы отладки, к которым это может привести, делают этот вариант еще худшим. Например, в функции doWorkлокальная переменная goodValsзахватывается лямбда-выражением по ссылке. Она также изменяется в лямбда-выражении (с помощью вызова push_back). Предположим теперь, что во время асинхронного выполнения лямбда-выражения вызов conditionsAreSatisfied()вернул false. В таком случае функция doWorkдолжна завершиться, а ее локальные переменные (включая goodVals) должны быть уничтожены. Ее кадр стека удаляется, и выполнение потока продолжается с точки вызова doWork.

Инструкции после этой точки могут в некоторой иной точке выполнять вызовы других функций, и как минимум одна из них может занять место в стеке, ранее занятое кадром стека doWork. Назовем эту функцию f. Во время работы fлямбда-выражение из doWorkпродолжает асинхронно выполняться и может вызвать push_backдля памяти в стеке, которая ранее использовалась для локальной переменной goodVals, а теперь принадлежит кадру стека f. Такой вызов может изменить память, использовавшуюся для goodVals, а это означает, что с точки зрения fсодержимое памяти в ее кадре стека может внезапно измениться! Только представьте себе, что вам придется отлаживать такое .

Комитет по стандартизации решил, что последствия уничтожения подключаемого потока достаточно неприятны, чтобы полностью их запретить (указав, что уничтожение подключаемого потока приводит к завершению программы).