为什么重新new两个线程线程号相同_C++ 20中的新线程（jthread）功能

C++ 20带来了许多很酷的新功能，其中一个我将在这里简单介绍一下：std::jthread。

这个的实现std::jthread基于已经存在的std::thread。它基本上是一个包装器，它为线程带来了两个新功能：默认情况下，它们可以协同中断并加入。在深入研究这两个术语之前，请注意该std::jthread对象包含std::thread一个成员，提供完全相同的公共函数，这些函数只是向下传递调用。这使我们可以将任何内容更改std::thread为std::jthread，确保它将像以前一样工作。

---

jthread是可协作中断的

该名称表明新的jthread是可中断的，即有一种方法可以阻止来自外部的线程。与C ++不同，在其他一些语言中，线程类具有abort()，stop()或interrupt()函数，而且大部分都不是用户可能期望的，即kill开关。有些人可能会认为我们没有这样的东西是如此糟糕，std::thread而且现在std::jthread我们终于拥有了它。但它可以协作中断，理解这一点的最好方法是看一下它的功能：request_stop()。这个名字的选择非常谨慎。考虑这个例子：

这里主线程创建一个新线程，它每秒都会重复执行某些操作(打印一行)。然后主线程继续执行5秒的作业，之后等待另一个线程完成。但它不会完成，它将继续运行，主线程将继续等待。

我们刚刚改变了thread，jthread并且，正如所承诺的，没有任何新的事情发生，它表现得像以前一样。现在让我们使用该函数在main完成后停止线程。

这编译并且有效，但它不会立即停止执行该线程，也不会停止执行。这没关系：注意，它说请求停止，而不是坚持或强制。所以我们(从线程外部)只能请求停止，并且该线程本身具有最终发言权。这就是它可以协作中断的原因。

这终于奏效了。当然，我们可以通过原子布尔来实现这一点，这是一个更广泛和值得信赖的版本。但问题仍然存在：我们为什么不在jthread上使用killswitch，特别是当其他语言(其他语言)这样做时？答案是：其他人没有真正拥有它，你也不想拥有它。

为什么一个killswitch是个坏主意？

假设您已经从主线程创建了一个工作线程，并且在某些时候，您想要杀死它(工作者)。想象一下，有一个杀戮开关，一个功能：stop()

• 从线程调度程序中删除worker ****(PAUSE)
• 释放用作堆栈的内存工作者，而不调用析构函数(WIPE OUT)

这几乎总能保证死锁或内存泄漏或两者兼而有之。所以这绝对是一个坏主意，无论如何都需要进行一些清理。其他语言主要做的是向工人抛出一个例外，它负责捕捉和清理你的肩膀。让我们不要忘记，这std::thread只是一个封面，而且大部分都是一个pthread底层。它也有几分相似，我们总是能获得native_handle()来自std::thread与它合作。但它更复杂。

是的，这很复杂。不要费心阅读。

但这个想法是一样的：在使用“killswitch”之前，你应该自己处理清理工作。

现在，假设您正在发明一种支持多线程并具有Thread类的新语言。您是否会给它一个stop功能，这个功能并不是名称所暗示的，并且存在滥用的高风险？我不会，因此用户被迫以正确的方式找到方法。

---

jthread 的 join

第二个特征jthread是帮助我们解决std::thread以前导致的困境：join或detach*。现在jthread来承担一些责任。它的析构函数简单地实现为：

这正是我们在上面的示例中所做的，因此我们可以删除那里的最后两行。

但是，为什么join被选为一个jthread默认结束了吗？首先，它与detach相比非常安全，而且在大多数情况下，这是你真正需要的。

为了更好地理解detach的危险以及为什么加入应始终是您的选择，请检查：“让我为您分离这些线程”。

---

尽管它附带了C ++ 20，但它std::jthread并没有使用任何新的语言功能，所以它现在几乎可用。这是由提出它的人Nicolai Josuttis 实施的。您可以使用此存储库中的两个头文件来完全访问此新功能：“ sources /”中的 “ jthread.hpp”和“ *stop_token.hpp *”。

翻译自：https://medium.com/@vgasparyan1995/a-new-thread-in-c-20-jthread-ebd121ae8906