在嵌入式系統的開發中，即時作業系統（RTOS）一直佔有舉足輕重的位置，然而，隨著處理器效能的不斷提高，以及Linux、Windows及其他所謂的通用作業系統（General Purpose OS；GPOS）也開始具有部分即時性能時，有人不僅要問，嵌入式專案的開發，是否還需要用到RTOS？

對於很多的嵌入式系統來說，RTOS仍是不可或缺的。以一個MPEG影像的播放功能來說，如果採用一般的GPOS來播放，可能會出現讓用戶難以接受的畫面更新速度；但若使用RTOS，系統設計工程師就能準確地控制軟體過程的執行程序，讓播放品質能得到保證。

基於設計策略上的基本差異，RTOS在嵌入式開發環境中的重要性仍是難以被GPOS所取代的。在Linux等GPOS中，排程器（scheduler）通常採用「公平策略」（fairness policy）來遞送執行緒到CPU，這樣的策略雖然能讓PC及伺服器獲得更高的整體傳輸率，但對於具有高優先需求和時間迫切的執行緒來說，卻無法得到保證。此外，當有愈多的執行緒時，GPOS得花上更多的時間來安排它們的執行順序，這往往延宕了優先工作的執行，對於使用者來說就是系統很不穩定的感覺，這並不符合嵌入式產品的開發宗旨。

相較之下，RTOS的執行就是以工作優先等級為執行上的第一守則。如果一個高優先順序的執行任務已準備好要運作了，那在很短的反應間隔中，它就會從低優先順序的執行序中取得CPU的使用權。不僅如此，一直到工作完成以前，這個優先執行緒都能安穩地使用處理器資源，除非有另一個更重要的任務出現。這個策略即是「優先級搶佔式調度」（priority-based preemptive scheduling），它讓高優先度的工作能在許多競爭處理器資源的執行緒中維持讓用戶滿意的高品質服務。

為了讓GPOS也有即時的功能，開發者採用第二核心或直接修改GPOS核心，這樣做的好處是開發者仍能使用標準核心的功能和其程序模組，但對於較複雜的即時作業環境來說，仍然是心有餘而力不足。此外，在大部分的情況中，為GPOS所寫的服務很難移植到即時的處理核心中；為特定廠商的即時系統開發的程序，在別的即時系統中往往也無法運作。

以Linux為例，當用在嵌入式的開發時，它的驅動程式和虛擬檔案系統（VFS）架構都得根據特定嵌入式開發專案而做適度的修改，若非如此，一些即時性的任務將可能遭到難以預期的延遲阻礙。此外，由於今日大部分的Linux驅動程序仍不具有搶佔性，所以工程師還得在每個系統驅動器中加入「搶佔點」（preemption point），以確保這個工作的可預期性。

這些議題都顯示出要將一個GPOS修改到具有即時性的功能是多麼困難，不過，它們只是在強調決定性工作的環境中顯得絆手絆腳，並不能因此就否定了GPOS的重要性，在對廣泛使用的API的支援，和開放源碼社群的豐富資源上，GPOS的優勢仍是RTOS所難以比擬的。然而，要真正進入到嵌入式領域的一些關鍵性應用市場，Linux等GPOS仍得克服在即時服務上的限制。（作者擔任電子產業媒體工作者多年，現為自由寫作工作者。聯絡方式：[email protected]）