簡介面向大二數(shù)據(jù)結(jié)構(gòu)課程設計的任務調(diào)度器完整實現(xiàn)基于C/C在Visual Studio 2019環(huán)境下開發(fā)適合需要完成同類課題或希望深入理解任務調(diào)度與隊列、優(yōu)先級等數(shù)據(jù)結(jié)構(gòu)應用的學生參考。壓縮包共38個文件約40.97MB包含源代碼文件cpp/hpp、Visual Studio工程文件sln/vcxproj/filters、編譯運行產(chǎn)生的exe、pdb、obj及日志文件等打開工程即可查看完整實現(xiàn)并運行驗證。目前已有207人學習下載。資源提供可直接運行的任務調(diào)度器Demo涵蓋任務隊列管理、優(yōu)先級調(diào)度等核心模塊代碼結(jié)構(gòu)清晰并附有類圖文件可幫助讀者快速理清模塊關系為課程設計答辯和功能擴展提供實用參考。1. 任務調(diào)度器把數(shù)據(jù)結(jié)構(gòu)課上的「鏈表和堆」變成能跑出結(jié)果的完整工程每年數(shù)據(jù)結(jié)構(gòu)課程設計的題目池里幾乎都會出現(xiàn)一個「任務調(diào)度器」。它聽起來像操作系統(tǒng)的事但實際上整份作業(yè)的核心矛盾只有一個一批任務在不同時刻到達每個任務要跑多久、優(yōu)先級多高各不相同你要用什么樣的數(shù)據(jù)結(jié)構(gòu)把它們組織起來才能讓「下一個該執(zhí)行誰」這個判斷既快又公平。這份用 C/C 寫成的課程設計資源把 FCFS先來先服務、SJF短作業(yè)優(yōu)先、時間片輪轉(zhuǎn)、優(yōu)先級調(diào)度四種算法全部落成了可編譯、可運行、可出報告對比的工程。適合正在備戰(zhàn)的課設學生也適合想借一個真實項目復習鏈表、二叉堆和模擬器設計的開發(fā)者。你拿到的不是只貼代碼的片段而是覆蓋「設計—實現(xiàn)—測試—報告」全流程的完整交付物。2. 項目結(jié)構(gòu)拆解壓縮包里藏著「源碼 文檔」兩條線先分清再動手解壓之后先別急著點開 main.cpp。我見過太多人拿到課設資源第一件事就是找主函數(shù)結(jié)果被十幾個文件繞暈最后連編譯都過不去。這份資源遵循了課程設計最常見的「雙軌」組織方式一條線是能編譯運行的 C/C 工程另一條線是寫報告用的需求分析、詳細設計和測試文檔。先花十分鐘把目錄結(jié)構(gòu)摸清楚后面調(diào)試和寫報告都會省下大量時間。2.1 目錄結(jié)構(gòu)src、data、docs 三層每個文件都能對號入座TaskScheduler/ ├── src/ │ ├── tcb.h # 任務控制塊任務狀態(tài)與時間屬性的定義 │ ├── queue.h / queue.cpp # 就緒隊列雙向鏈表的接口與實現(xiàn) │ ├── heap.h / heap.cpp # 二叉堆SJF 和優(yōu)先級調(diào)度的共同底座 │ ├── scheduler.h # 調(diào)度器對外接口策略入口與統(tǒng)計函數(shù) │ ├── scheduler.cpp # 四種調(diào)度算法的核心邏輯 │ └── main.cpp # 程序入口讀文件、跑調(diào)度、打印結(jié)果 ├── data/ │ ├── case1.txt # 5 個任務的經(jīng)典測試用例便于肉眼驗算 │ ├── case2.txt # 20 個任務含到達時間沖突和優(yōu)先級重復 │ └── case3.txt # 隨機生成的大樣本用于驗證性能 ├── docs/ │ ├── 需求分析.md # 題目要求拆解與功能清單 │ ├── 詳細設計.md # 數(shù)據(jù)結(jié)構(gòu)選型、模塊劃分、偽代碼 │ └── 測試報告.md # 四組算法對比數(shù)據(jù)與圖表說明 └── Makefile # 一鍵編譯依賴關系和清理目標都已配好src 目錄是真正的工程核心頭文件和實現(xiàn)文件成對出現(xiàn)職責劃分得很清楚tcb.h 只定義數(shù)據(jù)結(jié)構(gòu)不摻任何算法邏輯queue 和 heap 是通用的容器層跟具體調(diào)度策略解耦scheduler 層才負責「用哪個容器、按什么規(guī)則選任務」。data 目錄里的三個測試用例是容易被忽略但價值很高的部分case1 的任務數(shù)量少、時間干凈就是為了讓你能拿筆在紙上驗算一遍結(jié)果case3 則是壓測用的能逼出時間復雜度上的問題。docs 目錄在交課設時幾乎是剛需詳細設計文檔里的偽代碼可以直接當作報告的核心章節(jié)來擴寫。2.2 數(shù)據(jù)結(jié)構(gòu)選型為什么就緒隊列用雙向鏈表優(yōu)先級調(diào)度用二叉堆這是答辯時老師最愛問的問題也是這份資源設計的隱藏主線。調(diào)度器里有兩類核心操作一類是「任務到達后插入就緒集合」另一類是「每次調(diào)度時取出下一個要執(zhí)行的任務」。不同的算法對這兩類操作的頻率要求不一樣于是選型也不一樣。數(shù)據(jù)結(jié)構(gòu)插入取出最值刪除指定節(jié)點適合的算法數(shù)組O(n) 移動O(n) 掃描O(n)數(shù)據(jù)量小、代碼簡單單向鏈表O(1) 頭插/尾插O(n) 遍歷O(n) 需找前驅(qū)FCFS、簡單 RR雙向鏈表O(1) 尾插O(n) 遍歷O(1) 已知節(jié)點FCFS、RR、搶占式優(yōu)先級二叉堆O(log n)O(1) 取堆頂O(log n) 重建SJF、非搶占優(yōu)先級這份資源的組合方案是「雙向鏈表 二叉堆」就緒隊列本體用雙向鏈表因為時間片輪轉(zhuǎn)要把被搶占的任務重新掛到隊尾FCFS 也是天然的先到先服務順序鏈表尾插正好 O(1)而 SJF 和優(yōu)先級調(diào)度需要反復「取出當前最優(yōu)任務」如果每次都用鏈表的 O(n) 遍歷20 個任務的樣例看不出問題case3 隨機生成幾百個任務時差距就會非常明顯所以這兩類算法走的是二叉堆。值得注意的是雙向鏈表在這里還有一個隱藏優(yōu)勢時間片輪轉(zhuǎn)里任務可能被執(zhí)行一半后被搶走此時它還在鏈表中需要按節(jié)點直接摘除雙向鏈表在已知節(jié)點的情況下刪除是 O(1)單向鏈表還得從頭遍歷找前驅(qū)這就是設計上多付一個 prev 指針換來的收益。2.3 模塊劃分讀入、調(diào)度、統(tǒng)計三層隔離接口只看 scheduler.hscheduler.h 是整個工程的門面四個公有函數(shù)把「數(shù)據(jù)進來」到「結(jié)果出去」的鏈路全部串起來其余細節(jié)全部封裝在實現(xiàn)文件里// scheduler.h 對外暴露的接口main.cpp 只依賴這四個函數(shù) bool loadTasks(const char* path, TCB tasks[], int taskCount); void runScheduler(TCB tasks[], int taskCount, int policy, int timeSlice); void printGantt(TCB tasks[], int taskCount); void printStatistics(TCB tasks[], int taskCount);參數(shù)說明policy 是算法枚舉資源里約定 0FCFS、1SJF、2優(yōu)先級調(diào)度、3時間片輪轉(zhuǎn)timeSlice 只在 policy 為 3 時有意義表示每個任務一次最多占用的時鐘節(jié)拍數(shù)。loadTasks 負責把 data 目錄下的 txt 文件解析成 TCB 數(shù)組runScheduler 根據(jù) policy 走不同分支printGantt 輸出帶時間軸的執(zhí)行序列printStatistics 計算平均周轉(zhuǎn)時間、平均帶權周轉(zhuǎn)時間和平均等待時間。三層之間不互相調(diào)用內(nèi)部函數(shù)比如 loadTasks 不會去碰 heap 的任何接口這樣做的實際收益是你想換一種輸入格式只需要改 loadTasks想加一種新調(diào)度算法只需要在 runScheduler 里加一個 case 分支測試時也可以單獨驗證每一層。我第一次改造這種結(jié)構(gòu)時感觸很深課設代碼最容易爛在「所有事情都塞在 main 里」而這個工程把邊界劃得很干凈二次開發(fā)時幾乎不用重構(gòu)。3. 核心代碼拆解一個任務從「到達」到「跑完」在調(diào)度器里的完整生命周期這一章是整套代碼最值得逐行讀的部分。調(diào)度器的本質(zhì)是一個按時鐘節(jié)拍推進的模擬器每個節(jié)拍代表一個單位時間程序在一個大循環(huán)里不斷回答三個問題——當前有沒有新任務到達CPU 上有沒有任務在跑如果沒有下一個該選誰理解了這條時間軸四種算法其實只是第三個問題的答案不同而已。3.1 TCB用結(jié)構(gòu)體把任務的「一生」記錄下來所有調(diào)度算法的輸入輸出都是圍繞任務控制塊TCB展開的它相當于操作系統(tǒng)的進程控制塊在課設里的簡化版typedef struct TCB { int pid; // 任務編號從 1 開始遞增 int arriveTime; // 到達時間單位是時鐘節(jié)拍 int serviceTime; // 需要的總 CPU 運行時間 int remainTime; // 剩余運行時間時間片輪轉(zhuǎn)要實時修改它 int priority; // 優(yōu)先級數(shù)值越小優(yōu)先級越高 int startTime; // 第一次被調(diào)度執(zhí)行的時間初始為 -1 int finishTime; // 執(zhí)行完成的時間初始為 -1 int status; // 0未到達 1就緒 2運行 3完成 struct TCB* prev; // 雙向鏈表前驅(qū)指針 struct TCB* next; // 雙向鏈表后繼指針 } TCB;字段設計的幾個關鍵點remainTime 和 serviceTime 分開存是因為時間片輪轉(zhuǎn)會一次次打斷任務執(zhí)行serviceTime 是任務的固有屬性用來算周轉(zhuǎn)類指標remainTime 是動態(tài)狀態(tài)歸零代表任務完成startTime 初始化為 -1 而不是 0是為了區(qū)分「任務真的在 0 時刻開始執(zhí)行」和「還沒執(zhí)行過」這個細節(jié)在計算帶權周轉(zhuǎn)時間時特別容易出錯status 字段配合鏈表指針使用能快速判斷一個任務當前是否還在就緒隊列里防止重復入隊。prev 和 next 直接嵌在 TCB 里而不是再包一層鏈表節(jié)點結(jié)構(gòu)是為了讓同一個 TCB 既能在鏈表中被管理又能直接作為堆里的元素避免指針來回轉(zhuǎn)換的麻煩。3.2 就緒隊列雙向鏈表的尾插與 O(1) 摘除就緒隊列是 FCFS 和 RR 的基礎容器它維護一個全局雙向鏈表頭指針指向最先到達的任務尾指針指向最后到達的任務// 將任務掛到就緒隊列尾部FCFS 和 RR 都用它入隊 bool appendReady(TCB* task) { if (task NULL) return false; if (readyHead NULL) { readyHead readyTail task; // 隊列為空 } else { readyTail-next task; // 掛在尾節(jié)點后面 task-prev readyTail; task-next NULL; readyTail task; // 更新尾指針 } readyCount; return true; } // 從就緒隊列中摘除指定任務已知節(jié)點時 O(1) bool removeReady(TCB* task) { if (task-prev ! NULL) task-prev-next task-next; else readyHead task-next; // 刪的是頭節(jié)點 if (task-next ! NULL) task-next-prev task-prev; else readyTail task-prev; // 刪的是尾節(jié)點 task-prev task-next NULL; // 斷開防止野指針 readyCount--; return true; }邏輯說明appendReady 維護隊尾新任務永遠從尾部進入這樣先到達的任務天然排在前面FCFS 按鏈表順序取頭節(jié)點即可removeReady 最核心的價值在時間片輪轉(zhuǎn)場景——一個任務被搶占后重新入隊或者優(yōu)先級調(diào)度中一個高優(yōu)先級任務插隊后把正在運行的任務放回隊列都需要從鏈表中間把某個節(jié)點摘掉再重新掛到尾部如果只有 next 指針必須從頭遍歷才能拿到前驅(qū)而雙向鏈表用 task-prev 直接回退刪除成本降為 O(1)。這兩個函數(shù)配合 readyCount 計數(shù)器還順帶解決了調(diào)度主循環(huán)的終止條件判斷。3.3 調(diào)度主循環(huán)時鐘節(jié)拍驅(qū)動下的策略分發(fā)scheduler.cpp 里的核心是一個 for 循環(huán)clock 從 0 開始每輪加一模擬時間流逝for (int clock 0; running ! NULL || readyCount 0; clock) { // 第一步當前時刻是否有任務到達到達則進入就緒隊列 while (taskIndex taskCount tasks[taskIndex].arriveTime clock) { tasks[taskIndex].status READY; appendReady(tasks[taskIndex]); taskIndex; } // 第二步CPU 空閑且有就緒任務時按策略選一個執(zhí)行 if (running NULL readyCount 0) { running selectTask(clock, policy); if (running-startTime -1) running-startTime clock; running-status RUNNING; } // 第三步當前任務執(zhí)行一個節(jié)拍 if (running ! NULL) { running-remainTime--; if (running-remainTime 0) { running-finishTime clock 1; // 完成時刻是下一拍 running-status FINISHED; running NULL; // 釋放 CPU } else if (policy POLICY_RR (clock 1) % timeSlice 0) { // 時間片耗盡任務回到就緒隊列尾部 running-status READY; appendReady(running); running NULL; } } }這段循環(huán)有三個容易寫錯的地方資源里的實現(xiàn)處理得比較到位。第一是到達檢查用的是 while 而不是 if因為同一時刻可能多個任務一起到達第二是搶占語義SJF 和優(yōu)先級調(diào)度如果在非搶占模式下running 為 NULL 才發(fā)生調(diào)度而搶占式優(yōu)先級需要在第二步之前先判斷「新到達的任務是否比當前任務的優(yōu)先級更高」資源默認是非搶占版本改搶占只需在第二步前加一段比較邏輯第三是 finishTime 的計算任務在 clock 這一拍執(zhí)行完它的完成時刻應該是 clock 1這是時間軸左閉右開的結(jié)果很多初版實現(xiàn)在這里少加 1導致周轉(zhuǎn)時間整體偏小我當年就在這上面翻過車。3.4 二叉堆SJF 與優(yōu)先級調(diào)度共用的「最優(yōu)先」底座selectTask 函數(shù)內(nèi)部根據(jù) policy 分流SJF 和優(yōu)先級調(diào)度走的是同一個小根堆區(qū)別只在于堆節(jié)點比較的 key 是什么// 小根堆上浮新元素從底部向上調(diào)整到合適位置 void heapPush(PriorityQueue* q, TCB* task, int keyType) { q-data[q-size] task; int cur q-size; while (cur 0) { int parent (cur - 1) / 2; int curKey getKey(q-data[cur], keyType); int parentKey getKey(q-data[parent], keyType); if (parentKey curKey) break; // 父節(jié)點更小停止上浮 swap(q-data[cur], q-data[parent]); cur parent; } } // 小根堆下沉堆頂取出后把最后一個元素放到根部調(diào)整 TCB* heapPop(PriorityQueue* q) { if (q-size 0) return NULL; TCB* top q-data[0]; q-data[0] q-data[--q-size]; int cur 0; while (true) { int left cur * 2 1, right cur * 2 2; int smaller cur; if (left q-size getKey(q-data[left], q-keyType) getKey(q-data[smaller], q-keyType)) smaller left; if (right q-size getKey(q-data[right], q-keyType) getKey(q-data[smaller], q-keyType)) smaller right; if (smaller cur) break; swap(q-data[cur], q-data[smaller]); cur smaller; } return top; }邏輯說明getKey 是個小工具函數(shù)keyType 為 1 時返回 serviceTimekeyType 為 2 時返回 priority這樣同一套堆代碼同時服務 SJF 和優(yōu)先級調(diào)度只改比較的字段不復制代碼。push 的上浮過程和 pop 的下沉過程都是標準的堆調(diào)整時間復雜度 O(log n)。這里有個課設答辯時值得講的細節(jié)SJF 和優(yōu)先級調(diào)度都需要在任務到達時把任務插入堆每次調(diào)度時從堆頂取最值如果就緒隊列用鏈表做每次取最值都是 O(n) 的全表掃描用堆之后整體復雜度從 O(n2) 降到 O(n log n)case3 里幾百個任務的樣本能直觀看到運行耗時差異。4. 編譯運行與結(jié)果驗證三條命令跑出四種算法的對比數(shù)據(jù)到了實操環(huán)節(jié)。這份資源自帶的 Makefile 已經(jīng)處理好了頭文件依賴和編譯參數(shù)理論上你只需要在命令行執(zhí)行三個動作就能看到輸出結(jié)果但我會把每一步背后的含義也說明白這樣出問題時你知道去哪里排查。4.1 編譯與運行命令行 Makefile 與 IDE 兩種姿勢cd TaskScheduler make clean make ./scheduler data/case1.txt 0 1參數(shù)說明第一個參數(shù)是測試數(shù)據(jù)文件路徑第二個參數(shù)是調(diào)度策略編號0FCFS1SJF2優(yōu)先級3RR第三個參數(shù)是時間片大小只在策略為 3 時生效其他策略下會被忽略。Makefile 里默認了 g 編譯標準為 C11編譯選項帶上 -Wall 打開全部警告課設階段把警告當錯誤處理能幫你避開不少隱式類型轉(zhuǎn)換和未初始化變量的問題。如果你習慣用集成開發(fā)環(huán)境也可以把 src 目錄下所有 .cpp 文件加入工程頭文件路徑指向 src然后直接編譯 main.cpp效果完全一樣。我一般建議先用命令行跑通一次因為 Makefile 把整個構(gòu)建過程透明化了出錯了能看到具體是哪個文件哪個函數(shù)的問題IDE 反而把編譯細節(jié)藏起來了。跑完之后終端會先打印一張文本形式的甘特圖用豎線分隔時間軸和任務編號然后打印每個任務的到達時間、開始時間、完成時間、周轉(zhuǎn)時間、帶權周轉(zhuǎn)時間最后是四項平均值。case1 只有 5 個任務你可以拿紙筆手動推一遍 FCFS 的結(jié)果跟程序輸出比對如果一致說明工程本身沒問題后面換算法和數(shù)據(jù)就是參數(shù)的事。4.2 輸入文件格式任務描述文件的字段約定data 目錄下的 txt 文件格式非常直白第一行是任務總數(shù)從第二行開始每行四個整數(shù)分別對應 TCB 里的 pid、arriveTime、serviceTime、priority5 1 0 8 3 2 2 5 1 3 3 1 4 4 6 4 2 5 8 2 5字段順序和 tcb.h 里的聲明順序保持一致loadTasks 用 fscanf 按 %d 逐個讀取遇到文件提前結(jié)束會自動報錯并返回 false。這里有個坑要提醒priority 數(shù)值越小代表優(yōu)先級越高這是資源里統(tǒng)一的約定如果你自己造測試數(shù)據(jù)時把數(shù)值大小關系搞反優(yōu)先級調(diào)度的結(jié)果會完全反過來。另外到達時間可以不從 0 開始也不必嚴格遞增但同一個任務的到達時間不能晚于它自己的完成時間否則算出來的周轉(zhuǎn)時間是負數(shù)這是邏輯上就不合法的數(shù)據(jù)。4.3 結(jié)果驗證周轉(zhuǎn)時間、帶權周轉(zhuǎn)時間、甘特圖怎么對得上程序輸出的統(tǒng)計指標是課設報告的核心數(shù)據(jù)也是答辯時老師最可能追問的部分Task 1: arrive0 start0 finish8 turnaround8 weighted1.00 Task 2: arrive2 start8 finish13 turnaround11 weighted2.20 Task 3: arrive3 start13 finish14 turnaround11 weighted11.00 Average turnaround time: 10.00 Average weighted turnaround time: 3.55公式說明周轉(zhuǎn)時間 finishTime - arriveTime表示任務從到達系統(tǒng)到執(zhí)行完成經(jīng)歷的總時間帶權周轉(zhuǎn)時間 周轉(zhuǎn)時間 / serviceTime衡量的是「等待時間被放大了多少倍」短作業(yè)如果被長作業(yè)堵在后面這個值會非常大所以它是評估調(diào)度算法公平性的關鍵指標。案例里 Task 3 運行時間只有 1 個節(jié)拍卻等了 10 拍才執(zhí)行完帶權周轉(zhuǎn)時間沖到 11這就是典型的短作業(yè)吃虧場景也是 SJF 能顯著改善的指標。你可以用程序輸出跟手算結(jié)果對一遍如果 FCFS 下對不上先檢查 finishTime 是不是按 clock 1 計的再檢查同一時刻多個任務到達時的入隊順序是否穩(wěn)定。5. 避坑指南課程設計與真實調(diào)度器之間的四個經(jīng)典翻車點這一章寫的是我在調(diào)試這類模擬器時遇到過的真實問題也是答辯時老師愛挖的坑。每一條都是「現(xiàn)象 → 原因 → 解決」的結(jié)構(gòu)你在跑通之后拿自己的測試數(shù)據(jù)去觸發(fā)一遍會比只看代碼理解得更深。5.1 新任務到達瞬間正在運行的任務沒讓出 CPU現(xiàn)象使用搶占式優(yōu)先級調(diào)度時明明 4 個任務運行時間都不長運行結(jié)果里卻出現(xiàn)了一個高優(yōu)先級任務被低優(yōu)先級任務壓在后面執(zhí)行的怪異序列。 原因調(diào)度主循環(huán)只有在 running NULL 時才調(diào) selectTask 選新任務新任務到達只是被放進了就緒隊列沒有在當下立即觸發(fā)一次搶占判斷。資源默認實現(xiàn)的是非搶占式調(diào)度搶占邏輯缺失。 解決在檢查新任務到達之后、執(zhí)行當前任務之前增加一個搶占判斷分支如果新任務 priority 比 running 的 priority 更小就把 running 放回就緒隊列并置空讓下一拍重新 selectTask。注意搶占的粒度是「一個完整時鐘節(jié)拍」新任務最早只能從下一拍開始執(zhí)行不能在同一拍內(nèi)完成切換。5.2 SJF 的饑餓問題被固定測試數(shù)據(jù)掩蓋現(xiàn)象case1 和 case2 跑 SJF 時一切正常但你自己生成一組「一個大長任務 若干個持續(xù)到達的短任務」的數(shù)據(jù)后發(fā)現(xiàn)長任務遲遲無法完成最后被迫地反復被短任務插隊。 原因SJF 每次選擇剩余運行時間最短的任務如果短任務源源不斷到達長任務永遠選不上這就是經(jīng)典的饑餓現(xiàn)象。課程設計通常不會用極端數(shù)據(jù)測試但答辯老師一定會問「SJF 的缺點是什么」。 解決工程里 SJF 用的是不可搶占版本已經(jīng)能緩解一部分問題真要做改進可以改成 HRRN最高響應比優(yōu)先響應比 等待時間 運行時間/ 運行時間它天然兼具 SJF 的短作業(yè)優(yōu)先和 FCFS 的防饑餓特性改造成本只在 selectTask 里多算一個比值代碼量很小但答辯效果很好。5.3 時間片輪轉(zhuǎn)的完成時間多算一拍現(xiàn)象RR 策略下一個任務明明運行了 5 拍服務時間也是 5打印出來的 finishTime 卻比預期大了 1周轉(zhuǎn)時間整體偏大。 原因把完成任務的那一拍直接寫成了 running-finishTime clock忽略了時鐘節(jié)拍是左閉右開區(qū)間——任務在第 clock 拍執(zhí)行完完成時刻應該是 clock 1。同理時間片耗盡判斷寫成 clock % timeSlice 0 也會錯一拍。 解決統(tǒng)一用 clock 1 作為完成時刻時間片耗盡判斷用 (clock 1) % timeSlice 0。寫完用 serviceTime 只有 1 的任務做最小測試它的 finishTime 必須等于 arriveTime 1這個用例能一秒暴露問題。5.4 多任務同時到達時就緒隊列的插入順序不穩(wěn)定現(xiàn)象兩份結(jié)構(gòu)相同、只有任務編號順序不同的測試數(shù)據(jù)在 FCFS 下跑出的甘特圖不一致某些任務的前后關系發(fā)生了對調(diào)。 原因loadTasks 按文件順序把任務讀入數(shù)組而調(diào)度主循環(huán)里檢查到達用的是 while (arriveTime clock)同一時刻到達的任務入隊順序取決于它們在這個時刻的檢查順序如果文件的寫入順序和任務編號順序不一致數(shù)組遍歷順序也會變鏈表尾插結(jié)果就會不同。 解決在 loadTasks 讀完后對 tasks 數(shù)組按 arriveTime 做一次穩(wěn)定排序相同到達時間的任務保持編號升序或者把 appendReady 改成按 pid 二次比較插入。穩(wěn)定的入隊順序是結(jié)果可復現(xiàn)的前提否則你寫報告時換一份數(shù)據(jù)格式前后兩組實驗就對不上了。6. 二次開發(fā)把「一次讀入全部任務」改成「運行時動態(tài)注入」的交互式調(diào)度器循環(huán)結(jié)構(gòu)的調(diào)度器最大的限制是任務集合在開始時就被定死時鐘循環(huán)只能消費已經(jīng)讀入的數(shù)組。如果你想讓這個課設更有區(qū)分度我建議把它改成交互式版本不再是加載完整文件后一口氣跑完而是每到一個時鐘節(jié)拍先從文件或標準輸入讀入新到達的任務再決定誰執(zhí)行。改造的核心是把「提前讀入數(shù)組」變成「邊跑邊讀」。具體做法是在 main 里維護一個輸入流runScheduler 的循環(huán)每推進一拍就嘗試從輸入流讀一行任務讀到就按 TCB 初始化并加入就緒隊列。原先 loadTasks 的批量解析可以保留為「預置數(shù)據(jù)」模式新增一個 -i 參數(shù)interactive走動態(tài)注入路徑// 交互式注入每個時鐘節(jié)拍調(diào)用一次有新任務就返回 true bool tryInjectTask(FILE* fp, TCB tasks[], int taskCount, int clock) { TCB temp; if (fscanf(fp, %d %d %d %d, temp.pid, temp.arriveTime, temp.serviceTime, temp.priority) ! 4) return false; if (temp.arriveTime clock) { // 只接收當前時刻的任務 temp.remainTime temp.serviceTime; temp.startTime temp.finishTime -1; temp.status READY; tasks[taskCount] temp; appendReady(tasks[taskCount - 1]); } return true; }改造完成后驗證方法也很直接先用原來的 case1 跑非交互模式再用交互模式逐個注入同樣的 5 個任務兩條路徑的輸出必須完全一致這個對拍實驗能證明你的動態(tài)注入沒有改變調(diào)度語義。之后再設計一個「運行期間臨時追加任務」的場景觀察追加任務的到達時間是否被正確插入到時間軸中。這個改造不僅讓課設從「靜態(tài)演示」升級成了「動態(tài)系統(tǒng)」答辯時還能順帶引出「任務預熱、批量到達」等真實系統(tǒng)話題遠比念報告有說服力。從那以后我每次拿到一份課設工程都會先花半小時把「入口參數(shù)、模塊邊界、輸出口徑」三個問題畫清楚再動手改這個習慣幫我少踩了很多坑。希望幫到你。本文還有配套的精品資源點擊獲取