为什么不是每个操作系统都是实时的？答案

【问题标题】：Why isn't every OS real-time?为什么不是每个操作系统都是实时的？
【发布时间】：2011-03-27 20:53:37
【问题描述】：

我只听说过关于 RTOS 的好消息——它们让程序员可以更好地控制调度程序，例如：避免优先级倒置，他们的时序更一致，更好的多任务处理。但是所有标准桌面设置都使用非实时操作系统。所以使用 RTOS 必须有一些权衡，它们是什么？

【问题讨论】：

标签： operating-system real-time real-time-systems

【解决方案1】：

RTOS 通常以吞吐量性能和功能换取可预测性和可处理性。人们通常对“实时”的定义是“确定性的”。不付出代价就无法拥有确定性。

在通用操作系统中，我们受到“常见情况”行为的激励——我们想要非常好的平均性能和很大的灵活性。在 RTOS 中，我们希望为“最坏情况”行为设置一个可靠的上限，并且我们为吞吐量或常见情况行为付出了（通常是高昂的代价）。

是的，可以创建混合体，例如 Windows 甚至 Linux 实时线程。但是在某个地方，您通常会付出代价，因为最终只有有限的可用资源集（CPU、IO 带宽等）并且消费者操作系统和 RTOS 围绕不同的标准进行优化。一些 RT Linux 方法通过分区明确地处理这个问题。在每个分区中针对不同的假设和不同的最优性标准进行了优化。

交易了哪些功能？我无法提供准确的列表——更重要的是通用操作系统往往有无数的驱动程序，并且能够跟上流失的速度新设备； RTOS 倾向于专注于更小的集合，对于这些集合，及时性可以很好理解，也可以明确避免干扰其他活动。您可能不会在普通 RTOS 上选择相同的驱动程序，因为通常实施它们是不合理的。

吞吐量记住“实时”！=“真正快速”。当系统是实时的时，这意味着活动的完成时间是其正确性的一部分。在某些情况下，这意味着非常快速地处理许多活动（高吞吐量）；在其他情况下，它可能在相对缓慢但非常可预测的时期进行处理。 RTOS 中的结构可能具有高吞吐量，但通常无法达到等效 RTOS 的吞吐量，因为用于公平实现该吞吐量的技术（缓存、花哨的交互驱动调度方法、“公平”排队和锁争用）会影响反对任何单个任务的及时性的可预测性。

【讨论】：

交易了哪些功能？你所说的“吞吐量性能”是什么意思，我的印象是，在 RTOS 上运行的运行速度与在任何地方运行的速度一样快。
注意：实时线程并不是真正的实时，因为它们不能绝对控制处理器的行为。 :\ 不过，它们已经很接近了。
@Mehrdad：我同意和不同意，这正是我的观点。你可以创建一个混合体，但你会得到一些不同的东西。我认为 Win/Linux RT 线程从广义上来说是“实时的”——它们明确关注及时性。它们不是确定性的，就像某些 RTOS 中的线程一样。在我的世界里，“实时”！=“确定性”。
@andersoj：我以为realtime = deterministic?
@Mehrdad：我在这里担任职务。就像我在上面承认的那样，许多使用“实时”一词的用户断言它意味着确定性。不是全部。在我的领域（国防）中那些在 RTOS 上构建大量 RT 系统的人不会以这种方式使用它。其他相关学科（航空或工业自动化）在说实时时几乎总是意味着确定性（但他们生活在一个方便的虚构中）。然而，有一种根深蒂固的工业和学术观点确实如此。我猜这个词的含义没有最终权威可以诉诸——它意味着它的用途，这是不一致的。

【解决方案2】：

我不确定这是否是一个很大的原因，但我相信处理器中存在像 System Management Mode 这样的非实时功能并不能真正实现实时操作系统，因为 SMM 可以任意采用只要它想响应 SMI，操作系统能做的最好的事情就是在它重新获得控制权时超时并崩溃——如果它会及时重新获得控制权。因此，您还需要 BIOS 是实时的，这并不像只有一家像微软这样的公司使其操作系统成为实时的那么容易（无论如何这本身并不容易）。

无论如何，对于普通用户来说可能不会有太多收益。

【讨论】：

谢谢——但这并没有作为一个破坏交易的东西跳出来。当然，您可以在 RTOS 中创建一个最高优先级的进程，并使用它来完成维基百科页面中“使用”下列出的所有事情。
@Matt：这将涉及 (1) 英特尔/AMD 等处理器公司，(2) 微软等操作系统制造商，(3) Phoenix、AMI 等 BIOS 制造商，(4) 可以发出高优先级中断的所有其他设备的制造商，(5) 许多软件公司。这是可能的，但成本可能会超过收益。

【解决方案3】：

有助于桌面应用程序开发的功能在需要实时操作系统的应用程序中并不重要。因此，RTOS 供应商倾向于将他们的工程时间集中在对客户很重要的事情上，例如快速启动和错误恢复。

在快速应用程序开发和实时之间存在重叠市场之前，您不太可能看到操作系统供应商在两者之间分配其资源。快速开发和安全关键不能同时使用。

随着 Blackberry Playbook 迁移到 QNX，我们可能会第一次看到一个友好的 RTOS 开发环境（库和工具）。

【讨论】：

“在快速应用程序开发和实时之间存在重叠市场之前，您不太可能看到操作系统供应商在两者之间分配其资源。”我想我的问题是我不明白这些相互排斥的程度。什么是 RAD 友好功能的示例，该功能会出现在标准桌面操作系统中，但操作系统无法接受？
@Matt：它们在 RTOS 中并不是不可接受的，它们在代表几乎所有 RTOS 被许可方的安全关键型应用程序中是不可接受的。为什么 RTOS 供应商会花时间将 Visual Basic for Applications（或单声道或 JVM）移植到他们的操作系统，因为它的性质限制了大多数客户使用它。
我想这是我不明白的事情——为什么不能在 RTOS 下运行 JVM？
@Matt：如果你移植了一个，你可以......但它对购买 RTOS 的人没有帮助，因为它没有得到足够的验证，无法在安全关键系统中使用。那么为什么要花时间和金钱来移植一个呢？我猜你可以开发一个经过充分验证的 JVM，但是你的竞争对手会花时间做客户要求的事情，这样就会拥有巨大的竞争优势。
@Ben Voigt：存在许多实时 JVM...stackoverflow.com/questions/4051966/… 包括来自 aicas 的一个，我相信它可以实现 DO-178B 验证/认证。

【解决方案4】：

这与“为什么不是每个人都用 C 编写 webapps？”的原因基本相同。它的速度要快得多，但是要困难得多。大型系统上的 RTOS 变得笨拙，因为很多控制权都交给了应用程序程序员。

【讨论】：

我从未对 RTOS 进行过编程——那它会变得更难吗？你可以承担更多的控制权，但你必须这样做吗？非 RT 和 RTOS 都存在 Qt，有一些差异，但并不多。
Qt 抽象出大量内容，让您在 RTOS 中感到快乐。
我现在找不到该页面，但诺基亚网站列出了许多 Qt for QNX 没有的功能，我记得唯一的主要功能是没有 QProcess。（也许也没有声子，或者类似的东西。）