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