问“实时”约束会阻止任务调度器的使用吗？

EN

实时这一术语相当灵活。“硬实时”往往意味着几十微秒就能区分“正常工作”和“不正常工作”，并不是所有的“实时”系统都需要这样的实时性。

我曾经在一个手机无线电基站工作过。电路板上的一个设备有一个中断，每2毫秒左右触发一次。为了正确操作(不丢失呼叫)，我们必须处理中断，即在100微秒内完成中断内部的工作，并使用新值写入硬件寄存器-如果我们错过了，就会有呼叫中断。如果在160微秒后没有中断，系统将重新启动。这是“硬实时”的，特别是当处理器只以几十MHz的速度运行时。

如果你制作一个视频播放器，它需要几毫秒范围内的实时。

“显示股票价格”可能在100ms的范围内。

对于For服务器来说，在1-2秒内响应可能是可以接受的，没有任何大的问题。

此外，“比X更糟糕的最坏情况意味着失败”(就像上面的100微秒或掉线的情况-如果每几周发生一次就很糟糕-甚至一年几次都是应该修复的)之间也有区别。这被称为“硬实时”。

但在其他系统中，错过截止日期意味着“哦，好吧，我们必须再做一次”或“一帧视频有点闪烁”，只要这种情况不经常发生，可能就没问题。这被称为“软实时”。

许多现代硬件将使“硬实时”( 10s或100微秒范围)变得困难，因为图形处理器会简单地停止处理器访问内存，或者如果处理器变热，stopclk引脚将被拉出100微秒……

大多数现代操作系统，如Linux和Windows，并不是真正意义上的“硬实时”。在这些操作系统的某些部分中，有些代码确实会禁用中断超过100微秒。

你几乎肯定可以从拥有现代硬件的主流现代操作系统中获得一些好的“软实时”(也就是，错过最后期限不是失败，只是一个小麻烦)。它可能需要修改操作系统或专用的实时操作系统(也许还需要合适的特殊硬件)才能使系统实现硬实时。

但世界上只有很少的东西需要这种硬实时。通常，硬实时需求由硬件处理-例如，我上面描述的下一代无线电基站，具有更智能的硬件，所以您只需要在接下来的2毫秒内给它新的值，而不需要“在几十微秒内疯狂地完成”。在现代移动电话中，GSM或UMTS协议主要由专用DSP (数字信号处理器)处理。

“硬实时”需求是指如果不能满足特定的截止日期(或一组截止日期)，即使只发生一次未能满足截止日期的情况，系统也会真正失败。然而，不同的系统有不同的系统对截止日期的实际时间有不同的敏感度(正如Jerry Coffin提到的那样)。几乎可以肯定地发现，商业上可用的通用OS在处理硬实时系统的实时要求方面完全足够。绝对可以肯定的是，在其他情况下，如果没有专门的系统，这种硬实时要求是不可能满足的。

我要说的是，如果你想从操作系统得到亚毫秒级的保证，那么桌面Windows或Linux不适合你。这实际上归结于操作系统和调度器设计的整体哲学，构建一个硬实时操作系统需要对锁定和一个线程阻止另一个线程运行等问题进行大量思考。

我不认为有一个答案适用于你的问题。是的，您当然可以在具有硬实时要求的系统中使用线程池。除非操作系统中有特定的支持，否则您可能无法在亚毫秒的基础上完成此操作。您可能需要有专门的线程和进程来处理最高优先级的实时行为，这不是线程池本身的一部分。

如果你的回答没有说“是”或“不是”，我很抱歉，但我认为你需要对操作系统的实际行为做一些研究，看看它能给出什么样的保证(最坏的情况)。你还必须决定最坏的情况是什么，如果你错过了最后期限会发生什么-是(许多)人死亡(飞机从天而降)，还是一些银行家将失去数百万人，是在十字路口的两个方向上同时亮起绿灯，还是从扬声器中传出一些糟糕的声音？

是的，这是可以做到的，但这不是微不足道的，而且是有限制的。

您可以编写调度器来保证(例如)中断处理程序、异常处理程序(等)从发生之日起，保证在没有固定时间段的情况下调用。您可以保证任何给定的线程(例如)在任何给定的秒(或适当的秒的一小部分)中至少获得X毫秒的CPU时间。

要执行后者，您通常需要准入标准--调度器能够说“对不起，我不能将其作为实时线程调度，因为CPU已经承受了太多的负载。

在其他情况下，它所做的就是保证至少(比如说) 99%的CPU时间将被分配给实时任务(如果存在的话)，这取决于在此基础上设计系统的任何人来调度足够少的实时任务，这将确保它们都能足够快地完成。

我觉得有必要补充一点，实时需求的“硬性”几乎与所需的响应速度完全正交。相反，这几乎完全是关于迟到后果的严重性。

例如，考虑一座核电站。对于发生的许多情况，您需要处理几分钟的时间段，在某些情况下甚至几个小时。比如说，用50万加仑的水填充一个特定的房间是不可能在几微秒或几毫秒内发生的。

同时，后一个答案的后果可能是巨大的--很可能不仅仅是像医院设备那样的几个人的死亡，而是可能导致数百甚至数千人的死亡，数亿的损失，等等。因此，它与实时要求一样“难”，即使按照大多数典型的标准，截止日期是异常“宽松”的。

另一方面，数字音频播放的限制要严格得多。在某些情况下，延迟或丢失的声音可以精确到几分之一毫秒。同时，除非您为大型音乐会(或类似的东西)提供声音处理，否则退出的结果通常只是用户的一小部分烦恼。

当然，将两者结合起来也是可能的--举个明显的例子，在高频交易中，截止日期可能只有几微秒(大约)，错过截止日期造成的损失可能很容易达到数百万或数千万美元(美元|欧元|英镑|等等)。

“实时”不仅仅意味着“快速”，它意味着系统可以在现实世界中响应以满足最后期限。这些截止日期取决于你在现实世界中要处理的事情。

任务是否在特定的时间范围内完成是任务的特征，而不是调度器的特征。调度器可以决定哪个任务获得资源，如果一个任务没有在截止日期之前完成，它可能会停止或限制其资源使用，以便其他任务可以满足其截止日期。

没有神奇的调度器可以接受任意的任务并在可预测的时间内完成它们。

更新：

如果任务调度器提供了您需要的保证，那么它就可以用于实时系统中。正如其他人所说，有任务调度程序提供了这些保证。

关于评论:这个问题是所需时间的上限。

不要求new和delete使用通用的动态分配器，您可以使用它们从具有确定性行为的静态分配池中分配出适合您的工作负载大小的池。

这是一个相同问题的例子:了解最坏情况下的性能很重要。