使用實時內核,優先級反轉問題是實時系統中出現得最多的問題。下圖解釋優先級反轉是如何出現的。如圖，任務1優先級高於任務2，任務2優先級高於任務3。任務1和任務2處於掛起狀態，等待某一事件的發生，任務3正在運行如[下圖(1)]。此時，任務3要使用其共享資源。使用共享資源之前，首先必須得到該資源的信號量(Semaphore)。任務3得到了該信號量，並開始使用該共享資源[下圖（2）]。由於任務1優先級高，它等待的事件到來之後剝奪了任務3的CPU使用權[下圖(3)]，任務1開始運行[下圖(4)]。運行過程中任務1也要使用那個任務3正在使用著的資源，由於該資源的信號量還被任務3占用著，任務1只能進入掛起狀態，等待任務3釋放該信號量[下圖(5)]。任務3得以繼續運行[下圖(6)]。由於任務2的優先級高於任務3，當任務2等待的事件發生後，任務2剝奪了任務3的CPU的使用權[下圖(7)]並開始運行。處理它該處理的事件[下圖(8)]，直到處理完之後將CPU控制權還給任3[下圖(9)]。任務3接著運行[下圖(10)]，直到釋放那個共享資源的信號量[下圖(11)]。直到此時,由於實時內核知道有個高優先級的任務在等待這個信號量，內核做任務切換，使任務1得到該信號量並接著運行[下圖(12)]。

在這種情況下,任務1優先級實際上降到了任務3 的優先級水平。因為任務1要等,直等到任務3釋放占有的那個共享資源。由於任務2剝奪任務3的CPU使用權,使任務1的狀況更加惡化,任務2使任務1增加了額外的延遲時間。任務1和任務2的優先級發生了反轉。

糾正的方法可以是,在任務3使用共享資源時,提升任務3的優先級。任務完成時予以恢復。任務3的優先級必須升至最高,高於允許使用該資源的任何任務。多任務內核應允許動態改變任務的優先級以避免發生優先級反轉現象。然而改變任務的優先級是很花時間的。如果任務3並沒有先被任務1剝奪CPU使用權，又被任務2搶走了CPU使用權,花很多時間在共享資源使用前提升任務3的優先級,然後又在資源使用後花時間恢復任務3的優先級,則無形中浪費了很多CPU時間。真正需要的是,為防止發生優先級反轉,內核能自動變換任務的優先級,這叫做優先級繼承(Priority inheritance)但μC/OS-Ⅱ不支持優先級繼承,一些商業內核有優先級繼承功能。

優先級反轉

下圖解釋如果內核支持優先級繼承的話,在上述例子中會是怎樣一個過程。任務3在運行下圖(1)],任務3申請信號量以獲得共享資源使用權[下圖(2)],任務3得到並開始使用共享資源[下圖(3)]。後來CPU使用權被任務1剝奪[下圖(4)],任務1開始運行[下圖(5)],任務1申請共享資源信號量[下圖(6)]。此時,內核知道該信號量被任務3占用了,而任務3的優先級比任務1低,內核於是將任務3的優先級升至與任務1一樣,,然而回到任務3繼續運行,使用該共享資源[下圖(7)],直到任務3釋放共享資源信號量[下圖(8)]。這時,內核恢復任務3本來的優先級並把信號量交給任務1,任務1得以順利運行。 [下圖(9)],任務1完成以後[下圖(10)]那些任務優先級在任務1與任務3之間的任務例如任務2才能得到CPU使用權,並開始運行 [下圖(11)]。注意,任務2在從[下圖(3)]到[下圖(10)]的任何一刻都有可能進入就緒態,並不影響任務1、任務3的完成過程。在某種程度上,任務2和任務3之間也還是有不可避免的優先級反轉。

優先級繼承