在基於優先級搶佔的實時操作系統（RTOS）中，優先級反轉 是最隱蔽也最致命的問題之一。本文通過時序圖解析反轉成因，並展示優先級繼承協議如何從根源解決。
場景設定
- 三個任務：
Task1 (高) > Task2 (中) > Task3 (低)
- 共享資源受二值信號量保護
- 初始狀態：Task1/Task2 掛起等待事件，Task3 運行中
優先級反轉完整時序（12 步）
- Task3 獲取信號量，進入臨界區使用共享資源
- Task1 事件就緒，搶佔 Task3 開始運行
- Task1 嘗試獲取同一信號量 → 失敗 → 掛起等待
- Task3 恢復運行，繼續臨界區工作
- Task2 事件就緒，搶佔 Task3（因優先級高於 Task3）
- Task2 執行任意長時間工作（與共享資源無關）
- Task2 完成，Task3 再次恢復
- Task3 釋放信號量，退出臨界區
- 內核檢測到 Task1 等待該信號量 → 切換至 Task1
- Task1 獲取信號量，開始關鍵工作
災難性後果： Task1（最高優先級）被 Task2（中優先級）間接阻塞了任意長時間！Task1 實際優先級「反轉」降至 Task3 水平，甚至更差。
優先級繼承協議解決方案
核心規則： 當高優先級任務因信號量被低優先級任務阻塞時，暫時將持有信號量的低優先級任務提升至高優先級，直到釋放信號量。
修正後時序（9 步）
- Task3 獲取信號量，進入臨界區
- Task1 搶佔，嘗試獲取信號量失敗
- 內核檢測到反轉風險 → 將 Task3 優先級提升至 Task1 級別
- Task3 以高優先級繼續執行，Task2 無法搶佔（因 Task3 現優先級 > Task2）
- Task3 釋放信號量
- 內核恢復 Task3 原始優先級，將信號量授予 Task1
- Task1 立即運行，Task2 只能在 Task1 完成後才能獲得 CPU
關鍵對比
| 指標 | 無保護 | 優先級繼承 |
|---|
| 高優任務最大阻塞時間 | 非確定性（受中優任務影響） | 僅受低優任務臨界區長度影響 |
| 中優任務干擾 | 可任意延遲高優任務 | 完全阻隔 |
| 實現複雜度 | 無 | 內核需支援動態優先級修改 |
|---|
工程落地提示
- μC/OS-II 預設不支援優先級繼承（僅有優先級天花板可選）
- 商業級 RTOS（VxWorks、QNX、FreeRTOS 配置開啟）均內建支援
- 臨界區應極短，避免長時間持有鎖、調用阻塞 API、動態分配內存
- 替代方案：優先級天花板協議（PCP），預先將信號量優先級設為所有可能使用者的最高優先級，無需運行時動態調整
總結
優先級反轉是實時系統「理論優先級」與「實際執行優先級」脫節的典型案例。優先級繼承通過動態優先級提升消除中優任務干擾，是硬實時系統必備的內核特性。選型 RTOS 時，務必確認是否支援 PI/PCP 協議。
