具有固定優(yōu)先級調(diào)度程序RTOS的優(yōu)先級倒置

具有固定優(yōu)先級調(diào)度程序的 RTOS 的核心思想是高優(yōu)先級任務應該在低優(yōu)先級任務之前調(diào)度。如有必要，RTOS 甚至可以搶占正在運行的任務，迫使它讓 CPU 執(zhí)行更高優(yōu)先級的任務。然而，作為開發(fā)人員，您必須注意可能導致較高優(yōu)先級任務必須等待較低優(yōu)先級任務的編程缺陷——這種情況稱為優(yōu)先級倒置。

優(yōu)先級反轉可以與互斥體、消息隊列或其他類型的同步對象一起發(fā)生。描述問題的最佳方式可能是通過一個示例來逐步說明。

在下面的時間線圖中，使用 Tracealyzer 捕獲，我們有一個低優(yōu)先級任務（綠色）正在執(zhí)行。它需要一個二進制信號量來保護某些臨界區(qū)并繼續(xù)在臨界區(qū)內(nèi)執(zhí)行代碼。當高優(yōu)先級任務（紅色）進入就緒狀態(tài)時，RTOS 搶占綠色任務并讓紅色運行。紅色任務嘗試獲取相同的二進制信號量，但由于低優(yōu)先級綠色任務持有它而被阻止。

到目前為止，一切都很好——這是預期的行為。一般來說，綠色任務現(xiàn)在會運行并快速釋放信號量，此時它再次被搶占，紅色任務可以獲取信號量并繼續(xù)。然而，這一次發(fā)生了反轉。出于某種原因，可能是定時等待已過期，中等優(yōu)先級（橙色）任務已進入就緒狀態(tài)并被允許在綠色任務之前執(zhí)行。由于橙色任務不知道有爭議的信號量，它很高興地運行完成。只有這樣，綠色任務才會最終運行，以便它可以釋放信號量并將執(zhí)行權交給紅色的高優(yōu)先級任務。

因此，高優(yōu)先級任務被阻塞，必須等待不確定的時間，而中等優(yōu)先級任務運行完成。這就是工作中的優(yōu)先級倒置。

重要的是要意識到這里涉及的三項任務基本上是無能為力的。他們沒有人可以做任何事情來避免倒置，至少在沒有 RTOS 的支持的情況下是這樣。幸運的是，這種支持在許多 RTOS 中以具有優(yōu)先級繼承的互斥鎖的形式提供?；コ饬浚ɑコ獾目s寫）是一種用于保護共享資源的信號量。優(yōu)先級繼承意味著如果一個高優(yōu)先級的任務在試圖獲得一個低優(yōu)先級任務當前持有的互斥鎖時阻塞，那么持有該互斥鎖的任務的優(yōu)先級會暫時提高到被阻塞任務的優(yōu)先級。在我們的場景中，當紅色任務被阻塞時，綠色任務將被提升為紅色優(yōu)先級，從而有效地阻止了橙色任務的運行。

優(yōu)先級繼承并不能真正治愈優(yōu)先級倒置，它只是在某些情況下將其影響最小化。硬實時應用程序仍應仔細設計，以便一開始就不會發(fā)生優(yōu)先級反轉。

通常，盡可能避免阻塞共享資源。例如，如果您的任務將數(shù)據(jù)寫入消息隊列（可能已滿），您可以改為使用足夠大但未滿的隊列，作為額外的預防措施，以非阻塞方式寫入并檢查任何失敗寫入的返回值。而不是使用分散在代碼中的多個關鍵部分（共享互斥鎖），您可以創(chuàng)建一個“服務器”任務，該任務執(zhí)行對資源的所有直接操作，并使用消息隊列從“客戶端”任務中獲取請求，在非-阻塞方式。服務器可以通過請求中指定的其他消息隊列發(fā)送任何回復，這些消息隊列由客戶端任務擁有。

審核編輯：郭婷