探讨选择实时操作系统(RTOS)的要点

的)需要注意这一重入性问题。

现在业内已有很多的任务同步机制，从互斥(mutex)到消息系统。从RTOS的角度，这些机制在诸如竞争条件此类的同步问题上，没有什么差异。

在MCU和操作系统中，定时器很常见。至少，一个定时器可被用作时钟。但由于定时器是如此的有用，以至于它常以一种特殊方式实现出来。POSIX规范甚至把定时器定义为组件。定时器还可当作看门狗来用。

在许多MCU中，一个定时器可以设置用来唤醒处在休眠模式的系统。一些实现允许操作系统把其用作一个通用定时器，尽管这一唤醒特性独立于操作系统。

一些系统具有带不同特性的多种定时器来满足不同的要求。一些定时器可被同步用以为电机控制应用提供同时的脉宽调制(PWM)流。对RTOS来说，一个定时器通常可用以实现时钟和提供时间切片支持。

定时器也支持时间切片。时间切片常见于时间共享系统，它给每种应用一个合理的时间片断来执行。可在任一中断层级上实现这种轮询调度。

通常，由时钟提供的时间切片是固定时长的，每个任务在获得优先权前将被给予同样长度的时间切片来执行。当然，该策略是随机的且可有多种实现。例如，可变的时间切片宽度将允许时间以每个任务为单位进行分配，其中一些任务获得的时间会比另一些长;而若采用任务优先级方法，则有可能使低优先级任务得不到响应。

许多RTOS采用固定调度器。其它RTOS则允许替换或定制，但RTOS中的另一部分支持各种策略。这一灵活方法使得像Linux这样的操作系统能够提供实时支持，与此同时，它们还能在时间切片环境下运行多种应用。实时任务具有高优先级，且在一般用户任务前得到执行。

Linux实际上具有一个更复杂的调度系统，它对任务是通过轮询方法把控制权转交给具有相同优先级的其它任务还是一直运行到结束做出了具体约定。像Open Kernel Labs的OKL4虚拟化RTOS平台解决了该问题。

基本通信

一些文献把任务同步和通信分开来说，但总的来说，它们是一回事。实际上就是讲信息是如何交换的。基于消息传递的RTOS最清楚地体现出这点。这里，消息系统处理所有通信且不区分通信和同步。

至少，RTOS必须提供一个相互排斥的本原，如互斥。其它东西可构建在该本原上。在许多场合，如消息传递系统，对相互排斥的支持隐藏在操作系统内。只有更高级别的消息功能显露于外。

消息系统有各种名称，从管道到队列。其实现可横跨从单处理器、单存储器模式到多内核群集系统。Enea的OSE RTOS和QNX的Neutrino是基于消息传递的两个主线RTOS。

不管选择了什么方法或API，通信系统必须在某一程度上被整合进操作系统。因此，若主动队列中的任务必须等待一个事件，则该任务可被移走。类似，引发一个事件从而导致另一个任务活动的任务将产生一个调度行为。

通信、事件和调度可与硬件关联起来，这是RTOS必须处理的其它一些事。TI的DSP/BIOS是一款RTOS，它设计用于运行在像TI的DaVinci双核系统的DSP上。DSP/BIOS的一个主要功能是处理 ARM 核和DSP 核间的通信。

向更多大内核的发展将很可能会保留RTOS或OS。不过，小内核阻止或限制了采用RTOS的可能性。Intellasys的SEAforth 40C18芯片带有40个运行Forth的小型18位内核。指令很精简，每个字包含四条指令。

每个内核有64个字的 ROM和RAM，该芯片只能容纳10,000指令。当然，这只够装下一个程序，安装RTOS是不可能的。不过，整个芯片上有足够空间安装一个操作环境的特定部分。同样，适于该平台的应用常常是特定的。于是，由于硬件可处理内核之间通信和任务调度，因此RTOS类的支持并不需要。

资源管理

使RTOS脱颖而出的是其管理资源(包括时间和存储器)的能力。时序问题与中断响应时间有关，但资源管理时序问题也会出现。虽然中断解决了一系列时序问题，但各应用仍必须利用资源。

考虑存储器分配情况。许多实时应用不采用动态存储器分配，以确保存储器分配和回收时所产生的不同不会变成一个问题。需要动态存储器分配的应用常把存储器划分为实时和非实时。后者处理动态存储器分配。典型情况下，在使用前，实时部分必须被分配有足够的存储器。

在实时嵌入式应用中采用C和C++是因为存储器和其它资源的用法是显式的。实时任务需要避免采用C和C++。特别是，当存储器分配和回收更容易隐藏时采用C++是很困难的。

像Java和C#这样的语言带来的挑战更大，它们与生俱来地采用动态存储器分配。程序员可控制存储器分配和回收。在某些情况下，编程环境可以强化存储器分配和回收。

Java实时规范(RTSJ)定义了创建不需要垃圾回收的Java应用的方法。RTSJ是在Java框架内这样做的，从而使程序