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

安全漏洞并非是導致進程匱乏的唯一原因。在許多情況下，增加系統的軟件功能都會導致系統“瀕臨危險邊緣”，導致現有應用程序的 CPU 時間匱乏。及時運行的應用程序或服務不再按預期或要求的那樣迅速響應。從歷史角度，解決這一問題的唯一途徑是更新硬件或對軟件進行重新編碼（或重新設計）——這兩種方法都無法讓人滿意。

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

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

但是，這種方法也存在問題。由于調度算法是固定的，因此一個分區無法使用分配到另一個分區的 CPU 周期，即使這些分區未使用其分配的周期。這種方法會浪費 CPU 周期并阻止系統處理高峰需求。因此，系統設計人員必須使用更昂貴的處理器應對運行緩慢的系統，或限制系統能支持的功能數量。
自適應分區
另一種被稱作自適應分區的方法提供了更靈活的動態調度算法，從而有效克服了這些缺陷。與靜態分區一樣，自適應分區允許系統設計人員為單獨進程或一組進程預留 CPU 周期。因此，系統設計人員能保證一個子系統或分區上的負載不會影響其他子系統的可用性。而且，與靜態分區不同的是，自適應分區還能將空閑分區中的 CPU 周期以動態方式重新分配到可受益于額外處理時間的分區——只有當 CPU 滿載時，分區預算才會執行。因此，系統就能處理高峰需求并使利用率達到 100%，同時又能繼續享受資源保證帶來的收益。

同樣重要的是，自適應分區還能直接應用于先有系統，而無需重新設計代碼或修改代碼。例如，在 QNX Neutrino 中，系統設計人員只需啟動分區內已有的基于 POSIX 應用程序，實時操作系統的調度程序就會確保每個分區都會收到分配的預算。在每個分區內，會繼續根據基于優先級的搶占式調度算法對每項任務進行調度——應用程序不必更改其調度運行。此外，系統設計人員還能以動態方式重新配置分區，以精確調節系統實現最佳性能。

圖 3——自適應分區可阻止優先級高的任務消耗超過其分配的規定比例的 CPU，除非系統包含未使用的 CPU 周期。例如，任務 A 和任務 D 可在分配至分區 3 的時間內運行，因為任務 E 和任務 F 不需要剩余的 CPU 周期預算。 6

“組合”內核
通用操作系統（包括 Linux、Windows 和各種類型的 Unix 系統）通常都缺少我們目前介紹的實時機制。但供應商已開發出許多實時擴展組件和補丁，試圖填補這一空白。例如，有一種雙內核方法，其中的通用操作系統能以任務的形式在專用實時內核上運行（參見圖 4）。任何需要確定性調度的任務都會在該內核中運行，但其優先級要高于通用操作系統的優先級。因此，只要這些任務需要運行，它們就能搶占 Linux，而且只有在其工作完成后，才會向 Linux 釋放 CPU。
遺憾的是，實時內核中運行的任務只能有限地利用通用操作系統中現有的系統服務，如文件系統、網絡服務等。

實際上，如果實時任務向通用操作系統請求任何服務，它都會面臨同樣的搶占問題，這會阻止通用操作系統以確定方式運行。因此，必須針對實時內核創建新的驅動程序和系統服務，即使通用操作系統中已存在相同的服務。但是，多數通用操作系統為正常的非實時進程提供的受內存管理單元 (MMU) 保護的可靠環境卻無法惠及在實時內核中運行的任務。相反，它們會在無保護的內核空間運行。因此，任何含有公共編碼錯誤（如損壞的 C 指針）的實時任務都會輕易導致內核出現嚴重故障。這的確是一個問題，因為需要實時功能的大部分系統同樣需要極高的可靠性。

雙內核方法的不同實現使用不同的應用程序接口 (API) 使問題進一步復雜。在多數情況下，為通用操作系統編寫的服務無法輕易移植到實時內核中，而且針對一個供應商的實時擴展組件編寫的任務未必能在另一個供應商的實時擴展組件上運行。

圖 4——在常見的雙內核實現中，通用操作系統會作為優先級最低的任務在單獨的實時內核中運行。
這種解決方案指出了使通用操作系統支持實時運行的實際困難和復雜性。但這并非是關于實時操作系統和通用操作系統孰優孰劣的問題。通用操作系統（如 Linux、Windows 和各種 Unix 系統）都能以臺式機或服務器操作系統的形式正常運行。但是，當進入不符合其設計用途的確定運行環境中（如車載遠程信息處理裝置、醫療器械、實時控制系統和連續媒體應用）時，它們就會凸顯不足。 7

令調試和定制更輕松的源代碼
使用通用操作系統仍有一些好處，例如在 Linux 的開源模式下支持廣泛使用的應用程序接口 (API)。利用開源模式，軟件開發人員能針對應用程序的具體需求定制操作系統組件，從而能節約大量用于故障排解的時間。為保持這些優勢，實時操作系統的供應商應根據友好的商業授權許可條款，確保其源代碼易于訪問。例如，QNX 不僅在社區網站 (www.foundry27.com) 中公布其源代碼，還采用了透明開發模式，確保源代碼在開發過程中就能公布。因此，軟件開發人員就能在開發過程中及早修復漏洞，并獲取最新技術。

實時操作系統的架構也發揮了重要作用。例如，基于微內核設計的實時操作系統能從根本上簡化操作系統的定制過程。在微內核實時操作系統中，只有少數核心基本對象（如信號、計時器、調度程序）才會存在于內核中。所有其他組件（驅動程序、文件系統、協議棧、應用程序）都會以單獨的受內存保護的進程在內核外部運行；參見圖 5。因此，開發定制的驅動程序和其他與應用程序有關的操作系統擴展組件無需專門的內核調試程序或內核專家。實際上，作為用戶空間程序，開發這種操作系統擴展組件和開發標準應用程序一樣容易，因為開發人員都能使用標準、源代碼級工具對它們進行調試。

圖 5——在微內核實時操作系統中，系統服務作為標準的用戶空間進程運行，因而簡化了操作系統的定制任務。
例如，如果設備驅動程序試圖訪問其進程空間之外的內存，操作系統就能識別相關進程，指出故障位置并創建可使用源代碼級調試工具查看的進程轉儲文件。轉儲文件可包括調試程序確定導致故障的源代碼行所需的所有信息以及診斷信息（如數據項的內容和函數調用的歷史）。 8

這種架構還提供了絕佳的故障隔離和恢復功能：如果驅動程序、協議棧或其他系統服務出現故障，它可在不影響其他服務或損壞操作系統內核的情況下完成這種操作。實際上，“軟件監視程序”會持續監測此類事件，并能以動態方式重啟出現故障的服務，無需重啟整個系統或以任何方式干擾用戶。同樣，驅動程序和其他服務都能以動態方式停止、啟動或升級，無需關閉系統。

絕不可小看這些優勢——因為破壞實時性能的最大威脅就是不定期的系統重啟！甚至軟件更新中包含的以可控制的方式進行的預定重啟都會干擾系統運行。為保證一直滿足最后期限的要求，軟件開發人員必須使用即使在出現軟件故障或進行服務升級時，也能保持連續可用的操作系統。