在嵌入式系統中，如果使用基于優先級調度算法的RTOS，系統中可能發生優先級反轉現象。優先級反轉用來描述系統中高優先級任務由于等待低優先級任務完成才能繼續執行的情景，通常發生在試圖獲取信號量使用權或共享資源時。優先級反轉可能會導致嚴重的后果。在小型嵌入式系統設計中，我們需要考慮如何訪問共享資源，避免資源競爭，防止優先級反轉發生。

本文將介紹如何通過分析工具檢測OPENRTOS(FreeRTOS)應用中的優先級反轉現象，如何最小化優先級反轉的影響，及如何在設計中避免優先級反轉問題。

使用Tracealyzer工具檢測優先級反轉現象

Tracealyzer是一個可視化分析工具，以圖形化的方式展示事件發生的序列。我們通過一個Percepio公司的示例說明如何使用Tracealyzer檢測優先級反轉問題。應用中存在一個隨機復位問題，在復位異常處理中設置斷點，發現該問題是由于看門狗定時器超時引起的，看門狗定時器應該在一個周期運行的高優先任務中重置。

插入自定義Tracealyzer用戶事件幫助工程師獲得更大的能見度。“用戶事件”類似于經典的“printf()”調用。在此示例中，在看門狗計時器被重置或超時位置添加用戶事件。用戶事件還支持數據參數，記錄重置之前的計時器值，以查看看門狗“margin”，即剩下的時間。捕獲結果如圖1所示。

圖1 用戶事件示例

從圖中我們可以看到SamplerTask任務正常運行，但任務在最后一個執行過程中沒有清除看門狗計時器，導致看門狗重置事件發生。SamplerTask為什么沒有復位看門狗定時器？在Tracealyzer中使能Kernel Service calls，查看任務當前在執行什么操作，捕獲結果如圖2所示。

圖2 系統服務調用示例

SamplerTask任務的最后一個動作是調用OPENRTOS函數xQueueSend，將消息放入消息隊列中。注意，該標簽顯示為紅色，表示xQueueSend 函數將阻塞任務，任務阻塞導致看門狗定時器復位之前，任務切換至ServerTask，從而導致看門狗超時，引起系統復位。

為什么xQueueSend阻塞了任務？雙擊此事件標簽，打開Object History視圖，顯示xQueueSend函數操作隊列“ControlQueue”的所有操作，如圖3所示。圖中最右邊一列展示了隊列存儲的消息。可以看到消息隊列已經包含五個消息，隊列已滿，因此xQueueSend操作引起任務阻塞。但ControlTask任務應該讀取隊列數據并清空隊列緩沖區，為什么預期的行為沒有發生？

圖3 Object history視圖

研究該問題，分析看門狗的margin如何隨時間而變化。這些信息記錄在User Event Logging中，使用User Event Signal Plot，我們可以繪制看門狗margin隨時間的變化。在同一時間軸上添加CPU負載圖，我們可以看到任務執行如何影響看門狗margin，如圖4所示。

圖4 User event Single slot視圖

在CPU負載圖中，我們可以看到跟蹤的后半部分，ServerTask執行消耗了約一半的跟蹤時間，這似乎影響了看門狗的margin。ServerTask任務（亮綠色）比ControlTask任務（深綠色）優先級高，所以當ServerTask任務消耗更多CPU時間后，ControlTask任務得到的CPU減少。由于高優先級的ServerTask任務占用了許多CPU時間，導致ControlTask無法及時讀取消息隊列中的數據。這是優先反轉問題的一個例子，SamplerTask任務被不相關的低優先級任務阻塞。

解決方案

更改任務優先級

一種解決辦法是改變優先級，使ControlTask任務的優先級高于ServerTask。圖5顯示了交換兩個任務調度優先級后的運行結果。系統行為更穩定。SamplerTask任務（紅色）的CPU負載穩定在20%左右，其周期行為穩定，看門狗margin為一條“線”，維持在10毫秒。看門狗不會超時-問題解決了！（注意：任務由于優先級改變，對應的顯示顏色也發生了變化）。

圖5 交換ServerTask與ControlTask優先級結果

使用互斥信號量

當多個任務訪問同一資源時，例如網絡驅動或圖形顯示，可能會發生優先級反轉。這種情況下，可以使用互斥信號量降低優先級反轉的影響。

互斥信號量是包含優先級繼承機制的二值信號量，二值信號量更適合實現任務間或任務與中斷服務之間的同步操作，互斥信號量更適用于互斥實現。

用作互斥機制時，互斥信號量相當于一個令牌，保護共享資源。當任務希望訪問該共享資源時，需要首先獲得（“take”）令牌。資源使用完后，任務必須釋放令牌，讓其它任務可以訪問相同的資源。

互斥信號量允許指定阻塞時間，阻塞時間指示一個任務在嘗試獲取令牌時，如果令牌不可用，任務可以阻塞的最大節拍數。然而，與二值信號量的區別在于，互斥量支持優先級繼承機制。這意味著，如果有一個高優先級的任務在試圖獲取當前持有令牌的低優先級任務占用的資源時，系統會臨時提升占有資源的任務優先級別為被阻塞任務的優先級。該機制確保高優先級的阻塞時間盡量短，從而盡量減少優先級反轉的時間。

優先級繼承并不能解決優先級反轉問題，它只是最小化了反轉在某些情況下產生的影響。硬實時應用設計時，需保證優先級反轉不會發生。

使用Gatekeeper任務

在訪問系統資源時，為了避免優先級反轉問題，我們推薦使用“Gatekeeper”任務。Gatekeeper任務結構如圖6所示，包含一個控制資源的任務，接收數據/命令的隊列和一個回調函數。

應用任務不直接訪問資源，而是將數據/命令寫入隊列。Gatekeeper任務處理接收到的數據/命令，并相應地更新資源。資源狀態發生改變時，將觸發ISR (例如接收到一個新的網絡消息)，將信息放置在隊列中，然后，Gatekeeper任務將執行回調函數，將新的數據傳給應用任務。

此方法防止了系統資源訪問時優先級反轉的出現，是我們推薦的解決辦法。

圖6 Gatekeeper任務

結論

使用實時內核，優先級反轉問題是實時系統中出現得非常多的問題。在嵌入式系統系統設計時，應盡量避免優先級反轉發生，或者可以通過可視化分析工具捕獲該問題，通過相應的RTOS方法降低其風險。

審核編輯：湯梓紅