为什么我需要显式分离短期变量？

Question

假设我有一个小操作，我想在一个单独的线程中执行。我不需要知道它何时完成，也不需要等待它完成，但我不希望该操作阻塞我当前的线程。当我编写以下代码时，我会崩溃：

void myFunction() {
    // do other stuff
    std::thread([]()
    {
        // do thread stuff
    });
}

通过将线程分配给变量并将其分离来解决此崩溃：

void myFunction() {
    // do other stuff
    std::thread t([]()
    {
        // do thread stuff
    });
    t.detach();
}

为什么需要这一步？或者有没有更好的方法来创建一个小的一次性线程？

Answer 1

Because the std::thread::~thread() specification says so:

一个线程对象在之后没有关联的线程（并且可以安全地销毁）

• 它是默认构造的
• 它被移出
• join() 已被调用
• detach() 已被调用

看起来detach() 是其中唯一一个对您的情况有意义的，除非您想将线程对象（通过移动）返回给调用者。

为什么需要这一步？

考虑线程对象代表一个长时间运行的执行“线程”（轻量级进程或内核可调度实体或类似实体）。

允许您在线程仍在执行时销毁对象，使您无法随后加入该线程（并找到该线程的结果）。这可能是一个逻辑错误，但它也可能使正确退出程序变得困难。

或者有没有更好的方法来创建一个小的一次性线程？

不是很明显，但通常最好使用线程池在后台运行任务，而不是启动和停止大量短期线程。

您也许可以改用std::async()，但future 在某些情况下，如果您尝试丢弃它，它会在析构函数中返回可能块。

Answer 2

见the documentation of the destructor of std:thread:

如果*this 有关联的线程(joinable() == true)，则调用std::terminate()。

您应该明确表示您不关心线程会发生什么，并且您可以对它失去任何控制。这就是detach 的用途。

一般来说，这看起来像是一个设计问题，所以崩溃是有道理的：很难就在这种情况下应该发生什么提出一个普遍且不令人惊讶的规则（例如，您的程序也可以正常结束其执行 - 应该发生什么用线程？）。

Answer 3

基本上，您的用例需要调用detach()，因为您的用例很奇怪，而不是 C++ 试图简化的。

虽然 Java 和 .Net 可以轻松地让您放弃关联线程仍在运行的 Thread 对象，但在 C++ 模型中，Thread 在某种意义上更接近于成为线程Thread 对象的存在与它所指的执行的生命周期或至少可连接性相吻合。请注意，不启动 Thread 是不可能创建它的（除了默认构造函数，它实际上只是在移动语义的服务中），或者复制它或从线程 id 创建一个。 C++ 希望Thread 比线程寿命更长。

保持这种状态有很多好处。线程控制数据的最终清理不必由操作系统自动完成，因为一旦Thread 消失，就没有任何东西可以尝试加入它。确保具有线程存储的变量及时销毁更容易，因为主线程是最后一个退出的（除非有一些移动恶作剧）。缺少的join - 这是一个非常常见的错误类型 - 在运行时会被正确标记。

相比之下，让一些线程飘到远处是允许的，但这是不寻常的事情。除非它通过同步对象与您的其他线程交互，否则无法确保它完成了它应该做的任何事情。一个分离的线程在reinterpret_cast 的级别上：你可以告诉编译器你知道一些它不知道的东西，但这必须是明确的，而不仅仅是你不知道的函数的结果 打电话。

Answer 4

考虑一下：线程 A 创建线程 B 并且线程 A 离开其执行范围。线程 B 的句柄即将丢失。现在应该怎么办？有几种可能性，最明显的如下：

1. 线程 B 已分离并继续独立执行
2. 线程 A 在退出自己的作用域之前等待（加入）线程 B

现在您可以争论哪个更好：1 还是 2？我们（编译器）应该如何决定其中哪一个更好？

所以设计者所做的是不同的：crash 终止代码，以便开发人员明确地选择这些解决方案之一。为了避免隐含的（也许是不需要的）行为。这是给你的一个信号：“嘿，现在注意，这段代码很重要，我（编译器）不想为你做决定”。