本文將基于RT-Thread，結合 RT-Trace 調試器細化到實際任務調度的粒度，來調試并逐步講解“優先級反轉”的調度和運行邏輯。如果對 RT-Trace 感興趣的可以看這篇文章：

國產嵌入式調試器之光？ RT-Trace 初體驗!

廢話不多說，我們直接開始。本文基于 RT-Thread 來編寫測試代碼。在此之前我們先捋一下代碼流程：

優先級反轉問題的本質是高優先級任務因等待低優先級任務釋放資源而被阻塞，同時又有其他中優先級任務搶占了 CPU，使得低優先級任務得不到執行機會，進而導致高優先級任務長時間無法繼續運行。

因此我們需要建立三個不同優先級的任務，然后需要有一個資源鎖來模擬實際場景下對共享資源的獲取與釋放。一般在 RTOS 中我們會使用互斥鎖來對資源進行上鎖，因此絕大多數的 RTOS 已經為互斥鎖這個組件加入了優先級繼承等應對優先級反轉問題的功能，包括 RT-Thread（RTT 的互斥鎖還具備優先級天花板功能），所以如果我們就是想觀察優先級反轉的現象，直接使用互斥鎖是不行的。

幸運的是，在 RT-Thread 中，還有一個線程間同步組件，其是不帶優先級繼承等功能的，并且在我們目前的場景中也可以作為資源鎖來使用，這就是二值信號量。（特別注意，這邊使用二值信號量作為資源鎖只是用于觀察優先級反轉這種異?，F象，并且也正是因為其存在這個問題，實際項目中并不推薦這么使用?。?/strong>

綜上，我們的測試代碼主體就是三個不同優先級的任務，加上一個資源鎖。且我們要測試三種情況，分別是用信號量實現優先級反轉，用互斥鎖實現優先級繼承，在互斥鎖的基礎上通過設置天花板優先級來實現優先級天花板機制，整體測試代碼如下：

#include"rtdef.h"#include"rttypes.h"#include#include#include#include#ifndefRT_USING_NANO#include#endif/* RT_USING_NANO *//* defined the LED0 pin: PB1 */#defineTHREAD_PRIORITY 10#defineUSE_MUTEX 0#defineUSE_PRIORITY_CEILING 0#ifUSE_MUTEXrt_mutex_tmutex;#elsert_sem_tsem;#endifstaticvoidworking(uint32_tnms){ for(volatileuint32_ti =0; i < nms; i++) {? ? ? ? for?(volatileuint32_t?j =?0; j

以上代碼動態創建了三個任務：th、tm和tl，分別對應高優先級（9），中優先級（10）和低優先級（11），在 RT-Thread 中優先級數字越小越高。同時還基于條件編譯定義了一個資源鎖，當USE_MUTEX為0時使用信號量作為鎖，用于制造優先級反轉，為1且USE_PRIORITY_CEILING為0時使用互斥鎖實現優先級繼承，USE_MUTEX以及USE_PRIORITY_CEILING都為1時實現優先級天花板策略。

working 函數本質上是制造一段時間的延遲用于模擬任務的工作流程，此處沒有使用 rt_thread_mdelay 延時的原因是 rt_thread_mdelay 會造成任務本身主動讓出，從而無法實現真實情況下高優先級在低優先級任務運行中的搶占過程。

th 任務首先使用 rt_thread_mdelay 延遲主動讓出使得低優先級任務能夠先運行從而獲取到資源，緊接著嘗試獲取資源，獲取到后使用 working 函數模擬對資源進行的操作，最后釋放資源。

tm 任務首先使用 rt_thread_mdelay 延遲主動讓出使得高優先級任務能夠有時間運行到嘗試獲取資源并阻塞，從而能夠成功制造出中優先級對低優先級任務的搶占。緊接著使用working函數模擬其運行。注意，該任務中沒有任何對資源的操作，也不會獲取與釋放鎖。

tl 任務開始運行后立馬嘗試獲取資源，進而使用working函數模擬對資源進行的操作，接著釋放資源，最后再次使用working函數模擬該任務的其他操作。

在開啟了優先級天花板機制的情況下，互斥鎖創建后會使用 rt_mutex_setprioceiling 為其設置一個天花板優先級，在這里也就是 THREAD_PRIORITY - 2，雖然我們所有任務的最高優先級為 THREAD_PRIORITY - 1，由于 RT-Thread 存在時間片輪轉調度功能，同優先級任務在時間片用完之后也能互相搶占。此處也可以設置一個比較大的時間片來臨時防止搶占，我這里就直接將該優先級設置為更高一級，從根本上避免搶占的發生。

OK，所有功能點都講解完成，接下來我們就借助 RT-Trace 的運行跟蹤功能，進入 CPU 視角，來看看底層的真實運行情況。

首先是使用信號量實現的優先級反轉場景，我們重點關注三個任務之間的運行，屏蔽掉中斷，空閑線程等其他信息：

可以看到 tl 在開始運行了一段時間后 th 發生了搶占并嘗試獲取資源，但由于當前資源被 tl 持有，于是 th 立馬阻塞讓出了 CPU 等待 tl 釋放資源：

然而還沒等 tl 釋放資源，中等優先級的 tm 就搶占了 tl 的運行，此時 th 雖有著最高優先級，但也只能眼睜睜等著 tm 執行完，因為要等 tl 釋放資源它才能運行，但 tl 優先級沒有 tm 高，當前情況下 tm 不運行完， tl 根本不會運行：

等 tm 終于運行完了，把 CPU 給到 tl，并且 tl 釋放了資源后，本應是最高優先級的 th 才得以運行：

由于低優先級任務持有了高優先級任務運行所需的共享資源，從而導致高優先級任務不可避免地進入等待，而當系統比較復雜，任務較多時，低優先級任務又特別容易被其他中優先級任務搶占，最終導致高優先級任務被無限延后，直至所有搶占的任務運行完并且低優先級任務釋放資源才得以運行，而這個過程需要等待多久是未知且不可控的。在很多工業、醫療、軍事領域中，一個任務之所以要定義為高優先級，就是需要其盡快執行，并且運行周期嚴格可控，否則很有可能造成不可挽回的后果，如果這個過程中遇到優先級反轉，那系統異常甚至崩潰幾乎是必然的！

現在我們將 USE_MUTEX 置 1 來使用帶有優先級繼承功能的互斥鎖，此時的任務調度過程如下：

很明顯，此時中優先級任務沒有能搶占低優先級任務在共享資源處理階段的運行，雖然高優先級任務第一次嘗試獲取資源會失敗，但這個過程也臨時抬升了tl的優先級：

而后 tl 得以不被中優先級的 tm 打斷，一路運行到釋放資源，緊接著 th 獲取資源執行，而 tm 自然是等到 th 運行完后才能運行。很明顯，優先級反轉帶來的影響在這種機制下得到大幅緩解，但這里仍然有一個小瑕疵：

在 tl 對共享資源進行處理的過程中，仍然發生了一次搶占，這期間還會動態修改任務的優先級，稍許拉長了tl 對資源的處理時間。如果頻繁操作資源，那么這對系統調度來說也是消耗比較大的。如果想要保證高優先級任務能夠盡快執行，那么這一段操作一定是要去除的。如何去除？這就引出了下面這個機制。

我們再將 USE_PRIORITY_CEILING 置 1 打開優先級天花板，注意優先級天花板的值是預設且靜態的，所以我們在使用這個特性的時候需要提前設置好值：

rt_mutex_setprioceiling(mutex, THREAD_PRIORITY -2);

這個值一般會設置成使用資源中所有任務的最高優先級，當然文章開頭也講過由于 RT-Thread 相同優先級可以通過輪轉調度機制相互搶占，我這邊為了避免這種情況，所以設置為最高任務優先級的更高一級。

我們來看下加入了優先級天花板后任務的調度情況：

乍一看好像與優先級繼承的調度情況沒有區別，接下來我將 tl 操作共享資源的時間軸放大：

對比優先級繼承機制下的這部分：

可以看到中間 th 對 tl 的搶占過程消失了！

正是由于我們設置了天花板優先級，tl 在獲取資源的那一刻就將其優先級提升到了天花板，因此在這過程中即使是高優先級的 th 也無法對其進行搶占，真正做到了最快的資源處理速度，自然 th 在這種情況下也得到了最快的響應運行速度。

通過上述內容，相信大家已經對優先級反轉，優先級繼承以及優先級天花板有了非常直觀的理解，在實際的項目中也能夠按照實際需求去選擇合適的機制。

最后提一點，以上兩種方式都是緩解優先級反轉帶來的影響，并不能解決，因為低優先級任務獲取到資源后高優先級任務不可避免地要等待，否則就會造成更為致命的數據同步問題，上述解決方案都只是盡可能讓低優先級任務更快速地處理完釋放資源從而讓高優先級任務及時獲取。如果你的系統就不能接受這種情況，那么或許你要從程序設計角度，根本上去避免低優先級任務與高優先級任務共享資源，或是通過精密的設計規避高優先級任務想要獲取資源時低優先級任務正在處理資源的情況。