多線程服務器

當前的機器的紅利已經結束了 主頻已經達到了一個極限了

多線程有自身的優勢

API日益成熟，操作系統和標準庫都支持了多線程。

用多線程編程要在數據IO和計算找到平衡點。

一個是帶寬，一個是數據計算。

linux下fork ，window下的Creat_Process。

多線程編程，如果顯示的看到了multithread 就相當於是現代的goto。

可能帶來的問題是

死鎖

亂序

並發訪問數據造成的問題

低效率

C++11中的接口

高級接口

async future

低階接口

thread mutex 和操作系統相關了。

標準庫提供的

std::thread_hardware_concurrency()函數可以查看有多少個並發的線程.

多線程編程中的問題？

當多線程中有共享變量的時候應該對共享變量進行一次保護，這樣才可以。

只要不進行數據共享就可以了，這樣就可以在計算的時候進行並行計算，不用擔心會出現問題。

如果沒有必要 線程之間不要共享資源。

在構造thread的時候都做了寫哪些事情。thread的構造函數參數是沒有限制的。

數據傳輸的時候用const的方式進行數據的傳輸

線程之間保證數據的完整性

一步到位的方法，就是原子操作。 <atomic> 一旦包裹起來就是不可分割的了。

mutex 臨界區 比atomic更不容易出錯。

STL中提供了lock_guard提供了構建的時候加鎖，析構的時候自動解鎖的功能，

標準庫如何實現的？

std::lock()將所有的鎖全部鎖住，只有全部鎖住才可以往下走, 否則回等待，會按照特定的順序來進行鎖住。僅僅管鎖，解鎖不管

std::lock_guard<std::mutex> lockA(a.Mutex, std::adopt_lock) 默認的lock_guard 會在調用的時候，調用a.mutex函數，因為上面已經調用了，因此這裏就沒有必須調用了，這裏會傳入第二個參數，只需要在析構的時候進行釋放鎖就可以了。

thread的兩種死法。

一般在線程返回之前調用join函數，默認在析構的函數會自動釋放，那麽就不用調用join函數，

但是實際上的時候，thread的析構函數做了一些很奇怪的事情，在程序結束的時候不調用jion會出現什麽事情呢？程序會掛掉，析構函數調用的是直接終止，調用abort函數。為什麽這樣設計呢？

thread的行為有兩種，一種是由父線程來管理，一種是不管理，在運行完畢的時候自己死掉。

對於這兩種行為，類的析構和構造沒有辦法進行模擬，因此，就需要程序員指定是那種行為，到底是不管還是自己進行處理。自己生成的線程自己進行管理，管理方式就是join ，最好先判斷一下，joinable。另外一種是調用detach，就是自己結束聲明周期的。如果detach之後在進行join就是錯誤的了，會拋出一個異常。

thread之間的交互

事先開好線程，只有在滿足條件的情況下才會去做一些事情。

thread_yield 會將CPU釋放出來，會讓給其他的線程去跑。

正確的做法。

多線程為什麽會快一點，快在什麽地方？快是快在了執行的非順序性。

C++中的條件變量，和mutex一起使用，本身是一種通知的方法，

<condition_variable>頭文件中。

沒有名字的記錄