Prozess (Informatik)

Begriff und Aufbau eines Prozesses

Ein Prozess, auch Task oder Programminstanz genannt, ist ein Computerprogramm zur Laufzeit. Genauer handelt es sich um die konkrete Instanziierung eines Programms zu dessen Ausführung innerhalb eines Rechnersystems. Dazu kommen Verwaltungsinformationen und Ressourcenzuteilungen des Betriebssystems. Ein Programm ist dagegen eine statische Folge von Anweisungen, Deklarationen und Instruktionen. Es bewirkt nichts, solange es nicht gestartet wurde. Erst wenn eine ausführbare Datei in den Hauptspeicher und den Adressraum eines Prozesses geladen wird, entsteht eine laufende Programminstanz.

Ein Prozess stellt die Ablaufumgebung für ein Programm bereit. Er umfasst insbesondere:

• den Befehlszähler mit der Adresse des nächsten auszuführenden Befehls,
• die Inhalte der zugehörigen Prozessorregister,
• das Programmsegment (text) mit dem ausführbaren Code,
• das Stack-Segment mit temporären Daten wie Rücksprungadressen und lokalen Variablen,
• das Datensegment (data) mit globalen Variablen und
• gegebenenfalls den Heap mit dynamisch angefordertem und wieder freigebbarem Speicher.

Die Gesamtheit der für Ablauf und Verwaltung wichtigen Zustandsinformationen heißt Prozesskontext. Die erlaubten Speicherbereiche bilden den Prozessadressraum. Dieser ist im Allgemeinen virtuell: Der virtuelle Speicher stellt dem Prozess einen vom tatsächlich vorhandenen Hauptspeicher unabhängigen Adressraum zur Verfügung. Die Memory Management Unit (MMU) wandelt virtuelle in physische Adressen um. Daten müssen in den Adressraum geladen sein; Daten, die ein Maschinenbefehl gerade verwendet, müssen sich außerdem im physischen Hauptspeicher befinden.

Zwei Prozesse können aus demselben Programm entstanden sein, gelten aber als getrennte Ausführungseinheiten. Ihre Programmsegmente können gemeinsam sein, während sich Daten-, Heap- und Stack-Segmente unterscheiden. So können mehrere Benutzer oder ein Benutzer mehrere Kopien eines Mail- oder Browser-Programms ausführen.

Ein Prozess kann außerdem selbst als Ablaufumgebung für anderen Programmcode dienen. Die Java-Laufzeitumgebung besteht üblicherweise aus der Java Virtual Machine (JVM), die Java-Anwendungen ausführt. Der Befehl java Program erzeugt einen gewöhnlichen Prozess für die JVM; diese führt anschließend Program in der virtuellen Maschine aus. Tanenbaum veranschaulicht den Unterschied zwischen Programm und Prozess mit dem Bild eines Kuchenrezepts: Das Rezept ist das Programm, der Bäcker der Prozessorkern, die Zutaten die Eingabedaten und das Backen die laufende Aktivität.

Zustände, Kontext und Verwaltung

Ein Prozess wird vom Betriebssystem dynamisch kontrolliert und durchläuft während seiner Lebenszeit verschiedene Zustände. Zu unterscheiden sind der Ausführungszustand, also etwa Registerinhalte, Speicherzuordnung und aktuelle Programmstelle, und der Prozesszustand aus Sicht des Betriebssystems. Vereinfacht gibt es vier Zustände:

• Rechnend (running oder aktiv): Die Befehle des Prozesses werden gerade auf der CPU ausgeführt.
• Rechenbereit (ready): Der Prozess könnte weiterlaufen, wartet aber auf die Zuteilung der CPU. Auch ein neu erzeugter Prozess gelangt zunächst in diesen Zustand.
• Blockiert (blocked): Der Prozess wartet auf ein notwendiges Ereignis oder eine Ressource, zum Beispiel Eingabedaten oder den Abschluss einer Ein-/Ausgabe.
• Beendet (terminated): Die Ausführung ist beendet, das Betriebssystem muss noch aufräumen.

Rechenbereite Prozesse werden in einer Ready-Queue verwaltet. Der Scheduler wählt daraus den nächsten Prozess aus. Läuft die zugeteilte Rechenzeit ab oder gibt ein Prozess die CPU freiwillig ab, wechselt er von rechnend zu rechenbereit. Wird eine benötigte Dienstleistung oder Ressource nicht sofort verfügbar, wird er blockiert. Sobald die Ursache entfällt, etwa durch eingetroffene Daten, einen Tastendruck, einen Mausklick oder eine abgeschlossene Dienstleistung, wird er wieder rechenbereit. Nach erfolgreichem Ende, einem schwerwiegenden Fehler oder einer ausdrücklichen Beendigung wechselt er in den Zustand beendet. Pro Prozessorkern kann immer nur ein Prozess gleichzeitig rechnend sein; viele Prozesse können jedoch gleichzeitig rechenbereit oder blockiert sein.

Die gesamte für Ablauf und Verwaltung relevante Information heißt Prozesskontext. Dazu gehören die Betriebssysteminformationen und die Inhalte aller Prozessregister, etwa Allzweckregister, Befehlszähler, Statusregister und MMU-Register. Bei einem Kontextwechsel wird zunächst der Hardware-Kontext des laufenden Prozesses gesichert. Danach wird der Kontext des Schedulers hergestellt. Dieser entscheidet, welcher Prozess folgt, sichert anschließend seinen eigenen Kontext und lädt den Hardware-Kontext des neuen Prozesses.

Jeder Prozess wird durch einen Prozesskontrollblock (PCB, auch task control block) dargestellt. Im PCB werden unter anderem gespeichert:

• die eindeutige Process identifier (PID), die sich während der Laufzeit nicht ändert,
• der Prozessstatus,
• Befehlszähler und übrige CPU-Register,
• Priorität, Scheduling-Warteschlangen und weitere Scheduling-Parameter,
• Informationen zur Speicherverwaltung,
• Buchhaltungsdaten wie Rechenzeit und Speicherverbrauch,
• belegte E/A-Geräte, Ressourcen und offene Dateien,
• Elternprozess, Prozessgruppe und CPU-Zeit der Kindprozesse sowie
• Zugriffs- und Benutzerrechte.

Die Prozesstabelle ist eine kerneleigene Datenstruktur mit den aktuellen Prozessen. Für jeden neuen Prozess wird ein PCB als Eintrag angelegt. Über die PID sucht das Betriebssystem den zugehörigen PCB. Da die darin enthaltenen Ressourceninformationen direkt zugreifbar sein müssen, ist ein effizienter Tabellenzugriff wichtig.

Erzeugung, Beendigung und Rechte

Prozesse können im Vordergrund oder im Hintergrund laufen. Vordergrundprozesse stehen in direkter Verbindung mit menschlichen Benutzern und belegen Eingabe- und Ausgaberessourcen. Hintergrundprozesse benötigen keine Benutzerinteraktion. Auf Unix-basierten Systemen heißen sie meist Daemons, auf Windows-basierten Systemen Dienste. Beim Hochfahren werden üblicherweise viele solcher Prozesse gestartet. Unter Unix zeigt ps laufende Prozesse an, unter Windows dient dazu der Taskmanager.

Ein laufender Prozess kann durch einen Systemaufruf weitere Prozesse erzeugen. In unixoiden Systemen erzeugt fork() aus einem Elternprozess einen neuen Kindprozess. Dieser ist zunächst eine Kopie des Elternprozesses, erhält aber eine eigene PID und wird als unabhängige Programminstanz ausgeführt. In Windows kann ein Prozess mit CreateProcess() gestartet werden. In Unix bilden ein Prozess und seine Nachkommen eine Prozessfamilie. Signale, die ein Benutzer beispielsweise über die Tastatur sendet, können an die betroffenen Prozesse dieser Familie weitergeleitet werden. Windows kennt dagegen keine Prozesshierarchie; ein spezielles Handle erlaubt dem Elternprozess lediglich, den Kindprozess zu steuern.

Normalerweise beendet sich ein Prozess am Ende seines Programmablaufs mit dem Systemaufruf exit unter Unix oder exitProcess unter Windows. Benutzer können bildschirmorientierte Programme auch über ein Symbol oder einen Menüpunkt beenden. Vor dem Ende sollte ein Prozess offene Dateien schließen und Ressourcen zurückgeben. Ein anderer Prozess kann die Beendigung mit kill unter Unix oder TerminateProcess unter Windows veranlassen. Das Betriebssystem kann einen Prozess außerdem wegen eines schwerwiegenden Programmierfehlers oder einer illegalen Aktion abbrechen, etwa bei einem Zugriff auf nicht mehr zugeteilte Ressourcen, unbekannten CPU-Befehlen oder verbotenen direkten Hardwarezugriffen.

Unter unixoiden Betriebssystemen kann ein beendeter Kindprozess vorübergehend noch in der Prozesstabelle stehen. Dieser Zustand heißt Zombie-Prozess. Der Elternprozess kann dadurch abfragen, ob das Kind erfolgreich, mit Fehler, abgestürzt oder abgebrochen beendet wurde. Bis diese Abfrage erfolgt, bleibt die Information erhalten.

Für Zugriffsrechte authentifiziert sich ein Benutzer normalerweise mit Login-Namen und Passwort. Das Betriebssystem ordnet ihm eine eindeutige Benutzer-ID (UID) zu; Gruppen erhalten eine Gruppen-ID (GID). Ein Prozess trägt die UID und GID seines Aufrufers und gehört damit dem Benutzer, der ihn gestartet hat. Dateien, die er erzeugt, erhalten ebenfalls dessen UID und GID. Beim Dateizugriff prüft das Betriebssystem anhand dieser Angaben, ob der Zugriff erlaubt ist. Der Superuser oder Root-Benutzer besitzt in unixoiden Systemen die UID 0 und weitreichende Rechte. Das Setuid-Bit kann die effektive UID eines Prozesses auf den Besitzer der ausführbaren Datei setzen und so einen kontrollierten Zugriff auf privilegierte Ressourcen ermöglichen.

Prozessumschaltung, Scheduling und Unterbrechungen

Bei einer Prozessumschaltung wird die CPU einem anderen Prozess zugeteilt. Bei nicht unterbrechbaren Prozessen geschieht dies beim Start und Ende einer Ausführung. Bei unterbrechbaren Prozessen kann der Wechsel auch während der Ausführung erfolgen. Erhält ein Prozess mit höherer Priorität die CPU, spricht man von Verdrängung oder Suspension.

Der Prozess-Scheduler regelt die zeitliche Ausführung mehrerer Prozesse. Seine Schedulingstrategie soll die CPU möglichst gut zuteilen; je nach System sind dabei kurze Antwortzeiten, Fairness oder eine hohe Gesamtauslastung wichtige Ziele. Auf einem Einprozessorsystem ist immer nur ein Prozess rechnend. Auch auf Mehrprozessorsystemen gibt es meist mehr Prozesse als Prozessorkerne, sodass die Prozesse um CPU-Zeit konkurrieren. Idealerweise bleiben sowohl CPU als auch Ein-/Ausgabegeräte beschäftigt.

• Eine nicht unterbrechende Schedulingstrategie lässt den ausgewählten Prozess laufen, bis er blockiert oder die CPU freiwillig abgibt.
• Eine unterbrechende Schedulingstrategie begrenzt die Rechenzeit durch ein festgelegtes Zeitintervall. Danach erhält der Scheduler durch einen Timerinterrupt die Kontrolle zurück und wählt einen anderen rechenbereiten Prozess.

Unterbrechungen erlauben es Hardware oder Software, einen Prozess vorübergehend anzuhalten und eine kurze, häufig zeitkritische Betriebssystemaufgabe auszuführen. Das auslösende Ereignis heißt Unterbrechungsanforderung (IRQ). Danach arbeitet der Prozessor eine Unterbrechungsroutine oder Interrupt-Service-Routine (ISR) ab. Anschließend wird der alte Prozessorstatus wiederhergestellt und der Prozess an der unterbrochenen Stelle fortgesetzt; je nach Schedulingstrategie kann zuvor ein Prozess höherer Priorität laufen.

Synchrone Unterbrechungen werden durch interne Ereignisse während der Verarbeitung eines Befehls ausgelöst. Sie treten bei gleichen Bedingungen an derselben Programmstelle auf, sind also vorhersehbar und nicht verzögerbar. Beispiele sind:

• ein Befehlsalarm beim Versuch, einen privilegierten Befehl auszuführen,
• ein Seitenfehler, wenn eine benötigte Speicherseite beim Paging nicht im Hauptspeicher liegt, und
• ein arithmetischer Alarm, etwa bei einer Division durch null.

Asynchrone Unterbrechungen hängen nicht vom gerade rechnenden Prozess und nicht von der CPU-Verarbeitung ab. Sie entstehen durch unvorhersagbare externe Ereignisse, häufig durch Ein-/Ausgabegeräte. Beispiele sind empfangene Daten einer Netzwerkkarte, fertig gelesene Daten einer Festplatte, ein fertig gezeichnetes Bild der Grafikkarte oder benötigte neue Sound-Daten. Interrupt-Vektoren in einer Interrupt-Vektor-Tabelle enthalten die Speicheradressen der zuständigen ISRs. Nach der Bearbeitung bestätigt die ISR die Unterbrechung beim Interrupt-Controller.

Threads und Interprozesskommunikation

Ein Thread ist eine nebenläufige Ausführungseinheit innerhalb eines Prozesses. Moderne Betriebssysteme benötigen zu jedem Prozess mindestens einen Thread, der den Programmcode ausführt. Ein Prozess kann mehrere Threads enthalten oder bei fehlender Parallelverarbeitung nur einen. Threads werden auch als leichtgewichtige Prozesse (light-weight processes, LWP) bezeichnet, weil sie sich schneller erzeugen und zerstören lassen. In vielen Systemen ist die Thread-Erstellung 10-100-mal schneller als die Prozesserstellung.

Threads eines Prozesses teilen sich dessen Adressraum sowie Ressourcen wie Prozessoren, Dateien und Netzwerkverbindungen. Für einen neuen Thread muss daher kein neuer Adressraum eingerichtet werden. Der Verwaltungsaufwand und der Datenaustausch sind geringer als bei Prozessen; auch beim Threadwechsel ist kein vollständiger Prozesskontextwechsel nötig. Der gemeinsame Speicher bedeutet aber, dass Threads nicht gegeneinander geschützt sind. Bei Zugriffen auf gemeinsame Ressourcen müssen sie sich synchronisieren.

Threads können auf Benutzerebene oder auf Kernelebene implementiert werden. Bei Benutzer-Threads übernimmt eine Threadbibliothek Scheduling und Umschaltung; der Kernel kennt die einzelnen Threads nicht. Jeder Prozess verwaltet dafür einen privaten Thread-Kontrollblock. Bei Kernel-Threads verwaltet der Betriebssystemkern die Threads und ist an ihrer Erzeugung und Umschaltung beteiligt. Windows verwendet Threads auf Kernelebene; unter Unix sind Implementierungen auf Kernel- und Benutzerebene möglich.

Interprozesskommunikation (IPC) umfasst Verfahren zum Informationsaustausch zwischen Prozessen:

• Beim Shared Memory greifen mehrere Prozesse auf einen gemeinsamen Datenspeicher zu.
• Eine Message Queue speichert Nachrichten, also Datenpakete, in einer Nachrichtenschlange, aus der ein anderer Prozess sie abholt.
• Eine Pipe ist ein Byte-Datenstrom zwischen zwei Prozessen nach dem FIFO-Prinzip. Für längere Datenpakete wird sie meist durch Sende- oder Empfangspuffer ergänzt.

Gemeinsam genutzte Ressourcen müssen geschützt werden, damit keine Race Conditions entstehen. Kritische Abschnitte, also Programmteile mit solchen Zugriffen, können etwa durch Semaphore oder Monitore geschützt werden. Ein Deadlock entsteht, wenn Prozesse gegenseitig auf Ressourcenfreigaben oder Nachrichten warten und dadurch dauerhaft blockiert bleiben. Klassische IPC-Probleme sind das Erzeuger-Verbraucher-Problem, das Philosophenproblem und das Leser-Schreiber-Problem.

CPU-Ausnutzung und Programmbeispiele

Multiprogrammierung verbessert die CPU-Ausnutzung, weil ein Prozess während einer Ein-/Ausgabe blockiert sein kann, während ein anderer die CPU nutzt. Wenn ein Prozess den Anteil p seiner Laufzeit auf die Beendigung von Ein-/Ausgaben wartet, beträgt die Wahrscheinlichkeit, dass n solche Prozesse gleichzeitig auf Ein-/Ausgaben warten, p^n. Das vereinfachte Modell lautet:

CPU-Ausnutzung = 1 - p^n

Der Wert n wird als Grad der Multiprogrammierung bezeichnet. Für interaktive Prozesse oder Server mit viel Plattenein-/ausgabe kann die Annahme realistisch sein, dass ein Prozess 80 % seiner Zeit blockiert ist. Der Artikel nennt unter dieser Annahme mindestens 10 laufende Prozesse, damit die CPU weniger als 10 % der Zeit verschwendet wird. Das Modell ist nur eine Annäherung, weil es unabhängige Prozesse voraussetzt und berücksichtigt werden müsste, dass auf einer einzelnen CPU nicht mehrere Prozesse gleichzeitig laufen. Ein genaueres Modell kann mit der Warteschlangentheorie erstellt werden.

Ein typisches fork()-Beispiel ist ein C-Programm mit der Zählervariable counter, die zunächst 0 ist. Nach fork() existieren Eltern- und Kindprozess mit jeweils einer eigenen Kopie dieser Variable. Bei Erfolg liefert fork() dem Elternprozess die PID des Kindes und dem Kind den Rückgabewert 0. Ein negativer Rückgabewert zeigt einen Fehler an. Mit getpid() kann ein Prozess seine eigene PID ermitteln. Beide Prozesse erhöhen ihre eigene Version von counter in einer Schleife von 0 bis 1000. Da das Scheduling nicht vorhersehbar ist, kann die Reihenfolge der Konsolenausgabe von Durchgang zu Durchgang variieren.

Eine Forkbomb entsteht, wenn ein Prozess in einer Endlosschleife mit fork() immer neue Kindprozesse erzeugt, die sich ebenso verhalten. Dadurch können Prozesstabellen, CPU und weitere Systemressourcen aufgebraucht werden. Eine Forkbomb ist damit eine Denial-of-Service-Attacke, kann aber auch durch unbedachte Verwendung von fork() ausgelöst werden. Der konkrete Effekt hängt von der Betriebssystemkonfiguration ab. Unter Unix kann PAM beispielsweise die Zahl der Prozesse und den maximalen Speicherverbrauch pro Benutzer begrenzen. Werden solche Grenzen genutzt, scheitern weitere Erzeugungsversuche irgendwann und das Wachstum wird eingedämmt.