在嵌入式系统的开发中，即时作业系统（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仍得克服在即时服务上的限制。 （作者担任电子产业媒体工作者多年，现为自由写作工作者。联络方式：ovenou@yahoo.com.tw）