3 回答
TA贡献1875条经验 获得超3个赞
在的析构函数中std::thread,std::terminate如果发生以下情况,则称为:
线程未加入(带有t.join())
并且也未与(分离t.detach())
因此,你应该总是要么join还是detach一个线程执行的流之前到达析构函数。
当程序终止(即main返回)时,不会等待在后台执行的其余分离线程;相反,它们的执行被挂起,并且它们的线程本地对象被破坏。
至关重要的是,这意味着不会解开那些线程的堆栈,因此不会执行某些析构函数。根据那些破坏者应该采取的行动,情况可能像程序崩溃或被杀死一样糟糕。希望操作系统将释放文件等上的锁,但是您可能损坏了共享内存,半写文件等。
因此,您应该使用join还是detach?
采用 join
除非您需要更大的灵活性并且愿意提供同步机制来独自等待线程完成,否则您可以使用detach
TA贡献1808条经验 获得超4个赞
detach如果您不打算等待线程完成,则应调用,join而线程将一直运行直到完成,然后终止而不必让主线程专门等待它。
detach基本上会释放能够实施所需的资源join。
这是一个致命的错误,如果一个线程对象结束其生命,并没有join,也不detach曾被称为; 在这种情况下terminate被调用。
TA贡献1921条经验 获得超9个赞
这个答案的目的是在标题答题,而不是解释之间的差异join和detach。那么什么时候应该std::thread::detach使用?
在正确维护的C ++代码中std::thread::detach,根本不应使用。程序员必须确保所有创建的线程正常退出以释放所有获取的资源并执行其他必要的清理操作。这意味着通过调用放弃线程所有权detach不是一种选择,因此join应在所有情况下使用。
但是,某些应用程序依赖于可能包含无限阻塞功能的旧的且通常设计不完善且受支持的API。将这些函数的调用移到专用线程中以避免阻塞其他内容是一种常见的做法。无法使此类线程正常退出,因此使用of join只会导致主线程阻塞。在这种情况下,使用detach而不是thread用动态存储持续时间分配对象然后有意地泄漏对象的方法不太邪恶。
#include <LegacyApi.hpp>
#include <thread>
auto LegacyApiThreadEntry(void)
{
auto result{NastyBlockingFunction()};
// do something...
}
int main()
{
::std::thread legacy_api_thread{&LegacyApiThreadEntry};
// do something...
legacy_api_thread.detach();
return 0;
}
- 3 回答
- 0 关注
- 2539 浏览
添加回答
举报