为什么在线程销毁之前必须调用join（）或detach（）？

Question

我不明白为什么当一个std::线程被破坏时，它必须处于连接（）或分离（）状态。

连接等待线程完成，而分离不会。似乎有一些我不理解的中间状态。因为我的理解是连接和分离是互补的：如果我不调用连接（），那么分离（）是默认的。

逻辑上的detach（）应该是线程的默认行为，因为这是线程的定义，它们是并行执行的，与其他线程无关。

那么，当线程对象被破坏时，为什么要调用terminate（）呢？为什么标准不能简单地将线程视为分离的线程？

我不理解在线程被破坏之前，当连接（）或分离（）没有被调用时终止程序背后的原理。这样做的目的是什么？

更新：

我最近发现了这个。安东尼·威廉姆斯在他的书《行动中的并发》中说，“C 17的一个建议是建立一个类似于std::线程的joining_thread类，只是它会像scoped_thread一样自动加入析构函数。这在委员会中没有得到共识，所以它没有被标准所接受（尽管它仍在C20的轨道上，d::jthray）..."

Answer 1

您可能希望线程在完成后完全清理自己，而不留下任何痕迹。这意味着你可以开始一个线程，然后忘记它。

但是，您可能还希望能够在线程运行时管理它，并获得它在运行时提供的任何返回值。在这种情况下，如果一个线程在完成后自行清理，您试图管理它可能会导致崩溃，因为您将访问一个可能无效的句柄。为了在线程完成时检查返回值，返回值必须存储在某个地方，这意味着线程不能完全清理，因为存储返回值的地方必须保留。

在大多数框架中，默认情况下，您会得到第二个选项。您可以管理线程（通过中断它、向它发送信号、加入它或其他方式），但它不能自行清理。如果您更喜欢第一个选项，有一个函数可以获得该行为（分离），但这意味着您可能无法访问线程，因为它可能会继续存在，也可能不会继续存在。

Answer 2

您会感到困惑，因为您将std:：thread对象与其引用的执行线程混为一谈。std:：thread对象是一个C对象（内存中的一组字节），用作执行线程的引用。调用std:：thread:：detach时，发生的情况是std:：thread对象与执行线程“分离”——它不再引用（任何）执行线程，执行线程继续独立运行。但是std:：thread对象仍然存在，直到它被销毁。

当一个执行线程完成时，它将其退出信息存储到引用它的std:：thread对象中，如果有一个（如果它被分离，那么就没有一个，因此退出信息被丢弃）它对std:：thread对象没有其他影响，尤其是std:：thread对象不会被销毁，并且会一直存在，直到其他人销毁它。

Answer 3

从技术上来说，答案是“因为规范这么说”，但这是一个迟钝的答案。我们无法理解设计师的想法，但这里有一些问题可能是其中的原因：

对于POSIX线程，子线程必须在退出后加入，否则它们将继续占用系统资源（如内核中的进程表项）。这是通过pthread_join（）完成的。如果进程持有子线程的HANDLE，则Windows有一个有点类似的问题；尽管Windows不需要完全连接，但进程仍然必须调用CloseHandle（）来释放线程上的重新计数。

由于std:：thread是一个跨平台的抽象，它受到POSIX要求的约束，POSIX要求连接。

理论上，d::线程析构函数可以调用pthread_join（）而不是抛出异常，但这（主观上）可能会增加死锁的风险。而正确编写的html" target="_blank">程序会知道何时在安全时间插入连接。

另见：

• https://en.wikipedia.org/wiki/Zombie_process
• https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessa
• https://docs.microsoft.com/en-us/windows/win32/procthread/terminating-a-process