对此有点困惑。如果我加快处理器速度,是否会减少执行任务所需的时间,从而加快截止日期?
谢谢
答案是,由于速度较快,可能会出现新的资源冲突。这被称为格雷厄姆异常:如果在多处理器上调度任务集以使调度长度最小化,那么增加处理器、减少执行时间或削弱优先约束可以增加调度长度。注意目标(最小化计划长度)。但是,如果任务有截止日期并且目标是满足所有任务截止日期,则可以很容易地证明异常是真实的。这在许多有关操作系统的书籍中都有详细的示例说明。
也可以看看:
这种事情发生了,道格拉斯已经解释了格雷厄姆的异常。我将尝试用一个小例子来解释它。我希望这可以更容易理解发生了什么:
如果您正在处理多个并发任务和固定速度的共享资源(例如通信通道),则会出现异常。
在实时系统的上下文中,一个很好的例子是数据采集。如果您必须从模数转换器读取 x 毫秒的数据,则无论 CPU 速度如何,它总是需要 x 毫秒。在我的示例中,我将此称为“IO-time”或“io-task”。
现在考虑以下场景:
您有一项任务 (A),其中包括:
第二个任务 (B) 将由硬件事件启动,包括:
第二个任务在毫秒 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 速度的提高导致两个任务延迟一毫秒完成。这是因为发生硬件事件时,固定速度共享资源很忙。
这只是一毫秒,但这些事情可能会加起来并可能导致错过最后期限。
取决于...加速处理器不会影响系统的其他部分(内存访问时间、传播延迟等)。提高处理器速度会使这些事情占用任务的大部分处理时间。
如果提高处理器速度,传播可能会跨越一个时钟周期,可能会由于重试而导致延迟,具体取决于您的系统设置方式。
如果最后期限与基于处理器的计数器或计时器相关联,它也会按比例增加,因为计数器没有主内存访问。
根据您的特定设置,其中任何一个都可能是因素之一。
也许——但许多用于加速处理器的技术(例如,缓存)也使它们更难预测。这些技术中的大多数以牺牲最坏情况为代价来改善平均情况(通常很多)——例如,使用缓存,在最坏的情况下,从内存中获取可能比没有缓存要慢,因为除了时间之外要从内存中获取,需要一些时间来搜索缓存以查看数据是否存在。
不幸的是,对于实时调度,您关心的主要是最坏情况,而不是平均情况,因此即使这样的优化在大多数情况下使大多数代码更快,它仍然可能导致实时错过最后期限系统。