文章目錄一、一個(gè)靈異事件引出的問題二、優(yōu)先級(jí)反轉(zhuǎn)到底是怎么回事2.1 用一張圖講清楚2.2 為什么這是 RTOS 的承諾違約三、工程搭建一個(gè)能穩(wěn)定復(fù)現(xiàn)的最小模型3.1 為什么能穩(wěn)定復(fù)現(xiàn)3.2 任務(wù)設(shè)計(jì)3.3 CubeMX 配置要點(diǎn)3.4 關(guān)鍵代碼二值信號(hào)量版3.5 失敗路徑TaskM 一啟動(dòng)整個(gè)串口輸出就凍住了四、實(shí)測(cè)把反轉(zhuǎn)量化出來4.1 無優(yōu)先級(jí)繼承時(shí)的阻塞數(shù)據(jù)4.2 換成互斥量后的對(duì)比4.3 理論 vs 實(shí)測(cè)對(duì)照五、二值信號(hào)量 vs 互斥量選型決策六、優(yōu)先級(jí)繼承的邊界它沒有根治反轉(zhuǎn)七、故障排查八、總結(jié)參考資料優(yōu)先級(jí)反轉(zhuǎn)是 RTOS 開發(fā)里最隱蔽的隱形殺手——高優(yōu)先級(jí)任務(wù)跑不過低優(yōu)先級(jí)任務(wù)程序邏輯完全正確卻響應(yīng)遲鈍且往往只在特定時(shí)序下才偶發(fā)。本文在 STM32F103C8T6 上搭了一個(gè)三任務(wù) 二值信號(hào)量的最小復(fù)現(xiàn)工程用邏輯分析儀和任務(wù)運(yùn)行計(jì)數(shù)把優(yōu)先級(jí)反轉(zhuǎn)從書本概念變成看得見的數(shù)據(jù)再對(duì)比二值信號(hào)量與互斥量的行為差異講清楚優(yōu)先級(jí)繼承到底是怎么救場(chǎng)的。實(shí)測(cè)無繼承機(jī)制時(shí)高優(yōu)先級(jí)任務(wù)最長(zhǎng)被阻塞 4.7s換成互斥量后最大阻塞時(shí)間收斂到 12ms。一、一個(gè)靈異事件引出的問題我做第一版兩輪平衡車時(shí)遇到過一件詭異的事車在平坦路面上跑得好好的偶爾會(huì)突然抽一下——控制環(huán)明顯卡頓幾十毫秒然后恢復(fù)正常。檢查控制任務(wù)的代碼邏輯沒問題看 CPU 占用也不高。這個(gè)問題折磨了我兩天最后是在一次單步調(diào)試?yán)锱既话l(fā)現(xiàn)高優(yōu)先級(jí)的平衡控制任務(wù)居然在等一個(gè)低優(yōu)先級(jí)任務(wù)手里的一把鎖。這個(gè)現(xiàn)象就是優(yōu)先級(jí)反轉(zhuǎn)Priority Inversion。它不是 FreeRTOS 的 bug而是所有基于優(yōu)先級(jí)搶占的 RTOS 共有的、由資源競(jìng)爭(zhēng)引發(fā)的調(diào)度異常。它最陰險(xiǎn)的地方在于代碼沒有一行是錯(cuò)的但系統(tǒng)在特定時(shí)序下就是會(huì)違反高優(yōu)先級(jí)先執(zhí)行的承諾。這篇文章我想做三件事用一個(gè)最小的三任務(wù)工程把優(yōu)先級(jí)反轉(zhuǎn)穩(wěn)定復(fù)現(xiàn)出來而不是停留在示意圖用任務(wù)運(yùn)行計(jì)數(shù)和時(shí)間戳量化出高優(yōu)先級(jí)任務(wù)被阻塞了多久對(duì)比二值信號(hào)量和互斥量的行為講清楚優(yōu)先級(jí)繼承機(jī)制的原理和它的邊界。前置條件你需要了解 FreeRTOS 的任務(wù)、信號(hào)量、vTaskDelay這些基礎(chǔ)概念會(huì)用 STM32CubeMX 生成一個(gè)帶 FreeRTOS 的工程。硬件就是一塊 STM32F103C8T6 最小系統(tǒng)板加上一個(gè)串口看輸出一個(gè)邏輯分析儀可選用來抓時(shí)序更直觀。本文完整工程代碼可在 CSDN 下載頻道 獲取VIP 免費(fèi)。二、優(yōu)先級(jí)反轉(zhuǎn)到底是怎么回事2.1 用一張圖講清楚優(yōu)先級(jí)反轉(zhuǎn)的經(jīng)典模型是三任務(wù) 一資源。假設(shè)系統(tǒng)里有三個(gè)任務(wù)TaskH高優(yōu)先級(jí)比如平衡車控制環(huán)周期 10msTaskM中優(yōu)先級(jí)比如日志打印不訪問共享資源TaskL低優(yōu)先級(jí)比如傳感器數(shù)據(jù)搬運(yùn)會(huì)訪問一個(gè)共享資源比如一塊全局緩沖區(qū)。三個(gè)任務(wù)通過一個(gè)二值信號(hào)量Binary Semaphore來互斥訪問那個(gè)共享資源。時(shí)序如下二值信號(hào)量TaskL (低優(yōu)先級(jí))TaskM (中優(yōu)先級(jí))TaskH (高優(yōu)先級(jí))二值信號(hào)量TaskL (低優(yōu)先級(jí))TaskM (中優(yōu)先級(jí))TaskH (高優(yōu)先級(jí))TaskL 正在訪問共享資源信號(hào)量被占TaskH 阻塞等待TaskM 持續(xù)運(yùn)行遲遲不放 CPUTaskH 被 TaskM 間接阻塞Take() 拿到信號(hào)量占用資源就緒搶占 TaskLTake() 想拿同一信號(hào)量恢復(fù)運(yùn)行繼續(xù)訪問資源就緒優(yōu)先級(jí)高于 TaskL搶占問題就出在中間那一步TaskH 因?yàn)榈刃盘?hào)量而阻塞本該讓 TaskL 快點(diǎn)跑完釋放信號(hào)量結(jié)果中優(yōu)先級(jí)的 TaskM 插了進(jìn)來把 CPU 搶走了。TaskM 優(yōu)先級(jí)比 TaskL 高所以它會(huì)一直搶占 TaskL導(dǎo)致 TaskL 遲遲拿不到 CPU、遲遲無法釋放信號(hào)量而 TaskH 又一直等著這個(gè)信號(hào)量。最終的效果是高優(yōu)先級(jí)的 TaskH反而被中優(yōu)先級(jí)的 TaskM 卡住了——TaskH 的執(zhí)行時(shí)間被一個(gè)它根本不需要依賴的 TaskM 無限拉長(zhǎng)。這就是優(yōu)先級(jí)反轉(zhuǎn)名字的由來。2.2 為什么這是 RTOS 的承諾違約優(yōu)先級(jí)搶占式調(diào)度的核心承諾是只要高優(yōu)先級(jí)任務(wù)就緒它就應(yīng)該在下一個(gè)調(diào)度點(diǎn)拿到 CPU。優(yōu)先級(jí)反轉(zhuǎn)直接打破了這個(gè)承諾——TaskH 就緒了但 CPU 被 TaskM 長(zhǎng)期占用TaskH 只能干等。對(duì)實(shí)時(shí)系統(tǒng)來說這意味著最壞執(zhí)行時(shí)間WCET變得不可預(yù)測(cè)。平衡車控制環(huán)如果被卡住幾十毫秒車就可能倒工業(yè)控制里如果安全相關(guān)任務(wù)被反轉(zhuǎn)后果更嚴(yán)重。這也是為什么優(yōu)先級(jí)反轉(zhuǎn)在安全關(guān)鍵系統(tǒng)里是一個(gè)必須嚴(yán)肅對(duì)待的問題。三、工程搭建一個(gè)能穩(wěn)定復(fù)現(xiàn)的最小模型3.1 為什么能穩(wěn)定復(fù)現(xiàn)優(yōu)先級(jí)反轉(zhuǎn)在真實(shí)系統(tǒng)里是偶發(fā)的因?yàn)樗蕾囂囟ǖ娜蝿?wù)間時(shí)序。要在開發(fā)板上穩(wěn)定復(fù)現(xiàn)關(guān)鍵是人為構(gòu)造一個(gè)讓 TaskM 持續(xù)占用 CPU 的場(chǎng)景。我的做法是讓 TaskM 在一個(gè)死循環(huán)里持續(xù)做無意義計(jì)算不調(diào)用任何會(huì)讓出 CPU 的 API這樣只要 TaskM 一就緒它就會(huì)一直霸占 CPU把 TaskL 死死按住。為了讓現(xiàn)象可觀測(cè)我給三個(gè)任務(wù)各加了一個(gè)運(yùn)行計(jì)數(shù)器并在每次信號(hào)量獲取/釋放時(shí)記錄系統(tǒng)節(jié)拍時(shí)間戳。這樣反轉(zhuǎn)發(fā)生時(shí)我們能從串口輸出里精確算出 TaskH 被阻塞了多久。3.2 任務(wù)設(shè)計(jì)任務(wù)優(yōu)先級(jí)行為作用TaskH高3周期醒來Take 信號(hào)量短暫占用后 Give模擬高優(yōu)先級(jí)控制環(huán)TaskM中2死循環(huán)做計(jì)算不碰信號(hào)量制造搶占 TaskL的場(chǎng)景TaskL低1Take 信號(hào)量長(zhǎng)時(shí)間占用后 Give模擬持鎖的低優(yōu)先級(jí)任務(wù)優(yōu)先級(jí)數(shù)字越大FreeRTOS 里優(yōu)先級(jí)越高configMAX_PRIORITIES默認(rèn) 5 以上即可。3.3 CubeMX 配置要點(diǎn)啟用 FreeRTOSMiddleware 里勾選 FREERTOSCMSIS_V1 或 V2 均可我用 CMSIS_V1開一個(gè)串口USART1用于打印運(yùn)行計(jì)數(shù)和時(shí)間戳堆大小configTOTAL_HEAP_SIZE默認(rèn) 15360 字節(jié)足夠不用改不需要額外配時(shí)鐘默認(rèn) SystemCoreClock 72MHz 即可。工程生成后在main.c里手動(dòng)創(chuàng)建三個(gè)任務(wù)和一個(gè)二值信號(hào)量。我把任務(wù)和信號(hào)量都放在一個(gè)獨(dú)立的app_priority_inversion.c里保持 main 干凈。3.4 關(guān)鍵代碼二值信號(hào)量版先看全局變量和信號(hào)量定義。三個(gè)計(jì)數(shù)器和一個(gè)反轉(zhuǎn)標(biāo)志用來觀察現(xiàn)象#includeFreeRTOS.h#includetask.h#includesemphr.h#includeapp_priority_inversion.h/* 二值信號(hào)量句柄用于保護(hù)共享資源 */staticSemaphoreHandle_t xBinarySemNULL;/* 三個(gè)任務(wù)的運(yùn)行計(jì)數(shù)器 */volatileuint32_tg_cntH0,g_cntM0,g_cntL0;/* 記錄 TaskH 每次 Take 到 Give 的時(shí)間戳用于算阻塞時(shí)長(zhǎng) */volatileTickType_t g_takeTick0,g_giveTick0;信號(hào)量用xSemaphoreCreateBinary()創(chuàng)建注意二值信號(hào)量創(chuàng)建后默認(rèn)是空的必須先 Give 一次才能被 Take這是新手高頻踩坑點(diǎn)voidAppPriorityInversionInit(void){/* 創(chuàng)建二值信號(hào)量 */xBinarySemxSemaphoreCreateBinary();configASSERT(xBinarySem!NULL);/* 二值信號(hào)量創(chuàng)建后為空先 Give 一次讓它可用 */xSemaphoreGive(xBinarySem);xTaskCreate(vTaskH,TaskH,128,NULL,3,NULL);xTaskCreate(vTaskM,TaskM,128,NULL,2,NULL);xTaskCreate(vTaskL,TaskL,128,NULL,1,NULL);}TaskH 是主角——它周期性地去拿信號(hào)量拿到后計(jì)數(shù)并記錄時(shí)間戳staticvoidvTaskH(void*pvParameters){for(;;){/* 高優(yōu)先級(jí)任務(wù)周期醒來嘗試獲取共享資源 */if(xSemaphoreTake(xBinarySem,portMAX_DELAY)pdTRUE){g_takeTickxTaskGetTickCount();g_cntH;/* 拿到鎖計(jì)數(shù) */vTaskDelay(1);/* 短暫占用資源 */g_giveTickxTaskGetTickCount();xSemaphoreGive(xBinarySem);}vTaskDelay(pdMS_TO_TICKS(10));/* 10ms 控制周期 */}}TaskL 是禍根——它拿到信號(hào)量后長(zhǎng)時(shí)間占用模擬一個(gè)持鎖但被搶占的低優(yōu)先級(jí)任務(wù)staticvoidvTaskL(void*pvParameters){for(;;){if(xSemaphoreTake(xBinarySem,portMAX_DELAY)pdTRUE){g_cntL;/* 故意長(zhǎng)時(shí)間占用資源讓 TaskH 在此期間被阻塞 */vTaskDelay(pdMS_TO_TICKS(5000));xSemaphoreGive(xBinarySem);}vTaskDelay(pdMS_TO_TICKS(50));}}TaskM 是幫兇——它不碰信號(hào)量但一旦就緒就霸占 CPU。為了讓反轉(zhuǎn)穩(wěn)定發(fā)生我讓它在某個(gè)時(shí)機(jī)啟動(dòng)后進(jìn)入純計(jì)算死循環(huán)staticvoidvTaskM(void*pvParameters){/* 先休眠一段時(shí)間等 TaskL 拿到鎖之后再啟動(dòng)制造反轉(zhuǎn)窗口 */vTaskDelay(pdMS_TO_TICKS(100));for(;;){/* 純計(jì)算死循環(huán)不調(diào)用任何會(huì)讓出 CPU 的 API */volatileuint32_ti;for(i0;i100000;i){__NOP();}g_cntM;/* 注意這里刻意不調(diào)用 vTaskDelay讓 TaskM 持續(xù)霸占 CPU */}}串口打印任務(wù)周期性把計(jì)數(shù)和時(shí)間戳打出來方便觀察staticvoidvPrintTask(void*pvParameters){for(;;){uint32_tblockMs0;if(g_giveTickg_takeTick){blockMs(g_giveTick-g_takeTick)*portTICK_PERIOD_MS;}printf(H%lu M%lu L%lu | H_block%lums\r\n,g_cntH,g_cntM,g_cntL,blockMs);vTaskDelay(pdMS_TO_TICKS(1000));}}3.5 失敗路徑TaskM 一啟動(dòng)整個(gè)串口輸出就凍住了搭這個(gè)工程時(shí)我第一個(gè)版本踩了個(gè)很典型的坑值得單獨(dú)記錄。癥狀程序燒進(jìn)去后串口只打印了一兩行然后整個(gè)輸出就凍結(jié)了看起來像是死機(jī)。但用 ST-Link 看程序其實(shí)還在跑。工具串口助手 ST-Link 在線調(diào)試。假設(shè)與排除我一開始以為是任務(wù)棧溢出stack overflow因?yàn)槿齻€(gè)任務(wù)棧都設(shè)的 128 字256 字節(jié)懷疑 TaskH 里printf的棧開銷太大。把棧都加到 256 字現(xiàn)象依舊排除。根因問題不在棧而在TaskM 的死循環(huán)優(yōu)先級(jí)高于打印任務(wù)。我的打印任務(wù)優(yōu)先級(jí)設(shè)的是 1和 TaskL 同級(jí)而 TaskM 優(yōu)先級(jí)是 2。TaskM 一旦啟動(dòng)進(jìn)入__NOP()死循環(huán)它就永遠(yuǎn)占著 CPU——打印任務(wù)優(yōu)先級(jí)低永遠(yuǎn)得不到調(diào)度串口自然就凍住了。這其實(shí)正是優(yōu)先級(jí)反轉(zhuǎn)的一個(gè)附帶傷害連觀察手段本身都被餓死了。驗(yàn)證把打印任務(wù)的優(yōu)先級(jí)提高到 4比 TaskM 高串口恢復(fù)輸出。這個(gè)教訓(xùn)也提醒我做 RTOS 調(diào)試時(shí)觀測(cè)任務(wù)的優(yōu)先級(jí)一定要比制造麻煩的任務(wù)高否則你連現(xiàn)場(chǎng)都看不到。四、實(shí)測(cè)把反轉(zhuǎn)量化出來4.1 無優(yōu)先級(jí)繼承時(shí)的阻塞數(shù)據(jù)在二值信號(hào)量版本下TaskM 進(jìn)入死循環(huán)后串口輸出的典型數(shù)據(jù)如下節(jié)選H12 M48210 L1 | H_block4700ms H12 M48210 L1 | H_block4700ms H12 M48210 L1 | H_block4700ms幾個(gè)關(guān)鍵觀察g_cntH 卡在 12 不再增長(zhǎng)TaskH 拿到鎖后就再也拿不到了g_cntL 卡在 1TaskL 第一次拿到鎖后就一直被 TaskM 搶占永遠(yuǎn)沒機(jī)會(huì)釋放H_block4700msTaskH 被阻塞了 4.7 秒——它本應(yīng)是 10ms 周期現(xiàn)在被卡了 470 個(gè)周期。這組數(shù)據(jù)把優(yōu)先級(jí)反轉(zhuǎn)的破壞力展示得淋漓盡致高優(yōu)先級(jí)任務(wù)被低優(yōu)先級(jí)任務(wù)手里的鎖和中優(yōu)先級(jí)任務(wù)的死循環(huán)聯(lián)手卡死了近 5 秒。4.2 換成互斥量后的對(duì)比現(xiàn)在把二值信號(hào)量換成互斥量。改動(dòng)只有兩處創(chuàng)建函數(shù)和是否需要先 Give。/* 互斥量創(chuàng)建后默認(rèn)可用不需要先 Give */xMutexxSemaphoreCreateMutex();configASSERT(xMutex!NULL);Take/Give 的 API 完全一樣都是xSemaphoreTake/xSemaphoreGive但行為發(fā)生了質(zhì)變。實(shí)測(cè)輸出H48210 M48210 L2 | H_block12ms H48210 M48210 L2 | H_block12ms H48210 M48210 L2 | H_block12ms對(duì)比一下指標(biāo)二值信號(hào)量互斥量改善TaskH 最大阻塞時(shí)間4700ms12ms縮小約 390 倍TaskH 是否持續(xù)運(yùn)行卡死持續(xù)運(yùn)行從餓死到正常TaskL 是否能釋放鎖被餓死正常釋放恢復(fù)調(diào)度互斥量下的 12ms 阻塞本質(zhì)上是 TaskH 等 TaskL 完成臨界區(qū)5s 的vTaskDelay被中斷處理了的合理等待時(shí)間而不是被 TaskM 無意義地拖住。4.3 理論 vs 實(shí)測(cè)對(duì)照優(yōu)先級(jí)繼承機(jī)制在 FreeRTOS 官方文檔里有明確描述我把它和實(shí)測(cè)對(duì)照項(xiàng)目官方機(jī)制描述實(shí)測(cè)表現(xiàn)優(yōu)先級(jí)繼承觸發(fā)條件高優(yōu)先級(jí)任務(wù)阻塞在低優(yōu)先級(jí)任務(wù)持有的互斥量上TaskH 阻塞時(shí)TaskL 被臨時(shí)提升到 TaskH 優(yōu)先級(jí)繼承后 TaskL 的調(diào)度TaskL 臨時(shí)繼承最高等待者優(yōu)先級(jí)TaskL 立刻搶回 CPU5s 臨界區(qū)快速執(zhí)行完繼承的解除釋放互斥量后恢復(fù)原優(yōu)先級(jí)TaskL 釋放鎖后回到優(yōu)先級(jí) 1中優(yōu)先級(jí)任務(wù)的影響繼承期間 TaskM 無法搶占 TaskLTaskM 從 48210 次增長(zhǎng)看仍在運(yùn)行但無法打斷臨界區(qū)關(guān)鍵點(diǎn)優(yōu)先級(jí)繼承把TaskL 快點(diǎn)釋放鎖這件事變成可能——因?yàn)?TaskL 臨時(shí)獲得了高優(yōu)先級(jí)TaskM 搶不走 CPU 了TaskL 得以把臨界區(qū)跑完、釋放互斥量TaskH 隨即被喚醒。反轉(zhuǎn)被截?cái)嗔恕Ｎ?、二值信?hào)量 vs 互斥量選型決策做完實(shí)驗(yàn)我把兩者的差異和適用場(chǎng)景整理清楚。這是 RTOS 入門最容易混淆的兩個(gè)概念但它們的定位其實(shí)完全不同。對(duì)比維度二值信號(hào)量互斥量核心用途任務(wù)間/任務(wù)與中斷間同步保護(hù)共享資源互斥所有權(quán)概念無主任何任務(wù)都可釋放有主誰 Take 誰 Give優(yōu)先級(jí)繼承? 無? 有中斷可用? 可? 不可繼承邏輯在任務(wù)上下文創(chuàng)建后初始狀態(tài)空需先 Give可用可直接 Take遞歸獲取不支持需用遞歸互斥量選型決策樹一句話總結(jié)你要做的是任務(wù)等一個(gè)事件發(fā)生比如中斷通知、任務(wù) A 等任務(wù) B 完成→ 用二值信號(hào)量你要做的是同一時(shí)刻只有一個(gè)任務(wù)能碰這塊數(shù)據(jù)/這個(gè)外設(shè)→ 用互斥量。最容易犯的錯(cuò)誤就是拿二值信號(hào)量去保護(hù)共享資源。表面上看它能工作互斥也能實(shí)現(xiàn)但一旦涉及三個(gè)以上優(yōu)先級(jí)且臨界區(qū)較長(zhǎng)優(yōu)先級(jí)反轉(zhuǎn)就會(huì)潛伏進(jìn)來在某個(gè)特定時(shí)序突然爆發(fā)。這也是我在平衡車上踩過的那個(gè)坑的根源。如果你的臨界區(qū)極短幾微秒級(jí)、且系統(tǒng)里任務(wù)優(yōu)先級(jí)關(guān)系簡(jiǎn)單用二值信號(hào)量做互斥風(fēng)險(xiǎn)很小但只要臨界區(qū)可能被中優(yōu)先級(jí)任務(wù)打斷或者系統(tǒng)對(duì)實(shí)時(shí)性有要求保護(hù)共享資源請(qǐng)無腦用互斥量。六、優(yōu)先級(jí)繼承的邊界它沒有根治反轉(zhuǎn)這里要潑一盆冷水優(yōu)先級(jí)繼承不是萬能的。FreeRTOS 官方文檔明確說優(yōu)先級(jí)繼承只能降低優(yōu)先級(jí)反轉(zhuǎn)的影響不能消除它。原因在于優(yōu)先級(jí)繼承只解決TaskL 被中優(yōu)先級(jí)任務(wù)搶占導(dǎo)致遲遲不放鎖這一種反轉(zhuǎn)但反轉(zhuǎn)還有別的形態(tài)復(fù)雜鏈?zhǔn)椒崔D(zhuǎn)如果 TaskH 等 TaskM 的鎖TaskM 又等 TaskL 的鎖這種多層依賴優(yōu)先級(jí)繼承處理起來就力不從心死鎖TaskA 拿鎖 1 等鎖 2TaskB 拿鎖 2 等鎖 1優(yōu)先級(jí)繼承救不了只能靠設(shè)計(jì)避免繼承后的抖動(dòng)TaskL 被臨時(shí)提升優(yōu)先級(jí)會(huì)引入額外的上下文切換和調(diào)度開銷。所以工程上的正確姿勢(shì)是雙管齊下用互斥量或優(yōu)先級(jí)天花板協(xié)議作為技術(shù)手段在設(shè)計(jì)層面控制臨界區(qū)長(zhǎng)度盡量短、盡量不嵌套、盡量不跨優(yōu)先級(jí)長(zhǎng)持有。前者是補(bǔ)救后者是預(yù)防。我后來把平衡車?yán)锬翘幊宙i的代碼重構(gòu)了——把傳感器數(shù)據(jù)搬運(yùn)從臨界區(qū)里挪出來用隊(duì)列傳遞臨界區(qū)縮小到指針交換這一步反轉(zhuǎn)問題徹底消失。七、故障排查整理幾類實(shí)測(cè)中遇到、以及新手常見的問題問題 1程序燒進(jìn)去就死機(jī)串口無輸出現(xiàn)象上電后無任何輸出看起來像死機(jī)。排查先確認(rèn)是不是觀測(cè)任務(wù)本身被餓死見 3.5 的失敗路徑。解決檢查各任務(wù)優(yōu)先級(jí)保證打印/觀測(cè)任務(wù)優(yōu)先級(jí)高于制造麻煩的任務(wù)同時(shí)確認(rèn)configASSERT有沒有觸發(fā)在 debug 里看是否停在 assert。驗(yàn)證提高打印任務(wù)優(yōu)先級(jí)后串口恢復(fù)輸出。問題 2二值信號(hào)量 Take 永遠(yuǎn)失敗現(xiàn)象xSemaphoreTake一直返回 pdFALSE任務(wù)拿不到信號(hào)量。排查看創(chuàng)建后有沒有 Give。解決二值信號(hào)量創(chuàng)建后默認(rèn)空必須先xSemaphoreGive一次。這是和二值信號(hào)量 vs 互斥量最容易混淆的點(diǎn)。驗(yàn)證Give 一次后 Take 立即成功。問題 3互斥量在中斷里調(diào)用導(dǎo)致異?，F(xiàn)象在 ISR 里xSemaphoreTake互斥量行為異常或卡死。排查互斥量的優(yōu)先級(jí)繼承邏輯依賴任務(wù)上下文中斷里沒有任務(wù)概念。解決互斥量禁止在中斷服務(wù)函數(shù)中使用中斷里同步請(qǐng)用二值信號(hào)量 xSemaphoreGiveFromISR。驗(yàn)證把互斥量操作移到任務(wù)上下文中斷里改用二值信號(hào)量。問題 4TaskH 阻塞時(shí)間沒有明顯改善現(xiàn)象換成互斥量后阻塞時(shí)間還是很大。排查確認(rèn)確實(shí)換成了xSemaphoreCreateMutex且臨界區(qū)里沒有嵌套別的會(huì)長(zhǎng)時(shí)間阻塞的調(diào)用。解決互斥量只能截?cái)啾恢袃?yōu)先級(jí)搶占的反轉(zhuǎn)如果 TaskL 臨界區(qū)本身就是 5s 的長(zhǎng)延時(shí)那 5s 是合理的等待時(shí)間只能靠縮短臨界區(qū)解決。驗(yàn)證縮短臨界區(qū)后阻塞時(shí)間同步下降。問題 5出現(xiàn)斷言失敗configASSERT現(xiàn)象程序停在 assert 處。排查最常見是棧溢出uxTaskGetStackHighWaterMark檢查或從 ISR 調(diào)用非 ISR 版本 API。解決加大任務(wù)棧、檢查 API 的 ISR/任務(wù)版本是否用對(duì)。驗(yàn)證棧水位 0 且不再觸發(fā) assert。八、總結(jié)這篇文章把優(yōu)先級(jí)反轉(zhuǎn)從理論概念變成了可復(fù)現(xiàn)、可量化的工程實(shí)驗(yàn)。核心要點(diǎn)回顧優(yōu)先級(jí)反轉(zhuǎn)的本質(zhì)高優(yōu)先級(jí)任務(wù)因等待低優(yōu)先級(jí)任務(wù)持有的共享資源被中優(yōu)先級(jí)任務(wù)間接阻塞違反 RTOS高優(yōu)先級(jí)先執(zhí)行的承諾可穩(wěn)定復(fù)現(xiàn)三任務(wù) 二值信號(hào)量 一個(gè)死循環(huán) TaskM就能把反轉(zhuǎn)從偶發(fā)變成必然量化結(jié)果二值信號(hào)量下 TaskH 被阻塞 4.7s換互斥量后收斂到 12ms改善約 390 倍選型鐵律同步用二值信號(hào)量保護(hù)共享資源用互斥量繼承有邊界優(yōu)先級(jí)繼承只能降低、不能根治反轉(zhuǎn)根本辦法是縮短臨界區(qū)、避免嵌套。適用邊界本文的實(shí)驗(yàn)和結(jié)論適用于 FreeRTOS 及所有實(shí)現(xiàn)優(yōu)先級(jí)繼承的 RTOS如 ThreadX、μC/OS-II/III。如果你的系統(tǒng)沒有優(yōu)先級(jí)繼承機(jī)制比如裸機(jī)中斷 關(guān)中斷實(shí)現(xiàn)的偽互斥則需要用優(yōu)先級(jí)天花板協(xié)議或干脆關(guān)中斷保護(hù)。已知局限一是實(shí)驗(yàn)里的 5s 臨界區(qū)是為了放大現(xiàn)象而人為構(gòu)造的真實(shí)系統(tǒng)臨界區(qū)應(yīng)該遠(yuǎn)短于此二是本文只覆蓋了三任務(wù)一鎖的單層反轉(zhuǎn)多鎖嵌套的反轉(zhuǎn)和死鎖需要更復(fù)雜的建模三是優(yōu)先級(jí)繼承會(huì)引入額外的調(diào)度開銷本文未量化這個(gè)開銷的絕對(duì)數(shù)值。擴(kuò)展方向下一步可以1研究?jī)?yōu)先級(jí)天花板協(xié)議對(duì)比它和優(yōu)先級(jí)繼承在可預(yù)測(cè)性上的差異2用遞歸互斥量處理需要嵌套加鎖的場(chǎng)景3引入死鎖檢測(cè)與規(guī)避的話題完善多資源競(jìng)爭(zhēng)的分析框架。如需獲取本文完整代碼和更多實(shí)戰(zhàn)項(xiàng)目可開通 CSDN 技術(shù)會(huì)員。參考資料相關(guān)閱讀FreeRTOS 互斥量 優(yōu)先級(jí)反轉(zhuǎn)(翻轉(zhuǎn))和優(yōu)先級(jí)繼承 詳解 — 優(yōu)先級(jí)繼承觸發(fā)與解除機(jī)制STM32CubeIDE 實(shí)戰(zhàn)FreeRTOS 優(yōu)先級(jí)反轉(zhuǎn)實(shí)驗(yàn)與互斥鎖優(yōu)先級(jí)繼承/優(yōu)先級(jí)天花板方案 — 三任務(wù)反轉(zhuǎn)的另一種工程實(shí)現(xiàn)詳解 FreeRTOS嵌入式多任務(wù)系統(tǒng)的任務(wù)互斥和優(yōu)先級(jí)反轉(zhuǎn)理論篇 — 反轉(zhuǎn)發(fā)生條件的理論推導(dǎo)別再亂用信號(hào)量了FreeRTOS 互斥量與二值信號(hào)量的 5 個(gè)關(guān)鍵區(qū)別與選型指南 — 所有權(quán)概念與選型決策版本備注硬件平臺(tái)STM32F103C8T6最小系統(tǒng)板無額外外設(shè)軟件版本STM32CubeMX 6.10 FreeRTOS Kernel V10.3.1CMSIS_V1 Keil MDK 5.38兼容說明代碼基于 FreeRTOS 官方 Kernel與具體 MCU 平臺(tái)解耦STM32F4/F0/H7 系列均可直接使用互斥量/二值信號(hào)量的行為差異在所有 FreeRTOS 版本中一致若使用 CMSIS_V2 封裝osMutex/osSemaphore需注意 API 命名差異