通过任务调度程序，我的意思是工作线程池的任何实现，它根据他们设计的任何算法将工作分配给线程。（如英特尔 TBB）
我知道“实时”约束意味着工作在可预测的时间内完成（我不是在谈论速度）。所以我的猜测是，使用任务调度程序，据我所知，它不能保证某些任务将在给定时间之前执行，这使得应用程序无法在这些约束中使用。
还是我错过了什么？有没有办法两者兼得？也许通过强制假设可以处理的数据量？或者也许有可预测的任务调度程序？
我说的是“硬”实时约束，而不是软实时（如视频游戏）。
澄清：
众所周知，C++ 中的某些特性无法在这种上下文中使用：new、delete、throw、dynamic_cast。它们是不可预测的（您不知道可以在其中一项操作上花费多少时间，这取决于在执行之前甚至不知道的太多参数）。你不能真正在实时环境中使用它们。我要问的是，任务调度程序是否具有相同的不可预测性，会使它们在实时应用程序中无法使用？
术语实时是相当灵活的。“硬实时”往往意味着几十微秒的时间会在“正常工作”和“不能正常工作”之间产生差异。并非所有“实时”系统都需要这种实时性。
我曾经在移动电话的无线电基站上工作过。板上的一个设备有一个中断，每 2 毫秒触发一次。为了正确操作（不丢失呼叫），我们必须处理中断，即在 100 微秒内完成中断内部的工作并用新值写入硬件寄存器 - 如果我们错过了，就会出现掉线。如果 160 微秒后没有中断，系统将重新启动。那是“硬实时”，特别是当处理器仅以几十兆赫兹运行时。
如果您制作视频播放器，它需要几毫秒范围内的实时性。
“显示股票价格”可能在 100 毫秒范围内。
对于网络服务器来说，在 1-2 秒内响应而没有任何大问题可能是可以接受的。
此外，“比 X 更糟糕的最坏情况意味着失败”之间存在差异（例如上面的 100 微秒或掉线的情况 - 如果每隔几周发生一次以上，那就很糟糕了 - 甚至一年几次也确实如此这应该是固定的）。这称为“硬实时”。
但是其他系统，错过你的最后期限意味着“哦，好吧，我们必须重新做一遍”或“一帧视频闪烁了一下”，只要它不经常发生，它可能没问题。这称为“软实时”。
许多现代硬件将使“硬实时”（10 秒或 100 微秒范围）变得困难，因为图形处理器将简单地阻止处理器访问内存，或者如果处理器变热，则将stopclk引脚拉出 100 微秒...
大多数现代操作系统，例如 Linux 和 Windows，并不真正意味着“硬实时”。在这些操作系统的某些部分，有些代码确实禁用了超过 100 微秒的中断。
您几乎可以肯定地从具有现代硬件的主流现代操作系统中获得一些好的“软实时”（也就是说，错过最后期限并不是失败，只是一个小烦恼）。它可能需要修改操作系统或专用的实时操作系统（可能还有合适的特殊硬件）才能使系统实时运行。
但世界上只有少数几件事需要这种硬实时。通常硬实时要求是由硬件处理的——例如，我上面描述的下一代无线电基站有更聪明的硬件，所以你只需要在接下来的 2-几毫秒，你没有“疯狂地在几十微秒内完成它”。在现代移动电话中，GSM 或 UMTS 协议主要由专用 DSP（数字信号处理器）处理。
“硬实时”要求是如果无法满足特定期限（或一组期限），即使未能满足期限仅发生一次，系统也确实失败了。但是，不同的系统有不同的系统对截止日期的实际时间有不同的敏感度（正如 Jerry Coffin 提到的）。几乎可以肯定的是，可以找到商用通用操作系统完全足以处理硬实时系统的实时要求的情况。绝对可以肯定的是，在其他情况下，如果没有专门的系统，就无法满足此类硬实时要求。
我想说，如果你想从操作系统获得亚毫秒级的保证，那么桌面 Windows 或 Linux 不适合你。这实际上取决于操作系统和调度程序设计的整体理念，并且构建一个硬实时操作系统需要大量考虑锁定和一个线程阻止另一个线程运行等的可能性。
我认为没有一个答案适用于您的问题。是的，您当然可以在具有严格实时要求的系统中使用线程池。除非操作系统对此有特定的支持，否则您可能无法以亚毫秒为单位执行此操作。而且您可能需要有专门的线程和进程来处理最高优先级的实时行为，这不是线程池本身的一部分。
抱歉，如果这不是对您的回答说“是”或“否”，但我认为您需要对操作系统的实际行为进行一些研究，看看它可以提供什么样的保证（最坏的情况）。您还必须决定最坏的情况是什么，以及如果您错过最后期限会发生什么 - 是（很多）人死亡（飞机从天上掉下来），还是某个银行家将损失数百万，是绿色在马路交叉口的两个方向上的灯会同时亮起，还是扬声器发出一些不好的声音？
是的，它可以做到，但不，这不是微不足道的，是的，有限制。
您可以编写调度程序以保证（例如）中断处理程序、异常处理程序（等）被保证在没有固定时间段的情况下被调用。您可以保证任何给定的线程将（例如）在任何给定的秒（或合适的几分之一秒）内获得至少 X 毫秒的 CPU 时间。
要强制执行后者，您通常需要准入标准——调度程序能够说“对不起，但我不能将其安排为实时线程，因为 CPU 已经承受了太多的负载。
在其他情况下，它所做的只是保证至少（比如说）99% 的 CPU 时间将被分配给实时任务（如果有的话），并且这取决于在此基础上设计系统的人来安排足够少的实时任务。 - 时间任务，这将确保他们都足够快地完成。
我觉得有必要补充一点，实时要求的“硬度”几乎与所需的响应速度完全正交。相反，这几乎完全是关于迟到后果的严重性。
举个例子，考虑一个核电站。对于发生的很多事情，您正在处理以分钟为单位的时间段，在某些情况下甚至是几小时。例如，用 50 万加仑的水填充一个特定的腔室不会在几微秒或几毫秒内发生。
同时，稍后回答的后果可能是巨大的——很可能不仅像医院设备那样造成少数人死亡，而且可能导致数百甚至数千人死亡、数亿人的损失等。因此，它是与实时要求一样“硬”，即使按大多数典型标准而言，截止日期异常“宽松”。
另一方面，数字音频播放有更严格的限制。在某些情况下，延迟或丢失的声音可能会低至几分之一毫秒。同时，除非您为大型音乐会（或按此顺序）提供声音处理，否则退出的后果通常是用户的片刻小烦恼。
当然，也可以将两者结合起来——举个明显的例子，在高频交易中，截止日期可能在微秒（左右）的数量级，而错过截止日期的损失很容易达到数百万或数十万。数百万（美元|欧元|英镑|等）
“实时”不仅意味着“快速”，还意味着系统可以响应现实世界中的最后期限。这些截止日期取决于您在现实世界中处理的内容。
任务是否在特定时间范围内完成是任务的特征，而不是调度程序。调度程序可以决定哪个任务获得资源，如果一个任务在截止日期之前没有完成，它可能会被停止或限制其资源使用，以便其他任务可以满足它们的截止日期。
因此，您的问题的答案是您需要一起考虑工作量、截止日期和调度程序，并构建您的系统以满足您的要求。没有神奇的调度程序可以执行任意任务并让它们在可预测的时间内完成。
更新：
如果任务调度程序能够提供您需要的保证，那么它可以在实时系统中使用。正如其他人所说，有提供这些保证的任务调度程序。
关于评论：问题是所用时间的上限。
如果您重载它们以获得您所追求的性能特征，您可以使用 new 和 delete；问题不是新的和删除的，而是动态内存分配。不要求 new 和 delete 使用通用动态分配器，您可以使用它们从静态分配的池中分配，该池的大小适合您的工作负载并具有确定性的行为。
关于 dynamic_cast：我倾向于不使用它，但我不认为它的性能是不确定的，以至于它应该在实时代码中被禁止。这是同一问题的一个示例：了解最坏情况下的性能很重要。