簡介面向大二學生數據結構課程設計基于C/C實現的任務調度器系統(tǒng)覆蓋任務隊列、調度模塊與交互主程序適合需要完成同類選題、理解隊列結構與任務管理流程的學生參考。壓縮包共38個文件大小約40.97MB包含VS2019解決方案、C源碼、任務隊列與調度管理相關頭文件、測試主程序、可直接運行的exe以及pdb、obj、tlog等編譯調試產生的中間文件工程目錄清晰解壓后用Visual Studio 2019打開即可復現運行效果。已有207名學生學習下載說明該選題在課程設計場景中具備一定代表性。通過該項目可以完整走一遍任務調度器的設計實現過程掌握任務隊列構建、任務狀態(tài)維護、調度策略設計等核心思路也能借鑒其模塊劃分、工程組織方式和類圖設計便于快速改寫成自己的課程設計代碼、報告與答辯材料。1. 任務調度器這件課設為什么值得認真做很多人拿到任務調度器這個題目的第一反應是去翻操作系統(tǒng)里的進程調度算法結果發(fā)現課設要求的是用數據結構去模擬調度過程而不是真的實現一個操作系統(tǒng)調度內核。先來先服務要排隊短作業(yè)優(yōu)先要快速找出最小服務時間時間片輪轉要環(huán)形取任務這背后對應的是隊列、優(yōu)先隊列和循環(huán)隊列的設計與編碼能力。正因為如此它才成為數據結構課程設計里最常被選中的題目之一——題目不大但能同時考到結構體、指針、堆、隊列和排序穩(wěn)定性。這份方案面向正在準備數據結構課程設計的學生也面向想快速理清任務調度器完整實現思路的開發(fā)者給出的是從需求分析、數據結構選型、模塊劃分到C語言核心實現的一整套可落地參考。適合拿來做C/C課設的藍本也適合在答辯時應對你為什么要這樣設計的追問。2. 需求分析與技術選型先確定調度規(guī)則再決定用堆還是隊列2.1 課設任務書里最容易被忽略的四個需求點先別急著寫代碼我會把任務書拆成四個必答項。第一必須支持的調度算法。常見組合是FCFS先來先服務、SJF短作業(yè)優(yōu)先、RR時間片輪轉三種部分題目還會要求動態(tài)優(yōu)先級調度。第二任務輸入方式。多數要求從文件或控制臺讀入任務列表每條任務包含任務ID、到達時間和服務時間。第三結果輸出。通常要求打印調度順序、每個任務的開始時間、完成時間、等待時間、周轉時間以及平均周轉時間。第四邊界行為。比如兩個任務同時到達、服務時間相同、任務到達時間錯峰這些場景決定了算法能否正確處理排序穩(wěn)定性。以最常見的輸入文件為例5 T1 0 8 T2 1 4 T3 2 9 T4 3 5 T5 4 2第一行是任務總數之后每行依次是任務ID、到達時間、服務時間。表面上簡單但隱含了一個容易漏掉的需求任務不是一開始全部到達調度器必須在current_time小于下一個任務到達時間時等待。我一般會在需求分析里專門寫一條支持任務錯峰到達這樣設計就完整了。需求分析還會直接影響編碼邊界。比如如果任務書要求輸出每個任務的開始時間那Task里還需要記錄start_time如果要求支持任務隨機生成那么輸入層就要加一個生成器函數。很多同學拿到題就開寫寫著發(fā)現字段不夠用又回頭改結構體來回浪費一個下午。我通常的做法是先在紙上畫一個輸入的樣例、一個輸出的樣例把字段對齊了再動鍵盤。2.2 數據結構選型優(yōu)先隊列、普通隊列和數組各司其職任務調度器的核心數據結構是就緒隊列但不同算法對隊列的要求彼此沖突。FCFS只需要先進先出用循環(huán)隊列即可SJF每次要選出服務時間最短的任務用最小堆最合適RR要按順序循環(huán)取任務本質上又是循環(huán)隊列。如果只用數組加排序硬扛每來一個新任務就重新全排序代碼難寫且復雜度高更重要的是答辯時說不清楚為什么用這個結構。因此在完整方案里我會同時實現兩個就緒容器一個二叉堆用于SJF和優(yōu)先級調度一個循環(huán)隊列用于FCFS和RR。二者都以Task指針為元素通過相同的隊列接口操作。下面這個表是我放在課設報告里的選型對比數據結構適用算法核心操作時間復雜度循環(huán)隊列FCFS / RR入隊、出隊、判空O(1)二叉堆最小堆SJF / 優(yōu)先級調度插入、取最小、堆化O(log n)數組全部算法存儲原始任務、按id索引O(n)有一點需要特別說明SJF里的最短是指服務時間最小當服務時間相等時按到達時間排序。這就要求堆的比較函數不是只看service_time而是先比service_time再比arrive_time否則兩個服務時間相同的任務順序可能與手算結果不一致。這是后面的避坑章節(jié)里最容易翻車的一個點。在這個選型階段還有一個容易被當成玄學的點為什么時間片輪轉也要用隊列而不是鏈表。鏈表插入刪除雖然方便但循環(huán)隊列在固定大小任務數組的課設場景下更簡單不需要頻繁malloc/new。如果任務數上限已知預分配一個MAX_TASKS容量的數組用head和tail兩個下標維護隊列幾乎沒有內存管理負擔。鏈表方案可以作為加分項寫在擴展思考里但核心代碼用循環(huán)隊列更容易講。2.3 用C還是C封裝與調試成本的權衡如果允許自由選擇語言我會優(yōu)先用C而不是C。原因有三第一C的結構體和指針能直觀展示任務節(jié)點、堆、隊列之間的關系答辯老師很容易看出你掌握的程度第二C的STL會把priority_queue、queue這些容器都包裝好代碼量少了但老師一句你講講最小堆的堆化過程就可能答不上來第三C程序用gdb調試堆數組和隊列更透明每次push/pop后都能直接查看data數組的順序。如果你更習慣C也可以用class封裝Scheduler和Task但必須自己管理析構和拷貝避免淺拷貝導致指針重復釋放。這個方案里給出的代碼以C語言為基準同時在注釋里標注了C改進點。我這里建議課設代碼控制在三個源文件main.c負責流程控制scheduler.c負責算法實現task_queue.c負責堆與隊列的操作。模塊清晰答辯時分頭講解很從容。選型確定后下一步需要把數據結構封裝成統(tǒng)一接口讓調度算法不感知底層是堆還是隊列。比如我定義一組入隊、出隊、判空函數堆和循環(huán)隊列都實現同一套函數名內部各自維護自己的存儲方式。這樣的抽象能讓后續(xù)切換算法時只改動一行設置代碼也為第3章的總體架構設計做了鋪墊。3. 總體架構設計三層結構與五類模塊的職責劃分3.1 頂層分層輸入層、調度核心層、輸出層任務調度器整體采用三層結構。輸入層負責解析任務文件、校驗數據比如任務數不能為0、服務時間不能為負數、時間片必須大于0等。調度核心層維護任務狀態(tài)機和三個調度算法這一層不關心數據是從文件還是控制臺來的。輸出層負責打印調度順序和統(tǒng)計指標。這樣的好處是算法切換不會影響輸入輸出新增算法時只需要在核心層添加一個函數。在課設報告里我會用一個模塊劃分表來說明模塊文件職責關鍵結構/函數main.c解析命令行參數、組織流程Scheduler結構體task_queue.c循環(huán)隊列與最小堆的操作enqueue、dequeue、heap_push、heap_popscheduler.c三種調度算法的狀態(tài)推進scheduler_fcfs / sjf / rroutput.c打印調度順序、計算統(tǒng)計量print_schedule、calc_avgmain函數中先用load_tasks()讀取任務數組再根據命令行參數創(chuàng)建Scheduler調用scheduler_run()最后調用print_result()。我會特別在main函數里保留一個打印中間狀態(tài)的開關調試時開啟答辯演示時關閉。在三層結構的邊界上我還會留一個hook點調度核心層只暴露一個scheduler_run()接口和一個scheduler_set_algorithm()設置函數。這樣main.c無需關心算法內部是用了堆還是隊列如果日后想支持動態(tài)優(yōu)先級搶占只需在Scheduler里增加一個priority字段并在比較函數中增加一條判斷即可。這種設計看似多寫幾行代碼但在答辯中被問到可擴展性時就能拿出實際的函數接口來證明而不是只說思路。3.2 任務狀態(tài)機新建、就緒、運行、完成任務不能共享同一塊隊列就完事每個任務都有自己的生命周期。我給Task設計一個state字段枚舉值分別代表NEW新建、READY就緒、RUNNING運行、FINISHED完成。調度流程是這樣的所有任務初始都是NEW當current_time推進到某個任務的到達時間時把它插入就緒隊列并置為READY調度器從就緒隊列取一個任務置為RUNNING并運行任務運行完成后置為FINISHED。以RR舉例任務T1第一次被調度時state由1變?yōu)?運行一個時間片未完成state回到1并插入隊尾等第二次出隊再次變?yōu)?運行完畢才變?yōu)?。如果沒有這中間一次READY回縮任務就可能在第二次被取出時還被當作RUNNING導致調度器認定它還在運行而不重新分配。狀態(tài)機把這個問題轉化成了簡單的枚舉判斷代碼里一眼能看清。這個狀態(tài)機最大的價值是避免重復入隊。RR算法里一個任務執(zhí)行完一個時間片但沒結束會被放回隊尾此時它的狀態(tài)應該是READY而不是RUNNING而一個已經FINISHED的任務如果因為下標判斷失誤再次被掃描到就會重復入隊。有了state每次入隊前檢查一下不是READY和RUNNING就能提前攔住錯誤。3.3 調度核心模塊統(tǒng)一接口與三個算法的策略選擇調度核心層我不會寫成三個相互獨立的大函數而是定義一個Scheduler結構體來統(tǒng)一管理typedef struct { int algorithm; /* 0-FCFS 1-SJF 2-RR */ int time_slice; /* RR使用 */ int current_time; Task *tasks; int task_count; int finished_count; } Scheduler;然后提供一個scheduler_run()入口內部通過switch調用不同的調度函數。每個調度函數只負責把task的finish_time寫好不直接打印結果。這樣統(tǒng)計模塊永遠從finish_time字段取數不會因為全局變量被改而算錯。使用統(tǒng)一接口還有一個微觀好處統(tǒng)計模塊在調度完成后遍歷任務數組不需要知道剛才跑的是哪個算法。算法的選擇只影響每個任務的finish_time不影響后續(xù)計算。這也讓main.c的代碼量大幅減少從開始到讀入參數再到輸出結果不超過60行。三種算法的推進邏輯分別是FCFS按到達順序入隊任務執(zhí)行完才讓出CPUSJF每步從最小堆堆頂取任務同樣不可搶占RR每個任務最多運行一個時間片沒做完就重新入隊尾部。對比來看SJF和FCFS都是運行到結束只是選擇順序不同RR才會在運行中途打斷。答辯時我會主動說出這個區(qū)別表明算法并不是簡單換排序。3.4 統(tǒng)計指標模塊周轉時間、等待時間與平均數的計算課程設計通常要求輸出平均周轉時間所以統(tǒng)計模塊要獨立于調度模塊。每個任務調度完成后只記錄finish_time統(tǒng)計時再統(tǒng)一計算周轉時間 finish_time - arrive_time等待時間 周轉時間 - service_time帶權周轉時間 周轉時間 / service_time。平均周轉時間則是所有任務周轉時間之和除以任務數。這里有一個容易踩坑的細節(jié)打印帶權周轉時間時如果用整數除法9/8會變成1而不是1.12。我會用浮點數保存結果printf保留兩位小數。另外當任務服務時間為0時帶權周轉時間會做除零運算我在輸入校驗里直接禁止服務時間小于等于0從根上規(guī)避掉這個黑匣子問題。輸出格式我建議用表格對齊方式比如每行打印任務ID、到達時間、服務時間、完成時間、周轉時間、帶權周轉時間。最后單獨一行打印平均周轉時間和平均帶權周轉時間。這樣的打印結果可以直接貼進課程設計報告不需要再手工整理。4. 關鍵實現堆、隊列與三種調度算法的落地代碼4.1 任務結構體與最小堆的實現代碼從Task定義開始typedef struct Task { int id; /* 任務ID從1開始 */ int arrive_time; /* 到達時間 */ int service_time; /* 服務時間 */ int done_time; /* 已經運行的時間RR用 */ int finish_time; /* 完成時間 */ int state; /* 0新建 1就緒 2運行 3完成 */ } Task;就緒容器我采用兩個獨立結構體的方案先看最小堆typedef struct PQueue { Task *data[MAX_TASKS]; /* 存儲任務指針 */ int size; /* 堆中元素個數 */ } PQueue; void heap_push(PQueue *h, Task *t) { int i h-size; h-data[i] t; while (i 0) { int p (i - 1) / 2; if (compare(h-data[i], h-data[p]) 0) { Task *tmp h-data[i]; h-data[i] h-data[p]; h-data[p] tmp; i p; } else { break; } } } Task *heap_pop(PQueue *h) { Task *top h-data[0]; h-data[0] h-data[--h-size]; int i 0; while (1) { int l 2 * i 1, r 2 * i 2, smallest i; if (l h-size compare(h-data[l], h-data[smallest]) 0) smallest l; if (r h-size compare(h-data[r], h-data[smallest]) 0) smallest r; if (smallest i) break; Task *tmp h-data[i]; h-data[i] h-data[smallest]; h-data[smallest] tmp; i smallest; } return top; }這段代碼的邏輯是heap_push從數組末尾上浮heap_pop先將堆頂與末尾元素交換并下沉正好對應堆的兩個核心操作。MAX_TASKS采用宏定義如#define MAX_TASKS 100避免動態(tài)擴容引出的指針失效問題。compare函數是優(yōu)先級判定的核心int compare(Task *a, Task *b) { if (a-service_time ! b-service_time) { return a-service_time - b-service_time; } return a-arrive_time - b-arrive_time; }返回值小于0表示a應排在b前面。這與普通排序的cmp函數保持一致。很多同學在這里會犯方向性錯誤寫成b-service_time - a-service_time導致最小堆變成最大堆這是最典型的翻車點。4.2 FCFS與SJF調度實現FCFS采用循環(huán)隊列這里給出調度主體的最簡版void scheduler_fcfs(Scheduler *sched) { CQueue q; init_queue(q); int next 0; while (sched-finished_count sched-task_count) { while (next sched-task_count sched-tasks[next].arrive_time sched-current_time) { sched-tasks[next].state 1; enqueue(q, sched-tasks[next]); next; } if (is_empty(q)) { sched-current_time; continue; } Task *t dequeue(q); t-state 2; t-finish_time sched-current_time t-service_time; sched-current_time t-finish_time; t-state 3; sched-finished_count; } }注意兩個細節(jié)第一個while負責把到點的新任務放入隊列第二個if用于處理隊列為空且任務尚未全部到達的情況這時current_time逐秒推進會稍慢但邏輯最簡單。如果追求效率可以直接跳到下一個任務的到達時間但仍要處理下一個任務也沒到齊的邊界。SJF與FCFS的結構非常像只是把循環(huán)隊列換成最小堆取任務時從堆頂取void scheduler_sjf(Scheduler *sched) { PQueue h; h.size 0; int next 0; while (sched-finished_count sched-task_count) { while (next sched-task_count sched-tasks[next].arrive_time sched-current_time) { sched-tasks[next].state 1; heap_push(h, sched-tasks[next]); next; } if (h.size 0) { sched-current_time sched-tasks[next].arrive_time; continue; } Task *t heap_pop(h); t-state 2; t-finish_time sched-current_time t-service_time; sched-current_time t-finish_time; t-state 3; sched-finished_count; } }這段代碼與FCFS最大的區(qū)別在于兩處一是就緒容器由隊列變成堆二是隊列為空時不再用current_time而是直接跳躍到下一個任務的到達時間。跳躍寫法在SJF里更合理因為堆為空代表此刻沒有可執(zhí)行任務繼續(xù)逐秒加一不會改變堆中的內容。4.3 時間片輪轉RR的實現與隊尾回插RR需要維護每個任務已經運行的時間done_time時間片time_slice由命令行傳入。核心代碼void scheduler_rr(Scheduler *sched, int time_slice) { CQueue q; init_queue(q); int next 0; while (sched-finished_count sched-task_count) { while (next sched-task_count sched-tasks[next].arrive_time sched-current_time) { sched-tasks[next].state 1; enqueue(q, sched-tasks[next]); next; } if (is_empty(q)) { sched-current_time; continue; } Task *t dequeue(q); if (t-state 3) continue; /* 防御已完成任務不入隊 */ t-state 2; int need t-service_time - t-done_time; int run_time need time_slice ? time_slice : need; t-done_time run_time; sched-current_time run_time; if (t-done_time t-service_time) { t-state 1; enqueue(q, t); /* 沒做完放回隊尾 */ } else { t-finish_time sched-current_time; t-state 3; sched-finished_count; } } }這段代碼里最關鍵的是回插動作任務每輪只能運行一個時間片如果還沒完成done_time加滿當前時間片后重新入隊。需要特別注意的是回插的任務不能被重復計算到達時間所以next指針只負責新到達任務回插直接走enqueue隊列尾部。防御性的state3判斷是血淚經驗曾經有同學在任務完成瞬間又被調度器取出就是因為狀態(tài)沒有置為完成。4.4 命令行參數與運行配置為了讓課設更完整我會讓程序支持命令行參數./scheduler -a sjf -t input.txt -o result.txt -q 2各參數含義如下表參數說明默認值-a調度算法fcfs/sjf/rrfcfs-t任務文件路徑input.txt-o結果輸出文件stdout-q時間片大小RR2main函數中用getopt解析參數并用switch判斷算法。文件不存在或參數非法時打印輸入文件不存在不直接崩潰。這樣設計的好處是演示時可以在答辯現場用同一份任務文件分別跑三種算法對比輸出效果比只看代碼好得多。參數表可以放在設計文檔中代碼里只需要一個結構體SchedConfig來保存。5. 常見問題與避坑指南五個最容易翻車的地方任務調度器這個課設代碼量不大但翻車點很集中。我見過的模擬項目里十個同學有七八個都卡在下面這幾類問題上。這里按現象→原因→解決的順序整理方便你在答辯前快速自查。5.1 比較函數方向寫反最短任務反而最后執(zhí)行現象SJF調度輸出里服務時間最短的任務出現在序列最后運行時間反而像最長作業(yè)優(yōu)先。 原因最小堆的compare返回值語義與預期相反。我見過很多初學者寫compare時參考qsort的寫法結果在堆的siftDown里又套了一層balance 0的符號翻轉負負得正。 解決統(tǒng)一約定compare(a,b) 0 表示 a 優(yōu)先級高于 b堆頂永遠存放compare值最小的元素。寫完compare后先把三個任務服務時間6、2、4按順序插入堆再全部彈出檢查是否得到2、4、6。這個測試只需10秒能避免后面所有算法結果錯亂。我一般會在單元測試代碼里直接寫上這個用例作為回歸檢查。5.2 時間片輪轉里任務重復入隊程序死循環(huán)現象RR運行到某個任務后發(fā)現它被調度了兩次或者printf刷屏不斷執(zhí)行同一個任務。 原因任務已經完成但狀態(tài)沒有置為FINISHED或者調度器在新到達任務掃描時重復處理了已經入隊的任務。 解決強制使用任務狀態(tài)機入隊前檢查state是否為NEW或FINISHED。更直接的防御是在調度器入口加一個斷言if (t-state 3) continue;同時維護一個next下標只掃描尚未入隊的新任務禁止每輪都從頭遍歷整個任務數組。這兩種手段疊加后重復入隊基本被根除。5.3 任務錯峰到達時程序卡在空隊列等待現象用全是0時刻到達的測試數據一切正常換成錯峰到達后程序要么長時間無輸出要么直接跳過任務。 原因調度器在隊列為空時沒有處理下一個任務還沒到達的情況。FCFS里用current_time能僥幸跑通但SJF里如果也這么做遇到下一個任務到達時間跨度很大程序會做大量無效循環(huán)觀感上像死機。 解決隊列為空時直接把current_time跳到下一個待入隊任務的到達時間。SJF代碼里的sched-current_time sched-tasks[next].arrive_time;就是這個用途。需要注意的是跳躍前要確保next下標有效也就是next task_count。否則說明所有任務都已經處理完這本來也是退出循環(huán)的條件。5.4 動態(tài)分配產生的野指針和內存泄漏現象程序測小數據正常加到50個任務后偶發(fā)崩潰或者使用valgrind檢查時發(fā)現一堆invalid read。 原因Task數組用malloc動態(tài)分配而隊列data數組里保存的是Task指針當任務數組被realloc擴容時舊指針全部失效。這是最典型的野指針來源。 解決課程設計場景下直接在棧上定義固定大小數組Task tasks[MAX_TASKS];并先讀入任務數再檢查是否超過MAX_TASKS。如果一定要動態(tài)分配就一次性malloc最大任務數不要做realloc。對于隊列中的指針只要任務數組地址不變指針始終有效。檢查泄漏時在gdb或valgrind下跑一遍完整測試會大大降低翻車概率。5.5 輸出結果與手算不一致平均周轉時間算錯現象調度順序看起來對但平均周轉時間比手算大很多或者帶權周轉時間出現1.00這種明顯不合理的數值。 原因統(tǒng)計時用全局current_time而不是任務自身的finish_time。由于RR會反復切換任務某個任務完成時current_time可能已經被后續(xù)任務推進過直接用當前時間減到達時間必然出錯。 解決在任務完成時就把t-finish_time記錄好統(tǒng)計模塊只從finish_time字段取值。打印前先逐個輸出每個任務的arrive_time、finish_time、周轉時間與手算表逐項比對。這里我踩過一個坑帶權周轉時間用整數除法9/8算成1后來全部改成double輸出加上%.2f結果才正常。6. 驗收與答辯把課設做到能演示、能講透6.1 功能驗收清單在提交前我會用一個包含5個任務、3種算法的測試文件跑完整流程并對照手算結果。下表是最低驗收標準檢查項通過標準輸入解析能正確讀取文件非法參數給出提示不崩潰FCFS調度順序與手算完全一致SJF最短任務最先執(zhí)行服務時間相同時按到達順序RR每個任務每個時間片只運行一次回插正確統(tǒng)計平均周轉時間、平均帶權周轉時間保留兩位小數魯棒性任務數0、時間片0、文件不存在均能友好退出6.2 答辯演示流程答辯時只講三條主線需求、選型、驗證。先花半分鐘說這個課設解決的問題是讓一組任務在三種調度策略下得到不同的執(zhí)行序列并量化對比再用同一組數據分別跑FCFS、SJF、RR指著輸出說SJF的平均周轉時間比FCFS低因為短任務優(yōu)先完成。最后結合代碼解釋為什么要用堆——SJF每次取任務需要O(log n)如果改用順序查找整體復雜度就到O(n2)。老師如果要你展示代碼優(yōu)先展示compare函數和RR的回插邏輯這兩個點最能體現出對數據結構的理解。演示前準備一頁打印紙左側輸入、右側三個算法的輸出老師提問時不會因為現場敲命令而冷場。如果時間充裕可以點亮一個debug模式開關打印每個時間片的就緒隊列內容這會讓演示顯得很扎實。這套完整的課程設計資源包含可編譯運行的C源碼、任務生成與測試用例、設計文檔框架和答辯PPT提綱拿到后可以直接對照修改。建議在動筆寫報告前先跑通功能再回頭整理文檔效率會高很多。我最初做模擬項目X時也曾在RR里把任務重復入隊調試到半夜翻車后來養(yǎng)成的習慣是每改一次算法先拿三個任務做手算再到程序里打印current_time和隊列內容比對。從那以后我每次做調度類的課程設計都會強制自己走一遍手算結果 → 程序輸出 → 差異分析的流程。希望這份方案能幫到你少踩幾個坑。本文還有配套的精品資源點擊獲取