假定系统有三个进程：A(低优先级)，B(中等优先级)，Z(高优先级)。这里Z是一个为A和B提供服务[de]“服务器”进程。参见图1。

现在假定A已经请求Z来执行一个计算，而在这期间，突然B需要Z[de]服务。因为B拥有比A更高[de]优先级，一般会认为Z将立即挂起A[de]请求并将转向为B服务。但是实际情况并非如此，因为Z比B具有更高[de]优先级。其结果是，B不能阻止Z完成它当前[de]工作，即对A做出响应。

从效果上看，低优先级[de]进程A占用了更高优先级进程B[de]CPU时间，这是引入优先级继承[de]原因。通过使用RTOS提供[de]优先级继承机制，系统可以在A发出请求[de]情况下，让Z继承A[de]低优先级。通过这种方式，B能够在任何时候抢占A[de]请求。

如果一个应用程序分布于几个通过网络连接[de]处理器，那么RTOS也应该支持分布式优先级继承，这样可以按照优先级[de]顺序处理来自多个处理器[de]请求。如果没有优先级继承，一个多处理器系统可能会落入无限[de]优先级倒置和死锁中。

中断处理

为了获得对外部事件[de]及时响应，最小化硬件中断发生到执行该中断[de]第一条代码[de]时间很重要。这个时间间隔称为中断延迟，为了保证中断延迟尽可能小，一个好[de]RTOS应该在几乎所有时间内都支持产生中断。正如在关于内核抢占部分提到[de]那样，一些重要[de]代码段[de]确需要暂时屏蔽中断。这种最大[de]屏蔽时间通常被定义为最大[de]中断延迟。

在某些情况下，硬件中断处理器必须调度并运行一个更高优先级[de]线程(例如在一个驱动程序中)。在这样[de]情况下，中断处理器将返回并指示一个事件将被处理。这样[de]处理将引入了第二种形式[de]延迟－调度延迟，这个延时必须在设计中加以考虑。调度延迟是介于用户[de]中断处理器[de]最后一条指令和驱动程序线程第一条指令[de]执行之间[de]时间。

在一个嵌入式系统中可能会同时出现多个硬件中断。例如，在一个病人监护系统中，当一个传感器记录了病人心跳[de]一次变化并且网卡接收到网络传来[de]数据[de]同时，护士按了触摸屏。很明显，一些中断(如心率[de]变化)应该立即得到处理，而其他[de]则可以延缓。通过提供对嵌套中断[de]支持，RTOS支持嵌入式系统优先处理更高优先级[de]中断。

如何提高可靠性

我们已经明白怎样使RTOS具有可以预测性，但是如何实现其可靠性呢？答案在很大程度上取决于RTOS[de]架构。

例如在实时执行模式架构中，大部分或所有软件组件都在一个单一[de]内存地址空间中运行，包括操作系统内核、网络协议栈、设备驱动程序、应用程序等。虽然很有效率，但这种架构有两个明显[de]缺陷：1. 在任何组件中[de]一个指针错误，不论这个错误多么细微，都可能破坏操作系统内核或任何其它组件，导致不可预测[de]行为和整个系统[de]崩溃；2. 很难动态修复或替换任何有故障[de]组件。在大多数情况下，出现这些问题时系统复位是唯一[de]选择。

一些RTOS，也像Linux一样，试图通过使用单内核架构来解决这个问题。在这种架构中，用户[de]应用程序在隔离[de]、受保护内存地址空间中运行。如果一个应用程序试图访问其地址空间之外[de]数据，内存管理单元(MMU)将通知操作系统，操作系统可能会采取保护措施，例如终止出错进程。然而，这样[de]操作系统需要将大多数或所有驱动程序、文件系统和其它系统服务绑定到内核中。因此，任何组件中[de]一个错误都可能带来灾难性[de]内核故障。

第三种方法是采用微内核(mricokernel)架构来提供更精确[de]故障隔离，像QNX Neutrino这样[de]操作系统都基于微内核架构。微内核有两个明确[de]特征：

1. 在操作系统内核中只实现了一个包含了基本OS服务[de]小内核(如信号量、定时器、任务调度等)。包括驱动程序、文件系统、协议栈和用户应用程序在内[de]所有其它[de]组件在内核外部分离[de]、保护内存[de]进程中运行。有问题[de]系统服务不再作为孤立[de]故障点，而是在它破坏其它服务或操作系统内核之前被终止并重启。

2. 所有[de]组件能够通过消息传递进行通信，一个定义良好[de]通信机制保障了程序在保持彼此安全隔离[de]前提下进行数据交换。适当实现[de]消息传递也可以作为一个虚拟[de]“软件总线”，允许几乎任何[de]软件组件，甚至是一个设备驱动程序被动态地加入或替换，对于必须提供连续服务[de]系统而言这是一项关键要求。

和传统[de]操作系统架构相比，微内核支持嵌入式设备赢得明显更快[de]平均修复时间(MTTR)。例如，如果一个设备驱动程序失败将可能出现以下情况：操作系统可以终止该驱动程序，回收其正在使用[de]资源，并对其进行重新启动，这个过程通常这只需要几个毫秒时间。

尽管和传统[de]操作系统相比，基于消息传递[de]微内核RTOS通常提供了更好[de]容错性和动态升级能力，也有一些观点认为消息传递增加了开销。在实际应用中，如果实现正确，消息传递[de]性能可以接近底层硬件[de]内存带宽。例如，一个微内核RTOS可以采用多段式(multipart)消息和线程到线程[de]消息数据直接拷贝等各种技术，来确保系统性能可以达到传统[de]进程间通信(IPC)方法[de]水平。由一些组织如Dedicated Systems(网址：www.omimo.be)等进行[de]独立测试证实，和传统[de]RTOS相比，微内核RTOS在一系列[de]实时指标方面表现良好，在很多情况下甚至有更好[de]表现。

策略决策

RTOS有助于使一个复杂[de]应用程序具有可预测性和可靠性。当然，选择一个合适[de]RTOS本身就是一项复杂[de]任务，而RTOS[de]底层架构是选择[de]重要依据，此外还有一些其它因素，包括：

1. 调度算法[de]灵活选择。RTOS应该支持调度算法[de]选择(先入先出(FIFO)、轮询(round robin)、零星调度等)并支持以线程为单位设定这些算法。这样，工程师就可以不必将一个算法用到系统中[de]所有线程。

2. 图形用户界面(GUI)。RTOS使用[de]是原始[de]图形库还是能支持多层界面、多路显示、3D渲染以及其它高级[de]图形功能[de]真正[de]窗口系统？能很容易定制GUI[de]外观吗？GUI支持同时显示和输入多种语言(汉语、韩语、日语、英语、俄语等)吗？

3. 远程诊断工具。因为对很多嵌入式系统而言，中断系统运行进行检测和维护是无法接受[de]。RTOS供应商应该提供诊断工具，这些工具能够在不中断系统服务[de]前提下分析系统[de]行为。要寻找能提供代码覆盖、应用测评、跟踪分析和内存分析工具[de]供应商。

4. 开发平台。RTOS提供商提供[de]开发环境是基于像Eclipse那样[de]开放平台，允许工程师嵌入所喜爱[de]第三方工具来进行建模、版本控制吗？还是开发环境基于专利技术？

5. 互联网功能。RTOS支持预集成最新[de]IPv4、IPv6、IPsec、SCTP和具有NAT功能[de]IP过滤等协议栈套件吗？它支持嵌入式网络浏览器吗？浏览器应该具有可扩展[de]封装模式，并能够在很小[de]屏幕上绘制网页。它也应该支持像HTML 4.01、XHTML 1.1、SSL 3.0和 WML 1.3这样[de]标准。

6. 标准API。RTOS将你限定到专有[de]API之中了吗？还是它对于像POSIX这样[de]标准API提供了完全[de]支持，这使得将代码移植到其它操作系统，或者从其它操作系统移植代码变得更容易？另外，所用[de]RTOS提供完全一致性[de]API还是仅仅支持被定义接口[de]一个子集？例如，POSIX.1[de]最新版本包含了大约1,300个接口。

7. 多处理技术。RTOS能支持对称多处理和分布式多处理技术来提高应用性能和容量吗？如果这样，是必须重新设计你[de]应用程序呢，还是RTOS能够将应用程序透明[de]分配到多个处理器上去呢？

8. 源代码工具包。RTOS供应商提供了能使RTOS满足设计需求[de]具有详细文档[de]定制工具包吗？供应商提供了方便开发驱动定制硬件[de]驱动程序开发工具包吗？

9. 对于很多公司而言，选择一款RTOS是一项战略性决策。RTOS供应商在对上述问题提供了清楚[de]回答后，你将选择出一个在现在和将来都适合你[de]RTOS。

上一页  [1] [2]