是什么让内核/操作系统实时？

Question

我正在阅读this文章，但我的问题是一般性的，我的思路如下：

1. 内核是否可以实时调用，因为它有实时调度程序？或者换句话说，假设我有一个Linux内核，如果我将默认调度程序从O(1)或CFS更改为real time scheduler，它是否会成为RTOS？
2. 是否需要硬件支持？通常我看到嵌入式设备有RTOS（例如VxWorks，QNX），这些有没有特殊规定/ hw来支持它们？我知道RTOS进程的运行时间是确定的，但是可以使用longjump / setjump在确定的时间内获得输出。

我真的很感激它的一些输入/见解，如果我对某事有误，请纠正我。

Answer 1

在做了一些研究之后，与人们交谈（Jamie Hanrahan，Juha Aaltonen @linkedIn Group - 设备驱动专家）以及@Jim Garrison的输入，我可以得出结论：

Jamie Hanrahan 的话 -

什么使内核实时？
实时操作系统的必要条件 -

• 能够保证外部中断与中断处理程序启动之间的最大延迟。

  请注意，最大延迟不需要特别短（例如微秒），您可以拥有一个实时操作系统，保证绝对最大延迟为137毫秒。

• 实时调度程序是一种提供完全可预测（对开发人员）线程调度行为 - “下一个运行的线程”。

  这通常与保证响应中断的最大延迟问题分开（因为中断处理程序不一定像普通线程一样进行调度），但通常需要实现实时应用程序。实时操作系统中的调度程序通常实现大量优先级。并且它们几乎总是实现优先级继承，以避免优先级反转情况。

因此，保证中断的延迟和线程调度的可预测性是好的，那么为什么不让每个操作系统都实时？

• 因为适合一般用途（服务器和/或桌面）的操作系统需要具有通常与实时延迟保证不一致的特性。

  例如，实时调度程序应具有完全可预测的行为。这意味着，除了其他事项之外，开发人员为各种任务分配的优先级应由操作系统单独留下。 这可能意味着一些低优先级的任务最终会长时间处于饥饿状态。但RT操作系统不得不耸耸肩说“这就是开发人员想要的”。请注意，为了获得正确的行为，RT系统开发人员必须非常担心很多关于任务优先级和CPU亲和力等问题。

  通用操作系统正好相反。您希望能够在其上抛出应用程序和服务，几乎总是由许多不同供应商编写的东西（而不是像大多数R-T系统那样紧密集成的系统），并获得良好的性能。也许不是绝对最好的表现，但好。

  请注意，“良好性能”不仅仅是在中断延迟中测量的。特别是，您希望CPU和其他资源分配通常被描述为“公平”，没有用户或管理员，甚至应用程序开发人员不必担心线程优先级和CPU关联性和NUMA节点等问题。一项工作可能比另一项工作更重要，但在通用操作系统中，这并不意味着第二项工作根本就没有资源。

  因此通用操作系统通常会在相同优先级的线程之间实现时间分片，并且可以根据过去的行为调整线程的优先级（例如，CPU hog可能优先级降低; I / O绑定线程可能会增加其优先级，因此它可以使I / O设备保持工作; CPU缺乏的线程可能会提升其优先级，因此它可以偶尔获得一点CPU时间）。

内核是否可以实时调用，因为它有实时调度程序？

• 不，RT调度程序是RT OS的必要组件，但您还需要在OS的其他部分中进行可预测的行为。

是否需要硬件支持？

• 通常，硬件越简单，其行为就越可预测。因此，PCI-E比PCI更难以预测，并且PCI比ISA等更不可预测。有一些特定的I / O总线被设计用于（除此之外）容易预测的例如。中断延迟，但现在可以通过商用硬件满足很多R-T要求。

Answer 2

实时的具体描述是流程具有最短的响应时间保证。这通常不足以应用，甚至不如确定性重要。使用现代功能丰富的操作系统尤其难以实现这一点。考虑：

如果我想在精确的时间点命令某些硬件或机器，我需要能够在那些特定时刻生成命令信号，通常具有很低的亚毫秒精度。通常，如果你编译，让我们说一个C代码运行一个等待半毫秒的循环＆＃34;并做了一些事情，等待时间不是半毫秒，它是一点点，因为普通操作系统处理这个问题的方式是，他们至少在正确的时间过去之前将过程放在一边，之后调度程序可能（在某些时候）再次接收它。

严重问题不在于时间t不是恰好半秒，而是事先不能知道它多少多少。这种不准确性不是恒定的，也不是确定的。

这在进行物理自动化时会产生令人惊讶的后果。例如，在没有通过内核接口使用专用硬件并告诉他们您真正想要的时间长度的情况下，无法使用任何典型的OS准确地命令步进电机。因此，单个AVR模块可以准确地命令多个电机，但是Raspberry Pi（在时钟速度方面绝对踩踏AVR）在任何典型操作系统中都不能管理超过2个。