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

Это решение возлагает на вас ответственность за то, что если вы используете объект std::thread, то должны сделать его неподключаемым на всех путях из области видимости, в которой он определен. Но охват всех путей может быть весьма сложным. Он включает как нормальный выход из области видимости, так и такие выходы, как с помощью return, continue, break, gotoили исключения. Этих путей может быть великое множество.

Всякий раз, когда надо выполнить некоторое действие на всех путях, ведущих из блока, естественным подходом является размещение этого действия в деструкторе локального объекта. Такие объекты известны как объекты RAII , а соответствующие классы — классы RAII . ( RAII означает “Resource Acquisition Is Initialization”, “захват ресурса есть инициализация”, хотя на самом деле речь идет о методе деструкции, а не инициализации.) RAII-классы — распространенное явление в стандартной библиотеке. Примерами являются контейнеры STL (деструктор каждого контейнера уничтожает его содержимое и освобождает память), стандартные интеллектуальные указатели (в разделах 4.1-4.3 поясняется, что деструктор std::unique_ptrвызывает удалитель для объекта, на который указывает, а деструкторы std::shared_ptrи std::weak_ptrуменьшают счетчики ссылок), объекты std::fstream(их деструкторы закрывают соответствующие файлы) и многое другое. Тем не менее стандартного RAII-класса для объектов std::threadнет, вероятно, потому что Комитет по стандартизации, отвергнув и join, и detachкак варианты по умолчанию, просто не знал, что же должен делать такой класс.

К счастью, такой класс несложно написать самостоятельно. Например, приведенный далее класс позволяет вызывающей функции указать, должна ли быть вызвана функция-член joinили detachпри уничтожении объекта ThreadRAII(объект RAII для std::thread):

class ThreadRAII {

public:

enum class DtorAction { join, detach }; // См. enum class

// в разделе 3.4

ThreadRAII(std::thread&& t, DtorAction а) // Деструктор для

: action(a), t(std::move(t)) {} // t выполняет а

~ThreadRAII() { // См. ниже о

if (t.joinable()) { // проверке на

if (action == DtorAction::join) { // подключаемость

t.join();

} else {

t.detach();

}

}

}

std::thread& get() { return t; } // См. ниже

private:

DtorAction action;

std::thread t;

};

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

• Конструктор принимает только rvalue std::thread, поскольку мы хотим перемещать передаваемый объект std::threadв объект ThreadRAII. (Вспомните, что объекты std::threadне копируются.)

• Порядок параметров выбран интуитивно понятным для программиста (сначала указывается поток, а затем — способ его деструкции), но список инициализации членов соответствует порядку объявлений членов-данных. Этот порядок размещает объект std::threadпоследним. В этом классе порядок не имеет значения, но в общем случае возможна ситуация, когда инициализация одного члена-данных зависит от другого, а поскольку объекты std::threadмогут запускаться на выполнение немедленно после их инициализации, объявлять их последними в классе — неплохая привычка. Это гарантирует, что в момент их создания все члены-данные, им предшествующие, уже инициализированы, и, таким образом, асинхронно выполняемый поток, соответствующий объекту 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неподключаемым.