學習c++多線程編程主要用pthread還是c++11中的thread類？

01-05

C++11 thread該做的東西沒做，不該做的東西反倒寫了一大堆。

1、 C++11 thread庫里的future居然沒不能做chain，也就是說你創建了一個future之後，只能用blocking的方式去等它的值算出來，要知道連node這種東西都能串聯future了啊……

2、 C++11 thread庫里居然沒有shared_mutex，這種東西居然也能拖3年？

3、 C++11 thread庫居然沒有executor之類的thread pool，類比一下，有多少Java程序會去用光桿thread的？

4、在Linux/GCC/libstdc++下，C++11 thread庫居然強制動態連接pthread，如果你編譯連接的時候忘了-pthread參數，一直要到運行的時候才會報錯，得多腦殘的人才會把這個庫做成這樣？

5、 thread的一些基本屬性比如優先順序、CPU affinity之類的東西居然都沒進標準，標準委員會留這麼大個空白是打算照顧8088上的DOS版么？

6、至於std::ref/cref之類的東西我就不吐槽了，畢竟這是C++語言的鍋，輪不到thread庫來背。

相比而言我覺得libdispatch/GCD才是設計對了的thread庫，給我個C++11 thread那麼裸而且搓的包裝我幹嘛不直接去用pthread。

如果只在 Linux 下編程，那麼 C++11 的 thread 的附加值幾乎為零（我認為它過度設計了，同時損失了一些功能），你自己把 Pthreads 封裝成一個簡單好用的線程庫只需要兩三百行代碼，用十幾個 pthreads 函數實現 4 個 class：thread、mutex、lock_guard、condvar，而且 RAII 的好處也享受到了。

現在C++開發是不是都遵守C++11標準,Linux下的多線程編程是優先考慮C++11的線程庫,還是用系統線程API封裝？ - 陳碩的回答

如果你用C++11的線程庫，那麼基本可以避免跨平台的問題，但是會對編譯器版本有要求。現在還有不少人再用CentOS 4，GCC可能只是4.3、4.4的樣子。

於是你還有一個選擇：自己搞定Windows API、pthread，然後自己寫一套線程包裝。

C++的thread是經過良好設計並且跨平台的線程表示方式，然而pthread是「粗獷、直接、暴力」的類UNIX平台線程表示方式，如你在C++11的thread你可以使用lock_guard等來實現RAII方式的lock管理，而pthread則很難。

推薦C++並發編程實踐這本書，是Boost線程和STL線程提案作者所著，寫的很好。

這個專欄寫得不錯：專欄：C++並發實戰(C++11)

新學的話，用 C++11 std::thread，委員會那幫老頭子不是傻的。

優先標準庫，標準庫有的，就不要用第三方的了。

pthread就是太麻煩了，按照C++引入thread類的思想無非是叫你把心思放在線程邏輯上，而不是糾結於語法本身。

我還是喜歡pthread，簡單直接粗暴

如果你想用pthread，最好也別裸著用。自己包裝一下唄。

強烈推薦 @陳碩老師的那本《linux多線程伺服器編程》，學著自己封裝一下 Mutex，LockGuard，ConditionVar，BlockQueue，ThreadPool

到頭來，你還是得兩樣都學。

用哪個的話，聽leader的

沒有人提ace啊。。

請問C++11如何優雅的結束一個線程。。。委員會這次還真是給出了個雞肋，估計之後的版本會好一些。不過長久看用C++11確實是可移植性和方便的。當你發現C++11 thread雞肋的時候，你可以用native_handler獲得pthread的handler。這樣就好用了，等以後C++更新了再改吧^_^

當然是用c++11的線程庫，這還有什麼疑問，使用簡單好理解，又跨平台

寫跨平台代碼用c++11的thread，另外參數傳遞挺爽的，不用專門搞個數據結構傳參數。

最後你都得學！

因為這些玩意既然都支持，那麼就說明有東西在用它們。

既然有東西在用，那麼早晚你都要去維護的。

所以，儘管麻煩，儘管噁心，你仍然必須接受這個不完美的現實。

pthread是最好的，如果要用並發容器可以用用那些C++封裝的，如果要考慮跨平台的話，用宏把位置都留出來，Linux，windows，安卓，iOS，Mac等，一定要懂得封裝的東西雖然方便但是在靈活使用已經性能調優方面會受限

看跨平台的需求了。線程這種既簡單又底層的東西，我覺得如果沒跨平台需求的話，直接用系統api或crt里的函數(推薦)就行了，因為太簡單了…