5

これについて少し混乱しています。プロセッサを高速化すると、タスクの実行にかかる時間が短縮され、期限が早くなるのではないでしょうか。

ありがとう

4

4 に答える 4

6

答えは、速度が速いために新しいリソースの競合が発生する可能性があるということです。これは、グラハムの異常として知られています。スケジュールの長さが最小になるようにタスクセットがマルチプロセッサでスケジュールされている場合、プロセッサを増やしたり、実行時間を短縮したり、優先順位の制約を弱めたりすると、スケジュールの長さが長くなる可能性があります。目的に注意してください（スケジュールの長さを最小化してください）。ただし、タスクに期限があり、目的がすべてのタスクの期限を満たすことである場合、異常は簡単に真実であることが示されます。これは、オペレーティングシステムに関する多くの本の例の図で十分に文書化されています。

参照：

  • アンダーソン、B .; ジョンソン、J .; 、「プリエンプティブマルチプロセッサスケジューリング異常」、Parallel and Distributed Processing Symposium。、Proceedings International、IPDPS 2002、Abstracts and CD-ROM、vol。、no。、pp.12-19、2002。doi：10.1109 / IPDPS.2002.1015483
  • Grahamm RL、「マルチプロセッシングのタイミング異常の限界」、SIAM Journal on Applied Mathematics、Vol。17、No。2（1969年3月）、pp.416-429。
于 2012-04-12T13:34:01.113 に答える
5

このようなことが起こり、ダグラスはすでにグラハムの異常について説明しました。少し例を挙げて説明しようと思います。これにより、何が起こっているのかを理解しやすくなることを願っています。

異常は、複数の同時タスクと、通信チャネルなどの固定速度の共有リソースを処理している場合に発生します。

リアルタイムシステムのコンテキストでのこの良い例は、データ取得です。アナログ-デジタルコンバータからxミリ秒のデータを読み取る必要がある場合、CPU速度に関係なく、常にxミリ秒かかります。私の例では、これを「IO-time」または「io-task」と呼んでいます。

ここで、次のシナリオを検討してください。

次のタスクで構成されるタスク（A）が1つあります。

  • 4ミリ秒のCPU計算
  • 4ミリ秒のIO時間（データの保存）

2番目のタスク（B）は、ハードウェアイベントによって開始されます。

  • 4ミリ秒のIO時間（データのロード）
  • 2ミリ秒のCPU時間

2番目のタスクはミリ秒3で開始されます。

IOとCPUは共有リソースです。これらは並行して実行できますが、IOまたはCPUは一度に1つのジョブしか処理できません。

このための1つの可能なスケジュールは次のようになります。

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パワーを2倍にして、CPUが2倍の速度で実行されるようにします。

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速度が遅いシナリオと比較して、2つのタスクが1ミリ秒後に終了しました。これは、ハードウェアイベントが発生している間、固定速度の共有リソースがビジーであったためです。

これはわずか1ミリ秒ですが、これらが合計され、期限を逃す可能性があります。

于 2012-04-14T03:23:01.817 に答える
2

依存...プロセッサの速度を上げても、システムの他の部分（メモリアクセス時間、伝播遅延など）には影響しません。プロセッサの速度を上げると、これらのものがタスクの処理時間の大部分を占めるようになります。

プロセッサの速度を上げると、伝播がクロックサイクルを超える可能性があり、システムの設定方法によっては、再試行による遅延が発生する可能性があります。

期限がプロセッサに基づいてカウンタまたはタイマーに関連付けられている場合、カウンタのメインメモリアクセスがないため、それに比例して期限も長くなります。

特定の設定によっては、これらのいずれかが要因の1つになる可能性があります。

于 2012-04-11T15:37:36.703 に答える
1

たぶん-しかし、プロセッサを高速化するために使用される多くの技術（たとえば、キャッシング）も、それらを予測しにくくします。これらの手法のほとんどは、最悪の場合を犠牲にして平均的なケース（多くの場合かなり多く）を改善します-たとえば、キャッシュがある場合、最悪の場合、メモリからのフェッチは、時間に加えて、キャッシュがない場合よりも遅くなる可能性がありますメモリからフェッチするには、データが存在するかどうかを確認するためにキャッシュを検索するのに時間がかかります。

残念ながら、リアルタイムスケジューリングの場合、懸念は主に最悪の場合であり、平均的な場合ではありません。そのため、このような最適化によってほとんどのコードが高速化されても、リアルタイムで期限を逃す可能性があります。システム。

于 2012-04-11T15:32:21.443 に答える