ucos是乙個典型的按照優先順序排程的作業系統，優先順序高的任務先執行，優先順序低的任務後執行，然而在任務的排程過程中可能會出現優先順序翻轉的情況。在嵌入式系統的應用中，實時性是乙個重要的指標，而優先順序翻轉是影響系統實時性的重要問題。
例如：有優先順序為a、b和c三個任務，優先順序a>b>c，任務a，b處於掛起狀態，等待某一事件發生，任務c正在執行，此時任務c開始使用某一共享資源s。在使用中，任務a等待事件到來，任務a轉為就緒態，因為它比任務c優先順序高，所以立即執行。當任務a要使用共享資源s時，由於其正在被任務c使用，因此任務a被掛起，任務c開始執行。如果此時任務b等待事件到來，則任務b轉為就緒態。由於任務b優先順序比任務c高，因此任務b開始執行，直到其執行完畢，任務c才開始執行。直到任務c釋放共享資源s後，任務a才得以執行。在這種情況下，優先順序發生了翻轉，任務b先於任務a執行。
優先順序翻轉的解決辦法：
從上面的分析中可以看出，優先順序翻轉其實是作為作業系統排程的一種異常情況出現的，作業系統的設計者其實是不想讓這種情況出現的，所以優先順序翻轉是作為乙個問題而存在的。解決優先順序翻轉問題有優先順序天花板(priority ceiling)和優先順序繼承(priority inheritance)兩種辦法。
>>> 優先順序天花板是當任務申請某資源時， 把該任務的優先順序提公升到可訪問這個資源的所有任務中的最高優先順序， 這個優先順序稱為該資源的優先順序天花板。這種方法簡單易行， 不必進行複雜的判斷， 不管任務是否阻塞了高優先順序任務的執行， 只要任務訪問共享資源都會提公升任務的優先順序。
>>> 優先順序繼承是當任務a 申請共享資源s 時， 如果s正在被任務c 使用，通過比較任務c 與自身的優先順序，如發現任務c 的優先順序小於自身的優先順序， 則將任務c的優先順序提公升到自身的優先順序， 任務c 釋放資源s 後，再恢復任務c 的原優先順序。這種方法只在占有資源的低優先順序任務阻塞了高優先順序任務時才動態的改變任務的優先順序，如果過程較複雜， 則需要進行判斷。
uc/os-ii中優先順序翻轉問題的解決
在uc/os-ii中，為解決優先順序翻轉影響任務實時性的問題，可以借鑑優先順序繼承的方法對優先順序天花板方法進行改進。對uc/os-ii的使用，共享資源任務的優先順序不是全部提公升，而是先判斷再決定是否提公升。即當有任務a申請共享資源s時，首先判斷是否有別的的任務正在占用資源s，若無，則任務a繼續執行，若有，假設為任務b正在使用該資源，則判斷任務b的優先順序是否低於任務a，若高於任務a，則任務a掛起，等待任務b釋放該資源，如果任務b的優先順序低於任務a，則提公升任務b的優先順序到該資源的優先順序天花板，當任務b釋放資源後，再恢復到原優先順序。在uc/os-ii中，每個共享資源都可看作乙個事件，每個事件都有相應的事件控制塊ecb。在ecb中包含乙個等待本事件的等待任務列表，該列表包括oseventtbl和oseventgrp兩個域，通過對等待任務列表的判斷可以很容易的確定是否有多個任務在等待該資源，同時也可判斷任務的優先順序與當前任務優先順序的高低，從而決定是否需要用ostaskchangepio()來改變任務的優先順序。這樣，僅在優先順序有可能發生翻轉的情況下才改變任務的優先順序，而且利用事件的等待任務列表進行判斷，比用ostaskchangepio()來改變任務的優先順序速度快，並占用較少的cpu時間，有利於系統實時性的提高。
優先順序翻轉
所謂優先順序翻轉問題 priority inversion 即當乙個高優先順序任務通過訊號量機制訪問共享資源時，該訊號量已被一低優先順序任務占有，而這個低優先順序任務在訪問共享資源時可能又被其它一些中等優先順序任務搶先，因此造成高優先順序任務被許多具有較低優先順序任務阻塞，實時性難以得到保證。例如 ...
FreeRTOS優先順序翻轉
舉例 高優先順序任務的任務函式 void high task void pvparameters 中等優先順序任務的任務函式 void middle task void pvparameters 低優先順序任務的任務函式 void low task void pvparameters xsemaph...
優先順序翻轉問題
考慮一台計算機有兩個程序，h優先順序較高，l優先順序較低。排程規則規定只要h處於就緒態它就可以執行。在某一時刻，l處於臨界區中，此時h變到就緒態準備執行 例如，一條i o操作結束 現在h開 始忙等待，但由於當h就緒時l不會被排程，也就無法離開臨界區，所以h將永遠忙等待下去。假定乙個程序中有三個執行緒...