首先，我們必須考慮任務同步如何能造成阻塞，而阻塞反過來又如何導致優先級反轉。我們假設有任務 1 和任務 2 兩個任務正在運行，其中任務 1 具有較高的優先級。如果任務 1 準備執行，但必須等待任務 2 完成運行，就出現阻塞的狀況。同步化也會導致這種阻塞;例如，任務 1 和任務 2 共享由鎖或信號量控制的資源，任務 1 等待任務 2 對資源進行解鎖。或者，當任務 1 請求目前正由任務 2 使用的服務時，也會出現阻塞狀況。

　　阻塞允許任務 2 運行，直到任務 1 等待的條件出現為止(例如，任務 2 對兩個任務共享的資源解鎖)。此時，任務 1 可以執行。任務 1 須等待的總時間就是阻塞因數。如果任務 1 滿足一定的時間限制，該因數不會隨任何參數變化，如線程數或系統內的輸入。換句話說，必須限制阻塞因數。

　　現在，我們引入第三個任務(任務 3)——其優先級比任務 2 的高但比任務 1 的低(參見圖 1)。當任務 2 正在運行時，任務 3 準備運行，它會搶占任務 2，而任務 2 在任務 3 阻塞或完成前都無法運行。當然，這樣會增加任務 1 的阻塞因數;也就是說，它會進一步延遲任務 1 的運行。搶占導致的總延遲就是優先級反轉。　　

圖 1. 當任務 3 搶占任務 2 時，任務 1 等待任務 2 完成運行。這進一步延遲了任務 1 的運行。　　

圖 2. 任務 2 繼承了任務 1 的優先級，因而阻止了任務 3 搶占任務 2。
任務 3 不再延遲任務 1 的運行。

　　實際上，可以有多個任務以這種方式搶占任務 2，從而導致連續阻塞的結果。在這種情況下，任務 2 可能被無限期地搶占，產生無限期的優先級反轉，導致任務 1 無法滿足其最后期限。

　　這時優先級繼承就會發揮作用。如果我們回到上述假設中，在同步期內使任務 2 以任務 1 的優先級運行，那么任務 3 就無法搶占任務 2，這樣就能避免優先級反轉的產生(參見圖 2)。

　　分區調度程序

　　保證資源的可用性對許多系統都至關重要。如果某個關鍵子系統(如 CPU 周期)丟失，用戶就無法獲取該子系統提供的服務。例如，在拒絕服務 (DoS) 攻擊中，惡意用戶會利用需要優先級高的進程處理的請求攻擊系統。該進程會使 CPU 過載并導致其他進程的 CPU 周期匱乏，從而使用戶無法使用系統。

　　安全漏洞并非是導致進程匱乏的唯一原因。在許多情況下，增加系統的軟件功能都會導致系統“瀕臨危險邊緣”，導致現有應用程序的 CPU 時間匱乏。及時運行的應用程序或服務不再按預期或要求的那樣迅速響應。根據以往經驗，解決這一問題的唯一途徑是更新硬件或重新編碼(重新設計軟件)，但這兩種方法都不盡如人意。

　　為解決這些問題，系統設計人員需要一種可通過硬件或軟件執行 CPU 預算的分區計劃，以阻止進程或線程獨占其他進程或線程所需的CPU 周期。因為實時操作系統已經提供了對 CPU、內存和其他計算資源的集中訪問，所以它是執行 CPU 分區預算的最佳選擇。

　　某些實時操作系統提供了固定分區調度算法。系統設計人員能利用這種調度算法對任務進行分組或分區，然后為每個分區分配一定比例的 CPU 時間。利用這種方法，任何既定分區內的任務消耗的 CPU 時間都不會超過該分區靜態確定的比例。例如，我們假設為分區分配了 30% 的 CPU。如果該分區內的進程隨后成為拒絕服務攻擊的目標，它會消耗不超過 30% 的 CPU 時間。這種分配限制確保了其他進程保持各自的可用性;例如，它能保證可訪問的用戶界面(如遠程終端)。因此，操作人員能訪問系統并解決問題——無需按動復位開關。

　　但是，這種方法也存在問題。由于調度算法是固定的，因此一個分區無法使用分配到另一個分區的 CPU 周期，即使這些分區未使用其分配的周期。這種方法會浪費 CPU 周期并阻止系統處理高峰需求。因此，系統設計人員必須使用更昂貴的處理器應對運行緩慢的系統，或限制系統能支持的功能數量。