为什么不是每个操作系统都是实时的？
我所听到的都是有关 RTOS 的好消息——它们使程序员能够更好地控制调度程序，从而避免优先级反转，它们的计时更加一致，更好的多任务处理。但所有标准桌面设置都使用非实时操作系统。因此，使用 RTOS 必须做出一些权衡，它们是什么？
I've heard nothing but good things about RTOSs--they give the programmer greater control over the scheduler so as to e.g. avoid priority inversion, their timing is more consistent, better multitasking. But all standard desktop setups use OSs that aren't real-time. So there must be some tradeoffs to using an RTOS, what are they?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
RTOS 通常会以吞吐量性能和功能来换取可预测性和易处理性。人们对“实时”的通常定义是“确定性的”；如果不付出代价，你就不可能拥有决定论。
在通用操作系统中，我们的动机是“常见情况”行为——我们想要真正良好的平均性能和很大的灵活性。在 RTOS 中，我们希望对“最坏情况”行为有一个可靠的上限，并且我们在吞吐量或常见情况行为方面付出了（通常是高昂的代价）。
是的，可以创建混合线程，例如 Windows 甚至 Linux 实时线程。但在某些地方，您通常会付出代价，因为最终只有有限的可用资源（CPU、IO 带宽等），并且消费者操作系统和 RTOS 围绕不同的标准进行优化。一些 RT Linux 方法通过分区来明确处理这个问题。在每个分区中针对不同的假设和不同的最优性标准进行优化。
交换哪些功能？我无法提供精确的列表 - 更重要的是通用操作系统往往拥有无数的驱动程序，并且能够跟上新设备的变化; RTOS 倾向于关注较小的集合，其及时性可以很好地理解，也可以明确地避免干扰其他活动。您可能不会在普通 RTOS 上选择相同的驱动程序，因为通常实现它们是不合理的。
吞吐量记住“实时”！=“实时快速”。当系统是实时的时，这意味着活动的完成时间是其正确性的一部分。在某些情况下，这意味着非常快速地处理许多活动（高吞吐量）；在其他情况下，它的处理速度可能相对较慢，但极其可预测。 RTOS 中的结构可能具有高吞吐量，但通常无法实现等效 RTOS 的吞吐量，因为用于公平实现该吞吐量的技术（缓存、奇特的交互驱动调度方法、“公平”排队和锁争用）会妨碍反对任何单一任务的及时性的可预测性。
RTOS typically trade throughput performance and features for predictability and tractability. The usual definition of "real-time" folks apply is "deterministic"; you can't have determinism without paying for it.
In general purpose OS'es, we're motivated by "common-case" behaviors -- we want really good average performance, and a lot of flexibility. In RTOS, we want a reliable ceiling on "worst case" behaviors, and we pay (often dearly) in throughput or common-case behaviors.
Yes, it's possible to create hybrids, like Windows or even Linux real-time threads. But somewhere you're typically paying a penalty because ultimately there is only the finite set of resources available (CPUs, IO bandwidth, whatever) and consumer OS'es and RTOS'es optimize around different criteria. Some of the RT Linux approaches deal with this explicitly, by having partitions. Different assumptions and different optimality criteria are optimized for in each partition.
What features are traded? I can't offer a precise list -- it's more that general-purpose OS'es tend to have a zillion drivers, and be able to keep up with the churn of new devices; RTOS tend to focus on a much smaller set for which timeliness can be either well-understood or explicitly kept from interfering with other activities. You probably won't have the same selection of drivers on a normal RTOS because it's not reasonable to implement them, typically.
Throughput Remember "real-time" != "real-fast". When a system is real-time, it means that activities' time of completion is part of their correctness. In some cases, this means processing many activities very quickly (high throughput); in others it may be processing at a relatively slow but extremely predictable period. The structures in an RTOS may have high throughput, but typically can't achieve the throughput of an equivalent RTOS because the techniques used to achieve that throughput fairly (caching, fancy interactivity-driven scheduling approaches, "fair" queuing and lock contention) militate against predictability of any single task's timeliness.
我不确定这是否是一个重要原因，但我相信非实时功能的存在，例如 系统管理处理器中的模式实际上并不允许实时操作系统，因为 SMM 可以任意长时间地响应 SMI，而操作系统最多只能在以下情况下超时并崩溃：它重新获得控制权—— 如果它及时重新获得控制权。因此，您还需要 BIOS 是实时的，这并不像只有 Microsoft 这样的一家公司实现其操作系统实时那么容易（无论如何，这本身并不容易）。
无论如何，对于普通用户来说可能不会有太多收益。
I'm not sure if this is a big reason, but I believe the existence of non-realtime features like System Management Mode in the processor doesn't really allow for a real-time OS, because SMM can take as arbitrarily long as it wants to respond to an SMI, and the best the OS can do is just time out and crash when it gains back control -- if it gains back control in a timely manner. So you'd need the BIOS to be realtime as well, which is not quite as easy as having just one company like Microsoft make its OS realtime (which isn't easy by itself anyway).
And there probably wouldn't be too much gain for the average user, anyway.
有助于桌面应用程序开发的功能对于需要实时操作系统的应用程序来说并不重要。因此，RTOS 供应商倾向于将工程时间集中在对客户重要的事情上，例如快速启动和错误恢复。
在快速应用程序开发和实时应用程序开发之间存在重叠市场之前，您不太可能看到操作系统供应商在两者之间分配资源。快速开发和安全关键是不能并存的。
随着 Blackberry Playbook 迁移到 QNX，我们可能会第一次看到 RTOS 的友好开发环境（库和工具）。
Features that help with desktop application development just aren't important in applications that require a real-time OS. So RTOS vendors tend to focus their engineering time on things that are important to their customers, like fast booting and error recovery.
Until there's a market for overlap between rapid application development and real-time, you're unlikely to see an OS vendor split its resources between both. Rapid development and safety-critical just don't go together.
With the Blackberry Playbook moving to QNX, we might see for the first time a friendly development environment (libraries as well as tools) for an RTOS.
这与“为什么不是每个人都用 C 语言编写 webapps？”的原因基本相同。它快得多，但是也困难得多。大型系统上的 RTOS 变得笨重，因为很多控制权都交给了应用程序员。
It is basically the same reason as "why doesn't everyone write webapps in C?". Its a lot faster, but, it is much more difficult. RTOSs on a large system becomes unwieldy because a lot of the control is given to the application programmer.