今回は、「どのようにTime Sharing of CPUを行うか」という点について考えていこうと思う。
「どのようにTime Sharing of CPUを行うか」を理解するということは、「Context Switchがどう行われるか」を理解することである。
Context Switchの話に移る前にいくつか前提となるOSのコンセプトに関して話す。
user modeとkernel mode
OSはユーザに使われていることを前提として設計されるが、ユーザに全てのOS上の権限を譲渡してしまうと、意図的かそうでないかに関わらず、システムに悪影響を与えるような処理（例：不正メモリアクセス）を許してしまうことになる。そこで、user modeとkernel modeという、OS稼働中のモードを２つ用意した。user modeでは、CPUは限られた命令しか実行できず、システム全体に影響を与えるような命令は実行できない。対して、kernel modeでは、すべての命令を実行できる。ユーザプログラムがシステムに影響を与えるような処理（例：ファイル管理、メモリ管理など）を実行したい際は、システムコールが使われる。これは、我々が携帯電話のサイレントモードや機内モードなどの複数モードを切り替えながら使っていることと似ている。user mode <–> kernel modeの切り替えは、ハードウェアレベルでサポートされており、それはCPUのMode Bitと呼ばれる２進数で管理されている。つまり、Mode Bitが０のとき、kernel modeであり、１のときはuser modeでOSは稼働する。
システムコール
システムコールとは、user mode で実行中のプロセスが、OSによって提供されているサービスを使うインターフェースである。それらのサービスには、以下のようなものがあり、対応するシステムコールはOSによって異なる。
ユーザプロセスからシステムコールを呼び出すと、user modeからkernel modeへと移行するために、trap 命令が実行される。（x86ではINTがtrap命令に当たる。）それはinterruptとしてシステムに捉えられ、システムブート時に初期化されたinterrupt vector（trap table)と呼ばれる、それぞれのinterruptとそれに対応するハンドラのメモリアドレスが格納されたテーブルが参照され、ハンドラが実行される。このとき、user modeからkernel modeへと移行するが、プロセスを再開できるよう、そのプロセスの情報（レジスタ、プログラムカウンタなど）はシステムのスタックに格納される。ハンドラの実行が終わると、return-from-trap命令が実行され、kernel modeからuser modeへと権限が落ちる。
Limited Direct Execution Protocol (LDE Protocol)
これまで議論した、「user mode & kernel modeを用意し、システムコールというインターフェースをユーザプログラムに提供し、必要に応じて２つのモードが切り替わる」という一連の流れは、Limited Direct Execution Protocolとして定義されている。（下図）
余談であるが、user modeからkernel modeへと移行するのは、ユーザプロセスがシステムコールを実行したときに限らない。例えば、あるプロセスがシステムコールを含まないforループを無限に回していたとすると、いつまでもそのプロセスがuser modeで実行されCPUを独占してしまう。そこで、タイマーハードウェアが決められた時間が経過するとinterruptを発生させ、user modeからkernel modeへと強制的に移行させる仕組みがある。
LDEプロトコルからContext Switchへ
さて、Context Switchの前提となるコンセプトの議論をしたところで、本題に入ろう。
Timer Interruptやシステムコールによってkernel modeに移った際、OSは２つの選択ができる。
- 元のプロセスへと戻る
- 異なるプロセスを実行する –> Context Switch
２の選択をした際に、違うプロセスへとCPUの時間が割かれることになる。他のプロセスへと実行が移った後も、同じ原理でkernel modeに移った後に、OSは上記の１，２の選択をすることになる。このようにして、CPUは複数プロセスを高速で実行する。
