C++霧中風景12:聊聊C++中的Mutex，以及拯救生產力的Boost

筆者近期在工作之中程式設計實現一個Cache結構的封裝，需要使用到C++之中的互斥量Mutex，於是花了一些時間進行了調研。（結果對C++標準庫很是絕望….）最終還是通過利用了Boost庫的shared_mutex解決了問題。借這個機會來聊聊在C++之中的多執行緒程式設計的一些“坑”。

1.C++多執行緒程式設計的困擾

C++從11開始在標準庫之中引入了執行緒庫來進行多執行緒程式設計，在之前的版本需要依託作業系統本身提供的執行緒庫來進行多執行緒的程式設計。（其實本身就是在標準庫之上對底層的作業系統多執行緒API統一進行了封裝，筆者本科時進行作業系統實驗是就是使用的pthread或來進行多執行緒程式設計的）
提供了統一的多執行緒固然是好事，但是標準庫給的支援實在是有限，具體實踐起來還是讓人挺困擾的：

• C++本身的STL並不是執行緒安全的。所以缺少了類似與Java併發庫所提供的一些高效能的執行緒安全的資料結構。(Doug Lea大神親自操刀完成的併發程式設計庫，讓JDK5成為Java之中里程碑式的版本)
• 如果沒有執行緒安全的資料結構，退而求其次，可以自己利用互斥量Mutex來實現。C++的標準庫支援如下的互斥量的實現：

互斥量	版本	作用
mutex	C++11	最基本的互斥量
timed_mutex	C++11	有超時機制的互斥量
recursive_mutex	C++11	可重入的互斥量
recursive_timed_mutex	C++11	結合 2,3 特點的互斥量
shared_timed_mutex	C++14	具有超時機制的可共享互斥量
shared_mutex	C++17	共享的互斥量

由上述表格可見，C++是從14之後的版本才正式支援共享互斥量，也就是實現讀寫鎖的結構。由於筆者的公司僅支援C++11的版本，所以就沒有辦法使用共享互斥量來實現讀寫鎖了。所以最終筆者只好求助與boost的庫，利用boost提供的讀寫鎖來完成了所需完成的工作。（所以對工具不足時可以考慮求助於boost庫，確實是解放生產力的大殺器，C++的標準庫實在太簡陋了~~）

2.標準庫互斥量的剖析

雖然吐槽了一小節，但並不影響繼續去學習C++標準庫給我們提供的工具………（但願公司能再推動升級一波C++的版本～～不過看起來是遙遙無期了）接下來筆者就要來帶領大家簡單剖析一些C++標準庫之中互斥量。

mutex

mutex的中文翻譯就是互斥量，很多人喜歡稱之其為鎖。其實不是太準確，因為多執行緒程式設計本質上應該通過互斥量之上加鎖，解鎖的操作，來實現多執行緒併發執行時對互斥資源執行緒安全的訪問。 我們來看看mutex類的使用方法：

long num = 0;
std::mutex num_mutex;

void numplus() {
    num_mutex.lock();
    for (long i = 0; i < 1000000; ++i) {
        num++;
    }
    num_mutex.unlock();
};

void numsub() {
    num_mutex.lock();
    for (long i = 0; i < 1000000; ++i) {
        num--;
    }
    num_mutex.unlock();
}

int main() {
    std::thread t1(numplus);
    std::thread t2(numsub);
    t1.join();
    t2.join();
    std::cout << num << std::endl;
}

呼叫執行緒從成功呼叫lock()或try_lock()開始，到unlock()為止佔有mutex物件。當存在某執行緒佔有mutex時，所有其他執行緒若呼叫lock則會阻塞，而呼叫try_lockh會得到false返回值。由上述程式碼可以看到，通過mutex加鎖的方式，來確保只有單一執行緒對臨界區的資源進行操作。
time_mutex與recursive_mutex的使用也是大同小異，兩者都是基於mutex來實現的。( 本質上是基於recursive_mutex實現的，mutex為recursive_mutex的特例)
time_mutex則是進行加鎖時可以設定阻塞的時間，若超過對應時長，則返回false。
recursive_mutex則讓單一執行緒可以多次對同一互斥量加鎖，同樣，解鎖時也需要釋放相同多次的鎖。
以上三種型別的互斥量都是包裝了作業系統底層的pthread_mutex_t:

在C++之中並不提倡我們直接對鎖進行操作，因為在lock之後忘記呼叫unlock很容易造成死鎖。而對臨界資源進行操作時，可能會丟擲異常，程式也有可能break，return 甚至 goto，這些情況都極容易導致unlock沒有被呼叫。所以C++之中通過RAII來解決這個問題，它提供了一系列的通用管理互斥量的類：

互斥量管理	版本	作用
lock_graud	C++11	基於作用域的互斥量管理
unique_lock	C++11	更加靈活的互斥量管理
shared_lock	C++14	共享互斥量的管理
scope_lock	C++17	多互斥量避免死鎖的管理

建立互斥量管理物件時，它試圖給給定mutex加鎖。當程式離開互斥量管理物件的作用域時，互斥量管理物件會析構並且並釋放mutex。所以我們則不需要擔心程式跳出或產生異常引發的死鎖了。
對於需要加鎖的程式碼段，可以通過{}括起來形成一個作用域。比如上述程式碼的栗子，可以進行如下改寫（推薦）：

long num = 0;
std::mutex num_mutex;

void numplus() {
    std::lock_guard<std::mutex> lock_guard(num_mutex);
    for (long i = 0; i < 1000000; ++i) {
        num++;
    }
};
void numsub() {
    std::lock_guard<std::mutex> lock_guard(num_mutex);
    for (long i = 0; i < 1000000; ++i) {
        num--;
    }
}

int main() {
    std::thread t1(numplus);
    std::thread t2(numsub);
    t1.join();
    t2.join();
    std::cout << num << std::endl;
}

由上述程式碼可以看到，程式碼結構變得更加明晰了，對於鎖的管理也交給了程式本身來進行處理，減少了出錯的可能。

shared_mutex

C++14的版本之後提供了共享互斥量，它的區別就在於提供更加細粒度的加鎖操作：lock_shared。lock_shared是一個獲取共享鎖的操作，而lock是一個獲取排他鎖的操作，通過這種方式更加細粒度化鎖的操作。shared_mutex也是基於作業系統底層的讀寫鎖pthread_rwlock_t的封裝：

這裡有個事情挺奇怪的，C++14提供了shared_timed_mutex 而在C++17提供了shared_mutex。其實shared_timed_mutex涵蓋了shard_mutex的功能。(不知道是不是因為名字被diss了，所以後續在C++17裡將shared_mutex**加了回來)。共享互斥量適用與讀多寫少的場景，舉個例子：

long num = 0;
std::shared_mutex num_mutex;

// 僅有單個執行緒可以寫num的值。
void numplus() {
    std::unique_lock<std::shared_mutex> lock_guard(num_mutex);
    for (long i = 0; i < 1000000; ++i) {
        num++;
    }
};

// 多個執行緒同時讀num的值。
long numprint() {
    std::shared_lock<std::shared_mutex> lock_guard(num_mutex);
    return num;
}

簡單來說：

• shared_lock是讀鎖。被鎖後仍允許其他執行緒執行同樣被shared_lock的程式碼
• unique_lock是寫鎖。被鎖後不允許其他執行緒執行被shared_lock或unique_lock的程式碼。它可以同時限制unique_lock與share_lock

不得不說，C++11沒有將共享互斥量整合進來，在很多讀多寫少的應用場合之中，標準庫本身提供的鎖機制顯得很雞肋，也從而導致了筆者最終只能求助與boost的解決方案。(其實也可以通過標準庫的mutex來實現一個讀寫鎖，這也是面試筆試之中常常問到的問題。不過太麻煩了，還得考慮和互斥量管理類相容什麼的，果斷放棄啊)

多鎖競爭

還剩下最後一個要寫的內容：scope_lock ，當我們要進行多個鎖管理時，很容易出現問題，由於加鎖的先後順序不同導致死鎖。(其實本來不想寫了，好累。這裡就簡單用例子做解釋吧，偷個懶～～)
如下栗子，加鎖順序不當導致死鎖：

std::mutex m1, m2;
// thread 1
{
  std::lock_guard<std::mutex> lock1(m1);
  std::lock_guard<std::mutex> lock2(m2);
}
// thread 2
{
  std::lock_guard<std::mutex> lock2(m2);
  std::lock_guard<std::mutex> lock1(m1);
}

而通過C++17提供的scope_lock就可以很簡單解決這個問題了：

std::mutex m1, m2;
// thread 1
{
  std::scope_lock lock(m1, m2);
}
// thread 2
{
  std::scope_lock lock(m1, m2);
}

好吧，媽媽再也不用擔心我會死鎖了～～

3.小結

算是簡單的梳理完C++標準庫之中的mutex了，也通過一些栗子比較完整的展現了使用方式。筆者上述關於標準庫的內容，在boost庫之中都能找到對應的實現，不過如果能夠使用標準庫，儘量還是不要引用boost了。（走投無路的時候記得求助boost，真香～～）希望大家在實踐之中可以很好的運用好這些C++互斥量來更好的確保執行緒安全了。後續筆者還會繼續深入的探討有關C++多執行緒的相關內容，歡迎大家多多指教。