为什么加速处理器会导致实时系统错过最后期限？答案

【问题标题】：why does speeding up the processor lead to missed deadlines in real time systems?为什么加速处理器会导致实时系统错过最后期限？
【发布时间】：2012-04-11 15:24:35
【问题描述】：

对此有点困惑。如果我加快处理器速度，执行任务会不会花费更少的时间，从而导致提前截止日期？

谢谢

【问题讨论】：

是什么让您认为这是真的？这是您经历过的问题，还是您被告知或阅读过的问题？需要引用。

标签： embedded real-time timing

【解决方案1】：

答案是，由于速度较快，可能会出现新的资源冲突。这被称为格雷厄姆异常：如果一个任务集在多处理器上调度，使得调度长度最小化，那么增加处理器、减少执行时间或削弱优先约束可以增加调度长度。注意目标（最小化计划长度）。但是，如果任务有截止日期并且目标是满足所有任务截止日期，则可以很容易地证明异常是真实的。这在许多有关操作系统的书籍中都有详细的示例说明。

另见：

安德森，B.；琼森，J。 , “抢占式多处理器调度异常”, 并行和分布式处理研讨会。, Proceedings International, IPDPS 2002, Abstracts and CD-ROM, vol., no., pp.12-19, 2002. doi: 10.1109/IPDPS.2002.1015483
Grahamm R. L.，“Bounds on Multiprocessing Timing Anomalies”，SIAM 应用数学杂志，卷。 17，第 2 期（1969 年 3 月），第 416-429 页。

【讨论】：

【解决方案2】：

这种事情发生了，道格拉斯已经解释了格雷厄姆的异常。我将尝试用一个小例子来解释它。我希望这能让我们更容易理解发生了什么：

如果您正在处理多个并发任务和固定速度的共享资源（例如通信通道），则会出现异常。

在实时系统环境中，数据采集就是一个很好的例子。如果您必须从模数转换器读取 x 毫秒的数据，则无论 CPU 速度如何，它总是需要 x 毫秒。在我的示例中，我将此称为“IO-time”或“io-task”。

现在考虑以下场景：

您有一项任务 (A)，其中包括：

4 毫秒 CPU 计算
4 毫秒 IO 时间（保存数据）

第二个任务 (B) 将由硬件事件启动，包括：

4 毫秒 IO 时间（加载数据）
2 毫秒 CPU 时间

第二个任务在毫秒 3 开始。

IO 和 CPU 是共享资源。它们可以并行运行，但 IO 或 CPU 一次只能处理一个作业。

一个可能的时间表如下所示：

timestamp:   cpu/io   job:
---------------------------------------------
t=0          event    <--- hardware event triggers task-a
t=0          cpu      start of task-a (4 ms)
t=3          event    <--- hardware event triggers task-b
t=3          io       start of task-b (4 ms)
t=4          cpu      task-a done
t=7          io       task-b done
t=7          io       start of task-a (4 ms)
t=7          cpu      start of task-b (2 ms)
t=9          cpu      task-b done
t=10         io       task-a done

现在我们将 cpu 功率加倍，这样 cpu 的运行速度就会提高一倍：

timestamp:   cpu/io   job:
---------------------------------------------
t=0          event    <--- hardware event triggers task-a
t=0          cpu      start of task-a (2 ms)
t=2          cpu      task a done
t=2          io       start of task a (4 ms)
t=3          event    <--- hardware event triggers task-b, but can't start
                           because io-bus is busy. Must wait.
t=6          io       task a done
t=6          io       start of task b (4 ms)
t=10         io       task b done
t=10         cpu      start of task b (1 ms)
t=11         cpu      task b done

如您所见，与较慢的 cpu 方案相比，CPU 速度的提高导致两个任务延迟了 1 毫秒。这是因为发生硬件事件时，固定速度共享资源正忙。

这只是一毫秒，但这些事情可能会加起来，并可能导致错过最后期限。

【讨论】：

【解决方案3】：

取决于...加速处理器不会影响系统的其他部分（内存访问时间、传播延迟等）。提高处理器速度会使这些事情占用任务的大部分处理时间。

如果提高处理器速度，传播可能会跨越一个时钟周期，可能会因重试而导致延迟，具体取决于您的系统设置方式。

如果最后期限与基于处理器的计数器或计时器相关联，它也会按比例增加，因为计数器没有主内存访问。

其中任何一个都可能是因素之一，具体取决于您的特定设置。

【讨论】：

【解决方案4】：

也许——但许多用于加速处理器的技术（例如缓存）也使它们的可预测性降低。这些技术中的大多数以牺牲最坏情况为代价来改善平均情况（通常很多）——例如，使用缓存，在最坏的情况下，从内存中获取可能比没有缓存要慢缓存，因为除了从内存中获取的时间之外，还有一些时间来搜索缓存以查看数据是否存在。

不幸的是，对于实时调度，您关心的主要是最坏情况，而不是一般情况，因此即使这样的优化在大多数情况下使大多数代码更快，它仍然可以导致错过实时系统的最后期限。

【讨论】：

另外，如果在 CPU 和系统其他部分之间共享任何资源，并且资源争用随着 CPU 速度增长而成为瓶颈（可能是资源不足），则可能会错过最后期限，因为的那个。