您何时需要实时操作系统？

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

避免优先级反转

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

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

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

阻塞允许任务 2 运行，直到任务 1 等待的条件出现为止(例如，任务 2 对两个任务共享的资源解锁)。此时，任务 1 可以执行。任务 1 须等待的总时间就是阻塞因数。如果任务 1 满足一定的时间限制，该因数不会随任何参数变化，如线程数或系统内的输入。换句话说，必须限制阻塞因数。

现在，我们引入第三个任务(任务 3)——其优先级比任务 2 的高但比任务 1 的低(参见图 1)。当任务 2 正在运行时，任务 3 准备运行，它会抢占任务 2，而任务 2 在任务 3 阻塞或完成前都无法运行。当然，这样会增加任务 1 的阻塞因数;也就是说，它会进一步延迟任务 1 的运行。抢占导致的总延迟就是优先级反转。　　

图 1. 当任务 3 抢占任务 2 时，任务 1 等待任务 2 完成运行。这进一步延迟了任务 1 的运行。　　

图 2. 任务 2 继承了任务 1 的优先级，因而阻止了任务 3 抢占任务 2。
任务 3 不再延迟任务 1 的运行。

实际上，可以有多个任务以这种方式抢占任务 2，从而导致连续阻塞的结果。在这种情况下，任务 2 可能被无限期地抢占，产生无限期的优先级反转，导致任务 1 无法满足其最后期限。

这时优先级继承就会发挥作用。如果我们回到上述假设中，在同步期内使任务 2 以任务 1 的优先级运行，那么任务 3 就无法抢占任务 2，这样就能避免优先级反转的产生(参见图 2)。

分区调度程序

保证资源的可用性对许多系统都至关重要。如果某个关键子系统(如 CPU 周期)丢失，用户就无法获取该子系统提供的服务。例如，在拒绝服务 (DoS) 攻击中，恶意用户会利用需要优先级高的进程处理的请求攻击系统。该进程会使 CPU 过载并导致其他进程的 CPU 周期匮乏，从而使用户无法使用系统。

安全漏洞并非是导致进程匮乏的唯一原因。在许多情况下，增加系统的软件功能都会导致系统“濒临危险边缘”，导致现有应用程序的 CPU 时间匮乏。及时运行的应用程序或服务不再按预期或要求的那样迅速响应。根据以往经验，解决这一问题的唯一途径是更新硬件或重新编码(重新设计软件)，但这两种方法都不尽如人意。

为解决这些问题，系统设计人员需要一种可通过硬件或软件执行 CPU 预算的分区计划，以阻止进程或线程独占其他进程或线程所需的CPU 周期。因为实时操作系统已经提供了对 CPU、内存和其他计算资源的集中访问，所以它是执行 CPU 分区预算的最佳选择。

某些实时操作系统提供了固定分区调度算法。系统设计人员能利用这种调度算法对任务进行分组或分区，然后为每个分区分配一定比例的 CPU 时间。利用这种方法，任何既定分区内的任务消耗的 CPU 时间都不会超过该分区静态确定的比例。例如，我们假设为分区分配了 30% 的 CPU。如果该分区内的进程随后成为拒绝服务攻击的目标，它会消耗不超过 30% 的 CPU 时间。这种分配限制确保了其他进程保持各自的可用性;例如，它能保证可访问的用户界面(如远程终端)