互斥鎖及條件變量的使用

本文主要分為三個(gè)部分：

• 第一部分簡(jiǎn)要介紹線程的概念及其使用
• 第二部分主要介紹互斥鎖及條件變量的使用（重點(diǎn)探討pthread_cond_wait）
• 第三部分參考運(yùn)行IBM的多線程工作代碼作為應(yīng)用。

一、線程簡(jiǎn)介及使用

正確的使用線程是一個(gè)優(yōu)秀程序員必備的素質(zhì)。線程類似于進(jìn)程，單處理器系統(tǒng)中內(nèi)核通過時(shí)間片輪轉(zhuǎn)模擬線程的并發(fā)運(yùn)行。那么，對(duì)于大多數(shù)合作任務(wù)，為什么多線程比多進(jìn)程優(yōu)越呢？

這是因?yàn)?，線程共享相同的內(nèi)存空間，不同線程之間可以共享內(nèi)存中的全局變量。使用fork()寫過子進(jìn)程的同學(xué)都會(huì)意識(shí)到多線程的重要性。為什么呢？雖然fork()允許創(chuàng)建多個(gè)進(jìn)程，但它會(huì)帶來進(jìn)程之間的通信問題：各個(gè)進(jìn)程都有各自獨(dú)立的內(nèi)存空間，需要使用某種IPC（進(jìn)程間通信）進(jìn)行通信，但它們都遇到兩個(gè)重要障礙：

• 強(qiáng)加了某種形式的額外內(nèi)核開銷，從而降低性能。
• 對(duì)于大多數(shù)情形，IPC 不是對(duì)于代碼的“自然”擴(kuò)展。通常極大地增加了程序的復(fù)雜性。

POSIX多線程不必使用諸如管道、套接字等長(zhǎng)距離通信，這些通信方式開銷大、復(fù)雜，由于所有線程都駐留在同一內(nèi)存空間，因此只需要考慮同步問題即可。

線程是快捷的

與標(biāo)準(zhǔn)fork()相比，線程開銷較少。無需單獨(dú)復(fù)制進(jìn)程的內(nèi)存空間或文件描述符等等，大大節(jié)省CPU時(shí)間，創(chuàng)建速度比進(jìn)程創(chuàng)建快到10-100倍，那么可以大量使用線程而無需擔(dān)心CPU或內(nèi)存不足。

同時(shí)，線程能夠充分利用多處理器的CPU，特定類型線程（CPU密集型）的性能隨處理器數(shù)目線性提高。如果編寫的是CPU密集型程序，則絕對(duì)要在代碼中使用多線程，無需使用繁瑣的IPC及其他復(fù)雜通信機(jī)制。

線程是可移植的

fork()的底層系統(tǒng)調(diào)用是__clone()，新的子進(jìn)程根據(jù)該系統(tǒng)調(diào)用的參數(shù)有選擇的共享父進(jìn)程的執(zhí)行環(huán)境（內(nèi)存空間，文件描述符等），但__clone()也有不好的一面，__clone()是特定于Linux平臺(tái)的，不使用于實(shí)現(xiàn)可移植程序。而Linux的POSIX線程是可移植的，代碼運(yùn)行于Solaris、FreeBSD、Linux 和其它平臺(tái)。

代碼：

該程序非常簡(jiǎn)單，但是也有我們需要學(xué)習(xí)的地方：

1）線程id的類型為pthread_t，可以認(rèn)為它是一種句柄，后續(xù)的使用都是利用它完成的

2）線程創(chuàng)建函數(shù)需要依次指定線程屬性、回調(diào)函數(shù)以及線程傳參（簡(jiǎn)單變量或結(jié)構(gòu)體），返回值考慮

3）線程創(chuàng)建后兩個(gè)線程如何運(yùn)行，子線程結(jié)束后如何處理

對(duì)于第三個(gè)問題：

子線程創(chuàng)建后，POSIX線程標(biāo)準(zhǔn)將它們視為相同等級(jí)的線程，子線程開始執(zhí)行的同時(shí)，主線程繼續(xù)向下執(zhí)行（其實(shí)這里已經(jīng)沒有像進(jìn)程那樣的父子概念了，這里只是為了更好的區(qū)分），二者并沒有一定的先后順序，CPU時(shí)間片的分配取決于內(nèi)核和線程庫。

子線程結(jié)束時(shí)的處理，當(dāng)子線程的默認(rèn)joinable屬性時(shí)，由主線程對(duì)其進(jìn)行清理；當(dāng)子線程為detached屬性時(shí)，由系統(tǒng)進(jìn)程對(duì)其清理。如果未對(duì)線程進(jìn)行正確清理，最終會(huì)導(dǎo)致 pthread_create() 調(diào)用失敗。

代碼2：

輸出：

非常意外吧，主線程和子線程各自對(duì)myglobal進(jìn)行20次加1操作，程序結(jié)束時(shí)myglobal應(yīng)當(dāng)為40，然而myglobal的輸出為21，這里面肯定有問題。究竟是為什么呢？

核心原因就是：對(duì)全局變量的修改并不是原子操作，假設(shè)子線程讀取全局變量到寄存器，寄存器內(nèi)部完成加1，之后即將重新賦值給全局變量前的時(shí)刻。主線程開始讀取全局變量完成操作，那么此時(shí)就覆蓋了子線程的這一環(huán)節(jié)操作，該操作也就成了無效操作。

解決這一問題就需要互斥操作了，見第二部分。

二、互斥鎖及條件變量的使用

通過互斥鎖 （mutex）完成對(duì)臨界資源的鎖操作，能夠保證各個(gè)線程對(duì)其的唯一訪問。

互斥對(duì)象的工作原理：

如果線程 a 試圖鎖定一個(gè)互斥對(duì)象，而此時(shí)線程 b 已鎖定了同一個(gè)互斥對(duì)象時(shí)，線程 a 就將進(jìn)入睡眠狀態(tài)。一旦線程 b 釋放了互斥對(duì)象（通過 pthread_mutex_unlock() 調(diào)用），線程 a 就能夠鎖定這個(gè)互斥對(duì)象（換句話說，線程 a 就將從 pthread_mutex_lock() 函數(shù)調(diào)用中返回，同時(shí)互斥對(duì)象被鎖定）。同樣地，其他對(duì)已鎖定的互斥對(duì)象上調(diào)用 pthread_mutex_lock() 的所有線程都將進(jìn)入睡眠狀態(tài)，這些睡眠的線程將“排隊(duì)”訪問這個(gè)互斥對(duì)象。

看到了嗎？其他試圖訪問已被鎖定互斥對(duì)象的線程都會(huì)排隊(duì)睡眠的:)

代碼修改：

此時(shí)pthread_mutex_lock() 和 pthread_mutex_unlock() 函數(shù)調(diào)用，如同“在施工中”標(biāo)志一樣，將正在修改和讀取的某一特定共享數(shù)據(jù)包圍起來。其他線程訪問時(shí)繼續(xù)睡眠，直到該線程完成對(duì)其的操作。

等待條件之POSIX條件變量

互斥對(duì)象是線程程序必需的工具，但它們并非萬能的。例如，如果線程正在等待共享數(shù)據(jù)內(nèi)某個(gè)條件出現(xiàn)，那會(huì)發(fā)生什么呢？

1）使用忙查詢的方法非常浪費(fèi)時(shí)間和資源，效率非常低。代碼可以反復(fù)對(duì)互斥對(duì)象鎖定和解鎖，以檢查值的任何變化。同時(shí)，還要快速將互斥對(duì)象解鎖，以便其它線程能夠進(jìn)行任何必需的更改。這是一種非?？膳碌姆椒?，因?yàn)榫€程需要在合理的時(shí)間范圍內(nèi)頻繁地循環(huán)檢測(cè)變化。

2）解決這個(gè)問題的最好方法是使用pthread_cond_wait() 調(diào)用來等待特殊條件發(fā)生。當(dāng)線程在等待滿足某些條件時(shí)使線程進(jìn)入睡眠狀態(tài)。一旦條件滿足，還需要一種方法以喚醒因等待滿足特定條件而睡眠的線程。如果能夠做到這一點(diǎn)，線程代碼將是非常高效的，并且不會(huì)占用寶貴的互斥對(duì)象鎖。這正是 POSIX 條件變量能做的事！

了解 pthread_cond_wait() 的作用非常重要 – 它是 POSIX 線程信號(hào)發(fā)送系統(tǒng)的核心，也是最難以理解的部分。

條件變量的概念

通常在程序里，我們使用條件變量來表示等待”某一條件”的發(fā)生。雖然名叫”條件變量”，但是它本身并不保存條件狀態(tài)，本質(zhì)上條件變量?jī)H僅是一種通訊機(jī)制：當(dāng)有一個(gè)線程在等待(pthread_cond_wait)某一條件變量的時(shí)候，會(huì)將當(dāng)前的線程掛起，直到另外的線程發(fā)送信號(hào)(pthread_cond_signal)通知其解除阻塞狀態(tài)。

由于要用額外的共享變量保存條件狀態(tài)(這個(gè)變量可以是任何類型比如bool)，由于這個(gè)變量會(huì)同時(shí)被不同的線程訪問，因此需要一個(gè)額外的mutex保護(hù)它。

《Linux系統(tǒng)編程手冊(cè)》也有這個(gè)問題的介紹：

A condition variable is always used in conjunction with a mutex. The mutex provides mutual exclusion for accessing the shared variable, while the condition variable is used to signal changes in the variable’s state.

條件變量總是結(jié)合mutex使用，條件變量就共享變量的狀態(tài)改變發(fā)出通知，mutex就是用來保護(hù)這個(gè)共享變量的。

cpp官網(wǎng)描述

pthread_cond_wait實(shí)現(xiàn)步驟

首先，我們使用條件變量的接口實(shí)現(xiàn)一個(gè)簡(jiǎn)單的生產(chǎn)者-消費(fèi)者模型，avail就是保存條件狀態(tài)的共享變量，它對(duì)生產(chǎn)者線程、消費(fèi)者線程均可見。不考慮錯(cuò)誤處理，先看生產(chǎn)者實(shí)現(xiàn)：

因?yàn)閍vail對(duì)兩個(gè)線程都可見，因此對(duì)其修改均應(yīng)該在mutex的保護(hù)之下，再來看消費(fèi)者線程實(shí)現(xiàn)：

當(dāng)”avail==0”時(shí)，消費(fèi)者線程會(huì)阻塞在pthread_cond_wait()函數(shù)上。如果pthread_cond_wait()僅需要一個(gè)pthread_cond_t參數(shù)的話，此時(shí)mutex已經(jīng)被鎖，要是不先將mutex變量解鎖，那么其他線程(如生產(chǎn)者線程)永遠(yuǎn)無法訪問avail變量，也就無法繼續(xù)生產(chǎn)，消費(fèi)者線程會(huì)一直阻塞下去。

因此pthread_cond_wait()對(duì)mutex解鎖，然后進(jìn)入睡眠狀態(tài)，等待cond以接收POSIX 線程“信號(hào)”。一旦接收到“信號(hào)”（加引號(hào)是因?yàn)槲覀儾⒉皇窃谟懻搨鹘y(tǒng)的 UNIX 信號(hào)，而是來自pthread_cond_signal() 或 pthread_cond_broadcast() 調(diào)用的信號(hào)），它就會(huì)蘇醒。但 pthread_cond_wait() 沒有立即返回 – 它還要做一件事：重新鎖定 mutex。

理解后提問：調(diào)用 pthread_cond_wait() 之 前，互斥對(duì)象必須處于什么狀態(tài)？pthread_cond_wait() 調(diào)用返回之后，互斥對(duì)象處于什么狀態(tài)？這兩個(gè)問題的答案都是“鎖定”。

綜上，pthread_cond_wait()函數(shù)大致會(huì)分為3個(gè)部分：

1.解鎖互斥量mutex 2.阻塞調(diào)用線程，直到當(dāng)前的條件變量收到通知 3.重新鎖定互斥量mutex

其中1和2是原子操作，也就是說在pthread_cond_wait()調(diào)用線程陷入阻塞之前其他的線程無法獲取當(dāng)前的mutex，也就不能就該條件變量發(fā)出通知。

虛假喚醒

前面判斷條件狀態(tài)的時(shí)候avail > 0放在了while循環(huán)中，而不是if中，這是因?yàn)閜thread_cond_wait()阻塞在條件變量上的時(shí)候，即使其他的線程沒有就該條件變量發(fā)出通知(pthread_cond_signal()/pthread_cond_broadcast())，條件變量也有可能會(huì)自己醒來(pthread_cond_wait()函數(shù)返回)，因此需要重新檢查一下共享變量上的條件成不成立，確保條件變量是真的收到了通知，否則繼續(xù)阻塞等待。關(guān)于虛假喚醒的相關(guān)介紹，可以戳這里查看維基百科下面的幾個(gè)引用：https://en.wikipedia.org/wiki/Spurious_wakeup。

三、工作隊(duì)列的實(shí)現(xiàn)

這里摘抄IBM第三部分應(yīng)用實(shí)現(xiàn)代碼：

在這個(gè)方案中，我們創(chuàng)建了許多工作程序線程。每個(gè)線程都會(huì)檢查 wq（“工作隊(duì)列”），查看是否有需要完成的工作。如果有需要完成的工作，那么線程將從隊(duì)列中除去一個(gè)節(jié)點(diǎn)，執(zhí)行這些特定工作，然后等待新的工作到達(dá)。

與此同時(shí)，主線程負(fù)責(zé)創(chuàng)建這些工作程序線程、將工作添加到隊(duì)列，然后在它退出時(shí)收集所有工作程序線程。您將會(huì)遇到許多 C 代碼，好好準(zhǔn)備吧！

隊(duì)列

需要隊(duì)列是出于兩個(gè)原因。首先，需要隊(duì)列來保存工作作業(yè)。還需要可用于跟蹤已終止線程的數(shù)據(jù)結(jié)構(gòu)。還記得前幾篇文章（請(qǐng)參閱本文結(jié)尾處的 參考資料）中，我曾提到過需要使用帶有特定進(jìn)程標(biāo)識(shí)的 pthread_join 嗎？使用“清除隊(duì)列”（稱作 “cq”）可以解決無法等待 任何已終止線程的問題（稍后將詳細(xì)討論這個(gè)問題）。以下是標(biāo)準(zhǔn)隊(duì)列代碼。將此代碼保存到文件 queue.h 和 queue.c：

queue.h

queue.c

data_control 代碼

我編寫的并不是線程安全的隊(duì)列例程，事實(shí)上我創(chuàng)建了一個(gè)“數(shù)據(jù)包裝”或“控制”結(jié)構(gòu)，它可以是任何線程支持的數(shù)據(jù)結(jié)構(gòu)?？匆幌?control.h：

現(xiàn)在您看到了 data_control 結(jié)構(gòu)定義，以下是它的視覺表示：

所使用的 data_control 結(jié)構(gòu)

圖像中的鎖代表互斥對(duì)象，它允許對(duì)數(shù)據(jù)結(jié)構(gòu)進(jìn)行互斥訪問。黃色的星代表?xiàng)l件變量，它可以睡眠，直到所討論的數(shù)據(jù)結(jié)構(gòu)改變?yōu)橹?。on/off 開關(guān)表示整數(shù) “active”，它告訴線程此數(shù)據(jù)是否是活動(dòng)的。在代碼中，我使用整數(shù) active 作為標(biāo)志，告訴工作隊(duì)列何時(shí)應(yīng)該關(guān)閉。以下是 control.c：

control.c

調(diào)試時(shí)間

在開始調(diào)試之前，還需要一個(gè)文件。以下是 dbug.h：

此代碼用于處理工作組代碼中的不可糾正錯(cuò)誤。

工作組代碼說到工作組代碼，以下就是：workcrew.c

代碼初排

現(xiàn)在來快速初排代碼。定義的第一個(gè)結(jié)構(gòu)稱作 “wq”，它包含了 data_control 和隊(duì)列頭。data_control 結(jié)構(gòu)用于仲裁對(duì)整個(gè)隊(duì)列的訪問，包括隊(duì)列中的節(jié)點(diǎn)。下一步工作是定義實(shí)際的工作節(jié)點(diǎn)。要使代碼符合本文中的示例，此處所包含的都是作業(yè)號(hào)。

接著，創(chuàng)建清除隊(duì)列。注釋說明了它的工作方式。好，現(xiàn)在讓我們跳過 threadfunc()、join_threads()、create_threads() 和 initialize_structs() 調(diào)用，直接跳到 main()。所做的第一件事就是初始化結(jié)構(gòu) – 這包括初始化 data_controls 和隊(duì)列，以及激活工作隊(duì)列。

有關(guān)清除的注意事項(xiàng)

現(xiàn)在初始化線程。如果看一下 create_threads() 調(diào)用，似乎一切正常 – 除了一件事。請(qǐng)注意，我們正在分配清除節(jié)點(diǎn)，以及初始化它的線程號(hào)和 TID 組件。我們還將清除節(jié)點(diǎn)作為初始自變量傳遞給每一個(gè)新的工作程序線程。為什么這樣做？

因?yàn)楫?dāng)某個(gè)工作程序線程退出時(shí)，它會(huì)將其清除節(jié)點(diǎn)連接到清除隊(duì)列，然后終止。那時(shí)，主線程會(huì)在清除隊(duì)列中檢測(cè)到這個(gè)節(jié)點(diǎn)（利用條件變量），并將這個(gè)節(jié)點(diǎn)移出隊(duì)列。因?yàn)?TID（線程標(biāo)識(shí)）存儲(chǔ)在清除節(jié)點(diǎn)中，所以主線程可以確切知道哪個(gè)線程已終止了。然后，主線程將調(diào)用 pthread_join(tid)，并聯(lián)接適當(dāng)?shù)墓ぷ鞒绦蚓€程。如果沒有做記錄，那么主線程就需要按任意順序聯(lián)接工作程序線程，可能是按它們的創(chuàng)建順序。由于線程不一定按此順序終止，那么主線程可能會(huì)在已經(jīng)聯(lián)接了十個(gè)線程時(shí)，等待聯(lián)接另一個(gè)線程。您能理解這種設(shè)計(jì)決策是如何使關(guān)閉代碼加速的嗎（尤其在使用幾百個(gè)工作程序線程的情況下）？

創(chuàng)建工作

我們已啟動(dòng)了工作程序線程（它們已經(jīng)完成了執(zhí)行 threadfunc()，稍后將討論此函數(shù)），現(xiàn)在主線程開始將工作節(jié)點(diǎn)插入工作隊(duì)列。首先，它鎖定 wq 的控制互斥對(duì)象，然后分配 16000 個(gè)工作包，將它們逐個(gè)插入隊(duì)列。完成之后，將調(diào)用 pthread_cond_broadcast()，于是所有正在睡眠的線程會(huì)被喚醒，并開始執(zhí)行工作。此時(shí)，主線程將睡眠兩秒鐘，然后釋放工作隊(duì)列，并通知工作程序線程終止活動(dòng)。接著，主線程會(huì)調(diào)用 join_threads() 函數(shù)來清除所有工作程序線程。

threadfunc()

現(xiàn)在來討論 threadfunc()，這是所有工作程序線程都要執(zhí)行的代碼。當(dāng)工作程序線程啟動(dòng)時(shí)，它會(huì)立即鎖定工作隊(duì)列互斥對(duì)象，獲取一個(gè)工作節(jié)點(diǎn)（如果有的話），然后對(duì)它進(jìn)行處理。如果沒有工作，則調(diào)用 pthread_cond_wait()。您會(huì)注意到這個(gè)調(diào)用在一個(gè)非常緊湊的 while() 循環(huán)中，這是非常重要的。當(dāng)從 pthread_cond_wait() 調(diào)用中蘇醒時(shí)，決不能認(rèn)為條件肯定發(fā)生了 – 它 可能發(fā)生了，也可能沒有發(fā)生。如果發(fā)生了這種情況，即錯(cuò)誤地喚醒了線程，而列表是空的，那么 while 循環(huán)將再次調(diào)用 pthread_cond_wait()。

如果有一個(gè)工作節(jié)點(diǎn)，那么我們只打印它的作業(yè)號(hào)，釋放它并退出。然而，實(shí)際代碼會(huì)執(zhí)行一些更實(shí)質(zhì)性的操作。在 while() 循環(huán)結(jié)尾，我們鎖定了互斥對(duì)象，以便檢查 active 變量，以及在循環(huán)頂部檢查新的工作節(jié)點(diǎn)。如果執(zhí)行完此代碼，就會(huì)發(fā)現(xiàn)如果 wq.control.active 是 0，while 循環(huán)就會(huì)終止，并會(huì)執(zhí)行 threadfunc() 結(jié)尾處的清除代碼。

工作程序線程的清除代碼部件非常有趣。首先，由于 pthread_cond_wait() 返回了鎖定的互斥對(duì)象，它會(huì)對(duì) work_queue 解鎖。然后，它鎖定清除隊(duì)列，添加清除代碼（包含了 TID，主線程將使用此 TID 來調(diào)用 pthread_join()），然后再對(duì)清除隊(duì)列解鎖。此后，它發(fā)信號(hào)給所有 cq 等待者 (pthread_cond_signal(&cq.control.cond))，于是主線程就知道有一個(gè)待處理的新節(jié)點(diǎn)。我們不使用 pthread_cond_broadcast()，因?yàn)闆]有這個(gè)必要 – 只有一個(gè)線程（主線程）在等待清除隊(duì)列中的新節(jié)點(diǎn)。當(dāng)它調(diào)用 join_threads() 時(shí)，工作程序線程將打印關(guān)閉消息，然后終止，等待主線程發(fā)出的 pthread_join() 調(diào)用。

join_threads()

如果要查看關(guān)于如何使用條件變量的簡(jiǎn)單示例，請(qǐng)參考 join_threads() 函數(shù)。如果還有工作程序線程，join_threads() 會(huì)一直執(zhí)行，等待清除隊(duì)列中新的清除節(jié)點(diǎn)。如果有新節(jié)點(diǎn)，我們會(huì)將此節(jié)點(diǎn)移出隊(duì)列、對(duì)清除隊(duì)列解鎖（從而使工作程序可以添加清除節(jié)點(diǎn)）、聯(lián)接新的工作程序線程（使用存儲(chǔ)在清除節(jié)點(diǎn)中的 TID）、釋放清除節(jié)點(diǎn)、減少“現(xiàn)有”線程的數(shù)量，然后繼續(xù)。