簡介東北大學(xué)操作系統(tǒng)課程設(shè)計完整實現(xiàn)圍繞進程管理、內(nèi)存管理、文件系統(tǒng)與設(shè)備管理四大核心模塊展開適合計算機專業(yè)學(xué)生作為課設(shè)參考也可用于操作系統(tǒng)原理的實踐復(fù)習(xí)。資源共24個文件主體為21個C源文件覆蓋文件系統(tǒng)讀寫、目錄操作、內(nèi)存分配與回收、進程調(diào)度算法模擬等關(guān)鍵功能另附頭文件、可直接運行的FileSystem.exe以及課程設(shè)計報告docx壓縮包僅2.11MB便于下載與本地運行。目前已有280人學(xué)習(xí)使用代碼結(jié)構(gòu)清晰從create、open、read等基本接口到AllocDataBlock、ReleaseDataBlock等底層實現(xiàn)均有覆蓋配套報告包含需求分析、模塊劃分、關(guān)鍵函數(shù)說明與測試結(jié)果可幫助理解設(shè)計思路與算法選擇。讀者既能通過可執(zhí)行文件直觀觀察運行效果也能對照源碼深入拆解操作系統(tǒng)核心概念對鞏固理論知識、提升編程與調(diào)試能力都很有幫助。1. 項目定位一份能跑起來、也能講明白的操作系統(tǒng)課設(shè)源碼包操作系統(tǒng)課設(shè)最怕的不是寫不出代碼而是寫完被導(dǎo)師一問“你的時間片是怎么切”就卡殼。這份資源是一個某高校計科專業(yè)提交過的操作系統(tǒng)課程設(shè)計完整項目用 C 語言在用戶態(tài)模擬了一個微型操作系統(tǒng)進程調(diào)度、內(nèi)存管理、文件系統(tǒng)一個不少而且可運行、可統(tǒng)計、可改參數(shù)。你不需要買開發(fā)板也不需要碰 ARM 匯編只需要一臺帶 make 的 Linux 機器就能看到任務(wù)如何入隊、頁面如何被置換、文件如何寫入磁盤。它既能直接交作業(yè)也能當(dāng)理解操作系統(tǒng)原理的動手副本。下面我把它的架構(gòu)、核心代碼和改造思路拆開。2. 技術(shù)棧與整體架構(gòu)一個靠主循環(huán)撐起來的“偽內(nèi)核”這個項目沒有跑在真實硬件上它通過一個 while 循環(huán)模擬時鐘中斷每次循環(huán)代表一個 tick。這樣做的好處是可控性強課設(shè)答辯時可以單步調(diào)試肉眼看到狀態(tài)變化。完全由 C99 編寫依賴只有 libc 和 Makefile不需要 pthread不需要 ncurses移植成本很低。如果你想過為什么不用真實內(nèi)核答案很現(xiàn)實真實內(nèi)核的一行匯編就能卡住一整天而課程設(shè)計要的是一個能講清楚的 demo。2.1 技術(shù)選型為什么用 C 而不是 C 或 Python操作系統(tǒng)課設(shè)選語言通常不是語法問題是講原理的便利問題。同樣一個時間片輪轉(zhuǎn)Python 十行就寫完了但老師問你怎么操作內(nèi)存你只能說“列表切片”。換成 C 以后PCB 就是一個 struct隊列就是一個結(jié)構(gòu)體指針頁面就是一個數(shù)組下標這些概念全都能對著代碼指出來。這個項目堅持用 C99 的另一個原因是方便單步調(diào)試在 gdb 里可以看 ready_head 鏈表的每個節(jié)點甚至可以直接修改某個 PCB 的內(nèi)存。編譯環(huán)境也很樸素。Makefile 里只有兩條關(guān)鍵變量CC : gcc CFLAGS : -Wall -g -O0 -stdc99-Wall打開所有常見警告-g保留調(diào)試信息-O0禁止優(yōu)化否則單步調(diào)試時變量可能被優(yōu)化掉。這是課設(shè)項目最常見的配置建議不要在 CFLAGS 里加-O2代價是斷點里的值全部變成optimized out那種體驗接近玄學(xué)。那么為什么不用 pthread 做真實并發(fā)因為課設(shè)的主題是操作系統(tǒng)而操作系統(tǒng)本身是單 CPU 上多個進程輪流跑用單線程主循環(huán)模擬并發(fā)反而更貼近底層真實行為。一旦引入 pthread調(diào)度順序會被內(nèi)核線程調(diào)度器隨機化課設(shè)答辯時同一個用例跑兩次結(jié)果不同是給自己挖坑。因此項目所有模塊共用同一個current_tick全局變量由main的循環(huán)統(tǒng)一驅(qū)動徹底避免鎖競爭問題。2.2 目錄結(jié)構(gòu)三個子系統(tǒng)如何由 main 串起來整個工程按“主循環(huán) 子系統(tǒng)”的方式組織目錄不復(fù)雜。先看全貌ostrain/ ├── Makefile ├── README.md ├── src/ │ ├── main.c # 入口解析參數(shù)并驅(qū)動 tick 循環(huán) │ ├── pcb.c # 進程控制塊操作 │ ├── scheduler.c # 調(diào)度算法RR / 優(yōu)先級 │ ├── memory.c # 內(nèi)存分配與頁面置換 │ ├── filesystem.c # 虛擬磁盤與 inode 管理 │ └── shell.c # 簡單的命令口 ├── include/ │ └── ostrain.h # 公共結(jié)構(gòu)體、宏、函數(shù)聲明 └── test/ ├── 01_rr_test.txt # 時間片輪轉(zhuǎn)測試用例 └── 02_fs_test.txt # 文件讀寫測試用例src/main.c是唯一入口它負責(zé)解析命令行參數(shù)并啟動模擬scheduler.c、memory.c、filesystem.c是三個業(yè)務(wù)子系統(tǒng)相互之間通過ostrain.h里的公共結(jié)構(gòu)體通信shell.c提供最基礎(chǔ)的命令行接口用來動態(tài)創(chuàng)建進程或讀寫文件。這樣拆分的好處是想把調(diào)度器換成多級反饋隊列只改scheduler.c不影響內(nèi)存和文件系統(tǒng)。編譯和運行方式很直接make clean make ./ostrain --modeall --tick200參數(shù)說明--mode控制要運行哪個子系統(tǒng)可選process、memory、fs、all--tick指定模擬多少個時間片默認 100。比如只要看文件系統(tǒng)就跑./ostrain --modefs --tick50輸出會只保留與文件讀寫相關(guān)的日志。測試階段用--modeall最合適讓三個子系統(tǒng)在同一時間源下協(xié)同觀察它們是否互相干擾。提示如果你在 Windows 上開發(fā)建議用 WSL 或虛擬機裝 Ubuntu 跑原生的 mingw 環(huán)境在usleep和路徑分隔上可能有點小問題。macOS 也能跑但sleep_millis里的usleep需要包含unistd.h。工程里還留了make test目標它會在test/目錄外生成result/文件夾把三個模塊的輸出分別寫到result/process.log、result/memory.log、result/fs.log方便答辯時把日志拉出來和代碼對照。2.3 一次“時鐘中斷”的完整數(shù)據(jù)流所有模塊的聯(lián)動都發(fā)生在一次 tick 中。展開看一個 tick 內(nèi)的步驟是current_tick自增作為全局時間戳。scheduler_tick()檢查當(dāng)前進程時間片是否用完用完則換下一個。memory_tick()處理缺頁請求如果物理內(nèi)存不足就調(diào)用 LRU 淘汰一頁。filesystem_tick()把臟掉的磁盤塊延遲寫回虛擬磁盤。shell_collect(t)把當(dāng)前各模塊的狀態(tài)快照存進統(tǒng)計數(shù)組。這些步驟在main.c的run_simulation里是順序調(diào)用的// main.c 核心循環(huán)每個 tick 模擬一次時鐘中斷 void run_simulation(int ticks) { for (int t 0; t ticks; t) { current_tick t; scheduler_tick(); // 進程調(diào)度檢查時間片余量 memory_tick(); // 內(nèi)存管理處理缺頁或回收 filesystem_tick(); // 文件系統(tǒng)延遲寫回臟塊 shell_collect(t); // 收集當(dāng)前狀態(tài)做統(tǒng)計 sleep_millis(1); // 模擬時鐘周期便于觀察 } }邏輯說明每個函數(shù)都只讀當(dāng)前current_tick不做跨 tick 的等待。sleep_millis(1)是內(nèi)部封裝用usleep(1000)實現(xiàn)參數(shù)是毫秒數(shù)注釋里把它當(dāng)作“時鐘周期”實際調(diào)試時可以改成 10 毫秒讓輸出滾動慢一點。ticks來自命令行參數(shù)--tick控制模擬總時長。需要特別留意的是函數(shù)名中的tick和current_tick全局變量是兩個概念前者是動詞表示驅(qū)動一步后者是全局時間戳?xí)唤y(tǒng)計模塊用來生成時間序列。這種設(shè)計有一個容易被忽略的好處因為所有模塊都掛在同一個循環(huán)里打斷點時不會出現(xiàn)“調(diào)度器在某個線程里跑內(nèi)存管理在另一個線程里跑”的錯亂情況。答辯時你可以在循環(huán)體一行行執(zhí)行指著 PC 寄存器概念說“這里就是中斷返回后回到用戶態(tài)的位置”。當(dāng)然真實內(nèi)核里中斷是具有異步性的這個模擬項目刻意把它改成了同步循環(huán)目的是降低課設(shè)難度這一點在答辯準備時可以說清楚。另外shell_collect(t)會在統(tǒng)計數(shù)組里記錄每個進程的 finish_tick這是后期計算平均完成時間的唯一數(shù)據(jù)來源。統(tǒng)計數(shù)組也是一個全局 struct在ostrain.h里定義成固定大小最多支持 32 個進程超過之后會返回 ENOMEM這塊也做了簡化避免動態(tài)擴容代碼干擾主線理解。3. 核心模塊拆解從 PCB 到 inode 的微觀實現(xiàn)三個子系統(tǒng)是這份課設(shè)的主體。下面按從“任務(wù)”到“存儲”的順序拆開看每一段代碼都來自項目里對應(yīng)的.c文件只是裁剪掉了無關(guān)的日志分支。3.1 進程調(diào)度PCB 與時間片輪轉(zhuǎn)進程管理模塊的核心是pcb_t結(jié)構(gòu)體它代表一個可以被調(diào)度器感知的任務(wù)// include/ostrain.h typedef struct pcb { char name[8]; // 進程名僅用于日志 int pid; // 進程號從 0 開始遞增 int need_time; // 還需要的 CPU 時間 int used_time; // 已使用的 CPU 時間 int time_slice_used; // 當(dāng)前時間片內(nèi)已用掉的 tick 數(shù) int priority; // 靜態(tài)優(yōu)先級數(shù)值越小優(yōu)先級越高 struct pcb *next; // 就緒隊列中的下一個節(jié)點 } pcb_t;字段說明name限制為 8 字節(jié)因為測試用例里的進程名最長就 7 個字符加一個\0need_time是創(chuàng)建進程時從測試文件讀入的time_slice_used專門用于時間片輪轉(zhuǎn)算法每次調(diào)度 tick 都會自增當(dāng)它等于全局宏TIME_SLICE時觸發(fā)切換。next指針把就緒進程串成一個單向鏈表這是最樸素、也最容易給老師畫圖的隊列實現(xiàn)。調(diào)度器的核心邏輯在scheduler_tick()里// src/scheduler.c void scheduler_tick(void) { pcb_t *current g_current; if (current NULL) { current pick_next(); // 隊列空嘗試取新任務(wù) } if (current NULL) { return; // 所有任務(wù)都已完成 } current-used_time; current-need_time--; current-time_slice_used; if (current-need_time 0) { // 任務(wù)完成移出就緒隊列 remove_from_queue(current); printf([tick%d] %s finished\n, current_tick, current-name); g_current NULL; } else if (current-time_slice_used TIME_SLICE) { // 時間片用完放回隊尾切換給下一個進程 current-time_slice_used 0; enqueue(current); // 入隊尾 g_current pick_next(); if (g_current ! NULL) { printf([tick%d] switch from %s to %s\n, current_tick, current-name, g_current-name); } } }邏輯說明每次 tick當(dāng)前進程的used_time和time_slice_used都加一need_time減一。先判斷任務(wù)是否結(jié)束結(jié)束就從隊列刪除再判斷時間片是否用完用完就重置時間片計數(shù)并重新入隊尾然后從隊頭取下一個進程。這里省略了真實的寄存器上下文切換用g_current指針的重新賦值來代替在課設(shè)講稿里可以說“我們把上下文切換抽象成了 PCB 指針切換”。參數(shù)說明TIME_SLICE在編譯期定義默認值是 5也就是每個進程一次最多跑 5 個 tickneed_time來自測試用例的第一列比如P0 5 2表示進程P0需要 5 個 tick 運行優(yōu)先級為 2。如果你調(diào)小TIME_SLICE進程切換頻率會變高日志里switch行明顯增多這很適合用來演示時間片大小對響應(yīng)時間的影響。3.2 內(nèi)存管理伙伴系統(tǒng)與 LRU 頁面置換內(nèi)存模塊在初始化時把物理內(nèi)存分成 64 個 4KB 頁框并用伙伴系統(tǒng)分配連續(xù)頁框?；锇橄到y(tǒng)的實現(xiàn)很短// src/memory.c static struct block free_list[MAX_ORDER 1]; int alloc_pages(int count) { int size 1; while (size count) size 1; // 向上取整到 2 的冪 int order 0; while ((1 order) size) order; for (int curr order; curr MAX_ORDER; curr) { if (free_list[curr] NULL) continue; struct block *blk free_list[curr]; free_list[curr] blk-next; // 把取出的塊不斷分裂直到達到需要的階數(shù) while (curr order) { curr--; // 把右半個塊放入下一階空閑鏈表 struct block *buddy (struct block *)((char *)blk (1 curr) * PAGE_SIZE); buddy-next free_list[curr]; free_list[curr] buddy; } return blk-index; } return -1; }邏輯說明free_list[curr]存儲當(dāng)前階2^curr 個連續(xù)頁框的空閑塊鏈表。分配時從最小滿足請求的階開始向上找找到后把塊分裂多出來的半塊掛回低一階的鏈表。參數(shù)count是請求的頁框數(shù)經(jīng)過前兩行取整后轉(zhuǎn)換成order如果所有階都為空返回 -1 表示物理內(nèi)存不足觸發(fā)后續(xù)的 LRU 置換。當(dāng)alloc_pages返回 -1 時內(nèi)存管理模塊會調(diào)用find_victim_page()選一個頁淘汰int find_victim_page(void) { // 第一遍看有沒有訪問位為 0 的合法頁有就直接選 for (int i 0; i PAGE_FRAMES; i) { if (page_table[i].valid !page_table[i].accessed_flag) { return i; } } // 第二遍退而求其次選 last_access 最老的一頁 int oldest -1; for (int i 0; i PAGE_FRAMES; i) { if (!page_table[i].valid) continue; if (oldest -1 || page_table[i].last_access page_table[oldest].last_access) { oldest i; } } return oldest; }邏輯說明這是簡化版 LRU沒有維護完整的歷史鏈表而是用accessed_flag做一次“時鐘指針”掃描只要找到訪問位為 0 的頁就直接淘汰如果所有合法頁都被訪問過則退化成按last_access選最老的。參數(shù)PAGE_FRAMES在ostrain.h里定義為 64last_access在每次頁表項被訪問時更新成當(dāng)前current_tick。調(diào)試這個模塊時最?？吹妮敵鍪?replace 日志。一個理想狀態(tài)是當(dāng)工作集明顯大于 64 頁時頁面置換頻率會保持穩(wěn)定如果還是頻繁抖動說明find_victim_page的選擇標準過于簡單。以后想加“增強型時鐘算法”把這個函數(shù)替換成查一遍臟位和訪問位的組合即可。3.3 文件系統(tǒng)模擬磁盤與 inode文件系統(tǒng)模塊不依賴真實文件它用一塊 4MB 的全局數(shù)組模擬磁盤用 inode 記錄文件和塊的對應(yīng)關(guān)系。結(jié)構(gòu)體定義如下// src/filesystem.c #define BLOCK_SIZE 512 #define DISK_BLOCKS 8192 static uint8_t virtual_disk[DISK_BLOCKS * BLOCK_SIZE]; typedef struct inode { uint16_t ino; char name[16]; uint32_t size; int blocks[8]; // 直接塊索引最多 8 塊 struct inode *next; // 哈希鏈表沖突鏈 } inode_t;字段說明DISK_BLOCKS8192 乘以BLOCK_SIZE512 正好 4MB這個大小在 bss 段分配不會占用?？臻gblocks[8]是直接數(shù)據(jù)塊索引意味著單個文件最大 4KB。別笑這是為了把“組織原理”講清楚故意不做多級索引改造擴展點在文末。寫入流程的核心函數(shù)是fs_writeint fs_write(uint16_t ino, const void *buf, uint32_t count) { if (count 0) return 0; inode_t *inode get_inode(ino); if (inode NULL) return -ENOENT; uint32_t max_size 8 * BLOCK_SIZE; if (inode-size count max_size) { return -EFBIG; // 單文件超出直接塊上限 } // 按塊寫入每寫入一塊就分配一個空閑塊號 uint32_t written 0; while (written count) { uint32_t len count - written; if (len BLOCK_SIZE) len BLOCK_SIZE; int blk alloc_simulated_block(); if (blk 0) return -ENOSPC; memcpy(virtual_disk[blk * BLOCK_SIZE], (const uint8_t *)buf written, len); inode-blocks[(inode-size written) / BLOCK_SIZE] blk; written len; } inode-size count; return count; }邏輯說明先通過 inode 號找到對應(yīng)的 inode 對象再檢查新文件大小是否超過 4KB 上限。寫入采用按塊循環(huán)每次從空閑塊位圖中取出一個塊號用memcpy把用戶緩沖區(qū)的數(shù)據(jù)拷進虛擬磁盤最后更新 inode 的塊數(shù)組和文件大小。參數(shù)buf是源數(shù)據(jù)指針count是字節(jié)數(shù)返回值是實際寫入字節(jié)數(shù)alloc_simulated_block()內(nèi)部用位圖記錄塊是否空閑分配失敗返回 -1。在文件系統(tǒng)模塊里目錄實際上是一個特殊 inode它的blocks里存的是目錄項的編碼。fs_create會先創(chuàng)建一個空 inode再把它掛到全局 inode 鏈表中fs_delete則反向操作釋放 inode 占用的所有虛擬磁盤塊。這塊代碼保留在最樸素的版本和真實 ext2 的目錄項相比它沒有記錄name_len所以讀取目錄時是按固定 16 字節(jié)大小跳著走的。你可能會問為什么不直接用fwrite寫真實文件。道理很簡單這個模塊想模擬的內(nèi)容是“磁盤塊如何被數(shù)據(jù)層管理”而不是“如何調(diào)用標準庫”。用內(nèi)存數(shù)組做虛擬磁盤可以配合調(diào)試器直接查看某個塊的內(nèi)容也可以把斷電丟失數(shù)據(jù)的特性放進講稿里。順帶一提virtual_disk在 main 里沒有初始化默認全是 0所以沒寫過數(shù)據(jù)的塊讀出來是0x00這在文件系統(tǒng)檢查軟件里會被判定為“空洞”是合法的。4. 常見問題與避坑記錄調(diào)試三塊模塊時容易翻車的地方下面的問題都不是算法難度造成的大部分是 C 語言邊界、文件格式和 Makefile 展開時機帶來的。我把它們單獨列出來是因為每一個都實際翻過車重跑一次至少浪費半天而且這類問題在答辯前才出現(xiàn)的話壓力會非常大。4.1 進程名帶\r調(diào)度輸出亂碼現(xiàn)象從測試文件讀出的進程名輸出到終端時名字后面多了一個^M而且strcmp(P0, name)永遠不相等導(dǎo)致進程明明完成卻不會從隊列刪除。原因測試用例.txt是在 Windows 上用記事本寫的換行符是 CRLF。fscanf(%s)會把空格之間的字符串讀進來\r殘留在字符串尾部于是name實際是P0\r。解決在read_testcase里讀入名字后做一次尾部清理。常見做法是判斷最后一個字符如果是\r就把它替換成\0。// 讀取 name 后立即清理 if (name[strlen(name) - 1] \r) { name[strlen(name) - 1] \0; }從那以后要求所有測試用例統(tǒng)一用.gitattributes強制 LF 換行省得每個人 clone 下來都遇到一遍。4.2 伙伴系統(tǒng)釋放時不檢查 magicdouble free現(xiàn)象內(nèi)存管理模塊跑幾十個 tick 后輸出block double free然后用 gdb 打斷點發(fā)現(xiàn)釋放相鄰塊時把同一個塊釋放了兩次。原因釋放函數(shù)free_pages里要做“伙伴合并”但只檢查了相鄰地址沒有檢查塊狀態(tài)。兩個塊都空閑時才能合并如果其中一個已經(jīng)被分配出去另一個的free_list指針會亂掉后面再釋放時把已釋放的塊又鏈入鏈表。解決給每個塊頭部加一個magic字段釋放前先斷言當(dāng)前塊狀態(tài)必須是分配態(tài)。合并時再檢查伙伴塊的狀態(tài)是否為空閑兩個條件都滿足才執(zhí)行 merge。#define MAGIC_ALLOC 0xA110C #define MAGIC_FREE 0xF3E if (blk-magic ! MAGIC_ALLOC) { fprintf(stderr, double free detected\n); return -1; }調(diào)試這種問題最有效的是在free_pages入口加printf把塊號、階、magic 都打出來兩行日志就能定位是哪一次釋放出的錯。4.3 就緒隊列為空時解引用 NULL現(xiàn)象--tick200跑完后程序還在運行但pick_next()返回 NULL后面的日志訪問了NULL-name導(dǎo)致段錯誤。原因調(diào)度器完成所有任務(wù)后就緒隊列已經(jīng)空了。但主循環(huán)仍會在每個 tick 調(diào)用scheduler_tick()此時g_current為 NULL后續(xù)代碼沒有提前退出。解決在scheduler_tick()最開頭加一個隊列空判斷同時在pick_next()里也返回 NULL 保護。另外讓shell_collect()只在g_current ! NULL時取樣。if (ready_head NULL) { g_current NULL; return; }這不算高明但很多同學(xué)復(fù)制代碼時容易漏掉這個邊界條件。好轉(zhuǎn)之后你會發(fā)現(xiàn)空轉(zhuǎn)的 tick 不再崩日志尾部會一直打印no process更便于解釋“空閑態(tài)”。4.4 Makefile 通配符緩存舊文件列表現(xiàn)象往src/里新增一個vfs.c后鏈接時瘋狂報undefined reference to fs_mount但單獨gcc這個文件能過。原因Makefile 里用的是SRCS : $(wildcard src/*.c)wildcard函數(shù)在 Makefile 解析時就會展開新增文件不會自動進到SRCS里所以make根本不會編譯 vfs.c。解決改成SRCS : $(shell find src -name *.c)讓 Makefile 每次運行時動態(tài)搜索源文件。注意這會讓 make 每次啟動都執(zhí)行一次find文件不多時影響可以忽略。SRCS : $(shell find src -name *.c)最穩(wěn)妥的辦法還是顯式列出源文件雖然麻煩但不會踩“改代碼沒生效”的坑。后來在 Makefile 里加了一個make clean調(diào)用rm -rf result每次新增文件先 clean避免日志里摻著舊輸出。5. 二次開發(fā)把時間片輪詢改成優(yōu)先級搶占調(diào)度這個項目最值得改的地方就是調(diào)度器。當(dāng)前實現(xiàn)是純時間片輪轉(zhuǎn)所有進程都在同一個隊列里按 FIFO 次序執(zhí)行。你可以把它改成“優(yōu)先級搶占式”維持多個就緒隊列每個隊列對應(yīng)一個優(yōu)先級在每個 tick 里調(diào)度器只從優(yōu)先級最高的非空隊列取進程一旦有高優(yōu)先級進程到來立刻搶占正在運行的進程。實現(xiàn)時只需要動兩個函數(shù)。第一個是pick_next從單隊列遍歷改成多隊列選擇// 多隊列版本 pick_next返回最高優(yōu)先級隊列的隊頭 pcb_t *pick_next(void) { for (int prio 0; prio MAX_PRIO; prio) { if (queues[prio] ! NULL) { return queues[prio]; } } return NULL; }第二個是入隊函數(shù)從固定enqueue(current)改成按current-priority選擇隊列void enqueue_prio(pcb_t *p) { int prio p-priority; if (queues[prio] NULL) { queues[prio] p; } else { pcb_t *tail queues[prio]; while (tail-next ! NULL) tail tail-next; tail-next p; } p-next NULL; }邏輯說明queues[prio]是指針數(shù)組數(shù)組下標就是優(yōu)先級數(shù)值越小優(yōu)先級越高。pick_next從最低下標開始找第一個非空隊列并返回隊頭。由于每個 tick 都調(diào)用pick_next只要高優(yōu)先級隊列非空低優(yōu)先級進程永遠不會被選中這就是“搶占”的實現(xiàn)。改完之后建議做一次對比實驗用同一個01_rr_test.txt分別跑--modeprocess --tick50和不帶優(yōu)先級參數(shù)的版本。觀察高優(yōu)先級進程的平均完成時間。一個簡單驗證辦法是讓所有進程創(chuàng)建后直接運行然后統(tǒng)計每個進程的finish_tick - create_tick算出平均值。兩個版本的平均完成時間應(yīng)該差出 1.5 倍左右這個數(shù)字就是答辯時可以寫進結(jié)論里的“性能提升”。如果你不想動調(diào)度器也可以改文件系統(tǒng)模塊把blocks[8]改成blocks[12]并增加一個間接塊索引字段模擬兩級索引文件。實現(xiàn)量不大但能把磁盤組織從“連續(xù)文件”往“索引文件”推進一步。無論改哪塊我的經(jīng)驗是先改一個參數(shù)跑出一個可對比的數(shù)值再動數(shù)據(jù)結(jié)構(gòu)。這個課設(shè)做完我才意識到操作系統(tǒng)每做一個新特性都要立刻把scheduler_tick、memory_tick和filesystem_tick的集成跑一遍。從那以后我每次給項目加模塊都強制自己先接上全局 tick 再寫內(nèi)部邏輯而不是等所有代碼寫完才去想到底從哪里開始調(diào)。希望幫到你。本文還有配套的精品資源點擊獲取