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

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

使用Tracealyzer工具檢測優(yōu)先級反轉現(xiàn)象

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

插入自定義Tracealyzer用戶事件幫助工程師獲得更大的能見度?！坝脩羰录鳖愃朴诮?jīng)典的“printf()”調用。在此示例中，在看門狗計時器被重置或超時位置添加用戶事件。用戶事件還支持數(shù)據(jù)參數(shù)，記錄重置之前的計時器值，以查看看門狗“margin”，即剩下的時間。捕獲結果如圖1所示。

圖1 用戶事件示例

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

圖2 系統(tǒng)服務調用示例

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

為什么xQueueSend阻塞了任務？雙擊此事件標簽，打開Object History視圖，顯示xQueueSend函數(shù)操作隊列“ControlQueue”的所有操作，如圖3所示。圖中最右邊一列展示了隊列存儲的消息?？梢钥吹较㈥犃幸呀?jīng)包含五個消息，隊列已滿，因此xQueueSend操作引起任務阻塞。但ControlTask任務應該讀取隊列數(shù)據(jù)并清空隊列緩沖區(qū)，為什么預期的行為沒有發(fā)生？

圖3 Object history視圖

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

圖4 User event Single slot視圖

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

解決方案

更改任務優(yōu)先級

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

圖5 交換ServerTask與ControlTask優(yōu)先級結果

使用互斥信號量

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

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

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

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

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

使用Gatekeeper任務

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

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

此方法防止了系統(tǒng)資源訪問時優(yōu)先級反轉的出現(xiàn)，是我們推薦的解決辦法。

圖6 Gatekeeper任務

結論

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

審核編輯：湯梓紅