RTOS 的最佳定义是什么？答案

【问题标题】：What is the best definition of an RTOS?RTOS 的最佳定义是什么？
【发布时间】：2016-01-16 17:32:49
【问题描述】：

我还没有找到足够具体、有意义的 RTOS 定义。我能找到的最好的是在 wiki 上：

https://en.wikipedia.org/wiki/Real-time_operating_system

但是我有一些关键的 cmets/问题：

我发现的所有 RTOS 定义中似乎都未定义“实时”。没有什么比实际实时快（无限小！）。因此，我相信“实时”只有在观察者的情况下才有意义。使用 iPhone 用户的人的实时时间可能小于 20 毫秒，因为人眼无法比这更快地检测到变化。对于安全气囊部署，它可能小于 1 毫秒。互联网上的所有定义似乎都掩盖了“实时”的定义！

如果 RTOS 是由在特定时间范围（“截止日期”）内执行某事的要求定义的，为什么定义中会出现抖动？如果 iPhone 响应在 12-14ms 之间抖动，是不是不再实时响应了？它满足20ms的要求，对吧？如果有一次响应达到 100 毫秒，用户可能会注意到，此时系统不是 RTOS
怎么可能有“软”RTOS？！ RTOS 的定义是满足特定的截止时间要求。如果它不满足它，那么它就不是 RTOS！ RTOS 的定义本身就禁止“软”RTOS

在我看来，RTOS 似乎没有正式和精确的定义。这是一个通用术语，用于解释操作系统的特征，其主要优先级是对特定类型的观察者呈现“实时”（按要求编号）。似乎这个名称也具有实现含义，例如事物的处理方式、多任务处理、消息传递、信号量等......如果系统无法在内部响应，所有这些都可能根本不是 RTOS 的一部分“截止日期”要求，对吧？

对于这样一个无处不在的问题，我感到很抱歉，但我无法在我的脑海中得到一个清晰的画面。我发现的所有定义都不够精确，或者将定义与实现细节混为一谈。

【问题讨论】：

据我所知，没有定义 RTOS 确切含义的标准机构，因此该术语定义不明确，就像“PC”或“汽车”等术语一样。除此之外的任何答案都必须主要基于意见。
虽然是的，但这是一个绝妙的问题，我有兴趣阅读所提供的答案。不幸的是，这样的问题不适合 stackoverflow，因为它没有编程问题，只有理论场景具有非优化的代码/服务器性能。像这样的问题最适合 superuser.com
@DarylGill：“非优化代码”实际上对于实时代码来说相当普遍。那是因为您非常喜欢保证性能而不是平均性能。 10-12 毫秒优于 1-13 毫秒，在实时代码中，即使 11 > 7。

标签： rtos

【解决方案1】：

您是对的，没有定义定义确切的时间范围。这不是定义的目标。但是，实时不依赖于观察者，而是依赖于应用程序。由于应用程序不同，时间界限也不同，因此定义不能将该界限作为数字给出。

只要满足应用程序的时间限制，抖动就无关紧要。你对这个例子是绝对正确的。如果最后期限是 20 毫秒，那么占用 100 毫秒是失败的。如果操作系统是造成延迟的罪魁祸首，那它就不是 RTOS。

“软实时”有一个非常具体的含义，这可能是你唯一真正弄错的地方。这里的工作理念是，当一项任务超过其截止日期时，你会怎么做？（注意：这可能是任务本身的错误，也可能是 RTOS 的错误。）在硬实时系统中，任务不再具有任何价值。迟到的结果和没有结果一样好，你取消了任务。冒其他任务的风险是没有意义的。

软 RTOS 实际上更复杂。完成任务仍然有价值，尽管有所减少。所以 RTOS 不能硬杀任务，但 OS 仍然必须确保其他任务按时完成。这需要额外的小心，如果你只是杀死任务就没有必要了。

【讨论】：

谢谢，请注意，我不是在寻找 RTOS 定义中的时间限制，而是试图在 RTOS 的上下文中建立“实时”的定义。我用了“观察者”这个词，但也想过像你说的那样用“应用程序”。

【解决方案2】：

有一个Embedded Systems Dictionary。以下是部分摘录：

实时调整。有及时性要求，通常是不能错过的最后期限。

实时操作系统 n.专为在实时系统中使用而设计的操作系统。缩写为 RTOS。

实时系统 n.任何具有时效性要求的嵌入式或其他计算机系统。可以使用以下问题将实时系统与其他系统区分开来：“是一个迟到的答案比错误的答案更糟糕，甚至更糟？”换句话说，会发生什么如果计算没有及时完成？如果没有什么不好的事情发生，它不是一个实时系统。如果有人死亡或任务失败，它通常被认为是“硬”实时，这意味着系统有严格的最后期限。介于两者之间的一切都是“柔软的” 实时。

【讨论】：