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

　　首先，我们必须考虑任务同步如何能造成阻塞，而阻塞反过来又如何导致优先级反转。我们假设有任务 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 时间。这种分配限制确保了其他进程保持各自的可用性;例如，它能保证可访问的用户界面(如远程终端)。因此，操作人员能访问系统并解决问题——无需按动复位开关。

　　但是，这种方法也存在问题。由于调度算法是固定的，因此一个分区无法使用分配到另一个分区的 CPU 周期，即使这些分区未使用其分配的周期。这种方法会浪费 CPU 周期并阻止系统处理高峰需求。因此，系统设计人员必须使用更昂贵的处理器应对运行缓慢的系统，或限制系统能支持的功能数量。