タスクの状態とスケジューリング方式

結論：状態は3つ、矢印は4本だけ

タスク（OSから見た仕事の単位。プロセスとほぼ同じ意味で出題されます）は、実行状態・実行可能状態・待ち状態の3つを行き来します。違いは「何を待っているか」です。実行可能状態はCPUの順番待ち、待ち状態は入出力（ディスクやネットワークの読み書き）の完了待ちです。

たとえるなら、銀行の窓口です。窓口で手続き中の人が実行状態、番号札を持って呼ばれるのを待つ人が実行可能状態です。「書類を取りに家へ帰った人」が待ち状態にあたります。家から戻っても、すぐ窓口には入れず、まず番号札の列（実行可能）に並び直します。

flowchart LR
  G["生成"] --> R["実行可能状態"]
  R -->|"CPUを割り当てる（ディスパッチ）"| E["実行状態"]
  E -->|"優先度の高いタスクに奪われる／持ち時間切れ"| R
  E -->|"入出力を要求した"| W["待ち状態"]
  W -->|"入出力が完了した"| R
  E --> F["終了"]

待ち → 実行の直接の矢印はありません。 入出力が終わったら、必ず実行可能状態に並び直します。新しく生成されたタスクも、最初は実行可能状態に入ります。

ディスパッチとプロセス切替えの手順

ディスパッチは、実行可能状態のタスクにCPUの使用権を割り当てる処理です。「次はどれにするか」を決めるのはスケジューリングです。決まったタスクに実際にCPUを渡すのがディスパッチで、この2つは別物として問われます。

プロセスを切り替えるとき、OSは退避 → 選択 → 回復の順で処理します。まず割込みで止まったプロセスAの実行状態（コンテキスト）を保存し、次に動かすプロセスを選び、そのプロセスBの状態を元に戻して再開させます。選ぶ前に回復はできない、と考えれば順番は迷いません。

スケジューリング方式を一言で見分ける

方式の問題は、選択肢に並んだ説明文から当てはまる方式を選ばせる形がほとんどです。下の表の「一言」を覚えれば、選択肢の言い換えに対応できます。

プリエンプティブな優先度方式は、重要度や緊急度に応じて処理したいときに使い、組込みのリアルタイムOSでよく使われます。たとえばタスクAがBより優先度が高いとします。Bの実行中にAが起動すると、OSはBを実行可能状態に戻してAを動かします。Bは入出力を待っているわけではないので、待ち状態にはなりません。

ラウンドロビンは、タイムクウォンタムがとても短いと、全タスクがCPUを均等に分け合うのと同じになります。計算問題はこの性質を使って解きます（例題参照）。

処理時間順（SPT）は長いタスクが待ち続ける

処理時間の短いタスクを優先し続けると、短いタスクが次々に来た場合に、長いタスクがいつまでもCPUをもらえない飢餓状態（スタベーション）が起きえます。選択肢にある他の方式と比べると違いが分かります。到着順やラウンドロビンはいつか必ず順番が来ます。待ち時間に応じて優先度を上げるエージング付きの優先度方式は、まさにこの飢餓を防ぐ工夫です。

ジョブスケジューリング：対話型を優先すると応答が速くなる

対話型処理（人が画面の前で結果を待つ処理）とバッチ処理（まとめて流す一括処理）が混在するシステムでは、対話型の優先度を高くすると応答性能が上がります。「FCFSなら応答時間を保証できる」「CPUを多く使うジョブを優先するとスループットが上がる」は誤りの選択肢です。

リアルタイムOSを使う理由は「時間内に終わらせる」

リアルタイムOS（RTOS）を組込みシステムで使う理由は、期待される応答時間内にタスクや割込みを処理する仕組みがあるからです。エンジン制御やハードディスク制御のように、締切りに遅れると故障や事故につながるシステムをハードリアルタイムシステムと呼びます。ここでは「定められた時間内にイベントへの処理を完了させる機構」が必須になります。

誤りの選択肢には、スループット（一定時間の処理量）の向上、メモリ保護によるウイルス対策、複数プログラムの並行実行、GUI、データ保全、セキュリティ保証などが並びます。どれも一般的なOSの利点で、RTOSを選ぶ理由ではありません。「時間」の言葉が入った選択肢が正解と覚えれば足ります。