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
閱讀更多 開心人開發世界 的文章
