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

原文鏈接：https://www.jianshu.com/p/92afa0114b5f

 

1.C++多線程編程的困擾

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

• 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:

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的封裝：

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);
}

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