就 RTOS 而言（在嵌入式系统上），当我们编写多线程应用程序时，我认为会发生同样的事情，具体取决于并发执行的线程数。

没有！

如果发生这种情况，那么它就不是实时操作系统 (RTOS)。

简短的回答是 RTOS 的定义与多任务或优先级无关。很简单，所有任务都有时间保证。

您认为 RTOS 的其他特征（优先级、任务完成等）仅仅是构建系统的结果（或功能），其中任务必须在指定的时间间隔内完成。

RTOS 中的多任务处理在概念上比软时间 OS 更简单，因为许多复杂的边缘情况基本上是不允许的。

RTOS 中的任务不是自动确定的，但可以对任务运行的时间和频率施加更严格的限制。RTOS 通常会为任务提供硬优先级；在任何时候，具有最高优先级的就绪任务正在运行。代码的作者还可以完全控制正在运行的任务集；您可以合理地预期没有高优先级的后台任务可能会中断您的代码，例如将数据交换到磁盘，除非您编写它们。

最重要的是，一些 RTOS 提供了协作多任务处理。与抢占式多任务相比，协作式多任务将继续执行任务，直到它自愿放弃对 CPU 的控制。

RTOS 通常不保证吞吐量，而是允许您保证延迟。

这通常通过优先系统来实现，例如在 FreeRTOS 中：

FreeRTOS 调度程序确保始终为处于就绪或运行状态的任务提供处理器 (CPU) 时间，优先于也处于就绪状态的较低优先级任务。换言之，处于运行状态的任务始终是能够运行的最高优先级任务。

假设您有一个优先级 1 的任务需要 10 毫秒来处理一个事件，一个优先级 2 的任务需要 100 毫秒来处理一个不同的事件，以及一个后台优先级 3 任务。如果您希望不超过每秒获得一个优先级 1 事件，您可以说处理优先级 2 事件的最坏情况是 10 毫秒 + 100 毫秒。优先级 3 的任务可能会被事件任意减慢，但您不在乎 - 因为它的优先级较低。

我宁愿这是一个评论，但它需要太多的字符。无论如何，ozgur，从您的评论回复中的问题来看，您似乎错过了一点，即您不能简单地说我的线程需要很长时间才能运行并期望它能够神奇地与其他线程一起工作，这一切都归功于操作系统。您必须设计线程并分析它们以获得最坏情况下的性能。如果最坏的情况不能满足您的要求，那么您需要重新设计您的线程。

因此，与其简单地说线程 1 需要 10 毫秒完成，线程 2 需要 20 毫秒，不如说线程 1 必须每 15 毫秒执行一次。线程 2 必须每 40 毫秒执行一次。线程 3 必须每 500 毫秒执行一次，线程 N 必须每 1500 毫秒执行一次。然后，您为每个线程在最坏情况下完成所需的时间分配时间。您将所有这些放在一起，确定可能出现的最坏情况，然后您必须确保每个线程都满足其时序要求。此分析也是您确定某些线程是否需要比其他线程更高的优先级才能满足其时序要求的地方。

例如，正在运行的线程 5 被线程 4 中断，线程 4 被线程 3 中断，线程 3 被线程 N 中断可能是一种最坏的情况。您将所有这些都放在一个时间线上，并验证即使在这种最坏的情况下，每个线程都满足其时序要求。您可以通过在实时操作系统中使用调度程序和优先级来确保线程确定性地完成这个最坏的情况。这种确定性造就了实时操作系统。

如果您使线程具有相同的优先级，那么您已经失去了一些（如果不是全部）确定性，因为调度程序可以自由选择它想接下来运行的任何线程。

在像 Windows 这样的操作系统中，您不仅无法指定每个线程何时运行，甚至无法保证您的应用程序将在任何时间点运行。操作系统可以随时暂停您的应用程序并运行一些后台服务。换句话说，没有决定论。因此，Windows 不是实时操作系统。虽然，如果您的时间要求很大，例如（thread1 每 10 秒运行一次，thread2 每 15 秒运行一次），那么您基本上可以将 Windows 视为实时操作系统，只要您考虑到 slop 并且大约每 10 或 15 秒（给予或花费几百毫秒和偶尔错过的窗口）就足够了。