我的意思是实时操作系统如何以及为什么能够满足最后期限而不会错过它们？或者这只是一个神话（他们不会错过最后期限）？它们与常规操作系统有什么不同，以及是什么阻止了常规操作系统成为RTOS？
答案 0 :(得分：29)
会议截止日期是您编写的应用程序的功能。 RTOS只提供帮助您满足截止日期的设施。你也可以在一个大的主循环中对“裸机”（没有RTOS）进行编程，并满足你的最后期限。
另请注意，与更通用的操作系统不同，RTOS的任务和流程集非常有限。
RTOS提供的一些功能：
基于优先级的计划程序
对于单个任务/流程，大多数RTOS具有32到256个可能的优先级。调度程序将以最高优先级运行任务。当正在运行的任务放弃CPU时，将运行下一个最高优先级的任务，依此类推......
系统中优先级最高的任务将使用CPU，直到：
作为开发人员，您的工作是分配任务优先级，以便满足您的截止日期。
系统时钟中断例程
RTOS通常会提供某种系统时钟（从500 uS到100 ms），允许您执行时间敏感的操作。 如果你有一个1ms的系统时钟，并且你需要每50ms做一次任务，那么通常有一个API可以让你说“在50ms内唤醒我”。此时，任务将一直处于休眠状态，直到RTOS将其唤醒。
请注意，只是被唤醒并不能确保您在那个时候准确地跑。这取决于优先级。如果当前正在运行具有更高优先级的任务，则可能会延迟。
确定性行为
RTOS非常长，以确保无论您有10个任务，还是100个任务，都不需要更长时间来切换上下文，确定下一个最高优先级任务是什么等等......
通常，RTOS操作尝试为O（1）。
RTOS中确定性行为的主要领域之一是中断处理。当发出中断线信号时，RTOS立即切换到正确的中断服务程序并立即处理中断（无论当前运行的任何任务的优先级如何）。
请注意，大多数特定于硬件的ISR都是由项目开发人员编写的。 RTOS可能已经为串行端口，系统时钟，网络硬件提供了ISR，但任何专门的（起搏器信号，执行器等......）都不会成为RTOS的一部分。
这是一个粗略的概括，与其他一切一样，有各种各样的RTOS实现。一些RTOS以不同的方式做事，但上面的描述应该适用于大部分现有的RTOS。
答案 1 :(得分：3)
在RTOS中，应该注意的最关键参数是较低的延迟和时间确定性。通过遵循某些政策和伎俩，这是令人愉快的。
在GPOS中，除了可接受的延迟外，关键参数还包括高吞吐量。你不能指望GPOS的时间决定论。
RTOS的任务比GPOS中的进程/线程轻得多。
答案 2 :(得分：2)
并不是说他们能够满足最后期限，而是他们确定了截止日期，而在常规操作系统中没有这样的截止日期。
在常规操作系统中，任务调度程序并不是非常严格。也就是说，处理器每秒会执行如此多的指令，但有时可能不会这样做。例如，可以抢占任务以允许执行更高优先级的任务（并且可以持续更长时间）。在RTOS中，处理器将始终执行相同数量的任务。
此外，通常会有完成任务的时间限制，然后报告失败。这在常规操作系统中不会发生。
显然需要解释更多细节，但以上是RTOS中使用的两个重要设计方面。
答案 3 :(得分：2)
您的RTOS的设计方式可以保证重要事件的时间安排，例如硬件中断处理和在需要时准确唤醒睡眠进程。
这个确切的时间允许程序员确定他的（比方说）起搏器将在需要时准确输出脉冲，而不是几十毫秒之后，因为操作系统正在忙于另一个低效的任务。
它通常比完全成熟的Linux或Windows简单得多，只是因为它更容易分析和预测简单代码的行为。没有什么可以阻止在RTOS环境中使用像Linux这样的完全成熟的操作系统，并且它具有RTOS扩展。由于代码库的复杂性，它无法保证其时序可以像小型操作系统一样小。
RTOS调度程序也比通用调度程序更严格。重要的是要知道调度程序不会更改您的任务优先级，因为您已经运行了很长时间并且没有任何交互式用户。大多数操作系统会将内部优先级降低到这种类型的过程，以支持不应该看到界面滞后的短期交互式程序。
答案 4 :(得分：2)
您可能会发现阅读典型RTOS的来源很有帮助。有几个开源示例，下面通过一些快速搜索产生了链接：
商业RTOS已有详细记录，以源代码形式提供，易于使用µC/OS-II。它具有非常宽松的教育许可许可，并且（稍微过时的版本）其源可以被绑定到一本书中，该书描述了使用实际实现作为示例代码的操作理论。这本书由Jean Labrosse撰写 MicroC OS II: The Real Time Kernel 。
多年来，我在多个项目中使用了μC/ OS-II，并且可以推荐它。
答案 5 :(得分：0)
重要的是实时应用程序，而不是实时操作系统。通常，实时应用程序是可预测的：已经执行了许多测试，检查，WCET分析，校样......，表明在任何特定情况下都可以满足最后期限。
实际上，RTOS帮助完成这项工作（构建应用程序并验证其RT约束）。但我已经看到在标准Linux上运行的实时应用程序，更多地依赖于硬件功能而不是OS设计。
答案 6 :(得分：0)
我没有使用RTOS，但我认为这就是它们的工作原理。
“硬实时”和“软实时”之间存在差异。你可以在像Windows这样的非RTOS上编写实时应用程序，但它们实时“软”：
作为一个应用程序，我可能有一个线程或计时器，我要求O / S每秒运行10次......也许O / S会这样做，大部分时间，但是有不能保证它总是能够...这种缺乏保证就是为什么它被称为“软”。 O / S可能无法做到的原因是不同的线程可能会使系统忙于执行其他操作。作为一个应用程序，我可以将我的线程优先级提升到例如HIGH_PRIORITY_CLASS，但即使我这样做，O / S仍然没有API，我可以使用它来请求保证我将在某些时间运行。
“硬”实时O / S确实（我想）有API可以让我请求保证执行切片。 RTOS可以做出这样的保证的原因是它愿意异常终止比预期更多的时间/而不是允许的时间。
答案 7 :(得分：0)
......好吧......
实时操作系统试图确定性并满足最后期限，但这一切都取决于您编写应用程序的方式。如果您不知道如何编写“正确的”代码，则可以使RTOS非实时。
即使您知道如何编写正确的代码： 它更多的是试图确定性而不是快速。
当我们谈论决定论时，它是
1）事件决定论
对于每组输入，系统的下一个状态和输出是已知的
2）时间决定论
...还知道每组输出的响应时间
这意味着如果你有像中断这样的异步事件，你的系统严格来说不再是时间确定性的。 （并且大多数系统使用中断）
如果你真的想成为确定性的民意调查。
......但也许没有必要100％确定性
答案 8 :(得分：0)
教科书/面试答案是“确定性的先发制人”。如果更高优先级的进程准备好运行（在就绪队列中）或中断被断言（通常在CPU / MCU外部输入），则系统保证在有限的时间段内传输控制。
答案 9 :(得分：0)
他们实际上并不保证会议期限;他们做了什么使他们真正的RTOS是提供识别和处理截止日期超支的方法。 “硬”RT系统通常是那些错过最后期限是灾难性的并且需要某种关闭的系统，而“软”RT系统则是继续降级功能的系统。无论哪种方式，RTOS都允许您定义对此类溢出的响应。非RT OS甚至不会检测到溢出。
答案 10 :(得分：0)
“基本上，你必须在RTOS中对每个”任务“进行编码，以便它们在有限的时间内终止。”
这实际上是正确的。 RTOS将具有由体系结构定义的系统标记，例如10毫秒，所有任务（线程）的设计和测量都在特定时间内完成。例如，在处理音频采样率为48kHz的实时音频数据时，对于正在处理数据的任何下游任务，预缓冲器将变为空的已知时间量（以毫秒为单位）。因此，使用RTOS需要正确调整缓冲区大小，估计和测量这需要多长时间，并测量系统中所有软件层之间的延迟。然后可以满足最后期限。否则申请将错过最后期限。这需要分析整个堆栈中的最坏情况数据处理，并且一旦知道最坏情况，系统可以设计为例如95％处理时间，空闲时间为5％（此处理可能不会发生在任何实际用法，因为在任何单个时刻，最坏情况数据处理可能不是所有层中的允许状态。）
实时操作系统网络应用程序设计的示例时序图在EE Times的这篇文章中， 产品如何：在基于VoIP的电话设计中提高实时语音质量 http://www.eetimes.com/design/embedded/4007619/PRODUCT-HOW-TO-Improving-real-time-voice-quality-in-a-VoIP-based-telephony-design
答案 11 :(得分：-1)
基本上，您必须对RTOS中的每个“任务”进行编码，以便它们在有限的时间内终止。
此外，您的内核会为每项任务分配特定的时间，以保证某些事情在某些时间发生。
请注意，这不是一件容易的事。想象虚拟函数调用之类的东西，在OO中很难确定这些东西。此外，RTOS必须在优先级方面进行仔细编码，可能需要在x毫秒内为CPU提供高优先级任务，这可能很难做到，这取决于调度程序的工作方式。