- 您何时需要实时操作系统?

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

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

自适应分区

另一种被称作自适应分区的方法提供了更灵活的动态调度算法，从而有效克服了这些缺陷。与静态分区一样，自适应分区允许系统设计人员为单独进程或一组进程预留 CPU 周期。因此，系统设计人员能保证一个子系统或分区上的负载不会影响其他子系统的可用性。而且，与静态分区不同的是，自适应分区还能将空闲分区中的 CPU 周期以动态方式重新分配到可受益于额外处理时间的分区——只有当 CPU 满载时，分区预算才会执行。因此，系统就能处理高峰需求并使利用率达到 100%，同时又能继续享受资源保证带来的收益。

同样重要的是，自适应分区还能直接应用于先有系统，而无需重新设计代码或修改代码。例如，在 QNX Neutrino 中，系统设计人员只需启动分区内已有的基于 POSIX 应用程序，实时操作系统的调度程序就会确保每个分区都会收到分配的预算。在每个分区内，会继续根据基于优先级的抢占式调度算法对每项任务进行调度——应用程序不必更改其调度运行。此外，系统设计人员还能以动态方式重新配置分区，以精确调节系统实现最佳性能。

图 3——自适应分区可阻止优先级高的任务消耗超过其分配的规定比例的 CPU，除非系统包含未使用的 CPU 周期。例如，任务 A 和任务 D 可在分配至分区 3 的时间内运行，因为任务 E 和任务 F 不需要剩余的 CPU 周期预算。 6

“组合”内核

通用操作系统(包括 Linux、Windows 和各种类型的 Unix 系统)通常都缺少我们目前介绍的实时机制。但供应商已开发出许多实时扩展组件和补丁，试图填补这一空白。例如，有一种双内核方法，其中的通用操作系统能以任务的形式在专用实时内核上运行(参见图 4)。任何需要确定性调度的任务都会在该内核中运行，但其优先级要高于通用操作系统的优先级。因此，只要这些任务需要运行，它们就能抢占 Linux，而且只有在其工作完成后，才会向 Linux 释放 CPU。

遗憾的是，实时内核中运行的任务只能有限地利用通用操作系统中现有的系统服务，如文件系统、网络服务等。

实际上，如果实时任务向通用操作系统请求任何服务，它都会面临同样的抢占问题，这会阻止通用操作系统以确定方式运行。因此，必须针对实时内核创建新的驱动程序和系统服务，即使通用操作系统中已存在相同的服务。但是，多数通用操作系统为正常的非实时进程提供的受内存管理单元 (MMU) 保护的可靠环境却无法惠及在实时内核中运行的任务。相反，它们会在无保护的内核空间运行。因此，任何含有公共编码错误(如损坏的 C 指针)的实时任务都会轻易导致内核出现严重故障。这的确是一个问题，因为需要实时功能的大部分系统同样需要极高的可靠性。

双内核方法的不同实现使用不同的应用程序接口 (API) 使问题进一步复杂。在多数情况下，为通用操作系统编写的服务无法轻易移植到实时内核中，而且针对一个供应商的实时扩展组件编写的任务未必能在另一个供应商的实时扩展组件上运行。

图 4——在常见的双内核实现中，通用操作系统会作为优先级最低的任务在单独的实时内核中运行。

这种解决方案指出了使通用操作系统支持实时运行的实际困难和复杂性。但这并非是关于实时操作系统和通用操作系统孰优孰劣的问题。通用操作系统(如 Linux、Windows 和各种 Unix 系统)都能以台式机或服务器操作系统的形式正常运行。但是，当进入不符合其设计用途的确定运行环境中(如车载远程信息处理装置、医疗器械、实时控制系统和连续媒体应用)时，它们就会凸显不足。 7

令调试和定制更轻松的源代码