RTOS 的最佳定义是什么？
What is the best definition of an RTOS?
我还没有找到足够具体且有意义的 RTOS 定义。我能找到的最好的一个是在 wiki 上：
https://en.wikipedia.org/wiki/Real-time_operating_system
但是我有一些批评意见comments/questions：
- "Real Time" 在我发现的所有 RTOS 的定义中似乎都未定义。没有什么比真正的实时更快（无限小！）。因此，我相信 "real time" 仅在观察者的上下文中才有意义。使用 iPhone 用户的人的实时时间可能小于 20 毫秒，因为人眼无法检测到比这更快的变化。对于安全气囊展开，它可能小于 1 毫秒。互联网上的所有定义似乎都掩盖了 "real time"!
的定义
- 如果RTOS定义为在特定时间范围内执行某事的要求（"deadline"），为什么抖动会出现在定义中？如果iPhone响应在12-14ms之间抖动，是不是不再实时响应了？满足20ms的要求吧？如果有一次响应达到 100 毫秒，用户可能会注意到，此时系统不是 RTOS
- 怎么可能有"soft"转发OS？！ RTOS 的定义是满足特定的截止时间要求。不符合就不是RTOS！ RTOS 的定义禁止 "soft" RTOS
在我看来，RTOS 似乎没有正式和准确的定义。这是一个通用术语，用于解释 OS 的特征，其主要优先级是 "real time"（根据要求编号）对特定类型的观察者的表现。这个名字似乎也具有实现意义，例如如何处理事物、多任务、消息传递、信号量等......所有这些都可能根本不是 RTOS 的一部分，如果系统没有在 "deadline" 要求内回应，对吧？
抱歉这么普遍的问题，但我脑子里想不清楚。我发现的所有定义都不够精确，或者混淆了实现细节的定义。
你是对的，没有定义定义确切的时间范围。这不是定义的目标。但是，实时并不依赖于观察者，而是应用程序。由于应用程序不同，时间范围也不同，因此定义不能以数字形式给出该范围。
只要满足应用程序的时间限制，抖动就无关紧要。你对这个例子完全正确。如果截止日期是 20 毫秒，则占用 100 毫秒是失败的。如果 OS 是造成延迟的原因，那不是 RTOS。
"Soft realtime" 具有非常具体的含义，这可能是您唯一真正弄错的地方。这里的工作概念是，当任务超过截止日期时你会怎么做？ （注意：这可能是任务本身的错误，也可能是 RTOS。）在硬实时系统中，任务不再具有任何价值。迟到的结果和没有结果一样好，你取消了任务。没有必要冒其他任务的风险。
软RTOS其实比较复杂。完成任务仍然具有价值，尽管有所减少。所以 RTOS 无法硬终止任务，但 OS 仍然必须确保其他任务在截止日期前完成。这需要格外小心，如果您只是终止任务就没有必要了。
有一个Embedded Systems Dictionary。以下是一些摘录：
real-time adj. Having timeliness requirements, typically in the form of deadlines that can’t be missed.
real-time operating system n. An operating system designed specifically for use in real-time systems. Abbreviated RTOS.
real-time system n. Any computer system, embedded or otherwise, that has timeliness requirements. The following question can be used
to distinguish real-time systems from the rest: “Is a late answer as
bad, or even worse, than a wrong answer?” In other words, what happens
if the computation doesn’t finish in time? If nothing bad happens,
it’s not a real-time system. If someone dies or the mission fails,
it’s generally considered “hard” real-time, which is meant to imply
that the system has hard deadlines. Everything in between is “soft”
real-time.
我还没有找到足够具体且有意义的 RTOS 定义。我能找到的最好的一个是在 wiki 上：
https://en.wikipedia.org/wiki/Real-time_operating_system
但是我有一些批评意见comments/questions：
- "Real Time" 在我发现的所有 RTOS 的定义中似乎都未定义。没有什么比真正的实时更快（无限小！）。因此，我相信 "real time" 仅在观察者的上下文中才有意义。使用 iPhone 用户的人的实时时间可能小于 20 毫秒，因为人眼无法检测到比这更快的变化。对于安全气囊展开，它可能小于 1 毫秒。互联网上的所有定义似乎都掩盖了 "real time"! 的定义
- 如果RTOS定义为在特定时间范围内执行某事的要求（"deadline"），为什么抖动会出现在定义中？如果iPhone响应在12-14ms之间抖动，是不是不再实时响应了？满足20ms的要求吧？如果有一次响应达到 100 毫秒，用户可能会注意到，此时系统不是 RTOS
- 怎么可能有"soft"转发OS？！ RTOS 的定义是满足特定的截止时间要求。不符合就不是RTOS！ RTOS 的定义禁止 "soft" RTOS
在我看来，RTOS 似乎没有正式和准确的定义。这是一个通用术语，用于解释 OS 的特征，其主要优先级是 "real time"（根据要求编号）对特定类型的观察者的表现。这个名字似乎也具有实现意义，例如如何处理事物、多任务、消息传递、信号量等......所有这些都可能根本不是 RTOS 的一部分，如果系统没有在 "deadline" 要求内回应，对吧？
抱歉这么普遍的问题，但我脑子里想不清楚。我发现的所有定义都不够精确，或者混淆了实现细节的定义。
你是对的，没有定义定义确切的时间范围。这不是定义的目标。但是，实时并不依赖于观察者，而是应用程序。由于应用程序不同，时间范围也不同，因此定义不能以数字形式给出该范围。
只要满足应用程序的时间限制，抖动就无关紧要。你对这个例子完全正确。如果截止日期是 20 毫秒，则占用 100 毫秒是失败的。如果 OS 是造成延迟的原因，那不是 RTOS。
"Soft realtime" 具有非常具体的含义，这可能是您唯一真正弄错的地方。这里的工作概念是，当任务超过截止日期时你会怎么做？ （注意：这可能是任务本身的错误，也可能是 RTOS。）在硬实时系统中，任务不再具有任何价值。迟到的结果和没有结果一样好，你取消了任务。没有必要冒其他任务的风险。
软RTOS其实比较复杂。完成任务仍然具有价值，尽管有所减少。所以 RTOS 无法硬终止任务，但 OS 仍然必须确保其他任务在截止日期前完成。这需要格外小心，如果您只是终止任务就没有必要了。
有一个Embedded Systems Dictionary。以下是一些摘录：
real-time adj. Having timeliness requirements, typically in the form of deadlines that can’t be missed.
real-time operating system n. An operating system designed specifically for use in real-time systems. Abbreviated RTOS.
real-time system n. Any computer system, embedded or otherwise, that has timeliness requirements. The following question can be used to distinguish real-time systems from the rest: “Is a late answer as bad, or even worse, than a wrong answer?” In other words, what happens if the computation doesn’t finish in time? If nothing bad happens, it’s not a real-time system. If someone dies or the mission fails, it’s generally considered “hard” real-time, which is meant to imply that the system has hard deadlines. Everything in between is “soft” real-time.