コンテキスト・スイッチ

共有リソースとしてのCPU時間

現代のオペレーティング・システムは、何十、何百ものアクティブなスレッドを操っている。.
CPUコアは数個しか存在しないので、ほとんどのスレッドはキューで待機し、その間に少数のサブセットが実行される。.

A コンテキストスイッチ を使うと、スケジューラは実行中のスレッドを一時停止し、別のスレッドを再開することができる。.
この迅速な切り替えは、並列性の錯覚を生み、またクラッシュダンプの中で後で見るものを形作る。.

スレッドの実行コンテキストの内部

各スレッドはコードとデータ以上のものを運ぶ。.
また、カーネルが正しく保存・復元しなければならない完全な実行コンテキストも持っている。.

その文脈には以下が含まれる：

• 汎用CPUレジスタとフラグ

• 命令ポインタとスタックポインタ

• セグメント・レジスタおよびコントロール・レジスタ（関連する場合

• カーネルスタックとユーザースタック、およびいくつかのスケジューラメタデータ

カーネルがスレッドから離れるときは、この状態を記録しなければならない。.
スケジューラが同じスレッドに戻ると、すべてが復元され、何も中断していないかのように実行が続けられる。.

コンテキストスイッチ中にカーネルが取るステップ

低レベルでは、コンテキストスイッチは予測可能なシーケンスに従う。.
詳細はアーキテクチャによって変わるが、核となるアクションは似ている。.

1. 実行中のスレッドは、タイマー割り込みやブロッキング・システムコールなどのスケジューリング・ポイントに到達する。.

2. カーネルはCPUレジスタ、スタックポインタ、いくつかの制御情報をスレッドのカーネルスタックまたは制御ブロックに保存する。.

3. スケジューラは、優先度、公平性、プロセッサとの親和性に基づいて、次に実行可能なスレッドを選択する。.

4. カーネルは、レジスタやスタックポインタを含む、次のスレッド用に保存されたコンテキストをロードする。.

5. 制御は新しいスレッドのユーザーモードまたはカーネルモードに戻り、そのスレッドは前の命令ポインタで続行する。.

このシーケンスは、ビジー状態のシステムで1秒間に何百万回も起こる。.
これらのステップにバグがあると、データ破損やハング、ダンプファイルを生成するクラッシュを引き起こす可能性がある。.

コンテキスト・スイッチを引き起こすトリガー

コンテキストの切り替えはランダムに起こるわけではない。.
これらは、OSやハードウェアの内部で明確に定義された事象から発生する。.

よくある引き金：

• 実行中のスレッドは 入出力, ロック、待機オブジェクト

• ハードウェアタイマー割り込みは、スレッドがタイムスライスを使用したことを示す。

• 優先順位の高いスレッドが実行可能になる

• スケジューラは、コア間の作業バランスを調整するシグナルを受け取る。

クラッシュダンプは、致命的な状態が発生したとき、またはカーネルがこれらの遷移の1つの間に重大な不整合を検出したときに、たまたま実行されたスレッドをキャプチャします。.

クラッシュ・ダンプとスレッド状態

ウィンドウズがバグチェックに当たると、スケジューリングがフリーズし、メモリのスナップショットがディスクに書き込まれる。.
そのスナップショットには通常、いくつかのスレッドと、エラーを引き起こした、あるいは検出したコンテキストについての詳細が含まれている。.

クラッシュダンプは通常、記録される：

• 障害発生時に各CPUでアクティブだったスレッド

• クラッシュ直前に実行された関数を示すカーネルスタック

• レディ・キューと待機状態を記述する構造体

これらのスレッドと最後のコンテキスト切り替えイベントを調べることで、アナリストは、どのドライバー、システムコール、ユーザーアクションが障害に寄与したかを推測する。.

パフォーマンスと信頼性に関する考察

コンテキスト・スイッチングはマルチタスクを可能にするが、オーバーヘッドを伴う。.
カーネルは特権レベル間を移動し、CPUの状態をフラッシュまたはリロードし、キャッシュの内容を妨害しなければならない。.

コンテキストの切り替えが多すぎると、その可能性がある：

• スケジューラーに費やすCPU時間を増やす

• キャッシュとTLBの局所性を損なう

• I/O集約型アプリケーションのスループット削減

不安定 ドライバー クラッシュダンプには、waitとwakeの長いスタックとして現れることがある。.
深刻なケースでは、これらの遷移中のバグがメモリ破壊やデッドロックを引き起こす。.

ダンプを分析する際のコンテキスト情報の実用的な使い方