Prozesse und Systemaufrufe

Ein Browser, ein Compiler und ein Musikplayer können auf einem Computer alle Fortschritte machen. Jeder braucht CPU-Zeit, Speicher und Zugriff auf Geräte. Das Betriebssystem stellt diese Ressourcen über Dienste bereit, die Programme nutzen können, ohne den ganzen Rechner zu kontrollieren.

Stelle Programmen nützliche Ressourcen bereit

Virtualisierung macht aus einer physischen Ressource eine bequem nutzbare virtuelle Ressource. Durch CPU-Virtualisierung können sich viele Prozesse so verhalten, als hätte jeder einen eigenen Prozessor. Das Betriebssystem lässt jeden eine Zeit lang laufen und bewahrt seinen Zustand zwischen den Abschnitten. Die Speichervirtualisierung gibt jedem Prozess einen eigenen Adressraum: die Adressen, die seine Befehle nutzen können.

Eine Abstraktion verbirgt Details hinter einer nützlichen Schnittstelle. Eine Datei ist eine Abstraktion für gespeicherte Bytes. Ein Programm kann write aufrufen, ohne zu wissen, ob diese Bytes auf eine SSD oder ein Netzlaufwerk gehen. Ein Systemaufruf bietet eine kontrollierte Möglichkeit, einen Kerneldienst anzufordern. Die gerätespezifische Arbeit bleibt hinter der Schnittstelle.

Teile Ressourcen auf und schütze Programme

Als Ressourcenverwalter entscheidet das Betriebssystem, wer CPU-Zeit, Speicher und Gerätedienste erhält. Es versucht, die Hardware sinnvoll auszulasten und Programmen zugleich angemessenen Zugriff zu geben. Die gemeinsame Nutzung braucht auch Schutz: Ein Programm darf weder den privaten Speicher eines anderen überschreiben noch den Timer deaktivieren, um die CPU zu behalten.

Die Hardware hilft, diese Grenze durchzusetzen. Anwendungsbefehle laufen im Benutzermodus mit eingeschränkten Berechtigungen. Kernelcode läuft mit den Privilegien, die zur Verwaltung des Rechners nötig sind. Ein Timer kann ein Programm auch dann unterbrechen, wenn es nie etwas vom Betriebssystem anfordert.

Betrachte bei einem Laptop, der eine Datei herunterlädt und gleichzeitig Code kompiliert, drei getrennte Aufgaben:

1. Das Netzwerkgerät meldet eintreffende Daten. Der Kernel stellt sie dem herunterladenden Prozess zur Verfügung.
2. Das Betriebssystem teilt die CPU-Zeit zwischen Browser, Compiler und anderen bereiten Prozessen auf.
3. Der Compiler fordert Dateioperationen an, um seine Ausgabe zu speichern. Sein Code steuert den Speichercontroller nicht direkt an.

Trenne den Kernel von der Oberfläche

Der Kernel ist der privilegierte Kern. Shell, Desktop und die meisten Systembibliotheken laufen als gewöhnliche Programme, selbst wenn sie mit dem Betriebssystem ausgeliefert werden. Das Schließen eines Desktopfensters entfernt den Kernel nicht. Ein Server ohne grafische Oberfläche braucht weiterhin Prozessverwaltung, Speicherschutz und Gerätedienste.

Auf einer logischen CPU wechseln sich Benutzercode und Kernelcode ab. Während der Compiler gewöhnliche Benutzerbefehle ausführt, läuft der Kernel nicht gleichzeitig auf dieser CPU. Systemaufrufe, Ausnahmen und Hardwareinterrupts geben ihm die Kontrolle zurück.

Wähle erst das Wie, dann das Wer

Ein Mechanismus stellt eine Operation bereit; eine Strategie wählt, wie sie genutzt wird. Die Register eines Prozesses zu sichern und die eines anderen wiederherzustellen, ist ein Mechanismus. Zu wählen, welcher bereite Prozess den nächsten Abschnitt erhält, ist eine Strategie. Diese Trennung erlaubt es dem Betriebssystem, seine Schedulingentscheidungen zu ändern, ohne den Wechselmechanismus zu ersetzen.

Beim Betriebssystementwurf werden nützliche Abstraktionen, Leistung, Schutz, Zuverlässigkeit, Sicherheit und Energieverbrauch gegeneinander abgewogen. Die zusätzliche CPU-Zeit und der zusätzliche Speicher für die Verwaltung sind Verwaltungsaufwand. Drei wiederkehrende Themen des Fachgebiets sind Virtualisierung, Nebenläufigkeit (gleichzeitig laufende Aktivitäten) und Persistenz, durch die gespeicherte Daten das Ende eines Programms oder einen Stromausfall überdauern.

Betriebssysteme entwickelten sich weiter, als Computer von der Ausführung einzelner Aufträge dazu übergingen, viele Aktivitäten gleichzeitig zu bedienen. Jede Änderung löste ein praktisches Problem: untätige Hardware, langsame Interaktion oder Fehler, die sich zwischen Programmen ausbreiten.

Von Stapeln zu überlappender Arbeit

Bei der Stapelverarbeitung laufen eingereichte Aufträge ohne Interaktion mit der einreichenden Person nacheinander ab. Frühe Unterstützungssoftware half hauptsächlich beim Laden von Aufträgen und bei üblichen Ein-/Ausgabeoperationen. Musste der aktuelle Auftrag auf ein Gerät warten, konnte die CPU untätig bleiben.

Der Mehrprogrammbetrieb hält mehrere Aufträge im Speicher. Blockiert einer wegen Ein-/Ausgabe, kann ein anderer rechnen. Angenommen, ein Auftrag rechnet wiederholt 20 ms und wartet 80 ms auf die Festplatten-Ein-/Ausgabe. Allein beträgt seine CPU-Auslastung 20 / 100 = 20 %. Bei zwei solchen Aufträgen und geeigneter Überlappung können nützliche Berechnungen 40 % der verstrichenen Zeit ausfüllen. Die Verzögerung des Geräts ist nicht kürzer geworden; stattdessen wurde CPU-Zeit gefüllt, die sonst ungenutzt bliebe.

Der Gewinn hängt davon ab, dass Arbeit bereitsteht. Zusätzliche Aufträge können die CPU-Auslastung nicht über 100 % erhöhen, und bei Aufträgen, die auf dasselbe Gerät warten, kann weiterhin ein Engpass entstehen. Mehrere Aufträge im Speicher brauchen auch Schutz: Keiner darf einen anderen überschreiben oder die eigenen Daten des Betriebssystems beschädigen.

Sorge für schnelle Reaktionen

Das Zeitteilverfahren gibt Prozessen kurze Abschnitte auf der CPU. Ein Terminal oder Desktop kann reagieren, während andere Programme weiterarbeiten. Müsste man warten, bis ein Stapelauftrag endet, bevor der Tastendruck eines anderen Benutzers bedient wird, würde sich das ganz anders anfühlen.

Nebenläufigkeit bedeutet, dass mehrere Aktivitäten im selben Zeitraum ablaufen. Ihre Befehle können auf einer logischen CPU verzahnt werden. Parallelität bedeutet, dass Befehle tatsächlich gleichzeitig auf unterschiedlichen Verarbeitungsressourcen ausgeführt werden. Mehrprogrammbetrieb setzt keine parallele Hardware voraus.

Platziere Dienste innerhalb oder außerhalb des Kernels

Linux ist monolithisch und kann Kernelmodule laden. MINIX 3, QNX und seL4 veranschaulichen Mikrokernelentwürfe. Windows NT und Apples XNU werden üblicherweise als hybride Entwürfe beschrieben. Ein Treiber im Benutzermodus lässt sich nach einem Absturz oft neu starten, während ein privilegierter Treiber Zugriff hat, durch den sein Ausfall das ganze System betreffen kann.

Frühen Personal-Computer-Systemen wie MS-DOS und dem klassischen Mac OS fehlte der heute erwartete Speicherschutz für Prozesse. Moderne Systeme verbinden Betriebssystemregeln mit ihrer Durchsetzung durch Hardware. Kurze CPU-Abschnitte allein würden ein Programm nicht daran hindern, den Speicher eines anderen Programms zu verändern. Aufteilung und Schutz lösen unterschiedliche Teile des Problems.

Eine ausführbare Datei auf einem Datenträger kann wiederholt gestartet werden. Jeder Start braucht einen eigenen veränderlichen Zustand, damit eine Instanz unabhängig pausieren, fortgesetzt werden oder ausfallen kann. Diese aktive Instanz ist ein Prozess.

Erkenne die laufende Instanz

Ein Programm besteht aus gespeicherten Befehlen und statischen Daten. Ein Prozess verbindet ein Programm mit seinem aktuellen Speicher, seinen CPU-Registern und seinem Ein-/Ausgabezustand. Drei Shells können dieselbe ausführbare Datei ausführen und dabei unterschiedliche Variablen, aktuelle Verzeichnisse und Befehlsverläufe haben.

Der Befehlszähler (PC) bezeichnet den nächsten Befehl. Der Stapelzeiger gibt die Position des aktiven Stacks an. Allgemeine Register enthalten Zwischenwerte. Wenn ein Prozess nicht mehr läuft, muss genug Zustand erhalten bleiben, damit er beim richtigen Befehl mit den richtigen Werten weitermachen kann.

Lies die Darstellung des Adressraums

Der Adressraum eines Prozesses ist der Speicher, den seine Befehle adressieren können. Eine übliche Darstellung für Lehrzwecke platziert Code und statische Daten bei niedrigeren Adressen, darüber einen Heap und bei höheren Adressen einen Stack. Der Heap dient dynamisch reservierten Objekten; der Stack unterstützt Funktionsaufrufe und lokalen Zustand. In dieser Darstellung wächst der Heap zu höheren und der Stack zu niedrigeren Adressen hin. Der tatsächliche Aufbau hängt vom System ab, und Implementierungen von malloc können Speicher auf mehr als eine Weise erhalten.

Zwei Prozesse können für eine Variable dieselbe virtuelle Adresse ausgeben und dort trotzdem unterschiedliche Werte halten. Virtuelle Adressen gehören zur Speichersicht eines Prozesses. Übereinstimmende Adresszahlen bedeuten keinen gemeinsam genutzten beschreibbaren Speicher.

Starte ein Programm

Um ein neues Programmabbild zu starten, richtet das Betriebssystem diese Teile ein:

1. Den ausführbaren Code und die Daten, wobei auf modernen Systemen Teile bei Bedarf geladen werden.
2. Einen anfänglichen Benutzerstack und Startinformationen, darunter die Argumentzeichenketten und den Argumentvektor, mit denen die Laufzeitumgebung main aufruft.
3. Speicher für dynamische Zuweisungen und den anfänglichen Registerzustand.
4. Eine Ein-/Ausgabeumgebung einschließlich geerbter Dateideskriptoren.
5. Einen Einstiegspunkt, an dem der Programmstartcode beginnt.

Unter Unix sind Dateideskriptoren kleine ganze Zahlen, die offene Ein-/Ausgaberessourcen bezeichnen. Nach Shell-Konvention steht 0 für die Standardeingabe, 1 für die Standardausgabe und 2 für die Standardfehlerausgabe. Sie sind oft mit einem Terminal verbunden. Ein Prozess kann weitere Deskriptoren erben; die drei vertrauten Nummern sind weder eine Obergrenze noch eine Zusage, dass jeder Prozess sie immer geöffnet hat.

Untersuche den Datensatz des Kernels

Der Prozesskontrollblock (PCB) speichert Informationen, die der Kernel zur Verwaltung eines Prozesses braucht: PID, Zustand, gesicherten Ausführungskontext, Speicherinformationen, offene Deskriptoren, Elternprozess, Eigentümer, aktuelles Verzeichnis und Abrechnungsinformationen. Linux verwendet task_struct; xv6 verwendet struct proc. Eine Prozesstabelle oder Prozessliste organisiert diese Datensätze.

Während ein Prozess läuft, befinden sich seine aktuellen Register in der CPU. Beim Eintritt in den Kernel werden seine Benutzerregister auf seinem Kernelstack gesichert; ein Kontextwechsel sichert außerdem den Kernelausführungskontext. Der PCB ist kein fortlaufend aktualisiertes Spiegelbild jedes Benutzerregisters.

Eine Linux-Ausgabe von ps könnte zum Beispiel 8240 8200 S bash und 8291 8240 R ps enthalten. Der zweite Prozess hat die PID 8291 und die Eltern-PID 8240, ist also ein Kindprozess der Shell. R umfasst sowohl laufende als auch bereite Prozesse. Eine PID bezeichnet einen existierenden Prozess innerhalb seines PID-Namensraums, aber nach der Bereinigung kann diese Nummer erneut vergeben werden.

Ein Prozess kann existieren, ohne gerade einen Befehl auszuführen. Sein Zustand zeigt dem Betriebssystem, ob er eine CPU nutzen kann oder erst auf etwas anderes warten muss. Dieser Unterschied erklärt, warum ein ausgelasteter Computer viele Prozesse haben kann, aber nur wenige in einem Augenblick ausgeführt werden.

Bestimme, was der Prozess braucht

Ein blockierter Prozess verbraucht keine CPU-Zeit, solange er blockiert ist. Sein Gerät kann trotzdem weiterarbeiten oder das Ereignis eintreten. Ein bereiter Prozess hat bereits alles, was er braucht, außer einer CPU.

Die grundlegenden Übergänge sind bereit → laufend bei Auswahl, laufend → bereit, wenn der Prozess von der CPU genommen wird, laufend → blockiert, wenn er warten muss, und blockiert → bereit, wenn sein Ereignis eintritt. Der Abschluss eines Ereignisses macht einen Prozess ausführungsbereit; er gibt ihm nicht sofort die CPU. Zwischen ausführungsbereiten Prozessen auszuwählen, ist die Aufgabe des Schedulers.

Verfolge überlappende Arbeit

Nutze eine logische CPU und vernachlässige den Kontextwechselaufwand. Prozess A rechnet 2 ms, wartet 3 ms auf Festplatten-Ein-/Ausgabe und rechnet dann 1 ms. Prozess B braucht 4 ms CPU-Zeit. A beginnt zuerst.

Bei 2 ms startet A die Ein-/Ausgabe und blockiert. B rechnet, während die Festplatte arbeitet. Bei 5 ms endet die Ein-/Ausgabe von A, aber das Betriebssystem lässt B seine vierte CPU-Millisekunde beenden, bevor es A ausführt. Das ist eine Strategieentscheidung und kein zusätzlicher Zustandsübergang direkt von blockiert zu laufend.

Die gesamte CPU-Arbeit beträgt 2 + 1 + 4 = 7 ms, und beide sind nach 7 ms fertig. Liefe A bis zum Ende, bevor B beginnt, betrüge die verstrichene Zeit 2 + 3 + 1 + 4 = 10 ms. Die CPU-Auslastung läge bei 7 / 10 = 70 %, weil keine andere Arbeit die Ein-/Ausgabewartezeit ausfüllen würde.

Lies Zustände auf einem realen System

Linux ps fasst laufend und bereit als R zusammen. Es zeigt unterbrechbaren Schlaf als S, nicht unterbrechbaren Schlaf, oft wegen Ein-/Ausgabe, als D, einen angehaltenen Prozess als T und einen beendeten Prozess, dessen Status noch nicht abgerufen wurde, als Z. Ein angehaltener Prozess wartet nicht einfach auf den Abschluss einer gewöhnlichen Ein-/Ausgabe. Ein Zombieprozess hat seine Ausführung beendet und behält nur den Datensatz, der zum Melden seines Ergebnisses nötig ist.

Ein neuer Prozess durchläuft außerdem seine Erzeugung, bevor er bereit ist. Auf einem System mit vier logischen CPUs können höchstens vier Prozesse mit je einem Thread gleichzeitig ausgeführt werden. Bereitschaftswarteschlangen ordnen ausführungsbereite Arbeit; Listen blockierter Prozesse erfassen die Ereignisse, die Prozesse benötigen. Ein Kontextwechsel sichert den Ausführungszustand eines Prozesses und stellt den eines anderen wieder her, wenn das Betriebssystem wechselt, welcher Prozess läuft.

fork() erzeugt aus dem aufrufenden Elternprozess einen Kindprozess. Beide setzen ihre Ausführung unmittelbar nach dem Aufruf fort, sodass aus einem Quellcodepfad zwei Ausführungen werden. Der Rückgabewert zeigt jedem Prozess, welche Rolle er hat.

Verzweige anhand aller drei Ergebnisse

pid_t rc = fork();
if (rc < 0) {
    perror("fork");
    exit(1);
} else if (rc == 0) {
    printf("child %ld\n", (long) getpid());
} else {
    printf("parent of %ld\n", (long) rc);
}

Verwende <unistd.h> für fork und getpid, <stdio.h> für Ausgaben und <stdlib.h> für exit. Bei Erfolg erhält der Elternprozess die positive PID des Kindprozesses; der Kindprozess erhält 0. Bei einem Fehler erhält der Aufrufer -1, errno gibt den Fehler an, und es existiert kein Kindprozess.

Hat der Elternprozess die PID 5000 und der Kindprozess die PID 5001, gibt der Elternprozess „parent of 5001“ und der Kindprozess „child 5001“ aus. Es ist nicht garantiert, welcher Prozess zuerst läuft. getpid() gibt die eigene PID des Aufrufers zurück; getppid() gibt die PID seines Elternprozesses zurück. Der Kindprozess startet main nicht neu und wiederholt keine Befehle vor dem fork.

Verfolge privaten Speicher und gemeinsame Ein-/Ausgabe

Eltern- und Kindprozess beginnen mit übereinstimmenden gewöhnlichen Speicherinhalten in getrennten Adressräumen. Ist x vor dem Aufruf 10 und setzt der Kindprozess seine Kopie auf 20, bleibt die Kopie des Elternprozesses 10. Selbst die ausgegebene Adresse von x kann übereinstimmen: Diese gleichen virtuellen Adressen gehören zu unterschiedlichen Prozessadressräumen.

Copy-on-Write vermeidet das sofortige Kopieren jeder Speicherseite. Eltern- und Kindprozess nutzen zunächst schreibgeschützte physische Seiten gemeinsam. Schreibt einer auf eine private Seite, stellt der Kernel eine private Kopie bereit, bevor er den Schreibvorgang erlaubt. So bleibt das Verhalten getrennter Speicher erhalten, während der Aufwand für einen Kindprozess sinkt, der bald exec aufruft.

Dateideskriptoren verhalten sich anders. Ihre kopierten Einträge verweisen auf dieselbe zugrunde liegende offene Dateibeschreibung, die den aktuellen Dateioffset enthält. Aufeinanderfolgende Lesevorgänge über einen geerbten Deskriptor setzen diesen gemeinsamen Offset weiter. Die Deskriptortabelle wird kopiert, aber der zugrunde liegende Zustand der offenen Datei im Kernel kann gemeinsam genutzt bleiben.

Zähle nur fork-Aufrufe, die ein Prozess erreicht

Sind alle Aufrufe erfolgreich, gibt es nach fork(); fork(); vier Prozesse: Beide durch den ersten Aufruf entstandenen Prozesse führen den zweiten aus. Eine Schleife mit drei Durchläufen, die alle Prozesse erreichen, hinterlässt $2^3=8$ Prozesse, einschließlich des ursprünglichen. Ein fork in einem Zweig, den nur der Elternprozess ausführt, wird von weniger Prozessen erreicht. Wiederholtes Verdoppeln beschreibt dann nicht mehr das ganze Programm.

Gib gepufferten Text bewusst aus

printf kann Text in einem Puffer im Benutzerraum zurücklassen. fork kopiert diesen Puffer mit dem übrigen Speicher. Wird die Ausgabe auf einen vollständig gepufferten Datenstrom umgeleitet, kann Text, der vor dem fork ausgegeben wurde, beim normalen Beenden von beiden Prozessen ausgegeben werden.

Bei printf("start\n"); fork(); gibt das üblicherweise zeilengepufferte Terminal den Zeilenumbruch vor dem fork aus. Bei der Umleitung in eine Datei kann der Text im Puffer bleiben, sodass die Datei zwei Kopien erhält. fflush(stdout) vor fork() gibt den ausstehenden Text einmal aus. Die doppelte Ausgabe entsteht durch kopierte gepufferte Daten, nicht dadurch, dass das frühere printf zweimal ausgeführt wird.

Ein Prozess kann seine Identität behalten und zugleich das Programm wechseln, das er ausführt. Die exec-Familie nimmt diesen Austausch vor. In Verbindung mit fork kann ein Elternprozess seine Arbeit fortsetzen, während im Kindprozess ein anderes Programm gestartet wird.

Ersetze das Abbild und behalte den Prozess

Ein erfolgreiches exec ersetzt den alten Code, die statischen Daten, den Heap und den Stack. Der Kernel bereitet die Argumente und den Anfangszustand des neuen Programms vor und beginnt dann dessen Startcode. Die alte Aufrufstelle existiert nicht mehr, sodass ein erfolgreiches exec nie dorthin zurückkehrt.

PID, Elternbeziehung und aktuelles Verzeichnis bleiben erhalten. Offene Deskriptoren bleiben erhalten, ausgenommen die mit Close-on-Exec markierten. Für abgefangene Signale gilt wieder die Standardaktion; ignorierte Signale bleiben im Allgemeinen ignoriert. Die Berechtigungsdaten bleiben gewöhnlich gleich, aber die Set-User-ID- oder Set-Group-ID-Berechtigung einer ausführbaren Datei kann die effektiven Berechtigungsdaten ändern, wenn das System es erlaubt.

Erstelle einen gültigen Argumentvektor

Um wc -l notes.txt auszuführen, kann der Kindprozess Folgendes verwenden:

char *args[] = {"wc", "-l", "notes.txt", NULL};
execvp(args[0], args);
perror("execvp");
_exit(127);

Die Zeichenketten sind getrennte Argumente und keine zusammengefasste Befehlszeile. Üblicherweise bezeichnet args[0] das Programm. Das abschließende NULL ist ein Zeiger, der das Ende des Arrays markiert; es ist nicht die Zeichenkette „NULL“. Ohne einen gültigen Abschluss kann der Aufruf über das Array hinauslesen.

Die Zeilen nach execvp behandeln einen Fehler. Kann das Programm nicht gefunden werden, gibt exec -1 zurück und setzt errno, zum Beispiel auf ENOENT. _exit beendet dann den Kindprozess, ohne geerbte C-Ausgabepuffer auszugeben. Würde nach einem Fehler in die Shell-Schleife zurückgekehrt, entstünde versehentlich ein weiterer Shell-Ausführungspfad.

Lies den Variantennamen

Das v in execv bedeutet, dass Argumente als Vektor ankommen; l-Varianten erhalten eine Liste. Eine p-Variante sucht einen Programmnamen in PATH. Eine e-Variante übergibt eine ausdrücklich angegebene Umgebung. Der zugrunde liegende Linux-Systemaufruf ist execve; die Bibliothek stellt die bequem nutzbaren Varianten bereit.

execvp("wc", args) durchsucht PATH. execv("wc", args) behandelt „wc“ als relativen Pfadnamen im aktuellen Verzeichnis. Ein absoluter Pfadname wie /usr/bin/wc kann dort verwendet werden, wo diese ausführbare Datei installiert ist. Exec wertet keine Shell-Syntax aus: Eine Zeichenkette > in args ist nur ein Argument, sofern ein Programm sie nicht selbst interpretiert.

Nutze die Zeit vor dem Austausch

Im Beispiel mit Eltern-PID 6000 und Kind-PID 6001 führt der Kindprozess nun wc aus, behält aber die PID 6001. Sein Elternprozess kann auf diese PID warten. Vor exec kann der Kindprozess Deskriptoren umleiten, eine Pipe verbinden oder das Verzeichnis wechseln; das neue Programm erbt die vorbereitete Umgebung.

Diese Trennung ist zentral für die Unix-Shell. Das Windows-Verfahren CreateProcess verbindet Erzeugung und Programmladen und konfiguriert den neuen Prozess über Parameter. POSIX bietet für eine kombinierte Operation außerdem posix_spawn.

Ein Elternprozess muss erfahren, ob und wie ein Kindprozess beendet wurde. Prozessende und Ergebnisabruf sind getrennte Schritte: Der Kindprozess endet, anschließend ruft sein Elternprozess den verbleibenden Datensatz des Kernels ab.

Beende einen Prozess

Die Rückkehr aus main oder der Aufruf von exit(status) beendet die Ausführung normal. exit gibt C-Ausgabepuffer aus und führt registrierte Behandlungsroutinen für die Beendigung aus. _exit(status) beendet den Prozess ohne diese Bereinigung durch die Bibliothek, was nach einem fehlgeschlagenen exec in einem mit fork erzeugten Kindprozess nützlich ist. Üblicherweise bedeutet 0 Erfolg und ein Wert ungleich null einen Fehler.

Auch ein Signal kann einen Prozess beenden. SIGTERM fordert die Beendigung an und kann behandelt werden; SIGKILL kann weder abgefangen noch ignoriert werden. SIGSTOP hält die Ausführung an und kann ebenfalls weder abgefangen noch ignoriert werden; SIGCONT setzt einen angehaltenen Prozess fort. Ein Terminal sendet normalerweise SIGINT bei Strg-C und SIGTSTP bei Strg-Z an den Vordergrundauftrag. Ein Signal ist eine Softwarebenachrichtigung an einen Prozess, kein Hardwareinterrupt.

Warte auf ein Ergebnis

wait(&status) wartet auf einen Kindprozess und gibt dessen PID zurück. waitpid(pid, &status, 0) wählt eine bestimmte positive Kind-PID aus. Ein beendeter Kindprozess, dessen Status noch nicht abgerufen wurde, kann sofort abgerufen werden. Andernfalls hält ein gewöhnliches blockierendes Warten den Elternprozess an, bis ein passendes Ergebnis verfügbar ist.

Mit WNOHANG gibt waitpid 0 zurück, wenn passende Kindprozesse existieren, aber keiner ein Ergebnis bereit hat. Ein positives Ergebnis bezeichnet den Kindprozess, dessen Status abgerufen wurde. Ein Ergebnis von -1 ist ein Fehler: ECHILD bedeutet, dass kein passender Kindprozess mehr vorhanden ist; EINTR bedeutet, dass eine Signalbehandlungsroutine das Warten unterbrochen hat.

Dekodiere den Status vor der Verwendung

int status;
pid_t r;
do {
    r = waitpid(child, &status, 0);
} while (r == -1 && errno == EINTR);
if (r == -1) {
    perror("waitpid");
} else if (WIFEXITED(status)) {
    printf("exit %d\n", WEXITSTATUS(status));
} else if (WIFSIGNALED(status)) {
    printf("signal %d\n", WTERMSIG(status));
}

Dies verwendet <sys/wait.h>, <errno.h> und <stdio.h>. Der gespeicherte Status kodiert sowohl die Art der Beendigung als auch ein Ergebnis. WEXITSTATUS ist aussagekräftig, nachdem WIFEXITED wahr ist; WTERMSIG folgt auf WIFSIGNALED.

Nur die unteren acht Bits eines normalen Beendigungswerts sind verfügbar. exit(300) ergibt daher 44, während exit(-1) 255 ergibt. Unter Linux erzeugt exit(3) gewöhnlich den rohen Wartestatus 768; die Ausgabe dieser rohen ganzen Zahl dekodiert den Beendigungscode nicht.

Rufe den Status von Zombieprozessen ab und erkenne verwaiste Prozesse

Ein Zombieprozess ist beendet, behält aber seine PID und sein Ergebnis, bis ein Warteaufruf sie abruft. Er führt keinen Code aus, sodass das Senden von SIGKILL ihn nicht entfernen kann. Ein langlebiger Elternprozess muss den Status jedes Kindprozesses abrufen. Um alle Kindprozesse abzurufen, warte nach jeder positiven PID weiter, versuche es bei EINTR erneut und höre bei ECHILD auf; melde andere Fehler.

Ein verwaister Prozess hat seinen Elternprozess verloren und kann weiterlaufen. Linux gibt ihm einen geeigneten Subreaper oder den Init-Prozess des Namensraums als neuen Elternprozess, der sein Ergebnis später abrufen kann. Gewöhnliche Signalberechtigungen hängen von Benutzeridentitäten und Privilegien ab. Die Ausführung als root gewährt Berechtigungen, bedeutet aber keine Ausführung im Kernelmodus.

Eine Shell setzt Befehlstext in Prozesserzeugung, Deskriptoreinrichtung und Ergebnisabruf um. Sie ist ein gewöhnliches Benutzerprogramm und nutzt dieselben geschützten Betriebssystemdienste, die anderen Programmen zur Verfügung stehen.

Starte einen externen Befehl

Für wc -l notes.txt erstellt die Shell den Argumentvektor und startet den Befehl. Die zerlegten Wörter bilden einen mit einem Nullzeiger abgeschlossenen Argumentvektor args:

pid_t child = fork();
if (child == -1) {
    perror("fork");
} else if (child == 0) {
    execvp(args[0], args);
    perror("execvp");
    _exit(127);
} else {
    int status;
    pid_t result;
    do {
        result = waitpid(child, &status, 0);
    } while (result == -1 && errno == EINTR);
    if (result == -1) perror("waitpid");
    else if (WIFEXITED(status)) {
        printf("exit %d\n", WEXITSTATUS(status));
    } else if (WIFSIGNALED(status)) {
        printf("signal %d\n", WTERMSIG(status));
    }
}

Dies verwendet <unistd.h>, <sys/wait.h>, <errno.h> und <stdio.h>. Die umgebende Shell liest und zerlegt jeden Befehl, führt diesen Startpfad aus und zeigt dann ihre nächste Eingabeaufforderung an.

Nur der Kindprozess ersetzt sein Programm; die Shell kann einen Befehlsabsturz als Beendigungsergebnis abrufen. Eingebaute Befehle wie cd müssen den eigenen Zustand der Shell ändern: Eine Änderung des Verzeichnisses eines Kindprozesses ließe die Eltern-Shell in ihrem bisherigen Verzeichnis.

Leite vor exec einen Deskriptor um

Für ls -l > out.txt öffnet der Kindprozess das Ziel zum Schreiben und erzeugt oder leert es dabei. Dann lässt er die Standardausgabe auf diese Datei verweisen:

int fd = open("out.txt", O_WRONLY | O_CREAT | O_TRUNC, 0644);
if (fd == -1) { perror("open"); _exit(1); }
if (dup2(fd, STDOUT_FILENO) == -1) {
    perror("dup2"); _exit(1);
}
if (fd != STDOUT_FILENO && close(fd) == -1) {
    perror("close"); _exit(1);
}

open braucht <fcntl.h>; Deskriptoraufrufe und _exit verwenden <unistd.h>. Der Erstellungsmodus wird durch die Dateierstellungsmaske des Prozesses gefiltert. Die Prüfung fd != STDOUT_FILENO hält Deskriptor 1 offen, selbst wenn open selbst 1 zurückgegeben hat. Nach erfolgreicher Einrichtung behält exec Deskriptor 1 bei, und ls schreibt normal, ohne von der Umleitung zu wissen.

Ein älterer Ansatz schließt Deskriptor 1 vor dem Öffnen der Datei: open gibt den unbenutzten Deskriptor mit der niedrigsten Nummer zurück. dup2 gibt das Ziel ausdrücklich an. Die Eingabeumleitung verbindet entsprechend eine lesbare Datei mit Deskriptor 0.

Verbinde zwei Befehle

Für ls | wc -l erzeugt pipe(fds) ein Leseende fds[0] und ein Schreibende fds[1]. Der erzeugende Kindprozess verbindet das Schreibende mit Deskriptor 1. Der verbrauchende Kindprozess verbindet das Leseende mit Deskriptor 0. Nach dem Duplizieren schließt jeder die ursprünglichen Pipe-Deskriptoren, die er nicht benötigt. Der Elternprozess schließt seine Kopien und wartet auf beide Kindprozesse.

Erzeuge beide Kindprozesse, bevor du auf einen von ihnen wartest. Ein Erzeuger kann die Pipe füllen und blockieren; der Leser muss existieren, um sie zu leeren. Der Leser erreicht das Dateiende erst, wenn alle Schreibdeskriptoren geschlossen und gepufferte Pipe-Daten verbraucht sind. Ein vom Elternprozess offengehaltenes ungenutztes Schreibende kann wc unbegrenzt warten lassen.

Halte die Eingabeaufforderung verfügbar

Bei sleep 60 & startet die Shell den Kindprozess und zeigt die nächste Eingabeaufforderung, ohne sofort zu warten. Später nutzt sie nicht blockierende Warteaufrufe oder reagiert auf SIGCHLD, um den Status beendeter Kindprozesse abzurufen.

Der Beendigungsstatus steuert auch Befehlskombinationen. make && ./app startet den zweiten Befehl nur nach Erfolg; make || echo failed startet den zweiten nur nach einem Fehler. Diese Entscheidungen nutzen das dekodierte Ergebnis, nicht den rohen kodierten Wartestatus.

Der Kernel muss Programme schnell rechnen lassen und zugleich Operationen verhindern, die den Rechner übernehmen könnten. Der Privilegienmodus der CPU ist die Hardwaregrenze, die beides ermöglicht.

Trenne Berechnung von privilegierter Steuerung

Im Benutzermodus können Befehle auf erlaubten Prozessspeicher zugreifen und gewöhnliche Berechnungen ausführen. Sie können die Hardwarekonfiguration, die andere Programme schützt, nicht beliebig ändern. Im Kernelmodus, auch Supervisormodus oder privilegierter Modus genannt, kann das Betriebssystem die geschützten Operationen zur Verwaltung des Rechners ausführen.

Zu den privilegierten Operationen gehören das Programmieren des Timers, das Deaktivieren von Interrupts, das Einrichten von Interruptbehandlungsroutinen, das Ändern von Steuerregistern der Speicherübersetzung, die direkte Steuerung geschützter Geräte und das Anhalten der CPU. Könnte jede Anwendung den Timer deaktivieren, wären kurze CPU-Abschnitte von der Kooperation dieser Anwendung abhängig.

AArch64 bietet außerdem EL2 für Hypervisoren und EL3 für sichere Firmware. Diese Namen bezeichnen Privilegienstufen der Hardware, keine unterschiedlichen Arten von Benutzerkonten.

Tritt an einer kontrollierten Adresse ein

Benutzercode kann seine eigenen Privilegien nicht erhöhen und keine beliebige Kerneladresse zur Ausführung wählen. Der Eintritt erfolgt durch einen Systemaufruf, eine durch einen Befehl verursachte Ausnahme oder einen Hardwareinterrupt. Die CPU überträgt die Kontrolle an einen vom Betriebssystem konfigurierten Einstiegspunkt. Der Rückkehrcode des Kernels stellt den gesicherten Benutzerzustand wieder her und senkt die Privilegienstufe, um den Anwendungscode fortzusetzen.

Der Kernel schützt seine Daten auch durch Speicherberechtigungen. Ein Prozess kann Kerneladressen in seinem virtuellen Adressraum haben, ohne im Benutzermodus die Berechtigung zum Zugriff darauf zu besitzen. Die Kenntnis einer Adresse gewährt keinen Zugriff auf die Bytes dort.

Betrachte eine x86-64-Linux-Anwendung, die hlt ausführt, einen Befehl, der eine CPU bis zu einem Ereignis anhalten soll. Im Benutzermodus verursacht der Befehl eine Ausnahme. Linux sendet normalerweise SIGSEGV, dessen Standardaktion diesen Prozess beendet. Die Anwendung hält nicht den ganzen Computer an; die Schutzgrenze macht aus der versuchten privilegierten Operation ein Ereignis, das der Kernel behandelt.

Trenne Identität und Modus

Ein Root- oder Administratorprozess ist weiterhin ein Programm im Benutzermodus, während seine eigenen Befehle laufen. Seine Benutzeridentität gibt ihm umfassendere Berechtigungen, Dienste anzufordern. Er tritt weiterhin über kontrollierte Pfade in den Kernel ein, und der Kernel prüft die Anfrage.

Ein privilegiertes Wartungsprogramm darf zum Beispiel möglicherweise eine geschützte Datei öffnen. Das Programm fragt über einen Systemaufruf an; es wird nicht allein deshalb zu Kernelcode, weil die Anfrage erlaubt wird. Umgekehrt wird Kernelcode, der ein read eines gewöhnlichen Benutzers bedient, im Kernelmodus ausgeführt, obwohl der Aufrufer keine Administratoridentität hat.

Auf einer logischen CPU ist dies eine Abfolge: Benutzerbefehle, Kerneleintritt, Kernelarbeit, Rückkehr zu Benutzerbefehlen. Ein Programm und eine zweite Betriebssystemaufgabe werden nicht gleichzeitig auf derselben CPU ausgeführt. Getrennte logische CPUs können im selben Augenblick unterschiedliche Modi ausführen.

Ein C-Programm scheint häufig eine gewöhnliche Funktion aufzurufen, wenn es einen Betriebssystemdienst braucht. Unterhalb eines Systemaufruf-Wrappers ermöglicht ein kontrollierter CPU-Übergang dem Kernelcode, diese Anfrage zu prüfen und auszuführen.

Unterscheide einen Bibliotheksaufruf von einer Kernelanfrage

Die C-Bibliothek implementiert strlen ohne Systemaufruf im Benutzerraum. printf formatiert Daten und kann sie puffern; ein späteres write überträgt Bytes über den Kernel. Ein schlanker read-Wrapper ordnet Argumente nach der Systemaufrufkonvention der Plattform an und führt den Eintrittsbefehl aus.

POSIX beschreibt Schnittstellen für Unix-ähnliche Systeme. Linux implementiert viele Dienste, die grob in Prozesssteuerung, Datei- und Geräteoperationen, Information, Kommunikation und Schutz gegliedert werden. Eine Systemaufrufnummer wählt einen Dienst aus der Zuordnungstabelle des Kernels. Die Nummern sind plattformabhängig: Linux auf x86-64 verwendet 1 für write und 39 für getpid; AArch64 verwendet 64 für write.

Verfolge eine Schreibanfrage

Verfolge bei write(1, "hi\n", 3) unter Linux auf x86-64 die Anfrage der Reihe nach:

1. Der Wrapper legt die Dienstnummer 1 in rax, Deskriptor 1 in rdi, die Pufferadresse in rsi und die Anzahl 3 in rdx ab.
2. syscall sichert die Rücksprungadresse und die Flags in Registern, wechselt in den Kernelmodus und springt zum konfigurierten Einstiegspunkt. Dabei wird der Stack nicht automatisch gewechselt.
3. Der Kerneleinstiegscode richtet den Kernelstack des Prozesses ein und sichert den übrigen Benutzerzustand.
4. Die Zuordnung im Kernel wählt write; die Implementierung prüft den Deskriptor, den Zugriff auf den Benutzerpuffer und die Anfrage, bevor sie Bytes an die Ausgaberessource weiterleitet.
5. Bei einem vollständig erfolgreichen Schreibvorgang beträgt das Ergebnis 3 Bytes. Der Rückkehrcode des Kernels stellt den Benutzerzustand wieder her und setzt den Wrapper fort, der zum Aufrufer zurückkehrt.

Deskriptor 1 kann ein Terminal, eine Datei oder eine Pipe bezeichnen. Die Nummer allein bestimmt das Ausgabegerät nicht. Ein Schreibvorgang kann auch erfolgreich eine kleinere Byteanzahl zurückgeben; Aufrufer, die jedes Byte übertragen müssen, verfolgen die tatsächlich geschriebene Menge.

Prüfe Fehler an der Schnittstelle

Der Kernel behandelt Benutzerzeiger und andere Argumente als nicht vertrauenswürdig. Eine Anfrage, aus einem nicht zugänglichen Puffer zu kopieren, kann mit EFAULT fehlschlagen; kontrolliertes Kopieren verhindert, dass der Aufrufer Zugriff auf Kernelspeicher erhält.

Unter Linux ist ein Kernelfehler ein negativer Fehlercode. Der übliche C-Wrapper meldet -1 und setzt errno. Schlägt zum Beispiel open("missing.txt", O_RDONLY) fehl, weil die Datei nicht existiert, ist errno gleich ENOENT. perror("missing.txt") kann „missing.txt: No such file or directory“ anzeigen. Prüfe errno nach einem gemeldeten Fehler, nicht als primären Erfolgstest: Ein erfolgreicher Aufruf muss einen früheren Fehler nicht zurücksetzen.

Berücksichtige die Zeit im Kernel

Ein Aufruf, der sofort abgeschlossen werden kann, kehrt möglicherweise zum selben Prozess zurück. Ein blockierender Lesevorgang am Terminal kann diesen Prozess dagegen in den Zustand „blockiert“ versetzen und einen anderen laufen lassen. Das Eingabeereignis macht den Leser bereit; sobald er eingeplant wird, schließt er den Rückweg ab.

Der Kerneleintritt verursacht gegenüber einem normalen Funktionsaufruf zusätzliche Arbeit: Zustand sichern, Privilegien ändern, Argumente prüfen und die Ausführung wiederherstellen. Pufferung durch die Bibliothek kann kleine Ausgaben zu weniger Schreibvorgängen zusammenfassen. Unter Linux führt strace ls den Befehl ls aus und meldet dabei dessen Systemaufrufe, Argumente und Ergebnisse.

Ein Kerneleintritt kann eine Dienstanfrage, ein Befehlsproblem oder ein Geräteereignis bedeuten. Wenn du die Ursache einordnest, kannst du vorhersagen, was das Betriebssystem tun wird und ob derselbe Befehl erneut ausgeführt werden soll.

Frage nach der Ursache des Ereignisses

Synchron bedeutet, dass das Ereignis an den ausgeführten Befehl gebunden ist. Es bedeutet nicht, dass dieselbe Eingabe bei jedem Durchlauf genau dieselben Ausnahmen verursacht. Ein Ladebefehl kann eine Ausnahme auslösen, wenn seine Seite fehlt, und später erfolgreich sein, wenn diese Seite im Speicher liegt. Asynchron bedeutet, dass die Ursache des Ereignisses vom aktuellen Befehl unabhängig ist, etwa wenn eine Festplatte eine frühere Arbeit abschließt.

CPU-Handbücher verwenden diese Begriffe unterschiedlich. Achte auf die Ursache: absichtliche Dienstanfrage, durch einen Befehl verursachtes Ereignis oder Hardwarebenachrichtigung.

Leite an die richtige Behandlungsroutine weiter

Beim Systemstart richtet das Betriebssystem geschützte Adressen für Behandlungsroutinen ein. Eine Trap- oder Interrupttabelle ordnet Ereignisarten Kernelroutinen zu. Auf x86-64 dient die Interruptdeskriptortabelle (IDT) für Interrupts und Ausnahmen; syscall nutzt eine Einstiegsadresse in einem speziellen Prozessorregister. Nur privilegierter Code kann diese Ziele konfigurieren.

Bei einem Interrupt aus dem Benutzermodus sichert die x86-64-Hardware einen Rückkehrrahmen auf einem Kernelstack. Der Einstiegscode sichert zusätzliche Register, bevor er die Arbeit erledigt. Der syscall-Pfad sichert seinen anfänglichen Rückkehrzustand in Registern und ist darauf angewiesen, dass der Einstiegscode den Kernelstack einrichtet. Alle Eintrittspfade als gleiche Hardwareaktionen zu behandeln, verdeckt einen wichtigen Implementierungsunterschied.

Wähle die Folge

Eine gültige Seite, die nicht im Speicher liegt, kann geladen werden. Danach wird der Befehl, der die Ausnahme auslöste, erneut versucht. Ein Zugriff auf Speicher, den der Prozess nicht nutzen darf, führt unter Linux normalerweise dazu, dass SIGSEGV gesendet wird. Eine Ausnahme ist daher nicht immer fatal und auch nicht immer eine Aufforderung, den aktuellen Befehl zu überspringen.

Bei einem tatsächlichen x86-64-Ganzzahlbefehl idiv mit Divisor null löst die CPU eine Division-Error-Ausnahme aus. Linux übermittelt normalerweise SIGFPE; die bekannte Meldung erwähnt Gleitkommazahlen, selbst bei diesem Ganzzahlbefehl. Die Ganzzahldivision von AArch64 liefert dagegen bei einem Divisor von null das Ergebnis null. Eine Division durch null in C hat undefiniertes Verhalten, sodass portabler C-Code sich auf keines der beiden Maschinenergebnisse verlassen kann.

Wenn ein Festplattenlesevorgang endet, vermerkt die Interruptbehandlungsroutine den Abschluss und macht den wartenden Prozess bereit. Dieser Prozess kann später laufen. Ein Timerinterrupt gibt dem Betriebssystem die Gelegenheit, die aktuelle CPU-Belegung zu überdenken, aber die Behandlungsroutine kann auch zu demselben Prozess zurückkehren.

Unterscheide ein Signal von einem Interrupt

Ein Hardwareinterrupt benachrichtigt die CPU; ein Signal benachrichtigt einen Prozess über das Betriebssystem. Eine Ausnahme kann den Kernel veranlassen, ein Signal zu senden, und ein Prozess kann über kill ein Signal für einen anderen anfordern. Normale Geräteabschlüsse sind Interrupts und bedeuten keine Programmfehler.

Kernelcode muss auch gemeinsam genutzte Daten schützen, während Ereignisse auftreten. Er kann Interrupts auf einer CPU kurz deaktivieren und bei Bedarf Sperren nutzen. Lange Zeiträume mit deaktivierten Interrupts verzögern die Gerätebehandlung; das Deaktivieren lokaler Interrupts allein hindert eine andere CPU nicht am Zugriff auf gemeinsame Daten.

Jeden Anwendungsbefehl in einem Softwaresimulator auszuführen, würde die gemeinsame CPU-Nutzung aufwendig machen. Einer Anwendung unbegrenzte Kontrolle über den Rechner zu geben, würde die gemeinsame Nutzung unsicher machen. Die eingeschränkte direkte Ausführung (LDE) nutzt gewöhnliche Hardwareausführung mit einem geschützten Rückweg zum Betriebssystem.

Löse zwei unterschiedliche Steuerungsprobleme

Direkte Ausführung bedeutet, dass die gewöhnlichen Befehle eines Prozesses auf der CPU selbst ausgeführt werden. Das Betriebssystem untersucht und genehmigt nicht jeden arithmetischen Befehl. Zwei Probleme bleiben: Operationen einzuschränken, die den Rechner beschädigen könnten, und die Kontrolle zurückzugewinnen, wenn ein Programm nicht freiwillig anhält.

Der Benutzermodus löst das Problem der Einschränkung. Systemaufruf-Traps erlauben einem Programm, Dienste anzufordern, ohne beliebigen privilegierten Code zu wählen. Ein Hardwaretimer löst das Steuerungsproblem: Er kann eine Anwendung unterbrechen, die überhaupt keine Aufrufe ausführt. Zusammen unterstützen diese Mechanismen die CPU-Virtualisierung mit geringem Verwaltungsaufwand.

Bereite alles vor, bevor Anwendungen laufen

Beim Systemstart konfiguriert der Kernel Ereignisbehandlungsroutinen und initialisiert den Timer. Diese Einrichtungsoperationen sind privilegiert. Spätere Benutzerprogramme können weder die Behandlungsroutinen umlenken noch den Timer deaktivieren, um ihre CPU-Abschnitte zu behalten.

Um einen Prozess zu starten, erzeugt das Betriebssystem seinen Verwaltungsdatensatz und sein Speicherabbild, bereitet Startargumente und einen Benutzerstack vor und legt anfängliche Registerwerte fest. Es richtet einen anfänglich gesicherten Kontext so ein, dass der normale Rückweg vom Kernel zum Benutzer das Programm starten kann. Vom Konzept her beginnt der Prozess mit der Rückkehr aus einem Trap, den er nie ausgelöst hat.

Der genaue Aufbau des gesicherten Rahmens hängt von CPU und Betriebssystem ab. Die nützliche Entwurfsidee ist die Wiederverwendung: Derselbe Wiederherstellungsmechanismus kann einen angehaltenen Prozess fortsetzen oder einen neu vorbereiteten starten.

Kehre freiwillig zum Kernel zurück

Bei einem Systemaufruf sichert die Hardware den anfänglichen Rückkehrzustand und überträgt die Kontrolle. Der Kerneleinstiegscode sichert die zusätzlichen Register auf dem Kernelstack des Prozesses. Nach Abschluss einer nicht blockierenden Anfrage stellt der Kernel den Prozess wieder her und kehrt in den Benutzermodus zurück. Blockiert die Anfrage, kann zunächst ein anderer bereiter Prozess laufen.

Wenn main zurückkehrt, fordert die Beendigungsverarbeitung der Laufzeitumgebung schließlich den Kernel auf, den Prozess zu beenden. Sein Speicher kann freigegeben werden, während sein Beendigungsdatensatz erhalten bleibt, bis ein Elternprozess ihn abruft.

Kehre ohne Kooperation zurück

Ein kooperatives System ist darauf angewiesen, dass Programme Aufrufe ausführen, die CPU freiwillig abgeben oder Ausnahmen verursachen. Eine Endlosschleife, die nichts davon tut, kann eine CPU für sich beanspruchen. Das klassische Mac OS veranschaulicht diese Schwäche.

Ein nicht kooperativer Entwurf nutzt einen Timerinterrupt, um den Kerneleintritt zu erzwingen. Betrachte ein Lehrmodell mit einer logischen CPU und einem periodischen Timer alle 4 ms. Der Timer erzeugt 1000 / 4 = 250 Taktimpulse pro Sekunde. Ein Benutzerprozess, der in while (1) { } feststeckt, wird beim nächsten Taktimpuls unterbrochen. Der Kernel kann dann einen anderen bereiten Prozess ausführen; die Schleife muss nicht erst einen Systemaufruf erreichen.

Der Taktimpuls ist eine Gelegenheit zu handeln, keine Pflicht zum Prozesswechsel. Der Scheduler kann den unterbrochenen Prozess weiterlaufen lassen. Timerbehandlung und Wiederherstellung des gesicherten Zustands sind Mechanismen; die Wahl des Schedulers ist eine Strategie. Die tatsächliche Antwortzeit hängt auch von der Kernelarbeit und davon ab, wann Interrupts behandelt werden können. Die Timerperiode allein garantiert daher keine bestimmte Antwortzeit einer Anwendung.

Der Eintritt in den Kernelmodus ändert nicht zwangsläufig den laufenden Prozess. Ein Kontextwechsel findet statt, wenn der Kernel den Ausführungszustand eines Prozesses sichert und einen anderen fortsetzt. Dazu muss sowohl der Benutzerzustand gesichert als auch der eigene Ausführungskontext des Kernels gewechselt werden.

Verfolge den Wechsel von A zu B

Verfolge bei einem timergesteuerten Wechsel auf x86-64 die Ebenen:

1. A führt Benutzerbefehle aus. Der Timer unterbricht den Prozess.
2. Die Hardware wechselt in den Kernelmodus und sichert den Interruptrückkehrrahmen von A auf dem Kernelstack von A. Der Einstiegscode sichert dort die übrigen Benutzerregister von A.
3. Der Scheduler wählt B. Die Wechselroutine sichert den Kernelausführungskontext von A und stellt den gesicherten Kernelkontext von B wieder her, einschließlich dessen Kernelstapelzeigers.
4. Der Kernel wechselt bei Bedarf zum Adressraumkontext von B. Er läuft nun im Auftrag von B und nutzt dessen Kernelstack.
5. Der Kernelaustrittscode stellt die Benutzerregister von B wieder her. Der Rückkehrbefehl stellt den Rückkehrzustand von B wieder her und wechselt in den Benutzermodus. B läuft dort weiter, wo der Prozess zuvor angehalten wurde.

Die erste Sicherung bewahrt die unterbrochene Benutzerausführung von A. Die zweite bewahrt die Stelle des Kernels bei der Behandlung von A. Es handelt sich nicht um zwei identische vollständige Kopien desselben Registersatzes. Ein PCB oder eine zugehörige Kontextstruktur und der prozessbezogene Kernelstack wirken zusammen, um den Zustand zu sichern.

Erkenne das Ereignis und die Entscheidung

Ein blockierender Aufruf, ein Prozessende oder eine Timerentscheidung kann zu einem Wechsel führen. Ein Geräteinterrupt kann einen anderen Prozess bereit machen, den das Scheduling dann auswählen kann. Der gesamte Wechselmechanismus läuft im Kernel; eine Anwendung sichert ihre eigenen Register nicht, um sich freiwillig unterbrechen zu lassen.

Ein Kontextwechsel sichert den für die Fortsetzung nötigen Ausführungszustand. Zeit vergeht und die Außenwelt kann sich ändern: Gemeinsam genutzte Dateioffsets und externe Eingaben werden nicht eingefroren, während ein Prozess pausiert.

Berücksichtige direkten und indirekten Aufwand

Zur direkten Arbeit gehören das Ausführen des Schedulers, das Sichern und Wiederherstellen von Registern und die Auswahl eines Adressraums. Übersetzungscaches müssen möglicherweise angepasst werden; gekennzeichnete Übersetzungen können verhindern, dass alle alten Einträge verworfen werden. Indirekter Aufwand folgt, wenn B CPU-Caches oder zwischengespeicherte Adressübersetzungen neu füllen muss, die A verdrängt hat. Der Aufwand hängt von Hardware und Arbeitslast ab. Verwende daher bei der Berechnung des Verwaltungsaufwands gemessene oder angegebene Werte.

Angenommen, ein Wechsel kostet einschließlich seiner relevanten Auswirkungen 5 µs und nutzbare CPU-Abschnitte dauern 10 ms. Rechne 10 ms in 10.000 µs um. Der Wechselanteil beträgt 5 / (10.000 + 5), etwa 0,05 %. Bei nutzbaren Abschnitten von 1 ms sind es 5 / 1005, etwa 0,50 %; bei 0,1 ms sind es 5 / 105, etwa 4,8 %.

Der Nenner umfasst die nutzbare Arbeit plus die Wechselzeit für einen wiederholten Zyklus. Ein kürzerer Abschnitt kann die Möglichkeiten für interaktive Arbeit verbessern, beansprucht aber einen größeren Anteil für wiederholte Wechsel. Timer und Wechselcode ermöglichen kurze Abschnitte; die Schedulingstrategie muss diesen Aufwand gegen die Reaktionsfähigkeit abwägen.