摘要

　　目前的高性能處理器和通用操作系統實時補丁的飛速更新，似乎又重新將嵌入式系統是否還需要實時操作系統這一問題擺在我們面前。答案依然沒變：在嵌入式環境中，只有真正的實時操作系統才能在低端處理器上同樣提供資源保證。

　　簡介

　　大部分嵌入式項目還需要實時操作系統嗎?這個問題問得好，因為現代高性能處理器和 Linux、Windows 和其他通用操作系統 (GPOS) 的實時補丁的出現等等這些都在飛速發展中。

　　嵌入式設備的本質道出了答案。制造設備通常都需要幾千個甚至幾百萬個部件。哪怕設備硬件的單位成本節省 1 美元，都會為制造商帶來不小的財富。換言之，設備無法承受數千兆赫茲級處理器的成本(更不用考慮功耗這些因素了)。

　　例如，在汽車遠程信息處理技術市場，常見的 32 位處理器以約 600Mhz 的速度運行——遠遠慢于臺式機和服務器的通用處理器。 在這種運行環境中，實時操作系統能得到低端硬件超快、可預測的響應，因此具有顯著的節約成本的優勢。

　　除節約成本之外，實時操作系統提供的服務還能使許多計算問題迎刃而解，特別是當多種運行爭奪系統資源時。例如，試想一個用戶期望(或需要)立即響應輸入的系統。利用實時操作系統，軟件開發人員能確保用戶啟動的操作會先于其他系統活動執行，除非必須先執行更重要的任務(如幫助保護用戶安全的運行)。

　　再試想一個必須滿足服務質量 (QoS) 要求的系統，例如一臺可播放現場視頻的設備。如果設備依靠軟件播放其內容，它可能會以用戶無法接受的速率出現失幀現象——從用戶的角度看，該設備不可靠。但使用實時操作系統的話，軟件開發人員就能精確控制軟件進程的執行順序，確保以適當和一致的媒體速率播放。

　　實時操作系統并不“公平”

　　對“硬”實時的需求——以及對實現該功能的實時操作系統的需求——仍然是嵌入式產品業的普遍要求。問題是：實時操作系統具備哪些通用操作系統所不具備的功能呢?適用于一些通用操作系統的實時擴展組件有多大用處呢?它們能提供和實時操作系統一樣的性能嗎?

　　讓我們先從任務調度開始。在通用操作系統中，調度程序通常使用一種“公平”策略，將線程和進程分配到 CPU 中。這種策略可確保臺式機和服務器的應用程序所需的較高的總吞吐量，但無法保證優先級高、時間要求嚴格的線程先于優先級低的線程執行。

　　例如，通用操作系統可能會降低分配給優先級高的線程的優先級，或按照有利于系統內其他線程的公平原則，以動態方式調整優先級。因此，優先級高的線程就可能被優先級低的線程搶占。此外，大多數通用操作系統都具有無限期的分配潛伏期：系統內的線程越多，通用操作系統調度線程執行所需的時間就越久。其中任何一種因素都能導致優先級高的線程錯過最后期限，即使在速度很快的 CPU 上。

　　另一方面，在實時操作系統中，線程會按其優先級的順序執行。如果優先級高的線程準備運行，它能在很短且有限的時間間隔內，從正在執行的優先級低的線程那里接管 CPU。此外，優先級高的線程還能不間斷地運行直到完成任務為止——當然，除非它被優先級更高的線程搶占。這種眾所周知的基于優先級的搶占式調度，可確保優先級高的線程始終如一地滿足最后期限的要求，即使在其他線程爭奪 CPU 時間時。

　　搶占式內核

　　大多數通用操作系統的操作系統內核都不是搶占式的。因此，優先級高的用戶線程無法搶占內核調用，相反，它必須等待整個調用全部結束——即使是系統內優先級低的進程進行調用。此外，當驅動程序或其他系統服務(通常在內核調用中運行)以客戶端線程的名義執行時，操作系統通常會丟失所有優先級信息。這種系統行為會導致無法預料的延遲，而且會妨礙關鍵運行按時完成。

　　另一方面，在實時操作系統中，內核運行是可搶占的。在通用操作系統中，有一些時間窗有可能是無法被搶占的，但在精心設計的實時操作系統中，這些時間窗非常短暫，通常僅約幾百納秒。另外，實時操作系統會針對搶占推遲和中斷禁止的時限設置上限;這能保證軟件開發人員確定情況最糟的延遲期。

　　為實現一致的可預見性目標和及時完成關鍵運行，實時操作系統內核必須盡可能簡單精致。實現這種簡單性的最佳途徑是設計一種只包含短執行路徑服務的內核。通過排除內核中任務集中的運行(如進程加載)并將其分配到外部進程或線程，實時操作系統的設計人員就能保證通過內核的最長的非搶占代碼路徑有上限。

　　在一些通用操作系統中，內核增加了某種程度的可搶占性。但無法搶占的時間間隔仍然比常見實時操作系統的長得多;這種搶占間隔的長度取決于通用操作系統內核中包含的最長的關鍵模塊部分(如網絡)。另外，搶占式通用操作系統內核不能解決可能的無限期延遲情形，例如因為客戶端調用驅動程序或其他系統服務時丟失優先級信息。

　　避免優先級反轉

　　在通用操作系統(甚至實時操作系統)中，優先級低的線程也能在無意中阻止優先級高的線程訪問 CPU——這種情況被稱為優先級反轉。當出現無限期的優先級反轉時，可能會錯過關鍵的最后期限，進而導致系統運行異常和全面故障的結果。遺憾的是，在系統設計過程中人們往往會忽視優先級反轉。有很多優先級反轉的實例，包括 1997 年 7 月火星探路者項目遭受困擾的實例。[1]

　　一般來說，當優先級不同的兩個任務共享資源，而優先級高的任務無法從優先級低的任務那里獲得資源時，就會出現優先級反轉。為防止這種狀況超過有限的時間間隔，實時操作系統可提供一種通用操作系統不具備的選擇機制，包括優先級繼承和優先級封頂模擬。我們不能單純地評價兩種機制的優劣，所以我們著重介紹優先級繼承的實例。