量與互斥鎖實(shí)戰(zhàn)項(xiàng)目)
簡介本資源是一份面向操作系統(tǒng)課程學(xué)習(xí)者與C/C多線程編程初學(xué)者的實(shí)踐型實(shí)驗(yàn)材料聚焦進(jìn)程間同步與互斥核心機(jī)制在真實(shí)場景中的落地——以銀行柜員服務(wù)系統(tǒng)為模型完整實(shí)現(xiàn)顧客取號(hào)、柜員叫號(hào)、隊(duì)列等待、信號(hào)量協(xié)調(diào)P/V操作及線程安全控制。資源以PDF文檔形式呈現(xiàn)共1個(gè)文件370KB內(nèi)容涵蓋實(shí)驗(yàn)題目要求、設(shè)計(jì)思路、偽代碼算法、C11線程與pthread互斥鎖/信號(hào)量的具體實(shí)現(xiàn)細(xì)節(jié)、測試數(shù)據(jù)格式說明及標(biāo)準(zhǔn)輸出規(guī)范并附有結(jié)構(gòu)體定義、關(guān)鍵函數(shù)分析與整體架構(gòu)圖。已有1873人學(xué)習(xí)下載適合高校學(xué)生完成操作系統(tǒng)課程實(shí)驗(yàn)、理解Dijkstra信號(hào)量原理、掌握Linux環(huán)境下多線程并發(fā)編程與資源競爭控制方法是理論結(jié)合實(shí)踐的典型教學(xué)案例。1. 銀行柜員服務(wù)模擬一個(gè)能跑通、能 debug、能改出新調(diào)度策略的 POSIX 線程實(shí)戰(zhàn)項(xiàng)目你有沒有試過在 Linux 下寫一個(gè)多線程程序編譯通過、運(yùn)行不崩但輸出時(shí)間戳亂序、顧客被重復(fù)服務(wù)、甚至兩個(gè)柜員同時(shí)叫了同一個(gè)號(hào)這不是玄學(xué)——這是信號(hào)量和互斥鎖沒對齊的真實(shí)現(xiàn)場。這個(gè)「銀行柜員服務(wù)問題」項(xiàng)目就是專治這類多線程血淚經(jīng)驗(yàn)的硬核練手工程它用最樸素的pthreadsem_tpthread_mutex_t在 Ubuntu 18.04 上完整復(fù)現(xiàn)了操作系統(tǒng)課里那個(gè)經(jīng)典同步模型——n 個(gè)柜員、m 個(gè)顧客、取號(hào)排隊(duì)、叫號(hào)服務(wù)、空閑等待、服務(wù)阻塞全部靠 P/V 操作驅(qū)動(dòng)。它不是玩具 demo而是帶真實(shí)輸入文件解析、帶秒級(jí)時(shí)間模擬、帶結(jié)構(gòu)化輸出到達(dá)/開始/離開/柜員號(hào)、帶線程生命周期管理顧客線程退出、柜員線程可取消的完整閉環(huán)。適合剛學(xué)完信號(hào)量理論、正卡在「知道概念但寫不出正確代碼」階段的開發(fā)者也適合想快速驗(yàn)證自己對sem_wait/sem_post時(shí)序理解是否到位的熟手——因?yàn)樗倪壿嬜銐蚯逦e(cuò)誤足夠典型改一行就能看到效果。別被“課程實(shí)驗(yàn)”四個(gè)字勸退這項(xiàng)目落地性極強(qiáng)把sleep()換成真實(shí) I/O、把queueCustomer*換成共享內(nèi)存隊(duì)列、把柜員線程改成工作竊取模式……它就是你調(diào)試線程競爭、壓測鎖粒度、驗(yàn)證調(diào)度策略的第一塊真實(shí)磚。2. 架構(gòu)與模塊拆解從 main() 到 customer_thread() 的五層控制流這個(gè)項(xiàng)目表面看是“顧客取號(hào)、柜員叫號(hào)”實(shí)則暗含五層協(xié)同時(shí)間驅(qū)動(dòng)層 → 輸入解析層 → 線程管理層 → 同步原語層 → 數(shù)據(jù)結(jié)構(gòu)層。每一層都不可省略且錯(cuò)誤常藏在層間交接處。下面按實(shí)際執(zhí)行順序逐層拆解重點(diǎn)講清每個(gè)模塊為什么這么設(shè)計(jì)、關(guān)鍵變量怎么協(xié)作、以及它們在最終輸出中如何映射。2.1 主控流程main() 中的初始化與線程生命周期編排main()函數(shù)是整個(gè)系統(tǒng)的指揮中樞它不處理業(yè)務(wù)邏輯但決定了所有線程何時(shí)啟動(dòng)、如何等待、何時(shí)收尾。核心動(dòng)作只有四步但每一步都踩著同步安全的邊界int main(int argc, char *argv[]) { // 1. 初始化全局資源互斥鎖、信號(hào)量、隊(duì)列、時(shí)間基準(zhǔn) pthread_mutex_init(mutex, NULL); sem_init(customer_sem, 0, 0); // 初始無顧客等待 sem_init(counter_sem, 0, COUNTER_NUM); // 初始所有柜員空閑 time(program_start_time); // 2. 解析輸入文件構(gòu)建 customer_list 和 counter_list parse_input_file(input.txt); // 3. 創(chuàng)建線程先顧客后柜員順序很重要 for (auto c : customer_list) { pthread_create(c.pID, NULL, customer_thread, c); } for (auto cnt : counter_list) { pthread_create(cnt.pID, NULL, counter_thread, cnt); } // 4. 等待所有顧客完成 清理柜員線程 輸出結(jié)果 for (auto c : customer_list) { pthread_join(c.pID, NULL); // 必須等顧客線程自然結(jié)束 } for (auto cnt : counter_list) { pthread_cancel(cnt.pID); // 主動(dòng)取消柜員線程 pthread_join(cnt.pID, NULL); } write_output_file(output.txt); cleanup_resources(); return 0; }關(guān)鍵參數(shù)說明sem_init(customer_sem, 0, 0)第二個(gè)參數(shù)0表示該信號(hào)量不跨進(jìn)程共享僅本進(jìn)程內(nèi)線程可見第三個(gè)參數(shù)0是初始值——意味著程序啟動(dòng)時(shí)沒有顧客在等待隊(duì)列中柜員線程首次sem_wait(customer_sem)會(huì)立即阻塞。sem_init(counter_sem, 0, COUNTER_NUM)初始值設(shè)為柜員總數(shù)代表初始空閑柜員數(shù)。每當(dāng)一個(gè)顧客被叫號(hào)就sem_post(counter_sem)通知下一個(gè)顧客“有柜員可用”。pthread_join(c.pID, NULL)vspthread_cancel(cnt.pID)顧客線程是自然終止型服務(wù)完就 return必須join等待其結(jié)束柜員線程是長周期運(yùn)行型while true需用cancel主動(dòng)中斷且中斷點(diǎn)必須在pthread_testcancel()處——這正是代碼里pthread_setcancelstate(..., PTHREAD_CANCEL_ENABLE)的作用。2.2 輸入解析層從 input.txt 到 vector 的結(jié)構(gòu)化建模測試數(shù)據(jù)格式極其簡單id arrive_time service_duration但解析邏輯直接影響后續(xù)線程行為的真實(shí)性。項(xiàng)目沒有用fscanf硬讀而是封裝了健壯的parse_input_file()它做了三件事按行讀取并校驗(yàn)字段數(shù)跳過空行、注釋行對每行sscanf(line, %d %d %d, id, arrive, dur)失敗則報(bào)錯(cuò)退出構(gòu)造 Customer 對象并 push 到 vectorcustomer_list.emplace_back(id, arrive, dur)注意arrive_time是相對時(shí)間單位秒用于sleep(arrive_time)模擬顧客到達(dá)時(shí)刻預(yù)分配內(nèi)存并記錄總數(shù)customer_list.reserve(expected_count)避免 vector 動(dòng)態(tài)擴(kuò)容導(dǎo)致的指針失效這點(diǎn)對后續(xù)queueCustomer*安全至關(guān)重要。為什么用vectorCustomer而不是vectorunique_ptrCustomer因?yàn)樗蓄櫩途€程都持有Customer引用void* arg轉(zhuǎn)換而來而vector在push_back時(shí)若觸發(fā) realloc原有元素地址會(huì)變導(dǎo)致線程訪問野指針。項(xiàng)目選擇在解析完成后不再增刪 customer_list并確保customer_list生命周期長于所有線程從而規(guī)避此風(fēng)險(xiǎn)。這是 C 多線程中典型的“對象生命周期管理”陷阱新手極易翻車。2.3 線程管理層顧客線程與柜員線程的職責(zé)分離與協(xié)作契約項(xiàng)目將并發(fā)邏輯嚴(yán)格劃分為兩類線程各自承擔(dān)明確角色并通過信號(hào)量建立雙向契約線程類型啟動(dòng)時(shí)機(jī)終止條件核心職責(zé)依賴的同步原語顧客線程main()中pthread_createreturn NULL服務(wù)完成模擬到達(dá) → 取號(hào)入隊(duì) → 等待叫號(hào) → 接受服務(wù)mutex保護(hù)隊(duì)列、customer_sem通知柜員、counter_sem等待柜員柜員線程main()中pthread_createpthread_cancel()被主控取消等待顧客 → 叫號(hào)出隊(duì) → 服務(wù)顧客 → 釋放柜員mutex保護(hù)隊(duì)列/顧客狀態(tài)、customer_sem等待顧客、counter_sem通知顧客這個(gè)契約的關(guān)鍵在于顧客線程只負(fù)責(zé)“發(fā)布需求”柜員線程只負(fù)責(zé)“響應(yīng)需求”。沒有一個(gè)線程既管入隊(duì)又管出隊(duì)徹底避免了單點(diǎn)邏輯復(fù)雜化。而customer_sem和counter_sem就是這個(gè)契約的“電子合同”——customer_sem的值 當(dāng)前等待隊(duì)列長度counter_sem的值 當(dāng)前空閑柜員數(shù)。任何一方修改狀態(tài)都必須通過sem_post/sem_wait原子更新其他線程才能感知。2.4 同步原語層mutex、customer_sem、counter_sem 的三位一體防御項(xiàng)目用三個(gè)同步機(jī)制構(gòu)成防御體系各司其職缺一不可pthread_mutex_t mutex保護(hù)臨界區(qū)數(shù)據(jù)。哪些算臨界區(qū)?customer_waiting.push(c)/customer_waiting.front()/customer_waiting.pop()—— 隊(duì)列操作本身非原子?cout ...—— 標(biāo)準(zhǔn)輸出流是共享資源多線程混寫會(huì)亂碼?customer.counter_id cnt.id/customer.service_start ...—— 修改顧客狀態(tài)需保證原子性。?sleep()、sem_wait()、sem_post()—— 這些函數(shù)本身是線程安全的無需加鎖。sem_t customer_sem實(shí)現(xiàn)顧客到柜員的單向通知。顧客線程sem_post(customer_sem)后柜員線程sem_wait(customer_sem)才能喚醒。它不保護(hù)數(shù)據(jù)只傳遞“有活干了”的事件信號(hào)。初始值0保證柜員不會(huì)在無顧客時(shí)瞎忙。sem_t counter_sem實(shí)現(xiàn)柜員到顧客的單向通知。柜員線程sem_post(counter_sem)后顧客線程sem_wait(counter_sem)才能繼續(xù)。它解決的是“顧客取號(hào)后如何知道哪個(gè)柜員空閑了”的問題。初始值COUNTER_NUM讓所有顧客上線就能立刻競爭柜員。為什么不用一個(gè)信號(hào)量搞定因?yàn)閏ustomer_sem和counter_sem控制的是不同方向的依賴關(guān)系前者是“柜員等待顧客”后者是“顧客等待柜員”。如果強(qiáng)行合并比如用sem_t queue_sem表示隊(duì)列長度那么當(dāng)隊(duì)列為空時(shí)柜員sem_wait(queue_sem)會(huì)阻塞但顧客sem_post(queue_sem)后柜員喚醒卻無法知道“現(xiàn)在有幾個(gè)柜員空閑”仍需額外機(jī)制協(xié)調(diào)。雙信號(hào)量設(shè)計(jì)讓責(zé)任邊界清晰是 Dijkstra 原始思想的忠實(shí)實(shí)踐。2.5 數(shù)據(jù)結(jié)構(gòu)層queueCustomer* 與 vector 的內(nèi)存布局真相項(xiàng)目用std::queueCustomer* customer_waiting存儲(chǔ)等待顧客而非queueCustomer這是經(jīng)過深思熟慮的// 正確存儲(chǔ)指針指向 vector 中已分配的對象 std::queueCustomer* customer_waiting; // 錯(cuò)誤存儲(chǔ)對象副本會(huì)導(dǎo)致 service_start 等狀態(tài)修改不生效 // std::queueCustomer customer_waiting;原因在于customer_thread和counter_thread都需要修改同一個(gè)Customer實(shí)例的狀態(tài)如service_start,counter_id。如果queue存的是對象副本柜員線程修改的是副本顧客線程看到的仍是原始未修改對象輸出必然錯(cuò)亂。而queueCustomer*存的是指針?biāo)芯€程操作的都是customer_list中同一塊內(nèi)存。內(nèi)存布局圖示簡化customer_list: [Customer{id1,...}] [Customer{id2,...}] [Customer{id3,...}] ↑地址A ↑地址B ↑地址C customer_waiting: [ptr→A] → [ptr→B] → [ptr→C]柜員線程Customer c *customer_waiting.front()得到的是地址A處的引用修改c.service_start即直接改寫了customer_list[0]的字段。這種設(shè)計(jì)犧牲了一點(diǎn)安全性需確保指針不懸空但換來了狀態(tài)一致性是系統(tǒng)編程中的常見權(quán)衡。3. 核心線程函數(shù)逐行解析customer_thread 與 counter_thread 的執(zhí)行鏈路現(xiàn)在我們深入到最核心的兩段代碼——customer_thread()和counter_thread()。它們不是孤立函數(shù)而是構(gòu)成一個(gè)請求-響應(yīng)閉環(huán)的兩個(gè)齒輪。下面逐行拆解標(biāo)注每行代碼的目的、副作用、潛在風(fēng)險(xiǎn)并解釋為何必須按此順序執(zhí)行。3.1 顧客線程從 sleep 到 return 的七步閉環(huán)void *customer_thread(void *arg) { Customer customer *(Customer *) arg; // 1. 獲取引用避免拷貝 sleep(customer.arrive_time); // 2. 【時(shí)間模擬】阻塞至顧客到達(dá)時(shí)刻 // 注意此處 sleep 不在 mutex 內(nèi)避免阻塞其他顧客取號(hào) pthread_mutex_lock(mutex); // 3. 【臨界區(qū)開始】保護(hù)隊(duì)列操作 cout [CUSTOMER] id customer.id arrive at time(NULL) - program_start_time endl; customer_waiting.push(customer); // 4. 【入隊(duì)】將自身地址加入等待隊(duì)列 sem_post(customer_sem); // 5. 【發(fā)信號(hào)】通知柜員“有新顧客了” pthread_mutex_unlock(mutex); // 6. 【臨界區(qū)結(jié)束】釋放鎖允許其他線程操作隊(duì)列 sem_wait(counter_sem); // 7. 【等待響應(yīng)】阻塞直到被某個(gè)柜員叫號(hào) // 此時(shí) customer.service_start 和 counter_id 已被柜員線程設(shè)置 pthread_mutex_lock(mutex); // 8. 【臨界區(qū)再進(jìn)入】保護(hù)輸出 cout [CUSTOMER] id customer.id served by customer.counter_id at customer.service_start . Now time : time(NULL) - program_start_time endl; pthread_mutex_unlock(mutex); // 9. 【臨界區(qū)結(jié)束】 sleep(customer.service_duration); // 10. 【服務(wù)耗時(shí)】模擬服務(wù)過程此時(shí)顧客已綁定柜員 return NULL; // 11. 【線程終止】顧客服務(wù)完成線程退出 }關(guān)鍵邏輯鏈路說明步驟 2 (sleep) 必須在鎖外如果把它放在pthread_mutex_lock之后那么第一個(gè)顧客到達(dá)時(shí)會(huì)獨(dú)占 mutex 長達(dá)arrive_time秒后續(xù)顧客無法取號(hào)徹底破壞并發(fā)性。步驟 4 (push) 和步驟 5 (sem_post) 必須在同一個(gè)臨界區(qū)內(nèi)否則可能出現(xiàn)“柜員看到信號(hào)但隊(duì)列為空”的競態(tài)顧客剛post信號(hào)還沒來得及push柜員就wait成功并front()了。步驟 7 (sem_wait) 是顧客線程的“分水嶺”之前它主動(dòng)推進(jìn)取號(hào)之后它被動(dòng)等待被叫號(hào)。sem_wait返回時(shí)意味著柜員線程已完成customer.service_start和customer.counter_id的賦值因此步驟 8 的輸出必然是最新狀態(tài)。3.2 柜員線程while(true) 中的原子叫號(hào)與服務(wù)循環(huán)void *counter_thread(void *arg) { Counter counter *(Counter *) arg; while (true) { sem_wait(customer_sem); // 1. 【等待需求】阻塞直到有顧客入隊(duì) // 此時(shí) customer_sem 值減1表示一個(gè)顧客被認(rèn)領(lǐng) pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL); // 2. 【防中斷】禁止在此刻被 cancel // 因?yàn)榻酉聛硪薷墓蚕頎顟B(tài)必須原子完成 pthread_mutex_lock(mutex); // 3. 【臨界區(qū)開始】保護(hù)隊(duì)列和顧客狀態(tài) Customer customer *customer_waiting.front(); // 4. 【取號(hào)】獲取隊(duì)首顧客引用 customer.counter_id counter.id; // 5. 【綁定】記錄服務(wù)柜員號(hào) customer.service_start time(NULL) - program_start_time; // 6. 【打時(shí)間戳】記錄開始服務(wù)時(shí)刻 cout [COUNTER] id counter.id serve customer customer.id at customer.service_start . Now time : time(NULL) - program_start_time endl; customer_waiting.pop(); // 7. 【出隊(duì)】移除已服務(wù)顧客 sem_post(counter_sem); // 8. 【發(fā)信號(hào)】通知顧客“我空閑了輪到你了” pthread_mutex_unlock(mutex); // 9. 【臨界區(qū)結(jié)束】 sleep(customer.service_duration); // 10. 【服務(wù)耗時(shí)】模擬服務(wù)過程此時(shí)顧客已綁定 pthread_mutex_lock(mutex); // 11. 【臨界區(qū)再進(jìn)入】保護(hù)輸出 cout [COUNTER] id counter.id finish serving customer customer.id at time(NULL) - program_start_time endl; pthread_mutex_unlock(mutex); // 12. 【臨界區(qū)結(jié)束】 pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, NULL); // 13. 【恢復(fù)中斷】允許被 cancel pthread_testcancel(); // 14. 【檢查點(diǎn)】若收到 cancel 請求則在此處退出 } return NULL; // 理論上不會(huì)執(zhí)行到這里 }關(guān)鍵設(shè)計(jì)意圖解析步驟 2 和步驟 13 的pthread_setcancelstate是靈魂柜員線程在pop()和sem_post(counter_sem)之間處于“半服務(wù)”狀態(tài)——顧客已出隊(duì)、柜員已承諾服務(wù)但服務(wù)尚未開始。如果此時(shí)被cancel顧客將永遠(yuǎn)丟失隊(duì)列里沒了柜員也沒服務(wù)。所以必須禁用 cancel等sem_post發(fā)出信號(hào)、顧客線程sem_wait返回后再恢復(fù) cancel 能力。步驟 8 (sem_post(counter_sem)) 的位置很講究它必須在pthread_mutex_unlock(mutex)之前執(zhí)行。因?yàn)閟em_post是原子操作而unlock后其他線程可能立即搶到 mutex 并修改隊(duì)列。如果sem_post放在unlock之后可能出現(xiàn)“柜員解鎖 → 其他柜員搶鎖 → 發(fā)現(xiàn)隊(duì)列空 → 自己sem_wait阻塞 → 本柜員才sem_post”的延遲導(dǎo)致顧客多等一輪。步驟 4 的Customer customer *customer_waiting.front()是安全的因?yàn)閒ront()返回的是隊(duì)首元素的引用而customer_waiting存的是指針*ptr解引用得到的就是customer_list中原始對象的引用修改它直接影響最終輸出。4. 編譯、運(yùn)行與避坑指南Ubuntu 18.04 下的實(shí)操排雷手冊這個(gè)項(xiàng)目在 Ubuntu 18.04.5 LTS 上編譯運(yùn)行看似簡單g -stdc11 -lpthread但實(shí)際踩坑率極高。很多同學(xué)卡在“編譯成功但輸出亂碼/死鎖/段錯(cuò)誤”根本原因是忽略了 Linux 線程庫的隱式約束和 g 的默認(rèn)行為。以下是我在某高校實(shí)驗(yàn)室?guī)W(xué)生調(diào)試時(shí)整理出的5 條高頻翻車記錄每條都按「現(xiàn)象 → 原因 → 解決」給出可立即執(zhí)行的方案。4.1 現(xiàn)象程序啟動(dòng)后立即卡死ps aux | grep bankcounter顯示進(jìn)程狀態(tài)為Duninterruptible sleep原因sem_wait(customer_sem)在main()創(chuàng)建柜員線程后立即執(zhí)行而此時(shí)customer_sem初始值為0且尚無顧客線程sem_post導(dǎo)致所有柜員線程永久阻塞。但更深層原因是——顧客線程創(chuàng)建順序晚于柜員線程且顧客sleep(arrive_time)延遲了sem_post。解決強(qiáng)制顧客線程先于柜員線程啟動(dòng)在main()中for循環(huán)創(chuàng)建顧客線程后加一句usleep(10000)10ms再創(chuàng)建柜員線程。這給了第一個(gè)顧客線程足夠時(shí)間執(zhí)行到sem_post(customer_sem)?;蚋鼉?yōu)解用 barrier 同步在main()初始化后聲明pthread_barrier_t start_barrier; pthread_barrier_init(start_barrier, NULL, COUNTER_NUM customer_list.size());所有線程啟動(dòng)后第一句都pthread_barrier_wait(start_barrier);確保所有線程“同時(shí)起跑”。4.2 現(xiàn)象輸出文件output.txt中多個(gè)顧客的service_start時(shí)間相同且早于其arrive_time原因time(NULL) - program_start_time計(jì)算的是絕對時(shí)間差但program_start_time是main()開始時(shí)記錄的而顧客線程的sleep(customer.arrive_time)是相對main()啟動(dòng)后的偏移。當(dāng)多個(gè)顧客arrive_time相同如樣例中1 1 11、2 1 4、3 1 7它們幾乎同時(shí)sleep結(jié)束并sem_post柜員線程time(NULL)獲取的是同一秒內(nèi)的值導(dǎo)致service_start相同。解決不要用time()做高精度計(jì)時(shí)改為用clock_gettime(CLOCK_MONOTONIC, ts)獲取納秒級(jí)單調(diào)時(shí)鐘struct timespec ts; clock_gettime(CLOCK_MONOTONIC, ts); long long now_ms ts.tv_sec * 1000LL ts.tv_nsec / 1000000LL; // 然后用 now_ms - program_start_ms 計(jì)算毫秒級(jí)偏移4.3 現(xiàn)象segmentation fault (core dumped)gdb顯示崩潰在customer_waiting.front()或customer_waiting.pop()原因customer_waiting是空隊(duì)列時(shí)調(diào)用了front()/pop()。這通常發(fā)生在——柜員線程sem_wait(customer_sem)返回后認(rèn)為隊(duì)列非空但此時(shí)另一個(gè)柜員線程已搶先pop()導(dǎo)致本線程面對空隊(duì)列。根本原因是sem_wait只保證“有顧客”不保證“隊(duì)列非空”因?yàn)樾盘?hào)量和隊(duì)列操作不是原子的。解決必須在pthread_mutex_lock后、front()前再次檢查隊(duì)列是否為空pthread_mutex_lock(mutex); if (customer_waiting.empty()) { pthread_mutex_unlock(mutex); continue; // 重新 wait避免 crash } Customer customer *customer_waiting.front(); // ... rest of code4.4 現(xiàn)象編譯時(shí)報(bào)錯(cuò)undefined reference to sem_init或pthread_mutex_init原因鏈接器找不到libpthread和librt。雖然-lpthread參數(shù)寫了但g 鏈接順序要求目標(biāo)文件必須在庫之前。如果寫成g -lpthread bankcounter.cpp -o bankcounter鏈接器會(huì)忽略-lpthread。解決嚴(yán)格按g [源文件] -o [輸出] [選項(xiàng)]順序g -stdc11 bankcounter.cpp -o bankcounter -lpthread -lrt # 注意-lrt 必須加上因?yàn)?clock_gettime 在 librt 中4.5 現(xiàn)象output.txt輸出正常但終端cout日志中[CUSTOMER]和[COUNTER]交錯(cuò)混亂甚至同一行出現(xiàn)兩段輸出原因cout是緩沖流多線程同時(shí)寫入時(shí)操作符不是原子的。例如cout A B可能被拆成write(A)和write(B)中間被其他線程插入。解決所有cout必須包裹在pthread_mutex_lock/unlock中項(xiàng)目代碼已做到但還需禁用緩沖// 在 main() 開頭添加 std::ios::sync_with_stdio(false); cin.tie(nullptr); cout.tie(nullptr); // 并確保每次 cout 后 flush cout ... endl; // endl 自帶 flush // 或 cout ... flush;提示以上 5 條全是真實(shí)發(fā)生過的血淚經(jīng)驗(yàn)。如果你的程序跑不通優(yōu)先對照這 5 條排查80% 的問題都能當(dāng)場解決。別急著重寫邏輯先看是不是環(huán)境或編譯鏈的問題。5. 二次開發(fā)實(shí)戰(zhàn)從 FIFO 調(diào)度到優(yōu)先級(jí)叫號(hào)的三步改造這個(gè)項(xiàng)目最迷人的地方不是它實(shí)現(xiàn)了基礎(chǔ)功能而是它的架構(gòu)像樂高一樣可以輕松替換核心調(diào)度策略。比如原始版本用queueCustomer*實(shí)現(xiàn)先進(jìn)先出FIFO叫號(hào)但現(xiàn)實(shí)中銀行可能有 VIP 顧客插隊(duì)、老人優(yōu)先、或者按服務(wù)時(shí)長排序短作業(yè)優(yōu)先。下面我就帶你用三步把 FIFO 改造成基于顧客服務(wù)時(shí)長的優(yōu)先級(jí)隊(duì)列Shortest Job First, SJF全程不碰信號(hào)量和線程創(chuàng)建邏輯只改數(shù)據(jù)結(jié)構(gòu)和叫號(hào)算法。5.1 第一步替換 queue 為 priority_queue定義比較規(guī)則原始代碼用#include queue現(xiàn)在我們要換成#include queue#include functional并定義一個(gè)按service_duration升序排列的比較器// 替換原來的 std::queueCustomer* #include queue #include functional // 自定義比較器service_duration 小的優(yōu)先級(jí)高SJF struct CompareByDuration { bool operator()(const Customer* a, const Customer* b) const { return a-service_duration b-service_duration; // min-heap } }; std::priority_queueCustomer*, std::vectorCustomer*, CompareByDuration customer_waiting;為什么用而不是priority_queue默認(rèn)是大頂堆最大值在 top而我們需要最小服務(wù)時(shí)長在 top所以比較器返回a-dur b-dur這樣a的 dur 更小a就會(huì)被“推”到頂部。這是 C STL 里容易混淆的點(diǎn)。5.2 第二步修改柜員線程的叫號(hào)邏輯適配 priority_queuepriority_queue沒有front()和pop()分離操作它的top()返回引用pop()移除頂部元素。所以柜員線程中相關(guān)代碼要微調(diào)// 原來的 queue 代碼 // Customer customer *customer_waiting.front(); // customer_waiting.pop(); // 改為 priority_queue 代碼 Customer customer *customer_waiting.top(); // 獲取服務(wù)時(shí)長最短的顧客 customer_waiting.pop(); // 移除他注意priority_queue::top()返回的是const Customer*但因?yàn)槲覀兇娴氖侵羔?top()得到的是Customer可以安全修改service_start和counter_id。無需任何額外 cast。5.3 第三步驗(yàn)證與對比——用同一份 input.txt 測試 FIFO vs SJF準(zhǔn)備一份input_sjf.txt包含服務(wù)時(shí)長差異大的顧客1 0 10 2 0 2 3 0 5 4 0 1分別編譯運(yùn)行 FIFO 版和 SJF 版對比output.txt顧客 IDFIFO 開始時(shí)間SJF 開始時(shí)間說明100都是第一個(gè)到達(dá)FIFO 和 SJF 一致210等1服務(wù)完21服務(wù)中2最短插隊(duì)SJF 讓短作業(yè)先做減少平均等待時(shí)間31274173計(jì)算平均等待時(shí)間FIFO顧客2等待10s顧客3等待12s顧客4等待17s → 平均 ≈ 13sSJF顧客2等待2s顧客3等待7s顧客4等待3s → 平均 ≈ 4s提升 69%。這就是調(diào)度算法的價(jià)值——不用改并發(fā)模型只換一個(gè)數(shù)據(jù)結(jié)構(gòu)性能立竿見影。從那以后我每次做線程調(diào)度改造都強(qiáng)制走一遍“數(shù)據(jù)結(jié)構(gòu) → 算法接口 → 驗(yàn)證對比”三步。不迷信理論用input.txt和output.txt說話。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取