“实时”约束是否阻止使用任务调度程序？

Question

通过任务调度程序，我的意思是工作线程池的任何实现，它根据设计的任何算法将工作分配给线程。 （如英特尔TBB）

我知道“实时”约束意味着工作在可预测的时间内完成（我不是在谈论速度）。所以我的猜测是使用一个任务调度程序，据我所知，它不能保证某个任务会在给定时间之前执行，这使得应用程序无法在这些约束中使用。

或者我错过了什么？有没有办法兼得？也许是通过强制假设可以处理的数据量？或者也许有可预测的任务调度程序？

我说的是“硬”实时约束，而不是软实时（如视频游戏）。

澄清：

据了解，有在C++的功能，是不可能在这种情况下的使用方法：新建，删除，抛出时，将dynamic_cast。它们是不可预测的（你不知道在这些操作之一上可以花费多少时间，这取决于执行前甚至不知道的太多参数）。 你不能真正在实时环境中使用它们。 我问的是，任务调度程序是否具有相同的不可预测性，以至于无法在实时应用程序中使用它们？

Answer 1

实时术语相当灵活。 “硬实时”倾向于意味着几十微秒会使“正确工作”和“不正常工作”之间的区别，而不是所有的“实时”系统都需要这种实时性。

我曾经在一个手机无线电基站工作过，主板上的一个设备有一个中断，每2毫秒触发一次，为了正确操作（不会失去呼叫），我们必须处理中断，即在中断内部完成工作，并在100微秒内将新值写入硬件寄存器 - 如果我们错过了，会有掉话，如果在160微秒后没有中断，系统会这就是“硬实时”，特别是当处理器运行在几十MHz时。如果您生产视频播放器，则需要在几毫秒的范围内实时播放。

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

对于网络服务器来说，在1-2秒内做出响应可能是没有问题的。

此外，“最差的情况比X更糟糕”意味着失败（例如上面的情况有100微秒或掉线的情况 - 如果每几周发生一次以上的情况就会很糟糕 - 甚至几次一年是真的应该固定的东西）。这被称为“硬实时”。

但是其他系统错过了最后期限意味着“哦，好吧，我们必须再做一遍”或者“一帧视频闪烁一下”，只要它不经常发生，它可能是好的。这被称为“软实时”。

许多现代硬件会使硬实时（10秒或100微秒范围）变得困难，因为图形处理器只会停止处理器访问内存，或者如果处理器变热，引脚stopclk拉100微秒...

大多数现代操作系统的，如Linux和Windows，都没有真正的意思是“硬实时”。有些代码段在这些操作系统的某些部分禁止中断时间超过100微秒。

你可以几乎肯定会得到一些不错的“软实时”（即，错过最后期限是不是失败，只是一个小麻烦）了主流的现代操作系统拥有现代化的硬件。它可能需要修改操作系统或专用实时操作系统（也许还有适当的特殊硬件），以使系统能够实时实时操作。

但只有在世界上的几件事情需要这一类的硬实时。硬实时要求通常由硬件来处理 - 例如，我上面描述的下一代无线基站具有更聪明的硬件，所以你只需要在下一个2年内给它新的值，几毫秒，而且你没有“疯狂地在几十微秒内完成它”。在现代移动电话中，GSM或UMTS协议主要由专用DSP（数字信号处理器）处理。

即使未达到最终期限的情况只发生一次，如果无法满足特定的期限（或一组期限），“实时实时”要求是系统真正失败。但是，不同的系统有不同的系统对截止日期的实际时间有不同的敏感度（正如Jerry Coffin所提到的那样）。几乎可以肯定的是，我们可以找到一些商业上可用的通用OS完全适合处理硬实时系统的实时需求的情况。还有一些绝对确定的情况是，如果没有专门的系统，这种硬实时要求不可能实现。

我想说的是，如果你从OS希望亚毫秒级的保证，那么桌面Windows或Linux不适合你。这实际上取决于操作系统和调度程序设计的整体理念，而构建硬实时操作系统需要考虑很多关于锁定和潜在的一个线程以阻止另一个线程，从运行等。

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

对不起，如果这不是说你的答案是“是”或“否”，但我认为你需要对操作系统的实际行为进行一些研究，看看它能给出什么样的保证最坏的情况下）。你还必须决定什么是最糟糕的情况，以及如果你错过了最后期限 - 会有很多人死亡（飞机从天上掉下来），或者一些银行家会损失数百万美元，会发生什么？灯会在路口两个方向同时出现，还是从扬声器中发出一些不好的声音？

Answer 2

是的，这是可以做到的，但没有它不是小事，而且是有极限。

可以编写调度以保证（例如），该中断处理程序，异常处理（等）保证在不脱离发生时的一段固定的时间被调用。您可以保证任何给定的线程将（例如）在任何给定的秒（或适当的几分之一秒）内获得至少X毫秒的CPU时间。

为了执行后者，您通常需要准入标准 - 调度程序说“抱歉”的能力，但我不能将此调度为实时线程，因为CPU已经负载过多。

在其他情况下，它所做的只是保证至少（比如说）99％的CPU时间将被赋予实时任务（如果有的话），并且取决于系统的设计，安排足够的实时任务，这将确保他们完成得足够快。

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

举个例子，考虑一个核电站。对于发生的很多事情，你正在处理的时间以分钟为单位，有些甚至是几小时。例如，用50万加仑的水填充一个特定的腔室就不会在几微秒或几毫秒内发生。

与此同时，后面的答案的后果可能是巨大的 - 很可能导致不只是几个人死亡像医院设备可以，但潜在的数百甚至数千人死亡，数亿美元的损害，等等。因此，尽管截止日期在大多数典型标准中非常“宽松”，但它与实时要求一样“很难”。

另一方面，数字音频播放有多更严格的限制。在某些情况下，延迟或退出可能会听起来很低，只有几分之一毫秒。同时，除非您为大型音乐会（或其他音乐会）提供声音处理，否则退出的后果通常会成为用户的一小部分烦恼。

当然，也有可能将两者结合起来 - 例如，在高频交易中，截止日期可能会在几微秒左右（因此）错过截止日期的损失可能很容易数百万或数千万（美元|欧元|磅|等等）

Answer 3

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

任务是否在特定时间范围内完成是该任务的一个特征，而不是调度程序。调度程序可以决定哪个任务获取资源，如果任务尚未完成截止日期，它可能会被停止或资源使用受到限制，以便其他任务可以满足截止日期。

因此，您的问题的答案是您需要将工作负载，截止日期和调度程序放在一起，并构建您的系统以满足您的要求。没有魔法调度程序可以执行任意任务并在可预测的时间内完成任务。

更新：

任务调度可以在实时系统中使用，如果它提供了你需要的保障。正如其他人所说，有任务调度程序提供这些保证。

关于意见：问题是时间的上限。

如果您将它们重载为具有您之后的性能特征，则可以使用new和delete;问题不是新的和删除，它是动态内存分配。没有要求new和delete使用通用动态分配器的情况，您可以使用它们从静态分配的池中分配，这些池的大小适合您的工作负载并具有确定性行为。

在dynamic_cast上：我倾向于不使用它，但我不认为它的性能是非确定性的，应该在实时代码中被禁止。这是一个同样问题的例子：理解最坏情况的表现很重要。