1. 從單核到多核為什么C11的同步原語(yǔ)是必學(xué)項(xiàng)十年前我還在用pthread_mutex_t和pthread_cond_t手動(dòng)管理線程每次寫多線程代碼都像在走鋼絲一個(gè)不小心就是死鎖或者數(shù)據(jù)競(jìng)爭(zhēng)。那時(shí)候的C標(biāo)準(zhǔn)對(duì)多線程的支持幾乎為零我們得依賴操作系統(tǒng)提供的API代碼可移植性差心智負(fù)擔(dān)極重。直到C11標(biāo)準(zhǔn)發(fā)布將多線程支持納入了語(yǔ)言標(biāo)準(zhǔn)庫(kù)這絕對(duì)是一個(gè)里程碑式的事件。它帶來(lái)的不僅僅是一套新的頭文件thread,mutex,condition_variable等更是一種思維范式的轉(zhuǎn)變多線程編程從“系統(tǒng)級(jí)技巧”變成了“語(yǔ)言級(jí)設(shè)施”。今天無(wú)論是處理高并發(fā)網(wǎng)絡(luò)請(qǐng)求、加速科學(xué)計(jì)算還是開發(fā)響應(yīng)式的桌面應(yīng)用多線程都是繞不開的核心技術(shù)。而多線程編程的靈魂就在于“同步”。沒有同步的多線程就像沒有交通燈的十字路口數(shù)據(jù)這輛車隨時(shí)可能被撞得面目全非。C11為我們提供了一套豐富的同步工具箱從最基礎(chǔ)的互斥鎖到更高級(jí)的條件變量、原子操作再到面向未來(lái)的異步任務(wù)模型。理解它們不僅僅是記住幾個(gè)API更是要理解它們各自解決的是什么問題以及背后的設(shè)計(jì)哲學(xué)。這篇文章我想從一個(gè)實(shí)踐者的角度帶你重新梳理C11中的這些核心同步機(jī)制。我不會(huì)只給你干巴巴的接口說(shuō)明而是會(huì)結(jié)合我這些年踩過(guò)的坑、調(diào)過(guò)的bug告訴你什么場(chǎng)景下該用什么工具以及如何避免那些教科書里不會(huì)寫的“坑”。無(wú)論你是正在準(zhǔn)備多線程面試還是在實(shí)際項(xiàng)目中遇到了并發(fā)難題希望這些經(jīng)驗(yàn)?zāi)芙o你一些實(shí)實(shí)在在的幫助。2. 基石互斥鎖Mutex的深度使用與避坑指南互斥鎖是多線程同步最直觀、最基礎(chǔ)的武器。它的核心思想很簡(jiǎn)單給一段代碼臨界區(qū)上一把鎖同一時(shí)間只允許一個(gè)線程持有這把鎖并執(zhí)行這段代碼。C11提供了好幾種互斥鎖用對(duì)了事半功倍用錯(cuò)了就是災(zāi)難現(xiàn)場(chǎng)。2.1 四種標(biāo)準(zhǔn)互斥鎖的選型邏輯很多人一上來(lái)就用std::mutex這沒錯(cuò)但它不是萬(wàn)能的。C11標(biāo)準(zhǔn)庫(kù)實(shí)際上提供了四種互斥鎖它們的適用場(chǎng)景截然不同。std::mutex 標(biāo)準(zhǔn)互斥鎖這是最常用、最基礎(chǔ)的鎖。它只提供最基本的lock()、try_lock()和unlock()操作。它的使用原則是簡(jiǎn)單場(chǎng)景快速上手。當(dāng)你只是需要保護(hù)一小段共享數(shù)據(jù)的讀寫且沒有遞歸上鎖、超時(shí)等復(fù)雜需求時(shí)就用它。std::mutex g_mutex; int shared_data 0; void increment() { std::lock_guardstd::mutex lock(g_mutex); // 核心使用RAII包裝器 shared_data; // 臨界區(qū) } // lock_guard析構(gòu)自動(dòng)解鎖這里立刻引出一個(gè)黃金法則永遠(yuǎn)不要直接調(diào)用mutex.lock()和unlock()。一定要使用RAII資源獲取即初始化包裝器如std::lock_guard或std::unique_lock。這能確保即使在臨界區(qū)代碼拋出異常的情況下鎖也能被正確釋放避免死鎖。這是我早期用原生API寫崩好幾個(gè)服務(wù)后得到的血淚教訓(xùn)。std::recursive_mutex 遞歸互斥鎖這是給那些“可能自己鎖自己”的函數(shù)準(zhǔn)備的。想象一下一個(gè)類的公有方法A()需要加鎖而它的另一個(gè)公有方法B()內(nèi)部又調(diào)用了A()。如果你用普通的std::mutex線程在B()中第一次加鎖成功進(jìn)入A()時(shí)試圖再次加鎖就會(huì)因?yàn)殒i已被自己持有而永遠(yuǎn)等待——這就是死鎖。std::recursive_mutex允許同一個(gè)線程多次獲取同一把鎖內(nèi)部用一個(gè)計(jì)數(shù)器記錄鎖的層級(jí)解鎖次數(shù)必須與加鎖次數(shù)匹配。注意遞歸鎖通常意味著你的代碼設(shè)計(jì)可能存在問題。它掩蓋了邏輯復(fù)雜性使得鎖的持有時(shí)間變長(zhǎng)更容易引發(fā)性能瓶頸。我的經(jīng)驗(yàn)是優(yōu)先考慮重構(gòu)代碼避免遞歸調(diào)用需要加鎖的函數(shù)。如果實(shí)在無(wú)法避免比如在遞歸遍歷數(shù)據(jù)結(jié)構(gòu)并修改時(shí)再使用它。std::timed_mutex與std::recursive_timed_mutex 定時(shí)互斥鎖這兩個(gè)鎖在mutex和recursive_mutex的基礎(chǔ)上增加了try_lock_for()和try_lock_until()方法。你可以指定一個(gè)時(shí)間段嘗試獲取鎖超時(shí)了就直接返回失敗而不是傻等。std::timed_mutex tm; if (tm.try_lock_for(std::chrono::milliseconds(100))) { // 成功獲取鎖執(zhí)行操作 tm.unlock(); } else { // 超時(shí)執(zhí)行備選方案比如記錄日志、返回錯(cuò)誤碼 std::cout 獲取資源超時(shí)可能發(fā)生死鎖或系統(tǒng)繁忙\n; }這個(gè)特性在避免死鎖和構(gòu)建響應(yīng)式系統(tǒng)時(shí)非常有用。比如一個(gè)服務(wù)需要同時(shí)鎖住A、B兩個(gè)資源你可以規(guī)定一個(gè)策略先嘗試鎖A如果在50毫秒內(nèi)沒鎖上就放棄并釋放所有已持有的鎖過(guò)會(huì)兒再重試。這比死等下去把整個(gè)線程卡住要好得多。2.2 鎖包裝器lock_guard與unique_lock的抉擇這是新手最容易混淆的地方之一。兩者都是RAII包裝器但能力不同。std::lock_guard 輕量級(jí)衛(wèi)士它在構(gòu)造時(shí)加鎖析構(gòu)時(shí)解鎖。沒有提供任何手動(dòng)控制鎖的接口你不能提前解鎖也不能嘗試加鎖。它的設(shè)計(jì)哲學(xué)是作用域即鎖周期。在絕大多數(shù)簡(jiǎn)單的臨界區(qū)保護(hù)場(chǎng)景下它是首選因?yàn)殚_銷最小。std::unique_lock 功能型管家它比lock_guard更靈活代價(jià)是稍微多一點(diǎn)開銷。它支持延遲加鎖defer_lock構(gòu)造時(shí)不立即加鎖。手動(dòng)加解鎖可以調(diào)用lock(),unlock(),try_lock()。所有權(quán)轉(zhuǎn)移可以通過(guò)std::move轉(zhuǎn)移鎖的所有權(quán)。與條件變量配合使用這是unique_lock最重要的用途條件變量的wait函數(shù)只接受unique_lock參數(shù)。如何選擇記住一個(gè)簡(jiǎn)單的原則默認(rèn)用lock_guard當(dāng)你需要延遲加鎖、手動(dòng)控制、或者要配合條件變量時(shí)再用unique_lock。2.3 實(shí)戰(zhàn)中的死鎖與預(yù)防策略死鎖是多線程的噩夢(mèng)經(jīng)典條件是“循環(huán)等待”。比如線程1鎖了A想去鎖B同時(shí)線程2鎖了B想去鎖A大家就卡死了。C11提供了兩個(gè)利器來(lái)預(yù)防std::lock函數(shù) 一次性鎖住多個(gè)互斥量這是一個(gè)原子操作要么把所有指定的鎖都鎖住要么一個(gè)都不鎖。這從根本上避免了“持有一個(gè)等待另一個(gè)”的死鎖場(chǎng)景。std::mutex mutex1, mutex2; // 錯(cuò)誤做法可能死鎖 // thread1: mutex1.lock(); mutex2.lock(); // thread2: mutex2.lock(); mutex1.lock(); // 正確做法 void safe_op() { std::unique_lockstd::mutex lock1(mutex1, std::defer_lock); std::unique_lockstd::mutex lock2(mutex2, std::defer_lock); std::lock(lock1, lock2); // 一次性鎖住兩個(gè)順序不重要 // ... 操作共享資源 ... }固定鎖順序如果因?yàn)槟承┰虿荒苡胹td::lock那就必須為所有鎖定義一個(gè)全局的獲取順序比如按內(nèi)存地址從小到大所有線程都遵守這個(gè)順序。這需要團(tuán)隊(duì)嚴(yán)格的代碼規(guī)范。一個(gè)我踩過(guò)的坑在析構(gòu)函數(shù)中加鎖要萬(wàn)分小心。如果兩個(gè)對(duì)象a和b的析構(gòu)函數(shù)都需要鎖住同一個(gè)全局鎖G而a的成員中有bb的成員中又有a或者通過(guò)其他方式形成循環(huán)依賴那么在析構(gòu)時(shí)可能會(huì)觸發(fā)未定義行為。解決方案是對(duì)于可能被多個(gè)對(duì)象析構(gòu)函數(shù)使用的鎖考慮使用引用計(jì)數(shù)智能指針來(lái)管理其生命周期或者確保析構(gòu)路徑不構(gòu)成循環(huán)。3. 協(xié)調(diào)者條件變量Condition Variable的生產(chǎn)者-消費(fèi)者模型精解互斥鎖解決了“互斥”訪問的問題但它解決不了“等待某個(gè)條件成立”的問題。比如消費(fèi)者線程需要等待隊(duì)列不為空才能消費(fèi)。如果只用互斥鎖消費(fèi)者線程可能會(huì)這樣寫while (true) { std::lock_guardstd::mutex lock(queue_mutex); if (queue.empty()) { lock.unlock(); // 手動(dòng)解鎖那鎖保護(hù)就失效了 std::this_thread::sleep_for(std::chrono::milliseconds(10)); // 忙等待浪費(fèi)CPU continue; } // 消費(fèi)數(shù)據(jù) }這種“忙等待”busy-waiting模式極其低效CPU空轉(zhuǎn)。條件變量就是為了優(yōu)雅地解決這種“等待-通知”場(chǎng)景而生的。3.1 條件變量的工作流程與“虛假喚醒”條件變量std::condition_variable總是和一個(gè)互斥鎖通常是std::mutex以及一個(gè)共享?xiàng)l件通常是某個(gè)布爾表達(dá)式或狀態(tài)一起使用。它的核心是三個(gè)操作wait,notify_one,notify_all。標(biāo)準(zhǔn)的使用范式如下std::mutex mtx; std::condition_variable cv; bool ready false; // 共享?xiàng)l件 std::queueint data_queue; // 生產(chǎn)者線程 void producer() { // 準(zhǔn)備數(shù)據(jù)... { std::lock_guardstd::mutex lock(mtx); data_queue.push(42); ready true; } // 鎖在這里釋放 cv.notify_one(); // 通知一個(gè)等待的消費(fèi)者 } // 消費(fèi)者線程 void consumer() { std::unique_lockstd::mutex lock(mtx); // 必須使用while循環(huán)來(lái)檢查條件不能是if while (!ready) { // 或者 while(data_queue.empty()) cv.wait(lock); // 1. 原子地解鎖mtx并阻塞本線程 // 2. 被喚醒后在返回前會(huì)重新獲取鎖mtx } // 此時(shí)鎖已重新獲得且條件ready為true // 消費(fèi)數(shù)據(jù)... auto data data_queue.front(); data_queue.pop(); if (data_queue.empty()) ready false; }這里有兩個(gè)至關(guān)重要的點(diǎn)為什么必須用while循環(huán)檢查條件而不是if這是因?yàn)榇嬖凇疤摷賳拘选眘purious wakeup。即使沒有線程調(diào)用notify等待的線程也可能被操作系統(tǒng)喚醒。這是出于性能考慮允許的行為。如果用if被虛假喚醒的線程會(huì)認(rèn)為條件已滿足直接執(zhí)行后續(xù)代碼而此時(shí)條件可能并未成立導(dǎo)致錯(cuò)誤。while循環(huán)確保了每次被喚醒后都重新檢查條件條件不成立就繼續(xù)等待這是唯一正確的寫法。cv.wait(lock)內(nèi)部做了什么這是一個(gè)原子操作a) 解鎖傳入的lockb) 將線程掛起進(jìn)入等待狀態(tài)c) 被通知喚醒后重新嘗試獲取鎖這可能會(huì)阻塞直到鎖可用d) 獲取鎖成功后函數(shù)返回。這個(gè)過(guò)程保證了在檢查條件!ready和進(jìn)入等待狀態(tài)之間不會(huì)有其他線程修改條件并發(fā)出通知否則通知可能丟失。3.2notify_one與notify_all的選用策略notify_one()只喚醒一個(gè)正在等待的線程。如果有多個(gè)線程在等系統(tǒng)會(huì)選擇一個(gè)通常是最先等待的或調(diào)度器決定的。這適用于“單消費(fèi)者”或“任務(wù)任意一個(gè)線程處理即可”的場(chǎng)景效率更高。notify_all()喚醒所有正在等待該條件變量的線程。它們會(huì)全部從wait中返回然后競(jìng)爭(zhēng)鎖并依次因?yàn)殒i是互斥的用while循環(huán)檢查條件。這適用于“條件變化后所有等待線程都需要知曉并可能行動(dòng)”的場(chǎng)景比如一個(gè)初始化完成事件所有工作線程都可以開始干活了。一個(gè)常見的性能陷阱在生產(chǎn)者-消費(fèi)者模型中如果生產(chǎn)者每次生產(chǎn)一個(gè)數(shù)據(jù)就調(diào)用notify_all()而消費(fèi)者有多個(gè)這會(huì)導(dǎo)致“驚群效應(yīng)”——所有消費(fèi)者都被喚醒但只有一個(gè)能搶到數(shù)據(jù)其他線程白忙活一場(chǎng)增加了不必要的上下文切換開銷。在這種情況下使用notify_one()通常是更優(yōu)的選擇。4. 輕量級(jí)武器原子操作Atomic與內(nèi)存模型當(dāng)你只需要保護(hù)一個(gè)簡(jiǎn)單的變量比如一個(gè)計(jì)數(shù)器、一個(gè)標(biāo)志位時(shí)動(dòng)用互斥鎖這種“重型武器”就有點(diǎn)殺雞用牛刀了。鎖的開銷包括系統(tǒng)調(diào)用、上下文切換和可能的緩存失效。C11的原子操作庫(kù)atomic提供了一種無(wú)鎖lock-free或僅需最小化同步的編程方式性能極高。4.1std::atomic的強(qiáng)大與局限std::atomicT模板類為類型T的操作提供了原子性保證。對(duì)于整型、指針等基本類型它提供了load(),store(),exchange(),fetch_add(),fetch_sub()等原子讀寫-修改-寫回操作。std::atomicint counter{0}; void increment() { counter.fetch_add(1, std::memory_order_relaxed); // 原子遞增 } int get_value() { return counter.load(std::memory_order_acquire); // 原子讀取 }原子操作的核心優(yōu)勢(shì)是快。它通常通過(guò)CPU提供的原子指令如x86的LOCK前綴指令實(shí)現(xiàn)直接在緩存一致性協(xié)議層面保證操作的原子性避免了操作系統(tǒng)內(nèi)核的介入。但是原子操作不是萬(wàn)能的它只保證單個(gè)變量的操作是原子的。像counter這樣的非原子操作在多線程下是分三步的讀、改、寫可能被打斷。而counter.fetch_add(1)是一步。它不解決復(fù)合操作的原子性問題。比如你想原子地“如果a5則a10”這需要compare_exchange_strongCAS操作。std::atomic提供了CAS但更復(fù)雜的邏輯如操作多個(gè)原子變量仍需謹(jǐn)慎設(shè)計(jì)有時(shí)甚至需要回退到使用鎖。內(nèi)存序Memory Order是高級(jí)話題用錯(cuò)后果嚴(yán)重。上面代碼中的std::memory_order_relaxed和std::memory_order_acquire就是內(nèi)存序參數(shù)。這是原子操作最難的部分。4.2 理解內(nèi)存序從relaxed到seq_cst這是C多線程中最燒腦也最關(guān)鍵的概念之一。它解決的問題是一個(gè)線程對(duì)原子變量A的寫入何時(shí)以及以何種方式對(duì)另一個(gè)線程可見以及非原子變量的讀寫會(huì)如何與原子操作交互現(xiàn)代CPU和編譯器為了性能會(huì)對(duì)指令進(jìn)行重排序reordering。在單線程下這不會(huì)影響最終結(jié)果。但在多線程下線程A的代碼順序在線程B看來(lái)可能是亂序的這會(huì)導(dǎo)致反直覺的bug。C11定義了6種內(nèi)存序最常用的是三種memory_order_seq_cst順序一致性這是std::atomic所有操作的默認(rèn)參數(shù)如果不指定。它提供了最強(qiáng)的保證所有線程看到的所有原子操作的順序都是一致的且任何操作都像有一個(gè)全局的單一修改順序。這最符合直覺但性能開銷也最大。對(duì)于初學(xué)者如果你不確定該用什么就用這個(gè)默認(rèn)的雖然慢點(diǎn)但安全。memory_order_acquire與memory_order_release這是一對(duì)“獲取-釋放”語(yǔ)義。release釋放用于寫操作如store。保證在這個(gè)操作之前的所有內(nèi)存讀寫包括非原子的都不會(huì)被重排序到這個(gè)操作之后。acquire獲取用于讀操作如load。保證在這個(gè)操作之后的所有內(nèi)存讀寫都不會(huì)被重排序到這個(gè)操作之前。 當(dāng)一個(gè)store帶release操作“同步于”一個(gè)load帶acquire操作即load讀到了store寫入的值那么store操作之前的所有寫都對(duì)load操作之后的讀可見。這常用來(lái)實(shí)現(xiàn)“鎖”或“發(fā)布”語(yǔ)義。// 線程1發(fā)布數(shù)據(jù) Data* data new Data;>std::atomicint error_count{0}; void log_error() { error_count.fetch_add(1, std::memory_order_relaxed); // 只關(guān)心最終值不依賴順序 }我的建議是除非你在進(jìn)行極低延遲的底層開發(fā)并且對(duì)內(nèi)存模型有深刻理解否則在大部分應(yīng)用開發(fā)中使用默認(rèn)的memory_order_seq_cst是穩(wěn)妥的選擇。在明確需要提升性能且場(chǎng)景簡(jiǎn)單時(shí)如自旋鎖、引用計(jì)數(shù)再考慮使用acquire-release語(yǔ)義。relaxed序要慎之又慎。5. 面向未來(lái)異步操作Async與基于任務(wù)的并發(fā)互斥鎖、條件變量、原子操作這些都是相對(duì)底層的同步原語(yǔ)。C11還提供了更高層次的抽象std::async和std::future/std::promise它們鼓勵(lì)我們以“任務(wù)”Task而非“線程”Thread為單位來(lái)思考并發(fā)。5.1std::async讓異步調(diào)用像函數(shù)一樣簡(jiǎn)單std::async是一個(gè)函數(shù)模板它嘗試將其所獲得的函數(shù)對(duì)象或可調(diào)用對(duì)象異步執(zhí)行。它返回一個(gè)std::future對(duì)象用于獲取異步執(zhí)行的結(jié)果。#include future #include iostream int heavy_computation(int x) { // 模擬耗時(shí)計(jì)算 std::this_thread::sleep_for(std::chrono::seconds(1)); return x * x; } int main() { // 啟動(dòng)一個(gè)異步任務(wù) std::futureint fut std::async(std::launch::async, heavy_computation, 10); // 在主線程中做其他事情... std::cout Doing other work...\n; // 當(dāng)需要結(jié)果時(shí)調(diào)用get()。如果任務(wù)未完成會(huì)阻塞等待。 int result fut.get(); std::cout Result is result std::endl; return 0; }std::async的第一個(gè)參數(shù)是啟動(dòng)策略std::launch::async強(qiáng)制在新線程中異步執(zhí)行。std::launch::deferred延遲執(zhí)行。只在future的get()或wait()被調(diào)用時(shí)才在當(dāng)前線程同步執(zhí)行。std::launch::async | std::launch::deferred默認(rèn)由實(shí)現(xiàn)決定。編譯器可能選擇異步也可能選擇延遲。這是一個(gè)坑點(diǎn)如果你依賴任務(wù)的并發(fā)性一定要顯式指定std::launch::async。5.2std::future與std::promise線程間的值傳遞與同步std::future代表一個(gè)“未來(lái)的值”。你可以通過(guò)它查詢異步操作是否完成wait_for,wait_until等待其完成wait或者獲取結(jié)果get。get()只能調(diào)用一次調(diào)用后future狀態(tài)變?yōu)闊o(wú)效。std::promise則是“值的提供者”。它和future是一一對(duì)應(yīng)的。你可以在一個(gè)線程中通過(guò)promise.set_value()來(lái)設(shè)置結(jié)果與之關(guān)聯(lián)的future就能在另一個(gè)線程中獲取到這個(gè)結(jié)果。void producer(std::promiseint prom) { std::this_thread::sleep_for(std::chrono::seconds(2)); prom.set_value(42); // 設(shè)置結(jié)果 } void consumer(std::futureint fut) { std::cout Waiting for result...\n; int result fut.get(); // 阻塞直到結(jié)果可用 std::cout Got result: result std::endl; } int main() { std::promiseint prom; std::futureint fut prom.get_future(); std::thread t1(producer, std::move(prom)); std::thread t2(consumer, std::move(fut)); t1.join(); t2.join(); }這個(gè)模型非常清晰地將“計(jì)算”和“結(jié)果”分離并通過(guò)future/promise這一通道進(jìn)行連接。它比直接用條件變量和共享變量來(lái)傳遞結(jié)果要安全、優(yōu)雅得多。5.3 基于任務(wù)的并發(fā) vs 基于線程的并發(fā)這是兩種不同的并發(fā)范式基于線程你直接管理std::thread的生命周期自己處理同步和數(shù)據(jù)共享。控制力強(qiáng)但負(fù)擔(dān)重容易出錯(cuò)?；谌蝿?wù)你提交任務(wù)函數(shù)給某個(gè)執(zhí)行器可能是std::async也可能是線程池然后通過(guò)future獲取結(jié)果。你不需要關(guān)心任務(wù)在哪個(gè)線程上執(zhí)行。我的實(shí)踐心得在應(yīng)用層代碼中優(yōu)先考慮基于任務(wù)的并發(fā)。使用std::async或更強(qiáng)大的線程池庫(kù)C11標(biāo)準(zhǔn)庫(kù)沒有線程池但C17有std::execution的雛形第三方庫(kù)如Intel TBB、微軟PPL很好用。這能讓你的代碼更干凈更專注于業(yè)務(wù)邏輯而不是線程管理的細(xì)節(jié)。只有在實(shí)現(xiàn)底層基礎(chǔ)設(shè)施如自定義線程池、高性能鎖時(shí)才需要直接操作std::thread和底層的同步原語(yǔ)。6. 信號(hào)量Semaphore的缺席與替代方案細(xì)心的你可能發(fā)現(xiàn)了C11標(biāo)準(zhǔn)庫(kù)并沒有直接提供“信號(hào)量”Semaphore。信號(hào)量是一種更古老的同步機(jī)制由Dijkstra提出它維護(hù)一個(gè)計(jì)數(shù)器提供waitP操作減一和signalV操作加一兩個(gè)原子操作?？梢杂脕?lái)控制同時(shí)訪問某個(gè)資源的線程數(shù)量比如連接池或者實(shí)現(xiàn)更通用的生產(chǎn)者-消費(fèi)者模型。C20終于在semaphore中加入了std::counting_semaphore和std::binary_semaphore。但在C11/14/17中我們需要自己實(shí)現(xiàn)或者用已有的工具組合。6.1 用條件變量和互斥鎖實(shí)現(xiàn)計(jì)數(shù)信號(hào)量一個(gè)計(jì)數(shù)信號(hào)量的核心就是一個(gè)計(jì)數(shù)器、一個(gè)互斥鎖和一個(gè)條件變量。class CountingSemaphore { public: explicit CountingSemaphore(int count 0) : count_(count) {} void signal() { // V操作釋放資源 std::unique_lockstd::mutex lock(mutex_); count_; cv_.notify_one(); // 通知一個(gè)等待的線程 } void wait() { // P操作申請(qǐng)資源 std::unique_lockstd::mutex lock(mutex_); // 必須用while防止虛假喚醒 while (count_ 0) { cv_.wait(lock); } --count_; } bool try_wait() { std::unique_lockstd::mutex lock(mutex_); if (count_ 0) { --count_; return true; } return false; } private: int count_; std::mutex mutex_; std::condition_variable cv_; };這個(gè)實(shí)現(xiàn)清晰展示了信號(hào)量與條件變量的關(guān)系信號(hào)量可以看作是一種泛化的條件變量。條件變量等待的是某個(gè)布爾條件而信號(hào)量等待的是計(jì)數(shù)器大于零。6.2 信號(hào)量的典型應(yīng)用場(chǎng)景限制并發(fā)數(shù)例如數(shù)據(jù)庫(kù)連接池只有10個(gè)連接?？梢杂靡粋€(gè)初始值為10的信號(hào)量。每個(gè)線程在使用連接前wait()用完后再signal()。這樣就能保證最多只有10個(gè)線程同時(shí)持有連接。生產(chǎn)者-消費(fèi)者模型有界緩沖區(qū)這是經(jīng)典用法。需要兩個(gè)信號(hào)量empty_slots初始值為緩沖區(qū)大小N代表空槽位數(shù)量。生產(chǎn)者生產(chǎn)前wait(empty_slots)生產(chǎn)后signal(full_slots)。full_slots初始值為0代表滿槽位數(shù)量。消費(fèi)者消費(fèi)前wait(full_slots)消費(fèi)后signal(empty_slots)。 配合一個(gè)互斥鎖保護(hù)緩沖區(qū)的實(shí)際讀寫就構(gòu)成了一個(gè)完整的有界緩沖區(qū)。這種方案比單純用條件變量判斷空/滿更模塊化。雖然C11標(biāo)準(zhǔn)庫(kù)沒有信號(hào)量但理解其原理并用條件變量實(shí)現(xiàn)它是深入理解同步機(jī)制的一個(gè)很好練習(xí)。在實(shí)際項(xiàng)目中如果用到C20之前的版本可以直接使用上述實(shí)現(xiàn)或者尋找可靠的第三方庫(kù)。