摘要:对很多嵌入式系统来说，一个设计良好的实时操作系统(RTOS)可以让开发工程师掌握系统执行任何任务或响应任何关键事件的时间，满足系统实时性要求。为了理解RTOS如何通过系统调度策略实现实时性要求，本文介绍了抢占式调度、可抢占的内核、优先级继承等概念。
关键词:计算机；实时操作；实时性；可靠性；策略
抢占式调度
在RTOS中，线程按照其优先级顺序执行。如果一个高优先级的线程准备运行时，它将在一个短的、有限时间间隔内从任何可能正在运行的低优先级进程接管CPU。另外，高优先级的线程能够不被中断地运行，直到它已经完成了需要做的事情－当然是在不被更高优先级进程抢占的前提下。这种方法就是抢占式调度，保证了高优先级线程始终满足其最终期限，而不管有多少其它线程正在竞争CPU时间。
通过合理地控制线程优先级，开发者能显著地提高很多对用戶非常重要的应用响应速度。然而，控制优先级可能是一把双刃剑，当使用不当时它可能会潜在地导致低优先级的进程不能得到CPU时间。保证高优先级的进程和线程的同时确保不会使其它进程处于“饥饿”状态的关键是要对它们的执行进行限制，通过对执行进行调整或在响应加载的过程中进行控制，开发人员能够限制这些活动消耗的CPU时间比例，并支持低优先级进程获得对CPU的共享。优先级控制能够使很多应用受益。
可抢占的内核
在RTOS中,内核操作是可抢占的。尽管仍然会存在一些时间窗口，在这些时间窗口中可能没有抢占，但是这些时间间隔应该是相当短暂的，通常在几百纳秒。另外，必须有一个关于抢占被推迟或中断被禁止的时间上限，这样开发者可以确定最坏情形下的等待时间。
为了实现这个目标，操作系统内核必须尽可能简洁，只有具有较短执行路径的服务才被包含在内核中，任何需要大量工作(如进程加载)的操作必须被安排到外部进程或线程。这种方法有助于通过内核确保最长的不可抢占代码路径具有一个时间上限。
优先级继承
然而，为一个进程设定一个高优先级并不总能保证该进程能够抢占低优先级的进程。有时候，系统会出现一种称为优先级倒置(priority inversion)的状态，在这种状态下，低优先级的进程将在“无意中”阻止较高优先级进程占用CPU。优先级倒置可能会表现为几种形式，为了防止发生这种情况，RTOS必须提供一种称为优先级继承的功能。
如果一个应用程序分布于几个通过网络连接的处理器，那么RTOS也应该支持分布式优先级继承，这样可以按照优先级的顺序处理来自多个处理器的请求。如果没有优先级继承，一个多处理器系统可能会落入无限的优先级倒置和死锁中。
我们已经明白怎样使RTOS具有可以预测性，但是如何实现其可靠性呢？答案在很大程度上取决于RTOS的架构。
例如在实时执行模式架构中，大部分或所有软件组件都在一个单一的内存地址空间中运行，包括操作系统内核、网络协议栈、设备驱动程序、应用程序等。虽然很有效率，但这种架构有两个明显的缺陷：1. 在任何组件中的一个指针错误，不论这个错误多么细微，都可能破坏操作系统内核或任何其它组件，导致不可预测的行为和整个系统的崩溃；2. 很难动态修复或替换任何有故障的组件。在大多数情况下，出现这些问题时系统复位是唯一的选择。
一些RTOS，也像Linux一样，试图通过使用单内核架构来解决这个问题。在这种架构中，用户的应用程序在隔离的、受保护内存地址空间中运行。如果一个应用程序试图访问其地址空间之外的数据，内存管理单元(MMU)将通知操作系统，操作系统可能会采取保护措施，例如终止出错进程。然而，这样的操作系统需要将大多数或所有驱动程序、文件系统和其它系统服务绑定到内核中。因此，任何组件中的一个错误都可能带来灾难性的内核故障。
采用微内核(mricokernel)架构来提供更精确的故障隔离，有两个明确特征：
1. 在操作系统内核中只实现了一个包含了基本OS服务的小内核(如信号量、定时器、任务调度等)。包括驱动程序、文件系统、协议栈和用户应用程序在内的所有其它的组件在内核外部分离的、保护内存的进程中运行。有问题的系统服务不再作为孤立的故障点，而是在它破坏其它服务或操作系统内核之前被终止并重启。
2. 所有的组件能够通过消息传递进行通信，一个定义良好的通信机制保障了程序在保持彼此安全隔离的前提下进行数据交换。适当实现的消息传递也可以作为一个虚拟的“软件总线”，允许几乎任何的软件组件，甚至是一个设备驱动程序被动态地加入或替换，对于必须提供连续服务的系统而言这是一项关键要求。
和传统的操作系统架构相比，微内核支持嵌入式设备赢得明显更快的平均修复时间(MTTR)。例如，如果一个设备驱动程序失败将可能出现以下情况：操作系统可以终止该驱动程序，回收其正在使用的资源，并对其进行重新启动，这个过程通常这只需要几个毫秒时间。
尽管和传统的操作系统相比，基于消息传递的微内核RTOS通常提供了更好的容错性和动态升级能力，也有一些观点认为消息传递增加了开销。在实际应用中，如果实现正确，消息传递的性能可以接近底层硬件的内存带宽。例如，一个微内核RTOS可以采用多段式(multipart)消息和线程到线程的消息数据直接拷贝等各种技术，来确保系统性能可以达到传统的进程间通信(IPC)方法的水平。由一些组织如Dedicated Systems(网址：www.omimo.be)等进行的独立测试证实，和传统的RTOS相比，微内核RTOS在一系列的实时指标方面表现良好，在很多情况下甚至有更好的表现。
策略决策
RTOS有助于使一个复杂的应用程序具有可预测性和可靠性。当然，选择一个合适的RTOS本身就是一项复杂的任务，而RTOS的底层架构是选择的重要依据，此外还有一些其它因素，包括：
1. 调度算法的灵活选择。RTOS应该支持调度算法的选择(先入先出(FIFO)、轮询(round robin)、零星调度等)并支持以线程为单位设定这些算法。这样，工程师就可以不必将一个算法用到系统中的所有线程。
2. 图形用户界面(GUI)。RTOS使用的是原始的图形库还是能支持多层界面、多路显示、3D渲染以及其它高级的图形功能的真正的窗口系统？能很容易定制GUI的外观吗？GUI支持同时显示和输入多种语言(汉语、韩语、日语、英语、俄语等)吗？
3. 远程诊断工具。因为对很多嵌入式系统而言，中断系统运行进行检测和维护是无法接受的。RTOS供应商应该提供诊断工具，这些工具能够在不中断系统服务的前提下分析系统的行为。要寻找能提供代码覆盖、应用测评、跟踪分析和内存分析工具的供应商。
4. 开发平台。RTOS提供商提供的开发环境是基于像Eclipse那样的开放平台，允许工程师嵌入所喜爱的第三方工具来进行建模、版本控制吗？还是开发环境基于专利技术？
5. 多处理技术。RTOS能支持对称多处理和分布式多处理技术来提高应用性能和容量吗？如果这样，是必须重新设计你的应用程序呢，还是RTOS能够将应用程序透明的分配到多个处理器上去呢？
6. 源代码工具包。RTOS供应商提供了能使RTOS满足设计需求的具有详细文档的定制工具包吗？供应商提供了方便开发驱动定制硬件的驱动程序开发工具包吗？
7. 对于很多公司而言，选择一款RTOS是一项战略性决策。RTOS供应商在对上述问题提供了清楚的回答后，你将选择出一个在现在和将来都适合你的RTOS。