最近一個多月寫的帖子比較雜，導(dǎo)致本系列又好久沒更新了。結(jié)果又有網(wǎng)友在評論中催我了，搞得我有點囧。今天趕緊把多線程篇補(bǔ)上。上次聊操作系統(tǒng)的時候，由于和OS有關(guān)的話題比較瑣碎，雜七雜八說了一大堆。當(dāng)時一看篇幅有點長，就把多進(jìn)程和多線程的部分給留到后面了。

★編譯器
◇關(guān)于C運(yùn)行庫選項
先來說一個很基本的問題：關(guān)于C運(yùn)行庫（后面簡稱CRT：C Run-Time）的設(shè)置。本來不想聊這么低級的問題，但周圍有好幾個人都在這個地方吃過虧，所以還是講一下。
大部分C++編譯器都會自帶有CRT（可能還不止一個）。某些編譯器自帶的CRT可能會根據(jù)線程的支持分為單線程CRT和多線程CRT兩類。當(dāng)你要進(jìn)行多線程開發(fā)的時候，別忘了確保相關(guān)的C++工程項目使用的是多線程的CRT。否則會死得很難看。
尤其當(dāng)你使用Visual C++創(chuàng)建工程項目，更加要小心。如果新建的工程項目是不含MFC的（包括Console工程和Win32工程），那工程的默認(rèn)設(shè)置會是使用“單線程CRT”，如下圖所示：

◇關(guān)于優(yōu)化選項
“優(yōu)化選項”是另一個很關(guān)鍵的編譯器相關(guān)話題。有些編譯器提供號稱很牛X的優(yōu)化選項，但是某些優(yōu)化選項可能會有潛在的風(fēng)險。編譯器可能自作主張打亂執(zhí)行指令的順序，從而導(dǎo)致出乎意料的線程競態(tài)問題（Race Condition，詳細(xì)解釋看“這里”）。劉未鵬同學(xué)在“C++多線程內(nèi)存模型”里舉了幾個典型的例子，大伙兒可以去瞧一瞧。
建議只使用編譯器常規(guī)的速度優(yōu)化選項即可。其它那些花哨的優(yōu)化選項，增加的效果未必明顯，但是潛在的風(fēng)險不小。實在不值得冒險。
以GCC為例：建議用-O2選項即可（其實-O2是一堆選項的集合），沒必要冒險用-O3（除非你有很充足的理由）。除了-O2和-O3之外，GCC還有一大坨（估計有上百個）其它的優(yōu)化選項。如果你企圖用當(dāng)中的某個選項，一定要先把它的特性、可能的副作用都摸清楚，否則將來死都不知道怎么死的。

★線程庫的選擇
由于當(dāng)前的C++ 03標(biāo)準(zhǔn)幾乎沒有涉及線程相關(guān)的內(nèi)容（即使將來C++0x包含了線程的標(biāo)準(zhǔn)庫，編譯器廠商的支持在短期內(nèi)也未必全面），所以在未來很長的一段時間，跨平臺的多線程支持還是要依賴第三方庫。所以線程庫的選擇是大大滴重要。下面大致介紹一下幾個知名的跨平臺線程庫。
◇ACE
先說一下ACE這個歷史悠久的庫。如果你之前從未接觸過它，先看“這里”掃盲。從ACE的全稱（Adaptive CommunicationEnvironment）來看，它應(yīng)該是以“通訊”為主業(yè)。不過ACE對“多線程”這個副業(yè)的支持還是非常全面的，比如互斥鎖（ACE_Mutex）、條件變量（ACE_Condition）、信號量（ACE_Semaphore）、柵欄（ACE_Barrier）、原子操作（ACE_Atomic_Op）等等。對某些類型比如ACE_Mutex還細(xì)分為線程讀寫鎖（ACE_RW_Thread_Mutex）、線程遞歸鎖（ACE_Recursive_Thread_Mutex）等等。
除了支持很全面，ACE還有另一個很明顯的優(yōu)點，就是對各種操作系統(tǒng)平臺及其自帶的編譯器支持很好。包括一些老式的編譯器（比如VC6），它也能夠支持（此處所說的支持，不光是能編譯通過，而且要能穩(wěn)定運(yùn)行）。這個優(yōu)點對于跨平臺開發(fā)那是相當(dāng)相當(dāng)?shù)蚊黠@。
那缺點捏？由于ACE開工的年頭很早（大概是上世紀(jì)九十年代中期），那會兒很多C++的老特性都還沒出來（更別提新特性了），所以感覺ACE整個的風(fēng)格比較老氣，遠(yuǎn)不如boost那么時髦前衛(wèi)。
◇boost::thread
boost::thread正好和ACE形成鮮明對照。這玩意貌似從boost1.32版本開始引入，年頭比ACE短。不過得益于boost里一幫大牛的支持，發(fā)展還是蠻快的。到目前的boost1.38版本，也能夠支持許多特性了（不過似乎沒ACE多）。鑒于很多C++標(biāo)準(zhǔn)委員會的成員云集在boost社區(qū)中，隨著時間的推移，boost::thread終將成為C++線程的明日之星，前途無量?。?br>boost::thread的缺點就是支持的編譯器不夠多，尤其是一些老式編譯器（很多boost的子庫都有此問題，多半因為用了一些高級的模板語法）。這對于跨平臺而言一個比較明顯的問題。
◇wxWidgets和QT
wxWidgets和QT都是GUI界面庫，但是它們也都內(nèi)置和對線程的支持。wxWidgets線程的簡介可以看“這里”，關(guān)于QT線程的簡介可以看“這里”。這兩個庫對線程的支持差不多，都提供了諸如mutex、condition、semaphore等常用的機(jī)制。不過特性沒有ACE豐富。
◇如何權(quán)衡
對于開發(fā)GUI軟件并已經(jīng)用上了wxWidgets或者QT，那你可以直接用它們內(nèi)置的線程庫（前提是你只用到基本的線程功能）。由于它們內(nèi)置的線程庫，特性稍嫌單薄。萬一你需要某高級的線程功能，那得考慮替換成boost::thread或ACE。
至于boost::thread和ACE的取舍，主要得看軟件的需求了。如果你要支持的平臺挺多挺雜，那建議選用ACE，以免碰上編譯器不支持的問題。如果你只需要支持少數(shù)幾個主流的平臺（比如Windows、Linux、Mac），那建議用boost::thread。畢竟主流操作系統(tǒng)上的編譯器，對boost的支持還是蠻好的。

★編程上的注意事項
其實多線程開發(fā)，需要注意的地方挺多的，我只能大致列幾個印象比較深的注意事項。
◇關(guān)于volatile
說到多線程編程可能碰到的陷阱，那就不得不提到volatile關(guān)鍵字。如果你對它還不甚了解，先看“這里”掃盲一下。由于C++ 98和C++ 03標(biāo)準(zhǔn)都沒有定義多線程的內(nèi)存模型，而標(biāo)準(zhǔn)中也就volatile和線程沾點兒邊。結(jié)果導(dǎo)致C++社區(qū)中有相當(dāng)多的口水都集中在volatile身上（其中有不少C++大牛的口水）。有鑒于此，我這里就不再多啰嗦了。推薦幾個大牛的文章：Andrei Alexandrescu的文章“這里”、還有Hans Boehm的文章“這里”和“這里”。大伙兒自個兒去拜讀一下。
◇關(guān)于原子操作
有些同學(xué)光知道多個線程的競爭寫需要加鎖，卻不知道多個讀單個寫也需要保護(hù)。比如有某個整數(shù)int nCount = 0x01020304；在并發(fā)狀態(tài)下，一個寫線程去修改它的值nCount = 0x05060708；另一個讀線程去獲取該值。那么讀線程有沒有可能讀取到一個“壞”的（比如0x05060304）數(shù)據(jù)捏？
數(shù)據(jù)是否壞掉，取決于對nCount的讀和寫是否屬于原子操作。而這就依賴于很多硬件相關(guān)的因素了（包括CPU的類型、CPU的字長、內(nèi)存對齊的字節(jié)數(shù)等）。在某些情況下，確實可能出現(xiàn)數(shù)據(jù)壞掉。
由于我們討論的是跨平臺的開發(fā)，天曉得將來你的代碼會在啥樣的硬件環(huán)境下執(zhí)行。所以在處理類似問題的時候，還是要用第三方庫提供的原子操作類/函數(shù)（比如ACE的Atomic_Op）來確保安全。
◇關(guān)于對象的析構(gòu)
在之前的系列帖子“C++對象是怎么死的？”里面，已經(jīng)分別介紹了Win32平臺和Posix平臺下線程的非自然死亡問題。由于上述幾個跨平臺的線程庫底層還是要調(diào)用操作系統(tǒng)自帶的線程API，所以大伙兒還是要盡最大努力確保所有線程都能夠自然死亡。

今天的話題就聊到這里，下一次聊多進(jìn)程的話題。

http://program-think.blogspot.com/2009/04/cxx-cross-platform-develop-6-thread.html