1. 搶占式調(diào)度器到底在搶什么概念拆解與價值分析1.1 “搶占”的本質(zhì)CPU是唯一的公共資源很多初學(xué)者看到“搶占式調(diào)度器”這幾個字第一反應(yīng)是“操作系統(tǒng)里才有的東西”離自己很遠(yuǎn)。我當(dāng)年第一次動手寫它的時候也是這個心理可真正讀懂之后才發(fā)現(xiàn)它就是一套“在多個任務(wù)之間分配CPU使用權(quán)”的規(guī)則。CPU是唯一的公共資源而“搶占”這兩個字說的就是這套規(guī)則最硬核的動作當(dāng)一個正在運行的任務(wù)還沒主動讓出CPU時調(diào)度器直接把它暫停把處理器交給另一個任務(wù)。打個比方搶占式調(diào)度就像馬路上跑著普通車輛突然救護(hù)車?yán)懢瘓笄懊娴能嚤仨毧窟厱和！＿@里“靠邊暫?！辈皇乔败囁緳C想不想讓的問題而是被規(guī)則強制執(zhí)行的。放在系統(tǒng)里也一樣低優(yōu)先級任務(wù)正在執(zhí)行高優(yōu)先級任務(wù)一就緒調(diào)度器馬上保存低優(yōu)先級任務(wù)的執(zhí)行現(xiàn)場切換到高優(yōu)先級任務(wù)。這個動作就叫“搶占”。所以搶占式調(diào)度器真正“搶”的是什么是CPU是處理器當(dāng)前這條指令執(zhí)行權(quán)。而要做到這一點系統(tǒng)必須能回答三個問題現(xiàn)在誰在用CPU誰更有資格用切換的時候怎么做到無縫交接這三個問題分別對應(yīng)任務(wù)狀態(tài)管理、調(diào)度策略、上下文切換也就是我這篇博客要講的三個核心設(shè)計。搞明白這三件事手寫一個最小可用的搶占式調(diào)度器就不難了。1.2 協(xié)作式調(diào)度 vs 搶占式調(diào)度一個對比實驗在動手寫代碼之前我強烈建議先搞清楚搶占式調(diào)度和傳統(tǒng)的協(xié)作式調(diào)度之間差的到底是“代碼量”還是“設(shè)計思路”。二者最大的區(qū)別只有一個切換的主動權(quán)在誰手里。協(xié)作式調(diào)度的經(jīng)典形態(tài)是這樣的// 最樸素的超級循環(huán) while (1) { task1(); // task1運行完自然回到循環(huán) task2(); // task2運行完自然回到循環(huán) }這種寫法下task1如果不主動返回task2永遠(yuǎn)沒機會跑。就算用yield()讓出CPU的協(xié)作式RTOS本質(zhì)上也是靠任務(wù)自覺。一旦某個任務(wù)里出現(xiàn)一段死循環(huán)整個系統(tǒng)直接卡死。搶占式調(diào)度則把主動權(quán)收回到了內(nèi)核手里。系統(tǒng)利用一個周期性中斷比如1ms觸發(fā)一次的系統(tǒng)節(jié)拍作為“心跳”每次心跳都會檢查當(dāng)前任務(wù)是否還被允許繼續(xù)占用CPU。如果此時有更高優(yōu)先級任務(wù)就緒或者當(dāng)前任務(wù)的時間片已經(jīng)用完內(nèi)核立刻發(fā)起上下文切換強制換人。我用一個表格把兩者的差異列清楚方便你對照著選型對比維度超級循環(huán)協(xié)作式調(diào)度搶占式調(diào)度切換時機任務(wù)結(jié)束返回任務(wù)主動讓出任意時刻可被內(nèi)核強制最大風(fēng)險單任務(wù)卡死全系統(tǒng)任務(wù)不讓出也會卡死需要處理共享數(shù)據(jù)競爭實時性無保證弱實時強實時可預(yù)測實現(xiàn)復(fù)雜度極低較低較高典型應(yīng)用極簡控制/教學(xué)早期系統(tǒng)RTOS、嵌入式操作系統(tǒng)搶占式調(diào)度并不神秘它做的事就是在“協(xié)作式中斷”上疊加了一個“強制切換”能力。每一個搶占式調(diào)度器背后其實只有四個要素任務(wù)控制塊、就緒隊列、上下文切換、系統(tǒng)節(jié)拍。把這四件事想通之后下面的代碼寫起來就是水到渠成的事。2. 動手前的核心設(shè)計TCB、就緒隊列與上下文切換2.1 TCB該存哪些信息調(diào)度的“戶口本”調(diào)度器要管理多個任務(wù)第一件事就是給每個任務(wù)建立一個“戶口本”系統(tǒng)里叫任務(wù)控制塊TCB。所有和任務(wù)相關(guān)的信息都記錄在這個結(jié)構(gòu)體里缺了哪項切換的時候都會出事。我寫的第一個最小版本TCB只保留了六個字段typedef struct tcb { uint32_t *sp; // 任務(wù)棧指針上下文切換時保存現(xiàn)場 uint8_t priority; // 任務(wù)優(yōu)先級數(shù)值越小優(yōu)先級越高 uint8_t state; // 任務(wù)狀態(tài)就緒、運行、阻塞 uint32_t slice; // 剩余時間片單位是系統(tǒng)節(jié)拍數(shù) void (*entry)(void *arg); // 任務(wù)入口函數(shù) struct tcb *next; // 用于串成鏈表指向下一個任務(wù) } tcb_t;這里最容易被忽略的是sp字段。每個任務(wù)都有自己獨立的棧運行時棧指針指向哪完全靠這個字段記錄。搶占發(fā)生的那一刻調(diào)度器會把當(dāng)前任務(wù)的棧指針保存到TCB里下一次恢復(fù)該任務(wù)時再從這個字段讀出棧指針把寄存器現(xiàn)場彈回來。你可以把它理解成書簽每次被強制暫停CPU就把讀書進(jìn)度寫到這個書簽上下次接著讀。需要提醒的是不同任務(wù)之間哪怕入口函數(shù)一模一樣也必須有各自獨立的?？臻g。很多初學(xué)者圖省事讓兩個任務(wù)共用一塊棧跑起來一開搶占就“炸”原因正是高優(yōu)先級任務(wù)的函數(shù)調(diào)用會覆蓋低優(yōu)先級任務(wù)還在使用的棧數(shù)據(jù)。2.2 就緒隊列如何設(shè)計從鏈表到位圖的一次實踐有了TCB下一步是回答“誰有資格被選中”。最常見的設(shè)計是維護(hù)一張就緒表凡是處于就緒狀態(tài)的任務(wù)都掛到這上面。調(diào)度時從就緒表里挑出一個最合適的任務(wù)。我在最初版本用的是普通單向鏈表簡單是簡單但有一個痛點是查找最高優(yōu)先級任務(wù)時要遍歷整個鏈表任務(wù)數(shù)量一多延遲就不穩(wěn)定。后來參考了一些實時內(nèi)核的做法改用就緒位圖bitmap一個32位無符號整數(shù)就能記錄32個優(yōu)先級上的就緒情況。某一位置1表示該優(yōu)先級上至少有一個任務(wù)就緒。// 假設(shè)優(yōu)先級0最高優(yōu)先級31最低 static uint32_t ready_bitmap; // 某位為1說明該優(yōu)先級有就緒任務(wù) // 優(yōu)先級p的任務(wù)就緒 void ready_set(uint8_t p) { ready_bitmap | (1u p); } // 優(yōu)先級p的任務(wù)離開就緒態(tài) void ready_clear(uint8_t p) { ready_bitmap ~(1u p); }在Cortex-M3及以上平臺獲取最高優(yōu)先級就緒任務(wù)可以用一條匯編指令CLZ計算前導(dǎo)零個數(shù)配合位圖就能在常數(shù)時間內(nèi)完成tcb_t *schedule(void) { int prio; if (ready_bitmap 0) { return NULL; // 沒有就緒任務(wù) } prio 31 - __CLZ(ready_bitmap); // 找到最高優(yōu)先級的序號 return priority_task_list[prio]; // 取出該優(yōu)先級上的任務(wù) }位圖方案的優(yōu)點是查找時間確定、邏輯容易驗證缺點是有多少個優(yōu)先級就要付出多少1bit的代價。好在32個優(yōu)先級對絕大多數(shù)實際系統(tǒng)已經(jīng)綽綽有余。這其實也引出了另一個關(guān)鍵問題調(diào)度策略真的只有“選最高優(yōu)先級”這一條嗎不是。更完整的策略還包含同優(yōu)先級任務(wù)之間的時間片輪轉(zhuǎn)以及“如果說最高優(yōu)先級也在運行新就緒的任務(wù)比它還高那馬上搶占”的判斷。這些我放到第四章細(xì)講。2.3 上下文切換為什么必須在PendSV里干上下文切換是搶占式調(diào)度器里技術(shù)含量最高的部分。它要做的就是把當(dāng)前任務(wù)CPU寄存器里的現(xiàn)場完整保存然后把新任務(wù)之前保存的現(xiàn)場恢復(fù)出來。具體來說要存檔的東西包括R0-R12通用寄存器、棧指針SP、鏈接寄存器LR、程序計數(shù)器PC、程序狀態(tài)寄存器xPSR。這些現(xiàn)場一旦缺一個恢復(fù)后任務(wù)就會“失憶”輕則數(shù)據(jù)錯亂重則直接跑飛。但有一個問題這些切換動作到底在什么時機執(zhí)行答案是必須在一個中斷處理函數(shù)里完成而不是在普通的任務(wù)代碼里。任務(wù)代碼運行時的上下文是它自己的“私人物品”調(diào)度器一旦在任務(wù)上下文里修改SP或者調(diào)用切換函數(shù)會把當(dāng)前的運行棧搞亂。更穩(wěn)妥的做法是借助一個專門的中斷在中斷處理程序里借“中斷機制的東風(fēng)”來做切換。我用的平臺是Cortex-M系列它提供兩個給OS用得很順手的工具SysTick定時器和PendSV異常。SysTick按時產(chǎn)生系統(tǒng)節(jié)拍相當(dāng)于心跳PendSV則被設(shè)計成專門留給操作系統(tǒng)做上下文切換的異常它的優(yōu)先級可以設(shè)為最低并且有一個特點如果切換請求進(jìn)來時還有其他中斷在處理PendSV會被“押后”到所有中斷都處理完之后再執(zhí)行。這一設(shè)計剛好避免了一個大坑——假如上下文切換打斷了一個中斷服務(wù)程序OS很難判斷此刻該不該切換而PendSV的延遲特性讓切換時機變得干凈安全。上下文切換的完整路徑是SysTick中斷觸發(fā) → 發(fā)現(xiàn)該切換了 → 置位PendSV的掛起位 → SysTick退出 → PendSV進(jìn)入 → 保存當(dāng)前現(xiàn)場 → 選新任務(wù) → 恢復(fù)新現(xiàn)場 → 返回。流程圖式的理解不難真正難的是棧上數(shù)據(jù)的排列順序。這個我在第三章的代碼里展開講解。3. 從零手寫的最小實現(xiàn)步驟與代碼逐段解析3.1 平臺和工具鏈怎么選手寫搶占式調(diào)度器最理想的學(xué)習(xí)平臺是帶片內(nèi)SysTick的32位MCU。我建議用Cortex-M3/M4內(nèi)核的開發(fā)板因為它在硬件上自動幫我們做了一部分現(xiàn)場保存一旦進(jìn)入中斷硬件會先把xPSR、PC、LR、R12、R0-R3這8個寄存器壓入當(dāng)前棧中斷返回時再自動彈出。這極大降低了手寫調(diào)度器的難度。RISC-V平臺也能做但需要自己處理的東西更多不適合第一次練手。工具鏈方面我用的是開源GCC交叉編譯器加一個調(diào)試器。環(huán)境配置就是三件套交叉編譯器、一個能燒錄調(diào)試的工具、一塊開發(fā)板。如果你手頭甚至沒有板子也可以用一款開源虛擬機模擬器先把調(diào)度邏輯調(diào)通跑通了再燒到真機上。我個人強烈建議走“先在模擬器上驗證、再上真機”這條路后面能替你省下大量排查硬件問題的時間。3.2 五步搭出最小搶占式調(diào)度器下面我按自己實際操作時的順序來講每一步都給了代碼片段。需要注意這里展示的是一個“最小可用原型”專職演示搶占式調(diào)度器的核心機制不追求功能齊全。第一步定義任務(wù)棧與TCB數(shù)組#define TASK_STACK_SIZE 512 #define MAX_TASKS 2 static uint32_t task_stack0[TASK_STACK_SIZE]; static uint32_t task_stack1[TASK_STACK_SIZE]; static tcb_t tcb0; static tcb_t tcb1;任務(wù)棧為什么用uint32_t數(shù)組而不用uint8_t因為Cortex-M的棧操作是4字節(jié)對齊的直接聲明32位數(shù)組?；刂诽烊话?字節(jié)對齊省去一堆對齊處理的麻煩。第二步初始化任務(wù)棧偽造一個“剛被搶占”的現(xiàn)場這是整個實現(xiàn)里最微妙的一步。任務(wù)是第一次運行并沒有真正的“現(xiàn)場”可保存所以我們要在棧上預(yù)先偽造一份“如果任務(wù)剛剛被打斷應(yīng)該長什么樣”的寄存器布局。等第一次切換發(fā)生時恢復(fù)現(xiàn)場就跟往常一樣仿佛這個任務(wù)早就存在。void task_stack_init(tcb_t *tcb, void (*entry)(void *), uint32_t *stack_top) { uint32_t *s stack_top; // 模擬Cortex-M進(jìn)入中斷時硬件自動壓棧的8個寄存器 *--s 0x01000000; // xPSRbit24必須置1表示Thumb模式 *--s (uint32_t)entry; // PC任務(wù)入口地址 *--s 0xFFFFFFFD; // LR任務(wù)一旦返回就進(jìn)異常 *--s 0x00000012; // R12 *--s 0x00000003; // R3 *--s 0x00000002; // R2 *--s 0x00000001; // R1 *--s 0x00000000; // R0 // 模擬PendSV處理程序中保存R4-R11這8個通用寄存器 for (int i 0; i 8; i) { *--s 0x00000000; } tcb-sp s; // 把偽造好的棧指針存進(jìn)TCB }初學(xué)時最容易在這里犯迷糊為什么壓棧順序是xPSR、PC、LR、R12、R3、R2、R1、R0然后再R4-R11答案很簡單Cortex-M中斷機制約定中斷返回時硬件按固定順序從棧中彈出8個寄存器從上到下依次是R0、R1、R2、R3、R12、LR、PC、xPSR。由于棧是向下增長的我們要預(yù)置這份布局就必須反向?qū)懭胍簿褪菑膞PSR開始寫最后寫R0。多出的R4-R11對應(yīng)PendSV處理程序里的“手動保存區(qū)”。第三步實現(xiàn)SysTick心跳決定“要不要切”系統(tǒng)節(jié)拍是搶占式調(diào)度器的驅(qū)動源。SysTick每1ms觸發(fā)一次中斷服務(wù)程序里把當(dāng)前任務(wù)的剩余時間片減一減到0就換任務(wù)void SysTick_Handler(void) { tcb_t *cur current_task; if (cur-slice 0) { cur-slice--; } if (cur-slice 0) { cur-slice DEFAULT_SLICE; // 重新填滿時間片 SCB-ICSR | (1UL 28); // 置位PendSV掛起位 } }這里只做了“觸發(fā)PendSV”的動作真正的切換在PendSV里。為什么不在SysTick里直接切因為SysTick的中斷上下文可能嵌套在別的中斷中直接切換會讓調(diào)度器與正在處理的中斷糾纏不清。置位掛起位、等PendSV順便執(zhí)行才是干凈的做法。第四步實現(xiàn)PendSV上下文切換PendSV的處理函數(shù)是調(diào)度器的心臟我直接用匯編寫因為C編譯器一旦介入寄存器保存的順序和時機就不再可控。下面是一個針對Cortex-M3/M4平臺的精簡實現(xiàn)__asm void PendSV_Handler(void) { // 1. 保存當(dāng)前任務(wù)現(xiàn)場 MRS R0, PSP ; 讀當(dāng)前進(jìn)程棧指針 STMDB R0!, {R4-R11} ; 把R4-R11壓入當(dāng)前任務(wù)棧 LDR R1, current_task ; R1指向current_task指針變量 LDR R2, [R1] ; R2 current_task STR R0, [R2] ; 將新的SP寫回當(dāng)前任務(wù)的TCB-sp // 2. 調(diào)用調(diào)度函數(shù)選出下一個要運行的任務(wù) BL schedule // 3. 更新current_task為新任務(wù)讀取其SP LDR R1, current_task STR R0, [R1] ; current_task 新任務(wù) LDR R0, [R0] ; R0 新任務(wù)的TCB-sp // 4. 恢復(fù)新任務(wù)的現(xiàn)場 LDMIA R0!, {R4-R11} ; 彈出R4-R11 MSR PSP, R0 ; 更新進(jìn)程棧指針 BX LR ; 返回時硬件自動彈出R0-R3、R12、LR、PC、xPSR }這個函數(shù)每次執(zhí)行就是一個完整的“交接儀式”。有一點一定要記住PendSV執(zhí)行期間Cortex-M硬件已經(jīng)把調(diào)用者現(xiàn)場固定保存在MSP主棧指針里我們操作的是PSP進(jìn)程棧指針也就是任務(wù)自己的棧。保存時用STMDB是“先遞減再存儲”恢復(fù)時用LDMIA“先加載再遞增”一壓一彈正好和棧的生長方向?qū)?yīng)。第五步創(chuàng)建任務(wù)并啟動調(diào)度器任務(wù)棧初始化好了TCB也賦值了最后把系統(tǒng)跑起來void task_create(tcb_t *tcb, void (*entry)(void *), uint32_t priority, uint32_t slice, uint32_t *stack_top) { task_stack_init(tcb, entry, stack_top); tcb-priority priority; tcb-slice slice; tcb-state READY; ready_set(priority); } void scheduler_start(void) { // 關(guān)閉中斷選第一個任務(wù)打開中斷 __disable_irq(); current_task schedule(); current_task-state RUNNING; PSP current_task-sp; __enable_irq(); }scheduler_start的竅門是一開始沒有循環(huán)、沒有while(1)而是直接在特權(quán)模式下把第一個任務(wù)的棧指針寫入PSP然后開中斷。第一次SysTick到來時它會乖乖走上“保存→調(diào)度→恢復(fù)”的軌道。從此兩個任務(wù)在心跳的驅(qū)動下交替運行搶占式調(diào)度器就活起來了。3.3 三個關(guān)鍵參數(shù)怎么定節(jié)拍、棧大小、優(yōu)先級數(shù)量寫完原型之后接下來就是調(diào)參數(shù)。我最早踩的坑全在參數(shù)上所以單獨拿出來說說。系統(tǒng)節(jié)拍一般取1ms到10ms。太快比如0.1ms會讓調(diào)度器自身開銷占比過高系統(tǒng)大量時間花在切換上太慢比如100ms則實時性無法保證。我習(xí)慣先按應(yīng)用的需求定如果只是LED閃爍、按鍵掃描10ms足矣如果后面要跑通信協(xié)議棧、電機控制建議從1ms起步再測量CPU占用率。任務(wù)棧大小沒有一個公式能給出精確值最靠譜的是“估大不估小”。一般計算公式是最大函數(shù)調(diào)用深度 × 平均局部變量占用 最大中斷嵌套深度 × 中斷幀大小最后再加20%到30%的安全余量。Cortex-M中斷幀是8個寄存器約32字節(jié)如果考慮當(dāng)前正在處理的局部變量一次嵌套中斷通常需要100字節(jié)左右。512字節(jié)的棧只夠跑很淺的調(diào)用實際產(chǎn)品里任務(wù)棧經(jīng)常是1KB到4KB。優(yōu)先級數(shù)量位圖方案下8個或16個優(yōu)先級已經(jīng)能應(yīng)對大多數(shù)場景。優(yōu)先級越多調(diào)度邏輯越靈活但系統(tǒng)設(shè)計時也要面對更復(fù)雜的優(yōu)先級反轉(zhuǎn)問題。我的建議是開始只設(shè)兩個優(yōu)先級先把“搶占”的動作驗證明白再逐步擴(kuò)展。4. 容易翻車的幾個關(guān)鍵細(xì)節(jié)以及我的取舍4.1 臨界區(qū)保護(hù)搶占之前先看紅綠燈調(diào)度器能在“任意指令邊界”強制切換任務(wù)這帶來一個隱患如果任務(wù)A正在修改一個共享變量只寫了一半突然被打斷任務(wù)B也來讀寫這個變量數(shù)據(jù)就亂了。搶占式調(diào)度器對共享資源的保護(hù)方式和裸機程序完全不同。裸機程序只要關(guān)中斷就行但搶占式系統(tǒng)里還需要配合互斥鎖或者臨界區(qū)。第一種臨界區(qū)實現(xiàn)最簡單全關(guān)中斷。uint32_t enter_critical(void) { uint32_t primask __get_PRIMASK(); __disable_irq(); // 關(guān)中斷 return primask; } void exit_critical(uint32_t primask) { __set_PRIMASK(primask); // 恢復(fù)之前的中斷狀態(tài) }這種做法的缺點是關(guān)中斷會讓所有中斷暫時失效如果臨界區(qū)代碼太長系統(tǒng)實時性會明顯變差甚至丟中斷。我在最初版本里就這么干后來發(fā)現(xiàn)通信中斷被關(guān)久了會丟數(shù)據(jù)才意識到問題。第二種方案是Cortex-M3/M4提供的BASEPRI機制設(shè)置一個閾值只屏蔽優(yōu)先級低于某個值的中斷高優(yōu)先級中斷仍然可以響應(yīng)。這樣臨界區(qū)可以保護(hù)共享數(shù)據(jù)又不犧牲像通信這類高優(yōu)先級中斷的實時響應(yīng)。具體代碼就是往BASEPRI寄存器寫一個數(shù)字中斷保護(hù)結(jié)束后寫0。這個方案把“關(guān)中斷時間”縮短到很短代價是M0系列不支持代碼要做條件編譯。4.2 中斷嵌套、延遲搶占與PendSV的優(yōu)先級PendSV的優(yōu)先級是新手很容易忽略的大坑。我剛開始實現(xiàn)時把PendSV優(yōu)先級和其他中斷一樣設(shè)成0最高結(jié)果調(diào)試時頻繁出現(xiàn)奇怪的現(xiàn)象SysTick一觸發(fā)PendSV馬上跑把本應(yīng)在SysTick之后處理的某些中斷全部攪亂。正確做法是PendSV的優(yōu)先級必須設(shè)置為所有中斷里最低的那個。原因在于它的設(shè)計定位是“等一切安靜下來再做切換”。如果PendSV優(yōu)先級太高它可能在一個中斷服務(wù)程序還沒結(jié)束時就搶進(jìn)去那個中斷執(zhí)行到一半現(xiàn)場可能還沒保存或者棧指針異常強行切換后果不可預(yù)料。把PendSV設(shè)為最低它就會等所有更高中斷都處理完再執(zhí)行這就是“延遲搶占”的核心思想。這里還牽扯到中斷嵌套。Cortex-M中斷優(yōu)先級比正常任務(wù)高但中斷之間也能嵌套只要更高優(yōu)先級中斷來了同樣能打斷正在執(zhí)行的中斷服務(wù)程序。這對調(diào)度器意味著即使任務(wù)切換在PendSV里做中斷服務(wù)程序本身也得小心不要在嵌套過程中訪問調(diào)度器共享數(shù)據(jù)否則還是要加臨界區(qū)保護(hù)。4.3 時間片輪轉(zhuǎn)和優(yōu)先級如何優(yōu)雅地共存很多第一次手寫調(diào)度器的人會糾結(jié)一個問題既然高優(yōu)先級任務(wù)總是搶占那低優(yōu)先級任務(wù)是不是永遠(yuǎn)沒有機會跑答案是取決于高優(yōu)先級任務(wù)的運行方式。如果高優(yōu)先級任務(wù)是一個帶阻塞操作的循環(huán)比如等待信號量、延時它會在阻塞時主動讓出CPU把運行機會還給低優(yōu)先級任務(wù)。這恰恰說明一個完整的搶占式調(diào)度器不能只有“搶占”這一個動作還得有任務(wù)阻塞與喚醒機制。對于同優(yōu)先級的多個任務(wù)我采用時間片輪轉(zhuǎn)。每個任務(wù)分配一個時間片時間片用完系統(tǒng)強行把CPU交給下一個同優(yōu)先級任務(wù)。如果此時有更高優(yōu)先級任務(wù)就緒調(diào)度器優(yōu)先切到高優(yōu)先級任務(wù)高優(yōu)先級任務(wù)阻塞后再回到當(dāng)前優(yōu)先級隊列里繼續(xù)輪轉(zhuǎn)。實現(xiàn)上我維護(hù)了“每個優(yōu)先級下掛一串任務(wù)就緒列表”的數(shù)據(jù)結(jié)構(gòu)調(diào)度時先看位圖找最高優(yōu)先級到了優(yōu)先級內(nèi)部再按輪轉(zhuǎn)順序選任務(wù)。這樣的分層設(shè)計讓調(diào)度器的核心邏輯保持簡單擴(kuò)展也方便。后面你想加信號量、郵箱只需要改變?nèi)蝿?wù)的狀態(tài)和就緒位圖調(diào)度器的核心不必大改。5. 實操中的坑問題現(xiàn)象、排查思路與修復(fù)記錄5.1 系統(tǒng)一跑就HardFault先查棧溢出和棧對齊我第一次在真機上跑這個調(diào)度器開局就是HardFault。那一刻的心情如果你也調(diào)過嵌入式代碼一定能懂。冷靜下來按三個層次排查才定位到問題。第一步確認(rèn)棧是否溢出。我預(yù)先把每個任務(wù)棧的起始區(qū)域填滿一個特定字節(jié)比如0xCC跑一段時間后查看棧高水位看這個填充字節(jié)有沒有被沖掉。結(jié)果發(fā)現(xiàn)低優(yōu)先級任務(wù)棧的0xCC全沒了說明棧確實不夠用。把512字節(jié)加大到1024字節(jié)系統(tǒng)穩(wěn)定了不少。第二步查棧對齊。Cortex-M要求進(jìn)行某些操作時16字節(jié)對齊才能保證硬件正常工作。我的任務(wù)棧聲明是uint32_t數(shù)組天然4字節(jié)對齊但在偽造初始現(xiàn)場時壓棧次數(shù)是奇數(shù)還是偶數(shù)的細(xì)節(jié)會影響棧的最終對齊需要在壓棧后檢查sp 0x0F的值。當(dāng)時我壓了16個寄存器恰好保持對齊這個坑沒有踩到。第三步查LR和異常返回。任務(wù)入口函數(shù)一旦執(zhí)行到末尾LR里的0xFFFFFFFD會讓CPU進(jìn)入異常模式而異常模式里又沒有任何處理函數(shù)結(jié)果也是HardFault。這個在初始化時本來就要避免我建議任務(wù)入口函數(shù)永遠(yuǎn)是一個while(1)循環(huán)別讓自己“跑完”。5.2 高優(yōu)先級任務(wù)被卡死優(yōu)先級反轉(zhuǎn)的現(xiàn)場復(fù)現(xiàn)有一次調(diào)試我遇到一個比HardFault更難纏的現(xiàn)象高優(yōu)先級任務(wù)A明明就緒了卻始終得不到執(zhí)行反而是低優(yōu)先級任務(wù)C一直在跑。打印各處標(biāo)志位后我發(fā)現(xiàn)真正的原因是一個共享資源——互斥量——被中等優(yōu)先級任務(wù)B和低優(yōu)先級任務(wù)C之間的一串調(diào)用搞得“顛倒”了。場景是任務(wù)C先拿到了互斥量執(zhí)行到一半被任務(wù)A搶占任務(wù)A想申請同一個互斥量發(fā)現(xiàn)被C持有于是A只能等待可這時候任務(wù)B優(yōu)先級高于C、低于A一就緒立刻搶占C。C被B壓住根本沒機會釋放互斥量于是A被C間接“卡死”。這就是教科書上的優(yōu)先級反轉(zhuǎn)。按理論說A優(yōu)先級最高應(yīng)該最快完成但實際上它等著一個“未來才有機會跑的C”釋放資源。修復(fù)方案用的是優(yōu)先級繼承當(dāng)?shù)蛢?yōu)先級任務(wù)持有高優(yōu)先級任務(wù)所需的互斥量時把低優(yōu)先級任務(wù)的優(yōu)先級臨時提升到高優(yōu)先級任務(wù)的級別讓C先跑完、釋放資源、恢復(fù)原優(yōu)先級A再繼續(xù)執(zhí)行。代碼里就是在拿鎖/解鎖操作中動態(tài)修改TCB的優(yōu)先級并重新調(diào)度。這個修復(fù)讓我對“調(diào)度器只是外殼資源管理才是靈魂”這句話有了深刻體會。5.3 上下文切換后數(shù)據(jù)錯亂調(diào)試器怎么一步步定位還有一次兩個任務(wù)交替跑一陣后某個全局變量莫名其妙變成了垃圾值。我心想這多半是上下文切換時某個寄存器沒保存或沒恢復(fù)。打開調(diào)試器在PendSV入口和出口各下一個斷點觀察PSP寄存器和棧內(nèi)存區(qū)域發(fā)現(xiàn)了一個典型錯誤我在“保存現(xiàn)場”時用了STMDB R0!, {R4-R11}更新了R0但后續(xù)“恢復(fù)現(xiàn)場”時又用同一個R0去找新任務(wù)的SP導(dǎo)致新任務(wù)的SP指針被舊任務(wù)的棧位置干擾。這種問題用眼睛盯代碼很難發(fā)現(xiàn)但調(diào)試器里逐指令單步執(zhí)行就一目了然。后來我養(yǎng)成了一個習(xí)慣每次寫完P(guān)endSV先用單個任務(wù)自啟動確認(rèn)第一次切換正常再兩個任務(wù)對切重點觀察SP和棧數(shù)據(jù)最后才加第三個任務(wù)壓測。分階段驗證能讓定位范圍縮小很多。5.4 避坑清單速查表我在實際調(diào)試中積累的這些經(jīng)驗整理成一個速查表遇到問題可以照著查現(xiàn)象最可能原因處理辦法一啟動就HardFault任務(wù)棧溢出 / 初始現(xiàn)場偽造錯誤查棧水印核對壓棧順序每隔固定時間就進(jìn)異常SysTick頻率過高切換開銷過大調(diào)低節(jié)拍頻率優(yōu)化臨界區(qū)長度低優(yōu)先級任務(wù)始終不執(zhí)行高優(yōu)先級任務(wù)從不阻塞給高優(yōu)先級任務(wù)加延時/等待邏輯全局變量值時好時壞中斷修改共享數(shù)據(jù)沒加臨界區(qū)用臨界區(qū)或互斥量保護(hù)切換后返回地址跑飛PendSV中SP恢復(fù)順序錯誤單步跟蹤核對進(jìn)出棧SP值PendSV一直不執(zhí)行PendSV優(yōu)先級被設(shè)成和SysTick相同或更高將PendSV設(shè)為所有可屏蔽中斷最低級6. 最后聊幾句個人心得手寫一個搶占式調(diào)度器最大的收獲不是“我會寫切換”這件事而是真正理解了操作系統(tǒng)為什么把調(diào)度器和中斷系統(tǒng)設(shè)計得如此緊密。那些平時用RTOS時覺得理所當(dāng)然的API比如“延時”“信號量”底層全靠一套精確的上下文切換在做支撐。紙上談兵一百遍不如自己把TCB建出來、把SysTick和PendSV跑通一遍來得扎實。如果讓我給剛開始動手的人一個建議那就是第一版千萬不要貪多先讓兩個任務(wù)在SysTick驅(qū)動下“輪流亮相”哪怕它們只負(fù)責(zé)翻轉(zhuǎn)變量跑通就是勝利。之后再慢慢加入優(yōu)先級、阻塞喚醒、資源鎖。我就是這么一步步踩過來的期間犧牲過好幾塊開發(fā)板調(diào)Sch的“黑盒時間”但最終換來的是對調(diào)度機制真正的掌控感。這個原型后面還能繼續(xù)擴(kuò)展的方向很多加軟件定時器、郵箱、信號量甚至把任務(wù)棧從靜態(tài)數(shù)組改成動態(tài)分配做成一個微型RTOS。但不管怎么加核心始終是那套“保存現(xiàn)場、選人、恢復(fù)現(xiàn)場”的鐵三角。把這套機制用自己的手寫透一次以后再看任何RTOS的源碼都會有一種“原來如此”的親切感。