ction a) // 在析构函数,对t采取动作a : action(a), t(std::move(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; };
我希望这份代码是一目了然的,但下面的几点可能对你有帮助:
构造函数只接受右值的std::thread,因为我们想要把传进来的std::thread对象移动到ThreadRAII对象里。(std::thread是不能被拷贝的类型。) 对于调用者,构造函数的形参顺序的设计十分直观(指定std::thread作为第一个参数,而销毁动作作为第二个参数,比起反过来直观很多),但是,成员初始化列表被设计来匹配成员变量声明的顺序,成员变量的顺序是把std::thread放到最后。在这个类中,这顺序不会导致什么不同,不过一般来说,一个成员变量的初始化有可能依赖另一个成员变量,而因为std::thread对象初始化之后可能会马上运行函数,所以把它们声明在一个类的最后是一个很好的习惯。那保证了当std::thread构造的时候,所有在它之前的成员变量都已经被初始化,因此std::thread成员变量对应的底层异步执行线程可以安全地取得它们。 ThreadRAII提供了一个get函数,它是一个取得内部std::thread对象的入口,这类似于标准智能指针提供了get函数(它提供了取得内部原生指针的入口)。提供get可以避免ThreadRAII复制std::thread的所有接口,而这也意味着ThreadRAII可以用于请求std::thread对象的上下文。 ThreadRAII的析构函数在调用std::thread对象t的成员函数之前,它先检查确保t是可连接的。这是必需的,因为对一个不可连接的线程调用join或detach会产生未定义行为。某个用户构建了一个std::thread,然后用它创建ThreadRAII对象,再使用get请求获得t,接着移动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对象的析构函数被调用时,不应该有其他线程调用该对象的成员函数。如果这两个函数同时发生,那的确是竞争,但竞争没有发生在析构函数内,它是发生在试图同时调用两个成员函数(析构函数和其他)的用户代码内。一般来说,对于一个对象同时调用两个成员函数,也只有是const成员函数(看条款16)才能确保线程安全。
在我们doWork的例子中使用ThreadRAII,代码是这样的:
bool doWork(std::function
goodVals; // 如前 ThreadRAII t( std::thread([&filter, maxVal, &goodVals) // 使用RAII对象 { for (auto i = 0; i <= maxVal; ++i) { if (filter) goodVals.push_back(i); } }), ThreadRAII::DtorAction::join // RAII动作 ); auto nh = t.get().native_handle(); ... if (conditionsAreStatisfied()) { t.get().join(); performConputation(goodVals); return true; } return false; }
在这个例子中,我们选择在ThreadRAII析构函数中,对异步执行线程调用join函数,因为我们之前看到,调用detach函数会导致一些恶梦般的调试。我们之前也看到过join会导致性能异常(实话说,那调试起来也很不爽),但在未定义行为(detach给的)、程序终止(使用原始std::thread会产生)、性能异常之前做出选择,性能异常就像是瘸子里面挑出的将军 。
额,条款39展示了使用ThreadRAII在std::thread销毁中进行join不会导致性能异常,而是导致挂起程序。这种问题的“合适的”解决方案是:和异步执行的lambda进行交流,当我们不需要它时候,它可以早早的返回;但C++11不支持这种可中断的线程。我们可以手动实现它们,但那个话题已经超越了这本书的范围了(在《C++并发编程实战》的章节9.2可以找到)。
条款17解释过,因为ThreadRAII声明了析构函数,所以不会有编译器生成的移动操作,但这里ThreadRAII对象没有理由不能移动。如果编译器生成的这些函数,这些函数的可以行为是正确的,所以显示请求创建它们是适合的:
class ThreadRAII { public: enum class DtorAction { join, detach }; // 如前 ThreadRAII(std::thread&& t, DtorAction a) // 如前 : action(a), t(std::move(t)) {} ~ThreadRAII() { ... // 如前 } ThreadRAII(ThreadRAII&&) = default; // 支持移动 ThreadRAA& operator=(ThreadRAII&) = default; std::thread& get() { return t; } private: DtorAction action; std::thread t; };
总结
需要记住的4点:
- 在所有路径上,让std::thread变得不可连接。
- 在销毁时用join会导致难以调试的性能异常。
- 在销毁时用detach会导致难以调试的未定义行为。
- 在成员变量列表最后声明std::thread。