Grundlagen der Betriebssysteme [Reprint 2019 ed.] 9783110843057, 9783110043204


170 56 14MB

German Pages 231 [236] Year 1975

Report DMCA / Copyright

DOWNLOAD PDF FILE

Table of contents :
Vorwort
Inhalt
1. Einleitung
2. Parallele Prozesse
3. Grundmodelle zur Beschreibung und Analyse von Scheduling-Problemen
4. Virtuelle Speicher
Anhang: Mathematische Grundlagen
Literaturverzeichnis
Stichwortverzeichnis
Recommend Papers

Grundlagen der Betriebssysteme [Reprint 2019 ed.]
 9783110843057, 9783110043204

  • 0 0 0
  • Like this paper and download? You can publish your own PDF file online for free in a few minutes! Sign Up
File loading please wait...
Citation preview

Grundlagen der Betriebssysteme von

H. Krayl, E. J. Neuhold, C. Unger

W DE

G_ 1975

Walter de Gruyter • Berlin • New York

SAMMLUNG GÖSCHEN 2051

Dipl.-Ing. H.

Krayl

Wissenschaftlicher M i t a r b e i t e r in der F o r s c h u n g s g r u p p e J o p C o n t r o l L a n g u a g e s an der Universität S t u t t g a r t D r . Erich

].

Neuhold

P r o f e s s o r für I n f o r m a t i k - S o f t w a r e Leiter der F o r s c h u n g s g r u p p e P r o g r a m m - und S y s t e m s t r u k t u r e n Geschäftsführender D i r e k t o r des Instituts für I n f o r m a t i k an der Universität Stuttgart D r . Claus

Utiger

Leiter der F o r s c h u n g s g r u p p e J o p C o n t r o l L a n g u a g e s an der Universität S t u t t g a r t

© Copyright 1975 by Walter de Gruyter & Co., vormals G. J . Göschen'sche Verlagshandlung, J . Guttentag, Verlagsbuchhandlung, Georg Reimer, Karl J . Trübner, Veit &c. Comp., 1 Berlin 30 - Alle Rechte, insbesondere das Recht der Vervielfältigung und Verbreitung sowie der Ubersetzung, vorbehalten. Kein Teil des Werkes darf in irgendeiner Form (durch Fotokopie, Mikrofilm oder ein anderes Verfahren) ohne schriftliche Genehmigung des Verlages reproduziert oder unter Verwendung elektronischer Systeme verarbeitet, vervielfältigt oder verbreitet werden - Printed in Germany - Satz und Druck: Mercedes-Druck, 1 Berlin 61 - Bindearbeiten: Berliner Buchbinderei Wübben 8c Co., 1 Berlin 42 ISBN 3 11 004320 3

Vorwort Das vorliegende Buch entstand aus einem Manuskript zu einer dreistündigen, einsemestrigen Vorlesung für Informatik-Studenten nach dem Vordiplom. Der Inhalt orientiert sich nur wenig an bestehenden Betriebssystemen; die Verfasser beabsichtigten vielmehr, grundsätzliche theoretische Modelle zur Darstellung von Teilkomponenten anzugeben und so die Grundlagen zum systematischen Verstehen bestehender und zukünftiger Betriebssysteme zu schaffen. Besonderer Wert wurde auf die Herleitung der angesprochenen Ergebnisse gelegt, um den Leser so in die Lage zu versetzen, analoge Modelle mit analogen Methoden analysieren zu können. Bei komplexeren Beweisen wurden zumindest die wesentlichen Beweisgedanken angegeben, so daß der Leser leicht in der Lage sein sollte, die angedeuteten Beweise selbst in der gewünschten Schärfe nachzuvollziehen. Dieses Vorgehen schloß die Möglichkeit eines ,State of the art reports' aus, auch die Literaturliste enthält im wesentlichen nur Referenzen, die im Text verwendet' wurden. Das Buch gliedert sich in drei Teile: — Der erste Teil beschäftigt sich mit parallelen Prozessen und behandelt Probleme des Parallelismus, der Kommunikation und Synchronisation gleichzeitig aktiver Benutzer sowie der Zuteilung von Betriebsmitteln. — Der zweite Teil behandelt allgemeine Scheduling-Strategien, mit Hilfe derer bestimmt wird, in welcher Reihenfolge ein Betriebsmittel einzelnen Benutzern zugeteilt wird. — Im dritten Teil wird schließlich auf die Verwaltung eines virtuellen Speichers eingegangen; verschiedene Seiten-Verfahren werden erläutert und anhand mathematischer Modelle verglichen. Der begrenzte Umfang des Buches machte es notwendig, auf einige weitere wichtige Problemkreise wie Eingabe-/Ausgabe-

2

Vorwort

Probleme oder deterministische Modelle der BetriebsmittelVergabe zu verzichten. Z u m Verständnis der angeschnittenen Probleme ist es nützlich, wenn der Leser Kenntnisse über eine höhere Programmiersprache besitzt sowie als Benutzer einige Erfahrungen im Umgang mit Betriebssystemen, etwa auf der Ebene von K o m m a n d o sprachen, gesammelt h a t . Da sich ein großer Teil des Buches mit Warteschlangen-Modellen b e f a ß t , sollte der Leser elementare Kenntnisse in der Wahrscheinlichkeitstheorie besitzen. A u f b a u e n d auf den behandelten S t o f f k ö n n t e n Vorlesungen über bestehende Betriebssysteme oder über G e s a m t k o n z e p t i o n und E n t w u r f von Betriebssystemen durchgeführt w e r d e n . Wir m ö c h t e n nicht versäumen, den Herren H. Beilner u n d B. Ziegler zu danken, die beim E n t w u r f der dem Buch zugrunde liegenden Vorlesung wesentlich mitgearbeitet h a b e n . Dank gebührt ferner den Damen H. Hoss u n d H. Sonnenschein für die o f t mühevolle Reinschrift des Manuskripts. Institut für Informatik Universität Stuttgart

H. Krayl E . J . Neuhold ^ jjnger

Inhalt 1. Einleitung 1.1 Prozesse 1.2 Betriebsmittel (resources) 1.3 Parallele Prozesse 1.4 Scheduling 1.5 Hauptspeicherverwaltung 1.5.1 Verwaltung des realen Speichers . . 1.5.2 Verwaltung des virtuellen Speichers .

5 9 10 13 15 17 17 18

2. Parallele Prozesse 2.1 Einleitung 2.2 Determiniertes Prozeßsystem 2.3 Wechselseitiger Ausschluß 2.3.1 Dekker/Dijkstra-Algorithmus . . . . 2.3.2 Enqueue und dequeue 2.3.3 Interrupt-Mechanismen 2.4 Synchronisierung 2.4.1 Binäre Semaphore 2.4.2 Das Erzeuger-Verbraucher Problem . 2.4.3 „Await"- und „Cause"-Operationen . . 2.5 Deadlock (Verklemmung) 2.5.1 Verhindern von Deadlocks . . . . 2.5.2 Entdecken und Beseitigen von Deadlocks 2.5.3 Vermeiden von Deadlocks

20 . . . . . . . . . . . . . .

3. Grundmodelle zur Beschreibung und Analyse von SchedulingPioblemen 3.1 Einleitung 3.2 Das allgemeine System . 3.2.1 Beschreibung . 3.2.2 Der Poisson-Prozeß . 3.2.3 Little's Theorem 3.2.4 Belegtzeiten (busy periods) . . . . . 3.2.5 Restbedienwünsche . 3.3 Das M/M/l-System 3.4 Das M/G/l-System 3.5 Nicht unterbrechende Strategien . 3.5.1 Bedienzeitunabhängige Strategien für eine Warteschlange

20 26 43 48 54 56 57 59 65 75 77 90 93 99 105 105 106 106 109 111 112 114 115 120 124 124

Inhalt

4

3.5.2 Verarbeitung nach Prioritäten 3.5.3 Prioritäten aufgrund verlangter Bedienzeiten (Shortest J o b Next) SJN 3.5.4 Strategien unter Berücksichtigung von Wartezeiten 3.6 Unterbrechende Strategien 3.6.1 Das „ R o u n d - R o b i n " (RR)-Modell 3.6.2 Das „Shortest-Elapsed-Time"-(SET)-Modell . . . 3.6.3 „Foreground-Background"-(FBN)-Modelle . . 3.7 Ein numerisches Beispiel 4. Virtuelle Speicher

.

. . .

4.1 Einführung 4.2 Segmentierung 4.2.1 Zuweisungsstrategien 4.2.2 Verschiebung der Segmente 4.3 Seitenverfahren (paging) 4.3.1 Strategien des Seitenverfahrens 4.3.2 Endlicher A u t o m a t 4.3.3 Zugriffsmodell und Markoff-Kette 4.3.4 Das Stack-Modell 4.3.5 Modell der Lokalität und des Arbeitsanteils . . 4.3.6 Stackalgorithmen 4.3.7 Optimale Algorithmen 4.3.8 Vergleich von l.RU, F I F O , A 0 4.3.9 Lokales und globales Verfahren bei Mehrprogrammverarbeitung

126 132 135 140 141 149 153 156 160 160 162 162 167 169 169 174 176 177 184 187 193 196 209

Anhang: Mathematische Grundlagen .

215

A . l Stochastische Prozesse A.2 Markoffketten mit diskretem Parameterraum . . . A.3 Erzeugende (generierende) F u n k t i o n e n und LaplaceTransfonnierte

215 218

Literaturverzeichnis

225

Stichwortverzeichnis

229

222

1. Einleitung Die historische Entwicklung der Betriebssysteme ist mit der Entwicklung der Hardware eng verbunden und durch sie stark motiviert worden. Die ersten Rechner kannten kein eigentliches Betriebssystem; Programme mußten direkt im Maschinencode abgefaßt werden; der Benutzer startete mit einem Tastendruck das Einlesen der zur Ausführung notwendigen Programme und Unterprogramme, stellte die vom Programm benötigten Daten — etwa auf einem Lochstreifenleser — bereit und startete das Programm durch die Bedienung einer weiteren Taste. Die Entwicklung schnellerer und komplexerer Rechner ließ den häufigen menschlichen Eingriff schnell zu kostspielig werden, und es entstanden System-Programme, die dem Benutzer einen Teil seiner Aufgaben abnahmen und ihm den Umgang mit dem Rechner erleichterten. Höhere Programmiersprachen und die zugehörigen Übersetzer erlaubten es dem Benutzer, seine Algorithmen problemnah zu definieren; Binde- und Lade-Programme erstellten aus verschiedenen Programmteilen automatisch ein lauffähiges Gesamtprogramm, das dann auch automatisch gestartet wurde; häufig benutzte Unterprogramme konnten mit Hilfe von maschineninternen Programmbibliotheken allen interessierten Benutzern zugängig gemacht werden Im Laufe der weiteren Entwicklung von Rechnersystemen vergrößerte sich die Anzahl der angeschlossenen E/A-Einheiten, zu deren Steuerung selbständige E/A-Prozessoren (Kanäle) entwickelt wurden. Auch die Verwendung mehrerer parallel arbeitender Prozessoren anstelle eines einzelnen zentralen Rechners gewann an Bedeutung. Es entstand eine dritte Computergeneration, die die Entwicklung einer komplexen und allgemein verwendbaren Software zur Steuerung und Kontrolle der im Rechnersystem auftretenden Abläufe erzwang. Diese Software wurde unter dem

6

1. Einleitung

Begriff „Betriebssystem" zusammengefaßt, zu dem häufig auch Dienstprogramme wie Compiler, Binder etc. gerechnet werden. Wir werden aber in diesem Buch derartige Programme der „äußeren Systemschale" nicht betrachten. Bild 1-1 zeigt eine typische Hardwarekonfiguration, wie sie den Ausführungen dieses Buches zugrunde liegt. Die Prozessoren entnehmen Befehle aus dem Hauptspeicher und verarbeiten sie; der Hauptspeicher enthält Information (Befehle und Daten), auf die schnell zugegriffen werden muß; die E/AProzessoren übernehmen die Steuerung der E/A-Geräte sowie den Datentransport zwischen Hauptspeicher und externen Speichern oder peripheren Geräten. Periphere Geräte stellen über Kanäle die Verbindung zwischen Außenwelt und System her. Zu ihnen gehören Kartenleser und -Stanzer, Drucker, Bildschirm, Datenstation, etc.

Folgende Aufgaben werden üblicherweise einem Betriebssystem zugeordnet: 1. Die Entwicklung und Ausführung von Programmen kann nur in einer geeigneten Umgebung erfolgen; zu ihr gehören Kommandosprachen, Dialogsysteme, Compiler, Testhilfen.

1. Einleitung

7

2. Der Benutzer soll die Erfahrungen anderer Benutzer verwenden können, um in seinem Problemkreis die Lösungsschritte zu vereinfachen. Hierzu sind Programmbibliotheken, Datenbanksysteme etc. notwendig. 3. Die im Rechnersystem zur Verfügung stehenden Hardwarekomponenten müssen verwaltet und möglichst effektiv an mehrere gleichzeitig im System befindliche Benutzer verteilt werden. 4. Viele im System gleichzeitig arbeitende Benutzer müssen koordiniert werden; die Gefahr gegenseitiger Störungen muß vermieden werden, ohne gleichzeitig eine gewünschte Kommunikation zu verhindern. Bei der Realisierung dieser Aufgaben treten immer wieder zwei Problemkreise in Erscheinung: (1) Parallelismus. Im allgemeinen sind in einem Rechnersystem mehrere Benutzerprogramme gleichzeitig aktiv, d. h. sie werden gleichzeitig ausgeführt. Sind mehrere Prozessoren vorhanden, so können diese Programme echt parallel ausgeführt werden. Existiert nur ein Prozessor, so wird durch Verteilung der zur Verfügung stehenden Prozessorzeit auf die aktiven Programme eine quasiparallele Bearbeitung erreicht. Wir nennen dies im Gegensatz zur Parallelausführung Parallelprogrammierung. Neben einer Vielfalt von Strategien zum Informationsaustausch, zur Kooperation von Systembenutzern, zur effizienten Benutzung der Prozessoren etc. sind insbesondere die Einflüsse des Parallelismus auf die Resultate der beteiligten Benutzer zu untersuchen. (2) Informationsspeicherung. Dem Benutzer steht eine Vielzahl verschiedener Speichermedien sowie externer Geräte zur Verfügung. Da im allgemeinen mehrere gleichzeitig aktive Benutzer auf diese Komponenten zugreifen, muß eine wechselseitige Störung vermieden werden. Die Information selbst muß vor fehlerhaftem oder unberechtigtem Zugriff geschützt werden. Wiederum sind eine Reihe von Strategien zur effizienten Verteilung der einzelnen Komponenten auf die aktiven Pro-

8

1. Einleitung

gramme notwendig, ohne daß einzelne Programme permanent auf eine Zuteilung warten müssen. Ein besonderer Problemkreis beschäftigt sich mit Strategien zur optimalen Nutzung des schnellen aber teuren Hauptspeichers im Zusammenhang mit der Auslagerung von Information auf langsamere aber billigere externe Speicher. Der begrenzte Umfang des Buches gestattet nur die Behandlung eines Teils der angeschnittenen Probleme, und auch bei diesen wurden insbesondere die theoretischen Grundlagen betont. Im einzelnen wurden die folgenden Themenkreise ausgewählt: a) der Einfluß von Parallelismus auf die erzeugten Resultate; allgemeine Kriterien zum Vermeiden gegenseitiger Störungen der Benutzer, b) Kommunikation und Synchronisation zwischen gleichzeitig aktiven Benutzern, c) Zuteilung von Betriebsmitteln ohne permanentes Blockieren einzelner Benutzer und ohne gegenseitige Informationsverfälschung, d) wahrscheinlichkeitstheoretische Untersuchungen von Strategien zur Betriebsmittelvergabe, e) Strategien zur effizienten Nutzung des Hauptspeichers unter Verwendung externer Speicher als Hilfsspeicher. Folgende Gebiete wurden nicht berücksichtigt: a) Verhalten und Organisation externer Speichermedien, b) deterministische Strategien zur Betriebsmittel-Vergabe (Job-Shop-Probleme), c) Verfahren zum Datenschutz (Schutz vor Zerstörung, unberechtigtem Zugriff etc.), d) Benutzeraspekte wie Programmiersprachen, Dialogmöglichkeiten, Testhilfen etc. Die folgenden Abschnitte dieser Einleitung sollen allgemein verwendete Begriffe einfuhren und kurz erläutern. Spezielle Definitionen, die sich nur auf einzelne Kapitel beziehen, sind in den entsprechenden Kapiteln enthalten.

9

1.1 Prozesse

1.1 Prozesse Zur Lösung einer Aufgabe eines Rechenmaschinenbenutzers müssen vom Rechnersystem Operationen durchgeführt werden, die mit Hilfe eines oder mehrerer Programme vorgegeben sind. Diese Programme bestehen entweder schon aus Befehlsfolgen im Maschinencode oder werden — falls sie in einer Programmiersprache formuliert sind — in solche Folgen übersetzt. Der Begriff „Befehlsfolge" ist in diesem Zusammenhang irreführend, da zwar einerseits i. a. Abhängigkeiten zwischen den Zeitpunkten bestehen, zu denen gewisse Befehle ausgeführt werden dürfen, andererseits aber auch die Parallelausführung ganzer Programmteile von der Problemstellung her möglich sein kann. Bild 1-2 zeigt ein Beispiel: In einem ersten Programmteil werden Problemparameter eingelesen, anschließend erfolgen von einander unabhängige Matrixoperationen, schließlich werden Ergebnisse auf verschiedenen Geräten ausgegeben.

Bild 1-2

Während das Programm die auszuführenden Operationen beschreibt, benötigen wir eine weitere Größe, die beschreibt, wie die Operationen jetzt wirklich ausgeführt werden. Wir fuhren deshalb den Begriff des Prozesses ein, der seinerseits Aktionen durchführt. Der Begriff des Prozesses ist in der Lite-

10

1. Einleitung

ratur nicht einheitlich definiert, wir wollen uns an obige vage Definition halten, die später in Abschnitt 2 formal präzisiert wird. Wird die Ausführung eines zusammenhängenden Programmblockes begonnen, so entsteht ein Prozeß, nach der Ausführung sämtlicher Operationen des entsprechenden Programmteils verschwindet er wieder. Wir nehmen an, daß zwischen den im Rechnersystem gleichzeitig existierenden Prozessen keine zeitliche Abhängigkeit besteht. Die Einführung des Begriffs Prozeß wird notwendig, da die Ausführung eines Programmteils durch einen anderen gleichzeitig aktiven Benutzer unterbrochen werden kann und für einen späteren Wiederstart des unterbrochenen Prozesses gewisse Informationen über den Zustand des unterbrochenen Prozesses zum Zeitpunkt der Unterbrechung sichergestellt werden müssen. Am Beispiel von Programmen, die von mehreren Benutzern gleichzeitig benutzt werden können (z.B. Compilern), wird klar, daß diese Zustandsinformationen nicht vom Programm, sondern nur von dem individuellen Benutzerprozeß geliefert werden können. Wir werden diesen allgemeinen Prozeßbegriff weiter strukturieren und den Begriff des Teilprozesses einführen. Jeder Prozeß besteht aus Teilprozessen, innerhalb derer Aktionen nur sequentiell ausgeführt werden, ein Parallelismus also nicht mehr möglich ist. Auch für diese Teilprozesse werden wir spezielle Annahmen treffen, so erfolgt die Übernahme der Eingabeparameter grundsätzlich zu Beginn eines Teilprozesses; analog werden Ergebnisse jeweils am Ende des Teilprozesses übergeben.

1.2 Betriebsmittel (resources) Zur Durchführung seiner Aktionen benötigt ein Prozeß Betriebsmittel, die sich anhand verschiedener Kriterien charakterisieren lassen. Wegen ihrer zentralen Bedeutung für die gesamte Betrachtung von Betriebssystemen wird im folgenden kurz auf verschiedene mögliche Klassifizierungen eingegangen.

1.2 Betriebsmittel (resources)

11

Klassifizierung 1: — Hardware-Betriebsmittel: Prozessoren, Hauptspeicher, externer Speicher, periphere Geräte (Drucker, Kartenleser, Bildschirme), Übertragungsleitungen, etc. — Software-Betriebsmittel: Programme, Botschaften (messages), Datenbanken, etc. Oft ist es sinnvoll, nicht nur Hardware- und Software-Einheiten als Betriebsmittel zu betrachten, sondern auch Teile von ihnen (Seiten, Speicherzellen, Dateisätze, Dateielemente) als selbständige Betriebsmittel einzuführen, sobald sie für einzelne Prozesse eine abgrenzbare Bedeutung besitzen. Wartet ein Prozeß auf Ergebnisse eines anderen Prozesses, so kann die Koordinierung über ein einzelnes Bit erfolgen, und es ist im Rahmen unserer Betrachtungen sinnvoll, dieses Bit als Betriebsmittel zu interpretieren. Klassifizierung 2: — Wiederverwendbare Betriebsmittel (reusable resources): Betriebsmittel, die nach der Benutzung durch einen Prozeß wieder verfügbar werden und von weiteren Prozessen angefordert und diesen zugeteilt werden. Beispiele sind Speichersegmente, Sätze in Dateien, etc. — Betriebsmittel zum Verbrauch (consumable resources): Betriebsmittel, die nach ihrer Benutzung für weitere Prozesse keine Bedeutung besitzen und daher verschwinden. Beispiele sind Botschaften, lokale Daten bei Ausführung einer Programmprozedur, etc.

Klassifizierung 3: — Entziehbare Betriebsmittel (preemptible resources): Diese Betriebsmittel können einem Prozeß von außen, d. h. ohne dessen Mitwirkung, entzogen und einem anderen Prozeß zugeteilt werden. Der Zustand des Betriebsmittels zum Zeitpunkt

12

1. Einleitung

des Entzuges kann gerettet und später wieder hergestellt werden. Der Entzug eines Betriebsmittels ist i. a. mit Kosten verbunden, die bei der Entziehungsstrategie zu berücksichtigen sind. Beispiele sind Prozessor (interne Register müssen gerettet werden) und Hauptspeicher (Sicherstellen des Inhalts auf einem externen Speicher ist notwendig), — nicht entziehbare Betriebsmittel (non-preemptible resources): Diese Betriebsmittel unterscheiden sich von entziehbaren Betriebsmitteln vielfach nur durch die Höhe der Kosten, die beim Entzug auftreten. Als Beispiel diene eine Magnetband, dessen Kopieren zum Zwecke des Entzuges sicher unvertretbar aufwendig wäre. Bei anderen Betriebsmitteln ändert sich die Eigenschaft der Entziehbarkeit mit der Zeit; so kann ein Drucker etwa nach Fertigstellen des Ausdrucks eines Teilprozesses (z. B. nach vollendeter Compilation) dem zugehörigen Prozeß unter geringerem Aufwand entzogen werden als während des Ablaufs des Teilprozesses. Nicht entziehbare Betriebsmittel müssen in jedem Fall von dem Prozeß explizit freigegeben werden, der sie benutzt hat.

Klassifizierung 4: — Exklusiv verwendbare Betriebsmittel: Diese Betriebsmittel können nur von einem Prozeß gleichzeitig verwendet werden. Ein typisches Beispiel ist der Drucker. — Nichtexklusiv verwendbare Betriebsmittel: Mehrere Prozesse können dasselbe Betriebsmittel gleichzeitig verwenden; Beispiele sind etwa eine Übertragungsleitung oder eine Datei, auf die mehrere Prozesse gleichzeitig lesend zugreifen. Das zweite Beispiel ist natürlich nur in einer gewissen Vergröberung technologischer Gegebenheiten richtig; auf eine einzelne Speicherzelle kann in der Datei wieder nur eine Leseoperation gleichzeitig angewendet werden, die Leseoperation ist atomar und die Speicherzelle für die Leseoperation nur exklusiv benutzbar. Auf dieses Problem atomarer Operationen werden wir später ausführlich eingehen. Wir wollen ein Be-

1.3 Parallele Prozesse

13

triebsmittel dann als nichtexklusiv benutzbar ansehen, wenn der Zustand des Betriebsmittels, d. h. alle Information, die das Betriebsmittel enthält, durch einen Prozeß nicht verändert wird. Soll eine Datei zum Schreiben verwendet werden, muß sie natürlich i. a. zu den exklusiv benutzbaren Betriebsmitteln gezählt werden. 1.3 Parallele Prozesse Da in unserem Rechnersystem viele Prozesse gleichzeitig existieren, andererseits aber Betriebsmittel nur in beschränkter Anzahl vorhanden sind, spielt die effektive Verwaltung dieser Betriebsmittel eine wichtige Rolle. Zur besseren Ausnutzung vor allem von Prozessoren und weiteren teuren HardwareBetriebsmitteln werden Strategien für die Zuteilung dieser Betriebsmittel an Prozesse entwickelt. Die Existenz entziehbarer Betriebsmittel macht es notwendig, Prozesse anhalten und wieder starten zu können. Für diesen Zweck müssen Prozesse unterbrechbar (interruptable) sein. Unterbrechungen (interrupts) können jedoch auch andere Ursachen haben. Wir unterscheiden a) interne Ursachen: Datenfehler, Programmfehler, Hardwarefehler, programmierte Interrupts (on-condition in PL/1), etc. b) externe Ursachen: Einschalten eines Terminals, Eingriffe durch den Operateur, Eingabe/Ausgabe-Unterbrechungen, Zeitgeber-Unterbrechungen, etc. Beim Auftreten einer Unterbrechung wird die Ausfuhrung des betroffenen Prozesses gestoppt und ein spezieller Prozeß, der Interruptverarbeitungsprozeß wird gestartet. Um zu verhindern, daß das Auftreten weiterer gleichartiger Unterbrechungen Störungen verursacht, ist der Interruptverarbeitungsprozeß i. a. nicht unterbrechbar (uninterruptable) durch Unterbrechungen gleicher Art; er ist ein Beispiel für eine komplexe atomare Operation. Neben der Behandlung von Interrupts tritt eine Reihe weiterer Koordinierungsprobleme auf, für die in Systemen der 3. Generation oft nur sehr wenig hardwaremäßige

14

1. Einleitung

Unterstützung vorhanden ist, die also durch geeignete Softwareentwicklung gelöst werden müssen. In Abschnitt 2 wird ein formales System entwickelt, das die theoretische Untersuchung folgender vier Problemkreise ermöglicht: (1) Determinierte Prozeßsysteme: Wir werden Bedingungen untersuchen, die die Prozesse eines Prozeßsystems erfüllen müssen, damit die einzelnen Aktionen und die durch sie bestimmten Betriebsmittelzustände unabhängig von der Ausfiihrungsgeschwindigkeit der beteiligten Prozesse sind. Zusätzlich können Algorithmen angegeben werden, die es gestatten, Prozeßsysteme umzuformen, um den möglichen Parallelismus eines Prozeßsystems maximal auszunutzen, ohne dabei die Forderung der Determiniertheit zu verletzen. (2) Wechselseitiger Ausschluß: Hier werden Hilfsmittel und Algorithmen entwickelt, die die gegenseitige Störung von Prozessen bei der Benutzung exklusiv verwendbarer Hilfsmittel verhindern. (3) Synchronisierung: Im Falle, daß parallel ablaufende Prozesse oder Teilprozesse Informationen austauschen wollen, müssen von den Prozessen mit Hilfe des Systems Hinweise gegeben werden, die anzeigen, daß auf bestimmte Ereignisse gewartet wird, beziehungsweise, daß gewisse Ereignisse schon eingetreten sind. Auf die Unsymmetrie der Belange von Informations-Verbrauchern und -Erzeugern muß bei der Entwicklung geeigneter Algorithmen besonders Rücksicht genommen werden. (4) Deadlockproblerne: Wegen der begrenzten Anzahl vorhandener Betriebsmittel kann bei ungeschickter Verteilung der Betriebsmittel der Fall eintreten, daß mehrere Prozesse wechselseitig auf die Freigabe nicht entziehbarer Betriebsmittel anderer Prozesse warten und schließlich kein Prozeß eine weitere Aktion ausführen kann. Diesen Zustand bezeichnet man als Deadlock (Verklemmung). Wir werden Algorithmen zum Vermeiden bzw. Entdecken und Beseitigen von Deadlocks diskutieren.

1.4 Scheduling

15

Unsere gesamten Untersuchungen sind sowohl auf Systeme mit Parallelausflihrung wie auf Systeme mit Parallelprogrammierung anwendbar. Wir treffen jedoch die Annahme, daß •Zugriffe auf Betriebsmittel auf niedrigster Ebene prinzipiell nicht gleichzeitig erfolgen können und daß daher für entsprechende Aktionen stets eine zeitliche Aufeinanderfolge gefunden werden kann. Unter der Annahme, daß jede betriebsmittelbenutzende Aktion neben externen Speichern und Geräten auch den Hauptspeicher des Systems benötigt, berücksichtigt diese Beschränkung lediglich die bekannten physikalischen Eigenschaften des Hauptspeichers eines Systems. 1.4 Scheduling Bei der Vergabe von Betriebsmitteln ergibt sich laufend die Situation, daß mehrere Prozesse gleichzeitig auf die Zuteilung desselben Betriebsmittels warten. In diesem Falle muß anhand einer vorgegebenen Scheduling-Strategie ein Prozeß ausgewählt werden, der nach erfolgter Zuteilung in seiner Ausfuhrung fortfahren kann. Die Auswahlstrategie wird nur in den seltensten Fällen auf die Belange des einzelnen betroffenen Betriebsmittels beschränkt werden können; im allgemeinen werden globale Gesichtspunkte wie Synchronisierungsforderungen oder Deadlocküberlegungen eine entscheidende Rolle spielen. Im Prinzip können bei jedem exklusiv benutzbaren Betriebsmittel Scheduling-Probleme auftreten, in der Literatur werden jedoch hauptsächlich zwei Problemkreise unterschieden, die von zwei speziellen Systemprozessen zentral behandelt werden: (1) In der Eingangs-Warteschlange befindliche Prozesse müssen in einer gewissen Reihenfolge rechenbereit gemacht werden, indem ihnen angeforderte externe Betriebsmittel (Bänder, Platten, etc.) zugewiesen werden. Für seine Auswahl wird der zugehörige Systemprozeß Kriterien der folgenden Art verwenden: - voraussichtliche Laufzeiten der wartenden Prozesse — bereits absolvierte Wartezeiten 2 Krayl/Neuhold/Unger, Gründl, d. Betriebssysteme

16

1. Einleitung

— externe Prioritäten — Umlauf der Betriebsmittelbedürfnisse — Typ der zu wertenden Prozesse (Realzeitforderungen, Dialogbedürfnisse, etc.). (2) Ein zweiter Systemprozeß, oft auch Dispatcher genannt, hat die Aufgabe, aus mehreren rechenwilligen wartenden Prozessen einen Prozeß auszuwählen und ihm einen Prozessor zuzuteilen. Dabei kann diese Zuteilung nicht entziehbar oder entziehbar erfolgen. Mögliche Strategien für den Dispatcher werden neben den oben genannten Gesichtspunkten etwa die folgenden Kriterien berücksichtigen: — gute Auslastung von Kanälen und peripheren Geräten — gleichmäßige Aufteilung der Prozessoren auf wartende Prozesse gleicher Eigenschaften (z. B. Dialogprozesse) — erträglicher Overhead bei häufigem Wechsel der ProzessorZuordnung. Bei der Lösung der angeschnittenen Scheduling-Probleme lassen sich zwei Lösungsansätze unterscheiden: a) Algorithmen, die sich darauf beschränken, zu einer fest vorgegebenen Konstellation wartender Prozesse eine — in welchem Sinne auch immer — optimale Vergabe der betroffenen Betriebsmittel zu gewährleisten. Ihnen liegen deterministische Modelle und Verfahren des Operations Research zugrunde. Derartige Modelle werden in dem vorliegenden Buch nicht untersucht, der interessierte Leser sei auf das Buch von Conway u.a. [3.5] verwiesen, das auch ein umfangreiches Literaturverzeichnis enthält. b) Da das Verhalten einzelner Prozesse im allgemeinen nicht vorhersagbar ist, bietet es sich an, anhand stochastischer Modelle die Eigenschaften dieser Prozesse zu erfassen und entsprechende Strategien zu entwickeln. Die Lösung dieser Probleme benutzt in starkem Maße Ergebnisse und Methoden aus der Warteschlangen-Theorie, die ihrerseits eine Teildisziplin der Theorie stochastischer Prozesse darstellt. Bis heute

1.5 Hauptspeicherverwaltung

17

sind, im Vergleich zur Komplexität der bei Betriebssystemen auftretenden Probleme, nur vergleichsweise einfache Modelle theoretisch untersucht und analysiert worden, da die Behandlung komplexerer Probleme auf erhebliche mathematische Schwierigkeiten stößt. In Kapitel 3 wird deshalb nur eine Reihe einfacher Grundmodelle behandelt, die im Falle eines zu realisierenden Betriebssystems dann zu umfassenden Modellen zusammengesetzt werden müssen. Ihr endgültiges Zusammenspiel kann jedoch bestenfalls mit Methoden der Simulation erfaßt und optimiert werden. 1.5 Hauptspeicherverwaltung Sobald ein Rechensystem mehrere Prozessoren bzw. vom 'Hauptprozessor unabhängige Kanäle besitzt und somit Parallelverarbeitung erlaubt, ist es sinnvoll, Prozesse mehrerer Benutzer gleichzeitig rechenbereit im Hauptspeicher zu halten. Hierdurch entstehen zwei Problemkreise: 1.5.1 Verwaltung des realen Speichers Die einfachste Möglichkeit, mehrere Benutzer gleichzeitig im Hauptspeicher zu halten, besteht darin, jedem Benutzer einen festen Teil des Hauptspeichers zuzuteilen und es ihm zu überlassen, durch entsprechende Overlay-Techniken diesen Teil gut auszunutzen. Die eigentlichen schwierigen Verwaltungsaufgaben werden hierbei dem Benutzer zugeschoben, der bei einer jeden Programmänderung seine Overlay-Struktur neu überprüfen muß. Betriebssystem-Änderungen werden problematisch, sobald sie die Hauptspeicher-Aufteilung zwangsläufig verändern. Da die einzelnen Prozesse den ihnen zugewiesenen Hauptspeicherplatz zu unterschiedlichen Zeiten freigeben, entstehen nach kurzer Zeit Lücken in der Hauptspeicherbelegung, die ihrerseits eine schlechte Auslastung des Hauptspeichers zur Folge haben. Als Ausweg bietet sich an, die Programme von Zeit zu Zeit im Hauptspeicher zusammenzuschieben (garbage collection), um so die entstandenen Lücken zu einem größeren zusammenhängenden Speicherbereich zusammen-

18

1. Einleitung

zufassen. Diese Technik setzt jedoch voraus, daß die einzelnen Programme verschiebbar (relocatable) programmiert sind, z. B. nur relative Adressen bezogen auf den Programmanfang besitzen. Da diese im Zusammenhang mit dem realen Speicher angeschnittenen Probleme beim virtuellen Speicher wiederum als Teilprobleme auftreten, werden wir sie nicht gesondert untersuchen. 1.5.2 Verwaltung des virtuellen Speichers Der virtuelle Speicher kann als Hauptspeicher eines virtuellen Rechensystems interpretiert werden, der auf einem Hintergrundspeicher simuliert wird und wesentlich größer ist als der Hauptspeicher des realen Rechensystems. Der Adreßraum des virtuellen Speichers umfasse die virtuellen Adressen VA, der Adreßraum des realen Hauptspeichers die physikalischen Adressen PA. Mit Hilfe einer zeitabhängigen Abbildungsfunktion f t (VA) : VA t -> PA wird jeweils eine Teilmenge VA t des virtuellen Adreßraums auf den physikalischen Adreßraum abgebildet. Einem realen Adreßraum stehen i. a. mehrere virtuelle Adreßräume verschiedener Prozesse gegenüber. Es entsteht das Problem, sowohl die virtuellen Adreßräume als auch den physikalischen Adreßraum aufzuteilen und diese Teile beider Adreßräume einander zeitabhängig zuzuordnen. Wir unterscheiden hierbei im wesentlichen zwei Methoden: - Bei der Segmentierung werden die Adreßräume in logische Einheiten (z.B. Programmsegmente, Unterprogramme, . . .) unterschiedlicher Größe aufgeteilt. — Beim Seitenverfahren werden die Adreßräume ohne Rücksicht auf die Struktur des Programms in Einheiten fester Größe (Seiten) aufgeteilt. Spricht ein Prozeß eine virtuelle Adresse an, der durch f t keine Hauptspeicheradresse zugewiesen ist, so wird ein Interrupt signalisiert und mit Hilfe eines System-Prozesses der benötigte Programmteil in den Hauptspeicher geladen.

19

1 . 5 Hauptspeicherverwaltung

Zur Realisierung eines Seitenverfahrens werden die Adressen i. a. hierarchisch aufgebaut. Der erste Teil einer Adresse enthält die sogenannte Seitenadresse, der zweite Teil die Wortadresse innerhalb dieser Seite. Analog definiert f t nicht mehr die Zuordnung einzelner virtueller und realer Adressen, sondern lediglich die Zuordnung virtueller und realer Seiten; f t wird in Form einer Seitentabelle dargestellt. Bild 1-3 zeigt den Adressierungsvorgang, wenn sich die angesprochene virtuelle Seite bereits im Hauptspeicher befindet. Die oft benötigten Teile der Seitentabelle werden häufig in einem Assoziativregister gespeichert, um die Tabellensuchzeiten gering zu halten. Bei Segmentierungs-Verfahren erfolgt die Adressierung analog. Seitentabelle

Bild 1-3. Adressierungsvorgang beim S e i t e n v e r f a h r e n va: pa: s: w: ft(s):

virtuelle Adresse physikalische Adresse virtuelle Seitenadresse virtuelle W o r t a d r e s s e physikalische Seitenadresse

Die Effektivität eines virtuellen Speichers hängt wesentlich von den Strategien ab, die den Informationstransport zwischen Haupt- und Hintergrundspeicher organisieren. Getrennt

20

2. Parallele Prozesse

nach ihren Aufgaben unterscheidet man drei Klassen von Strategien: (1) Die Einlagerungsstrategie bestimmt den Zeitpunkt und die Seiten bzw. Segmente, die zu diesem Zeitpunkt in den Hauptspeicher einzulagern sind. (2) Die Zuweisungsstrategie bestimmt, in welchem freien Teil des Hauptspeichers die von der Einlagerungsstrategie bestimmten Seiten bzw. Segmente einzulagern sind. (3) Die Ersetzungsstrategie bestimmt, welche Seiten oder Segmente des Hauptspeichers auszulagern sind, damit die neuen Seiten bzw. Segmente eingelagert werden können. Bei Segmentierungsverfahren spielen vor allem Zuweisungsstrategien eine wichtige Rolle, bei Seitenverfahren kommen in erster Linie Einlagerungs- und Ersetzungsstrategien zum Einsatz. Alle Verfahren versuchen, durch eine Analyse des Programmverhaltens in der Vergangenheit Informationen für die Seitenanforderungen in der Zukunft zu erhalten, um so die Zahl der Seitenwechsel zu minimieren. Vereinfachte Modellannahmen fuhren zu bezüglich dieser Modelle optimalen Algorithmen. Dabei spielt die Tatsache eine Rolle, daß sich die Adressierungsanforderungen eines Prozesses i. a. „lokal" verhalten, d. h. daß über eine längere Zeit oft nur ein relativ kleiner Teilraum des virtuellen Adreßraums eines Prozesses angesprochen wird.

2. Parallele Prozesse 2.1 Einleitung Parallele oder quasiparallele Prozeßausführung verursacht bei der Verteilung der Betriebsmittel des Systems eine Reihe von Koordinationsproblemen, die in diesem Abschnitt näher untersucht werden sollen. Zu ihrer Lösung wird es im allgemeinen notwendig sein, eine geeignete Ausführungsreihenfolge der

21

2.1 Einleitung

einzelnen Prozesse und Prozeßteile zu erzwingen, die garantiert, daß die gegenseitige Beeinflussung der Prozesse sich nicht auf die von den Prozessen erstellten Resultate in unerwünschter Weise auswirkt. Für Prozesse (oder Teilprozesse), die sich ihrer gegenseitigen Existenz nicht bewußt sind, z. B. zwei Benutzerprozesse eines interaktiven Systems, müssen diese Koordinationsaufgaben vom Betriebssystem gelöst werden. Falls jedoch den Prozessen ihre gegenseitige Existenz bekannt ist, kann zumindest ein Teil der Aufgaben durch geeignete programmiersprachliche Hilfsmittel an die Programmierer oder Compiler übertragen werden. Für unsere Untersuchungen erweitern wir den im vorhergehenden Kapitel eingeführten Prozeßbegriff auf ein Prozeßsystem, das in ähnlicher Weise von J. L. Baer [2.1] für parallele Programmschemata und von E. J. Neuhold [2.27] für formale Beschreibungen von Betriebssystemen eingeführt wurde. Ein Prozeßsystem

ist durch das Tripel

. .. , P m } . Je nach dem untersuchten Koordinationsproblem ist diese Menge entweder a priori gegeben, oder es können Prozesse dynamisch verschwinden, beziehungsweise neu hinzukommen. Dabei werden jedoch keine Untersuchungen über die Ursachen solcher Veränderungen, das heißt, die ERZEUGE/VERNICHTE-PROZESS-Operationen, angestellt. Die Menge S charakterisiert die Zustände der Betriebsmittel des Prozeßsysteim. Diese setzen sich aus den globalen Betriebsmitteln -" B = (W, b 2 , . . . , b n )

n > 1

22

2. Parallele Prozesse

und den für die einzelnen Prozesse Pj, 1 < j < m lokalen Betriebsmitteln Bj.= (bji. bj2, • • • , b j n j ) nj > 0 zusammen. Dabei entsprechen die lokalen Betriebsmittel am ehesten den in konventionellen Programmsystemen auftretenden lokalen Datenstrukturen. Jedem der Betriebsmittel bj und bj, werden Werte aus einem Wertevorrat Vj beziehungsweise Vjj zugeordnet. Je nach Art des Betriebsmittels können diese Werte einfacher Bauart sein, zum Beispiel der numerische Inhalt einer Speicherzelle, oder auch sehr komplexe Struktur aufweisen, wie zum Beispiel die auf einem Bildschirm dargestellten Objekte, oder die auf einem Drucker ausgegebenen Protokolle. Informationen über die physikalische Konfiguration von Betriebsmitteln und Steuerungsinformationen werden ebenfalls zu diesen Werten gerechnet. Die Menge B ist für das Prozeßsystem a priori gegeben, Veränderungen von B können bei den hier untersuchten Problemkreisen nicht auftreten. Bei der Erzeugung und Zerstörung einzelner Prozesse werden jedoch lokale Betriebsmittelmengen neu auftreten bzw. aus dem System verschwinden. Jedes Element von S stellt eine mögliche Wertebelegung der Betriebsmittel dar und wird als Zustand bezeichnet. S ist daher als Menge von N-tupeln O l , v2, . . . , vn, v n , v12, . . . v l n i , . . . , Vim,V2m, • • • ,

v

mnm)

m

definiert; dabei gilt N = n + 2 nj, v; S V i ; 1 < i < n, und j=i

vji G Vjj, 1 < i < n j ; 1 < j < m. s 0 ist Element von S und stellt den Anfangszustand des Prozeßsystems dar. Er setzt sich aus den Anfangswerten der globalen und aller a priori existierenden lokalen Betriebsmittel zusammen. Wenn ein neuer Prozeß zum Prozeßsystem dynamisch hinzugefügt wird, werden die Anfangswerte seiner loka-

2.1 Einleitung

23

len Betriebsmittel zum gleichen Zeitpunkt Teil des gerade existierenden Zustandes. Jeder der im Prozeßsystem iP auftretenden Prozesse Pj wird durch ein Paar Pj =

Cj)

beschrieben, wobei gilt: 4>j ist eine Menge partieller

Abbildungsfunktionen

**={fji.fj2,-...fjpj} Pj>l von S auf S, wobei in den Elementen von S nur die Komponenten V,, 1 < i < n, und Vji( 1 < i < nj, benutzt werden dürfen. Alle anderen Komponenten bleiben von den Abbildungsfunktionen fjj, 1 < i < pj, unberührt. Cj ist die Kontrollkomponente des Prozesses Pj und legt die möglichen Ausfuhrungsreihenfolgen der Funktionen fjj im Prozeß Pj fest. Diese Komponente entspricht dem auszuführenden Programm in einem konventionellen Programmsystem. Um die Kooperation der Prozesse und die gegenseitige Beeinflussung durch die gemeinsam verwendeten Betriebsmittel untersuchen zu können, wird es notwendig werden, über die einzelnen Komponenten des Prozeßsystems weitere Aussagen zu machen und die bis jetzt allgemein gehaltenen Definitionen weiter einzuschränken. Diese Einschränkungen werden jedoch je nach dem untersuchten Problemkreis verschieden sein und dürfen daher nicht in die grundsätzliche Definition des Prozeßsystems übernommen werden. Bei den Einschränkungen werden jeweils nur die zur Problemlösung unmittelbar benötigten Details festgelegt. Alle anderen Komponenten werden entweder ganz vernachlässigt, oder sie bleiben weiterhin unspezifiziert. Eine Ausführung im Prozeßsystem (P wird durch eine Folge von ausgeführten Funktionsanweisungen (Aktionsfolge) a = f j f2 . . . f k , fie$

1

u$

2

u...u$

m

, l k i=1

j=m e +l

gilt, dann gibt es keine Aktionsfolge a in