Kontextwechsel

CPU-Zeit als gemeinsam genutzte Ressource

Moderne Betriebssysteme jonglieren mit Dutzenden oder Hunderten von aktiven Threads.
Es gibt nur wenige CPU-Kerne, so dass die meisten Threads in Warteschlangen warten, während eine kleine Teilmenge läuft.

A Kontextwechsel ermöglicht es dem Scheduler, einen laufenden Thread anzuhalten und einen anderen wieder aufzunehmen.
Dieses schnelle Umschalten erzeugt die Illusion von Parallelität und prägt auch das, was Sie später in den Crash Dumps sehen.

Innerhalb des Ausführungskontexts eines Threads

Jeder Thread enthält mehr als nur Code und Daten.
Außerdem verfügt er über einen vollständigen Ausführungskontext, den der Kernel korrekt speichern und wiederherstellen muss.

Dieser Kontext umfasst:

• CPU-Register und Merker für allgemeine Zwecke

• Anweisungszeiger und Stapelzeiger

• Segmentregister und gegebenenfalls Steuerregister

• Kernel- und Benutzer-Stacks sowie einige Scheduler-Metadaten

Wenn der Kernel von einem Thread wegschaltet, muss er diesen Zustand aufzeichnen.
Wenn der Scheduler zu demselben Thread zurückkehrt, stellt er alles wieder her, so dass die Ausführung fortgesetzt wird, als ob nichts unterbrochen worden wäre.

Schritte, die der Kernel während eines Kontextwechsels durchführt

Auf einer niedrigen Ebene folgt ein Kontextwechsel einer vorhersehbaren Sequenz.
Die Details ändern sich in den verschiedenen Architekturen, aber die Kernaktionen bleiben ähnlich.

1. Der laufende Thread erreicht einen Zeitplanungspunkt, z. B. einen Timer-Interrupt oder einen blockierenden Systemaufruf.

2. Der Kernel speichert CPU-Register, Stack-Zeiger und einige Steuerinformationen im Kernel-Stack oder Steuerblock des Threads.

3. Der Scheduler wählt den nächsten lauffähigen Thread auf der Grundlage von Priorität, Fairness und Prozessoraffinität aus.

4. Der Kernel lädt den gespeicherten Kontext für diesen nächsten Thread, einschließlich der Register und Stapelzeiger.

5. Die Kontrolle kehrt in den Benutzer- oder Kernelmodus des neuen Threads zurück, der mit seinem vorherigen Befehlszeiger fortfährt.

Diese Sequenz läuft auf ausgelasteten Systemen millionenfach pro Sekunde ab.
Jeder Fehler in diesen Schritten kann zu Datenbeschädigung, Hängenbleiben oder einem Absturz führen, der eine Dump-Datei erzeugt.

Auslöser, die einen Kontextwechsel verursachen

Der Kontextwechsel erfolgt nicht zufällig.
Sie entstehen durch genau definierte Ereignisse innerhalb des Betriebssystems und der Hardware.

Häufige Auslöser:

• Der laufende Thread blockiert auf E/A, eine Sperre oder ein Warteobjekt

• Ein Hardware-Timer-Interrupt zeigt an, dass der Thread seine Zeitscheibe verbraucht hat

• Ein Thread mit höherer Priorität wird laufbereit

• Der Scheduler erhält ein Signal zur Neuverteilung der Arbeit auf die Kerne

Crash Dumps erfassen, welcher Thread gerade lief, als eine fatale Bedingung eintrat oder als der Kernel eine schwerwiegende Inkonsistenz während eines dieser Übergänge feststellte.

Absturzdumps und Thread-Zustände

Wenn Windows auf eine Fehlerprüfung stößt, friert es die Planung ein und schreibt einen Schnappschuss des Speichers auf die Festplatte.
Dieser Snapshot enthält in der Regel Details über mehrere Threads und die Kontexte, die den Fehler verursacht oder entdeckt haben.

Crash Dumps zeichnen normalerweise auf:

• Der aktive Thread auf jeder CPU zum Zeitpunkt des Ausfalls

• Kernel-Stacks, die zeigen, welche Funktionen kurz vor dem Absturz ausgeführt wurden

• Strukturen, die bereitstehende Warteschlangen und Wartezustände beschreiben

Durch die Untersuchung dieser Threads und ihrer letzten Kontextwechselereignisse können die Analysten ableiten, welcher Treiber, Systemaufruf oder welche Benutzeraktion zu dem Fehler beigetragen hat.

Leistungs- und Zuverlässigkeitsaspekte

Die Kontextumschaltung ermöglicht Multitasking, ist aber mit Overhead verbunden.
Der Kernel muss zwischen Berechtigungsstufen wechseln, einige CPU-Zustände flushen oder neu laden und Cache-Inhalte stören.

Zu viele Kontextwechsel sind möglich:

• Erhöhung der CPU-Zeit im Scheduler

• Verletzung der Cache- und TLB-Lokalität

• Reduzieren Sie den Durchsatz für E/A-intensive Anwendungen

Instabil Fahrer oder fehlverhaltende Benutzerprozesse können extreme Schaltmuster erzeugen, die manchmal in Absturzdumps als lange Stapel von Warte- und Aufwachoperationen erscheinen.
In schwerwiegenden Fällen führen Fehler bei diesen Übergängen zu Speicherfehlern oder Deadlocks.

Praktische Verwendung von Kontextinformationen bei der Analyse von Dumps