Prozesse - pearson.ch fileTeil 2 Prozesse Darum geht es in Teil 2 Die wichtigste Aufgabe moderner Betriebssysteme ist die Prozessverwaltung. Das Betriebssystem muss den Prozessen Ressourcen

Teil 2

Prozesse

Darum geht es in Teil 2Die wichtigste Aufgabe moderner Betriebssysteme ist die Prozessverwaltung. DasBetriebssystem muss den Prozessen Ressourcen zuteilen, es den Prozessen ermögli-chen, Informationen zu teilen und auszutauschen, die Ressourcen der Prozesse voranderen Prozessen schützen und die Synchronisierung unter den Prozessen ermögli-chen. Um diese Anforderungen erfüllen zu können, muss das Betriebssystem für jedenProzess eine Datenstruktur verwalten, die den Status und den Ressourcenbesitz desProzesses beschreibt und es dem Betriebssystem ermöglicht, die Kontrolle auszuüben.

Bei einem Einprozessorsystem mit Mehrprogrammbetrieb kann die Ausführungmehrerer Prozesse zeitlich im Wechsel erfolgen. Bei einem Mehrprozessorsystemkönnen nicht nur mehrere Prozesse im Wechsel auf einem Prozessor bearbeitet wer-den, sondern mehrere Prozesse auf mehreren Prozessoren gleichzeitig parallel ablau-fen. Sowohl die parallele als auch die Ausführung im Wechsel sind Ausführungsvari-anten nebenläufiger Programme. Nebenläufigkeit (Concurrency) impliziert eineReihe von gravierenden Problemen, sowohl für den Anwendungsprogrammierer alsauch für das Betriebssystem.

In vielen zeitgenössischen Betriebssystemen werden die Schwierigkeiten der Pro-zessverwaltung durch die Unterstützung von Threads um eine weitere Dimension ver-größert. In einem System mit Multithreading gehören alle Aspekte des Ressourcenbesit-zes zum Begriff des Prozesses, während Aspekte der Ausführung den Threads einesProzesses zugeordnet werden. Da ein Prozess mehrere Threads haben kann, kann eineinzelner Prozess dadurch intern mehrere nebenläufige Ausführungsströme aufweisen.

Wegweiser für Teil 2

Kapitel 3: Beschreibung und Verwaltung von ProzessenBei einem herkömmlichen Betriebssystem liegt das Hauptaugenmerk auf der Verwal-tung von Prozessen. Jeder Prozess befindet sich zu jedem beliebigen Zeitpunkt in

Teil 2 – Prozesse130

einem von zahlreichen Ausführungszuständen, wie z.B. »bereit«, »aktiv« und »blo-ckiert«. Das Betriebssystem überwacht diese Ausführungszustände und verwaltetden Übergang der Prozesse von einem Zustand in einen anderen. Zu diesem Zweckpflegt das Betriebssystem relativ komplexe Datenstrukturen, die jeden Prozessbeschreiben. Das Betriebssystem muss das Scheduling durchführen, eine geteilteNutzung von Speicherbereichen durch mehrere Prozesse ermöglichen und hierbeiauch Möglichkeiten zur Synchronisierung von Prozessen bereitstellen. Kapitel 3befasst sich mit den Datenstrukturen und den Techniken, die in einem typischenBetriebssystem für die Prozessverwaltung zum Einsatz kommen.

Kapitel 4: Threads, SMP und Mikrokernel

In Kapitel 4 werden drei Themengebiete behandelt, die für viele heutige Betriebssys-teme kennzeichnend sind und gegenüber der traditionellen Struktur von Betriebssys-temen einen Fortschritt darstellen. In vielen heutigen Betriebssystemen wird das tra-ditionelle Konzept des Prozesses in zwei Teile gespalten: Ein Teil befasst sich mit demRessourcenbesitz (Prozess), der andere mit der Folge auszuführender Befehle(Thread). Ein einzelner Prozess kann mehrere Threads beinhalten. Threads könnensowohl vorteilhaft in Bezug auf eine klare Strukturierung einer Anwendung als auchin Bezug auf das Leistungsverhalten sein. In Kapitel 4 wird darüber hinaus das SMP-System untersucht. Es handelt sich hierbei um ein Computersystem mit mehrerenProzessoren, von denen jeder in der Lage ist, sämtliche Anwendungs- und System-codes auszuführen. Durch den SMP-Aufbau werden die Leistung und die Zuverläs-sigkeit verbessert. SMP (Symmetric Multi-Processing) wird häufig in Verbindung mitMultithreading eingesetzt, kann aber auch ohne Multithreading durch Parallelverar-beitung zu enormen Leistungssteigerungen führen. Schließlich wird in Kapitel 4 dasKonzept des Mikrokernels untersucht. Hierbei handelt es sich um eine Betriebssys-temstruktur, bei der die Menge des Systemcodes, der im Kernelmodus läuft, mini-miert wird. Die Vorteile dieses Ansatzes werden analysiert.

Kapitel 5: Nebenläufigkeit: wechselseitiger Ausschluss und Synchronisierung

Zwei zentrale Themen moderner Betriebssysteme sind der Mehrprogrammbetrieb(Multiprogramming) und die verteilte Verarbeitung. Grundlegend für diese beidenThemen und auch für das Design von Betriebssystemen ist die Nebenläufigkeit. InKapitel 5 werden zwei Aspekte der Nebenläufigkeit betrachtet: der wechselseitigeAusschluss und die Synchronisierung. Der wechselseitige Ausschluss bezieht sichauf die Fähigkeit, mehrere Prozesse (oder Threads), Code, Ressourcen oder Daten sogemeinsam zu nutzen, dass zu jedem Zeitpunkt jeweils nur maximal ein ProzessZugriff auf das gemeinsam genutzte Objekte hat. Die Synchronisierung steht zumwechselseitigen Ausschluss in einem engen Zusammenhang. Durch Synchronisie-rung können mehrere Prozesse ihre Aktivitäten untereinander koordinieren, diesgeschieht durch den Austausch von Informationen etwa über geteilte Objekte oderdurch Nachrichtenübermittlung. In Kapitel 5 werden die Themen der Nebenläufig-keit ausführlich behandelt, wobei mit prinzipiellen Überlegungen begonnen wird. Eswerden algorithmische Lösungen für den wechselseitigen Ausschluss ebensobetrachtet, wie verschiedene Varianten der Hardwareunterstützung. Anschließend

Teil 2 – Prozesse 131

folgt eine Vorstellung der wesentlichen Konzepte für die Unterstützung nebenläufi-ger Programme: Semaphore, Monitore und Nachrichtenübermittlung.

Kapitel 6: Nebenläufigkeit: Verklemmung und VerhungernIn Kapitel 6 werden zwei weitere Aspekte der Nebenläufigkeit behandelt. Der Aus-druck Verklemmung (Deadlock) bezeichnet eine Situation, in der zwei oder mehrProzesse darauf warten, dass der jeweils andere Prozess eine Operation beendet, umdann selbst fortfahren zu können, wobei aber keiner der Prozesse in der Lage ist fort-zufahren. Die Verklemmung ist als Phänomen durch automatisierte Verfahren nurschwer vorherzusehen und es gibt keine allgemein gültigen, einfachen Lösungen fürdieses Problem. In Kapitel 6 werden einige Ansätze für den Umgang mit Verklem-mungen betrachtet: die Verhinderung, die Vermeidung und die Erkennung. ImUnterschied zur Verklemmung bezieht sich der Ausdruck Verhungern (Starvation)auf eine Situation, in der ein Prozess für die Ausführung bereit ist, ihm aber derZugriff auf den Prozessor permanent verweigert wird, weil anderen Prozessen derVorzug gegeben wird. Das Verhungern wird zu einem großen Teil in Zusammenhangmit der Ablaufplanung, dem Scheduling, behandelt und somit in Teil 4 näher bespro-chen. Obwohl sich Kapitel 6 auf die Verklemmung konzentriert, wird das Verhungernin diesem Zusammenhang dennoch angesprochen, da bei den Lösungen für die Ver-klemmung darauf geachtet werden muss, das Problem des Verhungerns zu vermei-den.

K AP I TE L 3

Beschreibung und Steuerung von Prozessen

Der Aufbau eines Betriebssystems muss gewisse allgemeine Anforderungen berück-sichtigen. Alle Mehrprogrammbetriebssysteme, von Einzelbenutzersystemen wieWindows 98 bis hin zu Großrechnersystemen wie OS/390, die Tausende Benutzerunterstützen können, nehmen das Prozesskonzept zum Ausgangspunkt für ihrenAufbau. Die meisten Anforderungen, die ein Betriebssystem erfüllen muss, lassensich daher mit Bezug auf Prozesse formulieren:

õ Das Betriebssystem muss mehrere Prozesse jeweils nur partiell und dafür imWechsel ausführen können, um den Nutzungsgrad des Prozessors zu maximierenund dabei eine akzeptable Antwortzeit für jeden einzelnen Prozess zu erreichen.

õ Das Betriebssystem muss Prozessen im Einklang mit einer spezifisch festgelegtenVorgehensweise (so haben beispielsweise bestimmte Funktionen oder Anwen-dungen eine höhere Priorität) Ressourcen zuteilen und gleichzeitig versuchen,eine Verklemmung1 (Deadlock) zu vermeiden.

õ Das Betriebssystem muss möglicherweise die Interprozesskommunikation unddie Erzeugung von Prozessen durch Benutzer unterstützen, was beides bei derStrukturierung von Anwendungen hilfreich sein kann.

Wir beginnen unsere detaillierte Studie der Betriebssysteme mit einer Untersuchungder Art und Weise, wie Betriebssysteme Prozesse darstellen und verwalten. An ersterStelle werden die Prozesszustände eingeführt, die das Verhalten von Prozessen cha-rakterisieren. Anschließend erfolgt eine Betrachtung der Datenstrukturen, die einBetriebssystem benötigt, um den Zustand von Prozessen darzustellen, sowie eineBetrachtung anderer Merkmale von Prozessen, die für ein Betriebssystem relevantsind. Abschließend wird die Prozessverwaltung in UNIX SVR4 besprochen.

Hinweis: In diesem Kapitel wird gelegentlich der virtuelle Speicher angesprochen.Viele Aspekte in der Behandlung von Prozessen können ohne Betrachtung des Spei-chers behandelt werden, aber an bestimmten Punkten der Diskussion sind Überle-gungen zum virtuellen Speicher durchaus relevant. Der virtuelle Speicher wird erstin Kapitel 8 im Detail besprochen, aber Kapitel 2 enthält einen kurzen Überblick überdieses Thema.

1 Das Thema Verklemmung wird in Kapitel 6 behandelt. Kurz gesagt tritt eine Verklemmung auf,wenn zwei Prozesse zur gleichen Zeit dieselben zwei Ressourcen benötigen und jeder der Pro-zesse eine der Ressourcen in seinem Besitz hat. Die Prozesse warten unendlich auf die fehlendeRessource.

Kapitel 3 – Beschreibung und Steuerung von Prozessen134

3.1 ProzesszuständeDie Hauptaufgabe eines Prozessors besteht darin, die im Hauptspeicher befindlichenMaschinenbefehle auszuführen. Diese Befehle liegen in Form von Programmen vor.Wie bereits im vorangehenden Kapitel beschrieben, kann ein Prozessor aus Gründender Effizienz und der Vereinfachung der Programmierung die Ausführung mehrererProgramme im Verlauf der Zeit miteinander verschachteln, d.h. die Bearbeitung einesProgramms zugunsten der Bearbeitung eines anderen Programms zeitweise unter-brechen.

Wie bereits in Kapitel 2 erklärt wurde, wird für die Ausführung eines Programmsein Prozess oder auch Task für das betreffende Programm erzeugt. Aus der Sichteines einzelnen Prozesses werden die Befehle des zugehörigen Programms durch denProzessor in einer Reihenfolge abgearbeitet, die durch das Programm selbst bestimmtwird und der aktuelle Befehl ist für den Prozessor als Wert im Programmzählerregis-ter erkennbar. Das Verhalten eines einzelnen Prozesses lässt sich durch eine Auflis-tung der Befehle, die für diesen Prozess ausgeführt werden, charakterisieren. Eine

Abbildung 3.1 Momentaufnahme eines Ausführungsbeispiels (Abbildung 3.3) am Befehlszyklus 13

3.1 Prozesszustände 135

solche Auflistung wird als Trace eines Prozesses bezeichnet. Im Verlauf der Zeit bear-beitet der Prozessor möglicherweise Befehle aus unterschiedlichen Programmen, dieTeil unterschiedlicher Prozesse sind. Das Verhalten des Prozessors kann dadurch cha-rakterisiert werden, dass aufgezeigt wird, wie die Traces der verschiedenen Prozessemiteinander verwoben sind.

Gehen wir einmal von einem einfachen Beispiel aus. In Abbildung 3.1 ist der Spei-cheraufbau von drei Prozessen dargestellt. Der Einfachheit halber nehmen wir an,dass kein virtueller Speicher verwendet wird. Alle drei Prozesse werden daher durchProgramme repräsentiert, die vollständig in den Hauptspeicher geladen sind. Zusätz-lich gibt es ein kleines Dispatcher-Programm, das einen Wechsel des bearbeitetenProzesses bewirken kann. In Abbildung 3.2 sind die Traces der drei Prozesse in einemfrühen Stadium ihrer Ausführung dargestellt. Die ersten zwölf Befehle, die in ProzessA und Prozess C ausgeführt wurden, werden in der Abbildung gezeigt. Prozess Bführt vier Befehle aus. Wir nehmen dabei einmal an, der vierte Befehl ruft eine E/A-Operation hervor, auf die der Prozess warten muss.

Wir betrachten diese Traces nun mit Blick auf den Prozessor. In Abbildung 3.3sind die miteinander verwobenen Traces, die aus den ersten 52 Befehlszyklen resul-tieren, dargestellt (zur Veranschaulichung sind die Befehlszyklen nummeriert). Wirnehmen an, dass das Betriebssystem einem Prozess nur erlaubt, die Ausführung übermaximal sechs Befehlszyklen fortzusetzen. Nach diesen sechs Befehlszyklen wird derProzess unterbrochen. Auf diese Weise wird verhindert, dass ein einzelner Prozessdie Prozessorzeit vollkommen für sich in Anspruch nimmt. Wie in Abbildung 3.3dargestellt, werden die ersten sechs Befehle von Prozess A ausgeführt, gefolgt von

Abbildung 3.2 Traces der Prozesse aus Abbildung 3.1


einem Timeout und der Ausführung von Code im Dispatcher, der sechs Befehle aus-führt, um festzulegen, dass anschließend Prozess B ausgeführt wird.2 Nach der Aus-

Abbildung 3.3 Kombinierte Traces der Prozesse aus Abbildung 3.1

2 Die geringe Anzahl von Befehlen, die von den Prozessen und dem Dispatcher ausgeführt werden,ist unrealistisch niedrig angesetzt. Sie dient in diesem vereinfachten Beispiel aber zur Klärung desSachverhalts.


führung von vier Befehlen fordert Prozess B eine E/A-Aktion an, auf die er wartenmuss. Der Prozessor stoppt also die Ausführung von Prozess B und setzt nach Bear-beitung des Dispatchers seine Arbeit mit der Ausführung von Prozess C fort. Nacheinem Timeout kehrt der Prozessor zurück zu Prozess A. Nach Ablauf des Zeitlimitsdieses Prozesses wartet Prozess B immer noch auf die Beendigung der E/A-Opera-tion, so dass der Dispatcher entscheidet, dass Prozess C als nächster Prozess bearbei-tet wird.

3.1.1 Prozessmodell mit zwei ZuständenDie Hauptverantwortung des Betriebssystems ist die Steuerung der Ausführung vonProzessen. Das beinhaltet die Festlegung der Ausführungsreihenfolge und die Zutei-lung von Ressourcen zu Prozessen. Der erste Schritt bei der Erstellung eines Pro-gramms für die Prozesssteuerung ist die Beschreibung des Verhaltens, das die Pro-zesse zeigen sollen.

Ein sehr einfaches Modell unterscheidet Prozesse zu einem Zeitpunkt lediglichdanach, ob sie durch den Prozessor ausgeführt werden oder nicht. Ein Prozess kanndemnach einen von zwei möglichen Zuständen annehmen: aktiv oder nicht aktiv, wiein Abbildung 3.4a dargestellt. Wenn das Betriebssystem einen neuen Prozess erzeugt,dann fügt es den Prozess im nicht aktiven Zustand in das System ein. Der Prozess

Abbildung 3.4 Prozessmodell mit zwei Zuständen


existiert, ist dem Betriebssystem bekannt und wartet auf eine Gelegenheit zur Aus-führung. Von Zeit zu Zeit wird der gerade aktive Prozess unterbrochen und der Dis-patcher-Teil des Betriebssystems wählt einen neuen Prozess für die Ausführung aus.Der vorherige Prozess wechselt vom aktiven Zustand in den nicht aktiven Zustandund einer der anderen Prozesse nimmt den aktiven Zustand an.

Anhand dieses einfachen Beispiels lassen sich bereits einige der Designelementedes Betriebssystems diskutieren. Jeder Prozess muss auf irgendeine Art und Weiserepräsentiert werden, damit das Betriebssystem ihn verfolgen kann. Das heißt, dasses für jeden Prozess irgendeine Art von Information geben muss, die den aktuellenStatus und den Speicherort beinhaltet. Prozesse, die nicht laufen, müssen in einer ArtWarteschlange geparkt werden, in der sie darauf warten, ausgeführt zu werden. InAbbildung 3.4b wird ein entsprechender Aufbau vorgeschlagen. Es gibt eine einzigeWarteschlange, in der jeder Eintrag einen Zeiger auf einen bestimmten Prozess dar-stellt. Alternativ kann die Warteschlange aus einer verketteten Liste von Datenblö-cken bestehen, wobei jeder Block einen Prozess repräsentiert. Die letzte Implementie-rung wird später besprochen.

Das Verhalten des Dispatchers kann mit Hilfe dieses Warteschlangendiagrammsbeschrieben werden. Ein Prozess, der unterbrochen wird, wird in die Prozesswarte-schlange eingereiht. Wenn der Prozess beendet oder abgebrochen wurde, wird eralternativ dazu aussortiert (er verlässt das System). In jedem Fall wählt der Dispat-cher anschließend einen Prozess aus der Warteschlange für die Ausführung aus.

3.1.2 Die Erzeugung und Terminierung von ProzessenVor einer Verfeinerung des einfachen Modells mit zwei Zuständen soll zunächst dieErzeugung und Terminierung von Prozessen besprochen werden, denn diese Punktebegrenzen das Leben eines Prozesses unabhängig von dem verwendeten Prozessver-haltensmodell.

ProzesserzeugungWenn ein neuer Prozess zu den aktuell verwalteten Prozessen hinzugefügt werdensoll, erstellt das Betriebssystem die Datenstrukturen, die für die Verwaltung des Pro-zesses verwendet werden (wie in Abschnitt 3.2 beschrieben wird), und weist demProzess Adressraum im Hauptspeicher zu. Diese Aktionen bilden die Erzeugungeines neuen Prozesses.

Tabelle 3.1 zeigt vier häufige Ereignisse, die zur Erzeugung eines Prozesses füh-ren. In einer Umgebung mit Batch-Betrieb wird ein Prozess als Reaktion auf die Ein-reichung eines Jobs erzeugt. In einer interaktiven Umgebung wird ein Prozesserzeugt, wenn ein neuer Benutzer versucht, sich anzumelden. In beiden Fällen ist dasBetriebssystem für die Erzeugung des neuen Prozesses verantwortlich. Ein Betriebs-system kann darüber hinaus einen Prozess auch im Auftrag einer Anwendung erzeu-gen. Wenn beispielsweise ein Benutzer den Ausdruck einer Datei anfordert, kann dasBetriebssystem einen Prozess erzeugen, der das Drucken regelt. Der anfordernde Pro-zess kann daher ungeachtet der Zeit, die für die Beendigung des Druckens notwen-dig ist, fortfahren.

In der Regel erzeugt das Betriebssystem sämtliche Prozesse auf eine Art undWeise, die für die Benutzer oder das Anwendungsprogramm transparent ist. DieseVorgehensweise findet sich nach wie vor in vielen heutigen Betriebssystemen. Aller-dings kann es nützlich sein, einem Prozess die Erlaubnis zu erteilen, einen anderen


Prozess zu erzeugen. So kann ein Anwendungsprozess beispielsweise einen anderenProzess generieren, um Daten zu empfangen, die die Anwendung generiert, und umdiese Daten in einer Form zu ordnen, die für eine spätere Analyse passend ist. Derneue Prozess läuft parallel zu der Anwendung und wird von Zeit zu Zeit aktiviert,wenn neue Daten verfügbar sind. Diese Vorgehensweise kann für die Strukturierungder Anwendung sehr hilfreich sein. Als weiteres Beispiel kann ein Serverprozess (z.B.Druckserver, Dateiserver) für jede Anforderung, die er behandelt, einen neuen Pro-zess generieren. Wenn das Betriebssystem als Folge einer expliziten Anforderungdurch einen Prozess einen neuen Prozess erzeugt, dann wird diese Vorgehensweiseals Process Spawning bezeichnet.

Wenn ein Prozess einen anderen erzeugt, dann wird Ersterer als Elternprozessund Letzterer als Kindprozess bezeichnet. In der Regel müssen die »verwandten«Prozesse miteinander kommunizieren und kooperieren. Die Erzielung dieser Koope-ration ist eine schwierige Aufgabe für den Programmierer. Dieses Thema wird inKapitel 5 behandelt.

ProzessterminierungTabelle 3.2 fasst die wichtigsten Gründe für die Terminierung von Prozessen zusam-men. Ein Computersystem muss für einen Prozess Mittel bereitstellen, die es ihmermöglichen, seine Beendigung anzuzeigen. Ein Batch Job sollte einen Stoppbefehloder einen expliziten Dienstaufruf des Betriebssystems für die Terminierung beinhal-ten. Im ersten Fall wird der Stoppbefehl einen Interrupt generieren, um das Betriebs-system darauf hinzuweisen, dass ein Prozess beendet wurde. In einem Timesharing-System soll beispielsweise der Prozess für einen bestimmten Benutzer terminiert wer-den, wenn sich der Benutzer abmeldet oder sein Terminal abschaltet. Bei einem PCoder einem Arbeitsplatzrechner könnte ein Benutzer eine Anwendung (z.B. ein Text-verarbeitungs- oder Tabellenkalkulationsprogramm) beenden. All diese Aktionenführen letztendlich zu einer Dienstanforderung an das Betriebssystem, den anfor-dernden Prozess zu terminieren.

Tabelle 3.1 Gründe für die Prozesserzeugung

Neuer Batch Job Das Betriebssystem erhält den Steuerungsstrom für den Batch Job, für gewöhnlich auf Band oder Disket-te. Sobald das Betriebssystem bereit ist, mit der neu-en Aufgabe zu beginnen, wird es die nächste Sequenz der Jobsteuerungsbefehle lesen.

Interaktives Anmelden Ein Benutzer meldet sich an einem Terminal am System an.

Für die Bereitstellung eines Dienstes durch das Betriebs-system erzeugt

Das Betriebssystem kann einen Prozess erzeugen, um im Namen eines Benutzerprogramms eine be-stimmte Funktion auszuüben, ohne dass der Benut-zer warten muss (z.B. ein Prozess für die Drucksteuerung).

Erzeugung durch bereits bestehenden Prozess

Aus Gründen der Modularität oder für eine parallele Ausführung kann ein Benutzerprogramm die Erzeu-gung einer Reihe von Prozessen veranlassen.


Darüber hinaus können eine Reihe von Fehlerbedingungen zur Terminierung einesProzesses führen. In Tabelle 3.2 werden einige der häufig erkannten Bedingungenaufgeführt.3

Und schließlich kann bei einigen Betriebssystemen ein Prozess durch denjenigenProzess terminiert werden, der ihn erzeugt hat, oder die Terminierung erfolgt, wennder Elternprozess selbst terminiert wird.

3 Ein »verzeihendes« Betriebssystem kann es einem Benutzer in einigen Fällen erlauben, die Arbeitnach einem Fehler wieder aufzunehmen, ohne den Prozess zu terminieren. Wenn ein Benutzerbeispielsweise den Zugriff auf eine Datei anfordert und dieser Zugriff verweigert wird, kann dasBetriebssystem den Benutzer ganz einfach darüber informieren, dass der Zugriff verweigert wird,und es dem Prozess dann erlauben fortzufahren.

Tabelle 3.2 Gründe für die Prozessterminierung

Normale Beendigung Der Prozess führt einen Dienstaufruf des Betriebssystems aus, um anzuzeigen, dass er fertig ist.

Überschreitung des Zeitlimits

Der Prozess lief länger als das festgelegte Gesamtzeitlimit. Für den Zeittyp, der gemessen wird, gibt es eine Reihe von Möglichkeiten. Dazu gehören die insgesamt abgelaufene Zeit (»reale Zeit«), die Menge der Zeit, die mit der Ausführung verbracht wurde, und, im Fall eines interaktiven Prozesses, die Menge der Zeit, die seit der letzten Benutzereingabe vergangen ist.

Nicht genügend Speicher verfügbar

Der Prozess benötigt mehr Speicher, als das System bereitstellen kann.

Verletzung von Begrenzungen

Der Prozess versucht, auf einen Speicherort zuzugreifen, für den er keine Zugriffsberechtigung hat.

Schutzfehler Der Prozess versucht, eine Ressource oder eine Datei zu benut-zen, die er nicht benutzen darf, oder er versucht, sie auf falsche Art und Weise zu nutzen, z.B. durch den Versuch, eine schreibge-schützte Datei zu überschreiben.

Arithmetischer Fehler Der Prozess versucht, eine unzulässige Berechnung, wie z.B. die Division durch null, durchzuführen oder Zahlen zu speichern, die größer sind als die Hardware bewältigen kann.

Zeitüberschreitung Der Prozess hat länger als einen festgelegten Maximalwert darauf gewartet, dass ein bestimmtes Ereignis eintritt.

E/A-Fehler Während der Eingabe oder Ausgabe tritt ein Fehler auf, wie z.B. die Unfähigkeit eine Datei zu finden, der Misserfolg beim Lesen oder Schreiben nach einer festgelegten Maximalanzahl von Versu-chen (wenn beispielsweise ein Band einen defekten Bereich auf-weist) oder eine ungültige Operation (wie z.B. das Lesen von einem Zeilendrucker).

Ungültiger Befehl Der Prozess versucht, einen nicht existierenden Befehl auszufüh-ren (häufig das Ergebnis eines Sprungs in einen Datenbereich und der Versuch, Daten als Befehl auszuführen).

➔

➔


3.1.3 Prozessmodell mit fünf ZuständenWenn immer alle Prozesse für die Ausführung bereit wären, wäre das in Abbildung3.4b (s. S. 137) vorgeschlagene Warteschlangenverfahren bereits ausreichend. Bei derWarteschlange handelt es sich um eine FIFO-Liste (First In First Out) und der Prozes-sor arbeitet mit den verfügbaren Prozessen nach dem Round-Robin-Verfahren. (DenProzessen in der Warteschlange wird für die Ausführung eine bestimmte Zeitdauerzugebilligt. Anschließend kehren sie in die Warteschlange zurück oder werden blo-ckiert.) Aber bereits für das beschriebene, einfache Beispiel ist die Implementierungunangemessen: Einige Prozesse im nicht aktiven Zustand sind für die Ausführungbereit, während andere dadurch blockiert sind, dass sie auf die Beendigung einer E/A-Operation warten. Bei der Verwendung einer einzigen Warteschlange kann derDispatcher also nicht einfach den Prozess aus der Warteschlange auswählen, der amlängsten gewartet hat und sich am Ende der Schlange befindet. Vielmehr muss er dieListe nach dem Prozess durchsuchen, der nicht blockiert ist und sich am längsten inder Liste befindet.

Ein natürlicherer Weg für die Handhabung dieser Situation ist die Aufspaltungdes Zustands »nicht aktiv« in die zwei Zustände »bereit« und »blockiert«. Das ist inAbbildung 3.5 dargestellt. Dem Ganzen wurden darüber hinaus zwei weitereZustände hinzugefügt, die sich noch als nützlich erweisen werden. Die folgendenfünf Zustände sind im Diagramm dargestellt:

õ Aktiv: Der Prozess, der zurzeit gerade ausgeführt wird. Für dieses Kapitel gehenwir von einem Computer mit nur einem Prozessor aus, so dass sich zu jedem Zeit-punkt höchstens ein Prozess in diesem Zustand befinden kann.

õ Bereit: Ein Prozess, der ausgeführt werden kann und auf Ausführung wartet.

õ Blockiert: Ein Prozess, der nicht ausgeführt werden kann, solange nicht einbestimmtes Ereignis, wie z.B. die Beendigung einer E/A-Operation, eintritt.

õ Neu: Ein Prozess, der gerade erzeugt wurde, aber vom Betriebssystem noch nichtzur Gruppe der ausführbaren Prozesse zugelassen wurde. Ein neuer Prozesswurde typischerweise noch nicht in den Hauptspeicher geladen.

Tabelle 3.2 Gründe für die Prozessterminierung

Privilegierter Befehl Der Prozess versucht, einen Befehl zu nutzen, der exklusiv für das Betriebssystem reserviert ist.

Falsche Benutzung von Daten

Die Daten sind vom falschen Typ oder nicht initialisiert.

Intervention des Bedieners oder des Betriebssystems

Aus irgendwelchen Gründen terminieren der Bediener oder das Betriebssystem den Prozess (z.B. wenn eine Verklemmung vor-liegt).

Terminierung eines Elternprozesses

Wenn ein Elternprozess terminiert wird, kann das Betriebssystem automatisch alle Kindprozesse des betreffenden Elternprozesses terminieren.

Anforderung durch einen Elternprozess

Ein Elternprozess ist in der Regel berechtigt, jeden seiner Kindpro-zesse zu terminieren.

➔


õ Terminiert: Ein Prozess, der vom Betriebssystem aus der Gruppe der ausführba-ren Prozesse aussortiert wurde, entweder weil er gestoppt hat oder weil er ausirgendeinem Grund abgebrochen wurde.

Die Zustände »neu« und »terminiert« sind nützlich für die Prozessverwaltung. DerZustand »neu« entspricht einem Prozess, der gerade erstellt wurde. Wenn beispiels-weise ein neuer Benutzer versucht, sich in einem Timesharing-System anzumelden,oder wenn ein neuer Batch Job für die Ausführung vorgelegt wird, kann das Betriebs-system einen neuen Prozess in zwei Schritten erstellen. Als Erstes führt das Betriebs-system die üblichen Verwaltungsarbeiten durch. Eine Kennung wird mit dem Pro-zess verknüpft. Tabellen, die für die Verwaltung des Prozesses benötigt werden,werden zugeteilt und aufgebaut. Zu diesem Zeitpunkt befindet sich der Prozess imZustand »neu«. Das bedeutet, dass das Betriebssystem die notwendigen Aktionen fürdie Erzeugung des Prozesses durchgeführt hat, aber noch nicht zur Ausführung desProzesses übergegangen ist. Das Betriebssystem kann beispielsweise bei Erreichender Leistungskapazität oder mangelndem Hauptspeicherplatz die Anzahl der Pro-zesse, die sich im System befinden, einschränken. Während sich ein Prozess imZustand »neu« befindet, werden die vom Betriebssystem benötigten Informationenzum Prozess in Steuerungstabellen im Hauptspeicher bereitgehalten. Der Prozessselbst befindet sich allerdings nicht im Hauptspeicher. Das heißt, dass sich der Codedes auszuführenden Programms nicht im Hauptspeicher befindet und dass denDaten, die mit dem Programm in Zusammenhang stehen, kein Speicherplatz zuge-teilt wurde. Solange sich der Prozess im Zustand »neu« befindet, bleibt das Pro-gramm im Sekundärspeicher, für gewöhnlich im Plattenspeicher.4

Auf ähnliche Art und Weise verlässt ein Prozess ein System in zwei Schritten. AlsErstes wird ein Prozess terminiert, wenn ein natürlicher Terminierungspunkt

Abbildung 3.5 Prozessmodell mit fünf Zuständen

4 Bei der Besprechung in diesem Kapitel wird das Konzept des virtuellen Speichers ignoriert. InSystemen mit Unterstützung für den virtuellen Speicher werden der Programmcode und dieDaten in den virtuellen Speicher geladen, sobald ein Prozess vom Zustand »neu« in den Zustand»bereit« wechselt. Der virtuelle Speicher wurde in Kapitel 2 kurz besprochen. In Kapitel 8 findetsich eine detaillierte Darstellung.


erreicht wurde, wenn er aufgrund eines nicht behebbaren Fehlers abgebrochen wirdoder wenn ein anderer Prozess mit der entsprechenden Berechtigung den Abbruchdes Prozesses herbeiführt. Durch die Terminierung wechselt der Prozess in denZustand »terminiert«. Zu diesem Zeitpunkt ist der Prozess nicht mehr zur Ausfüh-rung berechtigt. Die Tabellen und Informationen, die mit dem Job in Zusammen-hang stehen, werden zeitweilig vom Betriebssystem aufrechterhalten, wodurchHilfs- oder Unterstützungsprogramme die Gelegenheit erhalten, benötigte Informa-tionen zu extrahieren. Ein Abrechnungsprogramm muss zu Buchungszwecken bei-spielsweise die Prozessorzeit und andere durch den Prozess genutzte Ressourcenaufzeichnen. Ein Dienstprogramm muss für Zwecke, die mit der Leistungs- oderNutzungsanalyse in Zusammenhang stehen, z.B. Informationen über die Geschichtedes Prozesses extrahieren. Sobald diese Programme die benötigten Informationenextrahiert haben, braucht das Betriebssystem mit dem Prozess in Verbindung ste-hende Daten nicht mehr aufrechtzuerhalten und der Prozess wird aus dem Systemgelöscht.

In Abbildung 3.5 werden die Ereignisarten aufgeführt, die für einen Prozess zueiner Zustandsänderung führen. Die folgenden Zustandsänderungen sind mög-lich:

õ Null → Neu: Ein neuer Prozess wird für die Ausführung eines Programmserzeugt. Dieses Ereignis tritt aus einem der in Abbildung 3.1 aufgeführten Gründeein.

õ Neu → Bereit: Das Betriebssystem ändert den Zustand eines Prozesses von »neu«in »bereit«, wenn es bereit ist, sich mit einem weiteren Prozess zu befassen. In denmeisten Systemen gibt es eine Beschränkung der Anzahl der bestehenden Pro-zesse oder der Menge des virtuellen Speichers, die für bestehende Prozesse vorge-sehen ist. Durch diese Beschränkung wird gewährleistet, dass durch die Anzahlder Prozesse die Leistung nicht herabgesetzt wird.

õ Bereit → Aktiv: Wenn es Zeit wird, einen neuen Prozess für die Ausführung aus-zuwählen, wählt das Betriebssystem einen der Prozesse aus, die sich im Zustand»bereit« befinden. Die Frage, welcher Prozess genau ausgewählt wird, wird inTeil 4 besprochen.

õ Aktiv → Terminiert: Der gerade aktive Prozess wird durch das Betriebssystemterminiert, wenn der Prozess anzeigt, dass er seine Aufgabe beendet hat, oderwenn er abgebrochen wird.

õ Aktiv → Bereit: Der häufigste Grund für diese Zustandsänderung besteht darin,dass der aktive Prozess die maximal zulässige Zeitdauer für eine unterbrechungs-freie Ausführung erreicht hat. Praktisch alle Mehrprogrammbetriebssysteme ver-hängen diese Art der zeitlichen Beschränkung. Es gibt mehrere alternativeGründe für diese Zustandsänderung, die nicht in allen Betriebssystemen imple-mentiert sind. Wenn das Betriebssystem beispielsweise unterschiedlichen Prozes-sen unterschiedliche Prioritätsstufen zuweist, dann kann ein Prozess verdrängtwerden. Nehmen wir als Beispiel einmal an, Prozess A läuft mit einer gegebenenPrioritätsstufe und Prozess B, der eine höhere Prioritätsstufe hat, ist blockiert.Wenn das Betriebssystem erfährt, dass das Ereignis, auf das Prozess B wartet, ein-getreten ist, wodurch Prozess B in den Zustand »bereit« wechselt, kann es ProzessA unterbrechen und Prozess B starten. Diesen Vorgang bezeichnet man als Unter-


brechung: Das Betriebssystem unterbricht Prozess A.5 Und schließlich kann einProzess auch freiwillig die Kontrolle über den Prozessor abgeben.

õ Aktiv → Blockiert: Ein Prozess wird in den Zustand »blockiert« versetzt, wenn eretwas anfordert, auf das er warten muss. Eine Anfrage an das Betriebssystemerfolgt in der Regel in Form eines Systemdienstaufrufs, d.h. ein Aufruf vom lau-fenden Programm an eine Prozedur, die Teil des Betriebssystemcodes ist. Ein Pro-zess kann beispielsweise einen Dienst vom Betriebssystem anfordern, den dasBetriebssystem nicht sofort erfüllen kann. Er kann eine Ressource, wie z.B. eineDatei oder einen gemeinsam genutzten Bereich des virtuellen Speichers, anfor-dern, die nicht sofort verfügbar ist. Oder der Prozess kann eine Aktion, wie z.B.eine E/A-Operation, initiieren, die erst beendet sein muss, bevor der Prozess fort-fahren kann. Wenn Prozesse miteinander kommunizieren, kann ein Prozessdadurch blockiert werden, dass er auf eine Eingabe oder Nachricht eines anderenProzesses wartet.

õ Blockiert → Bereit: Ein Prozess im Zustand »blockiert« wird in den Zustand»bereit« versetzt, wenn das Ereignis, auf das er gewartet hat, eintritt.

õ Bereit → Terminiert: Diese Zustandsänderung ist im Diagramm nicht dargestellt.In einigen Systemen kann ein Elternprozess einen Kindprozess jederzeit terminie-ren. Auch wenn ein Elternprozess terminiert wird, können alle Kindprozesse, diemit diesem Elternprozess in Zusammenhang stehen, terminiert werden.

õ Blockiert → Terminiert: Für diese Zustandsänderung gelten die Aussagen desvorhergehenden Punkts.

5 Der Ausdruck Unterbrechung (Verdrängung, Preemption) bezieht sich im Allgemeinen auf dieZurückforderung einer Ressource von einem Prozess, bevor der Prozess die Nutzung der Res-source beenden konnte. In diesem Fall ist der Prozessor selbst die Ressource. Der Prozess wirdausgeführt und könnte auch weiterhin ausgeführt werden, aber er wird verdrängt, damit einanderer Prozess ausgeführt werden kann.

Abbildung 3.6 Prozesszustände für den Trace aus Abbildung 3.3


Kehren wir nun zu unserem einfachen Beispiel zurück. Abbildung 3.6 zeigt dieZustandswechsel einzelner Prozesse über die Zeit. In Abbildung 3.7a findet sich eineUmsetzung des Modells mit Warteschlangen. Es gibt hier nur zwei Warteschlangen:eine Warteschlange für bereite Prozesse sowie eine Warteschlange für blockierte Pro-zesse. Wenn ein Prozess in das System hereingelassen wird, wird er in die Warte-schlange für bereite Prozesse eingereiht. Wenn es für das Betriebssystem an der Zeitist, einen neuen Prozess für die Ausführung auszuwählen, wählt es einen Prozess ausder Warteschlange für bereite Prozesse aus. Wenn kein Prioritätsschema gegeben ist,kann es sich hierbei um eine einfache FIFO-Warteschlange (First In First Out) han-

Abbildung 3.7 Warteschlangenmodell aus Abbildung 3.5


deln. Wenn ein aktiver Prozess aus der Ausführung entfernt wird, wird er je nach denUmständen entweder terminiert oder in die Warteschlange der bereiten Prozesseoder in die Warteschlange der blockierten Prozesse eingereiht. Wenn ein Ereignis ein-tritt, auf das einige der Prozesse in der Warteschlange für blockierte Prozesse gewar-tet haben, dann werden diese Prozesse in die Warteschlange für bereite Prozesse ver-schoben.

Letzteres bedeutet, dass das Betriebssystem bei Eintreten eines Ereignisses diegesamte Warteschlange für blockierte Prozesse auf der Suche nach den Prozessendurchforsten muss, die auf dieses Ereignis gewartet hatten. Bei einem großenBetriebssystem können sich in dieser Warteschlange Hunderte oder Tausende vonProzessen befinden. Es wäre daher effizienter, eine ganze Reihe von Warteschlangen,nämlich eine für jedes Ereignis, zu implementieren. Wenn dann das Ereignis eintritt,kann die gesamte Liste der Prozesse in der entsprechenden Warteschlange in denZustand »bereit« versetzt werden (Abbildung 3.7b).

Hier noch eine letzte Verbesserung: Wenn die Zuteilung (Dispatching) der Pro-zesse durch ein Prioritätsschema geregelt wird, wäre es vorteilhaft, mehrere Warte-schlangen für bereite Prozesse zu haben: eine für jede Prioritätsstufe. Das Betriebssys-tem könnte dann leicht feststellen, welches der Prozess im Zustand »bereit« mit derhöchsten Priorität ist, der am längsten wartet.

3.1.4 Suspendierte Prozesse

Die Notwendigkeit des AuslagernsDie drei gerade beschriebenen wesentlichen Zustände (bereit, aktiv, blockiert) ermög-lichen eine systematische Vorgehensweise bei der Modellierung des Verhaltens vonProzessen und dienen als Anleitung für die Implementierung des Betriebssystems.Viele Betriebssysteme verwenden nur diese drei Zustände.

Allerdings gibt es gute Gründe dafür, das Modell mit weiteren Zuständen zuergänzen. Um den Nutzen dieser neuen Zustände zu verdeutlichen, betrachten wirein System ohne virtuellen Speicher. Jeder auszuführende Prozess muss vollständigin den Hauptspeicher geladen werden. Es müssen alle in Abbildung 3.7b dargestell-ten Prozesse aus allen Warteschlangen im Hauptspeicher resident sein.

Erinnern wir uns an dieser Stelle noch einmal daran, dass der Grund für diese dif-ferenzierte Vorgehensweise darin liegt, dass E/A-Aktivitäten wesentlich langsamerals Computerberechnungen sind und sich der Prozessor in einem Einprogrammsys-tem daher die meiste Zeit über im Leerlauf befindet. Aber auch der Vorschlag in Abbil-dung 3.7b kann das Problem nicht vollständig lösen. Es stimmt, dass der Speicher indiesem Fall mehrere Prozesse beinhaltet und dass der Prozessor sich einem anderenProzess zuwenden kann, wenn sich ein Prozess im Wartezustand befindet. Aber derProzessor ist so viel schneller als die Ein-/Ausgabe, dass es wahrscheinlich ist, dassalle Prozesse im Speicher auf eine Ein-/Ausgabe warten. Der Prozessor kann sichdaher selbst im Mehrprogrammbetrieb die meiste Zeit über im Leerlauf befinden.

Was kann man tun? Der Hauptspeicher könnte ausgebaut werden, um mehr Pro-zesse aufnehmen zu können. Es gibt aber zwei Schwachstellen bei diesem Ansatz.Erstens ist eine Vergrößerung des Hauptspeichers mit Kosten verbunden. Bitweisebetrachtet sind diese Kosten zwar gering, aber sie summieren sich, wenn wir überMegabits und Gigabits an Speicherplatz sprechen. Zweitens ist der Bedarf der Pro-gramme nach Speicherplatz im gleichen Maße gewachsen wie die Speicherkosten


gefallen sind. Ein größerer Speicher führt also zu größeren Prozessen und nicht zumehr Prozessen.

Eine andere Lösung ist die Auslagerung (Swapping), bei der ein Teil eines Prozes-ses oder auch ein ganzer Prozess auf die Festplatte verschoben wird. Wenn sich kei-ner der im Hauptspeicher befindlichen Prozesse im Zustand »bereit« befindet, lagertdas Betriebssystem einen der blockierten Prozesse auf die Festplatte in eine Warte-schlange für suspendierte Prozesse aus. Dabei handelt es sich um eine Warteschlangebestehender Prozesse, die zeitweise aus dem Hauptspeicher ausgelagert, also suspen-diert werden. Das Betriebssystem kann dann einen anderen Prozess aus der Warte-schlange für suspendierte Prozesse aufnehmen oder der Anforderung eines neuenProzesses nachkommen. Die Ausführung setzt sich dann mit dem neu hinzugekom-menen Prozess fort.

Die Auslagerung ist allerdings eine E/A-Operation und beinhaltet daher dasPotenzial, das Problem noch weiter zu verschärfen, statt es zu verbessern. Da aber diePlatten-E/A im Allgemeinen die schnellste Ein-/Ausgabe im gesamten System ist(z.B. verglichen mit einer Band- oder Drucker-E/A), wird die Auslagerung die Leis-tung für gewöhnlich verbessern.

Wenn die Auslagerung wie gerade beschrieben verwendet wird, muss dem Pro-zessverhaltensmodell ein weiterer Zustand hinzugefügt werden (Abbildung 3.8a): DerZustand »suspendiert«. Wenn sich alle Prozesse im Hauptspeicher im Zustand »blo-ckiert« befinden, kann das Betriebssystem einen Prozess suspendieren, indem es ihn inden suspendierten Zustand versetzt und auf die Festplatte auslagert. Der so freigewor-dene Platz im Hauptspeicher kann dann für einen anderen Prozess genutzt werden.

Wenn das Betriebssystem eine Auslagerung vorgenommen hat, hat es zwei Mög-lichkeiten für die Auswahl eines Prozesses, der in den Hauptspeicher gebracht werdensoll: Es kann einen neu erzeugten Prozess oder einen zuvor suspendierten Prozessladen. Scheinbar wäre es vorzuziehen, einen zuvor suspendierten Prozess zu laden unddiesen Prozess zu bedienen, anstatt die Gesamtbelastung des Systems zu erhöhen.

Dieser Denkansatz ist allerdings problematisch. Zum Zeitpunkt des Suspendie-rens befanden sich alle suspendierten Prozesse im Zustand »blockiert«. Es wäre mitSicherheit nicht ratsam, einen blockierten Prozess zurück in den Hauptspeicher zuholen, der möglicherweise immer noch nicht bereit für die Ausführung wäre. Aller-dings muss man bedenken, dass jeder suspendierte Prozess ursprünglich blockiertwar, weil er auf ein bestimmtes Ereignis wartete. Wenn dieses Ereignis eintritt, ist derProzess nicht mehr blockiert und eventuell für die Ausführung verfügbar.

Dieser Designaspekt muss also noch einmal überdacht werden. Es gibt dabei zweiunabhängige Konzepte, und zwar die Frage, ob ein Prozess auf ein Ereignis wartet(blockiert oder nicht) und ob ein Prozess aus dem Hauptspeicher ausgelagert wurde(suspendiert oder nicht). Um dieser 2-x-2-Kombination gerecht werden zu können,werden vier Zustände benötigt:

õ Bereit: Der Prozess befindet sich im Hauptspeicher und ist für die Ausführungverfügbar.

õ Blockiert: Der Prozess befindet sich im Hauptspeicher und wartet auf einbestimmtes Ereignis.

õ Blockiert/Suspendiert: Der Prozess befindet sich im Sekundärspeicher und war-tet auf ein bestimmtes Ereignis.

õ Bereit/Suspendiert: Der Prozess befindet sich im Sekundärspeicher, ist aber fürdie Ausführung verfügbar, sobald er in den Hauptspeicher geladen wird.


Bevor wir uns einem Zustandsübergangsdiagramm zuwenden, das diese beidenneuen suspendierten Zustände beinhaltet, muss ein anderer Punkt angesprochenwerden. Bisher wurde davon ausgegangen, dass kein virtueller Speicher verwendetwird und dass sich ein Prozess entweder ganz im Hauptspeicher oder ganz außer-halb des Hauptspeichers befindet. Bei Einsatz eines virtuellen Speichers ist es mög-lich, einen Prozess auszuführen, der sich nur teilweise im Hauptspeicher befindet.Wenn auf eine Prozessadresse verwiesen wird, die sich nicht im Hauptspeicher befin-det, dann kann der passende Teil des Prozesses in den Hauptspeicher gebracht wer-den. Es scheint so, als könnte die Verwendung des virtuellen Speichers die Notwen-digkeit der expliziten Auslagerung vollständig eliminieren, da jede gewünschteAdresse in jedem gewünschten Prozess von der Speicherverwaltungshardware desProzessors in den Hauptspeicher geladen und von dort auch wieder entfernt werdenkann. Wie wir in Kapitel 8 jedoch sehen werden, kann die Leistung eines virtuellenSpeichers kollabieren, wenn es genügend aktive Prozesse gibt, die sich alle teilweiseim Hauptspeicher befinden. Selbst in einem System mit virtuellem Speicher muss dasBetriebssystem zur Erhaltung oder Steigerung der Leistung gegebenenfalls Prozesseexplizit und vollständig auslagern.

Sehen wir uns nun in Abbildung 3.8b das Zustandsübergangsmodell an, das wirentwickelt haben. (Die gestrichelten Linien in der Abbildung zeigen mögliche, abernicht notwendige Zustandsänderungen an.) Die folgenden wichtigen neuenZustandsänderungen sind enthalten:

õ Blockiert → Blockiert/Suspendiert: Wenn es keine bereiten Prozesse gibt, wirdmindestens ein blockierter Prozess ausgelagert, um Platz für einen anderen Pro-zess zu schaffen, der nicht blockiert ist. Diese Zustandsänderung kann sogar dannvollzogen werden, wenn es verfügbare bereite Prozesse gibt, und zwar dann,wenn das Betriebssystem feststellt, dass der gerade aktive Prozess oder ein berei-ter Prozess, dem sich das Betriebssystem gerne zuwenden würde, mehr Haupt-speicher benötigt, um die Leistung angemessen aufrechtzuerhalten.

õ Blockiert/Suspendiert → Bereit/Suspendiert: Ein Prozess im blockierten/sus-pendierten Zustand wird in den bereiten/suspendierten Zustand überführt,wenn das Ereignis eintritt, auf das er gewartet hat. Hierbei ist zu beachten, dassdie Statusinformationen des suspendierten Prozesses für das Betriebssystemzugänglich sein müssen.

õ Bereit/Suspendiert → Bereit: Wenn sich keine bereiten Prozesse im Hauptspei-cher befinden, muss das Betriebssystem einen Prozess in den Hauptspeicherladen, um mit der Ausführung fortfahren zu können. Darüber hinaus kann es derFall sein, dass ein Prozess im bereiten/suspendierten Zustand eine höhere Priori-tät als jeder der bereiten Prozesse hat. In diesem Fall kann der Betriebssystement-wickler festlegen, dass es wichtiger ist, sich dem Prozess mit der höheren Prioritätzuzuwenden als die Auslagerungsvorgänge zu minimieren.

õ Bereit → Bereit/Suspendiert: Normalerweise würde es das Betriebssystem vor-ziehen, eher einen blockierten Prozess und nicht einen bereiten Prozess zu sus-pendieren, da der bereite Prozess nun ausgeführt werden kann, während der blo-ckierte Prozess Hauptspeicherplatz belegt und nicht ausgeführt werden kann. Eskann allerdings notwendig sein, einen bereiten Prozess zu suspendieren, wenndas die einzige Möglichkeit darstellt, einen ausreichend großen Hauptspeicher-block freizusetzen. Darüber hinaus kann sich das Betriebssystem entscheiden,


einen bereiten Prozess mit niedriger Priorität an Stelle eines blockierten Prozessesmit höherer Priorität zu suspendieren, wenn es davon ausgeht, dass der blockierteProzess bald bereit sein wird.

Verschiedene andere Zustandsübergänge sollten ebenfalls in Betracht gezogen wer-den.

õ Neu → Bereit/Suspendiert und Neu → Bereit: Wenn ein neuer Prozess erzeugtwird, kann er entweder zur Warteschlange für bereite Prozesse oder zur Warte-schlange für bereite/suspendierte Prozesse hinzugefügt werden. In jedem Fallmuss das Betriebssystem Tabellen für den Prozess erstellen, um den Prozess zuverwalten, und dem Prozess einen Adressraum zuteilen. Es kann für das Betriebs-system wünschenswert sein, diese Organisationsarbeiten frühzeitig auszuführen,

Abbildung 3.8 Prozesszustandsübergangsdiagramm mit suspendierten Zuständen


so dass es eine große Gruppe von Prozessen beibehalten kann, die nicht blockiertsind. Durch diese Strategie gibt es häufig nur ungenügend Platz im Hauptspei-cher für einen neuen Prozess, was der Grund für die Zustandsänderung (Neu →Bereit/Suspendiert) ist. Andererseits könnte man argumentieren, dass die Just-In-Time-Philosophie, die darauf abzielt, Prozesse so spät wie möglich zu erzeugen,den Steuerungsaufwand für das Betriebssystem reduziert und es dem Betriebs-system ermöglicht, die Erzeugung der Prozesse zu einem Zeitpunkt durchzufüh-ren, an dem das System ohnehin durch blockierte Prozesse verstopft ist.

õ Blockiert/Suspendiert → Blockiert: Diese Zustandsänderung erscheint wie einEntwurfsfehler. Was ist schließlich der Sinn darin, einen Prozess zu laden, dernicht für die Ausführung bereit ist? Aber stellen wir uns einmal das folgende Sze-nario vor: Ein Prozess wird terminiert, wodurch Platz im Hauptspeicher frei wird.In der Warteschlange für blockierte/suspendierte Prozesse befindet sich ein Pro-zess mit einer höheren Priorität als alle Prozesse in der Warteschlange für bereite/suspendierte Prozesse und das Betriebssystem hat Grund anzunehmen, dass dasblockierende Ereignis für diesen Prozess bald eintreten wird. Unter diesenUmständen würde es sinnvoll erscheinen, einem blockierten Prozess beim Ladenin den Hauptspeicher den Vorzug vor einem bereiten Prozess zu geben.

õ Aktiv → Bereit/Suspendiert: Normalerweise wird ein aktiver Prozess in denbereiten Zustand versetzt, wenn die ihm zugeteilte Zeit abläuft. Wenn dasBetriebssystem den Prozess allerdings vorrangig unterbricht, weil gerade die Blo-ckierung eines Prozesses mit höherer Priorität in der Warteschlange für blo-ckierte/suspendierte Prozesse aufgehoben wurde, kann das Betriebssystem denaktiven Prozess direkt in die Warteschlange für bereite/suspendierte Prozesseverschieben und so Platz im Hauptspeicher schaffen.

Verschiedene → Terminiert: In der Regel wird ein Prozess terminiert, während erläuft, und zwar entweder weil er beendet wurde oder weil ein schwerwiegender Feh-ler vorlag. In einigen Betriebssystemen kann ein Prozess allerdings auch durch denje-nigen Prozess terminiert werden, der ihn erzeugt hat, oder er wird terminiert, wennder Elternprozess selbst terminiert wird. Wenn das möglich ist, kann jeder Prozess injedem beliebigen Zustand in den terminierten Zustand überführt werden.

Weitere Anwendungsfälle für das SuspendierenBisher haben wir das Konzept eines suspendierten Prozesses mit dem eines Prozessesgleichgesetzt, der sich nicht im Hauptspeicher befindet. Ein Prozess, der sich nicht imHauptspeicher befindet, ist nicht sofort für die Ausführung bereit und zwar unab-hängig davon, ob er auf ein Ereignis wartet oder nicht.

Wir können das Konzept eines suspendierten Prozesses verallgemeinern. Legenwir fest, dass ein suspendierter Prozess die folgenden Merkmale aufweist:

1. Der Prozess ist nicht sofort für die Ausführung verfügbar.

2. Der Prozess kann auf ein Ereignis warten, muss es aber nicht. Wenn er auf einEreignis wartet, dann ist diese Blockierungsbedingung von der Suspendierungs-bedingung unabhängig und der Eintritt des Blockierungsereignisses gibt den Pro-zess nicht für die Ausführung frei.

3. Der Prozess wurde durch einen Agenten in den suspendierten Zustand versetzt.Dieser Agent kann entweder er selbst, ein Elternprozess oder auch das Betriebs-system selbst sein, wenn es die Ausführung des Prozesses verhindern möchte.


4. Der Prozess kann diesen Zustand erst verlassen, wenn der Agent dies explizitanordnet.

In Tabelle 3.3 sind einige der Gründe für das Suspendieren eines Prozesses aufge-führt. Einer der Gründe, den wir bereits besprochen haben, ist die Notwendigkeit,einen Prozess auf die Festplatte auszulagern, um das Laden eines bereiten Prozesseszu ermöglichen oder um einfach die Belastung des virtuellen Speichersystems zureduzieren, so dass den verbleibenden Prozessen mehr Hauptspeicherplatz zur Ver-fügung steht. Das Betriebssystem hat möglicherweise noch andere Beweggründe fürdie Suspendierung eines Prozesses. So kann beispielsweise ein Audit-Prozess oderein Protokollierungsprozess eingesetzt werden, um die Aktivitäten im System zuüberwachen. Der Prozess kann dazu verwendet werden, den Nutzungsgrad der ver-schiedenen Ressourcen (Prozessor, Speicher, Kanäle) und die Fortschrittsgeschwin-digkeit der Benutzerprozesse im System zu dokumentieren. Gesteuert von einemBediener kann das Betriebssystem diesen Prozess von Zeit zu Zeit aktivieren unddeaktivieren. Wenn das Betriebssystem ein Problem erkennt oder vermutet, kann eseinen Prozess suspendieren. Ein Beispiel hierfür ist die Verklemmung, die in Kapitel6 besprochen wird. Im Fall eines anderen Beispiels wird in einer Kommunikationslei-tung ein Problem erkannt und der Bediener veranlasst das Betriebssystem, den Pro-zess, der die Leitung gerade nutzt, zu suspendieren, während einige Tests durchge-führt werden.

Andere Gründe betreffen die Aktionen eines interaktiven Benutzers. Wenn einBenutzer beispielsweise einen Defekt in einem Programm vermutet, kann er den Feh-ler beheben, indem er die Ausführung des betreffenden Programms suspendiert, dasProgramm oder die Daten untersucht oder verändert und anschließend die Ausfüh-rung wieder aufnimmt. Möglicherweise gibt es auch einen Hintergrundprozess, dereine Trace oder Buchungsstatistiken aufzeichnet, den der Benutzer gerne aktivierenund deaktivieren möchte.

Tabelle 3.3 Gründe für die Prozesssuspendierung

Auslagerung/Swapping Das Betriebssystem muss ausreichend Hauptspeicherplatz freimachen, um einen Prozess aufnehmen zu können, der für die Ausführung bereit ist.

Andere Betriebssystem-gründe

Das Betriebssystem kann einen Hintergrund- oder Hilfs-prozess oder einen Prozess, von dem angenommen wird, dass er ein Problem verursacht, suspendieren.

Interaktive Benutzer-anforderungen

Ein Benutzer möchte aus Gründen der Fehlerbehebung oder in Zusammenhang mit der Nutzung einer Ressource die Ausführung eines Programms suspendieren.

Timing Ein Prozess (z.B. ein Buchungsprozess oder ein Prozess für die Systemüberwachung) kann periodisch ausgeführt und bis zum nächsten Nutzungsintervall suspendiert werden.

Anforderung durch einen Elternprozess

Ein Elternprozess möchte die Ausführung eines von ihm abstammenden Kindprozesses suspendieren, um den sus-pendierten Prozess zu untersuchen oder zu verändern oder um die Aktivitäten mehrerer Kindprozesse zu koordinieren.


Auch Überlegungen zum Timing können zu einer Auslagerungsentscheidung füh-ren. Wenn ein Prozess beispielsweise periodisch aktiviert werden soll, die meiste Zeitüber aber im Leerlauf ist, dann sollte dieser Prozess zwischen den Benutzungsinter-vallen ausgelagert werden. Ein Beispiel hierfür wäre ein Programm, das die System-nutzung oder die Benutzeraktivitäten überwacht.

Zu guter Letzt kann auch ein Elternprozess einen von ihm abstammenden Prozesssuspendieren. Prozess A erzeugt beispielsweise Prozess B, der eine Datei lesen soll.Prozess B entdeckt einen Fehler in der Dateileseprozedur und meldet dies Prozess A.Prozess A setzt Prozess B aus, um die Ursache zu untersuchen.

In all diesen Fällen wird die Aktivierung eines suspendierten Prozesses von demAgenten angefordert, der ursprünglich die Suspendierung angefordert hat.

3.2 ProzessbeschreibungDas Betriebssystem steuert die Ereignisse innerhalb eines Computersystems. Es plantden Ablauf von Prozessen und übernimmt die Zuteilung der Prozesse für die Aus-führung durch den Prozessor, es weist Prozessen Ressourcen zu und es reagiert aufAnforderungen nach grundlegenden Diensten durch Benutzerprogramme. Grund-sätzlich kann man sich das Betriebssystem als die Einheit vorstellen, die die Verwen-dung der Systemressourcen durch Prozesse regelt.

Dieses Konzept wird in Abbildung 3.9 dargestellt. In einer Mehrprogrammbe-triebsumgebung gibt es mehrere Prozesse (P1…Pn), die erzeugt wurden und sich imvirtuellen Speicher befinden. Während der Ausführung benötigen die ProzesseZugriff auf bestimmte Systemressourcen, wie den Prozessor, E/A-Geräte und denHauptspeicher. In der Abbildung läuft Prozess P1. Zumindest ein Teil des Prozessesbefindet sich im Hauptspeicher und der Prozess hat zwei E/A-Geräte unter seinerKontrolle. Prozess P2 befindet sich ebenfalls im Hauptspeicher, ist aber blockiert, weiler auf ein E/A-Gerät wartet, das P1 zugeteilt wurde. Prozess Pn wurde ausgelagertund daher suspendiert.

Die Details der Verwaltung dieser Ressourcen durch das Betriebssystem im Inter-esse der Prozesse werden später im Verlauf dieses Kapitels untersucht. Hier befassenwir uns mit einer grundlegenderen Frage: Welche Informationen benötigt dasBetriebssystem, um die Prozesse zu steuern und die Ressourcen für sie zu verwalten?

Abbildung 3.9 Prozesse und Ressourcen (Ressourcenzuteilung als Momentaufnahme

3.2 Prozessbeschreibung 153

3.2.1 Steuerungsstrukturen des BetriebssystemsWenn das Betriebssystem Prozesse und Ressourcen verwalten soll, dann benötigt esInformationen über den aktuellen Zustand der einzelnen Prozesse und Ressourcen.Der Universalansatz für die Bereitstellung dieser Informationen ist einfach und nahe-liegend: Das Betriebssystem erstellt und pflegt Informationstabellen für jede Einheit,die es verwaltet. Abbildung 3.10 vermittelt einen Eindruck vom Umfang dieser Auf-gabe. Gezeigt werden vier verschiedene Arten von Tabellen, die vom Betriebssystemverwaltet werden, eine für den Speicher, eine für die Ein-/Ausgabe, eine für Dateienund eine für Prozesse. Auch wenn sich diese Einzelheiten von Betriebssystem zuBetriebssystem unterscheiden werden, so verwalten doch alle Betriebssysteme Infor-mationen in diesen vier Kategorien.

Speichertabellen werden verwendet, um sowohl die Nutzung des Hauptspei-chers (Realspeichers) als auch des Sekundärspeichers (virtuellen Speichers) zu erfas-sen. Ein Teil des Hauptspeichers ist für die Nutzung durch das Betriebssystem reser-viert, der Rest steht den Prozessen zur Verfügung. Prozesse werden imSekundärspeicher vorgehalten, indem eine Variante des virtuellen Speichers oder eineinfacher Auslagerungsmechanismus eingesetzt wird. Die Speichertabellen müssendie folgenden Informationen enthalten:

õ Die Zuteilung von Hauptspeicher zu Prozessen.

õ Die Zuteilung von Sekundärspeicher zu Prozessen.

õ Schutzattribute von Blöcken des Hauptspeichers oder des virtuellen Speichers,wie beispielsweise Angaben dazu, welche Prozesse auf gewisse, gemeinsamgenutzte Speicherregionen zugreifen dürfen.

õ Informationen für die Verwaltung des virtuellen Speichers.

Die Informationsstrukturen für die Speicherverwaltung werden detailliert in Teil 3besprochen.

E/A-Tabellen werden vom Betriebssystem für die Verwaltung der E/A-Geräteund der Kanäle des Computersystems verwendet. Zu jedem beliebigen Zeitpunktkann ein E/A-Gerät entweder verfügbar oder einem bestimmten Prozess zugeteiltsein. Wenn gerade eine E/A-Operation durchgeführt wird, muss das Betriebssystemden Status der E/A-Operation und die Stelle im Hauptspeicher kennen, die alsQuelle oder Ziel für die E/A-Übertragung dient. Die E/A-Verwaltung wird in Kapi-tel 11 behandelt.

Das Betriebssystem kann außerdem Dateitabellen verwalten. Die Tabellen enthal-ten Informationen über die Existenz von Dateien, ihren Speicherort im Sekundärspei-cher, deren aktuellen Status und andere Attribute. Viele, wenn nicht sogar alle dieseInformationen können auch durch ein Dateiverwaltungssystem unterhalten und vonihm genutzt werden. In diesem Fall hat das Betriebssystem nur geringe oder über-haupt keine Kenntnisse über die Dateien. In anderen Betriebssystemen wiederumwerden viele der Einzelheiten der Dateiverwaltung durch das Betriebssystem selbstgehandhabt. Dieses Thema wird in Kapitel 12 besprochen.

Darüber hinaus muss das Betriebssystem Prozesstabellen verwalten, um die Pro-zesse verwalten zu können. Der restliche Teil dieses Abschnitts widmet sich derUntersuchung der benötigten Prozesstabellen. Bevor wir uns diesem Thema zuwen-den, müssen noch zwei weitere Punkte angesprochen werden. Erstens: Obwohl inAbbildung 3.10 vier unterschiedliche Gruppen von Tabellen dargestellt sind, muss


klar sein, dass diese Tabellen auf irgendeine Art und Weise miteinander verkettetoder durch Querverweise miteinander verbunden sein müssen. Der Speicher, die Ein- /Ausgabe und Dateien werden im Interesse der Prozesse verwaltet. Es muss also inden Prozesstabellen entweder direkt oder indirekt irgendeinen Verweis auf diese Res-sourcen geben. Auf die in der Dateitabelle aufgeführten Dateien kann mittels einesE/A-Geräts zugegriffen werden und die Dateien befinden sich zeitweise entwederim Hauptspeicher oder im virtuellen Speicher. Das Betriebssystem muss Zugriff aufdie Tabellen selbst haben, die daher der Speicherverwaltung unterliegen.

Zweitens: Woher weiß das Betriebssystem überhaupt, wie es die Tabellen erstellenkann? Es ist klar, dass das Betriebssystem zumindest einige Kenntnisse über diegrundlegende Umgebung haben muss. Es muss beispielsweise wissen, wie groß derHauptspeicher ist, welche E/A-Geräte vorhanden sind, wie deren Kennungen lautenusw. Das ist eine Frage der Konfiguration. Das Betriebssystem muss also, wenn es ini-tialisiert wird, Zugriff auf Konfigurationsdaten haben, die die grundlegende Umge-bung definieren. Diese Daten müssen außerhalb des Betriebssystems, mit menschli-cher Hilfe oder unter Einsatz einer Autokonfigurationssoftware erstellt werden.

Abbildung 3.10 Allgemeine Struktur der Betriebssystemkontrolltabellen


3.2.2 ProzesskontrollstrukturenEs ist zu bedenken, was ein Betriebssystem alles wissen muss, wenn es einen Prozessverwalten und steuern soll. Es muss erstens wissen, wo sich der Prozess befindet,und zweitens die Attribute des Prozesses kennen, die für die Verwaltung des Prozes-ses wichtig sind (z.B. Prozesskennung, Prozesszustand, Speicherort).

ProzessspeicherortBevor wir uns der Frage zuwenden können, wo sich ein Prozess befindet oder wasseine Attribute sind, müssen wir uns zunächst mit einer noch viel grundlegenderenFrage beschäftigen: Was ist die physikalische Manifestation eines Prozesses? AlsMinimum muss ein Prozess ein oder mehrere Programme enthalten, die ausgeführtwerden sollen. Mit diesen Programmen hängen eine Reihe von Datenorten für lokaleund globale Variablen und definierte Konstanten zusammen. Ein Prozess umfasstalso mindestens genug Speicher, um die Programme und Daten des Prozesses auf-nehmen zu können. Darüber hinaus beinhaltet die Ausführung eines Programms inder Regel einen Stapel (siehe Anhang 1B), der verwendet wird, um die Prozedurauf-rufe und Parameterübergaben innerhalb der Prozeduren im Auge zu behalten. Undschließlich verfügt jeder Prozess über eine Reihe von Attributen, die durch dasBetriebssystem für die Prozesssteuerung eingesetzt werden. Diese Attributsammlungwird für gewöhnlich als Prozesskontrollblock (Process Control Block, PCB) bezeich-net.6 Die Sammlung der Programme, Daten, Stapel und Attribute ist unter demNamen Prozessabbild bekannt (Tabelle 3.4).

Der Speicherort eines Prozessabbilds hängt vom verwendeten Speicherverwaltungs-verfahren ab. Im einfachsten Fall wird das Prozessabbild in Form eines zusammen-hängenden, fortlaufenden Speicherblocks unterhalten. Dieser Block wird im Sekun-

6 Andere weit verbreitete Bezeichnungen für diese Datenstruktur lauten Aufgabensteuerblock(Task Control Block), Prozessdeskriptor (Process Descriptor) und Aufgabendeskriptor (TaskDescriptor).

Tabelle 3.4 Typische Elemente eines Prozessabbilds

BenutzerdatenDer veränderbare Teil des Benutzerraums. Kann Programmdaten, einen Benutzerstapel-bereich und Programme, die verändert werden können, enthalten.

BenutzerprogrammDas auszuführende Programm.

SystemstapelMit jedem Prozess wird mindestens ein LIFO-Systemstapel (Last In First Out) verknüpft. Ein Stapel wird verwendet, um Parameter und Aufrufadressen für Prozeduren und Sys-temaufrufe zu speichern.

ProzesskontrollblockDie vom Betriebssystem für die Steuerung des Prozesses benötigten Daten (siehe Tabelle 3.6).


därspeicher, für gewöhnlich eine Festplatte, vorgehalten. Damit das Betriebssystemden Prozess verwalten kann, muss zumindest ein kleiner Teil des Prozessabbilds inden Hauptspeicher oder zumindest in den Sekundärspeicher geladen werden. DasBetriebssystem muss also den Speicherort jedes Prozesses auf der Festplatte sowie imFall von Prozessen, die sich im Hauptspeicher befinden, den Speicherort des Prozes-ses im Hauptspeicher kennen. Eine etwas komplexere Variation dieses Verfahrenswurde in Kapitel 2 in Zusammenhang mit dem Betriebssystem CTTS beschrieben.Wenn in CTTS ein Prozess ausgelagert wird, kann ein Teil des Prozessabbilds imHauptspeicher verbleiben. Das Betriebssystem muss daher berücksichtigen, welcheTeile des Abbilds der verschiedenen Prozesse sich nach wie vor im Hauptspeicherbefinden.

Die meisten modernen Betriebssysteme verwenden ein Speicherverwaltungsver-fahren, bei dem ein Prozessabbild aus einer Reihe von Blöcken besteht, die nichtzusammenhängend abgespeichert werden müssen. Je nach verwendetem Verfahrenkönnen diese Blöcke von variabler Länge (so genannte Segmente) oder von festerLänge (so genannte Seiten) sein bzw. eine Kombination aus beiden Möglichkeitenaufweisen. In jedem Fall ermöglichen es derartige Verfahren dem Betriebssystem, nureinen Teil eines bestimmten Prozesses in den Hauptspeicher zu laden. Zu jedembeliebigen Zeitpunkt kann daher ein Teil des Prozessabbilds im Hauptspeicher vor-liegen, während sich der Rest im Sekundärspeicher befindet.7 Die vom Betriebssys-tem verwalteten Prozesstabellen müssen daher den Speicherort jedes Segments und/oder jeder Seite jedes Prozessabbilds angeben.

In Abbildung 3.10 wird die Struktur der Speicherortinformation auf die folgendeArt und Weise dargestellt. Es gibt eine primäre Prozesstabelle mit einem Eintrag fürjeden Prozess. Jeder Eintrag enthält mindestens einen Zeiger auf das Prozessabbild.Wenn das Prozessabbild über mehrere Blöcke verfügt, ist diese Information direkt inder primären Prozesstabelle enthalten oder über Querverweise auf Einträge in Spei-chertabellen verfügbar. Diese Darstellung ist generisch. Jedes Betriebssystem ordnetdie Speicherortinformation auf eine eigene Art und Weise an.

ProzessattributeEin komplexes Betriebssystem benötigt zahlreiche Informationen über jeden einzel-nen Prozess. Wie bereits erklärt wurde, liegen diese Informationen in Form eines Pro-zesskontrollblocks vor. Je nach System sind die Informationen auf unterschiedlicheArt und Weise angeordnet. Am Ende dieses Kapitels und am Ende des nächstenKapitels werden mehrere Beispiele beschrieben. An dieser Stelle beschränken wir unsdarauf, die Art der Informationen, die für das Betriebssystem von Nutzen sein kön-nen, zu untersuchen, ohne dabei detailliert darauf einzugehen, wie diese Informatio-nen angeordnet sein mögen.

In Tabelle 3.5 werden typische Informationskategorien aufgeführt, die vomBetriebssystem für jeden Prozess benötigt werden. Die Menge der Informationen

7 In dieser kurzen Besprechung werden einige Details nur kurz angesprochen. In einem System,das den virtuellen Speicher einsetzt, befindet sich das gesamte Prozessabbild eines aktiven Pro-zesses stets im Sekundärspeicher. Wenn ein Teil des Abbilds in den Hauptspeicher geladen wird,dann wird dieser Teil eher kopiert und nicht wirklich verschoben. Der Sekundärspeicher enthältalso eine Kopie aller Segmente und/oder Seiten. Wenn allerdings der Hauptspeicherteil desAbbilds verändert wird, ist die im Sekundärspeicher befindliche Kopie so lange veraltet, bis derHauptspeicherteil zurück auf die Festplatte kopiert wird.


mag dabei überraschen. Je mehr Kenntnisse der Verantwortungsbereiche desBetriebssystems sich der Leser jedoch aneignet, umso verständlicher erscheint dieListe.

Tabelle 3.5 Typische Elemente eines Prozesskontrollblocks

Prozessidentifikation

Kennungen

Numerische Kennungen, die zusammen mit dem Prozesskontrollblock abgespeichertwerden beinhalten:

õ die Kennung des Prozessesõ die Kennung des Prozesses, der diesen Prozess erzeugt hat (Elternprozess)õ die Benutzerkennung

Prozessorstatusinformationen

Für den Benutzer sichtbare Register

Ein für den Benutzer sichtbares Register ist ein Register, auf das mit Hilfe der Maschi-nensprache, die der Prozessor ausführt, Bezug genommen werden kann. In der Regelgibt es zwischen acht und 32 dieser Register, obwohl einige RISC-Implementierungenmehr als 100 dieser Register aufweisen können.

Steuer- und Statusregister

Es gibt eine Vielzahl von Prozessorregistern, die für die Steuerung des Prozessorbe-triebs eingesetzt werden:

õ Programmzähler: Enthält die Adresse des nächsten abzurufenden Befehlsõ Zustandscodes: Ergebnis der letzten arithmetischen oder logischen Operation (z.B.

Vorzeichen, null, Übertrag, gleich, Überlauf)õ Statusinformationen: Beinhaltet Flags für die Freischaltung/Sperrung von Inter-

rupts, Ausführungsmodus.

Stapelzeiger

Mit jedem Prozess hängen ein oder mehrere LIFO-Systemstapel (Last In First Out)zusammen. Ein Stapel wird für die Speicherung von Parametern und Aufrufadressen fürProzeduren und Systemaufrufe verwendet. Der Stapelzeiger zeigt auf das oberste Ele-ment des Stapels.

Prozesskontrollinformationen

Scheduling und Zustandsinformationen

Das Betriebssystem benötigt diese Informationen, um seine Ablaufplanungsfunktion ausü-ben zu können. Typische Informationselemente beinhalten:

õ Prozesszustand: Der Prozesszustand bestimmt, inwiefern ein Prozess bereit ist, fürdie Ausführung eingeplant zu werden (z.B. aktiv, bereit, wartend, gestoppt).

õ Priorität: Ein oder mehrere Felder können für die Beschreibung der Ablaufplanungs-priorität des Prozesses verwendet werden. In einigen Systemen werden mehrereWerte benötigt (z.B. Vorgabewert, aktueller Wert, Maximalwert).

➔

➔


Die Informationen im Prozesskontrollblock lassen sich in drei allgemeine Kategorieneinteilen:

õ Prozessidentifikation

õ Prozessorstatusinformationen

õ Prozesskontrollinformationen

Zur Prozessidentifikation lässt sich sagen, dass in praktisch allen Betriebssystemendem Prozess eine eindeutige numerische Kennung zugewiesen wird, bei der es sicheinfach um einen Index in der primären Prozesstabelle handeln kann (Abbildung3.10). Andernfalls muss es eine Zuordnung geben, die es dem Betriebssystem ermög-licht, die entsprechenden Tabellen anhand der Prozesskennung zu lokalisieren. DieseKennung ist auf mehrere Arten nützlich. Viele der anderen vom Betriebssystem

Tabelle 3.5 Typische Elemente eines Prozesskontrollblocks (Forts.)

õ Ablaufplanungsrelevante Informationen: Diese Informationen hängen vom verwen-deten Scheduling-Verfahren ab, z.B. die Zeitdauer, die der Prozess gewartet hat,und die Zeitdauer, seit der Prozess zuletzt ausgeführt wurde.

õ Ereignis: Identität des Ereignisses, auf das der Prozess wartet, bevor er wieder auf-genommen werden kann.

Datenstrukturierung

Ein Prozess kann mit einem anderen Prozess in einer Warteschlange, einem Ring odereiner anderen Struktur verbunden sein. So können beispielsweise alle Prozesse, dieauf eine bestimmte Prioritätsebene warten, in einer Warteschlange verkettet sein. EinProzess kann mit einem anderen Prozess in einer Eltern-Kind-Beziehung (Erzeuger-Erzeugnis-Beziehung) stehen. Der Prozesskontrollblock kann Zeiger auf andere Pro-zesse enthalten, um diese Struktur zu unterstützen.

Interprozesskommunikation

Verschiedene Flags, Signale und Nachrichten können mit der Kommunikation zwischenzwei unabhängigen Prozessen in Zusammenhang stehen. Einige oder sämtliche dieserInformationen können im Prozesskontrollblock enthalten sein.

Prozessprivilegien

Prozessen werden Privilegien in Form von Speicherplatz, auf den zugegriffen werdenkann, und in Form der Befehlsarten zugestanden, die ausgeführt werden können. Dar-über hinaus können sich die Privilegien auch auf die Nutzung von Systemhilfsprogram-men und Diensten erstrecken.

Speicherverwaltung

Dieser Bereich beinhaltet Zeiger auf Segment- und/oder Seitentabellen, die den vir-tuellen Speicher beschreiben, der diesem Prozess zugeteilt wurde.

Ressourcenbesitz und Ressourcennutzung

Vom Prozess kontrollierte Ressourcen können, beispielsweise in Form von geöffnetenDateien, angezeigt werden. Darüber hinaus kann eine zeitliche Aufzeichnung der Nut-zung des Prozessors oder anderer Ressourcen enthalten sein. Diese Informationenwerden vom Scheduler benötigt.

➔


gesteuerten Tabellen können Prozesskennungen für Querweise in Prozesstabellennutzen. Die Speichertabellen können beispielsweise so aufgebaut sein, dass sie einAbbild des Speichers darstellen mit einem Hinweis darauf, welcher Prozess welchemSpeicherbereich zugeteilt ist. Ähnliche Bezüge gibt es auch in E/A- und Dateitabel-len. Wenn Prozesse miteinander kommunizieren, informiert die Prozesskennung dasBetriebssystem über das Ziel einer bestimmten Kommunikation. Wenn Prozesseandere Prozesse erzeugen können, zeigen Kennungen den Elternprozess und dieKindprozesse eines jeden Prozesses an.

Zusätzlich zu diesen Prozesskennungen kann einem Prozess auch eine Benutzer-kennung zugewiesen werden, die den für den Job verantwortlichen Benutzer anzeigt.

Die Prozessorstatusinformationen bestehen aus den Inhalten der Prozessorregis-ter. Während ein Prozess aktiv ist, befinden sich die Informationen natürlich in denRegistern. Wird ein Prozess gestoppt, müssen die gesamten Registerinformationengesichert werden, so dass sie sich wiederherstellen lassen, wenn der Prozess zueinem späteren Zeitpunkt seine Ausführung wieder aufnimmt. Die Art und dieAnzahl der daran beteiligten Register hängt vom Aufbau des Prozessors ab. In derRegel enthält der Registersatz für den Benutzer sichtbare Register, Steuer- undStatusregister sowie Stapelzeiger. Eine Beschreibung dieser Register findet sich inKapitel 1.

Von besonderer Wichtigkeit ist, dass alle Prozessoren ein Register oder einen Satzvon Registern enthalten, der häufig als Programmstatuswort (PSW) bezeichnet wirdund die Statusinformationen enthält. Das PSW enthält normalerweise dieZustandscodes sowie weitere Statusinformationen. Ein gutes Beispiel für ein Pro-grammstatuswort ist das auf Pentium-Rechnern vorhandene Programmstatuswort,bekannt unter dem Namen EFLAGS-Register (dargestellt in Abbildung 3.11 undTabelle 3.6). Dieser Aufbau wird von jedem Betriebssystem (inklusive UNIX undWindows NT) verwendet, das auf einem Pentium-Computer läuft.

Die dritte große Informationskategorie im Prozesskontrollblock sei zur Abgren-zung als Prozesskontrollinformation bezeichnet. Es handelt sich hierbei um diezusätzlichen Informationen, die das Betriebssystem für die Steuerung und die Koor-

Abbildung 3.11 Pentium II EFLAGS-Register


Tabelle 3.6 Pentium EFLAGS-Registerbits

SteuerungsbitsAP (Alignment, Anordnungsprüfung)Wird gesetzt, wenn ein Wort oder Doppel-wort auf einer Nichtwort- oder Nichtdoppel-wortgrenze adressiert wird.

ID (Identifikations-Flag)Wenn dieses Bit gesetzt und gelöscht wer-den kann, unterstützt der Prozessor den CPUID-Befehl. Dieser Befehl liefert Informa-tionen über den Händler, die Produktfamilie und das Modell.

WF (Resume, Wiederaufnahme-Flag)Dieses Flag ermöglicht es dem Programmie-rer, Fehlerbehebungsausnahmen zu sper-ren, so dass der Befehl nach einer Fehlerbehebungsausnahme neu gestartet werden kann, ohne dass sofort eine weitere Fehlerbehebungsausnahme hervorgerufen wird.

EAPE (E/A-Privilegebene)Wenn dieses Bit gesetzt wird, wird der Pro-zessor veranlasst, eine Ausnahme auf alle Zugriffe auf E/A-Geräte während des Be-triebs im geschützten Modus zu generieren.

RF (Richtungs-Flag)Dieses Bit bestimmt, ob Zeichenkettenver-arbeitungsbefehle den Wert der 16-Bit-Teil-register SI und DI (für 16-Bit-Operationen) oder der 32-Bit-Register ESI und EDI (für 32-Bit-Operationen) erhöhen oder erniedri-gen.

IF (Interrupt-Freischaltungs-Flag)Wenn dieses Bit gesetzt wird, erkennt der Prozessor externe Interrupts.

TF (Trap-Flag)Wenn dieses Bit gesetzt wird, wird nach der Ausführung jedes einzelnen Befehls ein In-terrupt generiert. Es wird bei der Fehlersu-che und Fehlerbehebung eingesetzt (Debugging).

BetriebsmodusbitsVT (verschachteltes Task-Flag, Nesting)Zeigt an, dass der aktuelle Task mit einem anderen Task im geschützten Modus ver-schachtelt ist.

VM (virtueller 8086er Modus)Ermöglicht es dem Programmierer, den vir-tuellen 8086er Modus freizuschalten oder zu sperren, wodurch festgelegt wird, ob der Prozessor als 8086er läuft.

AVI (anstehender virtueller Interrupt)Wird im 8086er Modus verwendet, um an-zuzeigen, dass ein oder mehrere Interrupts darauf warten, bedient zu werden.

VIF (virtuelles Interrupt-Flag)Wird im virtuellen 8086er Modus an Stelle von IF verwendet.

ZustandscodesHF (Hilfsübertrags-Flag)Repräsentiert den positiven oder negativen Übertrag zwischen Halbbytes einer arithme-tischen oder logischen Operation von 8 Bit unter Verwendung des AL-Registers.

ÜTF (Übertrags-Flag)Zeigt den positiven oder negativen Übertrag an die höchstwertige Bitstelle nach einer arithmetischen Operation. Wird durch einige der Verschiebungs- und Rotationsoperatio-nen verändert.

ÜLF (Überlauf-Flag)Zeigt einen arithmetischen Überlauf nach ei-ner Addition oder Subtraktion an.

PF (Paritäts-Flag)Parität des Ergebnisses einer arithmeti-schen oder logischen Operation. 1 steht für gerade Parität, 0 für ungerade Parität.

VF (Vorzeichen-Flag)Zeigt das Vorzeichen des Ergebnisses einer arithmetischen oder logischen Operation an.

NF (Null-Flag)Zeigt an, dass das Ergebnis einer arithmeti-schen oder logischen Operation null lautet.


dinierung der verschiedenen aktiven Prozesse benötigt. Im letzten Teil von Tabelle 3.5wird der Umfang dieser Informationen deutlich. Bei der Untersuchung der Detailsder Betriebssystemfunktionalität in den nachfolgenden Kapiteln wird die Notwen-digkeit der verschiedenen Elemente der Liste deutlicher werden.

In Abbildung 3.12 wird die Struktur von Prozessabbildern im virtuellen Speicherdargestellt. Jedes Prozessabbild besteht aus einem Prozesskontrollblock, einemBenutzerstapel, dem privaten Adressraum des Prozesses und anderen Adressräu-men, die sich der Prozess mit anderen Prozessen teilt. In der Abbildung erscheintjedes Prozessabbild als ein zusammenhängender Adressbereich. In echten Implemen-tierungen ist dies möglicherweise nicht der Fall. Das hängt vom verwendeten Spei-cherverwaltungsverfahren und der Organisation von Steuerstrukturen durch dasBetriebssystem ab.

Wie in Tabelle 3.5 dargestellt ist, kann der Prozesskontrollblock Strukturierungsin-formationen enthalten, in denen sich auch Zeiger befinden können, die das Verkettenvon Prozesskontrollblöcken ermöglichen. Die Warteschlangen, die im vorhergehen-den Abschnitt beschrieben wurden, ließen sich also in Form einer verketteten Listevon Prozesskontrollblöcken implementieren. So könnte beispielsweise die Warte-schlangenstruktur in Abbildung 3.7a wie in Abbildung 3.13 vorgeschlagen imple-mentiert werden.

Abbildung 3.12 Benutzerprozesse im virtuellen Speicher


Die Rolle des ProzesskontrollblocksDer Prozesskontrollblock stellt die wichtigste Datenstruktur in einem Betriebssystemdar. Ein Prozesskontrollblock enthält sämtliche Informationen über einen Prozess, dievom Betriebssystem benötigt werden. Die Blöcke werden von praktisch jedem Modulim Betriebssystem, d.h. auch von den Modulen, die mit der Ablaufplanung, der Res-sourcenzuteilung, der Interrupt-Verarbeitung sowie der Leistungsüberwachung und-analyse in Zusammenhang stehen, gelesen und/oder verändert. Man kann sagen,der Satz der Prozesskontrollblöcke bestimmt den Zustand des Betriebssystems.

Das wirft eine wichtige Designfrage auf. Zahlreiche Routinen innerhalb desBetriebssystems benötigen Zugriff auf Informationen in den Prozesskontrollblöcken.Einen direkten Zugriff auf diese Tabellen zu ermöglichen, ist nicht schwierig. JedemProzess wird eine eindeutige Kennung zugewiesen, die als ein Index für eine Tabellevon Zeigern auf die Prozesskontrollblöcke verwendet werden kann. Die Schwierig-keit liegt nicht im Zugriff, sondern vielmehr im Schutz. In diesem Zusammenhangzeigen sich zwei Probleme:

õ Ein Fehler in einer Einzelroutine, wie z.B. einem Interrupt-Handler, kann Prozess-kontrollblöcke beschädigen, wodurch es für das System unmöglich wird, diebetroffenen Prozesse zu verwalten.

õ Eine Designänderung in der Struktur oder Semantik des Prozesskontrollblockskönnte mehrere Module im Betriebssystem betreffen.

Abbildung 3.13 Strukturen von Prozesslisten

3.3 Prozesssteuerung 163

Diese Probleme werden vermieden, wenn Lese- und Schreibzugriffe auf Prozesskon-trollblöcke nur mit Hilfe eines speziellen Handlers möglich sind, der Zugriffe kon-trolliert und Prozesskontrollblöcke kapselt. Der Nachteil des Einsatzes einer solchenHandler-Routine ergibt sich aus der Leistung und der Frage, in welchem Ausmaßdarauf vertraut werden kann, dass der Rest der Systemsoftware korrekt ist.

3.3 Prozesssteuerung

AusführungsmodiBevor wir mit der Besprechung der Verwaltung der Prozesse durch das Betriebssys-tem fortfahren, müssen wir zwischen dem Modus der Prozessorausführung, der nor-malerweise mit dem Betriebssystem assoziiert wird, und dem, der normalerweise mitBenutzerprogrammen assoziiert wird, unterscheiden. Die meisten Prozessoren unter-stützen mindestens zwei Ausführungsmodi. Bestimmte Befehle können nur im privi-legierteren Modus ausgeführt werden. Darunter fällt das Lesen oder Verändern einesSteuerregisters wie z.B. des Programmstatusworts, primitive E/A-Befehle undBefehle, die die Speicherverwaltung betreffen. Darüber hinaus kann auf bestimmteSpeicherbereiche nur im privilegierteren Modus zugegriffen werden.

Der weniger privilegierte Modus wird häufig als Benutzermodus bezeichnet, dain der Regel Benutzerprogramme in diesem Modus ausgeführt werden. Der privile-giertere Modus wird als Systemmodus, Steuermodus oder Kernel-Modus bezeich-net. Die letzte Benennung bezieht sich auf den Kernel des Betriebssystems, also denTeil des Betriebssystems, der die wichtigen Systemfunktionen enthält. In Tabelle 3.7sind die für den Kernel eines Betriebssystems typischen Funktionen aufgeführt.

Tabelle 3.7 Typische Funktionen des Betriebssystemkernels

Prozessverwaltung

õ Prozesserzeugung und Prozessterminierungõ Prozessablaufplanung und Prozesszuteilungõ Prozesswechselõ Prozesssynchronisation und Unterstützung für die Interprozesskommunikationõ Verwaltung der Prozesskontrollblöcke

Speicherverwaltung

õ Zuteilung von Adressraum für Prozesseõ Auslagerungõ Seiten- und Segmentverwaltung

E/A-Verwaltung

õ Pufferverwaltungõ Zuteilung von E/A-Kanälen und E/A-Geräten für Prozesse

Unterstützungsfunktionen

õ Interrupt-Behandlungõ Buchführungõ Überwachung


Der Grund für die Verwendung zweier Modi sollte klar sein. Das Betriebssystem undwichtige Betriebssystemtabellen wie Prozesskontrollblöcke müssen vor dem Eingriffdurch Benutzerprogramme geschützt werden. Im Kernel-Modus hat die Software dievollständige Kontrolle über den Prozessor und alle seine Befehle, Register und denSpeicher. Für Benutzerprogramme ist dieser Grad an Kontrolle nicht notwendig undaus Sicherheitsgründen auch nicht erwünscht.

Es stellen sich zwei Fragen: Wie weiß der Prozessor, in welchem Modus er arbei-ten soll, und wie wird der Modus geändert? Die Antwort auf die erste Frage ist einBit, das normalerweise im Programmstatuswort (PSW) enthalten ist und den Ausfüh-rungsmodus anzeigt. Dieses Bit wird als Reaktion auf bestimmte Ereignisse verän-dert. Wenn ein Benutzer beispielsweise einen Aufruf an einen Dienst des Betriebssys-tems richtet, wird der Modus auf den Kernel-Modus eingestellt. In der Regelgeschieht dies durch die Ausführung eines Befehls, der den Modus wechselt. Ein Bei-spiel hierfür ist der Change-Mode-Befehl (CHM) auf dem VAX. Wenn der Benutzereinen Systemdienst aufruft oder ein Interrupt die Steuerung auf eine Systemroutineüberträgt, führt die Routine den Change-Mode-Befehl aus, um in einen privilegierte-ren Modus zu gelangen, und führt sie erneut aus, um in einen weniger privilegiertenModus zu gelangen, bevor die Steuerung zurück an den Benutzerprozess übergebenwird. Wenn ein Benutzerprogramm versucht, einen Change-Mode-Befehl auszufüh-ren, dann führt das ganz einfach zu einem Aufruf an das Betriebssystem, dasanschließend einen Fehler ausgibt, es sei denn, ein Moduswechsel soll erlaubt sein.

3.3.1 ProzesserzeugungIn Abschnitt 3.1 wurden die Ereignisse betrachtet, die zur Erzeugung eines neuenProzesses führen. Nach der Festlegung der Datenstrukturen, die mit einem Prozess inZusammenhang stehen, sind wir nun in der Lage, kurz die Schritte zu beschreiben,die bei der eigentlichen Erzeugung eines Prozesses durchlaufen werden müssen.

Sobald das Betriebssystem (z.B. aus einem der Gründe in Abbildung 3.1) entschei-det, einen neuen Prozess zu erzeugen, kann es wie folgt vorgehen:

1. Zuweisung einer eindeutigen Prozesskennung zum neuen Prozess. Zu diesemZeitpunkt wird der primären Prozesstabelle ein neuer Eintrag hinzugefügt. DieTabelle enthält pro Prozess einen Eintrag.

2. Zuteilung von Speicherplatz für den Prozess. Das beinhaltet alle Elemente desProzessabbilds. Das Betriebssystem muss daher wissen, wie viel Platz für den pri-vaten Benutzeradressraum (Programme und Daten) und den Benutzerstapelbenötigt wird. Diese Werte können je nach Art des Prozesses als Standardwertfestgelegt oder auf Anforderung des Benutzers zum Zeitpunkt der Joberstellungeingestellt werden. Wenn ein Prozess durch einen anderen Prozess erzeugt wird,kann der Elternprozess die benötigten Werte als Teil der Prozesserzeugungsanfor-derung an das Betriebssystem weiterleiten. Wenn ein bereits bestehender Adress-raum durch den neuen Prozess gemeinsam mit anderen Prozessen genutzt wer-den soll, müssen die entsprechenden Verknüpfungen eingerichtet werden. Undschließlich muss noch Speicherplatz für den Prozesskontrollblock zugewiesenwerden.

3. Initialisierung des Prozesskontrollblocks. Die Prozessidentifikation im Prozess-kontrollblock enthält die Kennung (ID) des Prozesses sowie weitere Kennungen,wie z.B. die des Elternprozesses. Im Teil der Prozessorstatusinformationen des


Prozesskontrollblocks werden die meisten Einträge zum Zeitpunkt der Initialisie-rung mit Ausnahme des Programmzählers (der auf die Programmeintrittstelleeingestellt ist) und des Systemstapelzeigers (der die Prozessstapelgrenzen fest-legt) auf null stehen. Der Teil der Prozesskontrollinformationen wird anhand vonStandardwerten und Attributen, die für den betreffenden Prozess angefordertwurden, initialisiert. Der Prozesszustand wird in der Regel mit »bereit« oder»bereit/suspendiert« initialisiert. Die Priorität kann standardmäßig auf den nied-rigsten Prioritätswert eingestellt werden, es sei denn, eine höhere Priorität wirdexplizit angefordert. Zu Beginn kann es sein, dass der Prozess keinerlei Ressour-cen (E/A-Geräte, Dateien) besitzt, es sei denn, die Ressourcen werden explizitangefordert oder sie werden vom Elternprozess geerbt.

4. Integration in dynamische Datenstrukturen. Wenn das Betriebssystem jede War-teschlange für die Ablaufplanung in Form einer verketteten Liste unterhält, mussder neue Prozess in die Liste für den Zustand »bereit« oder in die Liste für denZustand »bereit/suspendiert« eingefügt werden.

5. Erzeugung oder Erweiterung anderer Datenstrukturen. Das Betriebssystemkann beispielsweise eine Abrechnungsdatei für jeden Prozess unterhalten, diespäter zu Abrechnungszwecken oder zur Leistungsbeurteilung verwendet wer-den kann.

3.3.2 ProzesswechselOberflächlich betrachtet scheint der Prozesswechsel einfach zu sein. Ein aktiver Pro-zess wird zu einem beliebigen Zeitpunkt unterbrochen und das Betriebssystem ver-setzt einen anderen Prozess in den aktiven Zustand und gibt die Steuerung an diesenProzess ab. Allerdings wirft das mehrere Designfragen auf. Am Anfang steht dieFrage, welche Ereignisse einen Prozesswechsel auslösen. Ein weiterer Aspekt, derbetrachtet werden muss, ist die Unterscheidung zwischen einem Moduswechsel undeinem Prozesswechsel. Am Ende steht die Frage, was das Betriebssystem mit denverschiedenen Datenstrukturen, die unter seiner Kontrolle stehen, tun muss, umeinen Prozesswechsel zu erreichen.

Wann ein Prozesswechsel erfolgen sollEin Prozesswechsel kann zu jedem beliebigen Zeitpunkt erfolgen, an dem dasBetriebssystem die Steuerung vom gerade aktiven Prozess erhalten hat. In Tabelle 3.8sind mögliche Ereignisse aufgeführt, aufgrund derer die Steuerung an das Betriebs-system übergeben wird.

Tabelle 3.8 Mechanismen für die Unterbrechung der Ausführung eines Prozesses

Mechanismus Ursache Verwendung

Interrupt Außerhalb der Ausführung des aktuellen Befehls

Reaktion auf ein externes asynchrones Ereignis

Trap Hängt mit der Ausführung des aktuellen Befehls zusammen

Behandlung eines Fehlers oder eines Ausnahmezustands

Supervisor-Aufruf Explizite Anforderung Aufruf an eine Betriebssystemfunktion


Betrachten wir zunächst die System-Interrupts. Wie es in vielen Systemen tatsächlichumgesetzt ist, können wir zwei Arten von System-Interrupts unterscheiden. Einerwird einfach als Interrupt bezeichnet, der andere als Trap (Befehlsfalle). Ein Interruptberuht auf einem Ereignis, das außerhalb des gerade aktiven Prozesses liegt undunabhängig von ihm ist, wie z.B. die Beendigung einer E/A-Operation. Der Trapbezieht sich auf einen Fehler- oder Ausnahmezustand, der durch den aktiven Prozessselbst generiert wurde, wie z.B. ein unzulässiger Zugriffsversuch auf eine Datei. Beieinem normalen Interrupt wird die Steuerung zunächst an einen Interrupt-Handlerabgegeben, der einige grundlegende Systemverwaltungsaufgaben durchführt unddann auf eine Betriebssystemroutine verzweigt, die sich um den spezifischen Inter-rupt-Typ kümmert, der aufgetreten ist. Im Folgenden werden einige Beispiele fürInterrupts genannt:

õ Zeit-Interrupt: Das Betriebssystem stellt fest, ob der gerade aktive Prozess bereitsfür die Dauer der maximal zulässigen Zeitscheibe ausgeführt wird. Wenn dies derFall ist, muss der Prozess in den Zustand »bereit« umgeschaltet werden und einneuer Prozess wird zugeteilt.

õ E/A-Interrupt: Das Betriebssystem stellt fest, welche E/A-Aktion durchgeführtwurde. Wenn die E/A-Aktion ein Ereignis darstellt, auf das ein oder mehrere Pro-zesse warten, schaltet das Betriebssystem alle entsprechenden blockierten Pro-zesse in den Zustand »bereit« um (und Prozesse im Zustand »blockiert/suspen-diert« in den Zustand »bereit/suspendiert«). Das Betriebssystem muss dannentscheiden, ob es die Ausführung des gerade im Zustand »aktiv« befindlichenProzesses wiederaufnehmen oder diesen Prozess vorzeitig abbrechen möchte, umeinem bereiten Prozess mit höherer Priorität den Vorzug zu geben.

õ Speicherfehler: Der Prozessor referenziert mit einer Adresse des virtuellen Spei-chers ein Wort, das sich nicht im Hauptspeicher befindet. Das Betriebssystemmuss den Speicherblock (Seite oder Segment) mit der referenzierten Adresse ausdem Sekundärspeicher in den Hauptspeicher laden. Nach der Ausgabe einer E/A-Anforderung zum Laden des Speicherblocks muss das Betriebssystem einenProzesswechsel durchführen, um die Ausführung eines anderen Prozesses aufzu-nehmen. Der Prozess mit dem Speicherfehler wird in den blockierten Zustandversetzt. Nachdem der gewünschte Block in den Speicher geladen wurde, wirdder Prozess in den Zustand »bereit« versetzt.

Bei einem Trap stellt das Betriebssystem fest, ob ein Fehler- oder Ausnahmezustandschwerwiegend ist. Ist das der Fall, wird der gerade aktive Prozess in den Zustand»terminiert« versetzt und es erfolgt ein Prozesswechsel. Wenn nicht, hängt die Vorge-hensweise des Betriebssystems von der Art des Fehlers und den dafür vorgesehenenMaßnahmen des Betriebssystems ab. Es kann versuchen, eine Wiederherstellung zuerreichen oder ganz einfach den Benutzer informieren. Es kann außerdem einen Pro-zesswechsel durchführen oder den gerade aktiven Prozess wiederaufnehmen.

Schließlich kann das Betriebssystem durch einen Supervisor-Aufruf des geradeausgeführten Programms aktiviert werden. Es läuft z.B. ein Benutzerprozess und eswird ein Befehl ausgeführt, der eine E/A-Operation anfordert, wie z.B. das Öffneneiner Datei. Dieser Aufruf führt zu einer Übertragung auf eine Routine, die Teil desBetriebssystemcodes ist. Im Allgemeinen führt ein Systemaufruf dazu, dass derBenutzerprozess in den Zustand »blockiert« versetzt wird.


ModuswechselIn Kapitel 1 wurde die Einbeziehung eines Interrupt-Zyklus als Teil des Befehlszyk-lus behandelt. Erinnern wir uns an dieser Stelle daran, dass der Prozessor im Inter-rupt-Zyklus prüft, ob Interrupts aufgetreten sind, was durch das Vorhandenseineines Interrupt-Signals angezeigt wird. Wenn keine Interrupts anstehen, fährt derProzessor mit dem Abrufzyklus fort und ruft den nächsten Befehl des aktuellen Pro-gramms im aktuellen Prozess ab. Wenn ein Interrupt ansteht, geht der Prozessor wiefolgt vor:

1. Er speichert den Kontext des aktuellen, geraden ausgeführten Programms.

2. Er setzt den Programmzähler auf die Startadresse eines Interrupt-Handler-Programms.

3. Er schaltet vom Benutzermodus auf den Kernel-Modus um, so dass der Interrupt-Verarbeitungscode privilegierte Befehle enthalten kann.

Der Prozessor fährt nun mit dem Befehlszyklus fort und ruft den ersten Befehl ausdem Interrupt-Handler-Programm ab, das den Interrupt behandelt.

An dieser Stelle stellt sich die Frage: Was verbirgt sich hinter dem Kontext, derabgespeichert wird? Die Antwort lautet, dass er alle Informationen enthalten muss,die durch die Ausführung des Interrupt-Handlers verändert werden könnten und diefür die Wiederaufnahme des unterbrochenen Programms benötigt werden. Dahermuss der Teil des Prozesskontrollblocks, der als Prozessorstatusinformationenbezeichnet wurde, gesichert werden. Das betrifft den Programmzähler, weitere Pro-zessorregister und Stapelinformationen.

Muss noch irgendetwas getan werden? Das hängt davon ab, was als Nächstesgeschieht. Der Interrupt-Handler ist in der Regel ein kurzes Programm, das einigegrundlegende Aufgaben, die mit einem Interrupt zusammenhängen, durchführt. Ersetzt beispielsweise das Flag oder den Anzeiger zurück, der das Vorhandensein einesInterrupts anzeigt. Er kann eine Bestätigung an die Einheit schicken, die den Inter-rupt ausgegeben hat, beispielsweise ein E/A-Modul. Er kann außerdem einigegrundlegende Systemverwaltungsaufgaben durchführen, die mit den Auswirkungendes Ereignisses, das den Interrupt hervorgerufen hat, zusammenhängen. Wenn derInterrupt beispielsweise mit einem E/A-Ereignis in Zusammenhang steht, wird derInterrupt-Handler prüfen, ob ein Fehlerzustand vorliegt. Wenn ein Fehler aufgetretenist, kann der Interrupt-Handler ein Signal an den Prozess senden, der die E/A-Ope-ration ursprünglich veranlasst hatte. Wenn der Interrupt aus Zeitgründen erfolgt,wird der Handler die Steuerung an den Dispatcher übergeben, der sie möglicher-weise wiederum an einen anderen Prozess abgeben muss, da die dem gerade aktivenProzess zugeteilte Zeitscheibe abgelaufen ist.

Was ist mit den anderen Informationen im Prozesskontrollblock? Wenn diesemInterrupt der Wechsel zu einem anderen Prozess folgt, sind einige Arbeiten erforder-lich. Bei den meisten Betriebssystemen führt das Auftreten eines Interrupts allerdingsnicht notwendigerweise zu einem Prozesswechsel. Es ist möglich, dass der geradeaktive Prozess nach der Ausführung des Interrupt-Handlers wiederaufgenommenwird. In diesem Fall müssen lediglich die Prozessorstatusinformationen abgespei-chert werden, wenn der Interrupt auftritt. Wenn anschließend die Steuerung zurückauf das Programm übertragen wird, das zuvor lief, müssen diese Informationen wie-derhergestellt werden. In der Regel erfolgen die Speicherung und Wiederherstellungder Funktionen in der Hardware.


Änderung des ProzesszustandsEs ist klar, dass sich das Konzept des Moduswechsels von dem des Prozesswechselsunterscheidet.8 Ein Moduswechsel kann ohne Veränderung des Zustands des Prozes-ses, der gerade läuft, erfolgen. In diesem Fall verursachen das Speichern des Kontextsund die nachfolgende Wiederherstellung nur wenig Aufwand. Wenn der geradeaktive Prozess allerdings in einen anderen Zustand versetzt wird (bereit, blockiertusw.), muss das Betriebssystem weitreichende Änderungen an seiner Umgebungvornehmen. Die folgenden Schritte sind für einen vollständigen Prozesswechsel not-wendig:

1. Speichern des Prozessorkontexts mit Programmzähler und anderen Registern.

2. Aktualisierung des Prozesskontrollblocks des Prozesses, der sich gerade imZustand »aktiv« befindet. Dies beinhaltet die Änderung des Prozesszustands ineinen der anderen möglichen Zustände (bereit, blockiert, bereit/suspendiert oderterminiert). Darüber hinaus müssen auch andere relevante Felder aktualisiertwerden, darunter der Grund für das Verlassen des Zustands »aktiv« und Informa-tionen zu Buchhaltungszwecken.

3. Verschieben des Prozesskontrollblocks des betroffenen Prozesses in die entspre-chende Warteschlange (bereit, blockiert durch Ereignis i, bereit/suspendiert).

4. Auswahl eines anderen Prozesses für die Ausführung. Dieses Thema wird in Teil4 behandelt.

5. Aktualisierung des Prozesskontrollblocks des ausgewählten Prozesses. Dies bein-haltet die Änderung des Zustands des Prozesses in den Zustand »aktiv«.

6. Aktualisierung der Speicherverwaltungsstrukturen. Dies ist abhängig davon, wiedie Adressumsetzung erfolgt, notwendig. Dieses Thema wird in Teil 3 behandelt.

7. Wiederherstellung des Prozessorkontexts wie er zu dem Zeitpunkt bestand, andem der ausgewählte Prozess zuletzt den Zustand »aktiv« verlassen hat. Diesgeschieht durch Laden der vorherigen Werte des Programmzählers und andererRegister.

Ein Prozesswechsel, der eine Zustandsänderung beinhaltet, verursacht also wesent-lich mehr Aufwand als ein Moduswechsel.

3.3.3 Ausführung des BetriebssystemsKapitel 2 nannte zwei interessante Tatsachen über Betriebssysteme:

õ Das Betriebssystem funktioniert auf dieselbe Art und Weise wie normale Compu-tersoftware, d.h., es ist ein Programm, das vom Prozessor ausgeführt wird.

õ Das Betriebssystem gibt die Steuerung häufig ab und die Rückübertragung derSteuerung hängt vom Prozessor ab.

8 In der Literatur und in Lehrbüchern zum Thema Betriebssysteme findet sich häufig der AusdruckKontextwechsel. Während dieser Ausdruck im Großteil der Literatur dazu verwendet wird, einenUmstand zu benennen, der hier als Prozesswechsel bezeichnet wird, bezeichnet man in anderenWerken damit unglücklicherweise einen Moduswechsel oder auch Thread-Wechsel (die im nächs-ten Kapitel beschrieben werden). Um Unklarheiten zu vermeiden, wird dieser Ausdruck in die-sem Buch daher nicht verwendet.


Wenn das Betriebssystem einfach eine Sammlung von Programmen ist und wie jedesandere Programm vom Prozessor ausgeführt wird, ist das Betriebssystem dann einProzess? Wenn ja, wie wird es gesteuert? Diese interessante Frage war inspirierendfür zahlreiche Designansätze. In Abbildung 3.14 werden eine Reihe von Ansätzendargestellt, die in verschiedenen modernen Betriebssystemen anzutreffen sind.

Kernel ohne Prozesse

Ein vor allem bei älteren Betriebssystemen weit verbreiteter Ansatz ist die Ausfüh-rung des Kernels des Betriebssystems außerhalb der Prozesse (Abbildung 3.14a).Wenn bei diesem Ansatz der gerade aktive Prozess unterbrochen wird oder einenSupervisor-Aufruf ausgibt, wird der Moduskontext dieses Prozesses gespeichert unddie Steuerung an den Kernel abgegeben. Das Betriebssystem hat einen eigenenSpeicherbereich und einen eigenen Systemstapel für die Steuerung von Prozedurauf-rufen und -rücksprüngen. Das Betriebssystem kann jede gewünschte Funktion ausü-ben und den Kontext des unterbrochenen Prozesses wiederherstellen, wodurch dieWiederaufnahme der Ausführung des unterbrochenen Benutzerprozesses ausgelöst

Abbildung 3.14 Beziehung zwischen dem Betriebssystem und Benutzerprozessen


wird. Alternativ dazu kann das Betriebssystem die Umgebung des Prozesses füreinen Prozesswechsel speichern und anschließend einen anderen Prozess zuteilen.Ob dies passiert, hängt vom Grund für die Unterbrechung und den zu diesem Zeit-punkt vorherrschenden Umständen ab.

Wichtig ist an dieser Stelle, dass das Prozesskonzept nur auf Benutzerprogrammeangewendet wird. Der Betriebssystemcode wird als separate Einheit ausgeführt, dieim privilegierten Modus operiert.

Ausführung innerhalb von BenutzerprozessenEine weit verbreitete Alternative bei Betriebssystemen auf kleinen Rechnern (PCs,Arbeitsplatzrechnern) ist die Ausführung praktisch der gesamten Betriebssystemsoft-ware im Kontext eines Benutzerprozesses. Bei dieser Sichtweise ist das Betriebssys-tem in erster Linie eine Sammlung von Routinen, die der Benutzer aufruft, umbestimmte Funktionen innerhalb der Umgebung des Benutzerprozesses auszuführen.Dies ist in Abbildung 3.14b dargestellt. An einem beliebigen Punkt verwaltet dasBetriebssystem n Prozesse. Jedes Prozessabbild enthält neben den in Abbildung 3.12dargestellten Bereichen zusätzlich Programm-, Daten- und Stapelbereiche für Kernel-Programme.

Abbildung 3.15 zeigt eine typische Struktur eines Prozessabbilds für diese Strate-gie. Für die Verwaltung der Aufrufe/Rücksprünge wird ein separater Kernel-Stapelverwendet, während sich der Prozess im Kernel-Modus befindet. Der Betriebssys-temcode und die Daten befinden sich im gemeinsamen Adressraum und werdengemeinsam von sämtlichen Benutzerprozessen genutzt.

Wenn ein Interrupt, Trap oder Supervisor-Aufruf erfolgt, wird der Prozessor inden Kernel-Modus versetzt und die Steuerung wird an das Betriebssystem überge-ben. Zu diesem Zweck wird der Moduskontext gespeichert und es erfolgt ein Modus-wechsel zu einer Betriebssystemroutine. Die Ausführung setzt sich allerdings mitdem aktuellen Benutzerprozess fort. Es findet also kein Prozesswechsel, sondernlediglich ein Moduswechsel innerhalb desselben Prozesses statt.

Wenn das Betriebssystem nach Beendigung seiner Arbeit feststellt, dass der aktu-elle Prozess weiterlaufen soll, wird das unterbrochene Programm innerhalb des aktu-ellen Prozesses durch einen Moduswechsel wieder aufgenommen. Dies stellt einender wichtigsten Vorteile dieses Ansatzes dar: Ein Benutzerprogramm wurde unter-brochen, damit eine Betriebssystemroutine angewendet werden kann, und wirdanschließend wieder aufgenommen. All das geschieht, ohne dass dafür zwei Prozess-wechsel notwendig wären. Wenn allerdings festgestellt wird, dass es zu einem Pro-zesswechsel und nicht zu einer Rückkehr zum vorher laufenden Programm kommensoll, dann wird die Steuerung an eine Prozesswechselroutine übergeben. Es hängtvom Systemaufbau ab, ob diese Routine im aktuellen Prozess ausgeführt wird odernicht. An einem gewissen Punkt muss der aktuelle Prozess allerdings in den nichtaktiven Zustand versetzt werden und ein anderer Prozess wird dazu bestimmt zulaufen. Während dieser Phase ist es sinnvoll, sich eine Ausführung des Betriebssys-temcodes außerhalb des Prozesses vorzustellen.

Diese Sichtweise des Betriebssystems ist in gewisser Hinsicht bemerkenswert.Einfach ausgedrückt speichert ein Prozess zu bestimmten Zeitpunkten seine Statusin-formationen, wählt unter den bereiten Prozessen einen anderen Prozess aus, der lau-fen soll, und gibt die Steuerung an diesen Prozess ab. Der Grund dafür, dass daskeine zufällige oder gar chaotische Situation ergibt, liegt darin, dass es sich bei demim kritischen Zeitraum im Benutzerprozess ausgeführten Code um gemeinsam


genutzten Betriebssystemcode und nicht um Benutzercode handelt. Aufgrund desKonzepts des Benutzermodus und des Kernel-Modus kann der Benutzer keine uner-laubten Änderungen an den Betriebssystemroutinen vornehmen, obwohl sie inner-halb der Benutzerprozessumgebung ausgeführt werden. Es sei an dieser Stelle daranerinnert, dass es zwischen dem Prozess- und dem Programmkonzept einen Unter-schied gibt und dass diese beiden Konzepte nicht in einem Eins-zu-Eins-Verhältniszueinander stehen. Innerhalb eines Prozesses können sowohl ein Benutzerprogrammals auch Systemprogramme ausgeführt werden und die Betriebssystemprogramme,die in den verschiedenen Benutzerprozessen ausgeführt werden, sind identisch.

Prozessbasiertes Betriebssystem

Eine weitere, in Abbildung 3.14c dargestellte Alternative besteht in der Implementie-rung des Betriebssystems als eine Sammlung von Systemprozessen. Wie bei den

Abbildung 3.15 Prozessabbild: Das Betriebssystem wird innerhalb des Benutzerraums ausgeführt.

di


anderen beiden Optionen läuft die Software, die Teil des Kernels ist, im Kernel-Modus. Allerdings sind in diesem Fall wichtige Kernel-Funktionen in Form von sepa-raten Prozessen realisiert. Auch hier kann es eine kleine Menge Prozesswechselcodegeben, der außerhalb der Prozesse ausgeführt wird.

Dieser Ansatz weist mehrere Vorteile auf. Er führt zu einem Softwaredesign, dasdie Verwendung eines modularen Betriebssystems mit minimalen, wohl definiertenSchnittstellen zwischen den Modulen fördert. Darüber hinaus werden einige nichtkritische Betriebssystemfunktionen in Form von separaten Prozessen implementiert.An vorheriger Stelle wurde ein Überwachungsprogramm als Beispiel genannt, dasden Nutzungsgrad der verschiedenen Ressourcen (Prozessor, Speicher, Kanäle) unddie Ablaufgeschwindigkeit der Benutzerprozesse im System aufzeichnet. Da diesesProgramm keine bestimmten Dienste für aktive Prozesse leistet, kann es nur vomBetriebssystem aktiviert werden. Als Prozess kann die Funktion mit einer zugewiese-nen Prioritätsstufe laufen und unter der Kontrolle eines Dispatchers mit anderen Pro-zessen im Wechsel ausgeführt werden. Die Implementierung des Betriebssystems alseine Reihe von Prozessen ist auch in einer Mehrprozessor- oder Mehrrechnerumge-bung nützlich, in der einige der Betriebssystemdienste auf dedizierte Prozessorenausgelagert werden, was zu einer Leistungssteigerung führt.

3.4 Prozessverwaltung in UNIX SVR4UNIX System V nutzt ein einfaches, aber wirkungsvolles Prozesskonzept, das für denBenutzer sichtbar ist. UNIX folgt dem Modell in Abbildung 3.14b, nach dem dergrößte Teil des Betriebssystems innerhalb der Umgebung eines Benutzerprozessesausgeführt wird. Es werden daher zwei Modi, der Benutzermodus und der Kernel-Modus, benötigt. UNIX verwendet zwei Prozesskategorien: Systemprozesse undBenutzerprozesse. Systemprozesse laufen im Kernel-Modus und führen Betriebssys-temcode aus, um administrative und organisatorische Aufgaben, wie z.B. die Spei-cherzuweisung und die Prozessauslagerung, durchzuführen. Benutzerprozesse lau-fen im Benutzermodus, um Benutzerprogramme und Hilfsprogramme auszuführen,und im Kernel-Modus, um Befehle auszuführen, die mit dem Kernel in Zusammen-hang stehen. Ein Benutzerprogramm gelangt durch einen Systemaufruf in den Ker-nel-Modus, wenn eine Ausnahme (Fehler) generiert wurde und ein Interrupt auftritt.

3.4.1 ProzesszuständeInnerhalb eines UNIX-Betriebssystems gibt es insgesamt neun Prozesszustände. InTabelle 3.9 sind diese Zustände aufgeführt. Ein Zustandsübergangsdiagramm ist inAbbildung 3.16 (basierend auf einer Abbildung in [BACH86]) dargestellt. Die Abbil-dung ähnelt Abbildung 3.7, wobei die beiden schlafenden Zustände in UNIX den bei-den blockierten Zuständen entsprechen. Die Unterschiede lassen sich schnell zusam-menfassen:

õ In UNIX gibt es zwei aktive Zustände, um anzuzeigen, ob ein Prozess im Benut-zermodus oder im Kernel-Modus ausgeführt wird.

õ Es wird zwischen den beiden Zuständen »bereit, im Speicher« und »verdrängt«unterschieden. Es handelt sich im Wesentlichen um die gleichen Zustände, wasdurch die gestrichelte Linie, durch die sie verbunden sind, angezeigt wird. DieUnterscheidung soll die Art und Weise betonen, in der der verdrängte Zustand

3.4 Prozessverwaltung in UNIX SVR4 173

eingenommen wird. Wenn ein Prozess im Kernel-Modus läuft (als Ergebnis einesSupervisor-Aufrufs, eines zeitlichen Interrupts oder eines E/A-Interrupts), wirdirgendwann der Punkt erreicht, an dem der Kernel seine Arbeit beendet hat undbereit ist, die Steuerung an das Benutzerprogramm zu übergeben. Zu diesem Zeit-punkt kann der Kernel beschließen, den aktuellen Prozess zu unterbrechen undeinem anderen Prozess, der bereit und von höherer Priorität ist, den Vorzug zugeben. In diesem Fall wechselt der aktuelle Prozess in den verdrängten Zustand.Allerdings bilden die Prozesse im verdrängten Zustand und die im Zustand»bereit, im Speicher« zum Zwecke der Zuteilung eine gemeinsame Warte-schlange.

Die Vorrangunterbrechung (Verdrängung) kann nur erfolgen, wenn ein Prozessgerade vom Kernel-Modus in den Benutzermodus wechselt. Solange ein Prozess imKernel-Modus läuft, kann er nicht verdrängt werden. Dadurch wird UNIX ungeeig-net für die Echtzeitverarbeitung. Die Anforderungen für die Echtzeitverarbeitungwerden in Kapitel 10 besprochen.

Es gibt in UNIX zwei einzigartige Prozesse. Prozess 0 ist ein spezieller Prozess,der erzeugt wird, wenn das System bootet. Er ist als eine Datenstruktur vordefiniert,die zum Zeitpunkt des Bootens geladen wird. Es handelt sich um den Auslagerungs-prozess (Swapper-Prozess). Zusätzlich dazu erzeugt Prozess 0 Prozess 1, der auch als

Tabelle 3.9 UNIX-Prozesszustände

Im Benutzermodus laufend (User Running)

Wird im Benutzermodus ausgeführt.

Im Kernel-Modus laufend (Kernel Running)

Wird im Kernel-Modus ausgeführt.

Bereit, im Speicher (Ready to Run, in Memory)

Bereit zur Ausführung, sobald der Kernel ihn dafür festlegt.

Schlafend im Speicher (Asleep in Memory)

Nicht in der Lage, ausgeführt zu werden, solange nicht ein bestimmtes Ereignis eintritt. Der Prozess befindet sich im Hauptspeicher (im blockierten Zustand).

Bereit, ausgelagert (Ready to Run, Swapped)

Der Prozess ist bereit zu laufen, aber der Swapper muss den Prozess in den Hauptspeicher bringen, damit der Kernel ihn für die Ausführung einplanen kann.

Schlafend, ausgelagert (Sleeping, Swapped)

Der Prozess wartet auf ein Ereignis und wurde (im blockierten Zustand) in den Sekundärspeicher ausgelagert.

Verdrängt (Preempted) Der Prozess kehrt vom Kernel-Modus in den Benutzermodus zurück, wird aber vom Kernel unterbrochen, der einen Prozess-wechsel durchführt, um einen anderen Prozess einzuplanen.

Erzeugt (Created) Der Prozess wurde neu erzeugt und ist noch nicht bereit zum Laufen.

Zombie Der Prozess existiert nicht mehr, aber er hinterlässt einen Eintrag als Resultat für seinen Elternprozess.


init-Prozess bezeichnet wird. Alle weiteren Prozesse im System stammen von Prozess1 ab. Wenn sich ein neuer interaktiver Benutzer am System anmeldet, erzeugt Prozess1 einen Benutzerprozess für diesen Benutzer. Anschließend kann der Benutzerpro-zess Kindprozesse in Form eines sich verzweigenden Baums erzeugen, so dass eineeinzelne Anwendung immer aus mehreren miteinander in Beziehung stehenden Pro-zessen besteht.

3.4.2 ProzessbeschreibungEin Prozess in UNIX ist ein komplexer Satz von Datenstrukturen, der das Betriebssys-tem mit all den Informationen versorgt, die für die Verwaltung und die Zuteilungvon Prozessen notwendig sind. In Tabelle 3.10 werden die Elemente des Prozessab-bilds zusammengefasst. Sie sind in drei Teile geordnet, den Benutzerebenenkontext,den Registerkontext und den Systemebenenkontext.Der Benutzerebenenkontext enthält die grundlegenden Elemente eines Benutzerpro-gramms und kann direkt aus einer kompilierten Objektdatei erzeugt werden. DasBenutzerprogramm ist in Text- und Datenbereiche aufgeteilt. Der Textbereich kannnur gelesen werden und ist für die Aufnahme der Programmbefehle gedacht. Wäh-rend der Prozess ausgeführt wird, verwendet der Prozessor den Benutzerstapelbe-reich für Prozeduraufrufe und -rücksprünge und die Weitergabe von Parametern.

Abbildung 3.16 UNIX-Prozesszustandsübergangsdiagramm


Der gemeinsam genutzte Speicherbereich ist ein Datenbereich, der gemeinsam mitanderen Prozessen genutzt wird. Es gibt nur eine physikalische Kopie eines gemein-sam genutzten Speicherbereichs, aber durch die Verwendung des virtuellen Spei-chers scheint es für jeden teilnehmenden Prozess, als befände sich der gemeinsamgenutzte Speicherbereich in seinem jeweiligen Adressraum. Wenn ein Prozess nichtläuft, werden die Prozessorstatusinformationen im Registerkontext gespeichert.

Der Systemebenenkontext enthält die restlichen Informationen, die das Betriebs-system für die Prozessverwaltung benötigt. Er besteht aus einem statischen Teil, des-sen Größe festgelegt ist und der über die gesamte Lebensdauer eines Prozesses bei

Tabelle 3.10 UNIX-Prozessabbild

Benutzerebenenkontext

Prozesstext Ausführbare Maschinenbefehle des Programms.

Prozessdaten Daten, auf die durch das Programm dieses Prozesses zugegriffen werden kann.

Benutzerstapel Enthält Argumente, lokale Variablen und Zeiger für Funktionen, die im Benutzermodus ausgeführt werden.

Gemeinsam genutzter Speicher

Speicher, der gemeinsam mit anderen Prozessen genutzt wird. Wird für die Interprozesskommunikation verwendet.

Registerkontext

Programmzähler Adresse des als Nächstes auszuführenden Befehls. Kann sich im Kernel- oder Benutzerspeicherraum des Prozesses befinden.

Prozessorstatusregister Enthält den Hardwarestatus zum Zeitpunkt der Verdrängung. In-halte und Format sind abhängig von der Hardware.

Stapelzeiger Zeigt abhängig vom Betriebsmodus zum Zeitpunkt der Verdrän-gung auf das obere Ende des Kernel- oder Benutzerstapels.

Register für allgemeine Zwecke

Abhängig von der Hardware.

Systemebenenkontext

Prozesstabelleneintrag Legt den Status eines Prozesses fest. Das Betriebssystem kann jederzeit auf diese Informationen zugreifen.

Benutzerbereich Prozesskontrollinformationen, auf die nur im Kontext des Prozes-ses zugegriffen werden muss.

Prozessbereichstabelle Legt die Zuordnung von virtuellen zu physikalischen Adressen fest. Enthält außerdem ein Erlaubnisfeld, das den für den Prozess zulässigen Zugriffstyp anzeigt: nur Lesen, Lesen und Schreiben oder Lesen und Ausführen.

Kernel-Stapel Enthält den Stapelrahmen von Kernel-Prozeduren, wenn der Prozess im Kernel-Modus läuft.


diesem Prozess verbleibt. Ein Element des statischen Teils ist der Prozesstabellenein-trag. Es handelt sich dabei um einen Teil der Prozesstabelle, die vom Betriebssystemverwaltet wird und einen Eintrag pro Prozess enthält. Der Prozesstabelleneintragumfasst Prozesskontrollinformationen, auf die der Kernel jederzeit zugreifen kann. Ineinem virtuellen Speichersystem befinden sich daher alle Prozesstabelleneinträge imHauptspeicher. In Tabelle 3.11 werden die Inhalte eines Prozesstabelleneintrags auf-geführt. Der Benutzerbereich, auch User- oder U-Area genannt, enthält zusätzlicheProzesskontrollinformationen, die vom Kernel benötigt werden, wenn er im Kontextdieses Prozesses arbeitet. Er wird darüber hinaus auch für das Paging von Prozessenin und aus dem Speicher verwendet. In Tabelle 3.12 werden die Inhalte dieser Tabelledargestellt.

Tabelle 3.11 UNIX-Prozesstabelleneintrag

Prozesszustand Aktueller Zustand des Prozesses.

Zeiger Mehrere Zeiger auf U-Area und den Prozessspeicherbereich (Text, Daten, Stapel).

Prozessgröße Ermöglicht es dem Betriebssystem, zu erkennen, wie viel Platz dem Prozess zugewiesen werden muss.

Benutzer-kennungen

Die reale Benutzerkennung identifiziert den Benutzer, der für den aktiven Prozess verantwortlich ist. Die effektive Benutzerkennung kann von einem Prozess verwendet werden, um temporäre Privilegien, die mit einem bestimmten Programm in Zusammenhang stehen, zu erlangen. Während das Programm als Teil des Prozesses ausgeführt wird, arbeitet der Prozess mit der effektiven Benutzerkennung.

Prozesskennun-gen

Kennung (ID) des Prozesses. Kennung (ID) des Elternprozesses. Die Kennungen werden erstellt, wenn der Prozess während des Fork-Sys-temaufrufs in den Zustand »erzeugt« wechselt.

Ereignis-beschreibung

Gilt, wenn sich ein Prozess im schlafenden Zustand befindet. Wenn das Ereignis eintritt, wird der Prozess in einen Zustand der Laufbereit-schaft versetzt.

Priorität Wird für die Prozessablaufplanung verwendet.

Signal Aufzählung von Signalen, die an einen Prozess geschickt, aber noch nicht bearbeitet wurden.

Timer Beinhaltet die Prozessausführungszeit, die Kernel-Ressourcennutzung und benutzerdefinierte Timer, die dazu verwendet werden, Alarmsig-nale an einen Prozess zu schicken.

P_link Zeiger auf das Folgeelement in der Warteschlange für bereite Prozesse (gültig, wenn der Prozess bereit für die Ausführung ist).

Speicherstatus Zeigt an, ob sich das Prozessabbild im Hauptspeicher befindet oder ausgelagert wurde. Wenn es sich im Speicher befindet, zeigt dieses Feld außerdem an, ob es ausgelagert werden kann oder temporär im Hauptspeicher bleiben muss, weil ein Lock gesetzt ist.

➔


Der Unterschied zwischen dem Prozesstabelleneintrag und der U-Area reflektiert dieTatsache, das der UNIX-Kernel immer im Kontext eines Prozesses läuft. Einen Groß-teil der Zeit über befasst sich der Kernel mit den Belangen des Prozesses. Gelegent-lich, z.B. wenn der Kernel vorbereitend für die Zuteilung eines anderen Prozesseseinen Ablaufplanungsalgorithmus durchführt, benötigt er allerdings Informationenüber andere Prozesse.

Der dritte statische Teil des Systemebenenkontexts ist die Prozessbereichstabelle,die vom Speicherverwaltungssystem genutzt wird. Der Kernel-Stapel ist der dynami-sche Teil des Systemebenenkontexts. Dieser Stapel wird verwendet, wenn der Prozessim Kernel-Modus läuft, und enthält die Informationen, die beim Auftreten von Pro-zeduraufrufen und Interrupts gespeichert und wiederhergestellt werden müssen.

Tabelle 3.11 UNIX-Prozesstabelleneintrag

Prozesstabellenzeiger Zeigt den Eintrag an, der der U-Area entspricht.

Benutzerkennungen Reale und effektive Benutzerkennungen. Werden verwendet, um Benutzerprivilegien festzulegen.

Timer Zeichnen die Zeit auf, die der Prozess (und seine Kindprozes-se) mit der Ausführung im Benutzermodus und im Kernel-Modus verbracht hat.

Signalverarbeitungs-Array Für jeden im System festgelegten Signaltyp. Zeigt an, wie der Prozess auf den Erhalt des entsprechenden Signals reagieren wird (Terminieren, Ignorieren, Ausführen einer bestimmten Be-nutzerfunktion).

Kontrollterminals Zeigt das Login-Terminal für den Prozess an, falls ein solches existiert.

Fehlerfeld Zeichnet Fehler auf, die während eines Systemaufrufs auftre-ten.

Rückgabewert Enthält das Ergebnis von Systemaufrufen.

E/A-Parameter Beschreiben den Umfang der zu übertragenden Daten, die Adresse des Quell- oder Zieldaten-Arrays im Benutzerraum und Datei-Offsets für die E/A.

Dateiparameter Das aktuelle Verzeichnis und die aktuelle Wurzel beschreiben die Dateisystemumgebung des Prozesses.

Benutzerdatei-beschreibungstabelle

In dieser Tabelle sind die vom Prozess geöffneten Dateien aufgezeichnet.

Begrenzungsfelder Schränken die Größe des Prozesses und die Größe einer Datei, in die er schreiben kann, ein.

Erlaubnismodusfelder Maskieren Moduseinstellungen für Dateien, die der Prozess erzeugt.

➔


3.4.3 ProzesssteuerungIn UNIX erfolgt die Prozesserzeugung mit Hilfe des Kernel-Systemaufrufs fork().Wenn ein Prozess eine Fork-Anforderung ausgibt, führt das Betriebssystem die fol-genden Schritte durch [BACH86]:

1. Es teilt dem neuen Prozess einen Abschnitt in der Prozesstabelle zu.

2. Es weist dem Kindprozess eine eindeutige Prozesskennung zu.

3. Es erstellt mit Ausnahme des gemeinsam genutzten Speichers eine Kopie desElternprozessabbilds.

4. Es erhöht die Zählerwerte von Dateien, die im Besitz des Elternprozesses stehen,um anzuzeigen, dass nun ein weiterer Prozess diese Dateien ebenfalls besitzt.

5. Es weist dem Kindprozess einen bereiten Zustand zu.

6. Es übergibt die Kennzahl des Kindprozesses an den Elternprozess und einen 0-Wert an den Kindprozess.

All diese Schritte werden innerhalb des Elternprozesses im Kernel-Modus durchge-führt. Wenn der Kernel diese Arbeiten beendet hat, kann er als Teil der Dispatcher-Routine eines der folgenden Dinge tun:

1. Im Elternprozess verbleiben. Die Steuerung kehrt am Punkt des Fork-Aufrufs desElternprozesses zum Benutzermodus zurück.

2. Die Steuerung an den Kindprozess abgeben. Der Kindprozess beginnt am selbenPunkt im Code mit der Ausführung wie der Elternprozess, also am Rücksprungvom Fork-Aufruf.

3. Die Steuerung an einen anderen Prozess abgeben. Sowohl der Elternprozess alsauch der Kindprozess verbleiben im bereiten Zustand.

Es ist vielleicht schwierig, sich diese Methode der Prozesserzeugung vorzustellen, dasowohl der Elternprozess als auch der Kindprozess im selben Codeabschnitt ausge-führt werden. Der Unterschied ist der Folgende: Beim Rücksprung von der Fork-Funktion wird der Rücksprungparameter geprüft. Ist der Wert null, handelt es sichum den Kindprozess und es kann eine Verzweigung auf das entsprechende Benutzer-programm durchgeführt werden, um mit der Ausführung fortzufahren. Ist der Wertnicht null, dann handelt es sich um den Elternprozess und die Hauptlinie der Aus-führung kann fortfahren.

3.5 ZusammenfassungDer wichtigste Baustein moderner Betriebssysteme ist der Prozess. Die prinzipielleAufgabe des Betriebssystems umfasst die Erzeugung, Verwaltung und Terminierungvon Prozessen. Solange Prozesse aktiv sind, muss das Betriebssystem dafür sorgen,dass jedem Prozess für die Ausführung durch den Prozessor Zeit zugeteilt wird, esmuss die Aktivitäten der Prozesse koordinieren, Konflikte regeln und den ProzessenSystemressourcen zuteilen.

Für die Durchführung der Prozessverwaltungsaufgaben verwaltet das Betriebs-system Prozessbeschreibungen oder Prozessabbilder, die den Adressraum, innerhalbdessen der Prozess ausgeführt wird, und einen Prozesskontrollblock enthalten. Der

Schlüsselwörter 179

Prozesskontrollblock enthält sämtliche Informationen, die vom Betriebssystem fürdie Verwaltung des Prozesses benötigt werden, wie der aktuelle Status, die ihm zuge-wiesenen Ressourcen, die Priorität und weitere relevante Daten.

Über seine gesamte Lebensdauer durchläuft ein Prozess zahlreiche Zustände. Diewichtigsten Prozesszustände heißen »bereit«, »aktiv« und »blockiert«. Ein bereiterProzess ist ein Prozess, der gerade nicht ausgeführt wird, der aber bereit für die Aus-führung ist, sobald das Betriebssystem ihn dafür zuteilt. Ein aktiver Prozess ist einProzess, der gerade vom Prozessor ausgeführt wird. Bei einem Mehrprozessorsystemkönnen sich mehrere Prozesse in diesem Zustand befinden. Ein blockierter Prozesswartet auf die Beendigung eines bestimmten Ereignisses, wie z.B. eine E/A-Opera-tion.

Ein aktiver Prozess wird entweder durch einen Interrupt, also ein Ereignis, dasaußerhalb des Prozesses auftritt und vom Prozessor erkannt wird, oder durch dieAusführung eines Supervisor-Aufrufs an das Betriebssystem unterbrochen. In beidenFällen führt der Prozessor einen Moduswechsel durch und übergibt so die Steuerungan eine Betriebssystemroutine. Das Betriebssystem kann nach Beendigung der not-wendigen Aktionen den unterbrochenen Prozess wieder aufnehmen oder zu einemanderen Prozess wechseln.

SCHLÜSSELWÖRTER

Aktiver ZustandAuslagerungBenutzermodusBereiter ZustandBlockierter ZustandInterruptKernel-ModusKindprozessModuswechsel

Neuer ZustandPrivilegierter ModusProgrammstatuswortProzessProzessabbildProzesskontrollblockProzesswechselRound RobinSuspendierter Zustand

SystemmodusTaskTerminierter ZustandTraceTrapElternprozessVerdrängt

WIEDERHOLUNGSFRAGEN

3.1 Was ist eine Befehls-Trace?

3.2 Welche häufig auftretenden Ereignisse führen zur Erzeugung eines Prozesses?

3.3 Definieren Sie für das Prozessmodell in Abbildung 3.5 kurz jeden Zustand.

3.4 Was bedeutet es, wenn ein Prozess verdrängt wird?

3.5 Was versteht man unter Auslagerung und was ist ihr Zweck?

3.6 Warum gibt es in Abbildung 3.8b zwei blockierte Zustände?

3.7 Nennen Sie vier Merkmale eines suspendierten Prozesses.➔


3.8 Für welche Arten von Einheiten unterhält das Betriebssystem Informationstabellenzu Verwaltungszwecken?

3.9 Nennen Sie drei allgemeine Informationskategorien in einem Prozesskontrollblock.

3.10 Warum werden zwei Modi (Benutzermodus und Kernel-Modus) benötigt?

3.11 Welche Schritte führt ein Betriebssystem für die Prozesserzeugung durch?

3.12 Was ist der Unterschied zwischen einem Interrupt und einem Trap?

3.13 Nennen Sie drei Beispiele für einen Interrupt.

3.14 Was ist der Unterschied zwischen einem Moduswechsel und einem Prozesswech-sel?

L I TERATURH INWE ISE

Sämtliche Literatur, die in Abschnitt 2.9 aufgeführt ist, behandelt den Themenumfangdieses Kapitels. Gute Beschreibungen der UNIX-Prozessverwaltung finden sich in[GOOD94] und [GRAY97]. [NEHM75] ist eine interessante Besprechung der Prozesszu-stände und der Basiseinheiten eines Betriebssystems, die für den Dispatcher benötigtwerden.

GOOD94 Goodheart, B. und Cox, J. The Magic Garden Explained: The Internals of

UNIX System V Release 4. Englewood Cliffs, NJ: Prentice Hall, 1994.

GRAY97 Gray, J. Interprocess Communications in UNIX: The Nooks and Crannies.Upper Saddle River, NJ: Prentice Hall, 1997.

NEHM75 Nehmer, J. »Dispatcher Primitives for the Construction of Operating SystemKernels.« Acta Informatica, Band 5, 1975.

ÜBUNGSAUFGABEN

3.1 Nennen Sie fünf Hauptaktivitäten eines Betriebssystems unter dem Gesichtspunktder Prozessverwaltung und beschreiben Sie kurz, warum jede dieser Aktivitäten not-wendig ist.

3.2 In [PINK89] werden die folgenden Prozesszustände genannt: ausführend (aktiv),aktiv (bereit), blockiert und suspendiert. Ein Prozess ist blockiert, wenn er auf dieErlaubnis, eine Ressource zu benutzen, wartet. Er ist suspendiert, wenn er daraufwartet, dass eine Operation mit einer Ressource, die er bereits besitzt, beendet wird.In vielen Betriebssystemen werden diese beiden Zustände zum blockierten Zustandzusammengefasst und der suspendierte Zustand ist so wie in diesem Kapitel defi-niert. Vergleichen Sie die relativen Vorzüge der beiden Definitionsarten.

3.3 Zeichnen Sie für das Prozessmodell mit sieben Zuständen in Abbildung 3.8b einWarteschlangendiagramm ähnlich dem in Abbildung 3.7b.

➔

➔

Übungsaufgaben 181

3.4 Betrachten Sie das Zustandsübergangsdiagramm in Abbildung 3.8b. Es sei für dasBetriebssystem an der Zeit, einen Prozess zuzuteilen, und es gebe Prozesse sowohlim bereiten als auch im bereiten/suspendierten Zustand. Mindestens ein Prozess imbereiten/suspendierten Zustand hat eine höhere Ablaufplanungspriorität als alle Pro-zesse im bereiten Zustand. Es gibt zwei extreme Vorgehensweisen: (1) Es wirdimmer ein Prozess im bereiten Zustand zugeteilt, um die Auslagerung zu minimieren.(2) Es wird immer dem Prozess mit der höchsten Priorität der Vorrang gegeben, auchwenn es dadurch zu unnötigen Auslagerungen kommt. Machen Sie einen Vorschlagfür den goldenen Mittelweg und versuchen Sie dabei, die Fragen der Priorität undder Leistung in Einklang zu bringen.

3.5 In Tabelle 3.12 sind die Prozesszustände für das Betriebssystem VAX/VMS aufge-führt.

a. Können Sie begründen, warum es so viele unterschiedliche Wartezustände gibt?b. Warum gibt es bei den folgenden Zuständen keine residenten oder ausgelager-

ten (outswapped) Versionen: page fault wait, collided page wait, common eventwait, free page wait und resource wait.

c. Zeichnen Sie das Zustandsübergangsdiagramm und kennzeichnen Sie die Aktio-nen oder die Erscheinungen, die jeweils für die einzelnen Zustandsänderungenverantwortlich sind.

Tabelle 3.12 VAX/VMS-Prozesszustände

Currently Executing Aktiver Prozess.

Computable (resident) Bereit und im Hauptspeicher resident.

Computable (outswapped)

Bereit, aber aus dem Hauptspeicher ausgelagert.

Page Fault Wait Der Prozess hat auf eine Seite Bezug genommen, die sich nicht im Hauptspeicher befindet, und muss darauf warten, dass die Seite eingelesen wird.

Collided Page Wait Der Prozess hat auf eine gemeinsam nutzbare Seite Bezug genommen, die der Grund für den Zustand »Page Fault Wait« eines anderen Prozesses ist, oder er hat Bezug auf eine private Seite genommen, in die oder aus der gerade geschrieben wird.

Common Event Wait Warten auf ein gemeinsam genutztes Ereignis-Flag (Ereig-nis-Flags sind Einzelbitmechanismen für Signale zwischen Prozessen).

Free Page Wait Warten darauf, dass eine freie Seite im Hauptspeicher der Menge Seiten im Hauptspeicher, die dem betreffenden Prozess gehören (dem Working Set des Prozesses), hinzu-gefügt wird.

Hibernate Wait (resident) Der Prozess versetzt sich selbst in einen Wartezustand.

Hibernate Wait (ausgelagert)

Ein im Wartezustand befindlicher Prozess wird aus dem Hauptspeicher ausgelagert.

➔

➔


Local Event Wait (resident)

Der Prozess befindet sich im Hauptspeicher und wartet auf ein lokales Ereignis-Flag (für gewöhnlich die Beendigung ei-ner E/A-Operation).

Local Event Wait (ausgelagert)

Ein Prozess im Zustand »Local Event Wait« wird aus dem Hauptspeicher ausgelagert.

Suspended Wait (resident)

Ein Prozess wird durch einen anderen Prozess in einen Wartezustand versetzt.

Suspended Wait (ausgelagert)

Ein suspendierter Prozess wird aus dem Hauptspeicher ausgelagert.

Resource Wait Der Prozess wartet auf verschiedene Systemressourcen.

3.6 Das Betriebssystem VAX/VMS verwendet zur Vereinfachung des Schutzes und dergemeinsamen Nutzung von Systemressourcen unter den Prozessen vier Prozesszu-griffsmodi. Der Zugriffsmodus ist entscheidend für die folgenden Punkte:

õ Befehlsausführungsprivilegien: Es wird festgelegt, welche Befehle der Prozes-sor ausführen kann.

õ Speicherzugriffsprivilegien: Es wird festgelegt, auf welche Speicherstellen imvirtuellen Speicher der aktuelle Befehl zugreifen kann.

Die vier Modi heißen wie folgt:

õ Kernel: Führt den Kernel des VMS-Betriebssystems aus. Das beinhaltet dieSpeicherverwaltung, die Interrupt-Behandlung und E/A-Operationen.

õ Executive: Führt viele der Betriebssystemdienstaufrufe aus. Das beinhaltet Rou-tinen für die Verwaltung von Dateien und Aufzeichnungen (Platte und Band).

õ Supervisor: Führt andere Betriebssystemdienste aus, wie z.B. Reaktionen aufBenutzerbefehle.

õ User: Führt Benutzerprogramme und Hilfsprogramme, wie Compiler, Editoren,Linker und Debugger aus.

Ein Prozess, der in einem weniger privilegierten Modus läuft, muss häufig eine Proze-dur aufrufen, die in einem privilegierteren Modus läuft, z.B. wenn ein Benutzerpro-gramm einen Betriebssystemdienst benötigt. Dieser Aufruf wird mit Hilfe einesChange-Mode-Befehls (CHM) erreicht, der einen Interrupt hervorruft, wodurch dieSteuerung an eine Routine im neuen Zugriffsmodus übergeht. Der Rücksprungerfolgt durch die Ausführung eines REI-Befehls (Return from Exception or Interrupt).

a. Zahlreiche Betriebssysteme haben zwei Modi: den Kernel-Modus und denBenutzermodus. Was sind die Vor- und Nachteile der Verwendung von vier stattzwei Modi?

b. Können Sie ein Argument für die Verwendung von sogar noch mehr als vier Modinennen?

3.7 Das in der vorhergehenden Aufgabe angesprochene VMS-Schema wird häufig alsRing Protection Structure (Ringschutz) bezeichnet (siehe Abbildung 3.17). Das ein-fache Kernel/Benutzer-Schema, dass in Abschnitt 3.3 beschrieben wurde, ist eineStruktur mit zwei Ringen. [SILB98] weist in Zusammenhang mit diesem Ansatz aufein Problem hin: Der wesentliche Nachteil der (hierarchischen) Ringstruktur liegt da-

Tabelle 3.12 VAX/VMS-Prozesszustände (Forts.)

➔

➔

Übungsaufgaben 183

rin, dass sie es uns nicht erlaubt, das Need-To-Know-Prinzip durchzusetzen. Beson-ders wenn es notwendig ist, dass auf ein Objekt im Bereich Dj, aber nicht im BereichDi zugegriffen werden kann, muss j < i gewährleistet sein. Das bedeutet aber, dassjedes Segment, auf das in Di zugegriffen werden kann, auch in Dj zugänglich ist.a. Erklären Sie, was genau das Problem ist, auf das sich das vorstehende Zitat

bezieht.b. Schlagen Sie eine Vorgehensweise vor, mit der ein Betriebssystem mit Ringstruk-

tur mit diesem Problem umgehen kann.

Abbildung 3.17 VAX/VMS-Zugriffsmodi

3.8 Abbildung 3.7b lässt darauf schließen, dass sich ein Prozess zur gleichen Zeit jeweilsnur in einer Ereigniswarteschlange befinden kann.

a. Ist es möglich, dass Sie es einem Prozess erlauben möchten, zur gleichen Zeitauf mehr als nur ein Ereignis zu warten? Nennen Sie ein Beispiel.

b. Wie würden Sie in diesem Fall die Warteschlangenstruktur der Abbildung ändern,um dieses neue Merkmal zu unterstützen?

➔

➔


3.9 Bei vielen älteren Computern hatte ein Interrupt zur Folge, dass die Registerwertean festen Orten gespeichert wurden, die mit dem gegebenen Interrupt-Signal inZusammenhang standen. Unter welchen Umständen ist das eine praktikable Vor-gehensweise? Erklären Sie, warum diese Vorgehensweise im Allgemeinen ungüns-tig ist.

3.10 In Abschnitt 3.4 wurde ausgesagt, dass UNIX aufgrund der Tatsache, dass ein Pro-zess, der im Kernel-Modus läuft, nicht verdrängt werden kann, für Echtzeitanwen-dungen ungeeignet sei. Führen Sie dies näher aus.

➔

Documents

Prozesse - pearson.ch fileTeil 2 Prozesse Darum geht es in Teil 2 Die wichtigste Aufgabe moderner Betriebssysteme ist die Prozessverwaltung. Das Betriebssystem muss den Prozessen Ressourcen