嵌入式實時系統中的優先順序反轉問題
1、
問題的提出
目前，市場上占有率比較高的商業
rtos
有vxworks/psos
、qnx
、lynxos
、vrtx,、
windows ce
等。這些為數眾多的
rtos
絕大多數都是多工實時微核心的結構，採用的是基於優先順序的可搶占式排程策略。系統為每乙個任務分配乙個優先權，排程程式保證當前執行的程序是優先權最高的程序。但是，有時候會出現一種比較奇怪的現象：由於多程序共享資源，具有最高優先權的程序被低優先順序程序阻塞，反而使具有中優先順序的程序先於高優先順序的程序執行，導致系統的崩潰。這就是所謂的優先順序反轉（
priority inversion
）。
2、
優先順序反轉
rtos普遍具有2個特點：實時性和多工。實時是指系統的響應時間必須在規定的時間內，超出這個時間限制將會使系統出現致命的錯誤；同時，實時性還要求對時間要求非常急迫的任務要先於對時間不是很緊急的任務執行。正是由於這
2個原因，
rtos的程序排程普遍採用的是基於優先順序的可搶占式pbp（priority basedpreemptive）的排程策略。多工是嵌入式系統的內在要求。如今的嵌入式系統普遍要求具有多工併發執行的能力，因此
rtos
中也必須提供多工併發執行的支援。由於多工併發，必然會導致多個任務共享資源。
大多數的
rtos
採用了一種稱作訊號量（
semaphore
）的機制來實現對共享資源的管理。任何乙個想使用臨界資源（如印表機等共享資源）的程序在進入臨界區
之前必須擁有使用臨界資源的訊號量，否則不可以執行臨界區**。假設系統中有
3個任務，分別為
task1
、task2
和task3
。task1
的優先權高於
task2
，而task2
的優先權高於
task3
。恰在此時
task1
和task2
因某種原因被阻塞，這時候系統排程
task3
執行。task3
執行一段時間後，
task1
被喚醒。由於採取的是
pbp的排程策略，因此
task1
搶占task3
的cpu, task1
執行。task1
執行一段時間後要進入臨界區，但此時
task3
占有此臨界資源的訊號量。因此
task1
被阻塞，處於等待狀態，等待
task3
釋放此訊號量。經過這麼一段時間後，
task2
此時此刻處於就緒狀態。因此系統排程
task2
執行。如果
task3
在task2
的執行期間一直沒有能夠被排程執行的話，那
task1
和task3
將一直等到
task2
執行完後才能執行，
task1
更要等到
task3
釋放它所把持的訊號量才能執行；而這段時間完全有可能超出
task1
的deadline
，使得task1
崩潰。當系統看到有高優先順序的任務崩潰時候，系統認為此時有重大事故發生，為了挽救系統，看門狗電路起作用，系統可能被自動復位。從上面的分析可以看到，導致系統崩潰的原因是由於優先順序高的任務
task1
要獲取被低優先順序任務
task3
占有的臨界資源而被
task3
阻塞，而具有中優先順序的任務
task2
搶占task3
的cpu,
從而導致
task2
先於task1
執行。這時候系統便出現了優先順序反轉的情況。
3、
優先順序反轉的解決方法
目前解決優先順序反轉有許多種方法。其中普遍使用的有
2種方法：一種被稱作優先順序繼承（
priorityinheritance
）；另一種被稱作優先順序極限（
priorityceilings
）。在優先順序繼承方案中，當高優先順序任務在等待低優先順序的任務占有的訊號量時，讓低優先順序任務繼承高優先順序任務的優先順序，即把低優先順序任務的優先權提高到高優先順序任務的優先順序；當低優先順序任務釋放高優先順序任務等待的訊號量時，立即把其優先權降低到原來的優先權。採用這種方法可以有效地解決上面所述的優先權反轉的問題。當高優先順序任務
task1
想要進入臨界區時，由於低優先順序任務
task3
占有這個臨界資源的訊號量，導致
task1
被阻塞。這時候，系統把
task3
的優先權公升到
task1
的優先權，此時優先權處於
task1
和task3
之間的任務
task2
，即使處於就緒狀態也不可以被排程執行，因為此時
task3
的優先權已經高於
task2
，所以task3
此時被排程執行。當
task3
釋放task1
需要的訊號量時，系統立即把
task3
的優先權降到原來的高度，來保證
task1
和task2
正常有序執行。
目前，有許多
rtos
是採用這種方法來防止優先順序反轉的，如大家比較熟悉的業界有名的
windriver
公司的vxworks。
在優先權極限方案中，系統把每乙個臨界資源與
1個極限優先權相聯絡。這個極限優先權等於系統此時最高優先權加1。當
1個任務進入臨界區時，系統便把這個極限優先權傳遞給這個任務，使得這個任務的優先權最高；當這個任務退出臨界區後，系統立即把它的優先權恢復正常，從而保證系統不會出現優先權反轉的情況。如上例中，當
task3
進入臨界區時，立即把它的優先權公升高到極限優先權，保證
task3
此時能盡快退出臨界區，進而釋放其占有的訊號量。當高優先順序任務
task1
執行的時候就不會出現其等待低優先順序任務
task3
釋放訊號量而被阻塞的情況，從而保證不會出現上面所說的優先順序反轉。採用這種方案的另乙個有利之處，是僅僅通過改變某個臨界資源的優先順序就可以使多個任務共享這個臨界資源。 21
世紀將是嵌入式系統的時代。從事嵌入式系統設計的人員深入了解
rtos
的原理和內部潛在的問題，如優先順序反轉等，將有助於開發出更加可靠的產品。
多執行緒多程序優先順序理解 優先順序反轉
1.優先順序反轉 priority inversion 由於多程序共享資源，具有最高優先權的程序被低優先順序程序阻塞，反而使具有中優先順序的程序先於高優先順序的程序執行，導致系統的崩潰。這就是所謂的優先順序反轉 priority inversion 2.產生原因 其實,優先順序反轉是在高優級 假設為...
優先順序反轉
1.優先順序反轉 priority inversion 由於多程序共享資源，具有最高優先權的程序被低優先順序程序阻塞，反而使具有中優先順序的程序先於高優先順序的程序執行，導致系統的崩潰。這就是所謂的優先順序反轉 priority inversion 2.產生原因 其實,優先順序反轉是在高優級 假設為...
優先順序反轉
實時作業系統中，在訊號量使用過程中，則可能出現優先順序反轉的不合理情況。1.優先順序翻轉出現場景 高優先順序的任務被低優先順序的任務阻塞，導致高優先順序任務得不到排程和執行。但是其他中等優先順序的任務卻能搶占到cpu資源。從現象看好像是中優先順序任務比高優先順序任務具有更高的優先權。當系統高優先順序...