您何时需要实时 *** 作系统?

　　大部分嵌入式项目还需要实时 *** 作系统吗?这个问题问得好，因为现代高性能处理器和 Linux、Windows 和其他通用 *** 作系统 (GPOS) 的实时补丁的可用性都在飞速发展。嵌入式设备的本质道出了答案。在许多情况下，制造设备都需要几千甚至几百万个部件。哪怕设备硬件的单位成本节省 1 美元，都会为制造商带来不小的财富。换言之，设备无法承受数千兆赫兹级处理器的成本(更不用说热耗散了)。例如，在汽车远程信息处理技术市场，常见的 32 位处理器以约 600 Mhz 的速度运行——远远慢于台式机和服务器的常用处理器。在这种运行环境中，实时 *** 作系统能得到低端硬件超快、可预测的响应，因此具有显著的节约成本的优势。

　　除节约成本之外，实时 *** 作系统提供的服务还能使许多计算问题迎刃而解，特别是当多种运行争夺系统资源时。例如，试想一个用户期望(或需要)立即响应输入的系统。利用实时 *** 作系统，软件开发人员能确保用户启动的 *** 作会先于其他系统活动执行，除非必须先执行更重要的任务(如帮助保护用户安全的运行)。

　　再试想一个必须满足服务质量 (QoS) 要求的系统，例如一台可播放现场视频的设备。如果设备依靠软件播放其内容，它可能会以用户无法接受的速率出现失帧现象——从用户的角度看，该设备不可靠。但使用实时 *** 作系统的话，软件开发人员就能精确控制软件进程的执行顺序，确保以适当和一致的媒体速率播放。

　　实时 *** 作系统并不“公平”

　　对“硬”实时的需求(以及对实现该功能的实时 *** 作系统的需求)仍然是嵌入式产品业的普遍要求。问题是，实时 *** 作系统具备哪些通用 *** 作系统所不具备的功能呢?适用于一些通用 *** 作系统的实时扩展组件有多大用处呢?它们能提供和实时 *** 作系统一样的性能吗?

　　让我们先从任务调度开始。在通用 *** 作系统中，调度程序通常使用一种“公平”策略，将线程和进程分配到 CPU 中。这种策略可确保台式机和服务器的应用程序所需的较高的总吞吐量，但无法保证优先级高、时间要求严格的线程先于优先级低的线程执行。

　　例如，通用 *** 作系统可能会降低分配给优先级高的线程的优先级，或按照有利于系统内其他线程的公平原则，以动态方式调整优先级。因此，优先级高的线程就可能被优先级低的线程抢占。此外，大多数通用 *** 作系统都具有无限期的分配潜伏期：系统内的线程越多，通用 *** 作系统调度线程执行所需的时间就越久。其中任何一种因素都能导致优先级高的线程错过最后期限，即使在速度很快的 CPU 上。

　　另一方面，在实时 *** 作系统中，线程会按其优先级的顺序执行。如果优先级高的线程准备运行，它能在很短且有限的时间间隔内，从正在执行的优先级低的线程那里接管 CPU。此外，优先级高的线程还能不间断地运行直到完成任务为止——当然，除非它被优先级更高的线程抢占。这种众所周知的基于优先级的抢占式调度，可确保优先级高的线程始终如一地满足最后期限的要求，即使在其他线程争夺 CPU 时间时。

　　抢占式内核

　　大多数通用 *** 作系统的 *** 作系统内核都不是抢占式的。因此，优先级高的用户线程无法抢占内核调用，相反，它必须等待整个调用全部结束——即使是系统内优先级低的进程进行调用。此外，当驱动程序或其他系统服务(通常在内核调用中运行)以客户端线程的名义执行时， *** 作系统通常会丢失所有优先级信息。这种系统行为会导致无法预料的延迟，而且会妨碍关键运行按时完成。

　　另一方面，在实时 *** 作系统中，内核运行是可抢占的。虽然仍有一些时间窗无法抢占，但在设计精密的实时 *** 作系统中，这些间隔非常短暂，通常大约仅几百纳秒。另外，实时 *** 作系统会针对抢占推迟和中断禁止的时限设置上限;这能保证软件开发人员确定情况最糟的延迟期。

　　为实现这一目标，实时 *** 作系统内核必须尽可能简单、精致。实现这种简单性的最佳途径是设计一种只包含短执行路径服务的内核。通过排除内核中任务集中的运行(如进程加载)并将其分配到外部进程或线程，实时 *** 作系统的设计人员就能保证通过内核的最长的非抢占代码路径有上限。

　　在一些通用 *** 作系统，内核增加了某种程度的可抢占性。但无法抢占的时间间隔仍然比常见实时 *** 作系统的长得多;这种抢占间隔的长度取决于通用 *** 作系统内核中包含的最长的关键模块部分(如网络)。另外，抢占式通用 *** 作系统内核不能解决可能的无限期延迟情形，例如因为客户端调用驱动程序或其他系统服务时丢失优先级信息。

　　避免优先级反转的机制

　　即使在实时 *** 作系统中，优先级低的线程也能在无意中阻止优先级高的线程访问 CPU——这种情况被称为优先级反转。当出现无限期的优先级反转时，可能会错过关键的最后期限，进而导致系统运行异常和全面故障的结果。遗憾的是，在系统设计过程中人们往往会忽视优先级反转。有很多优先级反转的实例，包括 1997 年 7 月火星探路者项目遭受困扰的实例。1

　　一般来说，当优先级不同的两个任务共享资源，而优先级高的任务无法从优先级低的任务那里获得资源时，就会出现优先级反转。为防止这种状况超过有限的时间间隔，实时 *** 作系统可提供一种通用 *** 作系统不具备的选择机制，包括优先级继承和优先级封顶模拟。我们不能单纯地评价两种机制的优劣，所以我们着重介绍优先级继承的实例。

　　首先，我们必须考虑任务同步如何能造成阻塞，而阻塞反过来又如何导致优先级反转。我们假设有任务 1 和任务 2 两个任务正在运行，其中任务 1 具有较高的优先级。如果任务 1 准备执行，但必须等待任务 2 完成运行，就出现阻塞的状况。同步化也会导致这种阻塞;例如，任务 1 和任务 2 共享由锁或信号量控制的资源，任务 1 等待任务 2 对资源进行解锁。或者，当任务 1 请求目前正由任务 2 使用的服务时，也会出现阻塞状况。