Embedded 为什么在实时系统中加速处理器会导致错过截止日期？

对此有点困惑。如果我加快处理器的速度，完成一项任务所需的时间是否会减少，从而缩短截止日期

谢谢你，也许吧，但许多用于加速处理器的技术（例如缓存）也会降低处理器的可预测性。这些技术中的大多数都以最坏的情况为代价改进了平均情况（通常是相当多的），例如，有了缓存，在最坏的情况下，从内存中获取的速度可能比没有缓存的慢，因为除了从内存中获取的时间外，还需要一些时间来搜索缓存以查看数据是否存在

---

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

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

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

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

---

根据您的特定设置，这两种情况都可能是其中之一。

答案是，由于速度加快，可能会出现新的资源冲突。这被称为格雷厄姆异常：如果在多处理器上调度任务集，使调度长度最小化，那么增加处理器、减少执行时间或减弱优先级约束都会增加调度长度。记下目标（最小化计划长度）。但是，如果任务有最后期限，并且目标是满足所有任务的最后期限，那么这种异常现象很容易被证明是正确的。这一点在许多关于操作系统的书籍中都有详细的说明，并附有示例插图

另见：

• 安德森，B。；Jonsson，J，“抢占式多处理器调度异常”，并行和分布式处理研讨会，国际会议记录，IPDPS 2002，摘要和CD-ROM，第卷，第12-19页，2002年。内政部：
• Grahamm R.L.，“，《暹罗应用数学杂志》，第17卷，第2期（1969年3月），第416-429页

  ---

  这类事情发生了，道格拉斯已经解释了格雷厄姆的反常现象。我将试着用一个小例子来解释它。我希望这能让你更容易理解发生了什么：
  如果处理多个并发任务和固定速度的共享资源（如通信通道），则会出现异常
  在实时系统中，数据采集就是一个很好的例子。如果您必须从模数转换器读取x毫秒的数据，则无论CPU速度如何，都将始终需要x毫秒。在我的示例中，我称之为“IO时间”或“IO任务”

  现在考虑下面的场景：

  您有一项任务（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/io作业：
  ---------------------------------------------
  t=0事件同样，如果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