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