コンテキストスイッチ

コンピューティングにおいて、コンテキストスイッチとは、プロセスまたはスレッドの状態を保存し、後で復元して実行を再開し、以前に保存した別の状態を復元するプロセスです。 ^[1]これにより、複数のプロセスが単一の中央処理装置(CPU) を共有できるようになり、マルチプログラミングまたはマルチタスクオペレーティングシステムの重要な機能です 。 従来の CPU では、各プロセス (実行中のプログラム) は、さまざまな CPU レジスタを使用してデータを保存し、実行中のプロセスの現在の状態を保持します。 ただし、マルチタスクオペレーティングシステムでは、オペレーティングシステムがプロセスまたはスレッドを切り替えて、複数のプロセスを同時に実行できるようにします。^[2]すべてのスイッチについて、オペレーティングシステムは現在実行中のプロセスの状態を保存し、次に CPU 上で実行される次のプロセスの状態をロードする必要があります。 実行中のプロセスの状態を保存し、次の実行中のプロセスをロードするこの一連の操作は、コンテキストスイッチと呼ばれます。

「コンテキスト スイッチ」という語句の正確な意味はさまざまです。マルチタスクのコンテキストでは、1 つのタスクのシステム状態を保存して、そのタスクを一時停止し、別のタスクを再開するプロセスを指します。コンテキスト スイッチは、タスクがディスク ストレージにアクセスして他のタスクの CPU 時間を解放する必要がある場合など、割り込みの結果として発生することもあります。一部のオペレーティング システムでは、ユーザー モードとカーネル モードのタスク間を移動するためにコンテキスト スイッチも必要です。コンテキスト スイッチのプロセスは、システム パフォーマンスに悪影響を及ぼす可能性があります。^{[3] : 28}

コンテキスト スイッチは通常、計算負荷が高く、オペレーティング システムの設計の多くはコンテキスト スイッチの使用を最適化することにあります。プロセス間の切り替えには、レジスタやメモリ マップの保存と読み込み、さまざまなテーブルやリストの更新などの管理作業に一定の時間がかかります。コンテキスト スイッチに実際に関係するものは、アーキテクチャ、オペレーティング システム、共有されるリソースの数によって異なります (同じプロセスに属するスレッドは、関連のない非協力的なプロセスに比べて多くのリソースを共有します)。

たとえば、Linuxカーネルでは、コンテキストスイッチでは、カーネルスタックのPCBテーブルに格納されている対応するプロセス制御ブロック（PCB）をロードして、新しいプロセスの状態に関する情報を取得します。レジスタ、スタックポインタ、プログラムカウンタなどのCPU状態情報、およびセグメンテーションテーブルやページテーブルなどのメモリ管理情報（古いプロセスが新しいプロセスとメモリを共有していない場合）は、新しいプロセスのPCBからロードされます。前のプロセスと現在のプロセスが異なるメモリを使用している場合に誤ったアドレス変換を回避するには、変換ルックアサイドバッファ（TLB）をフラッシュする必要があります。これは、ほとんどのコンテキストスイッチ後にTLBが空になるため、TLBへのすべてのメモリ参照がミスになるため、パフォーマンスに悪影響を及ぼします。^{[4] [5]}

さらに、類似のコンテキスト切り替えがユーザー スレッド(特にグリーン スレッド)間で行われ、多くの場合非常に軽量で、最小限のコンテキストを保存および復元します。Goのgoroutine 間の切り替えなどの極端なケースでは、コンテキスト切り替えはコルーチンのyield と同等であり、サブルーチン呼び出しよりもわずかにコストがかかるだけです。

コンテキストスイッチのトリガーとして考えられるものは 3 つあります。

最も一般的なのは、あるスケジューリングスキーム内で、別のプロセスを実行できるように、あるプロセスを CPU から切り替える必要があることです。このコンテキスト スイッチは、I/Oまたは同期操作の完了を待機するなど、プロセス自体が実行不可能になることでトリガーされます。プリエンプティブ マルチタスクシステムでは、スケジューラは実行可能なプロセスを切り替えることもできます。他のプロセスが CPU 時間を奪われるのを防ぐために、プリエンプティブ スケジューラは多くの場合、プロセスがタイム スライスを超えたときにタイマー割り込みが発生するように構成します。この割り込みにより、スケジューラはコンテキスト スイッチを実行するための制御を取得できます。

現代のアーキテクチャは割り込み駆動です。つまり、たとえば CPU がディスクからデータを要求した場合、読み取りが完了するまでビジー ウェイトする必要はなく、要求を (I/O デバイスに) 発行して、他のタスクを続行できます。読み取りが終了すると、CPU は(この場合はハードウェアによって、PICに割り込み要求を送信して)割り込まれ、読み取りが提供されます。割り込みの場合、割り込み ハンドラと呼ばれるプログラムがインストールされ、ディスクからの割り込みを処理するのは割り込み ハンドラです。

割り込みが発生すると、ハードウェアはコンテキストの一部を自動的に切り替えます (少なくとも、ハンドラが割り込みを受けたコードに戻ることができる程度に)。 特定のハードウェアおよびソフトウェア設計の詳細に応じて、ハンドラは追加のコンテキストを保存する場合があります。 多くの場合、割り込みの処理にかかる時間を最小限に抑えるために、コンテキストの最小限の部分のみが変更されます。 カーネルは割り込みを処理するために特別なプロセスを生成したりスケジュールしたりしませんが、代わりに、ハンドラは割り込み処理の開始時に確立された (多くの場合、部分的な) コンテキストで実行されます。 割り込み処理が完了すると、割り込みが発生する前に有効だったコンテキストが復元され、割り込みを受けたプロセスは適切な状態で実行を再開できます。

システムがユーザー モードとカーネル モード間を遷移する場合、コンテキスト スイッチは必要ありません。モード遷移自体はコンテキスト スイッチではありません。ただし、オペレーティング システムによっては、この時点でコンテキスト スイッチが発生することもあります。

現在実行中のプロセスの状態は、実行を再スケジュールするときに復元できるように保存する必要があります。

プロセス状態には、プロセスが使用している可能性のあるすべてのレジスタ（特にプログラム カウンタ）と、必要となる可能性のあるその他のオペレーティング システム固有のデータが含まれます。これは通常、プロセス制御ブロック(PCB) またはスイッチフレームと呼ばれるデータ構造に格納されます。

PCB は、カーネル メモリ内のプロセスごとのスタック(ユーザー モードの呼び出しスタックとは対照的) に格納されるか、この情報用にオペレーティング システムで定義された特定のデータ構造が存在する場合があります。PCBへのハンドルは、実行準備が整ったプロセスのキュー (準備完了キューと呼ばれることが多い) に追加されます。

オペレーティング システムは、事実上 1 つのプロセスの実行を一時停止しているため、準備完了キューからプロセスを選択し、その PCB を復元することでコンテキストを切り替えることができます。その際、PCB からプログラム カウンターがロードされ、選択されたプロセスで実行を続行できます。プロセスとスレッドの優先度は、準備完了キューからどのプロセスが選択されるかについて影響を与える可能性があります (つまり、優先度キューである可能性があります)。

詳細はアーキテクチャとオペレーティング システムによって異なりますが、これらは一般的なシナリオです。

一般的な算術加算演算 A = B+1 を考えてみましょう。命令は命令レジスタに格納され、プログラム カウンターが増分されます。A と B はメモリから読み取られ、それぞれレジスタ R1、R2 に格納されます。この場合、B+1 が計算され、最終結果が R1 に書き込まれます。この演算では、連続した読み取りと書き込みが行われ、関数呼び出しの待機は行われないため、この場合はコンテキスト スイッチ/待機は発生しません。

プロセス A が実行中で、タイマー割り込みが発生したとします。プロセス A のユーザー レジスタ (プログラム カウンタ、スタック ポインタ、ステータス レジスタ) は、CPU によって A のカーネル スタックに暗黙的に保存されます。次に、ハードウェアはカーネル モードに切り替わり、オペレーティング システムが引き継ぐ割り込み ハンドラにジャンプします。次に、オペレーティング システムはルーチンを呼び出して、switch()まず A の汎用ユーザー レジスタを A のカーネル スタックに保存し、次に A の現在のカーネル レジスタ値を A の PCB に保存し、プロセス B の PCB からカーネル レジスタを復元し、コンテキストを切り替えます。つまり、カーネル スタック ポインタをプロセス B のカーネル スタックを指すように変更します。その後、オペレーティング システムは割り込みから戻ります。次に、ハードウェアは B のカーネル スタックからユーザー レジスタをロードし、ユーザー モードに切り替えて、B のプログラム カウンタからプロセス B の実行を開始します。^[6]

コンテキストスイッチ自体は、タスクスケジューラの実行、TLBフラッシュ、および間接的に複数のタスク間でCPUキャッシュを共有することによるパフォーマンスの低下を伴います。^{[7]単一プロセスのスレッド間の切り替えは、スレッドが同じ}仮想メモリマップを共有するため、2つの別々のプロセス間の切り替えよりも高速になり、TLBフラッシュは不要です。^[8]

2 つの別個のプロセス間の切り替えにかかる時間は、プロセス切り替え待ち時間と呼ばれます。同じプロセスの 2 つのスレッド間の切り替えにかかる時間は、スレッド切り替え待ち時間と呼ばれます。ハードウェア割り込みが生成されてから割り込みが処理されるまでの時間は、割り込み待ち時間と呼ばれます。

単一アドレス空間のオペレーティングシステムで2つのプロセスを切り替えると、プロセスごとにプライベートなアドレス空間を持つオペレーティングシステムで2つのプロセスを切り替えるよりも高速になる場合があります。^[9]

コンテキスト スイッチは、主にソフトウェアまたはハードウェアによって実行できます。Intel 80386やその後継機などの一部のプロセッサ^{[10]では、}タスク状態セグメント(TSS)と呼ばれる特別なデータ セグメントを使用することで、コンテキスト スイッチをハードウェアでサポートしています。タスク スイッチは、グローバル記述子テーブル内の TSS 記述子をターゲットとした CALL または JMP 命令で明示的にトリガーできます。割り込み記述子テーブル(IDT)にタスクゲートがある場合は、割り込みまたは例外がトリガーされたときに暗黙的に発生することがあります。タスク スイッチが発生すると、CPU は TSS から新しい状態を自動的にロードできます。

ハードウェアで実行される他のタスクと同様に、これはかなり高速であると予想されますが、WindowsやLinuxを含む主流のオペレーティングシステム[ 11 ]では^この機能は使用されていません。これは主に2つの理由によるものです。

• ハードウェア コンテキスト スイッチングでは、すべてのレジスタが保存されるわけではありません (汎用レジスタのみが保存され、浮動小数点レジスタは保存されません。ただし、制御レジスタTSのビットは自動的にオンになり、浮動小数点命令の実行時にエラーが発生し、OS が必要に応じて浮動小数点状態を保存および復元できるようになります)。CR0
• 関連するパフォーマンスの問題。たとえば、ソフトウェア コンテキスト スイッチングは選択的であり、保存が必要なレジスタのみを保存しますが、ハードウェア コンテキスト スイッチングでは、必要かどうかに関係なくほぼすべてのレジスタを保存します。

• レイテンシー（エンジニアリング）

• OSDev.org でのコンテキスト スイッチング
• Linux Information Project (LINFO) によるコンテキスト スイッチの定義
• Microsoft Developer Network (MSDN) のコンテキスト スイッチ
• 一般的なアーキテクチャと設計 - FreeBSD.org での割り込み処理
• OS コンテキスト スイッチング - Computerphile