CPUに余裕があれば締切を守れる？｜タスク・優先度・リアルタイム処理

CPUの使用率が低ければ、制御処理は間に合うのでしょうか。必要なのは平均的な余裕だけでなく、処理の発生から締切までに完了できることです。まず、同時に発生した仕事を時刻順に追います。

事例：三つの周期タスクを一つのCPUで動かす

制御Hは周期5ms・実行時間1ms、計測Mは周期10ms・実行時間2ms、記録Lは周期20ms・実行時間4msです。優先度はH、M、Lの順に高く、時刻0に三つとも実行可能になります。

各ジョブの締切は、発生時刻から各タスクの周期と同じ時間後です。単一CPUで、固定優先度のプリエンプティブ方式とします。切替時間・割込み・共有資源待ちは、この最初の追跡では無視します。

高優先度でも、実行可能でなければ動かない

1. 実行中

   CPUを使って処理している状態です。

2. 実行可能

   処理できる条件がそろい、CPUが割り当てられるのを待つ状態です。

3. 待ち

   通知や時間経過、資源の解放などを待ち、実行対象に選ばれない状態です。

固定優先度方式では、実行可能なタスクのうち最も高い優先度を選びます。高優先度のタスクが通知待ちなら、低いタスクを動かせます。優先度の高さと、常にCPUを使うことは別です。

同じ優先度のタスクの扱いは、タイムスライス等の設定で変わります。優先度の数値が大きい方を高く扱うか、小さい方を高く扱うかも仕様に従います。この事例は名前で順位を指定します。

時刻5msで、記録処理が中断される理由

0〜1msはH、1〜3msはM、3〜5msはLです。Lはまだ2ms分の処理を残しています。5msに次のHが実行可能になるので、Lを中断してHへ切り替えます。

Hは5〜6msに完了し、Lは6〜8msに残りを実行して完了します。Lが待った時間も含むため、最初のLの応答時間は8msです。CPUを使った合計時間4msとは異なります。

応答時間を、どこからどこまで測る？

応答時間Rは、ジョブが実行可能になった時刻から完了までです。締切Dが発生からの許容時間なら、R<=Dが必要です。Hの2回目は5ms発生・6ms完了なのでR=1ms、締切時刻は10msです。

締切より早く開始しても、完了が締切を過ぎれば要件を満たしません。入出力の待ち、割込み、切替の負荷まで含めるかは測定対象に従います。異なる対象の値を足し引きしないようにします。

平均応答時間が短くても、最悪条件の締切を守る証拠にはなりません。周期の重なりや到着の揺らぎ、処理量の上限を確認します。今回の最初の区間だけから、別の条件でも必ず間に合うとは断定しません。

CPU利用率60%から、何が判断できる？

締切を保証する検討では、実行時間を平均だけで決めず、最悪条件でも超えない上限を使います。入出力待ちや他のタスクによる妨げは別に扱います。事例の実行時間も、指定した条件での処理量として読みます。

この事例の利用率Uは、1/5+2/10+4/20=0.6、つまり60%です。周期的に要求される実行時間の比率を合計しています。切替等を含まないモデルの値です。

Mの実行時間が8msへ増えると、U=1/5+8/10+4/20=1.2、120%になります。一つのCPUで継続的に全ジョブを処理するには時間が不足します。処理量を減らすなどの設計変更が必要です。

U<=100%でも、それだけで各締切を守れるとはいえません。非プリエンプティブ区間や資源待ち、締切が周期より短い条件などで、個別の締切を超える場合があります。利用率と応答時間を別に確認します。

待ちや割込みが入ると、どこが変わる？

Hが使いたい資源をLが保持している間は、Hも待つ必要がある場合があります。低い優先度の仕事により高い仕事が待つ優先度逆転です。詳しい対策は並行処理の記事で扱います。

割込みを長時間禁止する区間や、非プリエンプティブな処理があると、優先度を高くしただけでは直ちに実行できません。最大の阻害時間を見積もり、最悪応答へ加える条件を確認します。

周期処理の開始を相対的な待ち時間で毎回決めると、処理時間の分だけ発生時刻がずれる場合があります。一定の周期を保つAPIや時刻基準を使い、処理が周期を超えた場合の扱いも決めます。

演習1：優先度の対象

条件：Hは高優先度ですが通知待ち、MとLは実行可能です。

問い：次に選ぶタスクはどれですか。

解答例：Mです。

根拠：実行可能なものの中で、Mが最も高い優先度だからです。

誤答の理由：Hの優先度だけを見て選ぶと、待ち状態では処理できない条件を無視します。

演習2：中断後の残り

条件：Lは3〜5msに2ms実行し、必要な実行時間は合計4msです。

問い：6msに再開したLは、妨げがなければ何msに終わりますか。

解答例：8msです。

根拠：残り2msを実行するので6+2=8msになります。

誤答の理由：4msを初めから加えて10msとすると、中断前に実行した分を二度数えます。

演習3：応答と実行時間

条件：Lは0ms発生、3ms開始、8ms完了、実行時間は4msです。

問い：応答時間はいくつですか。

解答例：8msです。

根拠：発生から完了までなので8-0=8msで、CPU待ちも含みます。

誤答の理由：開始からの5msやCPU時間4msは、指定された応答時間と測定区間が違います。

演習4：締切時刻

条件：Hの2回目は5msに発生し、相対締切は5ms、完了は6msです。

問い：締切時刻と、締切を満たすかを答えてください。

解答例：締切時刻は10msで、6msに完了するので満たします。

根拠：発生時刻へ相対締切を加えてから、完了時刻と比べます。

誤答の理由：締切を時刻5msと読むと、相対的な許容時間と絶対時刻を混同します。

演習5：実行時間の増加

条件：HとLは事例のままで、Mの実行時間が8msになりました。

問い：一つのCPUで継続的に処理できますか。

解答例：この条件では利用率が120%となり、継続的に全仕事を処理できません。

根拠：1/5+8/10+4/20=1.2で、要求がCPU時間を超えます。

誤答の理由：優先度の変更だけでは総実行時間を減らせず、すべての締切を解決できません。

演習6：低い平均使用率

条件：平均CPU使用率は40%ですが、割込み禁止が最大8ms続きます。Hの許容応答は5msです。

問い：平均使用率だけで安全と判断できますか。

解答例：できません。禁止区間でHが最大8ms待つなら、処理開始前に許容時間を超える場合があります。

根拠：平均の余裕と、仕事が発生した際の最大の阻害時間は別です。

誤答の理由：空き時間が60%あるという説明だけでは、締切直前の連続した待ちを説明できません。

出典と仕様を確認する

IPA：APシラバス Ver.7.2

FreeRTOS公式：タスク状態と固定優先度スケジューリング

FreeRTOS公式：共有資源と優先度逆転

関連テーマを続けて学ぶ

状態・イベント・割込み

排他制御と優先度逆転