Systemnahe Programmierung

Systemnahe Programmierung 

Johann Schlichter 

Institut für Informatik 

TU München, Munich, Germany 

Oktober 2003 

Vorlesungsunterlagen 

(Student Script 1 ) 

1 Script generated by Targeteam; Not for general Distribution

Inhaltsverzeichnis 

1 Übersicht 2 

1.1 Ziel der Vorlesung . . . . . . . . . . . . . . . . . . . . . . . . . . 2 

1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 

1.2.1 Anforderungen an Rechensysteme . . . . . . . . . . . . . 3 

1.2.2 Struktur eines Rechensystems . . . . . . . . . . . . . . . 6 

1.3 Themen der Vorlesung . . . . . . . . . . . . . . . . . . . . . . . 8 

1.3.1 Laufzeitmodell . . . . . . . . . . . . . . . . . . . . . . . 8 

1.3.2 Inhaltsübersicht . . . . . . . . . . . . . . . . . . . . . . . 9 

1.4 Literaturübersicht . . . . . . . . . . . . . . . . . . . . . . . . . . 10 

1.4.1 Begleitend zur Vorlesung . . . . . . . . . . . . . . . . . . 10 

1.4.2 Begleitend zur Übung . . . . . . . . . . . . . . . . . . . 10 

1.4.3 Weiterführende Literatur . . . . . . . . . . . . . . . . . . 10 

2 Rechner und hardwarenahe Programme 12 

2.1 Fragestellungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 

2.2 von Neumann Rechner . . . . . . . . . . . . . . . . . . . . . . . 12 

2.3 Architektur sequentieller Rechner . . . . . . . . . . . . . . . . . 14 

2.3.1 Blockdiagramm für eine Architektur . . . . . . . . . . . . 14 

2.3.2 Befehlsgrundzyklus . . . . . . . . . . . . . . . . . . . . . 17 

2.3.3 E/A Architekturvarianten . . . . . . . . . . . . . . . . . . 18 

2.3.4 Architektur der MI . . . . . . . . . . . . . . . . . . . . . 19 

2.4 Befehlsvorrat eines Rechners . . . . . . . . . . . . . . . . . . . . 20 

2.4.1 Charakterisierung der Befehle . . . . . . . . . . . . . . . 20 

2.4.2 Aufbau Maschinenbefehle . . . . . . . . . . . . . . . . . 22 

i

Schlichter, TU München INHALTSVERZEICHNIS 

2.4.3 Befehle der MI . . . . . . . . . . . . . . . . . . . . . . . 30 

2.5 Hardwarenahe Programme . . . . . . . . . . . . . . . . . . . . . 34 

2.5.1 Definitionen . . . . . . . . . . . . . . . . . . . . . . . . 34 

2.5.2 Programmaufbereitung . . . . . . . . . . . . . . . . . . . 35 

2.5.3 MI Assemblerprogramm . . . . . . . . . . . . . . . . . . 36 

2.5.4 Assembler Grundfunktionen . . . . . . . . . . . . . . . . 38 

2.5.5 Assemblerläufe . . . . . . . . . . . . . . . . . . . . . . . 40 

2.5.6 Binder und Lader . . . . . . . . . . . . . . . . . . . . . . 44 

2.6 Hardwarenahe Datenstrukturen . . . . . . . . . . . . . . . . . . . 49 

2.6.1 Felder . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 

2.6.2 Programme im Arbeitsspeicher . . . . . . . . . . . . . . . 53 

3 Parallele Systeme 59 


3.2 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 

3.2.1 Begriffsdefinitionen . . . . . . . . . . . . . . . . . . . . 61 

3.2.2 Beschreibungskonzepte . . . . . . . . . . . . . . . . . . . 62 

3.3 Modellierung paralleler Systeme . . . . . . . . . . . . . . . . . . 63 

3.3.1 Modellierungsziele . . . . . . . . . . . . . . . . . . . . . 64 

3.3.2 Verhaltensbeschreibung . . . . . . . . . . . . . . . . . . 65 

3.3.3 Ereignisse und Aktionsstrukturen . . . . . . . . . . . . . 66 

3.3.4 Aktionen als Zustandsübergänge . . . . . . . . . . . . . . 72 

3.3.5 Petri-Netze . . . . . . . . . . . . . . . . . . . . . . . . . 77 

3.4 Thread-Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 

3.4.1 Charakterisierung von Threads . . . . . . . . . . . . . . . 90 

3.4.2 Threads in Java . . . . . . . . . . . . . . . . . . . . . . . 93 

3.5 Synchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 

3.5.1 Beispiele . . . . . . . . . . . . . . . . . . . . . . . . . . 96 

3.5.2 Definition: Wechselseitiger Ausschluss . . . . . . . . . . 98 

3.5.3 Modellierung . . . . . . . . . . . . . . . . . . . . . . . . 99 

3.5.4 Synchronisierungskonzepte . . . . . . . . . . . . . . . . 100 

3.5.5 Semaphore . . . . . . . . . . . . . . . . . . . . . . . . . 105 

3.5.6 Synchronisierung von Java Threads . . . . . . . . . . . . 111 

ii


3.6 Verklemmungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 

3.6.1 Allgemeines . . . . . . . . . . . . . . . . . . . . . . . . 113 

3.6.2 Belegungs-Anforderungsgraph . . . . . . . . . . . . . . . 113 

3.6.3 Verklemmungs-Erkennung . . . . . . . . . . . . . . . . . 114 

3.6.4 Verklemmungs-Vermeidung . . . . . . . . . . . . . . . . 114 

3.6.5 Verklemmungs-Verhinderung . . . . . . . . . . . . . . . 115 

4 Prozess- und Prozessorverwaltung 118 


4.2 Betriebssystem - Überblick . . . . . . . . . . . . . . . . . . . . . 119 

4.2.1 BS-Hauptaufgaben . . . . . . . . . . . . . . . . . . . . . 119 

4.2.2 Systemprogrammierung . . . . . . . . . . . . . . . . . . 120 

4.2.3 Betriebssystem-Architektur . . . . . . . . . . . . . . . . 121 

4.2.4 Betriebsarten . . . . . . . . . . . . . . . . . . . . . . . . 126 

4.3 Prozessverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . 127 

4.3.1 Prozesskonzept . . . . . . . . . . . . . . . . . . . . . . . 127 

4.3.2 Dispatcher . . . . . . . . . . . . . . . . . . . . . . . . . 131 

4.3.3 Arbeitsmodi . . . . . . . . . . . . . . . . . . . . . . . . 132 

4.3.4 Systemaufrufe . . . . . . . . . . . . . . . . . . . . . . . 133 

4.3.5 Realisierung von Threads . . . . . . . . . . . . . . . . . 137 

4.4 Prozessorverwaltung . . . . . . . . . . . . . . . . . . . . . . . . 140 

4.4.1 Kriterien . . . . . . . . . . . . . . . . . . . . . . . . . . 140 

4.4.2 Scheduling-Strategien . . . . . . . . . . . . . . . . . . . 141 

4.4.3 Beispiel Unix Scheduling . . . . . . . . . . . . . . . . . 144 

4.4.4 Thread Scheduling . . . . . . . . . . . . . . . . . . . . . 145 

4.4.5 Mehrschichtiges Scheduling . . . . . . . . . . . . . . . . 147 

4.4.6 Echtzeit Scheduling . . . . . . . . . . . . . . . . . . . . 148 

4.5 Unterbrechungskonzept . . . . . . . . . . . . . . . . . . . . . . . 150 

4.5.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 150 

4.5.2 Unterbrechungsarten . . . . . . . . . . . . . . . . . . . . 151 

4.5.3 Behandlung externer Unterbrechungen . . . . . . . . . . 153 

4.5.4 Konflikte . . . . . . . . . . . . . . . . . . . . . . . . . . 154 

iii


5 Speicherverwaltung 158 


5.2 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 

5.2.1 Adressräume . . . . . . . . . . . . . . . . . . . . . . . . 159 

5.2.2 Organisation von Adressräumen . . . . . . . . . . . . . . 160 

5.2.3 Fragmentierung . . . . . . . . . . . . . . . . . . . . . . . 162 

5.2.4 Forderungen an Adressraumrealisierung . . . . . . . . . . 164 

5.3 Speicherabbildungen . . . . . . . . . . . . . . . . . . . . . . . . 165 

5.3.1 Direkte Adressierung . . . . . . . . . . . . . . . . . . . . 165 

5.3.2 Basisadressierung . . . . . . . . . . . . . . . . . . . . . . 167 

5.4 Virtueller Speicher . . . . . . . . . . . . . . . . . . . . . . . . . 168 

5.4.1 Seitenadressierung . . . . . . . . . . . . . . . . . . . . . 168 

5.4.2 Segment-Seitenadressierung . . . . . . . . . . . . . . . . 179 

5.4.3 Speicherverwaltung der MI . . . . . . . . . . . . . . . . . 180 

6 Dateisysteme 182 


6.2 Charakteristika von Dateisystemen . . . . . . . . . . . . . . . . . 183 

6.3 Dateien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 

6.4 Memory-Mapped Dateien . . . . . . . . . . . . . . . . . . . . . . 187 

6.5 Verzeichnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 

6.6 Schichtenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . 188 

6.6.1 Datenträgerorganisation . . . . . . . . . . . . . . . . . . 188 

6.6.2 Blockorientiertes Dateisystem . . . . . . . . . . . . . . . 189 

6.6.3 Dateiverwaltung . . . . . . . . . . . . . . . . . . . . . . 189 

6.7 Einbettung der E/A . . . . . . . . . . . . . . . . . . . . . . . . . 190 

7 Prozesskommunikation 191 


7.2 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 

7.2.1 Kommunikationsarten . . . . . . . . . . . . . . . . . . . 192 

7.2.2 Verteilte Systeme . . . . . . . . . . . . . . . . . . . . . . 196 

7.3 Nachrichtenbasierte Kommunikation . . . . . . . . . . . . . . . . 198 

iv


7.3.1 Elementare Kommunikationsmodelle . . . . . . . . . . . 198 

7.3.2 Erzeuger-Verbraucher Problem . . . . . . . . . . . . . . . 204 

7.3.3 Modellierung durch ein Petrinetz . . . . . . . . . . . . . . 204 

7.3.4 Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 

7.3.5 Kanäle . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 

7.3.6 Ströme . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 

7.4 Client-Server-Modell . . . . . . . . . . . . . . . . . . . . . . . . 208 

7.5 Netzwerkprogrammierung . . . . . . . . . . . . . . . . . . . . . 210 

7.5.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . 211 

7.5.2 Server Protokoll . . . . . . . . . . . . . . . . . . . . . . 212 

7.5.3 Client Protokoll . . . . . . . . . . . . . . . . . . . . . . . 213 

7.5.4 Bidirektionale Stromverbindung . . . . . . . . . . . . . . 214 

7.5.5 Java Socket Class . . . . . . . . . . . . . . . . . . . . . . 214 

7.6 Remote Procedure Call . . . . . . . . . . . . . . . . . . . . . . . 216 

8 Sicherheit in Rechensystemen 223 


8.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 

8.3 Schutzmechanismen . . . . . . . . . . . . . . . . . . . . . . . . 228 

8.3.1 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . 228 

8.3.2 Ebenen des Zugriffschutzes . . . . . . . . . . . . . . . . 229 

8.3.3 Schutzmatrix . . . . . . . . . . . . . . . . . . . . . . . . 229 

8.4 Sicherheit in verteilten Systemen . . . . . . . . . . . . . . . . . . 234 

8.4.1 Unsicherheitsfaktoren in verteilten Systemen . . . . . . . 234 

8.4.2 Sicherheitsanforderungen . . . . . . . . . . . . . . . . . 235 

8.4.3 Kryptographie . . . . . . . . . . . . . . . . . . . . . . . 236 

8.4.4 Authentifizierungsdienst Kerberos . . . . . . . . . . . . . 240 

8.4.5 Mobiler Code . . . . . . . . . . . . . . . . . . . . . . . . 245 

9 Zusammenfassung 248 

v


¯ Prof. J. Schlichter 

– Lehrstuhl für Angewandte Informatik / Kooperative Systeme, Fakultät für 

Informatik, TU München 

– Boltzmannstr. 3, 85748 Garching 

Email: schlichter@in.tum.de (URL: mailto:schlichter@in.tum.de) 

Tel.: 089-289 18654 

URL: http://www11.informatik.tu-muenchen.de/ 

1

Kapitel 1 

Übersicht 

1.1 Ziel der Vorlesung 

Diese Vorlesung beschäftigt sich mit den technischen Aspekten von Rechensystemen 

und der Informationsverarbeitung, insbesondere der systemnahen Programmierung. 

Dabei werden sowohl nicht verteilte als auch verteilte Systeme betrachtet. 

¯ Der erste Teil der Vorlesung behandelt hardwarenahe Programm- und Datenstrukturen. 

Deshalb wird zunächst die Modellmaschine MI (basierend auf einer 

VAX Architektur von vormals Digital Equipment) vorgestellt. Diese Maschine 

dient als Basis zur Diskussion des Aufbaus von typischen Maschinenund 

Assemblerbefehlen. Anhand dieser Modellmaschine wird die Entwicklung 

von Programmen unter Berücksichtigung der jeweiligen Komponenten einer 

Hardwarekonfiguration aufgezeigt. Die einfachen Programme, die zunächst 

entwickelt werden, werden dann zu den Programm- und Datenstrukturen verallgemeinert, 

die heute für hardwarenahe Systemebenen verwendet werden. 

¯ Im nächsten Teil der Vorlesung erfolgt eine wichtige Verallgemeinerung, 

nämlich der Übergang von sequentiellen zu parallelen Systemen und die 

Entwicklung von parallelen Systemen. Zu den Themen, die behandelt werden, 

gehören die Grundlagenprobleme paralleler Systeme und die Verfahren, mit 

denen diese gelöst werden können: Modellierung des Systemverhaltens, 

Synchronisation, Verklemmungen. 

¯ Im Anschluss daran werden Konzepte und Verfahren sowie der Aufbau von 

Betriebssystemen, die der wesentliche Teil der Konkretisierung paralleler Systeme 

sind, behandelt. Insbesondere geht es um die Arbeitsspeicherverwaltung 

2

Schlichter, TU München 1.2. MOTIVATION 

(Hauptspeicherverwaltung, "main memory management"), die Prozessverwaltung 

und die Prozessorzuteilung sowie Mechanismen zur Kontrolle der Nebenläufigkeit. 

¯ Parallele Systeme können auf zentralen Hardwarekonfigurationen realisiert 

werden. Als Basis können aber auch verteilte, vernetzte Hardwarekonfigurationen 

dienen, so dass verteilte Rechensysteme entstehen, die heute durchweg 

im Einsatz sind. Es werden deshalb die grundlegenden Aspekte von verteilten 

Systemen behandelt, insbesondere die nachrichtenbasierte Prozesskommunikation, 

das Client-Server Modell und die Netzwerkprogrammierung. 

¯ Mit der rasanten Verbreitung des Internet und dessen Nutzung für private und 

geschäftliche Transaktionen (E-Commerce und E-Business) steigt der Bedarf 

an sicheren IT-Systemen. Der Abschnitt behandelt nach einigen verbreiteten 

Sicherheitslücken verschiedene Schutzmechanismen, wie Schutzmatrizen, 

Kryptosysteme und Authentifizierungsmechanismen. 

1.2 Motivation 

Aufgabe der Informatik ist es, Rechensysteme zu entwickeln und diese Anwendern 

als leistungsfähige Hilfsmittel für Lösungen ihrer Informationsverarbeitungsprobleme 

zur Verfügung zu stellen. Diese Aufgabe ist vielgestaltig, 

weitreichend, kompliziert und komplex; sie führt im Zuge der Weiterentwicklung 

von Rechensystemen und im Zuge der wachsenden Nachfrage der Gesellschaft 

nach Information fortwährend auf neue Fragestellungen, für die nach Antworten 

gesucht werden muss. Sie hat zudem dazu geführt, dass sich große Bereiche der 

Industrie und der Wirtschaft mit dieser Aufgabe befassen. Im folgenden werden 

zunächst die wichtigsten Anforderungen, die mit der Entwicklung von Rechensystemen 

erfüllt werden sollen, in Kürze genauer erklärt. 

1.2.1 Anforderungen an Rechensysteme 

Rechensysteme sind offene, dynamische, technische Systeme mit Fähigkeiten zur 

Speicherung und zur Verarbeitung von Information, die für Anwendungen und 

Anwender nutzbar zur Verfügung gestellt werden sollen. 

Offenes System 

Ein Rechensystem R ist ein offenes System sagt zweierlei: 

3


¯ R ist als System eine durch Zusammenfassung gebildete, abgegrenzte Einheit. 

Innen ist das, was zu R gehört, und außen ist das, was nicht zu R und damit zur 

Umgebung U(R) gehört. 

¯ R hat eine (offene) Schnittstelle, mit der Einwirkungen von U(R) auf R und 

Einwirkungen von R auf U(R) möglich sind. 

¯ Schnittstelle eines Rechensystems 

Umgebung 

U(R) 

Schnittstelle R - U(R) 

Rechensystem R 

¯ Sichten eines Rechensystems 

Es existieren verschiedene Sichten auf das Rechensystems R 

– Außensicht vs. Innensicht. Die Außensicht, die von außen die Eigenschaften 

der R-U(R) Schnittstelle zeigt, und die Innensicht, welche die inneren 

Eigenschaften von R zeigt. 

– Black-box Sicht vs. White-box Sicht. Das System ist ein schwarzer 

Kasten (black box): Das System wird als einzelner Gegenstand aufgefasst. 

Das System ist ein weißer Kasten (white box oder auch glass box): Für 

das Verständnis des Systems ist die Zusammensetzung in Subsysteme und 

Komponenten wichtig. 

– Sichten sind methodische Hilfsmittel für Systemanalysen: 

£ Komponenten haben Eigenschaften, die denen von Systemen entsprechen. 

Dies bedeutet, Komponenten können für sich als Systeme betrachtet 

werden. 

4


£ Verbindungen zwischen Komponenten beschreiben Abhängigkeiten zwischen 

Komponenten. 

£ Aufteilungen liefern verfeinerte White-box Sichten. 

£ Zusammenfassungen und Abgrenzungen liefern Einheiten, für die Blackbox 

Sichten möglich sind. 

£ Rekursion bei der Entwicklung und Analyse von Rechensystemen. Die 

umrissene Vorgehensweise unter Anwendung der erklärten Systembegriffe 

ist für Analysen großer Systeme geeignet, wenn sie iterativ (rekursiv) 

angewandt wird; sie ist insbesondere dann geeignet, wenn sie induktiv 

angewandt werden kann. Die Möglichkeiten hierfür ergeben sich aus den 

Eigenschaften, die ein gegebenes System hat. Für ein Rechensystem R 

wird über diese Möglichkeiten bei der Entwicklung von R entschieden. 

Die Vorgehensweise bei der Entwicklung von R und die Vorgehensweise 

bei Analysen von R stehen also in engem Zusammenhang. 

Dynamisches System 

Eigenschaften des Rechensystems R ändern sich mit der Zeit 

Beschreibung des Verhaltens von R. 

In diesem Zusammenhang werden wir Beschreibungsmöglichkeiten kennenlernen, 

insbesondere Petrinetze. Diese dienen dazu das Verhalten von Prozessen und 

deren Interaktion zu spezifizieren. Ein Rechensystem erhält seine Fähigkeiten 

zu selbsttätigen Veränderungen seiner Eigenschaften mit entsprechenden Komponenten; 

demnach sind für R aktive und passive Komponenten zu unterscheiden: 

Mit seinen aktiven Komponenten führt R Aktionen aus, die Veränderungen der 

Eigenschaften von R bewirken; die passiven Komponenten sind Hilfsmittel für 

diese Aktionen. 

Technisches System 

Rechensystem ist mit hardware- und softwaretechnischen Mitteln realisiert. R 

ist entweder ein mit technischen Mitteln realisiertes, reales System oder ein 

künstliches, artifizielles System, das die Eigenschaften hat, die es mit seiner 

Entwicklung und mit seinen Weiterentwicklungen erhält. 

Informationsspeicherung und -verarbeitung 

5


Information 

Daten 

Nachricht 

Wissen 

Information 

Repräsentation Interpretation 

Daten 

Daten sind elementare Fakten, Aussagen und Sachverhalte. Sie sind leicht 

zu strukturieren, leicht maschinell zu erfassen und leicht zu übertragen. Im 

Zusammenhang mit der Übertragung spricht man auch gerne von Nachrichten. 

Information sind Daten mit einer Bedeutung und einem Zweck; sie erfordert 

Analyse, Konsens bzgl. Semantik und Interpretation. Wissen ist Information 

in einem bestimmten, für den Menschen relevanten Kontext; es ist schwierig, 

Wissen zu strukturieren, schwierig maschinell zu erfassen und zu verarbeiten. 

Weiterhin ist es schwierig Wissen zu übertragen, da es oft nur implizit existiert 

(siehe auch das neue Forschungsgebiet Wissensmanagement bzw. "Knowledge 

Management"). 

1.2.2 Struktur eines Rechensystems 

6


Datenbank World Wide Web Email 

Shell Übersetzer Dateisystem 

Betriebssystem 

Maschinensprache 

Mikroprogramme / festverdrahtete Programme 

physische Komponenten und Geräte 

Anwendungsprogramme 

Systemprogramme 

Hardware 

In dieser Vorlesung werden wir uns besonders mit Aspekten der technischen Informatik 

beschäftigen, und zwar mit den Bereichen Hardware (Architektur, Maschinensprache) 

und Systemprogramme (Betriebssysteme, Assembler, Kommunikation 

in verteilten Systemen). Die Vorlesung ist als eine Einführung in diese Bereiche 

zu interpretieren; eine detailliertere Behandlung von Hardware, Systemprogramme 

und verteilte Systeme erfolgt in weiterführenden Vorlesungen des Hauptstudiums. 

Mikroprogramme dienen zur Realisierung der Maschinensprache; bei 

RISC-Rechnern (z.B. Sun Workstation) sind die Mikroprogramme oft festverdrahtet. 

¯ Darstellung von Programmen in maschinennaher Form für bestimmte Anwendungen 

auch heute noch unerläßlich, beispielsweise für den Übersetzerbau, 

eingebettete Systeme oder für systemnahe Programmierung in Teilen des Betriebssystems. 

Beispiele dafür sind Echtzeitanwendungen, aber auch Teile 

des Betriebssystems wie Nachrichtenaustausch, low-level Speicherverwaltung. 

Eingebettete Systeme sind in Autos oder Handies zu finden. Beispielsweise 

ist in modernen Autos bereits eine zwei- oder dreistelligen Anzahl von Prozessoren 

zu finden, die über einen internen Bus miteinander verbunden sind. 

¯ Thema der Vorlesung ist also maschinennahe Programmierung, systemnahe 

Programmentwicklung; nebenläufige ("concurrent") Ausführung von mehreren 

7

Schlichter, TU München 1.3. THEMEN DER VORLESUNG 

Teilabläufen Nichtdeterminismus. Dabei ergibt sich von selbst eine neue 

Qualität der Programmierung: Nebenläufigkeit, d.h. zwei oder mehrere 

Teilabläufe finden gleichzeitig statt, beispielsweise CPU (bzw. RK) und 

Drucker. Neue Qualität insofern, als Nebenläufigkeit auch Nichtdeterminismus 

enthält. Unter Nichtdeterminismus verstehen wir das willkürliche Auftreten 

von Abläufen und Ereignissen (bedingt durch Einflüsse wie Last, Interaktion 

mit Benutzer). 

1.3 Themen der Vorlesung 

Diese Vorlesung beschäftigt sich mit den technischen Aspekten von Rechensystemen 

und der Informationsverarbeitung, insbesondere der systemnahen Programmierung. 

Dabei werden sowohl nicht verteilte als auch verteilte Systeme betrachtet. 

1.3.1 Laufzeitmodell 

Bereitstellung eines indirekten Zugangs zur Rechnerhardware über eine Dienstschicht. 

Ziel dieser Schicht ist die Realisierung einer virtuellen Maschine. Virtualisierung 

kann sowohl zur Fehlervermeidung als auch zur Reduktion der Komplexität 

eingesetzt werden. 

¯ Die in den Diensten bereitgestellten Abstraktionen stellen einen Rahmen für 

die Organisation von Anwendungen zur Laufzeit dar, d.h. ein Laufzeitmodell. 

¯ Dienste des Laufzeitmodells: Systembedienung, Prozessmanagement, Prozessinteraktion, 

Datenhaltung, Gerätemanagement. Wichtige Fragestellungen der 

systemnahen Programmierung sind: 

a) welche Dienste gehören zu einem Laufzeitmodell? 

b) gibt es einen inneren Zusammenhang unter den Diensten? 

c) welche Dienstmenge ist unverzichtbar? 

d) wo werden die Dienste realisiert? 

Beispielsweise werden die Dienste im Betriebssystemkern oder als Systemprozesse 

realisiert, die im Benutzermodus ("user mode") ablaufen. 

¯ elementare Abstraktionen eines Laufzeitmodells. Prozesse sind dynamische 

Objekte, die Aktivitäten in einem Rechensystem repräsentieren. Jeder 

Prozess ist definiert durch einen Adressraum A, eine darin gespeicherte 

Handlungsvorschrift H in Form eines sequentiellen Programms und einen 

8

Schlichter, TU München 1.3. THEMEN DER VORLESUNG 

Aktivitätsträger T, der mit der Handlungsvorschrift verknüpft ist und sie 

ausführt. Der Aktivitätsträger T wird oft auch als "Thread" bezeichnet. Das 

Tripel (A, H, T) repräsentiert einen sequentiellen Prozess. 

Elemente des Laufzeitmodells 

– Adressräume = Abstraktion eines physischen Speichers. Unter einem 

Adressraum versteht man einen von der Speichertechnologie und den 

beschränkten Ausbaumöglichkeiten physischer Speicher unabhängigen 

virtuellen Speicher. Adressräume verschiedener Prozesse sind gegeneinander 

abgeschottet. 

Threads ablaufen. 

Innerhalb eines Adressraums können ein oder mehrere 

– Threads = Abstraktion eines physischen Prozessors. Ein Thread ist der 

Träger einer sequentiellen Aktivität, die durch die Ausführung eines dem 

Thread zugeordneten Programms (Handlungsvorschrift) bestimmt ist. 

– Prozessinteraktion. Prozessinteraktion kann entweder speicherbasiert, 

d.h. es gibt gemeinsame Speicherbereiche, auf die die Prozesse 

(Threads) zugreifen, oder nachrichtenbasiert ablaufen. Im ersten Fall 

sind Mechanismen zur Synchronisation der Zugriffe auf den gemeinsamen 

Speicherbereich notwendig, um Inkonsistenzen zu vermeiden. Im letzten Fall 

haben die Prozesse getrennte Adressräume. Sie tauschen Informationen über 

Nachrichten aus. Dieser Ansatz wird vor allem in verteilten Rechensystemen 

verwendet, wo Prozesse über ein Rechnernetz miteinander kommunizieren. 

1.3.2 Inhaltsübersicht 

Im einzelnen werden in der Vorlesung die folgenden Themen behandelt: 

1. hardwarenahe Programm-/Datenstrukturen anhand der Modellmaschine MI. 

Neben der MI Rechnerarchitektur werden einige Maschinenbefehle sehr kurz 

behandelt. Auch wird die Programmaufbereitung mit Assembler, Binder und 

Lader kurz andiskutiert. Ein Aspekt ist auch noch die Darstellung von ein- 

/mehrdimensionalen Felder im Arbeitsspeicher. 

2. Übergang von sequentiellen Systemen zu parallelen Systemen: Verhaltensbeschreibungen 

mit Hilfe von Spuren und Petrinetzen, Synchronisationskonzepte. 

Hier steht vor allem die speicherbasierte Prozessinteraktion im 

Vordergrund, d.h. das gemeinsame Nutzen von Daten. Hier kommen 

Semaphore und Monitore zum Einsatz. Ein wichtiger Aspekt ist die Behandlung 

von Verklemmungen, d.h. Prozesse blockieren sich gegenseitig. 

9

Schlichter, TU München 1.4. LITERATURÜBERSICHT 

3. grundlegende Betriebssystemkonzepte: Prozessverwaltung, 

Prozessorzuteilung, Arbeitsspeicherverwaltung, Dateisysteme. Bei der 

Arbeitsspeicherverwaltung steht vor allem der virtuelle Speicher in Form der 

Seitenadressierung im Vordergrund. Die Modellmaschine MI unterstützt auch 

die virtuelle Adressierung auf der Basis von Seiten und Kacheln. Bei Dateisystemen 

wird neben allgemeinen Anforderungen auch ein Schichtenmodell kurz 

vorgestellt. 

4. Kommunikation in verteilten Systemen: Client-Server-Paradigma, RPC, 

Netzwerkprogrammierung. In diesem Abschnitt steht die nachrichtenbasierte 

Prozessinteraktion im Vordergrund, und zwar die Kommunikation über Ports 

und Sockets. 

5. Sicherheit in Rechensystemen: Schutzmechanismen, Zugriffskontrolllisten, 

Capability-Listen, Kryptographie, Authentifizierungsdienst Kerberos. In 

diesem Abschnitt steht die Sicherheit in Rechensystemen im Vordergrund, und 

zwar sowohl in lokalen als auch in verteilten Systemen. 

1.4 Literaturübersicht 

Literatur, die als Basis für die Vorlesung verwendet wird. 

1.4.1 Begleitend zur Vorlesung 

¯ Jürgen Nehmer, Peter Sturm, "Systemsoftware - Grundlagen moderner 

Betriebssysteme", dpunkt.verlag, 2001 

¯ Andrew S. Tanenbaum, "Modern Operating Systems", Prentice Hall, 2001 

1.4.2 Begleitend zur Übung 

U. Borghoff, T. Gasteiger, A. Schmalz, P. Weigele, H.J. Siegert, "MI - Eine 

Maschine für die Informatikausbildung", TU Bericht 1987 

1.4.3 Weiterführende Literatur 

¯ Manfred Broy, "Informatik - Eine grundlegende Einführung", Springer-Verlag, 

1998 

10

Schlichter, TU München 1.4. LITERATURÜBERSICHT 

¯ George Coulouris, Jean Dollimore, Tim Kindberg, "Distributed Systems - 

Concepts and Design", Addison-Wesley, 2001 

¯ Claudia Eckert, "IT-Sicherheit: Konzepte - Verfahren - Protokolle", Oldenbourg 

Verlag, 2003 

¯ Elliotte Rusty Harold, "Java Network Programming", O'Reilly, 2000 

¯ Ralph Morelli, "Java, Java, Java - Object-Oriented Problem Solving", Prentice 

Hall, 2000 

¯ Andrew S. Tanenbaum, "Computernetzwerke", Prentice Hall, 2000 

¯ Andrew S. Tanenbaum, Marten van Steen, "Verteilte Systeme - Grundlagen und 

Paradigmen", Pearson Studium, 2003 

11

Kapitel 2 

Rechner und hardwarenahe 

Programme 

In diesem Abschnitt werden hardwarenahe Programme und Datenstrukturen 

für einfache Rechensysteme behandelt. Die Systeme sind zentralisiert, führen 

sequentielle Berechnungen aus und bestehen aus wenigen Komponenten. 

2.1 Fragestellungen 

Dieser Abschnitt wird relativ kurz gehalten, da einige Themen bereits in 

einführenden Vorlesungen zu Informatik angesprochen wurden. Insbesondere 

werden nachfolgende Themen angesprochen. 

¯ prinzipieller Aufbau eines einfachen sequentiellen Rechners. 

¯ Basisfähigkeiten sequentieller Rechner. Beispiele für Basisfähigkeiten sind der 

Befehlsgrundzyklus sowie der vorhandene Befehlsvorrat. 

¯ kurze Einführung in die Modellmaschine MI. 

¯ Programmaufbereitung in die Modellmaschine MI. 

¯ hardwarenahe Datenstrukturen (z.B. Linearisierung von Feldern). 

2.2 von Neumann Rechner 

Die Entwicklungsgeschichte von Rechensystemen wurde durch den sogenannten 

von Neumann-Rechner geprägt.Dieses Konzept dient auch weiterhin als Basis für 

12

Schlichter, TU München 2.2. VON NEUMANN RECHNER 

die meisten Rechnerarchitekturen, wobei es jedoch einige Variationen gibt, um 

gewisse Schwächen zu umgehen (z.B. mehrere Bussysteme). 

Arbeitsspeicher 

Eingabewerk Steuerwerk 

Ausgabewerk 

¯ Komponenten 

Rechenwerk 

Prozessor 

(CPU) 

– Arbeitsspeicher (ASP, oft auch als Hauptspeicher bezeichnet): Speicherung 

der Programme und ihrer Daten. ASP besteht aus einem Feld von adressierbaren 

Speicherzellen. Problem: Variable höherer Programmiersprachen sind 

typisiert; Arbeitsspeicher ist jedoch nicht typisiert, sondern nur Folge von 

Bits. Es gibt einige Rechnerarchitekturen, die einen typisierten Arbeitsspeicher 

(eine sogenannten "tagged memory") unterstützen, z.B. Burroughs 

Rechner. 

– Steuerwerk: Steuerung des Ablaufs der Befehle eines Programms. Jeder 

Maschinenbefehl ist ein Paar (Opcode, Operanden). Die Aktionen, die das 

Steuerwerk ausführt werden mit Hilfe von Maschinenbefehlen spezifiziert. 

Ein Maschinenbefehl besteht aus dem OpCode und den Operanden. Der 

OpCode spezifiziert die Operation (abgesehen von Sprungbefehlen), die 

dann im Rechenwerk ausgeführt werden soll. Das Steuerwerk enthält 

Informationen über den Status des Programmablaufs (z.B. Befehlszähler) 

und Einrichtungen für die Erzeugung der Steuersignale zur Ausführung der 

einzelnen Befehle (Steuersignale für den Steuerbus beim Zugriff auf Ein-/ 

Ausgabewerk bzw. ASP). 

Aufgaben des Steuerwerks 

1. Holen von Maschinenbefehlen aus dem Arbeitsspeicher. 

13

Schlichter, TU München 2.3. ARCHITEKTUR SEQUENTIELLER RECHNER 

2. Dekodieren der Befehle. 

3. Holen der Operanden der Befehle aus dem Arbeitsspeicher. Dies erfordert 

je nach Situation die geeignete Adressrechnung zur Bestimmung der 

relevanten Speicherzellen im Arbeitsspeicher. Sowohl das Steuerwerk 

als auch das Rechenwerk führen Maschinenbefehle aus. Letzteres 

die Rechenoperationen, während das Steuerwerk Maschinenbefehle zur 

Steuerung des Programmablaufes ausführt (z.B. Sprungbefehle). 

– Rechenwerk: Ausführung von Rechenoperationen, die während des Ablaufs 

durchgeführt werden müssen. 

– Eingabewerk: Einlesen des Programms und der Daten in den Arbeitsspeicher. 

– Ausgabewerk: Ausgabe von Daten aus dem Arbeitsspeicher. Ein- 

/ Ausgabewerk werden bei der MI zu einem EA-Prozessor (EAP) 

zusammengefasst. Ein MI-Rechner kann mehrere EA-Prozessoren besitzen. 

¯ Ein Prozessor (Rechnerkern) ist die Zusammenfassung des Steuer- und 

Rechenwerks. Register dienen zur Speicherung von Zwischenergebnissen. 

Daneben gibt es in Rechnerimplementierungen ein Bussystem, das die 

einzelnen Komponenten untereinander verbindet. Ein MI-Rechner kann bis zu 

vier Rechnerkern besitzen; sie werden mit RK0 bis RK3 bezeichnet. 

2.3 Architektur sequentieller Rechner 

Der von Neumann Rechner ist ein logisches Modell für einen Rechner. Mit Hilfe 

von physischen Komponenten wird dieses Modell implementiert. 

2.3.1 Blockdiagramm für eine Architektur 

14


Prozessor 

(Register) 

Adressbus 

Datenbus 

Steuerbus 


Monitor Tastatur Festplatte 

Graphik 

Controller 

Keyboard 

Controller 

Festplatten 

Controller 

¯ Der Bus verbindet die einzelnen Rechnerkomponenten. Er wird exklusiv 

genutzt. Allgemeines Problem: Synchronisation konkurrierender Zugriffe 

verschiedener Komponenten auf den exklusiv nutzbaren Bus. Der Bus besteht 

aus einer Menge von Verbindungsleitungen. 

– Adressbus (16, 32 oder 64 bit): Übergabe von Adressen. Der Adressbus 

addressiert einzelne Speicherzellen des Arbeitsspeichers (gegebenenfalls 

auch Speicherzellen in den Ein-/Ausgabewerken). Die Breite des Adressbus 

legt die Menge der maximal adressierbaren Speicherzellen fest, z.B. können 

mit einem 32 bit breiten Adressbus maximal 2 32 Zellen angesprochen werden 

(insgesamt 4 GByte). 

– Datenbus (32 oder 64 bit): Übermittlung von Daten. 

– Steuerbus: Menge von Steuerleitungen, z.B. Lese- oder Schreibbefehl an 

ASP. Der Steuerbus dient zur Koordination der Lese- und Schreibzyklen 

zwischen Prozessor und den anderen Komponenten. 

¯ Kommunikation zwischen Komponenten 

Nachfolgendes Beispiel zeigt die Aktionen, die ein Prozessor (Rechnerkern 

RK) und der Arbeitsspeicher ausführen, um Daten vom Arbeitsspeicher über 

den Bus zum Prozessor zu übertragen. 


Daten 

15 

Prozessor 

(RK)


– Ablauf der Kommunikation 

Die Komponenten arbeiten nicht mit einem gemeinsamen Takt, sondern 

unabhängig voneinander. 

1. RK legt die ASP-Adresse der gewünschten Dateneinheit (16, 32 oder 64 

bit Umfang) auf den Adressbus. 

2. RK legt das Signal "Lesen" auf eine bestimmte Leitung im Steuerbus. 

3. RK legt das Signal "Adresse gültig" auf eine bestimmte Leitung im 

Steuerbus. Damit wird erreicht, dass die Adresse erst gelesen wird, wenn 

alle Adressleitungen und Signale gültig sind (d.h. stehen). 

4. ASP ist passiv, "hört" aber auf Adress- und Steuerbus mit. 

5. ASP erkennt, dass eine Adresse gültig ist und prüft, ob er mit dieser 

Adresse gemeint ist. Falls ja, führe Schritte 6 - 12 aus. Dies sieht er 

anhand von der spezifizierten Adresse; später werden die Aufteilung der 

Adressbereiche noch gesondert behandelt. Wenn ASP durch die Adresse 

nicht angesprochen ist, erfolgt keine weitere Aktion. 

6. ASP prüft das Transportrichtungssignal im Steuerbus (es erkennt das 

Signal "Lesen"). 

7. ASP legt die (adressierten) Daten auf den Datenbus. 

8. ASP legt das Signal "Daten bereit" auf eine bestimmte Leitung im 

Steuerbus. 

9. RK wartet, bis das Signal "Daten bereit" erscheint. Er weiß dann, dass die 

Daten auf dem Datenbus gültig sind und übernimmt diese. 

10. RK legt das Signal "Daten übernommen" auf eine bestimmte Leitung im 

Steuerbus. 

11. ASP deaktiviert daraufhin den Datenbus und das Signal "Daten bereit" . 

12. Sobald das Signal "Daten bereit" vom ASP weggenommen wird, 

deaktiviert der RK die von ihm verwendeten Adress- und Steuerleitungen. 

Der Bus ist wieder im Grundzustand und kann damit von einem anderen 

Prozessor verwendet werden. 

– Protokoll 

Zwischen den beteiligten Kommunikationspartnern existiert ein vereinbartes 

Verhaltensprotokoll. 

£ Verhaltensprotokolle in der Praxis: in der Vorlesung (Finger heben), 

Straßenverkehrsordnung, etc. 

£ Definition 

Ein Ablauf aus Aktions- und Kommunikationsschritten zwischen Kommunikationspartnern 

heißt ein Protokoll. Das Protokoll definiert auch 

16


Syntax, Semantik und die Reihenfolge der auszutauschenden Information. 

Protokolle dienen zur Festlegung der Kommunikation zwischen Komponenten. 

Sie spielen eine wichtige Rolle für effiziente Kommunikation 

und Kooperation. Es besteht eine hoher Standardisierungsbedarf, da die 

beteiligten Komponenten dasselbe Protokolle verwenden müssen. Protokolle 

spielen im Bereich der Rechnernetze eine sehr wichtige Rolle. 

£ Der oben geschilderte Ablauf ist ein Busprotokoll. Das obige Busprotokoll 

macht keine Annahmen über die Geschwindigkeit der Arbeit bei 

den beteiligten Partnern (d.h. es besteht asynchrones Arbeiten ohne 

Zeitgrenzen). Deshalb sind immer wieder Quittungen eines Partners 

erforderlich, in denen er mitteilt, dass er einen Schritt abgeschlossen hat. 

2.3.2 Befehlsgrundzyklus 

Die Reihenfolge der Ausführung der Maschinenbefehle wird durch den 

Befehlsgrundzyklus des Prozessors festgelegt. 

ÛÐ ØÖÙ ß 

ÓÐ Ò Ò ×ØÒ Å× ÒÒÐ Ö×× ×ØÑÑØ ÙÖ 

Ð×ÞÐÖ È 

×ØÑÑ Ò ÇÔÓ × Ð× 

×ØÑÑ ÙÒ Ð ÇÔÖÒÒ × Ð× Ò ÚÓÒ 

Ö Ö××ÖÙÒ×ÖØ 

Ö Ò Ð Ù× Ñ×Ø ÙÖ × Ê ÒÛÖ 

× ÐØ Ò Ð×ÞÐÖ ÓÖØ ÞÙÑ Æ ÓÐÖÐ 

 

Der Fortschaltung und damit der Wert des neuen Befehlszählers ist abhängig von 

der Länge des aktuellen Befehls (Operanden) bzw. von dem Sprungziel. 

¯ Ein Berechnungsschritt besteht aus den beiden Phasen: Befehlsholphase und 

Befehlsausführungsphase. Damit ergibt sich die Pipeline 

hole 

Befehl 

dekodiere 

Befehl 

führe 

Befehl aus 

In modernen Prozessoren werden die einzelnen Phasen der Pipeline durch 

getrennte Hardwarekomponenten durchgeführt. Dadurch ist eine verschränkte 

Ausführung von mehreren Befehlen möglich. Verschiedene Befehle können 

sich gerade in unterschiedlichen Phasen befinden, z.B. Befehl 1 wird 

gerade ausgeführt, während Befehl 2 dekodiert wird und während die 

17


Befehlsholeinheit gerade den Befehl 3 aus dem Arbeitsspeicher holt. Dadurch 

ist eine Beschleunigung des Ablaufes möglich. Besondere Aufmerksamkeit 

benötigen Sprünge, da sie die serielle Ausführung von Maschinenbefehlen 

unterbrechen. 

Animation Pipelining 

siehe online Version 

¯ Die Ausführung des Befehls erfolgt auf einer niedrigeren Abstraktionsebene, 

der Mikroebene. 

¯ Der Grundzyklus hat einen festen Zeittakt, der die Dauer eines Zyklus festlegt. 

2.3.3 E/A Architekturvarianten 

Die Ein-/Ausgabewerke können durch unterschiedliche Architekturvarianten 

realisiert werden. Dabei muss insbesondere das unterschiedliche Zeitverhalten 

der peripheren Geräte und der Komponenten wie Prozessor und Arbeitsspeicher 

berücksichtigt werden. Periphere Geräte sind um ein Vielfaches langsamer. 

E/A-Controller können entweder direkt an den Prozessorbus oder über einen 

getrennten Gerätebus an den Prozessorbus angeschlossen werden. 

¯ Speicherbasierte E/A 

Bei dieser Variante entsprechen E/A-Controller in ihrer Ansteuerung herkömmlichen 

Speicherbausteinen. Der Prozessor kann Register der E/A-Controller 

nicht von normalen Speicherzellen unterscheiden. 

Prozessor 


E/A Controller E/A Controller 

Durch normale Lese- und Schreiboperationen und ohne Einschränkungen 

bei den verwendeten Adressierungsarten kann auf die Register der E/A- 

Controller zugegriffen werden. Diese E/A-Architekturvariante wird bei der 

Modellmaschine MI verwendet. 

¯ E/A-Bus Controller 

Bei dieser Variante werden die peripheren Geräte nicht direkt an den schnellen 

Prozessorbus angeschlossen, sondern über einen separaten Gerätebus. 

18 

Bus


Prozessor 

E/A Controller E/A Controller E/A Controller 


E/A-Bus 

Controller 

Prozessorbus 

Gerätebus 

Bekannte Gerätebussysteme sind PCI, ISA und IEEE 1394 (FireWire) im PC- 

Bereich. Der Bus-Controller kann eine Reihe von Grundfunktionen, z.B. 

die Bearbeitung von Interrupts und DMA-Aufträgen, für alle angeschlossenen 

Geräte-Controller übernehmen. 

2.3.4 Architektur der MI 

Die Modellmaschine MI basiert auf der real-existierenden VAX-Architektur (von 

Digital Equipment). Sie umfasst bis zu 4 Prozessoren; Adressbus und Datenbus 

haben jeweils 32 bit. 

Prozessor 

RK0 

Adressbus 

Datenbus 

Steuerbus 

Prozessor 

RK3 

Plattenspeicher 1 


Plattenspeicher 2 

E/A 

Controller1 

Terminal 

Drucker 

E/A 

Controller2 

E/A-Controller werden bei der MI auch als E/A-Prozessoren bezeichnet. Bei der 

MI hat jeder Prozessor eine Nummer 0 - 3. Der Bus kann jeweils nur von einem 

Rechnerkern betrieben werden. Die MI-Architektur ist eine Multiprozessor- 

19

Schlichter, TU München 2.4. BEFEHLSVORRAT EINES RECHNERS 

Architektur. 

¯ Die Prozessoren der MI (RK0 - RK3) haben jeweils 16 Register R0 - 

R15 mit jeweils 32 Bit. Das Register R15 ist der Befehlszähler PC. Das 

Register R14 ist der Kellerpegel SP. Der Kellerpegel dient zur Verwaltung des 

Kellerbereichs im Arbeitsspeicher bei Unterprogrammaufrufen. Daneben gibt 

es noch einige Sonderregister, z.B. für die Ansteuerung der aktuellen Seiten- 

Kacheltabelle. Moderne Prozessoren umfassen sehr viel mehr Register. Ziel ist 

die Reduzierung von Arbeitsspeicherzugriffen, um den Bus als Flaschenhals zu 

umgehen. 

¯ R14 und R15 sind vom Benutzer nicht frei verwendbar. Die übrigen Register 

können aus Sicht der MI frei verwendet werden. 

¯ R0 - R15 sind symbolische Adressen. 

2.4 Befehlsvorrat eines Rechners 

Das Verhalten eines Rechensystems R wird von den Aktionen bestimmt, die 

der Prozessor P von R ausführt, und dieses Verhalten wird gestaltet, indem die 

Befehle, die P ausführen soll, festgelegt und zur Ausführung bereitgestellt werden. 

In jedem Grundzyklus führt P eine atomare Aktion aus, die mit einem Befehl 

spezifiziert ist, und die eine Veränderung des Zustands von R bewirkt. 

2.4.1 Charakterisierung der Befehle 

Ein Befehl ist eine elementare Verarbeitungs- oder Berechnungsvorschrift. Als 

solche legt ein Befehl fest, was getan werden soll, und womit es getan werden 

soll; zudem legt ein Befehl, wie schon erklärt wurde, seinen Nachfolgerbefehl 

fest. Ein Befehl besteht aus einer Operations- und einer Operandenspezifikation. 

¯ Ein Befehlswort ist die binäre Darstellung eines Befehls in einem Rechner. Ein 

Befehlswort ist ein Paar 

– Operationsteil: was soll getan werden? 

– Operandenteil: womit soll es getan werden? Der Operandenteil wird oft 

auch als Adressteil bezeichnet, weil Operanden überwiegend mit Adressen 

spezifiziert werden. 

20


¯ Befehlsvorrat 

Der Befehlsvorrat (Instruktionssatz) eines Rechners ist die Menge der 

Befehle, die der Prozessor des Rechners ausführen kann. Aus der 

angegebenen Struktur von Befehlen ergibt sich, dass der Befehlsvorrat mit den 

jeweils zugelassenen Operationsspezifikationen und den ihnen zugeordneten 

Operandenspezifikationen festgelegt ist; dabei bedeutet zugelassen, dass der 

Prozessor die entsprechende Repräsentation als Befehlswort interpretieren und 

den Befehl ausführen kann. 

¯ Befehlsklassen 

Befehle des Befehlsvorrats lassen sich in 3 Hauptgruppen einteilen: 

1. Transportbefehle: dienen dem Austausch von Daten (Binärwörtern) 

zwischen Registern, Arbeitsspeicher und E/A-Geräten. 

2. Rechenbefehle: dienen zur Verknüpfung von Binärwörtern, z.B. Arithmetik-, 

Logik- und Schiebeoperationen. 

3. Steuerbefehle: dienen zur Steuerung der Reihenfolge der Befehlsausführungen, 

z.B. unbedingte und bedingte Sprünge. 

¯ Getrieben von den hardware- und softwaretechnischen Fortschritten und von 

Erweiterungen ihrer Einsatzgebiete entstanden in der Folgezeit Rechner mit 

wachsenden Befehlsvorräten und mit komplizierteren Befehlen. Dieser Trend 

verstärkte sich, als in den 60-er Jahren die Rechner für wissenschaftliche und 

für kommerzielle Anwendungen, die bis dahin nebeneinander entwickelt wurden, 

zu sog. Rechnerfamilien (Rechner mit unterschiedlichen Leistungsmerkmalen 

aber einem allen Familienmitgliedern gemeinsamen Befehlsvorrat) 

zusammengeführt wurden. Dieser Trend setzte sich allgemein bis in die 

80-er Jahre und darüber hinaus bis heute fort. Diese Rechner werden mit 

CISC (für Complex Instruction Set Computer) charakterisiert. Sie haben Befehlssätze 

mit 250-350 Befehlen (Operationen) und vielen, zum Teil komplizierten 

Adressierungsarten. 

In den 80-er Jahren begann die Entwicklung von Rechnern mit bewusst 

klein gewählten Befehlsvorräten, etwa 100 Befehlen, und wenigen, einfachen 

Adressierungsarten, die mit RISC (für Reduced Instruction Set Computer) 

charakterisiert werden. Zur Begründung für RISC wurden CISC- 

Befehlsstatistiken ausgewertet. Sie zeigten, dass 95% der ausgeführten Befehle 

lediglich 25% der Befehle des Befehlsvorrats nutzen. Dieses Ergebnis ist 

insbesondere darauf zurückzuführen, dass nur ein kleiner Teil der Maschinenprogramme, 

die ausgeführt werden, von Hand als hardwarenahe Programme 

entwickelt werden; sie sind vielmehr die Ergebnisse von Transformationen von 

Programmen, die in höheren Programmiersprachen entwickelt werden. 

21


Diese Argumente, die damals zur Begründung für RISC benutzt wurden, gelten 

heute verstärkt. 

– CISC = Complex Instruction Set Computer; ca. 250 - 350 Operation; z.B. 

Intel Pentium, Modellmaschine MI 

– RISC = Reduced Instruction Set Computer; ca. 100 Operation; z.B. Sun 

Sparc 

– Während CISC komplexe Befehle unterstützt, werden diese bei RISC durch 

eine Menge einfacher Befehle ersetzt; 

ÁË Ð 

 

ÊÁË Ð 

ÄÇ Ê 

ÄÇ Ê 

Ê Ê 

ËÌÇÊ Ê 

Die Wirkung ist S[a3] = S[a1] + S[a2]. Dabei bezeichnet S[a3] die 

Speicherzelle, deren Adresse a3 ist. Der Inhalt der mit a1 und a2 

adressierten Speicherzellen wird addiert und der Speicherzelle mit Adresse 

a3 zugewiesen. Man spricht im Zusammenhang mit RISC oft auch von einer 

Load und Store Architektur. 

2.4.2 Aufbau Maschinenbefehle 

Ein Maschinenbefehl gliedert sich in einen Operations- und einen Operandenteil 

(am Beispiel der MI); der Operandenteil kann u.U. fehlen; 

mnemonische Zeichen 

Datentyp/Kennung 

(Operationsteil, Operandenspezifikation) 

1-4 teilig mit 

Ausdrücken 

Å× ÒÒÐ ÇÔÖØÓÒ×ØÐ 

ÇÔÖØÓÒ×ØÐ ßÇÔÖÒÒ×ÔÞ 

¯ Der Operationsteil spezifiziert die Operation, die Kennung, und die Anzahl 

der Operanden. Letztere Information wird vom Assembler automatisch 

hinzugefügt; sie muss nicht vom Programmierer angegeben werden. Die 

Kennung ist wichtig bei den unterschiedlichen Adressierungsarten. Die 

Kennung definiert den Typ und die Länge der Operanden (LOP) in Bytes: 

22


B Byte: 1 

H Halbwort: 2 

W Wort: 4 

F 32 bit Gleitpunktzahl: 4 

D 64 bit Gleitpunktzahl: 8 

Bei den Kennungen wird zwischen W und F unterschieden, weil bei bestimmten 

Operationen die Kennung nicht nur eine Angabe über die Länge der Operanden, 

sondern auch über die Art des Operanden enthalten muss. Beispielsweise ist 

für das Kopieren von Daten die Angabe der Länge ausreichend, aber bei der 

Addition muß auch noch die Angabe, ob ganze Zahlen oder Gleitpunktzahlen 

addiert werden sollen, dazukommen. 

¯ Die Operanden werden entweder direkt spezifiziert oder durch eine Vorschrift 

zur Bestimmung (Adressrechnung) angegeben. Bei der Modellmaschine MI 

lautet die Reihenfolge der Operanden stets so, dass das Ziel als letztes 

angegeben wird. 

¯ Maschinenadressen 

Der Arbeitsspeicher besteht aus einer Folge von fortlaufend nummerierten 

Bytezellen, denen jeweils Adressen zugeordnet sind. Man spricht hier von 

Maschinenadressen. 

Speicher 

0 7 0 7 

Adressraum a a+1 

Die Nummerierung beginnt bei 0; die höchste Nummer hängt vom Ausbau des 

physikalischen Speichers ab. Die Nummer der Bytes entsprechen jeweils den 

Maschinenadressen. Falls bei der MI eine Dateneinheit angesprochen wird, 

die mehr als ein Byte umfasst, dient immer die Adresse des ersten Bytes als 

Adresse der Dateneinheit. Die nachfolgenden Bytes der Dateneinheit haben 

immer höhere Adressen; sie werden jedoch nicht explizit spezifiziert. Eine 

Speicherzelle umfasst jeweils ein Byte; die Bits einer Speicherzelle b werden 

mit b 0 bis b 7 bezeichnet (von links nach rechts betrachtet). 

– Die Menge der möglichen Maschinenadressen ist der Maschinenadressraum. 

Prozesse sind ja Instanzen eines ablaufenden Programms. Prozesse 

haben ihre eigenen Adressen mit sogenannten Prozess- bzw. Programmadressen. 

Zu einem späteren Zeitpunkt wird eine Abbildung zwischen Pro- 

23


grammadressen und Maschinenadressen vorgestellt, die Seitenadressierung. 

Sie ist ein wichtiger Teil des Betriebssystems. 

– S[a] ist der Wert der durch a adressierten Speicherzelle. 

– Über den Adressbus des Rechners werden Maschinenadressen übertragen. 

– Bei der Modellmaschine MI ist eine gültige Maschinenadresse 

£ einem Arbeitsspeicherbereich, oder 

£ einem Register eines EA-Prozessors (EA-Register) zugeordnet. Falls 

beides nicht zutrifft, ist die Maschinenadresse ungültig. Die Verwendung 

einer ungültigen Adresse führt zu einem Speicherschutzalarm, und damit 

zu einer Unterbrechung des in Ausführung befindlichen Prozesses. Die 

normalen MI-Maschinenbefehle können sowohl zur Adressierung des 

Arbeitsspeichers als auch zur Adressierung der EA-Register verwendet 

werden. 

¯ Aufbau des Maschinenadressraums der MI 

24


¯ Operandenspezifikation 

H'0000 0000' 

H'000F FFFF' 

H'0010 0000' 

H'1FFF FFFF' 

H'2000 0000' 

H'3FFF FFFF' 

H'4000 0000' 

H'FFFF FFFF' 

1 MB Arbeitsspeicher 

Ausbau 


Erweiterungen 

(1 MB - 512 MB) 

Bereich, in dem über 

festgelegte Adressen 

die Register der EA- 

Prozessoren 

zugänglich sind 

keine Zuordnung 

ÇÔÖÒÒ×ÔÞ 

ÖØ Ö××ÖÙÒ 

ÙÒÑØØÐÖÖ ÇÔÖÒ 

Ê×ØÖÖ××ÖÙÒ 

ÖÐØÚ Ö××ÖÙÒ 

ÒÖØ Ö××ÖÙÒ 

ÒÞÖØ ÖÐØÚ Ö××ÖÙÒ 

ÒÞÖØ ÒÖØ Ö××ÖÙÒ 

ÃÐÐÖÖ××ÖÙÒ 

Im weiteren wird die Notation der Modellmaschine MI verwendet. 

– Direkte Adressierung 

Man spricht in diesem Zusammenhang auch von einer absoluten Adresse. 

Der Operand zeigt auf eine Stelle im Speicher, wo der Wert des Operanden 

25


gespeichert ist. 

ÖØ Ö××ÖÙÒ 

Ù×ÖÙ Ö ÒÞ Ð 

ÁÒØØÓÖ ß ßÚÓÖÞ ÒÐÓ× ÒÞ Ð 

Ò 

Der Ort des Operanden wird durch seine Adresse angegeben; dabei sind 

symbolische Adressen (Identifikatoren) zugelassen. Symbolische Adressen 

sind frei wählbare Bezeichner für Speicherzellen. Der Definitionsbereich 

einer symbolischen Adresse ist das Programm, in dem es definierend 

auftritt. Ein Bezeichner tritt in einer Operandenspezifikation eines Befehls 

anwendend auf. 

£ Beispiele 

MOVE H 107, a + 315 Wirkung: S[a+315] = S[107] 

MOVE H 205 + 7, H'F1' Wirkung: S[241] = S[212] 

Es werden jeweils Halbwörter betrachtet, d.h. es werden jeweils 2 Byte 

transportiert. 

ADD W 101, 35, b Wirkung: S[b] = S[101] + S[35] 

Hier werden die Operanden als Wörter, d.h. mit 4 Byte betrachtet 

– Unmittelbarer Operand 

Ein unmittelbarer Operand ("immediate operand") steht im Befehl selbst. 

ÙÒÑØØÐÖÖ ÇÔÖÒ 

Á ßÐØÔÙÒØÞÐ Ù×ÖÙ Ö ÒÞ Ð 

Für unmittelbare Operanden ist keine Adresse im Arbeitsspeicher oder die 

Adresse eines Registers definiert. 

£ Beispiele 

MOVE B I 2, a2 Wirkung: S[a2] = 2 als Byte 

ADD W I H'FFOO', a2 , a3 Wirkung: S[a3] = H'FFOO' + S [a2] 

– Registeradressierung 

Die Register des Prozessors sind ausgezeichnete Speicherplätze. Operanden 

können aus Registern kommen und Ergebnisse können in Registern abgelegt 

werden. Da Zugriffe auf Register wesentlich schneller (es ist kein Transfer 

über den Bus notwendig) erfolgen als Zugriffe auf den Arbeitsspeicher, 

werden Zwischenergebnisse oder häufiger benötigte Werte tunlichst in 

Registern gehalten. Die Register werden durch einen symbolischen 

Registernamen bezeichnet. Moderne Architekturen haben sehr viel mehr 

Register als die Modellmaschine MI. Der Bus wird gerne als der Flaschenhals 

der von Neumann Architektur bezeichnet. Um dieses Problem weiter 

zu reduzieren, werden in heutigen Architekturen neben einer großen 

Registermenge zunehmend auch Prozessor-Caches verwendet. 

26


Ê×ØÖÖ××ÖÙÒ ÊÜ 

ÊÜ Ê Ê Ê Ê Ê ËÈÈ 

Es wird der Wert des angesprochenen Registers verwendet. 

£ Es gilt: SP = R14 und PC = R15. 

£ Register werden auch im Zusammenhang mit der relativen, der indirekten 

und der indizierten Adressierung benutzt. 

– Relative Adressierung 

ÖÐØÚ Ö××ÖÙÒ 

ßÙ×ÖÙ Ö ÒÞ Ð ÊÜ 

ÒÞÖØ ÖÐØÚ Ö××ÖÙÒ 

ÖÐØÚ Ö××ÖÙÒÁÒÜÒ 

ÁÒÜÒ ÊÜ 

Die Funktion !adr entspricht einem Inhaltsoperator. Die Relativadressierung 

ist mit der Basis Rx und der angegebenen ganzen Zahl als 

Relativadresse zu verstehen. 

£ Steht auf Operandenstelle der Ausdruck "z+!Rx", so wird die Zahl 

z zum Wert des Registers Rx addiert und das Ergebnis als Adresse 

interpretiert, d.h. Operand = S[z + Wert von Rx]. 

£ Steht auf Operandenstelle der Ausdruck "z+!Rx/Ry/", so werden 

die Zahl z, der Wert des Registers Rx und LOP * Wert des Registers 

Ry addiert und das Ergebnis als Adresse interpretiert. LOP ist die 

Länge des Operanden, z.B. 1 für B, 2 für H und 4 für W. 

£ Die relative Adressierung eignet sich sehr gut für den Zugriff von Feldern. 

£ Beispiel 

Es sei eine Feld a mit den Elementen a[1], a[2], ..., a[10] in 

aufeinanderfolgenden Speicherzellen abgelegt. Die Elemente sind von 

der Kennung W, d.h. 4 Byte lang. Das Element a[j] soll in Register R5 

gebracht werden. Die Adresse des ersten Elements a[1] stehe bereits in 

Register R0 und der Index j des gewünschten Elements in R1. Zur Lösung 

wird ein Befehl benötigt: 

ÅÇÎ Ï Ê Ê Ê 

-4 muß subtrahiert werden, da das Feld ab 1 durchgezählt ist; der Ausdruck 

R0 /R1/ verweist auf das Element j+1 und nicht auf das Element j. 

27


Speicher 

R0 

R1 

a[1] a[2] a[j] a[10] 

– Indirekte Adressierung 

Bei der indirekten Adressierung (auch Adresssubstitution) entsteht in einem 

ersten Schritt die Adresse einer Speicherzelle. In dieser Speicherzelle steht 

nicht direkt der gewünschte Wert, sondern die Adresse des gewünschten 

Wertes. Man substituiert also beim Holen des Operanden zweimal. 

ÒÖØ Ö××ÖÙÒ 

ÖÐØÚ Ö×× ÊÜ 

ÒÞÖØ ÒÖØ Ö××ÖÙÒ 

ÒÖØ Ö××ÖÙÒÁÒÜÒ 

ÁÒÜÒ ÊÜ 

Die indirekte Adressierung wurde erstmals in der PERM (Programmgesteuerte 

Elektronische Rechenanlage München) verwirklicht (Erfinder: 

Schecher). !!Rx ist als Abkürzung für !(!Rx) zu sehen. 

£ Steht auf Operandenstelle der Ausdruck "!(z+!Rx)", so gilt: 

S[ S[z + Wert von Rx]] 

Die Zahl z wird zum Wert des Registers Rx addiert und das 

Ergebnis als Adresse a1 interpretiert. Der Inhalt der mit a1 adressierten 

Speicherzelle wird als Adresse einer Speicherzelle interpretiert, deren 

Wert der gesuchte Operand ist. 

£ Steht auf Operandenstelle der Ausdruck "!(z+!Rx)/Ry/", so gilt: 

S[ S[z + Wert von Rx] + LOP*Wert von Ry] 

LOP ist wieder die Länge des Operanden, z.B. 1 für B, 2 für H und 4 für 

W. 

£ Beispiel 

ÅÇÎ Ï Þ Ê Ê Ê 

Schritte für die Adressrechnung 

1. Relativadresse: a1:= z + (Wert in R3); 

2. dann indirekte Adresse: a2 := S[a1]; 

3. dann Indizierung: a3:= a2 + (Wert in R4) * LOP; 

4. dann ab Operandenadresse a3 den (Wort-)Operand w holen: w := S[a3]; 

anschließend wird w in Register R5 gespeichert. 

28 

R5


a1 

a2 

a3 

a2 

w 

Wert von 

R4*LOP 

– Kelleradressierung 

Die Kelleradressierung dient zur Speicherung von Daten vor allem bei 

Unterprogrammaufrufen und der Blockstrukturen von Programmen. 

ÃÐÐÖÖ××ÖÙÒ ÊÜ ÊÜ 

Diese Adressierungsart ist vorwiegend für den Zugriff auf kellerartig 

angeordnete Elemente gedacht. Der Keller wächst von größeren Adressen 

zu kleineren Adressen. Der Kellerpegel zeigt auf die Adresse des letzten 

belegten Bytes im Keller, dies ist auch die Adresse des letzten Elementes 

im Keller. Der aktuelle Kellerpegel befindet sich in dem angegebenen 

Register (meist wird SP als Register verwendet). Das Register wird entweder 

vor der Adressberechnung dekrementiert oder nach der Adressberechnung 

inkrementiert, und zwar um den Wert LOP gemäß Kennung im Befehl. 

29


Adresse 

kleiner 

größer 

wachsender 

Keller 

belegter Keller 

-!Rx entspricht der Kelleroperation push 

!Rx+ entspricht der Kelleroperation pop 

2.4.3 Befehle der MI 

-! 

!+ 

Nachfolgend werden exemplarisch einige MI Befehle kurz vorgestellt. Eine 

detaillierte Darstellung der verfügbaren Maschinenbefehle befindet sich im MI 

Manual. 

Transportbefehle 

ÅÇÎ ßÀÏ ÏÖÙÒ Ë ℄ Ë ℄ 

ÅÇÎÆ ßÀÏ ÏÖÙÒ Ë ℄ Ë ℄ 

ÄÊ ßÀÏ ÏÖÙÒ Ë ℄ 

Der Befehl MOVE B R1, 201 transportiert das letzte Byte des Registers R1 

nach der Speicherzelle 201. Bei MOVEN wird eine negative Zahl gebildet; 

hier ist sofort ersichtlich, daß W und F unterschieden werden müssen, weil - 

x für eine ganze Zahl x anders auszuführen ist als für eine Gleitpunktzahl x. 

Weitere Transportbefehle sind PUSHR, der die Register R0 bis R14 der MI in den 

Keller speichert (wobei der Kellerpegel, d.h. SP, jeweils erhöht wird), sowie der 

entsprechende Befehl POPR, der die Werte vom Keller entfernt und in die Register 

lädt (der Kellerpegel wird erniedrigt). Die Register werden in der Reihenfolge 

R14 - R0 im Keller abgelegt, und in umgekehrter Reihenfolge aus dem Keller 

entfernt. 

30


Rechenbefehle 

ÇÊ ßÀÏ ß 

ÏÖÙÒ Ë ℄ Ë ℄ ÓÖ Ë ℄ ØÛ× ÐÓ× 

ÇÔÖØÓÒ 

ßÀÏ ß 

ÏÖÙÒ Ë ℄ Ë ℄ Ë ℄ 

Logische Operationen wie z.B. OR oder ANDNOT werden gerne verwendet, um 

einzelne Bits zu setzen oder mit Hilfe einer Maske einzelne Bits auszublenden. 

¯ Shiftbefehl 

ËÀ ÏÖÙÒ Ë ℄ Ë ℄ ÚÖ× ÓÒ 

ÙÑ Ë ℄ ÇÔÖÒÒ Ñ Ï ÓÖÑØ 

– S[a1] 0 

Verschiebung nach links um S[a1] Stellen. Von rechts werden 0-Bits 

nachgezogen. Nach links hinausgeschobene Bits gehen verloren. 

£ Arithmetische Interpretation: Multiplikation von S[a2] mit 2 S[a1] 

(Überlauf möglich). 

– S[a1] 0 

Verschiebung nach rechts um |S[a1]| Stellen. Von links werden vorzeichengleiche 

Bits nachgezogen (d.h. der Wert von b bestimmt, welche Bitwerte 

0 

von links nachgezogen werden). Nach rechts hinausgeschobene Bits gehen 

verloren. 

£ Arithmetische Interpretation: Division von S[a2] durch 2 |S[a1]| 

– S[a1] = 0 

keine Verschiebung; Wirkung wie MOVE W a2, a3 

¯ Rotationsbefehl 

ÊÇÌ ÏÖÙÒ Ë ℄ Ë ℄ ÖÓØÖØ ÙÑ 

Ë ℄ ÇÔÖÒÒ Ñ Ï ÓÖÑØ 

Während man SH auch als arithmetischen Shift bezeichnet, nennt man ROT 

einen logischen Schiebebefehl. 

– S[a1] 0 

Verschiebung nach links um S[a1] Stellen. Nach links hinausgeschobene Bits 

werden von rechts nachgezogen. 

31


– S[a1] 0 

Verschiebung nach rechts um |S[a1] |Stellen. Nach rechts hinausgeschobene 

Bits werden von links nachgezogen. 

– S[a1] = 0 

keine Verschiebung; Wirkung wie MOVE W a2, a3 

¯ Anwendungsbeispiel 1 

Aufgabe: prüfe, ob eine ganze Zahl x im W Format gerade ist. Prüfung, ob 

x gerade ist, durch Prüfung des Bit x[b ] = 0; Ungerade bedeutet, dass das 

31 

letzte Bit gleich 1 ist. Eine Möglichkeit ist z.B. das Ausblenden aller Bits bis 

auf b ; dann Abfrage mit JGE (Jump Greater Equal), d.h. ist die Bedingung 

31 

größer/gleich 0. 

ÊÇÌ Á Ü Ê ÙÑ Ò Ö Ø× Ñ ÃÖ× ÛÖ ÞÙÑ 

ÎÓÖÞ Ò 

Â ×ÔÖÒ ÐÐ× Ð ÔÓ×ØÚ ×Ø ÁÒ 

×Ñ ÐÐ ×Ø Ð Ö 

¯ Anwendungsbeispiel 2 

Aufgabe: In Abhängigkeit eines Zeichenausschnitts im Zeichen z sollen 

entsprechende Operationen ausgeführt werden. Das entspricht einer Fallunterscheidung. 

Ein Beispiel dafür sind in höheren Programmiersprachen die sogenannten 

case-Anweisungen. 

Zeichen z 

b 0 

b 1 

b 2 

b 3 

b 4 

k sei der betrachtete Ausschnitt mit k = 0,...,7 

Die zugehörigen Bearbeitungssequenzen stehen ab den Adressen: f0, f1, ..., 

f7, d.h. in Abhängigkeit des Wertes von k wird an die entsprechende Stelle f i 

gesprungen. Realisierung mit Hilfe einer Sprungkaskade. 

– Vereinbarung der Sprungziele 

Ï Ö×× Ö ÖØÙÒ××ÕÙÒÞ 



32 

b 5 

b 6 

b 7


– Programmausschnitt 

ÄÊ Ï Ê ×ØÞ Ê×ØÖ Ê ÞÙÖ 

ÅÇÎ Þ Ê Ê ℄ Ê 

℄ Þ 

ËÀ Á Ê Ê ÖØÑØ× Ö ËØ Ò Ö Ø× 

ÙÑ Þ Ù ÈÓ×ØÓÒ ÞÙ 

ÔÐØÞÖÒ 

ËÀ Á Ê Ê ËØ Ò ÐÒ× ÙÑ ÛÐ× 

ÏÓÖØÖÒÞ ÞÙ ÖÐØÒ ×Ø 

ÙÑ ÄÇÈ 

ÅÇÎ Ê ×× Ö ËÔÖÙÒÞÐÖ××Ò Ò 

Ê 

Ï Ê Ê Ö×× Ö ÖØÙÒ××ÕÙÒÞ Ò 

Ê 

ÂÍÅÈ Ê ×ÔÖÒ ÞÙÖ ÖØÙÒ××ÕÙÒÞ 

Steuerbefehle 

I.a. werden Befehle in der Reihenfolge ihrer Programmaufschreibung ausgeführt. 

Sprünge spezifizieren einen Nachfolgebefehl, der i.a. in der Programmaufschreibung 

nicht unmittelbar auf den Sprungbefehl folgt. Es wird zwischen unbedingten 

und bedingten Sprüngen unterschieden. 

¯ ÂÍÅÈ unbedingter Sprung an die Adresse a1; der Befehlszähler PC wird mit 

a1 besetzt 

¯ Bedingungen 

Die Bedingungen von bedingten Sprüngen sind durch die jeweiligen Werte von 

vier speziellen 1-Bit-Registern bestimmt. 

N negativ 

Z zero (0) 

V Überlauf (overflow) 

C Übertrag (carry) 

Die Register können zu dem Spezialregister CC = (N, Z, V, C) zusammengefasst 

werden. 

– Die Ausführung des Befehls führt mit x = S[a1]+S[a2] zu 

folgender Besetzung von CC 

CC = (x 0, x == 0, ?, ?) wobei sich die Werte für ? gemäß der 

Arithmetik ergeben. 

33

Schlichter, TU München 2.5. HARDWARENAHE PROGRAMME 

Es gilt dabei S[a3] = x. Wenn x 0 ist, ergibt sich N = 1, sonst gilt N=0. 

Falls x gleich 0 ist, wird Z mit 1 besetzt. 

– Die Ausführung des Befehls ÅÇÎ Ï 

Besetzung von CC 

führt mit x = S[a1] zu folgender 

CC=(x0, x == 0, 0, C), d.h. der Wert von C bleibt unverändert. 

– Die Ausführung des Befehls ÅÈ Ï führt mit x = S[a1] und y = S[a2] 

zu folgender Besetzung von CC. ÅÈ ist ein Vergleichsbefehl, der die Werte 

der mit a1 und a2 bezeichneten Operanden vergleicht. 

CC = (x y, x == y, V, C), d.h. 

unverändert. 

die Werte von V und C bleiben 

¯ bedingte Sprünge 

Die Bedingungen bzgl. des Sprungs beziehen sich auf die Werte im 

Spezialregister CC. Die nachfolgende Liste von Sprüngen ist nur eine Auswahl 

der in der MI verfügbaren Sprünge (siehe MI Manual). Bei den 1-Bit-Registern 

geht es insbesondere darum, ob das entsprechende Bit gesetzt ist oder nicht. 

– Beispiele von Sprungbefehlen 

ÂÉ ÒÙÒ 

ÂÆ ÒÙÒ 

Â ÒÙÒ Æ ÓÖ 

ÂÎ ÒÙÒ Î 

Â ÒÙÒ 

Animation MI Programm 


2.5 Hardwarenahe Programme 

Zur Erleichterung werden hardwarenahe Programme für ein Rechensystem nicht 

als ausführbare Maschinenprogramme (Folge von Befehlswörtern) realisiert, 

sondern mit Hilfe von Assemblerprogrammen. 

2.5.1 Definitionen 

Maschinenschnittstelle 

Als Maschinenschnittstelle bezeichnet man die Gesamtheit aller Datenobjekte und 

Operationen der reinen Hardwarearchitektur (auch Programmierschnittstellen der 

Maschine). 

34


¯ Folge von Maschinenbefehlen ist auf dieser Ebene eine Folge von Binärzeichen. 

Auf dieser Ebene müsste man insbesondere die Befehle der Maschine als reine 

Folge von Binärzeichen (Befehlswörter) schreiben; diese Schnittstelle ist sehr 

programmier-unfreundlich. 

Assemblerschnittstelle 

Die Assemblerschnittstelle ist die eigentliche maschinennahe (konkrete) Programmierschnittstelle. 

Sie erlaubt, alle Befehle, Adressen und Datenobjekte der reinen 

Hardware darzustellen. 

¯ Verwendung von Namen für Adressen und Operationen. Assemblersprachen 

sind eine geringfügige Erweiterung von reinen Maschinensprachen. Zur 

bequemeren Nutzung werden u.a. symbolische Adressen (z.B. Identifikatoren) 

und symbolische Namen für Operationen (z.B. ADD für Addition) verwendet. 

Für die Beschreibung der MI (insbesondere der MI Befehle) haben wir bereits 

diese Schnittstelle zugrunde gelegt. 

Assembler 

Ein Assembler ist ein Programm, das die Aufgabe hat, 

1. Assemblerbefehle in Maschinencode zu transformieren, 

2. symbolischen Namen Maschinenadressen zu zuweisen, sowie 

3. ein Objektprogramm zu erzeugen. 

2.5.2 Programmaufbereitung 

Hier beschäftigen wir uns mit dem Programmieren auf der Assemblerschnittstelle. 

Ausgangspunkt sind Assembler-Programme (z.B. MI-Programme), und wir 

versuchen zu klären, was ist noch zu tun, um ein ausführfähiges Programm 

im Arbeitsspeicher zu haben. Wir wollen eine grobe Vorstellung der 

Funktion eines Assemblers, Binders und Laders vermitteln. Binder/Lader 

sind i.d.R. Bestandteil des Betriebssystems. Hier steht nicht die Konstruktion 

solcher Komponenten (Systemprogrammierung), sondern deren Aufgaben und 

Funktionen im Vordergrund. 

35


Programm 

z.B. Java Programm 

Assembler 

Programm 

Compiler 

Assembler 

Bindemodul Bindemodul 

Lademodul 

Maschinenbefehle mit 

relativen Adressen 

Maschinenprogramm im 


Binder 

Lader 

symbolische Bezüge nach 

außen 

offene Referenzen 

In der Vorlesung werden nur allgemeine Assembler-Funktionen behandelt. Für 

den MI-Assembler gilt, dass er die Aufgaben Assemblieren und Binden in sich 

vereinigt, also ein ausführbares Ladeobjekt erstellt. (vgl. MI-Handbuch, Kapitel 

4). 

2.5.3 MI Assemblerprogramm 

Ein Assemblerprogramm besteht aus einer Menge von Segmenten, die jeweils 

durch ein Trennzeichen (z.B. Neuzeile) voneinander getrennt sind (siehe MI 

Manual für die Grammatik des MI Assemblers). 

36


×ÑÒØ ×ÑÒØÒÑ Ë ß 

ÐÖ×× ÌÖÒÒÞ 

ßßÅÖ ÒÛ×ÙÒÌÖÒÒÞ 

ÐÖ×× ÚÓÖÞ ÒÐÓ× ÒÞ Ð 

ÅÖ ÆÑ ßÌÖÒÒÞ 

ÒÛ×ÙÒ ××ÑÐÖ×ØÙÖÙÒ 

Å× ÒÒÐ ØÒÒØÓÒ 

ÌÖÒÒÞ ßÃÓÑÑÒØÖÆÙÞÐ 

Die Assemblersteuerung enthält Anweisungen an den Assembler, z.B. die 

Bekanntmachung von Variablen in anderen Segmenten durch die Importund 

Exportanweisungen. Ablageadressen sind hier als Programmadressen zu 

verstehen. Anwenderprogramme arbeiten mit virtuellen Speicheradressen, die 

bei der Ausführung des Programms in Maschinenadressen umgewandelt werden, 

d.h. der virtuelle Arbeitsspeicher wird auf den realen Arbeitsspeicher abgebildet. 

Die Segmentierung dient der Einteilung eines Programms in Einheiten (genannt 

Segmente) aus Benutzersicht (z.B. für gleichartige Zugriffsrechte!). 

¯ Komponenten eines systemnahen Programms 

Ein systemnahes Programm besteht aus drei Komponenten: dem Anweisungsteil, 

dem Datenteil und dem Registerteil. 

im Arbeitsspeicher 

im Prozessor 

Datenteil 

Anweisungsteil 

Registerteil 

Variable 

Programmcode 

invariant 

Hilfsvariable 

Der Anweisungs- und Datenteil sind explizit definiert, während der Registerteil 

implizit für jedes Programm existiert. Die implizite Definition bedeutet, dass 

die Registerwerte (mit Ausnahme des PC) bei Ablaufbeginn undefiniert sind. 

Die Anfangswerte des Datenteils werden i.a. durch das Programm vorgegeben. 

Der Anweisungs- und Datenteil werden je nach Art der Daten im Keller bzw. 

auf der Halde gespeichert. 

37


2.5.4 Assembler Grundfunktionen 

Ein Assembler muss aus den Assemblerbefehlen den entsprechenden Maschinencode 

erzeugen, und anschließend das Objektprogramm generieren, wobei symbolische 

Namen auf Maschinenadressen abgebildet werden. 

Erzeugen von Maschinencode 

Beispiel 

Ö×× ÅÖ Ð 

Ï ÁÒÜ Ê 

ÁÒÜ 

¯ Aktionen bei der Erzeugung 

– Maschinencode für Operationsteil, z.B. in MI: Assemblerbefehl ADD W 

wird codiert als H'C1', falls nur 2 Operandenspezifikationen folgen. 

– Maschinencode für Operandenspezifikationen, z.B. in MI: R6 codiert als 

H'56' 

– Konvertieren von symbolischen Namen in Maschinenadressen, z.B. symbolischer 

Name Index auf Adresse 1033 abbilden 

– Konstruktion eines Maschinenbefehls im korrekten Format 

– Konvertieren von Konstanten in interne Maschinen-Repräsentationen z.B. 

EOF in H'454F46'. Hier ist die Zeichenkette "EOF" gedacht, und nicht endof-file. 

– Assembler-Steuerungsanweisung: Assembler Direktiven, z.B. bei MI RES, 

werden vom Assembler nicht transformiert, sondern interpretiert, z.B. als 

Auftrag, Speicherplatz zu reservieren. 

¯ Problem 

Abarbeiten des Quellprogramms Zeile für Zeile. Befehle können jedoch 

Vorwärts-Referenzen enthalten, z.B. im Beispiel Definition des symbolischen 

Namens Index erst nach Nutzung. Die korrekte Adresse der Vorwärts-Referenz 

ist bei dieser Vorgehensweise beim ersten Auftreten der Referenz noch nicht 

bekannt und es kann noch kein korrekter Code erzeugt werden. 

– Lösung 

Assembler macht 2 (oder mehr) Läufe (siehe Seite 40) (engl. "pass") über 

das Assemblerprogramm. 

38


£ 1-ter Lauf: Zuordnen von Maschinenadressen 

£ 2-ter Lauf: Codierung, d.h. Erzeugung der Maschinenbefehle 

Erzeugen des Objektprogramms 

Der Assembler schreibt den generierten Maschinencode in ein Objekt- 

Programm/Ladeobjekt (z.B. ".o" oder ".obj" Datei), das dann in den Speicher 

geladen und ausgeführt werden kann. Ein einfaches Objekt-Programm enthält unterschiedliche 

Klassen von Einträgen (z.B. gekennzeichnet mit einem speziellen 

Buchstaben), die unterschiedliche Informationen für den Binder/Lader zur Verfügung 

stellen. 

¯ Header Informationen 

Name des Programms, Startadresse (Hex), Länge des Programms (Hex), 

Einträge z.B. mit H gekennzeichnet. Bei MI enthält die erste Zeile des 

Objektprogramms: Startadresse, Anzahl der Zeichen in Segmentnamen, 

Segmentname 

¯ Text 

Maschinencode und Daten, Einträge z.B. mit T gekennzeichnet. Bei MI: keine 

extra Kennung und Code wird zeilenweise im Ladeprogramm gespeichert. 

¯ Ende 

Ende des Programms und Adresse der ersten auszuführenden Instruktion (Hex), 

Einträge z.B. mit E gekennzeichnet. Bei MI: letzte Zeile mit einem Punkt in 

erster Spalte. 

¯ Beispiel eines Ladeobjekts 

××ÑÐÖ Ó 

Ì×Ø Ë 

ÅÇÎ Ï Á À ËÈ 

ÂÍÅÈ ×ØÖØ 

ÞÙÖ× ÄÓØ 

Ì×Ø 

 

 

ÛØÖÖ Å× ÒÒ Ó 

Die erste Zeile spezifiziert die Startadresse H'0, die Länge 4 des Segmentnamens 

sowie den Segmentnamen selbst. Die 2. Zeile repräsentiert den Befehl: 

39


MOVE W I H'10000, SP. Die 3. Zeile entspricht JUMP start; die Adresse von 

start ergibt sich dabei durch AF19. 

Datenstrukturen des Assemblers 

Für die Transformation benötigt der Assembler im wesentlichen 2 Tabellen: eine 

Objekt-Code Tabelle und eine Symboltabelle. Beide Tabellen (OCT u. SYMT) 

werden normalerweise als Hashtabellen realisiert, auf OCT wird dann z.B. mit 

dem Befehl als Such-Schlüssel zugegriffen. 

¯ Objekt-Code Tabelle (OCT) 

Die Objekt-Code Tabelle enthält eine Zuordnung zwischen Maschinencode und 

Assemblerbefehl; diese Tabelle ist meist statisch fest. OCT kann auch weitere 

Informationen enthalten: z.B. Befehlslänge, Operandenzahl, Format. 

– MI: ÅÇÎ Ï entspricht H'A0' oder ÂÍÅÈ entspricht H'F1' 

¯ Symboltabelle (SYMT) 

Die Symboltabelle enthält die Zuordnung zwischen symbolischen Namen und 

Maschinenadressen; diese Tabelle kann auch weitere Informationen enthalten: 

z.B. Typ, Länge. 

– Der Assembler erzeugt die Symboltabelleneinträge während des ersten 

Laufs. Während des zweiten Laufs werden dann alle Namen, die in Operandenspezifikationen 

auftreten, durch die in der Symboltabelle eingetragene 

Adresse ersetzt.In die Symboltabelle werden auch die benutzerdefinierten 

Symbole (z.B. bei der MI durch EQU Anweisungen festgelegt) aufgenommen, 

zusammen mit dem Wert, der durch eine solche Anweisung für den 

symbolischen Namen festgelegt wird. 

2.5.5 Assemblerläufe 

Ein Assembler macht 2 (oder mehr) Läufe über das Assemblerprogramm. 

Nachfolgend werden kurz die Schritte eines einfachen Assemblers vorgestellt. 

Lauf 1 

Der Lauf 1 erzeugt ein Programm in einem Zwischenformat, das als Eingabe für 

Lauf 2 dient, insbesondere erfolgt eine Zuordnung von symbolischen Namen zu 

Maschinenadressen. 

40


1. Initialisiere Location Counter (Zähler) mit Startadresse, falls angegeben, sonst 

mit 0. 

2. Ersetze Operationsteil durch Maschinencode. 

3. Auftreten eines symbolischen Namens N in einem Befehl: Trage N in 

Symboltabelle ein, falls noch nicht in Tabelle. 

4. Falls eine Marke definierend auftritt: 

¯ Falls Name noch nicht in SYMT: Erzeuge SYMT-Eintrag mit Zählerstand 

¯ Falls Marke ohne Zählerstand schon drin: Eintrag des Zählerstands 

¯ Falls Marke mit Zählerstand schon drin: Fehler, da doppelte Namensvereinbarung 

5. Erhöhe Zähler um Länge der Instruktion (aus Op-Code zu entnehmen). 

6. Falls nicht Dateiende, lies nächste Zeile und gehe zu Schritt 2. 

Beispiel 

ÓÙÒØÖ ÅÖ Ð 

Ì×Ø Ë 

×ØÖØ 


¯ Beim Auftreten der Marke start in "ÂÍÅÈ ×ØÖØ" : Eintrag in Symboltabelle 

an Indexstelle i . 

ÁÒÜ ÆÑ Ö×× 

×ØÖØ 

¯ Beim Auftreten der Definition Marke start in "start:" Eintrag des aktuellen 

Zählerstandes in Symboltabelle an Indexstelle i . 

ÁÒÜ ÆÑ Ö×× 

×ØÖØ 

41


Lauf 2 

Der Lauf 2 des Assemblers erzeugt das Objekt-Programm 

1. Erzeuge Header-Eintrag und schreibe ihn in Objekt-Programm. 

2. Initialisiere ersten Text-Eintrag. Ein Texteintrag kann beispielsweise ein 

Maschinenbefehl sein. 

3. Falls symbolischer Name in Operandenspezifikation auftritt: 

¯ suche Name in SYMT 

¯ ersetze Name in Operand durch Adresse in SYMT 

¯ Falls Name nicht gefunden: trage 0 als Adresse ein und setze Flag: undefined 

Symbol 

4. Konstruiere korrekten Maschinenbefehl-Code. 

5. füge Code dem Text-Eintrag hinzu, falls noch Platz, sonst: schreibe Text- 

Eintrag in Objekt-Programm und erzeuge neuen Text-Eintrag. 

6. Falls noch nicht Programmende: lies nächste Zeile des Eingabe-Programms 

und führe Schritte 3 bis 6 durch. 

7. schreibe letzten Text-Eintrag in Objekt-Programm. 

8. schreibe End-Eintrag in Objekt-Programm. 

PC-relative Adressierung 

Ein Problem bei dieser Vorgehensweise ist, dass das Programm an den 

angegebenen Adressen zur Ausführung kommen muss Wunsch: verschiebbare 

Programme. Berechnen relativer Adressen durch Assembler, und zwar relativ zum 

PC. Dies wird auch von der MI unterstützt. 

¯ Idee 

Anstatt der Adresse an der der symbolische Name laut Symboltabelle zu finden 

ist: Angabe eines PC-relativen Displacements. 

42


¯ Vorgehen 

Zieladresse setzt sich zusammen aus Zähler (PC) und Displacement; PC 

Wert wird bereits nach dem Holen des Befehls erhöht; das muss bei der 

Adressrechnung berücksichtigt werden. Displacement bestimmt eine Adresse 

relativ zum Wert des Befehlszählers (PC). 

– Displacement x für Adresse des symbolischen Names muss berechnet 

werden: Zieladresse = PC + x 

– Beispiel: Vorwärtsverweis 

ÓÙÒØÖ ÅÖ Ð 

Ì×Ø Ë 


×ØÖØ 

Als Code für den Befehl Jump start ergibt sich folgender 

£ F1 = Code für ÂÍÅÈ 

£ PC-relative Adressierung: PC =Register 15 (R15), d.h. es ergibt sich AF 

(F = R15 und A für relative Adressierung) 

£ Berechnen des Displacements x mit PC + x = 00000045 (= Adresse von 

start) 

Æ Wert des PC nach Abarbeitung von F1 AF: 00000033 + 2 = 00000035. 

Der Sprungbefehl umfasst 2 Byte, d.h. der PC wird nach dem Holen des 

Befehls um 2 inkrementiert. 

Æ also: Displacement x = 10, damit sich die Zieladresse 00000045 ergibt 

£ Insgesamt ergibt sich als Maschinencode: F1 AF10 

¯ Vorteile der PC-relativen Adressierung 

– Verschiebbarkeit der Objektprogramme durch relative Adressierung. Der 

Lader hat dann die Aufgabe, dazu jeweils die absolute Startadresse hinzu 

zu addieren. 

– kurze Operanden: Register-relative Adressierung (in unserem Fall durch 

PC). 

¯ Bemerkung: One-Pass Assembler: es dürfen keine Vorwärts-Referenzen 

auftreten, d.h. es muss das Define-before-use Prinzip gelten. 

43


2.5.6 Binder und Lader 

Ein Assembler-Programm kann aus mehreren logischen Einheiten (MI: Segmente) 

bestehen, die vom Assembler als einzelne, unabhängige Einheiten (Bindemoduln) 

transformiert werden. In Informatik I/II wurde bereits Modularisierung 

als wichtiges Konstruktionsprinzip behandelt. Aspekte sind: Problem wird in 

Teilprobleme zerlegt, Bausteine als Lösung von Teilproblemen, Wiederverwendung 

von Bausteinen, Bibliotheken (engl. library). Modularisierung ist besonders 

bei der Entwicklung großer Programme sehr wichtig. 

Binder 

Der Binder (engl. linker) hat die Aufgabe, aus einer Menge von einzelnen 

Bindemoduln ein ausführfähiges Ladeprogramm zu erzeugen, indem die noch 

offenen externen Referenzen aufgelöst werden. 

¯ Binde-Module 

Der Assembler erzeugt Code, der jeweils relativ zum Modul-Anfang adressiert. 

Segment 1 

JUMP start 

Lade 

objekt 1 

Segment 2 Segment n 

Lade 

objekt 2 

start: 

assemblieren 

Lade 

objekt n 

Assemblermodule 

Bindemodule 

Das Zusammenfügen der einzelnen Segmente zu einem ausführfähigen 

Programm ist die Aufgabe des Binders (Linker). 

– Externe Referenzen 

In einem Modul M i können Referenzen auf Daten/Marken auftreten, wobei 

die Daten/Marken in einem anderen Modul M j definiert werden. Beispiel: 

Marke start wird in Segment 1 verwendet, und erst in Segment n definiert. 

44


Solche Referenzen heißen externe Referenzen. Assembler kann Referenzen 

nicht auflösen, Assembler besitzt keine Informationen darüber, wo sich die 

einzelnen Segmente zur Ausführungszeit im Arbeitsspeicher befinden. 

– Behandlung externer Referenzen 

Für jede externe Referenz erzeugt der Assembler Informationen, die 

es dem Binder ermöglicht, aus den Einzelmoduln ein ausführfähiges 

Gesamtprogramm zu erzeugen, d.h. die Referenzen (siehe Seite 47) 

aufzulösen. Module können unabhängig assembliert werden: keine Vorgabe 

über zeitliche Reihenfolge. 

£ Der Programmierer gibt durch spezielle Assembler-Direktiven für jeden 

Modul an, welche Symbole, Namen und Marken des Moduls von außen 

verwendet werden können, d.h. exportiert werden (in MI durch EXP bzw. 

EXPORT Direktive). 

£ Extern referenzierte Symbole in einem Modul, sogenannte importierte 

Symbole, müssen durch Assembler-Steuerungsanweisungen im Modul 

markiert werden (in MI: IMP oder IMPORT Direktive). 

£ Assembler erzeugt ausgehend von diesen Steuerinformationen spezielle 

Einträge im Objekt-Programm. 

Æ Für exportierte Symbole: ein Eintrag (gekennzeichnet z.B. durch ein 

D (=define)), der den Namen und die relative Adresse des Symbols 

umfasst. Aufbau des Define-Eintrag: 

"Kennung D, Name des exportierten Symbols, relative Adresse des 

Symbols im definierenden Segment". 

Æ Für importierte Symbole: ein Eintrag (gekennzeichnet z.B. durch ein R 

(=refer)), der den Namen des importierten Symbols umfasst. Adressen 

können hierfür noch nicht eingetragen werden. Aufbau des Refer- 

Eintrag: 

"Kennung R, Name des importierten Symbols". 

£ Findet der Assembler eine externe Referenz, so trägt er in dem 

erzeugten Code die Adresse 0 ein. Gleichzeitig erzeugt er einen 

Modifikations-Eintrag (gekennzeichnet z.B. durch ein M (=modify)) im 

Objektprogramm, der für den Binder die benötigte Information enthält: 

Angabe, welches Auftreten der Referenz zu modifizieren ist und 

Name des externen Symbols. 

Auftreten bezieht sich hier auf die Angabe in der Operandenspezifikation, 

wo die externe Referenz auftritt. Aufbau Modifikations-Eintrag: 

"Kennung M, Startadresse des zu modif. Adressfeldes, importiertes 

Symbol". 

45


Lader 

Ein Lader (engl. loader) ist ein Systemprogramm, das die Aufgabe hat, 

Objektprogramme in den Speicher zu laden und deren Ausführung anzustoßen. 

¯ Eigenschaften 

In einem System ist i.d.R. nur ein Lader vorhanden, so dass Programme 

unterschiedlicher Quellsprachen in ein einheitliches Objektprogramm-Format 

transformiert werden müssen. 

– Viele Lader beinhalten gleichzeitig Binde-Funktion. Binde/Lader sind 

heutzutage typische Komponenten in Rechensystemen. Binde/Lader sind 

Bestandteil der Dienste, die ein Betriebssystem anbietet. 

£ Binde/Lader: Programmmodule werden zur Ladezeit gebunden. 

£ Lauf 1: Zuweisung von Adressen zu externen Referenzen (Auflösen von 

Referenzen) 

£ Lauf 2: Binden, Verschieben, Laden 

– Absoluter Lader 

Aufgaben eines absoluten Laders; ein Lauf genügt. 

£ Prüfen des Header-Teils im Objekt-Programm, ob es sich um das dort 

spezifizierte Programm handelt und ob der für das Programm vorgesehene 

Speicher groß genug ist (Header-Infos über Programmgröße). 

£ Die Text-Einträge im Objekt-Programm werden gelesen und der Code 

wird an die dort angegebenen, absoluten Adressen des Speichers geladen. 

£ Beim Lesen des END-Eintrags springt der Lader zur angegebenen Start- 

Adresse des Programms, um die Programmausführung zu starten. Ein 

absoluter Lader hat jedoch eine Reihe von Problemen: a) Programmierer 

muss Lade-Adressen explizit angeben, b) Probleme bei Multiprogramming: 

Ladeadresse nicht vorab bekannt, c) Verschiebbarkeitsforderungen 

können nicht erfüllt werden, und d) Probleme bei Wiederverwendbarkeit 

von z.B. Bibliotheksfunktionen, wenn diese vorab vergebene absolute 

Adressen besitzen. 

– Relativer Lader 

Laden verschiebbarer Objekt-Programme, wobei die Information, welche 

Adressen neu zu berechnen sind, vom Assembler zur Verfügung 

gestellt werden, z.B. durch Modifikations-Einträge im Objekt-Programm. 

Modifikations-Einträge sind jedoch nicht für jede Maschinen-Architektur 

geeignet. Maschinen, die z.B. keine relative Adressierung kennen, erfordern, 

46


dass u.U. fast alle Adressen neu berechnet werden müssen durch den Lader. 

Entsprechend umfangreich sind dann die benötigten Modifikations- 

Einträge und entsprechend groß wird dann das Objekt-Programm. Die Verschiebbarkeit 

wird in Zusammenhang mit der Seitenadressierung (siehe 

Seite 168) detaillierter behandelt. 

Datenstrukturen eines Binde/Laders 

Der Binder benötigt eine Tabelle ESTAB ("external symbol table") für die 

aufzulösenden externen Referenzen, wenn im Programm externe Referenzen 

auftreten. Der Tabelleneintrag besteht aus [Symbol, Adresse]. ESTAB hat analoge 

Aufgaben wie die Symboltabelle des Assemblers. Der Tabelleneintrag beinhaltet 

u.U. auch den Modul, in dem das Symbol definiert ist. 

¯ Hilfsvariable 

– PADR: Startadresse im Speicher, wohin das gebundene Programm geladen 

werden soll. Der Wert wird i.d.R. durch das Betriebssystem ermittelt und 

dem Lader mitgeteilt. 

– CSADR: Startadresse des jeweils bearbeiteten Moduls; dieser Wert wird zu 

den Relativ-Adressen des jeweiligen Moduls hinzu addiert. CSADR steht für 

control section adr. 

¯ Algorithmus zum Lauf 1 

Festlegen der Startadresse PADR des zu ladenden Programms (also wohin es in 

den Speicher geladen werden soll). Jedes Modul wie folgt bearbeiten: 

– Header-Eintrag lesen und Eintrag in Symboltabelle ESTAB: 

[Name des Moduls, Startadr. (=CSADR) des Moduls]. 

Beim ersten Modul gilt: PADR=CSADR. 

– Lesen von Export-Einträgen (Symbol-Definitionen) im Objekt-Programm; 

alle auftretenden Symbole in ESTAB eintragen, wobei gilt: 

[symbolischer-Name, Adresse = Relativadr + CSADR]. 

– Lesen des END-Eintrags: CSADR = CSADR_alt + Länge des Segments 

(steht als Info im Header); Bearbeiten des nächsten Moduls mit der neuen 

Anfangsadresse CSADR. 

¯ Algorithmus zum Lauf 2 

47


Nach Lauf 1 enthält ESTAB alle externen Symbole, die in Modulen definiert 

wurden zusammen mit deren Adresse. Der 2. Lauf erledigt die Funktionen 

Laden, Verschieben, Binden. 

– Sukzessives Lesen der Text-Einträge aus Objektprogramm; Abspeichern des 

Codes an "Startadresse des Segments + Relativadresse" im Eintrag. Die 

Startadresse des Segments ist CSADR und ist jeweils im Eintrag zum Modul 

in ESTAB enthalten. 

– Wird ein Modifikations-Eintrag gelesen, so wird das extern referenzierte 

Symbol bzw. dessen Adresse, in ESTAB nachgeschlagen. 

– Ist das letzte Modul bearbeitet und dessen END-Eintrag gelesen, so wird 

zum dort angegebenen Beginn des Programms gesprungen und die Kontrolle 

zur Ausführung des Programms wird an das Programm abgegeben. Bei 

mehreren Objektprogrammmodulen enthält meist nur das Hauptprogramm 

eine Angabe einer Startadresse. Falls kein Modul eine Startadresse definiert, 

wird vom Lader per default die Anfangsadresse PADR genommen. Damit 

gilt folgendes: Reihenfolge, in der Module geladen werden spielt keine 

Rolle. Andere Möglichkeit: Startadresse des geladenen Programms wird an 

das Betriebssystem zurückgeliefert und Benutzer muss mit einem Execute- 

Befehle (exec) explizit die Ausführung starten. 

Dynamisches Binden 

Binden von Unterprogrammen erst zur Laufzeit, d.h. erst wenn sie das erste Mal 

aufgerufen werden. Als Vorteile ergeben sich folgende: 

¯ Nach Bedarf laden 

Unterprogramme werden also nur dann, wenn sie tatsächlich gebraucht werden, 

zum in Ausführung befindlichen Programm hinzu gebunden. Bei großen 

Unterprogrammen oder bei Unterprogrammen mit vielen externen Referenzen 

kann man mit dynamischen Binden viel Speicherplatz und Zeit einsparen. Z.B. 

Nutzung einer großen Statistik-Bibliothek abhängig von Eingabewerten, die 

erst zur Laufzeit bekannt sind: kein Binden einer vollständigen Kopie der 

Bibliothek nötig. 

Beispiel Windows: Routinen in Dynamic Link Libraries (DLL) zusammengefasst; 

erst wenn sie benötigt wird, Laden der gesamten DLL. 

¯ Code-Sharing 

Dynamisches Binden wird oft verwendet, wenn mehrere ausführfähige 

Programme eine einzige Kopie eines Unterprogramms oder einer Bibliothek 

48

Schlichter, TU München 2.6. HARDWARENAHE DATENSTRUKTUREN 

gemeinsam nutzen sollen. Z.B. werden für die Programmiersprache C 

die Routinen für die Laufzeit-Unterstützung in der dynamic link library 

zusammengefasst. Es wird dann nur eine Kopie der Routinen der Bibliothek 

in den Arbeitsspeicher geladen und alle ausführenden Programme können dann 

dynamisch diese Kopie zu ihrem Programm hinzu binden, anstatt jeweils eine 

eigene Kopie in ihr Objektprogramm zu binden. 

2.6 Hardwarenahe Datenstrukturen 

Dieser Abschnitt behandelt kurz einige hardwarenahe Datenstrukturen. Einige 

davon, z.B. Keller und Halde, wurden bereits zusammen mit ihren Operationen in 

der Informatik-Einführungsvorlesung ausführlich vorgestellt. 

2.6.1 Felder 

Eindimensionale Felder 

Angenommen wir haben ein Feld a[u:o] von Elementen mit u o; u ist die untere 

Grenze und o die obere Grenze des Feldes. In Java ist die untere Grenze immer 

0, d.h. ein Feld beginnt immer mit dem Feldelement a[0]. Es gibt jedoch andere 

Programmiersprachen, bei denen der Programmierer sowohl die untere als auch 

die obere Feldgrenze frei wählen kann, jedoch mit u o. Es ergibt sich folgende 

Möglichkeit einer linearen Anordnung im Speicher. 

a[u] 

a[u+1] 

a[u+2] 

a[o-1] 

a[o] 

49


Die Anzahl der benötigten Bytes pro Feldelement ergibt sich durch die Art der 

Feldelemente, z.B. bei integer wird Kennung W verwendet mit LOP = 4 Bytes. 

¯ Zugriff auf Feldelement 

Das Element a[j] (mit u j o) soll in das Register R0 gebracht werden. Die 

Adresse des ersten Elementes a[u] sei die symbolische Adresse a. Der Index j 

stehe im Register R2. Das Register R2 darf verändert werden. Die Untergrenze 

u steht in Register R3. 

– LOP ist die Länge in Bytes eines Feldelements; adr(a[u]) liefert die Adresse 

des Feldelements a[u]. 

Ö ℄ Ö Ù℄ Ù ÄÇÈ 

– Im Assemblercode der MI 

ÅÇÎ Ê Ö×× ÚÓÒ Ù℄ 

ËÍ Ï Ê Ê Ê Ê Ê Ù 


Die Adressrechnung ist folgendermaßen: inhalt(R1) + (j-u)*4, da die 

Kennung W verwendet wird. Zur Adressierung wird also das Inkrement (j 

- u) benötigt. Nachteil, da das Inkrement (j - u) jeweils berechnet werden 

muss. Dieser Nachteil lässt sich durch Einführung der sogenannten fiktiven 

Anfangsadresse adr(a[0]) vermeiden. 

¯ Fiktive Anfangsadresse 

Ö ℄ Ö Ù℄ Ù ÄÇÈ ÄÇÈ 

Ö ℄ ÄÇÈ 

adr(a[0]) ist die fiktive Anfangsadresse des Feldes a. Die fiktive Anfangsadresse 

muss im Speicher abgelegt werden. I.a. wird sie unmittelbar vor dem 

Feldelement a[u] abgelegt. 

– Im Assemblercode der MI 

ÅÇÎ Ê 


Die symbolische Adresse a zeigt auf das 1. Feldelement a[u]. Die fiktive 

Anfangsadresse a[0] wird unmittelbar vor a[u] gespeichert; deshalb muss -4 

abgezogen werden. Probleme mit obigem Programmstück: 

a) die Indexgrenzen werden nicht überprüft, 

b) es wird nicht überprüft, ob der Zugriff im Speicherbereich der Reihung 

bleibt. 

50


Bei eindimensionalen Reihungen sind diese beiden Prüfungen äquivalent. 

Bei mehrdimensionalen Feldern ist die erste genannte Prüfung die schärfere. 

Wir ordnen daher jeder Reihung einen unabhängig abgespeicherten 

Felddeskriptor zu, der auch Informationen über Dimension und Feldgrenzen 

enthält. 

Mehrdimensionale Felder 

Angenommen wir haben ein Feld a[u1:o1,..., uk:ok] von Elementen mit uj oj; 

uj ist die untere Grenze und oj die obere Grenze der j-ten Dimension des Feldes. 

¯ Linearisierung 

des Feldes im Arbeitsspeicher, so dass der letzte Index am schnellsten läuft. 

Beispielsweise werden bei einem 3-dimensionalen Feld die Feldelemente in der 

Reihe a[u1,u2,u3], a[u1,u2,u3+1], a[u1,u2,u3+2],...a[u1,u2,o3], a[u1,u2+1,u3], 

a[u1,u2+1,u3+1], ..., a[u1+1,u2,u3], ....a[o1,o2,o3]. Eine andere Möglichkeit 

ist es den ersten Index am schnellsten laufen zu lassen. 

¯ Vorschrift zur Adressberechnung 

Ö ℄ 

Ö Ù Ù℄ 

Ù × Ù × Ù 

ÄÇÈ 

mit den Spannen sj = oj - uj + 1. Herausziehen der konstanten Terme und 

Nutzung der fiktiven Anfangsadresse: 

Ö ℄ 

Ö ℄ 

× × ÄÇÈ 

Ö ℄ 

Ö Ù Ù℄ 

Ù × Ù × Ù ÄÇÈ 

Problematisch bei der zweiten Art der Adressrechnung ist, dass die fiktive 

Adresse adr(a[0, ..., 0]) negativ werden kann und der Wert möglicherweise 

auch nicht mehr in einem Wort darstellbar ist. Dieser Fall tritt insbesondere 

bei sehr hohen unteren Indexgrenzen auf. Für solche Fälle ist es also besser, 

das erstgenannte Berechnungsschema mit den Differenzen zwischen aktuellem 

Index und unterer Grenze zu verwenden. Zur Kontrolle auf Indexfehler kann 

für jeden Index überprüft werden, ob i u und i-u s ist, wobei u die untere 

Grenze und s die zugehörige Spanne ist. 

51


¯ Felddeskriptor 

Prinzipiell ist folgende Information in einem Felddeskriptor enthalten: 

– Die Anzahl der Indexpositionen (Dimension) des Feldes. 

– die Konstanten zur Berechnung der Adresse, z.B. die Indexgrenzen bzw. die 

Spannen, aber auch LOP (Komponentenlänge). 

– die Werte, die für die vorgesehenen Kontrollen vorgesehen sind, beispielsweise 

zur Überprüfung der Indexgrenzen. 

– die Kennung der Daten oder ähnliche Angaben, damit ein einheitlicher 

Zugriffsalgorithmus für alle Felder realisiert werden kann. 

steigende 

Adressen 

adr (a[0,...,0]) 

k 

u1 

sk 

LOP 

Gestreute Realisierung von Felder 

a: 

fiktive Anfangsadresse 

Dimensionenanzahl 

Anfangsindex der 1. Dim. 

s1 Spanne der 1. Dim. 

Spanne der k-ten Dim. 

Komponentenlänge 

a Anfangsadresse 

Im folgenden wird als Alternative zu linearisierten Realisierungen erklärt, wie 2dimensionale 

Felder (Matrix) gestreut realisiert werden können. Gestreut bedeutet 

dabei, dass ein Feld statt mit einem linearen Speicherbereich mit mehreren 

linearen Speicherbereichen, die im Arbeitsspeicher gestreut sein können, realisiert 

wird. Dabei kann das 2-dimensionale Feld entweder zeilenweise oder 

spaltenweise im Arbeitsspeicher abgelegt werden. 

¯ Sei a[u1:o1, u2:o2] das darzustellende Feld; 

52


a[u1, *] 

a[o1, *] 

ref(u1) ref(o1) Referenzen 

1. Zeile von a 

letzte Zeile von a 

Der Speicherbereich Referenzen beinhaltet die Verweise auf die jeweiligen 

Zeilen des 2-dimensionalen Feldes, die als linearer Speicherbereich verwaltet 

werden. 

2.6.2 Programme im Arbeitsspeicher 

Der Adressraum eines Programmes besteht aus drei Teilen: dem statischen Bereich 

mit seinen Maschinenbefehlen und statischen Variablen, der Halde für die dynamischen 

erzeugten Datenstrukturen und dem Keller, der die Blockschachtelung 

der Ablaufstruktur bzgl. der Methodenaufrufe (Unterprogrammaufrufe) widerspiegelt. 

Keller/Stapel 

Halde 

Maschinenbefehle 

statische Variable 

steigende 

Adressen 

¯ Der Keller/Stapel dient zur Aufnahme der Daten bei dynamischen Aktivierungen 

von Unterprogrammen (Methodenaufrufe); blockorientierte Speicherung. 

53


¯ Die Halde dient zur Speicherung von Daten, die dynamisch zur Laufzeit 

aufgebaut werden, z.B. Listen. 

¯ Unterprogrammaufruf bei der MI 

Deklaration in einer Programmiersprache 

ÔÙÐ ÒØ ÔÖÓ ÒØ Ô ÒØ ÔÒ ß 

 

Aufruf im Hauptprogramm: Ö×ÙÐØ ÔÖÓ Ú ÚÒ 

– Ablage im Keller 

R12 

R13 

SP 

...... 

Rückgabewert 

vn 

...... 

v1 

PC 

R14 

...... 

R0 

lokale Variable 

freier Keller 

Keller 

wachstum 

steigende 

Adressen 

– Die Parameter stehen im Keller. Der letzte Parameter wird als erster 

in den Keller geschrieben. Unmittelbar vor Aufruf des Unterprogramms 

zeigt der Kellerpegel auf den ersten Parameter. Achtung: Bei Aufruf 

des Unterprogramms wird noch die Rückkehradresse im Keller abgelegt. 

Im Keller wird auch Speicherplatz für das Ergebnis des Unterprogramms 

reserviert. Falls das Ergebnis sehr groß ist bzw. die Größe nicht a priori 

bekannt ist. wird nur Speicherplatz für eine Adresse reserviert. Das Ergebnis 

54


wird dann auf der Halde gespeichert, und das Unterprogramm gibt nur eine 

Adresse auf die Datenstruktur in der Halde zurück. 

– Unmittelbar nach dem Aufruf werden die aktuellen Register gesichert. 

– Die lokalen Variablen werden ebenfalls im Keller abgelegt. Wir nennen 

diesen Bereich den lokalen Datenraum. 

– R14 (SP) ist immer der aktuelle Kellerpegel. Im Gegensatz zu R12 und R13 

verändert sich also SP normalerweise dynamisch in der Prozedur. 

– Die Register R12 und R13 werden in Unterprogrammen wie folgt benutzt: 

£ R12 zeigt im Keller auf den Bereich der Parameter. Es enthält die 

Ablageadresse des ersten Parameter. 

£ R13 enthält die Basisadresse für den lokalen Datenraum, 

– Befehlsfolge in MI Assembler 

Hauptprogramm: 

ÔÙ× Ê ÛÖØ ÎÓÖÖØÙÒ×Ô× 

ÔÙ× ÚÒ 

ÔÙ× Ú 

ÄÄ ÔÖÓ 

ÔÓÔ ÐÐ ÈÖÑØÖ 

Ò× ÐÐ Ò 

Ê ÛÖØ 

Unterprogramm proc: 

Æ ÖØÙÒ×Ô× 

55


ÈÍËÀÊ ÒÒ×Ô× Ë ÖÒ Ö 

Ê×ØÖ Ê×ØÖ 

ÛÖÒ Ö×Ø ÚÓÒ Ö ÙÖÙÒÒ 

ÈÖÓÞÙÖ × ÖØ ÙÒ ÞÛÖ 

ÚÓÖ ÔÖÓ Ê×ØÖ ÚÖÒÖØ 

ÙÖ È 

ÅÇÎ ËÈ Ê Ö×× Ö×ØÖ ÈÖÑØÖ Ò 

Ê Ê×ØÖ ÝØ× ÖØ 

ÝØ× ×ÔÐ ÑÒØ 

ÅÇÎ Ï ËÈ Ê ××Ö×× ÐÓÐÖ ØÒÖÙÑ 

Ò Ê 

ÐÓÐÒ ØÒÖÙÑ ÒÐÒ 

Ö ÒÙÒ×Ô× 

ÅÇÎ Ï Ê ËÈ × ÐÙ××Ô× ××Ö×× 

ÐÓÐÖ ØÒÖÙÑ Ò ËÈ ÐÐ× 

ÃÐÐÖ Ò Ø ÖØ× ÚÐÐ ÙÖ 

ÈÖÓÞÙÖ ÙØ ÛÙÖ 

ÙÖ ÛÖ Ö ÐÓÐ ØÒÖÙÑ 

ÑÔÐÞØ Ð× Ø 

ÈÇÈÊ Ê×ØÙÖÖÒ Ê×ØÖ 

ÊÌ Ê Ö 

¯ Haldenverwaltung 

In Informatik-Einführungsvorlesung wurde bereits gezeigt, wie dynamisch 

erzeugte Daten, z.B. Listen und Objekte auf der Halde gespeichert werden. Die 

Halde wird nicht nach dem Kellerprinzip verwaltet. Zellen des Kellerspeichers 

werden mit Hilfe der Operation pop oder durch Zurücksetzen des Kellerpegels 

in Register SP (R14) freigegeben. Kellerbereiche werden nach dem LIFO- 

Prinzip verwaltet. Datenobjekte der Halde werden bei Bedarf erzeugt und 

gelöscht. Nicht mehr benötigte Datenobjekte werden entweder explizit 

durch einen Programmaufruf entfernt (z.B. durch Anweisung free(objref)) 

oder implizit durch das System mit Hilfe der Speicherbereinigung (garbage 

collection). Garbage collection ist eine Komponente des Laufzeitsystems, das 

nicht referenzierte Objekte identifiziert, und deren Speicherplatz auf der Halde 

freigibt. 

– Der Speicherbereich einer Halde besteht aus zwei Klassen: 

£ Belegtbereiche: Speicherbereiche werden für Realisierungen von 

Datenobjekten verwendet. 

£ Freibereiche: Speicherbereiche, die momentan nicht für Realisierungen 

von Datenobjekten verwendet werden; d.h. sie sind frei. Belegt- 

56


/Freibereiche sind nicht konsekutiv im Arbeitsspeicher organisiert, 

sondern bestehen jeweils aus einer Menge von Teilbereichen. 

– Buchführung des Speicherbereichs einer Halde mit Hilfe von Belegungs- und 

Freigabeoperationen. 

– Freiliste 

Die Freibereiche der Halde werden mit Hilfe einer Liste (z.B. einfach 

verkettet) verwaltet. 

ÔÙÐ Ð×× ÖÖ ß 

ÒØ ×Þ 

ÖÖ ÒÜØ 

ÑØÓÒÒØÓÒÒ 

 

Für jeden verfügbaren Freibereich wird jeweils die Größe in Bytes 

gespeichert. 

£ Auswahl eines geeigneten Freibereichs 

Bei Erzeugung eines neuen Datenobjektes wird die Operation 

Ð ÒØ ×Þ ausgeführt. Der Parameter size spezifiziert hier die 

Größe des benötigten Speicherbereichs auf der Halde. Für die Auswahl 

eines geeigneten Freibereichs zur Erfüllung der gestellten Anforderungen 

existieren verschiedene Verfahren. 

Æ first-fit-Verfahren 

bestimme von Beginn der Freiliste den ersten Speicherbereich, der 

die Anforderung erfüllt. Der gefundene freie Speicherbereich wird 

aufgeteilt in den Belegtbereich und den nicht benötigten Bereich. 

Letzterer wird wieder in die Freiliste eingetragen. Es kann passieren, 

dass am Beginn der Freiliste die Freibereiche immer kleiner werden, 

d.h. nachfolgende Anforderungen müssen mehr Elemente in der 

Freiliste untersuchen. 

Æ next-fit-Verfahren 

bestimme in der Freiliste den ersten Speicherbereich, der die Anforderung 

erfüllt. Die Suche wird dort fortgesetzt, wo die letzte Suche 

beendet wurde. 

Æ best-fit-Verfahren 

bestimmt in der gesamten Freiliste den Speicherbereich, der am 

besten die gestellte Anforderung erfüllt, d.h. mit möglichst wenig 

Verschnitt. best-fit ist langsamer als first-fit und next-fit, da jeweils 

die gesamte Freiliste durchsucht werden muss. Überraschenderweise 

führt es im Durchschnitt zu größerer Speicherverschwendung; das 

Zuteilungsverfahren hinterläßt mehr sehr kleine Speicherbereiche, die 

nicht mehr zugeteilt werden können. 

57


Æ worst-fit-Verfahren 

bestimme in der Freiliste den größten freien Speicherbereich und teile 

ihn in einen Belegtbereich (zur Erfüllung der Anforderung) und einen 

verbleibenden Freibereich auf. Mit Hilfe des worst-fit-Verfahrens soll 

die Problematik des best-fit-Verfahrens mit seinen vielen kleinen, meist 

nicht mehr nutzbaren freien Speicherbereichen vermieden werden. 

£ Fragmentierung 

Problematisch ist die Entstehung von vielen kleinen freien Rest- 

Freibereichen, die wegen ihrer kleinen Längen als Belegtbereiche 

ungeeignet sind. Zur Vermeidung dieser nutzlosen, kleinen Freibereiche 

ist es zweckmäßig, eine Minimallänge für Freibereiche festzulegen 

und bei Belegungsanforderungen entsprechend längere Belegtbereiche zu 

erzeugen. Auch wird mit Hilfe des worst-fit-Verfahrens die Problematik 

etwas reduziert. 

Animation Haldenverwaltung 


58

Kapitel 3 

Parallele Systeme 

Bis jetzt haben wir die Modellmaschine MI als eine Ein-Benutzer, Ein- 

Programm Rechenanlage betrachtet ohne ein Betriebssystem, das die Ausführung 

von Programmen koordiniert. Wir haben uns dabei mit der Formulierung 

von Benutzerprogrammen auf maschinennaher Ebene beschäftigt. Für die 

Ausführung von Programmen sind eine Reihe von organisatorischen Maßnahmen 

notwendig. Die angesprochenen organisatorischen Aufgaben sind wesentlicher 

Bestandteil der Aufgaben eines Betriebssystems und die Programmierung eines 

Betriebssystems gehört zu dem Bereich der systemnahen Programmierung. 

Typischerweise finden in einem allgemeinen Rechensystem eine Vielzahl 

paralleler Abläufe statt, die miteinander koordiniert werden müssen. Bevor 

wir auf die Aufgaben eines Betriebssystems und insbesondere auf die Bereiche 

Prozess- und Prozessorverwaltung, Speicherverwaltung sowie Ein/Ausgabe 

eingehen, werden wir uns zunächst mit den Problemen beschäftigen, die sich 

daraus ergeben, dass in einem Rechensystem eine Vielzahl von parallelen 

Abläufen/Prozessen, existieren kann, die sich beeinflussen können, miteinander 

kommunizieren oder auch in Konkurrenz zueinander stehen können. 


¯ Bisher betrachtete Aspekte von systemnaher Programmierung: 

– Programm als Repräsentation eines Algorithmus; ein Algorithmus ist ein 

schrittweise effektiv durchführbares Verfahren, in endlichen Schritten; er hat 

eine endliche eindeutige Beschreibung. 

– Programm als sequentielle Folge von Aktionen/Anweisungen (alle Schritte 

nacheinander); 

59

Schlichter, TU München 3.2. GRUNDLAGEN 

– determinierte Programme: unter gleichen Bedingungen und Eingaben 

produziert das Programm stets das gleiche Ergebnis; dies erlaubt eine 

einfaches Testen bzw. Debuggen der Programme und der Prozessabläufe. 

– deterministische Abläufe: eindeutig vorbestimmter Ablauf, keine willkürliche 

Auswahl von alternativen Schritten. 

¯ Übergang 

von sequentiellen Systemen hin zu parallelen Systemen/Programmen. Dabei 

werden die folgenden Aspekte näher betrachtet. 

– gleichzeitige Aktivität von Komponenten, die möglicherweise miteinander 

kommunizieren oder aufeinander einwirken. 

– Beispiele 

£ HW-Komponenten eines Rechensystems, z.B. Prozessor und E/A- 

Controller, siehe Rechnerarchitektur (siehe Seite 14). 

£ SW-Komponenten eines Rechensystems, z.B. parallel ablaufende Programme, 

siehe MI-Mehrprozessorarchitektur (siehe Seite 19); u.U. Zugriff 

auf gemeinsame Ressourcen, z.B. Daten im Arbeitsspeicher. 

£ SW-Komponenten in einem verteilten System, d.h. Rechensysteme, die 

über ein Rechnernetz miteinander verbunden sind. 

– Aspekte des Abschnitts 

£ Modellierungstechniken zur Analyse und Beschreibung der Eigenschaften 

paralleler Systeme (Spuren, Petrinetze). 

£ Threads als Mittel zur Realisierung von Parallelität innerhalb eines 

Prozesses. 

£ Synchronisation in parallelen Systemen. Hier geht es darum, dass 

Konkurrenz in parallelen Systemen koordiniert werden muss, um 

Inkonsistenzen in Rechensystemen zu vermeiden. Erhaltung der kausalen 

Beziehungen zwischen Aktionen; Synchronisation des Zugriffs auf 

gemeinsame Ressourcen. 

£ Mechanismen zur Behandlung von Verklemmungen. Im Rechensystem 

gibt es keinen Fortschritt, da sich die einzelnen Prozesse gegenseitig 

blockieren. 

3.2 Grundlagen 

In diesem Teilabschnitt werden kurz die wichtigsten Begriffe definiert sowie 

Konzepte zur Formulierung paralleler Aktivitäten aufgelistet. Einige dieser 

Konzepte werden in nachfolgenden Teilabschnitten ausführlicher diskutiert. 

60


3.2.1 Begriffsdefinitionen 

Nebenläufigkeit 

Nebenläufigkeit (engl. concurrency) bezieht sich auf die zeitliche Beziehung 

zwischen den Aktivitäten von Komponenten, die gleichzeitig oder zeitlich 

verzahnt (engl. interleaving) ablaufen können. 

¯ z.B. gleichzeitig: Drucken eines Dokuments und Berechnen einer Formel in 

einer Tabellenkalkulation (CPU-Nutzung). 

¯ z.B. zeitlich verzahnt: Benutzerauftrag muss CPU abgeben und wartet; ein 

anderer Auftrag wird (teilweise) ausgeführt und gibt CPU wieder zurück bevor 

das Ende erreicht ist. Hier spricht man auch von Pseudoparallalität. 

Parallelität 

Parallelität wird häufig synonym zu Nebenläufigkeit verwendet; 

¯ spezielle Form der Nebenläufigkeit: mehrere Prozessoren stehen zur Ausführung 

zur Verfügung. Ein Beispiel dafür ist die MI Modellmaschine mit bis 

zu 4 Prozessoren. Auch bei einem Ein-Prozessor gibt es echte Parallelität zwischen 

E/A-Controller (z.B. mit angeschlossenem Drucker) und CPU. 

Verteiltheit 

Verteilheit (engl. distribution) ist die räumliche oder auch nur konzeptionelle 

Aufteilung der Komponenten eines Systems, z.B. vernetzte PCs. Die Verteilung 

kann sich sowohl auf der Ebene der HW-Komponenten als auch auf der Datenund 

Anwendungsebene abspielen. Der Verteilungsaspekt wird vor allem Ende der 

Vorlesung näher beleuchtet. 

Interaktion 

Kommunikation, Synchronisation, Konkurrenz betrifft die kausalen Beziehungen 

zwischen räumlich verteilten und nebenläufig ausgeführten Aktivitäten. 

¯ kausale Abhängigkeit zwischen Ampel und Fußgänger: 

Ereignis von Fußgänger: 

er drückt Knopf 

Ereignis beeinflusst Ampel: sie schaltet auf Rot für Auto 

61


¯ Kommunikation: Prozesse auf dem gleichen oder unterschiedlichen Rechensystemen 

tauschen Nachrichten untereinander aus. 

¯ Koordinierung: Beziehung zwischen Auftraggeber und Auftragnehmer 

Erstellen eines Auftrages durch Client und anschließendes Bearbeiten des 

Auftrags durch Server. 

¯ Konkurrenz: Aktivitäten eines Prozesses behindern die eines anderen Prozesses 

z.B. Warten, wenn CPU von anderem Prozess belegt. 

Nichtdeterminismus 

System zeigt bei gleichen Ausgangsbedingungen und gleichen Eingaben 

unterschiedliches Verhalten (Reihenfolge der Prozesse spielt eine Rolle!). 

Problem: Nichtreproduzierbarkeit von Ergebnissen, Testen von parallelen 

Programmen bei Nichtdeterminismus ist schwierig. Beispiel: 

Ü ÈÖÓÞ×× Ü Ü ÈÖÓÞ×× Ü Ü 

Ausführungsreihenfolge 

È ÚÓÖ È Ü 

È ÚÓÖ È Ü 

3.2.2 Beschreibungskonzepte 

Es gibt eine Vielzahl von Konzepten zur Formulierung paralleler Aktivitäten. 

In der Vorlesung werden wir uns vor allem mit den beiden modell-basierten 

Ansätzen, Ereignisse und Petrinetze befassen. Es gibt auch noch andere 

Modellansätze, z.B. formale Beschreibungssprachen (Estelle, LOTOS), die 

z.T. auf Prozessalgebren basieren. Eine andere Möglichkeit sind parallele 

Programmiersprachen. 

modell-basierte Konzepte 

¯ ereignis-orientiert: es wird der Ablauf von Prozessen betrachtet; jeder 

Ablauf wird durch eine Menge von Ereignissen charakterisiert. Jeder 

Ablauf repräsentiert eine Ereignisspur. Ereignisse können in kausalem 

Zusammenhang stehen. Es werden nun eine Menge von Prozessen und deren 

Zusammenwirken betrachtet, insbesondere auch wie deren Ereignismengen im 

Zusammenhang zueinanderstehen. 

62

Schlichter, TU München 3.3. MODELLIERUNG PARALLELER SYSTEME 

¯ graphisch-orientiert: der Prozessablauf wird graphisch dargestellt. Petrinetze 

sind ein Beispiel dafür. Petrinetze sind Graphen mit 2 Arten von Knoten, 

den Stellen und Transitionen. Abläufe werden durch das Schalten von 

Transitionen und der Propagierung von Marken charakterisiert. Dabei können 

Aussagen bzgl. der kausalen Abhängigkeit, aber auch der Unabhängigkeit von 

Teilabläufen getroffen werden. 

Sprachkonstrukte in Programmiersprachen 

¯ parallele Komposition von Teilabläufen innerhalb eines Prozesses, z.B. Java 

Threads. Andere Beispiele sind Tasks in Ada, Prozesshierarchien in 

Betriebssystemen (fork, join) oder auch parbegin, parend. 

¯ Kommunikationskonzepte: u.a. send, receive 

¯ Synchronisationskonzepte: u.a. lock, unlock 

Konzepte in Betriebssystemen 

¯ Prozesskonzept = Programm in Ausführung; 

¯ Threadkonzept = leichtgewichtigter Prozess 

¯ Kommunikation: Shared memory, Dateien, Nachrichten etc. 

¯ Synchronisation: Unterbrechungen (Interrupts), Sperren etc. Das Auftreten 

von Unterbrechungen sowie deren Behandlung wird im Verlaufe der Vorlesung 

noch näher behandelt. 

3.3 Modellierung paralleler Systeme 

In diesem Abschnitt behandeln wir grundlegende Mechanismen zur Modellierung 

und Beschreibung parallel ablaufender Systeme. Siehe auch das Buch M. Broy 

"Informatik", Springer-Verlag. Insbesondere geht es in diesem Abschnitt um 

folgendes: 

das Verhalten von parallelen Systemen klären, 

sich auf wesentliche Aktionen, Ereignisse konzentrieren (Abstraktion), 

die Abhängigkeiten zwischen Aktionen ermitteln/klären, 

Fehler oder Konflikte aufgrund paralleler Tätigkeiten vermeiden und 

maximale Parallelität erzielen. 

63


3.3.1 Modellierungsziele 

Ziel ist die einfache Analyse und Beschreibung von parallelen Systemen. 

¯ Spezifikation eines Modells im Sinne von Abstraktion: Vereinfachung, 

Weglassen von Details, Beschränken auf interessierende Eigenschaften. 

¯ Beispiele interessanter Eigenschaften sind: 

– Determiniertheit. 

– Störungsfreiheit. Für störungsfreie Systeme gilt, dass unter Einhaltung der 

durch eine Ordnung (später wird hierzu die Kausalitätsordnung zwischen 

Ereignissen verwendet) festgelegten Reihenfolge, die Ausführungsreihenfolge 

der parallelen Ereignisse und deren Aktionen keinen Einfluss auf die 

berechneten Ergebnisse hat. 

– wechselseitiger Ausschluss. Hier geht es darum, dass bei konkurrierenden 

Zugriffen auf gemeinsame Ressourcen, die exklusiv benutzt werden, immer 

nur ein Prozess zu einem Zeitpunkt darauf zugreift. Damit soll die 

Konsistenz sichergestellt werden. 

– Endloses Blockieren (engl. Deadlock). 

– Verhungern (engl. Starvation). Beispielsweise erzielt ein Prozess keinen 

Fortschritt, da er nie rechnend gesetzt wird, obwohl er rechenbereit wäre. 

In Rechnerkernvergabe gibt es jedoch immer einen anderen rechenbereiten 

Prozess, der eine höhere Priorität hat. 

¯ Die Eigenschaften können in zwei Klassen eingeteilt werden. 

– Sicherheitseigenschaften (engl. safety): Sicherstellen, dass gewisse unerwünschte 

Zustände und unerwünschte Aktionsverläufe nicht auftreten; Formulierung 

durch Invarianten (z.B. wechselseitig ausgeschlossene Nutzung 

der CPU). Hier geht es nicht um Datensicherheit, d.h. persistente Speicherung 

von Daten, damit sie auch nach einem Systemcrash noch zur Verfügung 

stehen. Es geht auch nicht um Datenschutz, d.h. dass Daten nicht für 

andere Prozesse lesbar sind. 

– Lebendigkeitseigenschaften (engl. liveness): Garantieren, dass gewisse 

erwünschte Zustände bzw. Aktionsmuster in den Abläufen irgendwann 

auch auftreten (z.B. erwünschter Ablauf: 

irgendwann auch Fortschritte). 

rechenbereiter Prozess macht 

64


3.3.2 Verhaltensbeschreibung 

Verhaltensbeschreibungen eines dynamischen Systems sind Beschreibungen der 

Eigenschaften des Systems und deren Veränderungen über der Zeit. Das Verhalten 

eines Systems kann mit Spuren in einem 2-dimensionalen Raum beschrieben 

werden: Die 1. Dimension ist die Zeit, mit der das Fortschreiten der Ausführung 

der Berechnungen erfasst wird, d.h. hier geht es um die Folge von Ausführungen 

von elementaren Aktionen, die jeweils Ereignisse auslösen. Die 2. Dimension 

ist der Raum der Eigenschaften des Systems, mit dem die Systemzustände in 

Zeitpunkten erfasst werden. Zu Zeitpunkten wird jeweils ein Schnappschuss des 

Systemzustands genommen. Über die Zeitachse wird eine Folge von Zuständen 

angegeben, die sich mit der Ausführung der Aktionen (Berechnungen) ergibt. 

Verhaltensbeschreibung setzt sich aus den Basiseinheiten Aktionen und Zustände 

zusammen. 

¯ Eigenschaftenveränderungen sind Ausführungen von elementaren Aktionen. 

Ausführungen von komplexen Berechnungen können mit Kombinationen von 

Ausführungen dieser elementare Aktionen beschrieben werden. Es sind zwei 

Sichten möglich. 

– Die Sicht auf die Tätigkeiten, die auszuführen sind; in dieser Sicht sind 

die Basiseinheiten die atomaren Aktionen. Eine Aktion kann ein MI- 

Maschinenbefehl oder eine Java Anweisung sein. 

– Die Sicht auf die Veränderungen, die erfolgen und beobachtet werden 

können; in dieser Sicht sind die Basiseinheiten die atomaren Ereignisse, 

die eintreten. Die Ausführung einer Aktion führt zu einem Ereignis im 

Rechensystem. Aktionen und Ereignisse sind dual zueinander und können 

nach Bedarf genutzt werden; hier wird überwiegend die Ereignissicht 

benutzt. Aktionen können mehrfach ausgeführt werden; sie resultieren in 

mehrfachen Ereignissen. 

¯ Aktionen bzw. Ereignisse sind zeitlich geordnet. In einem sequentiellen 

System werden die elementaren Aktionen sequentiell ausgeführt, d.h. es 

existiert eine lineare Ordnung bzgl. der Zeitachse. Diese Zeitachse für 

Verhaltensbeschreibungen hat mit der gewohnten, physikalischen Zeit die 

lineare Ordnung gemeinsam; sie abstrahiert jedoch als diskrete Zeit von der 

Dauer der Ausführung von Aktionen. In einem parallelen System müssen 

zusätzlich auch nebenläufige Aktionen betrachtet werden, d.h. für sie kann 

keine zeitliche Reihenfolge bestimmt werden. 

¯ Zustände des Systems anhand der Werte der Datenobjekte. Folge von 

Zuständen gemäß der Zeitachse. Jedem Zeitpunkt wird der Zustand der 

65


Datenobjekte, der mit dem Zeitpunkt erreicht ist, zugeordnet. Für jeden 

Zeitpunkt wird damit ein Schnappschuss vom System angegeben; über der 

Zeitachse wird die Folge der Zustände angegeben, die sich mit der Ausführung 

der Berechnungen ergibt. 

¯ Spuren 

Es sind zwei Varianten von Verhaltensbeschreibungen zweckmässig. 

1. Ereignisspuren: Sie beschreiben den zeitlichen Ablauf der Berechnungen 

eines Systems mit Ereignissen, die linear geordnet sind. 

2. Zustandsspuren: Sie beschreiben den zeitlichen Ablauf der Berechnungen 

eines Systems anhand der auftretenden Zustände der Datenobjekte. Ereignisspur 

und Zustandsspur sind eng miteinander verknüpft. Bei Auftreten eines 

Ereignisse wird jeweils ein Schnappschuss des Systems genommen. Dieser 

Schnappschuss stellt ein Element der Zustandsspur dar. 

3.3.3 Ereignisse und Aktionsstrukturen 

In diesem Abschnitt wird der Begriff Prozess anhand von Aktionsstrukturen mathematisch 

gefasst. Dies ermöglicht die mathematische Modellierung beliebiger, 

nichtkontinuierlicher ("diskreter") Abläufe verteilter Systeme, insbesondere von 

Prozessen in Rechenanlagen. Durch diese Modellierung können jedoch auch andersartige, 

technische oder betriebliche Vorgänge, die sich aus Einzelaktionen 

zusammensetzen und zwischen denen kausale Beziehungen bestehen, erfasst werden. 

Prozess 

Gegeben seien eine Menge (das "Universum") E * von Ereignissen (engl. events) 

und eine Menge A von Aktionen (engl. actions). 

¯ Definition 

Ein Triple p = (E, , «) nennen wir einen Prozess oder auch eine 

Aktionsstruktur, falls folgende Aussagen gelten: 

– E E * , E heißt die Ereignismenge. 

– ist eine partielle Ordnung über E, ist die Kausalitätsrelation. 

Die partielle Ordnung ist eine reflexive, transitive und antisymmetrische 

Relation. 

66


– «: E A ist die Aktionsmarkierung des Prozesses p. 

– Die Abbildung « ordnet jedem Ereignis eine Aktion zu. In dieser Definition 

von Aktionsstrukturen ist auch der leere Prozess eingeschlossen. Er wird 

durch die Aktionsstruktur dargestellt, die aus der leeren Ereignismenge 

besteht. 

¯ Beispiel: Fußgängerübergang 

Wir betrachten einen Prozess mit 14 Ereignissen. 

Aktionen zugeordnet. 

Jedem Ereignis werden 

Ereignis Aktion 

e1 Knopf wird gedrückt 

e2 Ampel für Autofahrer schaltet auf Gelb 

e3 Ampel für Autofahrer schaltet auf Rot 

e4 Auto hält auf Spur 1 

e5 Ampel für Fußgänger schaltet auf Grün 


e7 Fußgänger benutzt Fußgängerübergang 


e9 Ampel für Fußgänger schaltet auf Rot 

e10 Ampel für Autofahrer schaltet auf Rot und Gelb 

e11 Ampel für Autofahrer schaltet auf Grün 

e12 Auto fährt an auf Spur 1 



e15 Knopf wird gedrückt 

Die Ausführung einer Aktion löst ein Ereignis aus. Wird dieselbe Aktion 

mehrmals ausgeführt, so wird jeweils ein neues Ereignis ausgelöst. 

– Die Relation der kausalen Abhängigkeiten sei gegeben durch: 

e1 e2, e2 e3, e3 e4, e3 e5, e3 e6, e5 e7, 

e3 e8, e5 e9, e9 e10, e10 e11, e11 e12, 

e11 e13, e11 e14, e4 e12, e6 e13, e8 e14, e9 e15. 

Die kausalen Abhängigkeiten ergeben keine vollständige Ordnung. 

– Diese Beziehungen erzeugen (durch die Bildung der reflexiv transitiven 

Hülle) eine partielle Ordnung, die die Kausalität zwischen den Ereignissen 

beschreibt. Man beachte, dass hier beispielsweise das Ereignis e12 nur 

stattfindet, nachdem die Ereignisse e4 und e11 stattgefunden haben. 

– Graphische Darstellung 

Endliche Prozesse lassen sich anschaulich durch knotenmarkierte, gerichtete, 

zyklenfreie Graphen darstellen, Die Knoten repräsentieren die Ereignisse 

und sind durch Aktionen markiert. 

67


e6 

e1 e2 e3 e4 

e8 

e5 

e9 e10 e11 

¯ Charakterisierung von Prozessen 

In einem Prozess hat jedes Ereignis eine eindeutige Identität ("X betritt am 

19.1.2001 um 11:15 h den Hörsaal"), eine Aktion kann jedoch mehrfach 

stattfinden (die Aktion "X betritt den Hörsaal" kann mehrfach stattfinden). 

Dementsprechend kann in einem Prozess verschiedenen Ereignissen die gleiche 

Aktion zugeordnet sein. Ereignisse haben einen eindeutigen Bezeichner; 

Prädikate sind eine andere Möglichkeit, Ereignisse zu identifizieren, z.B. 

Ermordung Kennedy's oder die Kreuzigung Christi. 

– Parallel, nebenläufig 

Für einen Prozess p = (E, , «) nennen wir zwei Ereignisse e1, e2 E 

parallel oder nebenläufig (engl. concurrent), falls sie im Prozess p nicht in 

einer kausalen Relation stehen, d.h. wenn gilt: 

(e1 e2 oder e2 e1) 

£ Parallele Ereignisse sind kausal unabhängig, sie können zeitlich 

nebeneinander oder in beliebiger Reihenfolge stattfinden. 

– Sequentiell 

Ein Prozess p = (E, , «) heißt sequentiell, wenn in ihm kein Paar von 

parallelen Ereignissen auftritt, d.h. die Kausalitätsrelation eine lineare 

Ordnung ist. Damit gilt für zwei beliebige Ereignisse e1 und e2 stets 

entweder e1 e2 oder e2 e1. 

– Der Ablauf eines Programmes kann auch als Prozess im Sinne der 

Aktionsstrukturen gedeutet werden. 

sequentielle Prozesse. 

– Endlich 

Sequentielle Programme erzeugen 

Ein Prozess p = (E, , «) heißt endlich, falls seine Ereignismenge 

eine endliche Menge ist. Beispielsweise ist das Abspielen einer CD ein 

endlicher Prozess, während ein Betriebssystem einen unendlichen Prozess 

68 

e7 

e15 

e14 

e13 

e12


repräsentiert. Unendliche Prozesse besitzen unendliche Ereignismengen. 

Unendliche Prozesse können jedoch endlich beschreibbar sein. 

Kausale Abhängigkeiten 

Häufig finden wir in Prozessen unterschiedliche Ursachen für die kausale 

Beziehung e d zwischen Ereignissen e und d. Im einzelnen können drei 

verschiedene Arten unterschieden werden. 

¯ Echt kausale Beziehungen 

das Ereignis e ist kausal für das Ereignis d in dem Sinn, dass d ohne e niemals 

auftreten kann. 

– Beispiel 

e = Geldeinwurf, d = Kartenausgabe; e d, d.h. der Fahrkartenautomat gibt 

erst dann eine Fahrkarte aus, wenn der passende Geldbetrag eingeworfen 

wurde. 

¯ zeitliche Beziehungen 

das Ereignis e endet, bevor das Ereignis d beginnt. 

– Beispiel: Nachricht muss gesendet sein, bevor sie empfangen werden kann. 

– Happend-before 

Die kausale Beziehung impliziert also eine zeitliche Relation; das ist die 

bekannte happened before-Beziehung von L. Lamport. Die Umkehrung 

gilt nicht. Die zeitliche Relation zwischen Ereignissen sagt nichts über die 

Kausalität aus. 

£ Wichtig: Ereignisse wurden als atomare Ereignisse modelliert. D.h. 

Beginn und Ende fallen auf einen Zeitpunkt zusammen. Ein alternativer 

Ansatz wäre die Spezifikation eines Zeitintervalls für ein Ereignis mit 

Anfangs- und Endzeitpunkt. Damit könnten auch Überlappungen von 

Ereignissen modelliert werden. 

£ Die Happend-before Relation spielt im Kontext von Verteilten Anwendungen 

eine wichtige Rolle (siehe Vorlesung Verteilte Anwendungen (URL: 

http://www11.in.tum.de/lehre/vorlesungen/archiv)). Insbesondere in der 

Gruppenkommunikation wird sie eingesetzt, um die an alle Gruppenmitglieder 

gesandten Nachrichten zu sequentialisieren. Auf diese Weise soll 

erreicht werden, dass alle Gruppenmitglieder in einen für die Gruppe konsistenten 

Zustand versetzt werden. 

69


¯ Systembeschränkungen 

Systembeschränkungen, z.B. wechselseitiger Ausschluss. Das Ereignis e darf 

nicht parallel zum Ereignis d auftreten. 

– Beispiel 

e = Fußgänger überquert die Fahrbahn beim Übergang, und 

d = Auto überfährt den Übergang. 

e und d dürfen nicht parallel ausgeführt werden, aber es besteht keine 

echte kausale Abhängigkeit zwischen e und d. Ereignisse, welche 

mit Aktionen markiert sind, die aufgrund von Systembeschränkungen 

nicht parallel stattfinden können, sind nicht unbedingt in einem "echt" 

kausalen Zusammenhang. Trotzdem sollten sie nicht als parallele 

Ereignisse auftreten. Um diese Systembeschränkungen mit den eingeführten 

Modellierungskonzepten (uninterpretierte Aktionen) zu erfassen, müssten sie 

in eine (künstliche) kausale Abhängigkeit gebracht werden; das ist aber meist 

nicht sehr sinnvoll. Wir werden später sinnvollere Möglichkeiten kennen 

lernen. 

Sequentialisierung 

Idee: vereinfachte Darstellung paralleler Abläufe, aus der Sicht eines 

Beobachters. Ein sequentieller Prozess hat genau eine vollständige Sequentialisierung, 

nämlich die vorgegebene Reihenfolge der Ereignisse. Durch « ergibt 

sich aus der Ereignisreihenfolge eine Folge von Aktionen. Vollständige Sequentialisierung: 

partielle Kausalitätsordnung zu linearer Ordnung ergänzen. 

¯ Definition 

Ein Prozess p 1 =(E 1 , 1 , « 1 ) heißt eine Sequentialisierung eines Prozesses p 2 

=(E 2 , 2 , « 2 ), falls gilt: 

E 1 =E 2 

e, d E 1 :e 2 d e 1 d 

« 1 = « 2 

– Ist p 1 sequentiell, so heißt die Sequentialisierung vollständig. Die 

Vervollständigung einer partiellen Ordnung zu einer linearen Ordnung heißt 

topologisches Sortieren. 

¯ Ein sequentieller Beobachter eines Prozesses ist ein Beobachter, der die 

Ereignisse eines Prozesses und die entsprechenden Aktionen in einem 

70


sequentiellen Ablaufprotokoll festhält. Parallele Aktionen werden dabei in 

eine zufällige Reihenfolge gebracht. Das Ergebnis der Beobachtung ist 

ein sequentieller Prozess, der einer zufällig gewählten Sequentialisierung 

entspricht. Gehen wir von sequentiellen Beobachtern aus, so erhalten wir 

sequentielle Prozesse als Beobachtungen. 

¯ Existiert für einen nichtsequentiellen Prozess eine Reihe von Beobachtungen, 

die alle vollständige Sequentialisierungen des Prozesses darstellen, so lässt sich 

aus diesen Beobachtungen der Prozess teilweise rekonstruieren. Kennen wir die 

Gesamtmenge aller Sequentialisierungen, so lässt sich der Prozess eindeutig 

rekonstruieren. Für den Beweis siehe Broy, Band II, S 12. 

¯ Die Ausführung eines Programms auf einer Rechenanlage kann ebenfalls 

als Prozess dargestellt werden. Gewisse Anweisungen ("Aktionen") eines 

Programms zerfallen bei der Ausführung auf einer Rechenanlage in eine Reihe 

von Einzelaktionen. 

¯ Beispiel 

Für das Beispiel des Fußgängerübergangs ist folgendes eine vollständige 

Sequentialisierung. 

e1 e2 e3 e4 e6 e5 e7 e8 e9 e10 e11 e14 e12 e13 e15 

¯ Spuren 

Darstellung sequentieller Prozesse mittels Spuren. Sequentielle Prozesse sind 

Spezialfälle paralleler Prozesse. Für die Darstellung sequentieller Prozesse 

bietet sich eine wesentlich einfachere Darstellungsform als Aktionsstrukturen. 

Wir können ganz auf die explizite Angabe von Ereignismengen verzichten und 

stattdessen endliche oder unendliche Sequenzen von Aktionen verwenden. 

– Sei A eine Menge von Aktionen, dann bezeichnen wir mit A + die Menge 

der endlichen Folgen von Aktionen aus A und mit A die Menge der 

unendlichen Folgen von Aktionen. 

– Jedem sequentiellen Prozess können wir eindeutig eine Folge von Aktionen 

zuordnen, wie sprechen von der Spur (engl. trace). Sei p = (E, , «) ein 

sequentieller Prozess. Wir definieren: 

£ spur : {p | p ist sequentieller Prozess } A + A 

£ spur(p) = empty, falls E = Ø 

£ spur(p) = a ¡ spur(p | E \ {e}), falls E Ø, wobei e das gemäß der 

Kausalitätsordnung kleinste Ereignis in p ist und «(e) = a gilt. 

71


p|E\{e}bezeichnet den Teilprozess, der durch die Einschränkung 

auf die Ereignismenge E \ {e} entsteht. 

"¡" ist hier die Konkatenation von Aktionen, die sich durch die Ereignisse 

ergeben. spur ist eine Abbildung auf die Menge der Aktionen. Als 

Ergebnis liefert spur einen Strom (engl. stream) von Aktionen. 

– Für einen nichtsequentiellen Prozess p gilt: 

Spuren(p) = {spur(q) : Prozess q ist eine vollständige Sequentialisierung 

von p} 

Spuren sind ein einfacheres Modell für sequentielle Abläufe eines Systems 

als Aktionsstrukturen. Da bei nichtsequentiellen Systemen in vielen 

Anwendungen die Frage, welche Aktionen parallel zueinander auftreten 

können, von untergeordneter Bedeutung ist, ist es naheliegend für 

solche Systeme vereinfachend statt ihrer nebenläufigen Prozesse deren 

Sequentialisierungen als Abläufe zu betrachten. In vielen Ansätzen zur 

Modellierung verteilter Systeme werden nicht Prozesse mit ihrer expliziten 

Darstellung von Parallelität, sondern die technisch etwas einfacher zu 

handhabenden Mengen von Aktionsströmen verwendet. 

3.3.4 Aktionen als Zustandsübergänge 

Neben der Beschreibung von Systemen durch die Prozesse, die deren Abläufe 

bilden, ist es naheliegend, Systeme durch Zustände und ihr Verhalten durch 

Zustandsänderungen zu modellieren. Zustandsraum = Menge aller 

Systemzustände. Dazu geben wir für ein System einen Zustandsraum an. Dieser 

besteht aus der Menge aller Zustände, die das System einnehmen kann. Auf dieser 

Basis beschreiben wir dann alle Zustandsübergänge, die im System auftreten 

können. 

Interpretierte Aktionen 

Aktionen werden Zustandsänderungen als Bedeutung zugeordnet. Bisher haben 

wir die Mengen der Aktionen nicht weiter interpretiert. Eine Deutung für 

Aktionen in Prozessen liefern Zustandsänderungen. Dazu weisen wir Aktionen 

Zustandsänderungen als Bedeutung zu. Dabei interessiert uns insbesondere die 

Frage, ob wir über diese Zuordnung auch Prozessen eindeutig eine Bedeutung 

zuordnen können. 

72


Modell 

Zu diesem Zweck definieren wir nichtdeterministische Zustandsautomaten mit 

Transitionsaktionen. 

¯ Zustandsautomat 

Ein nichtdeterministischer Zustandsautomat ist gegeben durch: 

– S, eine Menge von Zuständen, genannt Zustandsraum, 

– A, eine Menge von Transitionsaktionen, 

– R S ¢ A ¢ S eine Zustandsübergangsrelation, 

£ Seien s , s S und a A gegeben. (s , a, s ) R bedeutet, 

0 1 

0 1 

dass im Zustand s die Aktion a ausgeführt werden kann und dies zum 

0 

Nachfolgezustand s S führen kann. 

1 

£ Diese Art von Automaten heißt nichtdeterministisch, da in einem 

Zustand mehrere Transitionsaktionen möglich sein können und eine 

Transitionsaktion zu unterschiedlichen Nachfolgezuständen führen kann. 

£ Wir schreiben (für gegebene Relation R) s s , um auszudrücken, dass 

0 a 1 

(s ,a,s ) R gilt. 

0 1 

– S0 eine Menge von möglichen Anfangszuständen. 

¯ Beispiel Fahrkartenautomat 

Akzeptiert werden 1- und 2 DMark Münzen. Mittels zweier Knöpfe kann man 

zwischen einer Kurzstrecke für 1 DM oder einer normalen Fahrt für 2 DM 

wählen. Der Automat gibt Wechselgeld zurück. 

– Menge der Zustände 

S S xS mit 

1 2 

S = {Wahl, kurz, normal} und S = {-1,0,1,2} 

1 2 

mit der folgenden Interpretation eines Zustandes s = (a, b): 

a= Wahl: Automat wartet auf die Wahltaste 

a= kurz: eine Kurzstreckenkarte wurde gewählt und ist noch auszugeben 

a= normal: eine normale Fahrkarte wurde gewählt und ist noch 

auszugeben 

b= -1 : es ist noch 1 DM zurückzugeben 

b= 0 : es ist kein Geld mehr einzuwerfen oder zurückzugeben 

b= 1 : es muss noch 1 DM eingeworfen werden 

b= 2 : es muss noch 2 DM eingeworfen werden 

73


– Menge der Transitionsaktionen 

A = {Wk, Wn, E1, E2, R1, Ak, An }, mit 

Wk: Wahl einer Kurzstreckenkarte 

Wn: Wahl einer normalen Fahrkarte 

E1: Einwurf eines 1DM Stückes 

E2: Einwurf eines 2DM Stückes 

R1: Rückgabe eines 1DM Stückes 

Ak: Ausgabe einer Fahrkarte für Kurzstrecke 

An: Ausgabe einer Normalfahrkarte 

– Zustandsübergänge 

(normal, 2) 

E1 

Wn Wk 

(Wahl, 0) 

E1 

E1 

(normal, 1) (normal, 0) (kurz, 0) (kurz, 1) 

E2 

E2 

R1 

An 

R1 

An 

Ak 

(normal, -1) (Wahl, -1) (kurz, -1) 

¯ Aktionsspur 

Jedem Zustandsautomaten lassen sich ausgehend von der gegebenen Menge 

von Anfangszuständen Spuren zuordnen. 

– Definition 

Gegeben sei ein Zustandsautomat Z = (S, A, R, S0). Eine Folge a , wobei 1 

i 

i k mit k IN { }, ist eine endliche oder unendliche Aktionsspur 

des Zustandsautomaten, falls eine Folge von Zuständen s existiert, mit s 

i i 

S, s S0 und 

1 

s s für alle i mit 1 i k 

i-1 ai i 

– Eine Aktion a heißt deterministisch, wenn für jeden Zustand s S höchstens 

ein Nachfolgezustand s S existiert mit 

f 

s s 

a f 

– Beispiel 

Auswertung eines Programms mit Zustandsänderung. Das Programm 

74 

Ak 

R1 

E2


Ý 

Ü 

ÛÐ Ü ß 

Ý Ü Ý Ü Ü 

 

berechnet die Fakultätsfunktion. Nach seiner Ausführung gilt 10! = y. Der 

Ablauf dieses Programms entspricht der sequentiellen Aktionsstruktur, deren 

Ereignisse, Aktionen und Zustände in der folgenden Tabelle angegeben sind. 

Ereignis Aktion Zustand x Zustand y 

a0 y = 1 undefiniert 1 

b0 x = 10 10 1 

a1 (x 0) ? 10 1 

b1 y=x*y 10 10 

c1 x=x-1 9 10 

... ... ... ... 

a10 (x 0)? 1 10! 

b10 y = x * y 1 10! 

c10 x = x - 1 0 10! 

a11 (x 0)? 0 10! 

Hier bezeichnen Aktionen wie (x 0)? Abfrageaktionen, die den 

Datenzustandsraum nicht ändern. Nehmen wir jedoch Kontrollzustände 

(etwa einen Befehlszähler) mit zu den Zuständen des Zustandsraums hinzu, 

so ändert auch diese Abfrage den Zustand. Zustände sind für das obige 

Programm durch Paare (n, m) von Zahlen gegeben, die die Werte der 

Programmvariablen x und y repräsentieren. Mit jeder Zuweisung in 

einem prozeduralen Programm wird eine Aktion verbunden, die einer 

Zustandsänderungsabbildung entspricht. 

Konflikte 

Im Zusammenhang mit Programmen und den ihnen zugeordneten Prozessen 

stellt sich die Frage, welche Zustandsänderungen ohne Schwierigkeiten zeitlich 

parallel durchgeführt werden können. In vielen Fällen lassen sich Aktionen 

zeitlich nebeneinander ausführen. Gewisse Zustandsänderungen können aber 

nicht ohne Konflikte nebeneinander ausgeführt werden. Wir sagen, dass diese 

Aktionen im Konflikt miteinander sind. Sollen beispielsweise zwei Anweisungen 

an die gleiche Programmvariable x parallel ausgeführt werden, so lässt sich dem 

entsprechenden Prozess keine Zustandsänderungsabbildung eindeutig zuordnen. 

In beiden Aktionen soll die Programmvariable x geändert werden. Die Aktionen 

sind im Konflikt. 

¯ Beispiel 

75


Mögliche Konflikte bei parallel durchzuführenden Zuweisungen. Wir 

betrachten die Aktionen, die den folgenden beiden Zuweisungen entsprechen: 

Ü Ü 

Ü Ü 

Die Zuweisungen stehen im Konflikt zueinander. 

– Werden sie parallel ausgeführt, so kann dem entsprechenden Prozess 

keine Zustandsänderung eindeutig zugeordnet werden; wir sagen auch, die 

Aktionen stören sich wechselseitig. 

¯ Störungsfreiheit 

Frage: Gibt es Kriterien, um auf einfache Weise solche Konflikte zu erkennen, 

so dass sie durch eine Reihenfolgeregelung gelöst werden können? Die Frage 

kann mit ja beantwortet werden; es gibt Kriterien, und zwar die Bernstein- 

Bedingungen. 

– Vorbereitung 

Für eine Transitionsaktion a gelte: 

V(a) S ist Vorbereich, d.h. die Menge der gelesenen Zustandsvariablen. 

N(a) S ist Nachbereich, 

Zustandsvariablen. 

– Beispiel 

Sei S = {x, y, z} 

d.h. die Menge der geschriebenen 

Ü Ü Ý Þ Î ßÜ Ý Þ Æ ßÜ 

Ý Ü Î ßÜ Æ ßÝ 

– Definition Störungsfreiheit 

Gegeben sei ein Prozess p= (E, , «). Der Prozess p heißt störungsfrei, 

genau dann, wenn für jedes Paar von Ereignissen e1, e2 E gilt: 

1.) e1 e2 oder e2 e1 oder 

2.) V(«(e1)) N(«(e2)) = N(«(e1)) V(«(e2)) = N(«(e1)) N(«(e2)) = Ø. 

£ Die Bedingung (2) nennt man auch Bernstein-Bedingungen. Gilt die 

Bernsteinbedingung, dann ist die Reihenfolge der Ausführung der beiden 

Zuweisungen ohne Einfluss auf den schließlich erreichten Endzustand. 

Der Störungsbegriff umfasst auch unerwünschte Situationen in konventionellen 

Rechnern, in denen ein gleichzeitiges Lesen und Schreiben, 

sowie mehrfaches gleichzeitiges Schreiben auf einer Speicherzelle auch 

technisch zu einem Konflikt führt. 

76


– Für störungsfreie Systeme gilt, dass unter Einhaltung der mit festgelegten 

Reihenfolge, die Ausführungsreihenfolge der parallelen Ereignisse und 

deren Aktionen keinen Einfluss auf die berechneten Ergebnisse hat. Die 

Bernstein-Bedingungen sind auch im Zusammenhang mit parallelisierenden 

Compilern wichtig. Parallelisierende Compiler versuchen, Anweisungen 

des zu compilierenden Programms, die keine gemeinsamen Datenobjekte 

benutzen, für eine parallele Bearbeitung vorzubereiten (z.B. Ausnutzen vieler 

Pipeliningstufen von RISC-Prozessoren). Dazu kann man die sequentiellen 

Aktionen (Anweisungen) schrittweise aus der Relation entfernen, solange 

die Bernsteinbedingung nicht verletzt wird. 

3.3.5 Petri-Netze 

Ein Prozess beschreibt einen möglichen Ablauf eines verteilten Systems. Verteilte 

Systeme besitzen viele Abläufe, d.h. ein System wird durch die Menge von 

Abläufen beschrieben. Gesucht wird deshalb ein Modell zur Beschreibung 

von Systemen und deren möglichen Abläufen. Drei Vertreter solcher 

Formalismen sind Petri-Netze (graphische Beschreibungsmethode), Agenten 

(formale Beschreibungssprache, siehe Broy Band II) und prädikatenlogische 

Formeln zur Beschreibung von Abläufen. Im folgenden werden Petri-Netze 

vorgestellt, die eine graphen-orientierte Beschreibung verteilter Systeme und 

deren Abläufen ermöglicht. 

Allgemeines 

Formalismus von C.A. Petri 1962 entwickelt. Ansatz führte zu einer Theorie zur 

Analyse und Entwicklung nebenläufiger Systeme. 

¯ informelle Charakterisierung 

Ein Petri-Netz ist gerichteter Graph mit Kanten und zweierlei Knoten. 

– Knoten: Stellen (graphisch Kreise) und Transitionen (graphisch Rechtecke) 

– Kanten: von Stellen zu Transitionen oder von Transitionen zu Stellen 

– Belegung der Stellen mit Marken/Werten (Token); 

£ In einem boolschen Netz sind als Werte nur 0 oder 1 zugelassen. 

£ In einem Stellen/Transitionsnetz sind für die Belegung der Stellen 

natürlichzahlige Werte zugelassen; die maximale Belegung definiert die 

Stellenkapazität. 

77


– Zustand: definiert durch Belegung der Stellen; 

£ Zustandsübergang durch sogenannte Schaltregeln (engl. firing rule); 

Belegung ändert sich. Man spricht in diesem Zusammenhang vom 

Schalten einer Transition. Das dynamische Verhalten eines Netzes läßt 

sich durch Schaltvorgänge beschreiben. Transitionen schalten, indem sie 

von allen Eingangsplätzen eine Marke abziehen (bei 1-wertigen Kanten) 

und auf allen Ausgangsplätzen eine Marke hinzufügen. Ein Schaltvorgang 

kann insbesondere die Gesamtzahl der Marken in einem Netz ändern. Eine 

einzelne Transition ist schaltbereit, wenn alle ihre Eingangsplätze echt 

positiv belegt sind; bei mehrwertigen Kanten müssen entsprechend viele 

Marken bei den Eingangsplätze vorhanden sein. 

– Markierung der Kanten, Kantengewichte: Gewichtung gibt an, wieviele 

Marken beim Schalten einer Transition von den Eingangsknoten (Stellen) 

der Transition abgezogen und den Ausgangsknoten (Stellen) der Transition 

hinzugefügt werden. 

¯ Beispiel eines Petri-Netzes 

grobe Modellierung einer Materialverwaltung. 

Bestellung 

Bestellaufnahme 

Produktionsauftrag 

Lieferauftrag 

Produktion 

Auslieferung 

Lager 

Waren 

Bestellungen kommen zur Bestellaufnahme, die Lieferaufträge an die 

Auslieferung erteilt. Diese bedient sich aus einem Lager und liefert 

Ware aus. Um das Lager aufzufüllen, müssen Produktionsaufträge an die 

Produktion erteilt werden. Aus der graphischen Darstellung ist ersichtlich, 

dass Transitionen Tätigkeiten repräsentieren, während Stellen eher Zustände 

darstellen. Marken, die Stellen zugeordnet sind und einen dynamischen Ablauf 

ermöglichen, werden erst weiter unten eingeführt. 

78


Definition: Petri-Netz 

Ein Petri-Netz ist ein Tripel (S, T, F) mit 

S ist eine endliche Menge von Stellen (engl. place) 

T ist eine endliche Menge von Transitionen (engl. transition) und es gilt: S 

T = Ø d.h. Stellen und Transitionen sind disjunkt. 

F ist die Flussrelation mit F (S ¢ T) (T ¢ S) 

Für einen Knoten x (S T) gilt: 

¡x = {y | y F x} den Vorbereich von x 

x¡ = {y | x F y} den Nachbereich von x 

x kann dabei eine Stelle oder eine Transition sein. 

¯ Mit obiger Definition ist die statische Struktur eines Netzes formal erfasst. Die 

graphische Darstellung wurde bereits anhand des obigen Beispiel gezeigt. 

¯ Für das Beispiel Materialverwaltung gilt beispielsweise: 

¡Bestellaufnahme = {Bestellung} 

Bestellaufnahme¡ = {Produktionsauftrag, Lieferauftrag} 

¯ Verfeinerung 

Netzstrukturen können schrittweise verfeinert, konkretisiert werden. Wichtig: 

Globale Struktur muss bei Verfeinerung erhalten bleiben, d.h. alle Kanten in 

eine verfeinerte Transition und alle Kanten aus dieser verfeinerten Transition 

bleiben erhalten. Die innere Struktur der Transition kann wiederum in 

Stellen, Transitionen und Kanten aufgeschlüsselt werden. Die zu verfeinernde 

Transition kann nach außen hin als Blackbox gesehen werden. 

– Beispiel 

Verfeinerung der Materialverwaltung: z.B. der Komponente Auslieferung. 

Anhand des Lieferauftrages wird der Lieferschein geschrieben, der zusammen 

mit dem Produkt verpackt und versandt wird. 

79


Lieferauftrag 

Lager 

Lieferscheinerstellung 

Lieferschein 

Verpacken 

Auslieferung 

Versenden 

verpackte 

Produkte 

Auslieferung ist nach außen hin eine Transition. 

Markierung und Schaltregeln 

Waren 

Zur Erfassung des dynamischen Verhaltens erweitern wir die Definition eines 

Petri-Netzes zunächst um Markierungen und geben dann die Schaltregeln an. 

¯ Markierung 

Gegeben sei ein Petri-Netz (S, T, F). 

– Eine Abbildung c: S IN { } gibt die Kapazität einer Stelle an. Wenn 

in den von uns verwendeten Netzen die Stellen nicht explizit markiert sind, 

dann bedeutet dies eine unbeschränkte Kapazität. 

– Eine Abbildung w: F IN {0} gibt die Gewichtung einer Kante an. Wenn 

in den von uns verwendeten Netzen die Kanten nicht explizit markiert sind, 

dann bedeutet dies eine implizite Gewichtung mit dem Gewicht 1. 

– Eine Abbildung M: S IN heißt natürlichzahlige Markierung der Stellen. 

Die Markierung beschreibt einen Zustand des Netzes. 

Es muss gelten: s S: M(s) c(s) 

Ein solches Netz heißt Stellen-Transitionsnetz 

– Falls gilt M: S IB, dann heißt das Netz: Bedingungs/Ereignisnetz 

oder Boolesches Netz. Demnach entsprechen Boolsche Petri-Netze 

natürlichzahligen Petri-Netzen, bei denen jede Stelle die Kapazität 1 hat 

(oder einen boolschen Wert mit true (=1) bzw. false (=0) hat). Eine Transition 

80


t kann nur dann schalten, wenn alle Stellen, zu denen Kanten von t aus führen, 

mit false markiert sind. 

¯ Schaltregeln 

Das Verhalten eines Netzes wird durch Schaltvorgänge beschrieben. Gegeben 

sei ein Petri-Netz (S, T, F), die Funktionen c, w und eine Anfangsmarkierung 

M0. 

– Ein Zustandsübergang erfolgt durch das Schalten von Transitionen, wobei 

gilt: Eine Transition t T kann schalten (ist transitionsbereit), wenn folgende 

Bedingungen erfüllt sind: 

Für alle s ¡tgilt: M(s) w((s,t)) 

Für alle s t¡ gilt: M(s) c(s) - w((t,s)) 

w(s,t) spezifiziert die für die Kante s t erforderliche Marken. Der zweite 

Fall bedeutet, dass vor Schalten der Transition die aktuelle Markierung der 

Stelle kleiner oder gleich als die Kapazität der Stelle minus der zugehörigen 

Kantengewichtung ist. 

– Durch das Schalten von t wird eine Folgemarkierung M' zu M erzeugt, mit 

Für alle s ¡t\t¡ gilt: M'(s) = M(s) - w((s,t)) 

Für alle s t¡ \ ¡t gilt: M'(s) = M(s) + w((t,s)) 

Für alle s (¡t t¡) gilt: M'(s) = M(s) - w((s,t)) + w((t,s)) 

Sonst: M'(s) = M(s) 

– Das Modell trifft keine Festlegungen über die Schaltdauer einer Transition, 

man geht davon aus, dass das Schalten keine Zeit erfordert. Die Definition 

besagt, dass eine Transition nur schalten kann, wenn in ihren Eingangsstellen 

mindestens soviele Marken liegen, wie die Gewichtung der jeweiligen 

Kanten angibt und wenn außerdem gewährleistet ist, dass durch das Schalten 

die Kapazität ihrer Ausgangstellen nicht überschritten wird. Durch das 

Schalten werden entsprechend der Kantengewichtung Marken von allen 

Eingangstellen abgezogen und ebenfalls entsprechend der Gewichtung 

Marken den Ausgangstellen hinzugefügt. 

– Beispiel: Schalten einer Transition 

Gegeben sei eine Kantengewichtungsfunktion w, die jede Kante mit 1 

gewichtet, also 

w: F 1 

81


vor dem Schalten nach dem Schalten 

– Beispiel: Schalten mit Kantengewicht 

2 

3 

vor dem Schalten nach dem Schalten 

– Beispiel: nichtschaltbare Transition 

In der linken Situation enthält die Stelle s2 zu wenige Tokens, da gemäß 

der Kantenmarkierung bei jedem Schalten der Transition t1 zwei Marken 

von der Stelle s2 konsumiert werden. In der rechten Situation liegt dagegen 

ein Markenüberfluss vor. Die Transition t1 kann nicht schalten, da auf 

der Stelle s4 bereits ein Token liegt und damit die Kapazität der Stelle (1) 

bereits erschöpft ist. Durch ein Schalten würde ein weiteres Token der Stelle 

hinzugefügt werden und die Kapazität überschreiten. 

s1 

s2 

t1 s3 s1 

t1 

s4 

s2 

2 2 

Markenmangel Markenüberfluss bei s4 

82 

2 

3 

s3 

s4 

Kapazität 1


Animation Petrinetz 


Nebenläufigkeit 

Mit Petri-Netzen lassen sich nebenläufige Systeme auf einfache Weise modellieren. 

Betrachten wir zum Beispiel vier Aktivitäten t1, ... , t4, wobei jede Aktivität 

durch eine Transition modelliert wird. Nach Beendigung von t1 (z.B. Einlesen 

von Eingabewerten) können t2 (z.B. Berechne ggt) und t3 (z.B. Berechne Fibonacci) 

nebenläufig aktiv sein, aber sie müssen beide beendet sein, bevor t4 ausgeführt 

wird. 

t1 

t2 

t3 

¯ Nichtdeterminismus 

Bei einer gegebenen Markierung M können Konflikte hinsichtlich der 

Schaltbereitschaft von Transitionen auftreten. Zwei Transitionen t1 und t2 sind 

im Konflikt, wenn sie gemeinsame Eingangs- und Ausgangsstellen besitzen, die 

so markiert sind, dass nur eine von beidem Transitionen schalten kann. Es 

erfolgt eine nichtdeterministische Auswahl. 

– Beispiel 

Erzeuger/Verbraucher mit Konfliktbelegung. Nach dem nebenläufigen 

Schalten der Transitionen a und b des Netzes (siehe Situation oben) ergibt 

sich eine Konfliktbelegung (siehe Situation unten), in der nur entweder die 

Transition c oder die Transition d schalten kann. 

83 

t4


a c e d b 

Erzeuger Verbraucher 

a c e d b 

Eigenschaften von Netzen 

nebenläufiges 

Schalten 

Konflikt 

belegung 

bzgl c und d 

Für ein gegebenes Petri-Netz, das das Verhalten eines verteilten Systems 

modelliert, sind wir daran interessiert, zu klären, ob das System bei gegebener 

Anfangsmarkierung bestimmte Eigenschaften besitzt. Eigenschaften sind die 

Erreichbarkeit und die Lebendigkeit. 

¯ Erreichbarkeit 

Häufig ist man an der Frage interessiert, ob das Netz ausgehend von einer 

Markierung M irgendwann eine Folgemarkierung M' erreicht. Das ist die Frage 

der Erreichbarkeit von Zuständen. 

– Erreichbare Markierung 

Gegeben sei ein Petri-Netz (S, T, F) mit der Markierung M. Eine endliche 

Sequenz = t1, t2, ..., tn mit t T heißt von M aktivierte endliche 

i 

Schaltfolge, wenn Markierungen M1, M2, ..., Mn existieren mit 

t1 

M M1 

t2 

M2 

tn 

Mn 

ρ 

d.h. M Mn 

£ M' ist von M erreichbar, wenn es eine Sequenz gibt, die von M 

in den Endzustand M' führt. Um die erreichbaren Markierungen eines 

Netzes zu erfassen, modelliert man das Netz als einen Zustandsautomat, 

84


der üblicherweise als Graph dargestellt wird (Erreichbarkeitsgraph). Die 

Knoten des Graphen sind die erreichbaren Markierungen und die Kanten 

sind mit Transitionen beschriftet. 

– Beispiel: Bahnnetz 

Vier Städte sind durch Bahngleise, die nur in einer Richtung befahrbar sind, 

im Kreis verbunden. Zwei Züge fahren auf der Strecke. 

Aufgabe: Das System ist so zu konstruieren, dass sich niemals beide Züge 

auf derselben Strecke befinden. 

Lösung: Die Strecken werden mit Stellen s1, ... , s4 modelliert. Eine 

Marke auf der Stelle s bedeutet, dass ein Zug auf der i-ten Strecke fährt. 

i 

Durch die zusätzlichen Kontrollstellen k1, .. , k4 soll garantiert werden, 

dass in keiner erreichbaren Markierung mehr als eine Marke auf einer der 

Stellen s liegt. k kontrolliert den Zugang zur Strecke s (Stelle). 

i i i 

t3 

t4 

t3 

s4 k4 

s1 

s3 

k1, s2, k3, s4 

k1 

k3 

t2 t4 

k2 

k1, k2, s3, s4 s1, s2, k3, k4 

t4 

s1, k2, s3, k4 

k1, s2, s3, k4 s1, k2, k3, s4 

t2 

t1 t3 

t1 

t1 

t2 

s2 

Bahnnetz 

Erreichbarkeitsgraph 

Die Zustände werden durch die Menge der markierten Stellen in einer 

erreichbaren Markierung beschrieben. Der Erreichbarkeitsgraph zeigt, dass 

kein Zustand ereichbar ist, in dem mehr als eine Marke, also mehr als ein 

Zug, auf einer Stelle s i liegt. Damit ist die gewünschte Eigenschaft korrekt 

85


modelliert. Die Frage, ob es einen Algorithmus gibt, der entscheidet, ob 

eine Markierung aus einer gegebenen Anfangsmarkierung aus erreichbar 

ist oder nicht, (Entscheidbarkeit des Erreichbarkeitsproblems), war ca. 10 

Jahre lang offen. Prof. E.W. Mayr hat die Entscheidbarkeit 1980 in seiner 

Dissertation (an der TUM) bewiesen. Aber: der Algorithmus besitzt sehr 

hohe Komplexität, er ist nicht effizient durchführbar. 

¯ Lebendigkeitseigenschaften 

Wie zu Beginn des Kapitels bereits erwähnt, verwendet man Systemmodelle 

häufig, um Lebendigkeitseigenschaften zu analysieren. Stellen- 

Transitionsnetze werden oft in Bereichen verwendet, in denen es auf die Anzahl 

und die Verteilung veränderlicher Objekte ankommt. (z.B. Daten in einem 

Rechner, Waren in einem Lager, Werkstücke). Man ist daran interessiert zu 

erkennen, ob es in einem System zu Blockierungen kommen kann, so dass Teile 

des Systems blockiert sind oder der gesamte Ablauf zum Stillstand kommt. Ursachen 

für solche Situationen sind Mangel oder Stau, der durch die veränderlichen 

Objekte ausgelöst wird. 

– Netzdarstellung 

aktive Systemelemente als Transitionen (Prozessor, Maschine, etc.) 

passive Systemteile als Stellen (Speicher, Lager, etc.) 

veränderliche Objekte als Marken 

Für Lebendigkeitsuntersuchungen sind Netzteile interessant, die niemals 

markiert werden oder die niemals ihre Marken verlieren. 

– Definition 

Gegeben sei ein Petri-Netz (S, T, F) mit der Anfangsmarkierung M0. 

£ Das Netz heißt lebendig, wenn für jede erreichbare Markierung M und für 

jede Transition t T eine Markierung M' existiert, die aus M erreichbar ist 

und in der t transitionsbereit ist. Informell: jede Transition t kann immer 

wieder schalten. 

£ Die von M0 aus erreichbare Markierung M beschreibt eine vollständige 

Verklemmung (eng. deadlock), wenn es keine Transition t T gibt, die 

unter M schalten kann. 

£ Die von M0 aus erreichbare Markierung M beschreibt eine lokale 

Verklemmung, wenn es eine Transition t T gibt, so dass ausgehend von 

M keine Folgemarkierung M' erreichbar ist, in der t transitionsbereit ist. 

£ Ist (S, T, F) mit Anfangsmarkierung M0 lebendig, dann ist es auch 

verklemmungsfrei. Lebendige Netze stellen sicher, dass es weder zu 

einem Markenmangel noch zu einem Überfluss kommt. Die Eigenschaft 

86


der Lebendigkeit eines Netzes ist insbesondere für Systeme, die für einen 

Endlosbetrieb ausgelegt sind (z.B. Betriebssysteme) wichtig. 

– Beispiel: Lebendiges Netz 

Aufgabe: Modellierung eines FIFO-Puffers mit Kapazität 3. Und zwar so, 

dass er verklemmungsfrei und lebendig ist. 

Lösung: Das System besteht aus 3 Zellen, die jeweils eine Nachricht 

aufnehmen können die Stellen repräsentieren die Speicherzellen). Die 

Transition t1 modelliert das Eingeben einer neuen Nachricht und die 

Transition t4 modelliert die Ausgabe der Nachricht. Mit den Transitionen 

t werden die Nachrichten von Zelle s zur Zelle s weitergereicht. 

i i-1 i 

Voraussetzung ist, dass die entsprechende Zelle leer ist. Der Zustand "Zelle 

s ist leer", wird durch die markierte Stelle k modelliert. 

i i 

Das modellierte Netz ist verklemmungsfrei und lebendig. Falls der FIFO 

Puffer in ein größeres System eingebunden ist, müssen die Transition t1 (für 

die Eingabe von Nachrichten) und t4 (für die Ausgabe von Nachrichten) in 

das Gesamtsystem integriert werden. 

t1 t2 t3 t4 

Eingabe einer 

Nachricht 

k1 k2 k3 

s1 s2 s3 

Ausgabe einer 

Nachricht 

– Beispiel: Verklemmung 

2 Studenten benötigen ein 2-bändiges Lehrbuch. Student 1 leiht sich 

zunächst nur Band 1 aus und Student 2 leiht sich vorsorglich den noch 

vorhandenen Band 2 aus. Bevor Student 1 seinen ersten Band zurückgibt, 

möchte er noch den zweiten ausleihen. Auch Student 2 gibt seinen 

ausgeliehenen Band nicht zurück, sondern versucht, den ersten Band 

auszuleihen. 

£ Vor der Ausleihe 

Anfangszustand des Netzes vor der Ausleihe. Die nachfolgende 

Abbildung zeigt zunächst das Netz, bevor einer der Studenten ein Buch 

ausleiht und die zweite Abbildung zeigt das Netz, nachdem die Studenten 

die jeweiligen Bände ausgeliehen haben. 

87


Student 1 Band1 Band 2 Student 2 

Band 1 

ausleihen 

Band 2 

ausleihen 

beide Bände 

zurückgeben 

Band 2 

ausleihen 

Band 1 

ausleihen 

beide Bände 

zurückgeben 

£ Nach der Ausleihe 

Zustand des Netzes nach dem Schalten Transitionen, d.h. nach der 

Ausleihe. Diese Abbildung zeigt, dass das Netz verklemmt ist; es 

gibt keinen Systemfortschritt mehr. Was ist das Problem unseres 

Modells? Bei Student 1 und Student 2 haben die Ausleihe der Bänder 

unterschiedliche Reihenfolgen; bei gleicher Reihenfolge der Ausleihe tritt 

keine Verklemmung ein. 

88

Schlichter, TU München 3.4. THREAD-KONZEPT 

Student 1 Band1 Band 2 Student 2 

Band 1 

ausleihen 

Band 2 

ausleihen 

beide Bände 

zurückgeben 

¯ Weitere interessante Eigenschaften: nur ganz informell: 

Band 2 

ausleihen 

Band 1 

ausleihen 

beide Bände 

zurückgeben 

– Fairness 

Gegeben sei ein Netz N mit Anfangsmarkierung M. Das Netz ist unfair für 

eine Transition t, wenn es eine unendliche Sequenz gibt, in der t nur endlich 

oft auftritt, obwohl t unendlich oft transitionsbereit ist. 

– Verhungern 

t verhungert (engl. Starvation): Es gibt eine unendliche Sequenz, in 

der die Transition t niemals auftritt. Falls unfaire Sequenz: trotz 

Transitionsbereitschaft von t. 

3.4 Thread-Konzept 

Threads sind ein BS-Konzept für die Modellierung und Realisierung von 

nebenläufigen Aktionen in einem Rechensystem. Threads (Kontrollflüsse) 

beschreiben die Aktivitäten in einem Rechensystem. Sie können als virtuelle 

Prozessoren aufgefasst werden, die jeweils für die Ausführung eines zugeordneten 

Programms in einem Adressraum verantwortlich sind. Threads konkurrieren um 

die physische CPU, um ablaufen zu können. In traditionellen Umgebungen hat 

89


jeder Prozess genau einen Thread, der den Kontrollfluss des Prozess repräsentiert, 

während in Multithreaded-Umgebungen ein Prozess mehrere Threads besitzen 

kann. 

Prozess 

Thread 


3.4.1 Charakterisierung von Threads 

Thread 

Benutzer 

Adressraum 

Aus BS-Sicht ist ein Prozess definiert 

durch einen Adressraum 

eine darin gespeicherte Handlungsvorschrift in Form eines sequentiellen 

Programms 

einen oder mehreren Aktivitätsträgern, die dynamisch die 

Handlungsvorschrift ausführen Threads 

Motivation 

Ein Thread ist die Abstraktion eines physischen Prozessors; er ist ein Träger einer 

sequentiellen Aktivität. Gründe für die Einführung von Threads: 

¯ mehrere Threads ermöglichen Parallelität innerhalb eines Prozesses unter 

Nutzung des gemeinsamen Adressraums. Durch die Nutzung des gemeinsamen 

Adressraums wird die Interaktion zwischen den Threads (Kommunikation und 

gemeinsame Nutzung von Daten) erleichtert. Jeder Thread für sich gesehen 

repräsentiert ein streng sequentielles Verarbeitungsmodell. 

¯ Aufwand für Erzeugen und Löschen von Threads ist geringer als für Prozesse. 

Threads führen nicht so einen großen Ballast an Information mit sich als 

Prozesse. Beispielsweise muss bei der Erzeugung eines Prozesses durch 

das BS ein neuer Adressraum generiert werden; Threads laufen im bereits 

vorhandenen Adressraum ab. Deshalb spricht man bei Threads auch von 

90


Leichtgewichtsprozesse ("light weight processes"), da sie erheblich weniger 

Verwaltungsinformation als normale Prozesse ("heavy weight processes") 

benötigen. 

¯ Verbesserung der Performanz der Applikationsausführung durch Nutzung 

mehrerer Threads. Dieses Argument ist besonders dann von Bedeutung, wenn 

die Applikation (und damit der zugehörige Prozess) sowohl CPU- als auch E/Aintensive 

Aktivitäten beinhaltet. E/A-Wartezeiten innerhalb einer Applikation 

können durch andere rechenbereite Threads der Applikation genutzt werden. 

Dagegen gewinnen CPU-dominierte Applikationen durch die Parallelisierung 

mittels Threads weniger an Performanz (falls nur eine CPU zur Verfügung 

steht). 

¯ Threads ermöglichen bei einem Multiprozessor-Rechensystem echte Parallelität 

innerhalb einer Applikation. 

Prozess vs. Thread 

Prozesse und Threads haben unterschiedliche Zielsetzungen: 

Prozesse gruppieren Ressourcen, 

Threads sind Aktivitätsträger, die zur Ausführung einer CPU zugeteilt 

werden. 

¯ Threadspezifische Information 

Jeder Thread umfasst eine Reihe von Informationen, die seinen aktuellen 

Zustand charakterisieren: 

Befehlszähler, aktuelle Registerwerte, Keller, Ablaufzustand des Thread. 

Ebenso wie ein Prozess befindet sich ein Thread in einem der nachfolgenden 

Zustände: rechenwillig, rechnend, wartend, terminiert. Entsprechend den 

ausgeführten Aktionen (z.B. Ein-/Ausgabe) und der Zuteilung bzw. des 

Entzugs der CPU finden Zustandsübergänge statt. Jeder Thread hat seinen 

eigenen Keller, in dem die Unterprogrammaufrufe verwaltet werden. Jeder 

Thread hat seinen eigenen Satz an Registern (darunter auch den Befehlszähler), 

die gerettet werden müssen, falls einem Thread die CPU entzogen wird. Bei 

einer CPU-Zuteilung werden die geretteten Registerwerte des Threads in die 

jeweiligen Register geladen. 

¯ Prozessspezifische Information 

Die nachfolgende Information/Ressourcen wird von allen Threads eines 

Prozesses geteilt. Jeder Thread kann sie verwenden bzw. darauf zugreifen. 

91


Adressraum, globale Variable, offene Dateien, Kindprozesse (z.B. erzeugt 

mit fork), eingetroffene Alarme bzw. Interrupts. 

Dies sind Eigenschaften des Prozesses und nicht eines einzelnen Threads. 

Beispielsweise, wenn ein Thread eine Datei öffnet, dann ist diese Datei auch 

für die anderen Threads sichtbar, und sie können in sie schreiben bzw. aus ihr 

lesen. Diese Information ist i.a. zwischen Prozessen nicht sichtbar, außer dass 

vom Vaterprozess an den Kindprozess Dateideskriptoren vererbt werden. 

Beispiel: Web-Server 

Ein Prozess kann mehrere Threads umfassen, die unterschiedliche Aufgaben 

übernehmen. Beispielsweise kann ein Web-Server einen Verteiler-Thread 

("dispatcher") und mehrere Server-Threads ("worker-thread") umfassen. 

Anforderung 

Verteiler- 

Thread 

Netzwerk-Verbindung 

Web-Serverprozess 


Server- 

Thread 

Benutzer 

Adressraum 

Auf diese Weise ist es möglich den Server als eine Menge von sequentiellen 

Threads zu realisieren. Der Verteiler-Thread ist eine unendliche Schleife, die die 

Schnittstelle für den Eingang von Service-Anforderungen darstellt. 

¯ Der Verteiler-Thread dient zur Annahme von Service-Anforderungen und gibt 

sie weiter an einen der Server-Threads zur Bearbeitung. Server-Threads 

können bei Eintreffen einer Service-Anforderung jeweils dynamisch erzeugt 

werden, und nach Erledigung der Anforderung bzw. nach Zustellung der 

Antwort terminiert werden. Zur Verbesserung der Antwortzeiten kann der 

Web-Server bereits einen Pool von Server-Threads erzeugen, denen jeweils 

dynamisch Anforderungen zugeteilt werden können. Server-Threads werden 

nach Bearbeitung einer Anforderung nicht beendet, sondern wieder in den Pool 

92


der freien Server-Threads eingereiht. Bei Bedarf können zusätzliche Server- 

Threads erzeugt werden, falls alle Server-Threads aus dem Pool bereits belegt 

sind. 

¯ Alle Server-Threads nutzen den gemeinsamen Web-Cache. 

3.4.2 Threads in Java 

Java unterstützt die Programmierung mit Threads, um nebenläufige Abläufe 

innerhalb einer Applikation zu ermöglichen. Java Threads können sowohl in Java- 

Programmen als auch in Java-Applets verwendet werden. Die Implementierung 

der Java Virtual Machine selbst beruht auf Threads: Der Java-Müllsammler 

(Garbage collector) ist z.B. ein Thread zum Sammeln von nicht länger 

referenzierten Objekten, der nebenläufig zum Java Programm abläuft. Hier 

erfolgt nur eine sehr kurze Wiederholung einiger der Aspekte, die bereits in der 

Informatik-Einführungsvorlesung behandelt wurden. 

Definition 

Threads können durch Implementierung der Schnittstelle ÊÙÒÒÐ realisiert 

werden. Eine weitere Möglichkeit besteht durch SubClassing der Klasse Thread 

selbst, d.h. 

ÔÙÐ Ð×× ÊØÙÖÒ×Ø ÜØÒ× ÌÖ ß 

¯ Thread Implementierungen überschreiben die run-Methode der Schnittstelle 

Runnable. 

ÔÙÐ Ð×× ÐÐ ×Ø ÑÔÐÑÒØ× ÊÙÒÒÐ ß 

 

ÔÙÐ ÚÓ ÖÙÒ ß 

¯ Thread Instanzen werden durch den Aufruf der start-Methode der Schnittstelle 

Runnable gestartet. Diese Methode sollte durch eine Thread-Implementierung 

nicht verändert werden. Die start-Methode ruft die run-Methode auf, wodurch 

die Instanz der Thread-Implementierung ausgeführt wird. 

ÔÙÐ ×ØØ ÚÓ ÑÒ ËØÖÒ℄ Ö× ß 

 

ÐÐ ×Ø ÒÛ ÐÐ ×Ø 

ÌÖ Ø ÒÛ ÌÖ 

Ø ×ØÖØ 

93


Ergebnisrückgabe 

Der Ablauf der Threads ist asynchron, d.h. die Ausführungsreihenfolge einer 

Menge von Threads ist nicht fest vordefiniert. Dies ist insbesondere bei 

kooperierenden Threads von Bedeutung, z.B. bei der Ergebnisrückgabe eines 

Thread an einen anderen Thread. Die Ausführungsreihenfolge ergibt sich 

durch die CPU-Zuteilung (Scheduling) durch das Betriebssystem oder das 

Laufzeitsystem. Dies bedeutet, dass bei der Kommunikation zwischen Threads 

nicht von einem bestimmten Zeitverhalten der Threads ausgegangen werden kann, 

d.h. wann welche Threads ausgeführt werden. 

¯ Direkter Ansatz 

Angenommen jeder Thread liest eine Datei und erzeugt daraus die zugehörige 

Hash-Information (z.B. verwendet für verschlüsselte Datenübertragung). 

ÔÙÐ Ð×× ÊØÙÖÒ×Ø ÑÔÐÑÒØ× ÊÙÒÒÐ ß 

ÔÖÚØ Ð ÒÔÙØ 

ÔÖÚØ ÝØ℄ ×Ø 

ÔÙÐ ÊØÙÖÒ×Ø Ð ÒÔÙØ ß Ø× ÒÔÙØ ÒÔÙØ 

ÔÙÐ ÚÓ ÖÙÒ ß 

 

×Ø 

 

ÔÙÐ ÝØ℄ Ø×Ø ß ÖØÙÖÒ ×Ø 

ÔÙÐ Ð×× ÊØÙÖÒ×ØÍ×ÖÁÒØÖ ß 

 


 

ÓÖ ÒØ Ö× ÐÒØ ß 

Ð ÒÛ Ð Ö×℄ 

ÊØÙÖÒ×Ø Ö ÒÛ ÊØÙÖÒ×Ø 

ÌÖ Ø ÒÛ ÌÖ Ö Ø ×ØÖØ 

 

ÝØ℄ ×Ø Ö Ø×Ø 

Jeder Thread speichert das Ergebnis der Dateibearbeitung in der Variablen 

digest, auf die über die Methode getDigest zugegriffen werden kann. 

94


– Die Ausführung führt zu dem Fehler 

Ü ÔØÓÒ Ò ØÖ ÑÒ Ú ÐÒ ÆÙÐÐÈÓÒØÖÜ ÔØÓÒ 

Ø ÊØÙÖÒ×ØÍ×ÖÁÒØÖ ÑÒ 

Die Variable digest wird vor der Thread-Initalisierung benutzt. Dies liegt 

daran, dass das Hauptprogramm nach der Erzeugung des Thread Zugriff 

auf die Variable digest erhält, ohne dass der Thread die Möglichkeit der 

Intialisierung bzw. zur Berechnung des Wertes für ×Ø erhielt. In einer 

single-threaded Umgebung würde dieses Programm korrekt ablaufen, da 

nach Ø ×ØÖØ sofort der entsprechende Thread ausgeführt wird. In einer 

multi-threaded Umgebung laufen die Threads dagegen asynchron ab, d.h. 

die CPU-Zuteilung hängt vom Laufzeitsystem (bzw. Betriebssystem ab). 

Man könnte nun den main-Thread künstlich verzögern, jedoch es besteht 

eine "Race-Condition" zwischen den kooperierenden Threads und man kann 

keine Aussage über die Java Virtual Machine machen, wann welcher Thread 

rechnend gesetzt wird. 

¯ Callback Ansatz 

Nicht das main-Programm holt die Ergebnisse ab, sondern die aufgerufenen 

Threads rufen jeweils eine Methode des main-Programms auf, um die 

Ergebnisse zu übergeben Callback 

ÔÙÐ Ð×× ÐÐ ×Ø ÑÔÐÑÒØ× ÊÙÒÒÐ ß 

ÔÖÚØ Ð ÒÔÙØ 

ÔÙÐ ÐÐ ×Ø Ð ÒÔÙØ ß Ø× ÒÔÙØ ÒÔÙØ 

ÔÙÐ ÚÓ ÖÙÒ ß 

 

ÝØ℄ ×Ø 

ÐÐ ×ØÍ×ÖÁÒØÖ Ö Ú×Ø ×Ø 

 

ÔÙÐ ÝØ℄ Ø×Ø ß ÖØÙÖÒ ×Ø 

ÔÙÐ Ð×× ÐÐ ×ØÍ×ÖÁÒØÖ ß 

95

Schlichter, TU München 3.5. SYNCHRONISATION 

 

ÔÙÐ ×ØØ ÚÓ Ö Ú×Ø ÝØ℄ ×Ø ß 

 


 

ÓÖ ÒØ Ö× ÐÒØ ß 

Ð ÒÛ Ð Ö×℄ 

ÊØÙÖÒ×Ø Ö ÒÛ ÊØÙÖÒ×Ø 

ÌÖ Ø ÒÛ ÌÖ Ö Ø ×ØÖØ 

 

Im Gegensatz zum main-Programm des direkten Ansatzes dient das main- 

Programm dieses Ansatzes nur zum Starten der verschiedenen Threads. Es 

versucht nicht die Berechnungen der getriggerten Threads direkt zu lesen und 

zu verarbeiten. Dies wird durch separate Methode Ö Ú×Ø erledigt. 

3.5 Synchronisation 

Eine wichtige Systemeigenschaft 

betrifft die Synchronisation paralleler Ereignisse, z.B. In einem 

Rechensystem konkurrieren parallele Aktivitäten um wiederholt exklusiv (d.h. zu 

einem Zeitpunkt darf höchstens eine Aktivität die Ressource nutzen) benutzbare 

Ressourcen, wie beispielsweise die CPU, den Drucker etc. Zusätzlich dazu können 

aber parallele Aktivitäten auch kooperieren, indem sie Daten über gemeinsam 

benutzte exklusive Objekte austauschen oder sich Nachrichten zusenden. In 

all diesen Fällen haben wir das Problem, den wechselseitigen Ausschluss (engl. 

mutual exclusion) zu gewährleisten, d.h. sicherzustellen, dass nur höchstens ein 

Prozess zu einem gegebenen Zeitpunkt eine exklusiv benutzbare Ressource belegt. 

3.5.1 Beispiele 

Die beiden Beispiele basieren auf der speicherbasierten Prozessinteraktion, 

d.h. Prozesse (oder auch Threads) interagieren über gemeinsam zugreifbare 

Speicherzellen. 

96


Beispiel: gemeinsame Daten 

P1 und P2 sind nebenläufige Prozesse, die in einem Multiprozessorsystem (z.B. 

MI) parallel ablaufen. Die Variable x ist gemeinsame Variable. Prozess P1 läuft 

auf CPU 0 mit Prozess P2 auf CPU 1 gleichzeitig ab. Das Problem ergibt sich auch 

bei quasiparallelem Ablauf (zeitliche Verschränkung der Arbeit der Prozesse). Z 

sei ein Zeitpunkt nach Ausführung der Aktionen A und B. Welchen Wert hat x 

zum Zeitpunkt Z? 

Das Ergebnis des Ablaufs kann je nach zeitlichem Ablauf x = 1, 2, 3 sein. 

Der grundlegende Nichtdeterminismus der Nebenläufigkeit wegen der Asynchronität 

schlägt hier auf die Ergebnisse der Prozesse durch. 

Zeitpunkt Z 

int x; x = 0 

Prozess P1 Prozess P2 

A: x = x + 1 

B: x = x + 2 

¯ Das Ergebnis ist vom zeitlichen Ablauf abhängig. Es sind folgende Fälle 

möglich: 

– Fall 1 

P1 liest x = 0, erhöht, speichert x = 1; 

P2 liest x = 1, erhöht, speichert x = 3; = Wert von x = 3 

– Fall 2 

P2 liest x = 0, erhöht, speichert x = 2; 

P1 liest x = 2, erhöht, speichert x = 3; = Wert von x = 3 

– Fall 3 

P1 und P2 lesen x = 0; 

P1 erhöht, speichert x = 1; 

P2 erhöht, speichert x = 2; = Wert von x = 2 

97


– Fall 4 

P1 und P2 lesen x = 0; 

P2 erhöht, speichert x = 2; 

P1 erhöht, speichert x = 1; = Wert von x = 1 

¯ Verhinderung des Nichtdeterminismus nur dadurch möglich, dass man 

garantiert, dass die Veränderung von x in den beiden Prozessen unter wechselseitigem 

Ausschluss (engl. mutual exclusion) erfolgt. Die Asynchronität der 

Prozesse muss also genau an dieser Stelle eingeschränkt werden. 

Erzeuger-Verbraucher-Problem 

Ein Beispiel für einen synchronisierten Zugriff auf eine gemeinsame Ressource, 

nämlich einen Puffer, haben wir bereits kennengelernt. Interpretiert man das 

bereits angesprochene Petri-Netz (siehe Seite 83) als eine Komposition aus 

drei Teilen: 

einem Erzeuger von Nachrichten (links), 

einem Puffer für Nachrichten (Mitte) und 

einem Verbraucher von Nachrichten (rechts). 

So kann man sehen, dass durch diese Modellierung gewährleistet wird, dass 

Erzeuger und Verbraucher nicht gleichzeitig etwas in den Puffer eintragen und 

aus ihm entnehmen können; sie greifen wechselseitig ausgeschlossen zu. 

3.5.2 Definition: Wechselseitiger Ausschluss 

Gegeben sei ein Petri-Netz (S, T, F) und eine Anfangsmarkierung M0. Wenn 

zwei Transitionen t1, t2 T wechselseitig ausgeschlossen sind, dann ist keine 

Markierung M' erreichbar, so dass t1 und t2 unter dieser Markierung gleichzeitig 

transaktionsbereit sind. Wir sagen, dass Transitionen, die wechselseitig 

ausgeschlossen auszuführen sind, kritische Abschnitte (engl critical section, 

critical region) eines Systemablaufs modellieren. 

¯ Beispiel: gemeinsame Daten 

Der Zugriff auf gemeinsame Ressourcen, z.B. auf gemeinsame Variable, 

muss koordiniert werden. Bei exklusiven Ressourcen wird die Nutzung 

sequentialisiert. Die gemeinsame Ressource wird in einem kritischen Bereich 

bzgl. der gemeinsamen Ressource benutzt. 

98


3.5.3 Modellierung 

Prozess P1: 

main () { 

....... 

region x do 

x = x + 1: 

end region 

........ 

} 

Prozess P2: 

main () { 

....... 

region x do 

x = x + 2: 

end region 

........ 

} 

Modelliert man parallele Einheiten, die kritische Abschnitte besitzen, durch Petri- 

Netze, so sind vier Phasen dieser parallelen Aktivitäten von Interesse: 

1. Ausführen unkritischer Abschnitte/Transaktionen 

2. Betreten eines kritischen Abschnitts 

3. Ausführen der Transaktion(en) des kritischen Abschnitts 

4. Verlassen des kritischen Abschnitts. 

Modellierung jeder Phase durch eine Transition; Koordinierung des wechselseitigen 

Ausschluss durch Kontrollstelle s. 

t1 

Prozess 1 

t2 

t3 

t4 

Eintritt 

k.A. 

s 

Eintritt 

Austritt Austritt 

Prozess 2 

t1: Phase 1; unkritische Transition 

t2: Phase 2; Eintritt in kritischen Abschnitt 

t3: Phase 3; Ausführung des kritischen 

Abschnitts 

t4: Phase 4; Verlassen des kritischen 

Abschnitts 

s: Kontrollstelle 

¯ Beispiel: Leser-Schreiber-Problem 

Betrachten wir als Beispiel ein weiteres klassisches Synchronisationsproblem: 

das Leser-Schreiber-Problem. Eine einfache Version des Leser-Schreiber- 

Problems ist wie folgt gegeben. Das System umfasst Lese-Aktivitäten, die in 

99


ihrem kritischen Abschnitt lesend auf eine gemeinsame Ressource zugreifen 

und Schreib-Aktivitäten, die in ihrem kritischen Abschnitt schreibend auf die 

gemeinsame Ressource zugreifen. Wir fordern: 

1. Lese-Aktionen im kritischen Abschnitt können parallel stattfinden, 

wobei die Anzahl der parallelen Leser begrenzt sei, z.B. auf drei. 

2. Lese- und Schreib-Aktionen sind wechselseitig ausgeschlossen. 

3. auch Schreib-Aktionen sind untereinander wechselseitig ausgeschlossen. 

Die Abbildung zeigt eine mögliche Modellierung mittels eines Petri-Netzes mit 

drei Lesern und drei Schreibern. Die Anfangsmarkierung der Stelle s beschreibt 

die Anzahl der Leser, die maximal parallel im kritischen Abschnitt arbeiten 

dürfen. Will ein Schreiber den kritischen Abschnitt betreten, so müssen 

alle drei Marken auf s liegen (kein Leser im kritischen Abschnitt). Durch 

die Kantengewichtung, werden beim Betreten des kritischen Abschnitts alle 

Marken von s durch den Schreiber konsumiert. Beim Verlassen des kritischen 

Abschnitts, werden wieder drei Marken produziert, also allen Lesern wieder ein 

Zugriff ermöglicht. 

Leser Schreiber 

Eintritt 

Eintritt 

k.A. k.A. 

s 

3 

3 

Austritt Austritt 

3.5.4 Synchronisierungskonzepte 

Ziel: Einführung wichtiger Realisierungskonzepte zur Synchronisierung paralleler 

Abläufe. Dazu Konkretisierung des Prozessbegriffs. Um die modellierten 

100


Eigenschaften eines System zu realisieren, benötigt man Konzepte zur Formulierung 

paralleler Abläufe. Auf der programmiersprachlichen Ebene sind dies 

Sprachkonstrukte, wie die Java-Threads oder die Ada-Tasks. Für das Folgende 

benötigen wir einen Prozessbegriff, der den abstrakten Prozessbegriff (siehe 

Seite 68) zunächst nur so konkretisiert, dass wir damit erste wichtige Konzepte 

zur Realisierung von Abhängigkeiten zwischen parallelen Aktivitäten einführen 

können. Dies ist ein erster Schritt in die Richtung auf einen Prozess, wie er auf 

der Betriebssystemebene benötigt wird. Auf die weitere Konkretisierung eines 

Prozesses als Betriebssystem-Verwaltungseinheit zusammen mit den Maßnahmen 

zur seiner Verwaltung gehen wir in den folgenden Abschnitten ein. 

Prozess - Konkretisierung 

Ein Prozess ist ein eindeutig identifizierbarer Ablauf eines Programms in 

einem Rechensystem. Der Ablauf ist bestimmt durch die Befehle und Daten 

des Programms. Ein Prozess kann unterschiedliche Zustände besitzen. Wir 

unterscheiden die Zustände erzeugt, rechnend, rechenwillig, wartend, terminiert. 

Die Zustände eines Prozesses und Beispiele für Aktionen, die Zustandsübergänge 

zur Folge haben, sind in der Abbildung angegeben. 

fork start 

erzeugt 

terminiert 

end 

kill 

rechnend 

CPU 

Zuteilung 

E/A-Auftrag 

CPU-Entzug 

rechenwillig 

wartend 

E/A- 

Auftrag 

beendet 

Zur Verwaltung eines Prozesses wird eine Datenstruktur benötigt, die alle Information, 

die einen Prozess charakterisiert, beinhaltet. Dies ist der Prozess- 

Kontext (Prozess-Deskriptor), der auf dieser Konkretisierungsebene den eindeutigen 

Prozessnamen und die Prozesszustände umfasst und später noch erweitert 

wird (z.B. Priorität, Registerinhalte). Dazu gibt es in der Modellmaschine 

das Programmstatuswort PSW, das alle relevanten Kontextinformation eines Programmablaufes 

speichert. 

101 

kill


Konzepte für wechselseitigen Ausschluss 

Die Netz-Modellierung hat bereits gezeigt, dass man zur Synchronisation von 

Prozessen spezifische Kontrollkomponenten benötigt (z.B. zusätzliche Stellen 

im Petri-Netz, oder Kapazitätsbeschränkungen, die implizit durch die abstrakte 

Kontrollkomponente, die die Transitionsbereitschaft von Transitionen prüft, 

kontrolliert werden). Weiterhin hat die Modellierung gezeigt, dass durch 

die Synchronisationsmaßnahmen, die ja im wesentlichen durch absichtlich 

herbeigeführte Konflikte modelliert wurden, ggf. unfaire Abläufe auftreten, die in 

einem realisierten System natürlich unerwünscht sind. Das heißt, wir benötigen 

geeignete Konzepte, durch die diese Kontrollaufgaben wahrgenommen werden 

und ein unfaires Verhalten vermieden wird. 

¯ Anforderungen 

Folgende Anforderungen sind an eine Realisierung des wechselseitigen 

Ausschlusses (w.A.) zu stellen: 

– Die kritischen Abschnitte der Prozesse sind wechselseitig auszuschließen. 

– Eine Realisierung des w.A. darf nicht von einer Annahme über die 

Reihenfolge, in der die Prozesse ihre kritischen Abschnitte ausführen, 

abhängen. 

– Eine Realisierung des w.A. darf nicht von Annahmen über die Ausführungszeit 

der Prozesse abhängen. 

– Unter der Annahme, dass Prozesse nach endlicher Zeit ihre kritischen 

Abschnitte wieder verlassen, muss gelten, dass kein Prozess einen anderen 

Prozess unendlich lange daran hindern darf, seinen kritischen Abschnitt 

auszuführen. 

¯ Jede Realisierung des w.A. benötigt eine Basis, mit festgelegten atomaren, 

d.h. nicht teilbaren Operationen. Diese unteilbaren Basisoperationen sind 

von Hard- und/oder Software zur Verfügung zu stellen. Informell: mit einer 

atomaren Operation kann überprüft werden, ob der kritische Abschnitt frei ist; 

falls ja kann er sofort betreten werden (und der kritische Abschnitt damit belegt 

werden). Falls die Abfrage und das Betreten nicht atomar sind, können mehrere 

zeit-verzahnte Abfrage stattfinden, und gegebenenfalls mehrere Prozesse den 

kritischen Abschnitt betreten. 

¯ Unterbrechungssperre 

Der Ablauf des Prozesses darf nicht unterbrochen werden. 

102


– In Ein-Prozessorsystemen kann es ausreichend sein, mit Enable und Disable 

Interrupt Operationen dafür zu sorgen, dass der Prozess, der einen kritischen 

Abschnitt ausführt, dabei nicht unterbrochen wird. Dies ist nur eine 

sinnvolle Vorgehensweise, wenn die kritischen Abschnitte kurz sind, da 

ansonsten die Systemantwortzeiten sehr hoch werden und u.U. E/A-Aufträge 

nicht rechtzeitig behandelt werden. Atomarität durch Unterbrechungssperre 

funktioniert nicht unbedingt bei Mehrprozessormaschinen. 

– Realisierung mit Unterbrechungssperre ist nützlich für den Betriebssystemkern, 

aber sollte nicht für allgemeine Benutzerprogramme zur Verfügung stehen. 

Maschine 'hängt', wenn Benutzerprogramm den kritischen Abschnitt 

nicht mehr verlässt. 

¯ Test-and-Set Operationen 

Test-and-Set Operationen (Test-And-Set-Lock, TSL) erlauben auf Hardware- 

Ebene (Maschinenbefehl) das Lesen und Schreiben einer Speicherzelle als 

atomare Operation. 

– Semantik eines Test-and-Set-Befehls 

Die Instruktion liest den Inhalt eines Speicherwortes in ein Register und 

schreibt einen Wert ungleich Null an die Adresse des Wortes. Diese beiden 

Operationen werden als atomare, unteilbare Sequenz ausgeführt. Durch 

Hardware bereitgestellte atomare Lese- und Schreiboperationen findet man 

z.B. in Sun SPARC mit Befehl: compare and swap; entsprechendes gibt es 

bei Motorola, Intel 80x86, Mips R4000. 

£ Problem: wie Atomarität gewährleistet? 

£ Lösung: Die CPU, die die TSL-Instruktion ausführt, blockiert den 

Speicherbus, um andere CPU's (Multi-Prozessorumgebung) daran zu 

hindern, auf die Speichereinheit zuzugreifen. 

– Atomare MI-Befehle 

Die Modellmaschine MI unterstützt die beiden atomaren Befehle JBSSI 

("Jump on bit set and set interlocked") und JBCCI ("Jump on bit cleared 

and clear interlocked") 

£ Bitfeld 

Ein Bitfeld ist eine lückenlose Folge von bits, die über Byte-Grenzen 

hinweg gehen kann. Die maximale Länge S eines Bitfelds in MI ist 32 

bit, d.h. S liegt zwischen 0 .. 32. Die Kennzeichnung eines Bitfeldes B(P, 

S, A) erfolgt durch drei Parameter: 

103


A: Adresse der Speicherzelle 

P: Adresse eines Bit (Bitnummer) relativ zum Bit b0 im Byte mit der 

Adresse A; P kann auch negativ sein ! 

S: Länge des Bitfeldes, 0 S 32. 

£ JBSSI a1, a2, a3 

Æ Es wird das Bitfeld B(S[a1], 1, a2) angesprochen. Dieses umfasst genau 

ein Bit b. Unteilbare Ausführung von 

ØÑÔ ÙÖ ØÐ ÒÒÞ ÒØ× Ø 

Ö ÙÖ ØÐ ÒÒÞ ÒØ× Ø 

ØÑÔ ß È 

PC ist hier der Befehlszähler; das Programm wird an der Adresse a3 

fortgesetzt, falls der Wert des Bitfeldes 1 war. Andernfalls setze mit 

dem nachfolgenden Befehl fort. 

£ JBCCI a1, a2, a3 

Æ Es wird das Bitfeld B(S[a1], 1, a2) angesprochen. Dieses umfasst genau 

ein Bit b. Unteilbare Ausführung von 

ØÑÔ ÙÖ ØÐ ÒÒÞ ÒØ× Ø 

Ö ÙÖ ØÐ ÒÒÞ ÒØ× Ø 

ØÑÔ ß È 

¯ Dienste mit passivem Warten 

Unterscheidung zwischen 

aktivem Warten: Prozess muss periodisch selber prüfen, ob die Voraussetzungen 

zum Weiterarbeiten erfüllt sind. 

passivem Warten: Prozess wird in Warte-Zustand versetzt und aufgeweckt, 

wenn das Ereignis, auf das er wartet, eingetreten ist. 

Aktives Warten hat den Nachteil, dass für andere Prozesse nutzbare CPU- 

Zyklen durch das wiederholte Anfragen, ob die Voraussetzungen zum 

Weiterarbeiten erfüllt sind, nutzlos verschwendet werden. Nachfolgend werden 

einige Dienste für passives Warten kurz aufgelistet. 

– Methoden oder Dienste, so dass unter Mithilfe des Betriebssystems ein 

Prozess in den Zustand wartend übergeführt wird. 

– beim Eintreten eines passenden "Weckereignisses" wird der Prozess 

vom Betriebssystem vom Zustand wartend in den Zustand rechenbereit 

übergeführt. 

– Beispiel: Java wait und notify. 

Wait: passives Warten auf das Eintreffen einer Bedingung und 

atomar gleichzeitig Freigabe der umfassenden Sperre einer synchronized 

Methode. Wait/notify nur innerhalb von synchronized nutzbar! 

Notify: Benachrichtigen eines wartenden Threads. 

104


Aber: in Java nicht möglich anzugeben, auf WAS ein Thread warten soll 

bzw. WELCHE Bedingung eingetreten ist. Nach dem Aufwecken muss 

der Thread also noch einmal explizit prüfen, ob der Weckruf den Thread 

wirklich betrifft. In Unix gibt es die Aufrufe Sleep and Wakeup; dies 

sind Betriebssystemaufrufe, mit denen der Aufrufer blockiert und wieder 

rechenbereit gesetzt werden kann. 

¯ Semaphor-Konzept 

Das Semaphor-Konzept ermöglicht die Realisierung des w.A. auf einem 

höheren Abstraktionslevel als die bereits angesprochenen Hardwareoperationen. 

Zur Realisierung wird aber auf diese wieder zurückgegriffen. Realisierung 

von Semaphoren mit aktivem und passivem Warten möglich. Ein weiterer Synchronisationsansatz 

sind Monitore. Darunter versteht man einen abstrakten Datentyp, 

dessen Operationen konzeptuell wechselseitig ausgeschlossen sind. 

¯ Monitor-Konzept 

Das Monitor-Konzept basiert auf der Idee, die in einem kritischen Bereich 

bearbeiteten Daten zusammen mit den darauf definierten Zugriffsalgorithmen 

in einer sprachlichen Einheit - dem Monitor - zusammenzufassen. Prozesse 

können zwar jederzeit die Methoden (Prozeduren) eines Monitors aufrufen, 

jedoch können sie nicht direkt auf die internen Daten eines Monitors zugreifen. 

Zu jedem Augenblick kann nur ein Prozess innerhalb des Monitors aktiv sein. 

Der erfolgreiche Aufruf einer Monitorprozedur ist gleichbedeutend mit der 

Sperre des Monitors, die bis zum Verlassen der Monitorprozedur bestehen 

bleibt. Die Vorteile des Monitor-Konzepts gegenüber den Semaphoren ist a) die 

gemeinsamen Daten werden in der Programmstruktur der beteiligten Prozesse 

explizit sichtbar gemacht, und b) Monitore kapseln alle relevanten Daten 

und Algorithmen des kritischen Bereichs. Innerhalb eines Monitors können 

Condition-Variable definiert werden, die anwendungsspezifische Bedingungen 

formulieren. Jede Condition-Variable steht für eine Bedingung, die für die 

Fortsetzung eines Prozesses in einer Monitorprozedur erfüllt sein. Falls die 

Bedingung nicht erfüllt ist, wird die wait-Operation auf dieser Condition- 

Variable ausgeführt. Mit sleep können Prozesse wieder aufgeweckt werden. 

3.5.5 Semaphore 

Semaphore wurden 1968 von Dijkstra eingeführt. Ein Semaphor (Signalmast) 

ist eine ganzzahlige Koordinierungsvariable s, auf der nur die drei vordefinierten 

Operationen (Methoden) zulässig sind: 

105


Initialisierung, 

Prolog P (kommt von protekt), 

Epilog V (kommt von vrej). 

Operationen 

Die Operationen P und V sind atomar; sie sind unteilbar und sie werden 

wechselseitig ausgeschlossen ausgeführt. 

Sei s die Koordinierungsvariable, dann sind die P und V Operationen wie 

nachfolgend definiert. 

Die Operation müssen mit Hilfe von Systemdiensten so realisiert werden, dass 

sie wechselseitig ausgeschlossen ausgeführt werden. Vorsicht: hier gibt es keine 

ganz einheitliche Definition in der Literatur für die beiden Operationen. 

¯ Informelle Charakterisierung 

ÔÙÐ ÚÓ È ÒØ × ß 

× × 

× ß ÈÖÓÞ×× Ò ÅÒ Ö ÞÐ × 

ÛÖØÒÒ ÈÖÓÞ×× ÒÖÒ 

 

ÔÙÐ ÚÓ Î ÒØ × ß 

× × 

× ß Ö ÒÙ ÒÒ Ö ÞÐ × ÛÖØÒÒ 

ÈÖÓÞ×× Ò Ò Ù×ØÒ Ö ÒÛÐÐ Ö 

 

s ist mit einem ganzzahligen Wert vorbesetzt, z.B. s = 1. Falls s mit einem Wert 

größer 1 vorbesetzt ist, bedeutet dies die Anzahl der Prozesse, die gleichzeitig 

im kritischen Bereich erlaubt sind. 

¯ Binäres Semaphor: die Kontrollvariable s nimmt nur boolesche Werte an. 

Einsatz von Semaphoren 

Notation: Zur Vereinfachung gehen wir im Folgenden von einem vordefinierten 

Typ ×ÑÔÓÖ ÒØ × aus, der die P und V Operationen als vordefinierte, 

atomare Methoden anbietet. Semaphor-Objekte werden als Instanzen bezüglich 

des Typs ×ÑÔÓÖ erzeugt, wobei bei der Instantiierung das Semaphor mit dem 

Parameter s initialisiert wird. 

106


¯ Zugang zu kritischen Abschnitten 

Realisierung der kritischen Abschnitte von Prozessen, in denen auf eine 

exklusiv benutzbare Ressource X zugegriffen wird: 

1. Definition eines Semaphor-Objekts wa: semaphor(1), d.h. Initialisierung der 

Kontrollvariable des Semaphor-Objekts wa mit 1. 

2. Klammern der kritischen Abschnitte, in denen auf die Ressource X 

zugegriffen wird, mit P und V Operationen: 

wa.P 

Code mit Zugriffen auf X 

wa.V 

¯ Die Anforderungen an Lösungen des wechselseitigen Ausschlusses sind mit 

dem Semaphor-Konzept aus folgenden Gründen erfüllt: 

– Wechselseitiger Ausschluss für alle kritischen Abschnitte. Aufgrund der 

Initialisierung der Koordinierungsvariablen mit 1 kann sich stets nur ein 

Prozess in einem kritischen Abschnitt befinden. 

– keine Reihenfolge-Annahmen. Annahmen über die Ausführungsreihenfolge 

der kritischen Abschnitte gehen nicht ein. 

– keine Ausführungszeit-Annahmen. Es werden keine Annahmen über die 

Ausführungszeiten der Prozesse gemacht. 

– kein Verhungern. Hier muss bei der Realisierung des Semaphors eine 

faire Strategie, z.B. FIFO (First-In-First-Out), zum Einsatz kommen. Wenn 

die blockierten Prozesse aus dem Warteraum nach FIFO entnommen 

werden und jeder kritische Abschnitt mit der P- und der V-Operation des 

Semaphors geklammert ist, wird jeder blockierte Prozess nach endlicher Zeit 

entblockiert und kann somit seinen kritischen Abschnitt ausführen. 

¯ Semaphor in MI 

MI-Realisierung eines binären Semaphors mit aktivem Warten. Es ist auch 

möglich Semaphore in MI auf der Basis des passiven Wartens zu realisieren. 

Für ein binäres Semaphor gilt, dass die Semaphor-Variable s nur die Werte 0 

oder 1 annehmen kann. 

Wirkung von s.P: if s == 1 {s = 0} else {warten bis s.V ausgeführt wird} 

Wirkung von s.V: s = 1; falls ein Prozess wartet, dann aufwecken. 

Für die Realisierung gehen wir davon aus, dass beim Aufruf von s.P und s.V 

die Adresse von s auf den Stack geschrieben wird. 

107


È ÂÁ Á ËÈ 

ÊÌ ÙÒ ÞÙÑ ÖØ× Ò Ö 

Î ÅÇÎ Ï Á ËÈ 

ÊÌ 

JBCCI steht für "Jump on Bit Cleared and Cleared Interlocked". Das Bitfeld ist 

gegeben durch (31, 1, !(4+!SP)). Die Länge des Bitfeldes ist gleich 1; betrachtet 

wird das Bit 31 der durch !(4+!SP) spezifizierten Speicherzellen (4 Bytes). 

Falls das durch das Bitfeld spezifizierte Bit gleich 0 ist, erfolgt ein Sprung zur 

Adresse a. 

Beispiel Erzeuger-Verbraucher 

Im Modellierungsteil wurde das Erzeuger-Verbraucher-Problem (siehe 

Seite 83) bereits kurz vorgestellt. 

Der Erzeuger-Prozess E erzeugt Datenelemente und schreibt sie in einen 

Puffer W. 

Der Verbraucher-Prozess V liest Datenelemente aus dem Puffer und 

verarbeitet sie. 

Der Zugriff der beiden Prozesse auf den Puffer ist zu synchronisieren. 

Lösung dieses Problems mittels Semaphor. 

¯ Variante 1 

Zugriff auf Puffer W erfolgt durch Semaphor wa: semaphor(1); sowohl der 

Erzeuger-Prozess E als auch der Verbraucher-Prozess V rufen vor jedem Zugriff 

auf den Puffer W die entsprechenden Operationen des Semaphors wa auf. 

Erzeuger E: 

while (true) { 

produziere 

wa.P 

schreibe nach W 

wa.V 

} 

Verbraucher V: 


wa.P 

entnimm aus W, falls Element da; sonst warte 

wa.V 

verarbeite 

} 

Problem: es kann eine Verklemmung auftreten, wenn der Verbraucher wa.P 

ausführt und warten muss, weil der Puffer kein Element enthält. Andererseits 

kann der Erzeuger den Puffer nicht betreten, da bereits der Verbraucher den 

Puffer exklusiv belegt hat. 

¯ Variante 2 

108


Einführen eines zusätzlichen Semaphors voll: semaphor(0), das die Datenelemente 

im Puffer zählt: 

Erzeuger E: 


produziere 

wa.P 

schreibe nach W 

wa.V 

voll.V 

} 



voll.P 

wa.P 

entnimm aus W 

wa.V 

verarbeite 

} 

Für den Erzeuger ergibt sich natürlich ein analoges Problem, falls der Puffer W 

nur eine beschränkte Kapazität besitzt. Eine Abhilfe kann analog wieder durch 

die Einführung eines weiteren Semaphors "leer" erreicht werden. Dieses stellt 

sicher, dass der Erzeuger den Puffer nicht betritt, wenn der Puffer bereits voll 

ist. 

¯ Variante 3 

Einführen eines zusätzlichen Semaphors leer: semaphor(n), das die Anzahl der 

freien Elemente im Puffer zählt: 

wa.semaphor(1); //kontrolliert den Zugang zum kritischen Bereich 

voll.semaphor(0); //zählt die Anzahl der Einheiten im Puffer 

leer.semaphor(n), //zählt die Anzahl der freien Pufferplätze 

Erzeuger E: 


produziere Einheit; 

leer.P; 

wa.P; 

schreibe Einheit nach W; 

wa.V; 

voll.V; 

} 



voll.P; 

wa.P; 

entnimm Einheit aus W 

wa.V 

leer.V; 

verarbeiteEinheit; 

} 

Darf die Reihenfolge der P-Operationen für die Semaphore leer, voll, wa 

beim Erzeuger bzw. beim Verbraucher vertauscht werden, ohne dass sich 

Ablaufprobleme ergeben? 

109


Beispiel Philosophenproblem 

Zu den klassischen Synchronisationsproblemen zählt das Problem der speisenden 

Philosophen ("Dining Philosophers"). In einem Elfenbeinturm leben fünf 

Philosophen. Der Tageszyklus eines jeden Philosophen besteht abwechselnd aus 

Essen und Denken. Die fünf Philosophen essen an einem runden Tisch, auf dem in 

der Mitte eine Schüssel voller Spaghetti steht. Jeder Philosoph hat seinen festen 

Platz an dem Tisch und zwischen zwei Plätzen liegt genau ein Stäbchen. Das 

Problem der Philosophen besteht nun darin, dass die Spaghetti nur mit genau 

zwei Stäbchen zu essen sind. Darüber hinaus darf jeder Philosoph nur das direkt 

rechts und das direkt links neben ihm liegende Stäbchen zum Essen benutzen. Das 

bedeutet, dass zwei benachbarte Philosophen nicht gleichzeitig essen können. 

¯ Realisierung mit Semaphoren 

4 

3 

3 

4 

0 

2 

– Variante 1 

Für eine Lösung des Philosophenproblems seien die folgenden 5 Semaphore 

definiert: stab_0, stab_1, ...., stab_4, wobei jedes der 5 Semaphore mit 1 

initialisiert ist. Jeder Philosoph j, mit j {0,...,4}, führe den folgenden 

Algorithmus aus: 

ÔÐÓ×ÓÔ 


ÒÒ 

×Ø È ÑØ 

×Ø È 

××Ò 

ÑØ ÑÓ 

×Ø Î ÑØ 

×Ø Î ÑØ ÑÓ 

 

Der angegebene Algorithmus liefert keine korrekte Lösung des wechselseitigen 

Ausschlusses! Wenn alle fünf Philosophen gleichzeitig die er- 

0 

110 

1 

2 

1


ste P-Operation (stab_i.P mit i = j) ausführen, d.h. alle gleichzeitig ihr 

linkes Stäbchen nehmen, folgt daraus eine Verklemmungs-Situation, da kein 

Philosoph das zweite Stäbchen nehmen kann. Bei Ausführung der zweiten 

P-Operation stab_i.P; mit i=j+1 mod 5 werden alle Philosophen blockiert. 

Die Philosophen verhungern somit. 

– Variante 2 

Nur vier Philosophen dürfen gleichzeitig zu ihrem linken Stäbchen 

greifen. Dies wird durch Einführung eines weiteren Semaphors Ø× 

×ÑÔÓÖ , das mit 4 initialisiert wird, erreicht. Der "Anweisungsteil" 

jedes Philosophen wird zusätzlich mit Ø× È und Ø× Î geklammert. 

Dadurch ist gewährleistet, dass höchstens vier Philosophen gleichzeitig ihr 

linkes Stäbchen nehmen können und somit immer mindestens ein Philosoph 

auch sein zweites Stäbchen nehmen und damit essen kann. Es ergibt sich 

also folgende Lösung: Jeder Philosoph j, mit j 

Algorithmus aus: 

ÔÐÓ×ÓÔ 

{0,...,4} führt den folgenden 


ÒÒ 

Ø× È 

×Ø È ÑØ 

×Ø È 

××Ò 

ÑØ ÑÓ 

×Ø Î ÑØ 

×Ø Î 

Ø× Î 

ÑØ ÑÓ 

 

Ein weiterer wichtiger Aspekt ist die Reihenfolge bei der Ausführung 

von P Operation, falls mehrere Semaphore belegt werden müssen. 

Eine unterschiedliche Reihenfolge der P-Operationen bei den beteiligten 

Prozessen kann leicht zu einer Verklemmung führen. 

Animation Semaphor 


3.5.6 Synchronisierung von Java Threads 

Java unterstützt synchronisierte Methoden. 

ÔÙÐ ×ÝÒ ÖÓÒÞ ÚÓ ÑØÓÒÑ ß 

Eine synchronisierte Methode kann nur exklusiv von einem Java Thread betreten 

werden. Andere Threads können die synchronisierte Methode erst dann betreten, 

111

Schlichter, TU München 3.6. VERKLEMMUNGEN 

wenn der erste Java Thread die Methode wieder verlässt. Einer der wartenden 

Threads wird aktiviert. 

Java Monitor 

Ein Monitor ist ein Java-Objekt, das synchronisierte Methoden enthält. 

¯ Ein Monitor stellt sicher, dass nur ein Thread zur Zeit in einer der 

synchronisierten Methoden sein kann. Bei Aufruf einer synchronisierte 

Methode wird das Objekt gesperrt. 

¯ Während das Objekt gesperrt ist, können keine anderen synchronisierten 

Methoden des Objekts aufgerufen werden. Andere Threads müssen warten, 

bis der erste Thread die synchronisierte Methode wieder verlässt, und damit die 

Sperre freigibt. 

¯ Kritische Abschnitte können in Java als Objekte mit den zugehörigen 

synchronisierten Methoden spezifiziert werden. Synchronisierte Methoden 

können je nach der verwendeten Java Virtual Machine sehr aufwendig und 

langsam sein. Weiterhin ist zu beachten, dass zwar innerhalb eines Monitors 

eine synchronisierte Methode andere synchronisierte Methoden blockiert, nicht 

jedoch unsynchronisierte Methoden. Dies kann u.U. zu Problemen führen. 

3.6 Verklemmungen 

Mit Verklemmung (engl. deadlock) bezeichnet man einen Zustand, in dem die 

beteiligten Prozesse wechselseitig auf den Eintritt von Bedingungen warten, die 

nur durch andere Prozesse in dieser Gruppe selbst hergestellt werden können. 

Verklemmungen können durch die gemeinsame Verwendung von Ressourcen 

(synonym verwenden wir auch den Begriff Betriebsmittel), wie z.B. CPU, Arbeitsspeicher, 

E/A-Geräte, Dateien auftreten. Der Austausch von Information 

über gemeinsame Speicherbereiche ist eine häufige Situation (speicherbasierte 

Prozessinteraktion), die bei unkorrekter Verwendung von Synchronisationsoperationen 

(z.B. P und V bei Semaphoren) leicht zu Verklemmungen führen 

kann; siehe die Variante 1 (siehe Seite 108) des Erzeuger-Verbraucher Lösungsansatzes. 

Dieser Abschnitt skizziert nur die Ansätze zur Erkennung, Vermeidung 

und Verhinderung von Verklemmungen. Ein ausführliche Behandlung 

dieser Thematik erfolgt in der Vorlesung Betriebssysteme des Hauptstudiums. In 

vielen Systemen wird eine 'Vogel-Strauß'-Politik in bezug auf die Deadlockproblematik 

verfolgt, d.h. es werden keine Maßnahmen eingesetzt, sondern es wird 

112


gehofft, dass alles gut geht. In Unix wird diese Philosophie z.B. bei der Verwaltung 

der Prozesstabelle verfolgt. 

3.6.1 Allgemeines 

Es lässt sich zeigen, dass die folgenden Bedingungen notwendig und hinreichend 

dafür sind, dass eine Verklemmung auftreten kann. 

1. Die gemeinsam benutzbaren Ressourcen können nicht parallel genutzt werden, 

d.h. sie sind nur exklusiv benutzbar. 

2. Die zugeteilten/belegten Ressourcen können nicht entzogen werden, d.h. die 

Nutzung ist nicht unterbrechbar. 

3. Prozesse belegen die schon zugeteilten Ressourcen auch dann, wenn sie auf 

die Zuteilung weiterer Ressourcen warten, d.h. wenn sie weitere Ressourcen 

anfordern. 

4. Es gibt eine zyklische Kette von Prozessen, von denen jeder mindestens eine 

Ressource belegt, die der nächste Prozess in der Kette benötigt, d.h. zirkuläre 

Wartebedingung. 

3.6.2 Belegungs-Anforderungsgraph 

Die Zuteilung/Belegung und Anforderung von Ressourcen kann man sich an 

einem Graphen, dem Belegungs-Anforderungsgraph, veranschaulichen. Die 

Knoten sind die Prozesse und Ressourcen, die Kanten spiegeln Belegungen und 

Anforderungen wider. 

¯ Beispiel 

Seien P = {P1, ... , Pn} Prozesse und R= {R1, ... , Rm} Ressourcen, z.B. n = 3 

und m = 4. Beispiel eines Belegungs/Anforderungsgraphen. 

fordert 

P1 R1 

R2 

belegt 

fordert 

P2 

belegt 

fordert 

113 

P3 

R3 

belegt 

belegt 

R4


P1 und P2 warten gegenseitig aufeinander. P1 wartet auf R1, die durch P2 

belegt ist, und P2 wartet auf R2, die durch P1 belegt ist. 

3.6.3 Verklemmungs-Erkennung 

In der Praxis häufig angewendete Strategie: Verklemmungen in Kauf nehmen, 

sie erkennen und beseitigen. Man versucht eine Verklemmung festzustellen 

und sie, sollte sie eingetreten sein, zu beseitigen. Indiz für Verklemmungen, 

z.B. angeforderte Ressource ist nach einer gewissen Zeit immer noch nicht 

zugewiesen. 

¯ Erkennungs-Algorithmus 

Ansatz 1: Suche nach Zyklen im Belegungs/Anforderungsgraph. 

Ansatz 2: Prüfen, ob es eine Reihenfolge für die Ausführung der Prozesse gibt, 

so dass alle Prozesse terminieren können. 

¯ Vorgehen für Ansatz 2 

1. Starte mit Prozessmenge P, die alle Prozesse enthält, 

2. suche Prozess p aus P, dessen zusätzliche Anforderungen im aktuellen 

Zustand erfüllbar sind, 

3. falls gefunden, simuliere, dass p seine belegten Ressourcen wieder 

freigibt, 

4. entferne p aus P und gehe zu 2 

5. falls kein Prozess mehr in P, dann terminiert Suche: keine Verklemmung, 

6. falls P Ø und in Schritt 2 kein Prozess mehr gefunden wird, dessen 

Anforderungen erfüllbar sind, dann terminiert die Suche; P enthält die 

Menge der verklemmten Prozesse. 

¯ Auflösung einer Verklemmung in der Regel durch Abbruch einzelner 

Prozesse. Dies erfordert in der Regel einen manuellen Eingriff bei der 

Auswahl der abzubrechenden Prozesse. Problem: Prozesse müssen erneut 

ausgeführt werden, bei Nicht-Determinismus ggf. anderes Verhalten der neuen 

Prozessabläufe. 

3.6.4 Verklemmungs-Vermeidung 

Die Vermeidungsverfahren beruhen darauf, dass man durch die Festlegung von 

Regeln dafür sorgt, dass mindestens eine der für das Auftreten von Deadlocks 

notwendigen Bedingungen nicht erfüllt ist. Aber: solche Regeln lassen sich nicht 

für jedes Verklemmungsproblem finden. Deshalb wird meist ein allgemeinerer 

Algorithmus gesucht: Verhinderungs-Algorithmus. 

114


¯ Festgelegte lineare Reihenfolge 

Bedingung "Zyklus tritt auf" in Belegungs-/ Anforderungsgraph darf nicht 

erfüllt werden. Dazu wird eine lineare Ordnung über den Ressourcen definiert: 

R1 R2 ... Rm. 

Die Prozesse dürfen dann Ressourcen nur gemäß dieser Ordnung anfordern, 

d.h. ein Prozess, der Ressource Ri belegt, darf nur Ressourcen Rj anfordern, 

für die gilt: Rj Ri. 

Problem: wie Ordnung festlegen? Daumenregel: wichtige Ressourcen, die 

gut ausgelastet genutzt werden sollten, dürfen nicht zulange einem Prozess 

zugeordnet werden. Deshalb sollte für eine solche Ressource Rj gelten: Rj 

Ri, für unwichtigere Ri. 

¯ Andere Möglichkeiten sind: 

a) Zuteilung aller benötigten Ressourcen zu einem Zeitpunkt. 

b) zwangsweiser Entzug aller belegter Ressourcen, falls eine Ressourcen- 

Anforderung nicht erfüllt werden kann. Gerade durch die Virtualisierung 

und die Bereitstellung logischer Geräte konnte dieser Ansatz verfolgt 

werden. Durch die eingeführte Indirektionsstufe war es möglich, einem 

Prozess ohne dessen Wissen physische Ressourcen in kritischen Situationen 

zu entziehen und damit eine der 4 notwendigen Bedingungen für das 

Entstehen einer Verklemmung außer Kraft zu setzen. 

3.6.5 Verklemmungs-Verhinderung 

Die Verhinderungsverfahren basieren auf der Idee, 

die zukünftigen Betriebsmittelanforderungen von Prozessen zu analysieren 

(bzw. diese geeignet abzuschätzen) und 

solche Zustände zu verbieten (sie also zu verhindern), die zu Verklemmungen 

führen könnten. 

Ein Beispiel ist der Bankiers-Algorithmus, der 1965 von Dijkstra entwickelt 

wurde. 

Veranschaulichung des Algorithmus 

Veranschaulichung des Verfahrens anhand eines Bankenszenarios. Das Verfahren 

wird im Hauptstudium in der Betriebssystem-Vorlesung ausführlicher behandelt. 

115


¯ Ausgangspunkt 

Idee: Verwaltung von nur einer Ressourcen-Klasse, nämlich den Bankkrediten. 

– Bankier besitzt festen Geldbetrag und verleiht Geld an seine Kunden. 

– Alle Kunden sind dem Bankier bekannt, jeder Kunde hat einen eigenen 

maximalen Kreditrahmen, der kleiner als die zur Verfügung stehende 

Geldmenge des Bankiers ist. 

– Bankier hat weniger Geld als die Summe dieser Kreditrahmen. 

– Kunden können jederzeit Geld in der Höhe ihres jeweiligen Kreditrahmens 

fordern, müssen aber ggf. in Kauf nehmen, dass der Bankier diese Forderung 

erst nach endlicher Zeit erfüllt. 

¯ Aufgabe des Bankiers 

Verleihen des Geldes so, dass jeder Kunde seine Geschäfte in endlicher 

Zeit durchführen kann und Kunden möglichst parallel bedient werden. Die 

sequentielle Abfolge ist natürlich eine triviale Lösung. 

Idee: Reihenfolge für Kreditvergabe finden, so dass selbst bei denkbar 

ungünstigsten Kreditforderungen die Durchführung aller Geschäfte 

sichergestellt ist. 

ungünstigster Fall: alle Kunden fordern Geld bis zu ihrem jeweiligen max. 

Kreditrahmen, ohne Kredite zurückzuzahlen. 

¯ Grobes Vorgehen 

1. falls ein Kunde (Prozess) eine Anforderung hat, die aktuell erfüllbar ist, 

so teilt man das Geld (die Ressource) probeweise zu und 

2. untersucht für den sich damit ergebenden Zustand, ob jetzt eine 

Verklemmung vorliegt, indem 

3. für alle anderen Kunden von deren ungünstigsten Anforderungen 

ausgegangen wird und 

4. ein Erkennungs-Algorithmus ausgeführt wird. 

Falls keine Verklemmung auftritt, kann die Zuteilung tatsächlich erfolgen, 

anderenfalls könnte bei einer Zuteilung ein Deadlock auftreten (muss aber 

nicht), weshalb die Anforderung nicht erfüllt wird. 

¯ Beispiel 

Ausgangspunkt ist die folgende Situation der vier Kunden A, B, C, D (Einheiten 

jeweils in Tausend DM): 

116


Kunde aktueller Kredit max. Kreditrahmen 

A 1 6 

B 1 5 

C 1 4 

D 4 7 

Es seien noch 3 Einheiten (Tausend DM) in der Bank als Kredit verfügbar. 

– Annahme: Kunde C fordere eine weitere Einheit als Kredit an. Diese 

Anforderung wird probeweise zugeteilt und mündet nicht in einem Deadlock, 

da zuerst C (max noch 2 Einheiten bis Kreditrahmen) bedient werden kann. 

Wenn C seine Einheiten wieder zurückgezahlt hat, können B oder D und 

schließlich A bedient werden. 

Probleme bei Verhinderungsverfahren: zukünftige maximale Anforderungen 

müssen bekannt sein; anderenfalls nur worst-case Abschätzungen 

möglich. Algorithmus ist sehr zeit- und speicherplatzaufwendig. Der 

Habermann-Algorithmus ist eine Erweiterung des Verfahrens auf verschiedene 

Ressourcen. 

117

Kapitel 4 

Prozess- und Prozessorverwaltung 

Erst die Verfügbarkeit von Betriebssystemen gestattet es einem Anwender, die 

Anwendungen einfacher zu organisieren und zu realisieren; Betriebssysteme 

machen damit eine Rechenanlage zu einem leistungsfähigen, einsetzbaren 

Werkzeug. Unter einem Betriebssystem (im weitesten Sinne) verstehen wir 

den Komplex von Programmen, dessen Funktionen die Benutzerschnittstelle des 

betreffenden Rechensystems bestimmen. Erst das Betriebssystem schafft die 

Schnittstelle für einen bequemen Umgang und Zugriff auf die Funktionen der 

Rechenanlage. 


Dieser Abschnitt gibt eine kurze Einführung in einige wichtige Verwaltungsaufgaben 

eines Betriebssystems: 

¯ Verwaltung von Prozessen. 

¯ Verwaltung des Prozessors, d.h. Zuteilung der CPU an rechenbereite Prozesse 

(Scheduling). 

¯ Unterbrechungskonzept. Bei Eintreten von bestimmten Ereignissen kann die 

Ausführung von Benutzerprogrammen unterbrochen werden, z.B. Warten auf 

Eingabe. Dies ermöglicht den Mehrprogrammbetrieb, und damit eine bessere 

Ausnutzung und Auslastung aller Geräte eines Rechensystems. 

118

Schlichter, TU München 4.2. BETRIEBSSYSTEM - ÜBERBLICK 

4.2 Betriebssystem - Überblick 

Ein Betriebssystem realisiert die Schnittstelle zwischen dem Benutzer und der physischen 

Rechenanlage. Aus der Sicht des Benutzers entsteht durch ein Betriebssystem 

eine virtuelle Maschine. Für einen Benutzer ist es nicht wichtig, ob in 

einem Rechensystem Systemfunktionen durch Hardware oder Software realisiert 

sind. Ein Betriebssystem realisiert insbesondere eine Benutzerschnittstelle. Der 

Entwurf und die Implementierung von Betriebssystemen gehören zu den klassischen 

Aufgabenstellungen der Systemprogrammierung. Je nach Art der Hardware 

gibt es sehr unterschiedliche Typen von Betriebssystemen. Sie reichen von Betriebssystemen 

für Großrechner, über Server-BS bis hin zu PC-Betriebsystemen 

und eingebetteten Betriebssystemen (z.B. in einem Palm PDA). 

4.2.1 BS-Hauptaufgaben 

Ein Betriebssystem (engl. operating system) erfüllt folgende Hauptaufgaben: 

¯ Veredeln der Hardware (Virtualisierung). 

¯ Steuerung und Kontrolle der Programmausführung. Dazu werden die 

beiden Betriebsmittel CPU und Arbeitsspeicher geeignet den Programmen 

zugeteilt. Zur Durchführung dieser Aufgabe ist eine Prozessverwaltung (die im 

System momentan auszuführenden Programme) und eine Benutzerverwaltung 

notwendig. 

¯ Verwaltung der Ressourcen (Speicher, CPU, Platten, Netz etc.). Die Benutzung 

der Ein-/ Ausgabegeräte sowie des Netzanschlusses erfolgt stets über das 

Betriebssystem. 

¯ Anbieten von Diensten in Form von Schnittstellen, so dass die Ressourcen 

genutzt werden können. 

¯ Struktureller Aufbau 

119


berechtigte 

Benutzer 

Schnittstelle zur Systemumgebung 

System- 

Prozesse 

Speicher 

verwaltung 

Scheduler & 

Dispatcher 

Betriebssystem-Schnittstelle 

Prozess 

verwaltung 

Unterbrechungs- 

System 

Hardware 

Konfiguration 

4.2.2 Systemprogrammierung 

berechtigte 

Benutzer 

Benutzer- 

Prozesse 

Datei 

system 

EA- 

System 

zu überprüf. 

Benutzer 

login 

Die Programmierung eines Betriebssystems gehört zu dem Bereich der Systemprogrammierung. 

¯ Definition 

Die Systemprogrammierung befasst sich mit der Darstellung, der Realisierung, 

den Eigenschaften und der Konstruktion derjenigen Algorithmen für ein 

Rechensystem, die die Bearbeitung und Ausführung von Benutzerprogrammen 

unter vorgegebenen Qualitätsgesichtspunkten organisieren, d.h. steuern und 

kontrollieren, und zum Teil selbst durchführen. 

¯ Qualitätskriterien können z.B. sein: 

120 

Z 

u 

g 

a 

n 

g 

s 

k 

o 

n 

t 

r 

o 

l 

l 

e


– Zuverlässigkeit der durchgeführten Berechnung (Behandlung von Systemcrashs, 

Netzausfällen, fehlerhafter Nachrichtenübermittlung etc.). 

– Effizienz und Performanz einerseits systemglobal, d.h. es wird versucht, 

das System optimal auszulasten, andererseits Auftrags-lokal, z.B. es wird 

versucht, zu garantieren, dass eine Auftragsbearbeitung eine festgelegte 

Zeitdauer nicht überschreitet. 

– Einhaltung von Realzeitanforderungen: zeitkritische Aufträge besitzen z.B. 

eine Deadline bis zu der sie ausgeführt sein müssen. 

– Durchsetzung von Sicherheitsanforderungen: Schutz der Daten und 

Informationen vor unberechtigten Zugriffen und Einsichtnahme. 

– Benutzerfreundlichkeit: bequeme Formulierungsmöglichkeit von Benutzeraufträgen. 

4.2.3 Betriebssystem-Architektur 

In der Praxis findet man einige verschiedene BS-Architekturkonzepte, wobei der 

monolithische Ansatz und zunehmend auch der Mikrokern-Ansatz am weitesten 

verbreitet sind. 

Monolithischer Ansatz 

Das Betriebssystem besteht aus einer umfangreichen Menge an Funktionen, 

die sich bei Bedarf gegenseitig aufrufen können. Die Funktionen werden in 

einem großen BS-Kern zusammengefasst. Der BS-Kern wird durch Aufruf 

von Systemdiensten betreten. Der BS-Kern hat i.a. nur wenig Struktur. Als 

Grundstruktur kann man von 3 Schichten ausgehen: a) die Hauptprozedur, b) 

den Systemfunktionen, die von der Hauptprozedur aufgerufen werden, sowie c) 

den Hilfsfunktionen. Unix kann als BS mit einer monolithischen Architektur 

betrachtet werden. 

121


Anwendung 

Benutzerprozess 

Systemdienste 

Hardware 

Anwendung 

Benutzerprozess 

Hilfs 

funktionen 

Benutzer-Modus 

(User Mode) 

System-Modus 

(Kernel Mode) 

¯ komplexe, monolithische Betriebssystem sind sehr schwierig zu warten und 

zu erweitern. Es ist oft schwierig nachzuvollziehen, welche Konsequenzen 

Änderungen von Systemdiensten bzw. Hilfsfunktionen im Betriebsystem 

nach sich ziehen. Dies bezieht sich vor allem auf die Synchronisation von 

nebenläufigen Zugriffen und die Nutzung von Ressourcen. Es sind oft viele 

Detailkenntnisse des gesamten Betriebssystems notwendig. 

¯ Geschichtete Systeme 

Einen Ausweg aus der Problematik monolithischer Systeme bieten geschichtete 

Systeme; 

das Betriebssystem besteht aus einer Hierarchie abstrakter Maschinen. 

Jede Schicht hat wohldefinierte Schnittstellen und eine wohldefinierte 

Aufgabe 

Reduktion der Systemkomplexität. 

Geschichtete Systeme ermöglichen die Realisierung von Systemfamilien, 

d.h. ein neues Familienmitglied (und damit eine neue Plattform für 

Anwendungen) kann mit vergleichsweise geringem Aufwand auf irgendeiner 

abstrakten Maschine aufgesetzt werden. Unter der Voraussetzung, dass die 

122


Schnittstellen präzis und in sich konsistent festgelegt wurden, kann jede 

abstrakte Maschine unabhängig von anderen erstellt werden. Dies bietet 

auch die Möglichkeit, einzelne Schichten durch neue Implementierungen zu 

ersetzen, solange Schnittstelle und Aufgabe eingehalten werden. Gerade im 

Bereich der Rechnernetze spielt das Schichtenkonzept eine sehr wichtige Rolle 

(siehe ISO/OSI Referenzmodell oder TCP/IP Referenzmodell). 

Mikrokern-Ansatz 

Anwendungen 

Funktionsschnittstelle 

abstrakte Maschine N 


abstrakte Maschine N - 1 


abstrakte Maschine 0 

Rechnerhardware 

Schicht N 

Schicht N-1 

Schicht 0 

Der Trend moderner Betriebssystem geht hin zu einem Mikrokern-Ansatz. Im 

Mikrokern sind nur mehr Basismechanismen, z.B. Prozesskommunikation (Austausch 

von Nachrichten), CPU-Zuteilung. Möglichst viele Subsysteme sind als 

Systemprozesse außerhalb des Mikrokerns realisiert. Sie laufen im Benutzermodus 

ab, z.B. Dateisystem, Verwaltungsstrategien, Speicherverwaltung. Man 

spricht im Zusammenhang mit diesem Ansatz auch von einer Client/Server- 

Struktur. Systemfunktionen werden als Serverprozesse im Benutzermodus ausgeführt. 

Benötigt ein Prozess (Client) eine Dienstleistung schickt er eine An- 

123


forderung an einen anderen Prozess (Server), der die Dienstleistung erfüllt und die 

Antwort an den Client zurückgibt. Die Kommunikation zwischen den beteiligten 

Prozesse erfolgt über den Mikrokern. Durch die Ausgliederung in Serverprozesse 

ist eine Trennung von Mechanismus und Strategie möglich. Die Strategien werden 

in Serverprozesse im Benutzermodus realisiert, während der Mikrokern wenige 

Basismechanismen beinhaltet. 

Einfaches Austauschen von Subsysteme ermöglicht die einfache Anpassung 

von Systemanforderungen. 

Benutzer 

Programm 

Prozess 

Server 

Anforderung 

Antwort 

Memory 

Server 

Beispiel: BS-Architekturen 

File 

Server 

Mikrokern 

Hardware 

Netzwerk 

Server 

Display 

Server 

Benutzer-Modus 

(User Mode) 

System-Modus 

(Kernel Mode) 

¯ Unix Betriebssystem 

Die nachfolgende Abbildung skizziert die wesentlichen Komponenten des 

Unix Betriebssystems. Der Unix-BS-Kern enthält die Datei-, Prozess- und 

Prozessorverwaltung, die Speicherverwaltung und die Geräte-Treiber. Zur 

Nutzung beispielsweise der Systemdienste des Dateisystems bietet das BS u.a. 

die Dienste ÓÔÒ Ö ÛÖØ ÐÓ× an. Bibliotheken enthalten u.a. die 

Routinen für Standard-Ein/Ausgabe sowie malloc-Funktion zur dynamischen 

Speicherverwaltung. 

124


Programme Shells 

Datei 

System 

Geräte Treiber 

Systemschnittstelle 

u.a. open,close, read, write; fork, exec, kill, ... 

Prozess 

verwaltung 

Unterbrechungs 

behandlung 

Hardware 

Prozessor 

verwaltung 

Bibliotheken 

(z.B. lib.a) 


verwaltung 

Benutzungsschnittstelle 

Programmierschnittstelle 

Betriebssystemkern 

¯ Windows NT Betriebssystem 

Mit Hilfe von HAL wird versucht, die meisten Maschinenabhängigkeiten zu 

verbergen. HAL präsentiert dem restlichen BS abstrakte Hardwaregeräte. 

Der Kernel ist kein Mikrokern. Zielsetzung des Kernels ist die vollständige 

Hardware-Unabhängigkeit, und damit sehr portable BS-Komponenten höherer 

Ebene. Der Kernel besteht aus Control-Objects (z.B. primitive Prozessobjekte, 

Unterbrechungsobjekte) und Dispatcher-Objects (z.B. Semaphore, Ereignisse, 

Timer). Der Kernel ist auch zuständig für das Scheduling von Threads. Der 

Objektmanager verwaltet alle Systemobjekte (z.B. Prozesse, Threads, Dateien, 

Semaphore). Der Prozessmanager ist für die Erzeugung, Verwaltung und 

Löschung von Prozessen und Threads verantwortlich. Die Local Procedure 

Call Facility realisiert eine effiziente Interprozess-Kommunikation zwischen 

den Subsystemen. Die System Services stellt die Schnittstelle zum Executive 

bereit. 

125


Object 

Manager 

Logon 

Process 

Security 

Subsystem 

Security 

Manager 

Hardware Manipulation 

OS/2 Client 

OS/2 

Subsystem 

4.2.4 Betriebsarten 

System Interface (DLL) 

Process 

Manager 

Kernel 

System Services 

Local 

Procedure 

Call Facility 

Hardware Abstraction Layer (HAL) 

Hardware 

Win32 

Client 

Win32 

Subsystem 

Virtual 

Memory 

Manager 

Posix Client 

Posix 

Subsystem 

Systemaufrufe 

I/O Manager 

File Systems 

Cache Mgr 

User Mode 

Kernel Mode 

Device Drivers 

Network 

Drivers 

Applications 

Protected 

Subsysteme 

(Servers) 

NT Executive 

Beim Betrieb von Rechenanlagen können bzgl. des Zusammenwirkens von Benutzer 

und Rechensystem die Betriebsweisen Stapelverarbeitung, Dialogbetrieb 

und Echtzeitbetrieb unterschieden werden. 

¯ Stapelbetrieb 

Das Rechensystem verarbeitet Ströme von Auftragspaketen (engl. batch processing). 

Ein Benutzer deklariert vollständig alle Teile eines Auftragspaketes, 

bevor es in das System eingegeben wird. Anschließend wird das Auftragspaket 

durch das Rechensystem abgearbeitet, ohne dass der Benutzer noch Einflussmöglichkeiten 

hat. Bei Auftreten eines Fehlers muss i.a. nach der Korrektur 

das gesamte Auftragspaket nochmals gestartet werden. Auftragspakete 

können in Unterabschnitte zerfallen, z.B. Teilprogrammabläufe. Diese Betriebsart 

war in den Anfängen von Rechenanlage sehr verbreitet (Nutzung von 

Lochkarten und Lochstreifen). 

¯ Dialogbetrieb 

126

Schlichter, TU München 4.3. PROZESSVERWALTUNG 

Im Dialogbetrieb erteilt der Benutzer dem Betriebssystem einen Auftrag 

nach dem anderen im Dialog. Innerhalb eines Benutzerauftrags findet 

eine Interaktion zwischen dem Benutzer und der Systemumgebung statt 

(z.B. Eingabe weiterer Daten, Ausgabe von Zwischenergebnissen). Der 

Dialogbetrieb erfordert eine besondere Gestaltung der Benutzerschnittstelle. 

Oft wird Betriebssystem und Benutzerschnittstelle (engl. user interface) in 

einem Atemzug genannt und auch oft gleichgesetzt. Beide sind jedoch getrennt 

voneinander zusehen. Beispielsweise existierten mit dem X11-Windowsystem 

und Sun Windowsystem (auf der Basis von Postscript) zwei unterschiedliche 

Benutzerschnittstellen auf demselben Betriebssystem. 

¯ Echtzeitbetrieb 

In der Prozessteuerung (automatische Fertigungssysteme, Roboter) und im 

Multimediabereich sind die Reaktionszeiten des Betriebssystems von großer 

Bedeutung. Dies erfordert spezielle Mechanismen bei der Behandlung von 

Ereignissen und Unterbrechungen sowie der CPU-Zuteilung an rechenbereite 

Prozesse / Threads. Beispielsweise ein Videoserver (bei Nutzung des Streaming 

Ansatzes) benötigt ein Betriebssystem, das gewisse Echtzeitfähigkeiten hat. 

Videos müssen mit einer bestimmten Geschwindigkeit abgespielt werden. Die 

Bilder dürfen an das Abspielprogramm nicht zu langsam (ansonsten ruckelt 

das Videobild) und nicht zu schnell ausgeliefert werden (sonst gehen bei 

Pufferüberlauf Videobilder verloren). 

4.3 Prozessverwaltung 

Dieser Abschnitt behandelt das Prozesskonzept, Datenstrukturen zur Beschreibung 

des aktuellen Prozesszustandes sowie Dienste zum Aufruf von Systemfunktionen. 

4.3.1 Prozesskonzept 

Wir unterscheiden Benutzerprozesse, die Anwendungsprogrammen in Ausführung 

entsprechen, und Systemprozesse, die Programme/Dienste des Betriebssystems 

durchführen. 

127


a) Jeder Prozess besitzt einen eigenen Prozessadressraum. 

b) Spezielle Systemprozesse sind die Dämonen (engl. daemon); das sind 

Hilfsprozesse, die ständig existieren, die meiste Zeit aber passiv sind. Sie 

erfüllen i. d. R. Service-Funktionen und werden dazu durch das Eintreten 

von Ereignissen aufgeweckt (z.B. Datei zum Drucken eingetroffen) oder 

werden von Zeit zu Zeit aktiv, um selber zu prüfen, ob Dienste zu 

erbringen sind. 

Dienste der Prozessverwaltung 

Die Prozesse werden durch das Betriebssystem verwaltet. 

Prozess-Erzeugen und Starten (z.B. fork). 

Terminieren, Auflösen (z.B. exit, kill). 

Prozess-Auswahl, Strategien zur Prozessorzuteilung: Scheduling (z.B. 

change-priority). Der Scheduler ist für Multitasking-Betriebssysteme 

von Bedeutung. Er wählt den nächsten auszuführenden Prozess aus 

der Menge der rechenbereiten Prozesse aus. Dabei werden in den 

Betriebssystemen unterschiedliche Verfahren angewandt, z.B. Auswahl nach 

Prioritäten oder Zeitscheibenverfahren (Round Robin). Eine ausführlichere 

Diskussion verschiedener Strategien erfolgt später und im Hauptstudium 

(Betriebssysteme). 

Prozessor-Anbindung; Dispatching (z.B. suspend, resume, sleep, wakeup). 

Die Durchführung des Übergangs eines Prozesses in den Zustand rechnend 

erfolgt durch den Dispatcher. Beispielsweise teilt er den vom Scheduler 

ausgewählten Prozess der CPU zu. Der Prozess geht vom Zustand 

rechenbereit in den Zustand rechnend über; der Prozess wird ausgeführt. 

Dabei muss sichergestellt, dass der entsprechende Kontext des Prozesses (z.B. 

seine Register) geladen werden. 

Prozesskontrollblock 

Jeder Prozess muss als eine Verwaltungseinheit beschrieben sein. Ein Prozess 

wird durch seinen Prozess-Kontext und dieser durch den Prozesskontrollblock 

(PCB) beschrieben. Ein PCB wird meist programmiersprachlich als Verbund 

(record) spezifiziert. Ein PCB (process control block) enthält i.d.R. folgende 

Informationen: 

¯ eindeutiger Name, z.B. fortlaufende Nummerierung des Prozesses (z.B. pid in 

Unix) 

128


¯ Name des Benutzers, dem der Prozess zugeordnet ist 

¯ der momentane Prozesszustand (wartend, rechnend, rechenwillig, ...) 

¯ falls der Prozess rechnend ist, Angabe des zugeordneten Rechnerkerns 

¯ falls der Prozess wartend ist, eine Spezifikation des Ereignisses, auf das der 

Prozess wartet (z.B. Adresse eines Semaphors). 

¯ die Ablaufpriorität des Prozesses 

¯ die Inhalte der programmierbaren Register (z.B. in MI: R0, .. , R15) 

¯ die Inhalte der Register, in denen die Anfangsadresse und Länge 

der prozessspezifischen Speicherabbildungstabellen enthalten sind (virtuelle 

Adressierung) (z.B. in MI P0B für die Seitentabelle) 

¯ das Programmstatuswort (PSW). Das PSW enthält weitere Informationen, 

die der Rechnerkern über den Prozess kennt. In der MI enthält PSW den 

Zustand der CC-Register, z.B. das N-Register (Ergebnis der letzten Operation 

negativ), den Ablaufmodus (Benutzer- oder Systemmodus), die momentane 

Ablaufpriorität, die Adressierungsart im Benutzermodus (virtuelle oder direkte 

Adressierung). Daneben kann ein PCB noch weitere Statistiken über die 

Historie des Prozesses speichern, die beim Scheduling ausgewertet werden. 

Prozesslisten 

Die Prozesse werden in Zustandslisten verwaltet, die als verkettete Liste der PCBs 

realisiert sind. 

für E/A-Geräte (z.B. Platte, Terminal) existiert i.d.R. eine jeweils eigene 

Warteschlange, die die PCBs der wartenden Prozesse enthält. 

Rechnend 

Rechenwillig 

Ready-Queue 

Wartend 

129 

Prozessidentifikation 

Registerzustand 

Scheduling Information (z.B. 

Priorität) 

Adressrauminformation 

Sonstiges 

nächster PCB 

Prozesskontrollblock PCB


Bei der MI steht während der Zuordnung eines Rechnerkerns an einen Prozess 

die Maschinenadresse des zugehörigen PCB in dem Sonderregister PCBADR des 

Rechnerkerns. Da der PCB eine Datenstruktur des Betriebssystems ist, kann die 

Ablage nicht im Benutzeradressraum erfolgen. Da weiterhin die Prozesse nicht 

kellerartig aktiviert und deaktiviert werden, sondern in beliebiger Folge, kann er 

auch nicht im Keller des Betriebssystems abgelegt werden, sondern es wird dafür 

die Halde verwendet. 

Zustandsmodell 

Das Prozess-Zustandsmodell unterscheidet neben den bereits vorgestellten 

Zuständen rechenwillig, rechnend, wartend auch den Zustand ausgelagert. 

Letzterer Zustand tritt ein, wenn der Adressraum aufgrund Speichermangels aus 

dem Arbeitsspeicher auf den Hintergrundspeicher verlagert wird ("swapping"). 

add retire 

rechenwillig 

assign rechnend 

swap in 

ready 

resign 

wartend 

ausgelagert 

130 

block 

swap out


Zustandsübergänge 

: ein neu erzeugter Prozess wird zu der Menge bereiten Prozesse 

hinzugefügt; 

××Ò: als Folge eines Kontextwechsels wird dem Prozess die CPU 

zugeordnet; 

ÐÓ : aufgrund eines EA-Aufrufs oder einer Synchronisationsoperation 

wird der Prozess wartend gesetzt; 

ÖÝ: nach Beendigung der angestoßenen Operation wechselt der Prozess 

in den Zustand rechenwillig; er bewirbt sich erneut um die CPU; 

Ö×Ò: dem rechnenden Prozess wird die CPU entzogen; er bewirbt sich 

anschließend erneut um die CPU; 

ÖØÖ: der aktuell rechnende Prozess terminiert; 

×ÛÔ ÓÙØ: der Prozess wird auf den Hintergrundspeicher ausgelagert; 

×ÛÔ Ò: der Prozess wird vom Hintergrundspeicher in den Arbeitsspeicher 

geladen. 

4.3.2 Dispatcher 

Aufgabe des Dispatchers: Realisieren der Zustandsübergänge zwischen rechnend 

und rechenwillig: Prozessor binden und entbinden. Dazu ist ein Kontextwechsel 

erforderlich. Dabei ist zu berücksichtigen, dass die Prozesslisten entsprechend 

aktualisiert werden, d.h. der PCB des ausgewählten Prozess muss aus der 

rechenwillig-Liste entfernt werden und in die rechnend-Liste eingetragen werden. 

Kontextwechsel 

CPU wird entzogen und einer anderen Aktivität zugeteilt; ein Kontextwechsel ist 

erforderlich, falls der rechnende Prozess P1 in den Zustand wartend oder z.B. 

durch Prozessorentzug in den Zustand rechenwillig übergeführt wird. 

¯ Problem 

aktueller Ausführungskontext des Prozesses muss gesichert werden und 

Kontext des nächsten rechenbereiten Prozesses muss geladen werden. Falls 

für den Zugriff auf eine Datei X nur ein Dateizeiger zur Verfügung steht, dann 

muss die Position des Dateizeigers gerettet werden. Wenn Prozess P1 wieder 

rechnend wird, dann soll er an der Position weiterlesen, an der er unterbrochen 

wurde; falls zwischenzeitlich ein anderer Prozess P2 ebenfalls die Datei gelesen 

und den Dateizeiger verändert hat, darf dies bei der Fortsetzung von P1 keine 

Auswirkung haben. In Unix erhält jeder Prozess einen eigenen Dateizeiger. 

Achtung: je umfangreicher ein PCB ist, desto "teurer" sind Prozesswechsel, 

d.h. das Umschalten der CPU zwischen den Prozessen. 

131


Threads 

Threads haben einen sehr viel kleineren Kontext Umschalten zwischen 

Threads innerhalb eines Prozesses sehr schnell, da Adressraum und andere 

Ressourcen (z.B. Dateien) gemeinsam genutzt werden. Auch TLB-Einträge 

( Translation lookaside Buffer (siehe Seite 175)) der Seitenadressierung 

müssen nicht invalidiert werden. Damit ergeben sich auch keine Folgekosten 

durch Laden von Seiten bei cache-Misses. Dagegen ist das Umschalten von 

Threads, die unterschiedlichen Prozessen angehören, ebenso aufwendig wie ein 

Prozesswechsel. 

Beispiel: Kontext-Wechsel in Unix 

Kontextwechsel z.B. durch den Aufruf der Systemoperation sleep durch einen 

Prozess. Beim Aufruf der Operation sleep ist ein Warteraum, in den der 

Prozess eingefügt werden soll, anzugeben (z.B. E/A-Warteraum, oder warten 

auf Terminieren eines Kind-Prozesses). Bei der Ausführung von sleep werden 

vergröbert folgende Schritte durchgeführt. 

1. Maskieren von Interrupts; 

2. Lokalisieren der benötigten Warteschlange; 

3. Neuberechnung der Priorität des Prozesses; 

4. Einfügen des Prozesses in die Warteschlange; 

5. Aufruf der Operation zum Kontextwechsel. 

Bei der Ausführung der Operation zum Kontextwechsel wird vom Scheduler 

der nächste Prozess ausgesucht, dem der Prozessor zugeteilt werden soll, 

und mit dieser Information wird die Operation resume aufgerufen. Zunächst 

wird der Zustand des noch aktuellen Prozesses aus den Registern in den 

Prozesskontrollblock des Prozesses gespeichert. Dann wird die Adresse des 

Prozesskontrollblocks des neu zu bindenden Prozesses sowie der Zustand des 

neuen Prozesskontrollblocks in die Register geladen und der Kontextwechsel 

ist durchgeführt. Durch das Maskieren von Interrupts kann das Warten auf die 

relevanten Ereignisse eingestellt werden, d.h. die anderen Interrupts werden 

ausgeblendet. 

4.3.3 Arbeitsmodi 

Ziel für den Betrieb von Rechensystemen: kontrollierter Zugriff auf Hardwarekomponenten 

nur durch BS. Dadurch soll verhindert werden, dass Benutzer 

oder Softwaresysteme Hardwarekomponenten unsachgemäß nutzen, und implizit 

andere nebenläufige Aktivitäten schädigen. 

132


Lösung: alle Zugriffe auf Hardware nur über privilegierte Befehle zulässig; 

Frage: wer darf privilegierte Befehle ausführen Antwort: Prozesse in 

einem privilegierten Modus. 

Herkömmlich unterscheidet man zwischen dem Benutzer- (engl. user mode) und 

dem Systemmodus (engl. kernel mode). 

¯ Benutzermodus 

Es sind nur die nicht privilegierten Befehle verfügbar. Damit ist der Zugriff auf 

Prozessadressraum und unkritische Register, wie Befehlszähler, Indexregister 

möglich. Benutzerprozesse werden im Benutzermodus ausgeführt.Kritische 

Register, über die der Kontext eines Prozesses beeinflusst werden kann 

(z.B. Ablaufpriorität, Arbeitsmodus) können nur im Systemmodus verändert 

werden. Wird versucht, einen privilegierten Befehl auszuführen, gibt es einen 

Befehlsalarm. 

¯ Systemmodus 

Es sind auch die privilegierten Befehle verfügbar (z.B. Anhalten der Maschine, 

Verändern der Ablaufpriorität). Die Dienste des Betriebssystemkerns werden 

im Systemmodus ausgeführt. 

¯ Nutzung der Hardware-Komponenten nur über Dienste des BS: Aufruf eines 

BS-Dienstes über spezielle Befehle: den Systemaufruf. Dies führt zu einer 

Unterbrechung (siehe Seite 150) und damit zu einem kontrollierten Eingang in 

das BS (z.B. Zugriffsrechte des aufrufenden Prozesses prüfen). 

4.3.4 Systemaufrufe 

Ein Systemaufruf ist eine Funktion, die von einem Benutzerprozess aufgerufen 

wird, um einen BS-Kerndienst aufzuführen. 

1. Der Systemaufruf überprüft die übergebenen Parameter und bildet daraus 

eine Datenstruktur, um die Daten an den BS-Kern weiterzureichen. 

2. Danach wird eine spezielle Instruktion, ein Software Interrupt (Trap), 

ausgeführt. Diese Instruktion identifiziert über einen Operanden den 

gewünschten Systemdienst. 

3. Bei Ausführung der Trap-Instruktion wird der Zustand des Benutzerprozesses 

gerettet und es findet ein Wechsel in den Systemmodus statt. 

In manchen Programmiersprachen sind Systemaufrufe (C, C++) über den 

Aufruf von Prozeduren der Laufzeitumgebung, die ihrerseits die Systemaufrufe 

durchführen, möglich. In Java ist kein direkter Systemaufruf möglich, sondern 

dies erfolgt i.a. über Methoden, die in anderen Sprachen geschrieben sind, meist 

C, C++. 

133


Beispiel 

Lesen von Daten aus einer Datei und Kopieren in eine andere Datei. Dabei treten 

die folgenden Systemaufrufe auf: 

(1) Schreiben des Prompts auf Bildschirm: Angabe der Dateinamen 

(2) Lesen der Tastatureingabe (bzw. Analoges bei Mouse-Eingabe) 

(3) Öffnen der zu lesenden Datei (open) 

(4) Erzeugen der neuen Datei 

(5) ggf. Fehlerbehandlung: Nachricht auf Bildschirm 

(6) Schleife: Lesen von Eingabedatei (ein Systemaufruf) und schreiben in zweite 

Datei (auch Systemaufruf) 

(7) Schließen beider Dateien 

(8) Ausgabe auf Bildschirm 

Durch die Verwendung von Laufzeitroutinen ergibt sich eine höhere Abstraktionsebene 

Aufruf einer Routine, die die notwendigen Systemaufrufe durchführt. 

Privilegierte MI Befehle 

Die Modellmaschine MI unterstützt die folgenden privilegierten Maschinenbefehle: 

134


a) das Anhalten der Maschine: HALT 

b) Laden des PCB in den Rechnerkern: LPCB; die Adresse des PCB steht im 

Register PCBADR. Die Adresse des PCB im Speicher ergibt sich durch 

die Adresse im Register PCBADR. PC und PSW aus dem PCB werden 

nicht in die aktuellen Register übernommen, sondern in den Keller für 

den Systemmodus abgelegt (bei der Fortsetzung können dann die Register 

entsprechend besetzt werden). 

c) Speichern des PCB (vom Rechnerkern) : SPPCB; Die Zieladresse im 

Speicher ergibt sich durch die Adresse im Register PCBADR. PC und 

PSW werden nicht aus den aktuellen Registern, sondern vom Keller 

genommen und im PCB im Speicher abgelegt. 

d) Rückkehr aus Unterbrechungen: REI (return from interrupt); Prozess, 

dessen PCB geladen ist, wird fortgesetzt. 

e) Speichern von Sonderregistern: SPSR a1; Das Sonderregister wird 

immer rechtsbündig in ein Wort abgespeichert. Links wird mit Null 

aufgefüllt, da die Sonderregister nicht immer Wortlänge haben. Siehe 

dazu auch die MI-Beschreibung. 

f) Laden von Sonderregistern: LSR a1; Es wird der zu ladende Wert für das 

Sonderregister immer rechtsbündig in einem Wort erwartet. 

g) Auslösen eines Rechnerkernalarms : RKALARM a1, wobei S[a1] die 

Nummer des zu unterbrechenden Rechnerkerns angibt. Die MI kann bis 

zu 4 Rechnerkerne haben, die von 0 bis 3 nummeriert sind. 

Folgende Größen bzw. Hardware Komponenten sind nur mit privilegierten 

Befehlen veränderbar: 

¯ der Arbeitsmodus. 

¯ der Adressierungsmodus. Hier wird zwischen virtuelle Adressierung 

(Seitenadressierung) und direkter Adressierung unterschieden. Letztere 

Adressierungsart ermöglicht auch den Zugriff auf den physischen Speicher. 

¯ die Register mit Adresse oder Länge der Speicheradressierungstabellen. 

¯ das Register PCBADR mit der Adresse des Prozesskontrollblocks PCB. 

¯ das Register SCBADR mit der Adresse des Systemkontrollblocks SCB. 

Der Systemkontrollblock beinhaltet die Startadressen für die Routinen zur 

Behandlung von Unterbrechungen, z.B. wenn Befehlsalarm auftritt oder eine 

Rückmeldung eines Kanals eintrifft. 

135


Systemaufrufe in der MI 

Systemdienste werden über Zahlen identifiziert. Ein Systemaufruf in der MI 

erfolgt mit dem Befehl CHMK. Nach dem oben Gesagten führt der Befehl 

CHMK daher bei der MI zu einer Unterbrechung. Es findet ein Übergang von 

einem Programmstück im Benutzermodus (Benutzer- oder Systemprozess) zu 

einem Programmstück im Systemmodus statt. Der Systemkern läuft in einem 

anderen Programmadressraum und mit einem anderen Arbeitsmodus. Daher muss 

muss der momentane Ablaufzustand (Rechnerkernzustand) gesichert werden und 

ein neuer Ablaufzustand eingestellt werden. Es muss auch mindestens der 

aktuelle PC und das PSW gerettet werden. Der neue Ablaufzustand, z.B. die 

Einsprungadresse in den Systemkern, darf aus Sicherheitsgründen nicht durch den 

Aufrufer, der ja nicht vertrauenswürdig ist, definiert werden. Es erfolgt daher eine 

Standardbesetzung. Diese Standardbesetzung ist wie bei den später besprochenen 

Unterbrechungen. Der Befehl CHMK führt in der MI zu einer Unterbrechung. 

CHMK a1 Aufruf eines Systemdienstes a1 ("CHange Mode to 

Kernel") 

¯ Wirkung des Befehls CHMK 

Auch das Betriebssystem verfügt analog zum Benutzerprozess über einen 

Systemkeller. 

– Ablage von PSW und PC des aufrufenden Prozesses auf dem Systemkeller. 

– Der Operand a1 gibt die Nummer des aufgerufenen Systemdienstes 

an. Diese Nummer wird ebenfalls auf dem Systemkeller abgelegt 

und kann vom Systemkern ausgewertet werden. Weitere Parameter 

für den Systemdienst werden in einem Versorgungsblock bereitgestellt. 

Der Ort dieses Versorgungsblockes muss vereinbart werden. Achtung 

bei Adressübergaben: 

Adressräumen! 

Aufrufer und Systemkern evtl. in getrennten 

– Zustand des Systemkellers nach der Ausführung von CHMK: 

Bit 0 - 31 

SP+8 PSW 

SP+4 PC 

SP S[a1] 

– Der Eintrag "vorhergehender Arbeitsmodus" im PSW wird mit dem 

gegenwärtigen Arbeitsmodus besetzt. Der gegenwärtige Arbeitsmodus ist 

der beim Aufruf von CHMK gültige Arbeitsmodus. Er wird gerettet. 

– Der aktuelle Arbeitsmodus wird der Systemmodus. 

136


– Der Befehlszähler PC wird auf die Adresse für die Behandlung von Systemdiensten 

gemäß dem Systemkontrollblock eingestellt (Systemdienstanfangsbehandlung). 

¯ Rückkehr von Systemaufruf in MI 

REI Rückkehr von der Unterbrechungsbehandlung (REturn from Interrupt) 

Es werden die Register PC und PSW gemäß den Werten auf dem 

Systemkeller besetzt. Dies entspricht der Einstellung des alten Zustandes 

des aufrufenden Prozesses, insbesondere bezüglich PC, Arbeitsmodus und 

Adressierungsmodus. Der Prozess, der den Systemdienst aufgerufen hat, wird 

also fortgesetzt. 

– Zustand des Systemkellers vor der Ausführung von REI: 

Bit 0 - 31 

SP+4 PSW 

SP PC 

4.3.5 Realisierung von Threads 

Es existieren zwei grundlegende Ansätze, Threads in einem Rechensystem 

zu realisieren: im Benutzer-Adressraum (Benutzermodus) oder im System- 

Adressraum (Systemmodus). 

¯ im Benutzer-Adressraum 

Der BS-Kern verwaltet nur single-threaded Prozesse. Damit ist es auch möglich 

ein Thread-Package für ein Betriebssystem zu realisieren, das auf BS-Ebene 

keine Threads unterstützt. 

Prozess Thread 

Laufzeitsystem 

Thread 

tabelle 

BS-Kern 

137 

Prozesstabelle 

Benutzer 

Adressraum 

(Benutzermodus) 

System 

Adressraum 

(Systemmodus)


– Threads werden durch Laufzeitsystem im Benutzeradressraum verwaltet. 

Eine Thread-Tabelle speichert Informationen (Register, Zustand, etc.) über 

Threads pro Prozess. 

– Prozessorzuteilung im BS-Kern erfolgt an Prozesse. Laufzeitsystem 

bestimmt, welcher Thread rechnend gesetzt wird. Jedes Laufzeitsystem 

hat seinen eigenen Thread-Scheduler. Damit ist es möglich, dass jeder 

Prozess seine eigene Variante des Scheduling-Algorithmus nutzt, d.h. die 

Auswahl des nächsten auszuführenden Threads. Beispielsweise kann durch 

eine geeignete Strategie verhindert werden, dass der Garbage Collector zu 

einem ungünstigen Zeitpunkt unterbrochen wird. 

– Problem: Systemaufruf eines Threads blockiert die anderen Threads 

des Prozesses. Dadurch wird gerade dies verhindert, was mit Threads 

in Applikationen erreicht werden soll, d.h. die Ausführung paralleler 

Aktivitätssequenzen, wobei trotz Blockierung einiger Threads andere 

Threads desselben Prozesses weiterlaufen können. 

– Problem: wie wird einem Thread die CPU entzogen? Threads müssen die 

CPU durch Ausführung des Befehls ØÖÝÐ freiwillig aufgeben. Das 

Laufzeitsystem wählt dann einen anderen rechenwilligen Thread aus. Falls 

ein Thread die CPU nicht aufgibt, kann ihm vom Laufzeitsystem (nicht wie 

im BS-Kern) die CPU entzogen werden. Innerhalb eines Prozesses existieren 

keine Clock-Interrupts. 

¯ im System-Adressraum 

Neben den Prozessen werden im BS-Kern auch alle Threads verwaltet. 

Damit können auch alle Funktionen zur Verwaltung von Prozessen, z.B. 

CPU-Zuteilung, für Threads verwendet werden. Dies bedeutet jedoch auch, 

dass bei Erzeugung bzw. Terminierung von Threads jeweils Systemaufrufe 

durchgeführt werden müssen. Systemaufrufe sind jedoch i.a. aufwendig. 

138


Prozess Thread 

BS-Kern 

Thread 

tabelle 

Prozesstabelle 

Benutzer 

Adressraum 


System 

Adressraum 

(Systemmodus) 

– Thread-Tabelle speichert Informationen (Register, Zustand, etc.) über 

Threads. 

– Prozessorzuteilung im BS-Kern erfolgt an Threads. Falls ein Thread 

blockiert, kann die Prozessorzuteilung entscheiden, ob ein anderer Thread 

aus demselben Prozess die CPU zugeteilt bekommt, oder ein Thread eines 

anderen Prozesses. 

– Der Systemaufruf eines Threads blockiert nicht die anderen Threads des 

Prozesses. 

¯ Es wurden auch hybride Ansätze verfolgt, die eine Kombination beider 

Möglichkeiten realisieren. Der BS-Kern verwaltet sogenannte Kernel-Threads. 

Das Betriebssystem kennt nur Kernel-Threads und teilt diese der CPU zur 

Ausführung zu. Threads des Benutzer-Adressraums (User-Threads) werden 

jeweils auf Kernel-Threads abgebildet, dabei können gleichzeitig mehrere 

User-Threads eines Prozesses verfügbaren Kernel-Threads zugeordnet werden. 

Auf einen einzelnen Kernel-Thread können gleichzeitig auch mehrere User- 

Threads abgebildet werden (Multiplexing). 

139

Schlichter, TU München 4.4. PROZESSORVERWALTUNG 

Benutzer 

Adressraum 


System 

Adressraum 

(Systemmodus) 

Prozess 

BS-Kern 

4.4 Prozessorverwaltung 

Kernel 

Thread 

User-Thread 

Eine wesentliche Aufgabe der Prozessorverwaltung besteht darin zu entscheiden, 

welcher der um den bzw. die Prozessor(en) konkurrierenden Prozesse (bzw. 

Threads) zu einem Zeitpunkt an den bzw. die Prozessor(en) gebunden wird. 

Dazu steht die BS-Komponente Scheduler zur Verfügung. Die Durchführung 

der Zustandsübergangs (siehe Seite 130) eines Prozesses von rechenwillig 

nach rechnend ist Aufgabe des Dispatchers, während der Scheduler aus der Liste 

der möglichen Prozesse einen geeigneten auswählt. Der Scheduler wählt den 

Prozess aus, der durch einen assign-Zustandsübergang nach rechnend übergeht. 

In folgenden Situationen muss ein Scheduler auf jeden Fall aktiviert werden: 

ein neuer Prozess wird erzeugt; 

ein Prozess terminiert; 

ein Prozess blockiert aufgrund eines EA-Auftrags; 

eine EA-Unterbrechung tritt auf. 

Daneben kann das Betriebssystem einem Prozess die CPU entziehen, falls er 

bereits zulange rechnend ist (Ablauf der Zeitscheibe). 

4.4.1 Kriterien 

Der Scheduler wählt aus der Menge der rechenwilligen Prozesse den nächsten 

auszuführenden Prozess aus. Es existieren unterschiedliche Verfahren die von der 

jeweiligen Prozessorverwaltungsstrategie abhängen. Mögliche Leistungskriterien 

für ein Schedulingverfahren: 

140


¯ Fairness. Jeder Prozess soll einen fairen Anteil der CPU zum Rechnen erhalten. 

¯ Effizienz, Prozessorauslastung. Dies ist ein Maß für die Auslastung eines 

Prozessors. Ziel sollte es sein, dass möglichst alle Teile der Rechenanlage 

effizient genutzt werden, z.B. CPU und EA-Geräte sollten möglichst gut 

ausgelastet sein. 

¯ Antwortzeit für interaktive Benutzer (Dialogverarbeitung). Für interaktive Anwendungen 

muss die Zeitspanne zwischen Ankunft, z.B. einer Benutzereingabe 

und einer potentiellen Reaktion möglichst kurz sein. 

¯ Wartezeit, insbesondere für Batch-Jobs (Stapelverarbeitung). Darunter ist die 

Verweilzeit in der Bereit-Liste zu verstehen, d.h. die Zeitdauer in der einem 

rechenwilligen Prozess kein physischer Prozessor zugeordnet ist. 

¯ Abschlusszeit, insbesondere für Realzeitsysteme. Hier geht es darum, ob die 

Realzeitgarantien eingehalten werden. Wird der Prozess rechtzeitig fertig und 

liefert seine Ergebnisse aus (z.B. das Videobild)? 

¯ Durchsatz, Anzahl der Aufträge pro Zeiteinheit. Mit den Leistungskriterien gibt 

es Probleme: a) die Optimierungsziele sind teilweise widersprüchlich (z.B. eine 

Strategie, die den Durchsatz optimiert ist nicht notwendigerweise geeignet, um 

kurze Antwortzeiten zu ermöglichen), und b) das Prozessverhalten (z.B. wann 

kommt der nächste E/A-Befehl) kann vom Scheduler nicht exakt vorausgesagt 

werden. Deshalb werden Scheduling-Strategien meist abhängig von der 

Betriebsart gewählt (Dialogbetrieb vs. Stapelbetrieb). 

4.4.2 Scheduling-Strategien 

Es werden zwischen zwei Klassen unterschieden: nicht-unterbrechende (nonpreemptive) 

und unterbrechende Strategien (preemptive). 

nicht unterbrechend: Scheduling nur dann möglich, wenn der rechnende 

Prozess blockiert wird oder wenn er terminiert, d.h. Prozess behält CPU bis 

er sie selber abgibt. 

Beispiel: Microsoft Windows 3.x; unterbrechende Strategien erst ab 

Windows 95 

unterbrechend: Unterbrechung beim Eintreten von speziellen Ereignissen, 

u.a. Eintreffen eines Prozesses mit höherer Priorität oder Prozess geht in 

Wartezustand. Problematisch ist diese Strategie für die Ausführung von 

Operationen des BS-Kerns. Lösung bei vielen Betriebssystemen (z.B. Unix): 

Ausführung von BS-Kernoperationen sind nicht unterbrechbar (Vorsicht: hier 

in bezug auf Scheduling, Interrupts können auftreten). 

141


Zeitscheibenstrategie 

Die Zeitscheibenstrategie (Round Robin) ist unterbrechend. Ziel ist die 

gleichmäßige Verteilung der Rechenzeit auf rechenwillige Prozesse. Round Robin 

ist eine weit verbreitete preemptive Schedulingvariante. Das Verfahren ordnet 

jedem rechenwilligen Prozess ein definiertes Zeitquantum (Zeitscheibe) zu. In 4.3 

BSD Unix beträgt z.B. die Zeitscheibe 100 ms. Nach dem Kontextwechsel ist der 

Prozess entweder bis zum Ablauf des Zeitquantums oder bis zum Auftreten einer 

blockierenden Systemfunktion im Besitz der CPU. Alle rechenwilligen Prozesse 

werden in einer FIFO-Warteschlange verwaltet. Nach Ablauf der Zeitscheibe wird 

der Prozess am Ende der FIFO-Warteschlange eingereiht. 

¯ Es werden die Prozesse an den Prozessor jeweils für ein festgelegtes 

Zeitquantum q gebunden und spätestens nach dem Ablauf dieser Zeitspanne 

wird den Prozessen der Prozessor wieder entzogen. 

¯ zyklisches Bedienen der Prozesse (Round Robin). 

¯ Ready-Queue (Liste der rechenwilligen Prozesse) als zyklische Warteschlange 

realisiert. 

¯ Wahl des Zeitquantums: 

falls q zu klein: viele unproduktive Kontextwechsel. Es scheint, als ob jeder 

Prozess seinen eigenen Prozessor besitzt; process sharing. 

falls q zu groß: Round Robin wird zu einem reinen FCFS Scheduling 

(First Come First Served), da die Wahrscheinlichkeit für einen Aufruf 

eines blockierenden Systemdienst steigt. Ein zu großes Zeitquantum ist 

insbesondere für interaktive Anwendungen nicht empfehlenswert, da sich 

die Wartezeit für einen Prozess, und damit die Reaktionszeit erhöht. 

Typische Werte für q: 10 bis 100 Millisekunden. 

¯ Für q = 100 ms gilt bei 1 MIPS Maschine: ca. 100.000 Instruktionen/q. 

Prioritäten 

Diese Strategie ist i.a. unterbrechend. Sie basiert darauf, an die Prozesse 

Prioritäten zu vergeben. Die Prioritätenvergabe kann dabei statisch oder 

dynamisch sein. Die Prioritätenstrategie kann unterbrechend und nichtunterbrechend 

sein. Im ersten Fall wird der Ablauf eines Prozesses unterbrochen, 

wenn ein anderer Prozess mit höherer Priorität rechenwillig wird. Im zweiten 

Fall behält der Prozess die CPU solange bis er entweder eine blockierende 

Systemfunktion aufruft oder die CPU freiwillig abgibt. 

142


¯ Prioritäten sind i.a. ein festgelegter Zahlenbereich, z.B. 0, ..., 7. Achtung: 

häufig: niedrige Zahl entspricht hoher Priorität, muss aber nicht so sein. 

¯ Statische Prioritätenvergabe 

jeder Prozess besitzt für die Dauer seiner Existenz eine feste Priorität. 

Problem: Gefahr des Verhungerns von Prozessen mit niedriger Priorität 

Lösung: Erhöhung der Priorität von lange wartenden Prozessen, d.h. 

dynamische Prioritäten. 

¯ Dynamische Prioritätenvergabe 

die Prioritäten der Prozesse können sich dynamisch verändern, d.h. sie werden 

in gewissen Zeitabständen neu berechnet. 

Idee: lange Wartezeiten berücksichtigen (Erhöhen die Priorität). 

Prozesse mit großem CPU-Verbrauch sinken in Priorität. 

E/A-intensive Prozesse steigen in Priorität (damit E/A-Geräte und CPU 

parallel genutzt werden). 

¯ Zeitscheibenstrategien und Prioritätenvergabe können zu effizienten Verwaltungsstrategien 

kombiniert werden. Beispielsweise können Prozesse in Prioritätsklassen 

gruppiert werden. Innerhalb einer Gruppe wird die Zeitscheibenstrategie 

verwendet. Beispielweise können 4 Prioritätsklassen eingerichtet werden, 

wobei die Klasse 4 die höchste Priorität hat. Solange Prozesse in der 

Klasse 4 sind, werden diese jeweils im Zeitscheibenverfahren ausgewählt. Falls 

die Klasse 4 leer, werden Prozesse der Klasse 3 ausgewählt usw. Prozesse 

müssen dynamisch den Klassen zugeordnet werden, damit nicht Prozesse der 

untersten Klasse verhungern. 

First-Come First-Served 

Dieses nicht-unterbrechende Verfahren (FCFS) teilt einen Prozessor in der 

Reihenfolge des Auftragseingangs zu. Ready-Queue wird als FIFO-Liste 

verwaltet; Verfahren einfach zu realisieren. 

¯ Ein Kontextwechsel findet nur statt, wenn der Prozess eine blockierende 

Systemfunktion aufruft oder der Prozess die CPU freiwillig abgibt. Im letzten 

Fall wird der Prozess sofort wieder am Ende der Ready-Queue eingereiht. Im 

ersten Fall wird der Prozess nach Ende der Blockierungsursache wieder am 

Ende der Ready-Queue eingereiht. 

¯ Es kann eine hohe CPU Auslastung erreicht werden. 

143


¯ Problem: Durchschnittliche Wartezeit ist hoch. 

Beispiel: Prozesse P1,P2,P3 kommen nahezu gleichzeitig zum Zeitpunkt 0 

an; 

Dauer ihrer Berechnungszeiten: P1: 24 ms, P2: 3ms, P3: 3ms; 

bei Reihenfolge P1, P2, P3: mittlere Wartezeit: (0 + 24 + 27)/3 = 17 ms 

bei Reihenfolge P2, P3, P1 mittlere Wartezeit (0+3+6)/3 = 3 ms 

Shortest-Jobs-First 

Dieses Verfahren (SJF) führt die Prozessorzuteilung in der Reihenfolge der 

wachsenden Rechenphasen ("CPU-Burst") zu, d.h. Prozess mit kürzester, 

nächster Rechenphase erhält Prozessor als nächster. Das Verfahren ist nur bedingt 

realisierbar, da die Länge des nächsten CPU-Bursts a priori nicht bekannt ist. 

In der Praxis wird daher eine Approximation eingesetzt, die auf der Basis der 

gemessenen Länge der zurückliegenden Bursts und einem Schätzwert für den 

nächsten Burst ermittelt wird. 

¯ anwendbar, falls die Dauer der nächsten Rechenphase bis E/A-Befehl, Interrupt 

etc. bekannt ist. 

¯ Beispiel: P1: 6ms, P2: 8ms, P3: 7ms, P4: 3ms 

Schedule bei SFJ : P4, P1, P3, P2; Wartezeit: (3+16 +9 +0) /4 = 7 ms 

bei FCFS: 10.25 ms (P1 vor P2 vor P3 vor P4) 

¯ Problem: Kenntnis über die Bedienzeiten erforderlich. Für Stapelbetrieb 

geeignet, da dort Information über Rechenzeiten zur Verfügung stehen 

(Benutzer geben bei Batch-Jobs Rechenzeit an). Für SJF gibt es wieder 

nicht-unterbrechende und unterbrechende Varianten. Im letzteren Fall wird 

ein Prozess unterbrochen, falls ein Prozess rechenwillig, dessen nächste 

Rechenphase kürzer ist als die noch verbleibende Rechenzeit des momentan 

rechnenden Prozesses. 

Animation Scheduling 


4.4.3 Beispiel Unix Scheduling 

Beim Unix-Scheduling handelt sich um eine Zeitscheibenstrategie mit dynamischer 

Prioritätenvergabe. Unix vergibt für seine Prozesse Prioritäten von 0 - 127 

(0 ist die höchste Priorität), die in 32 Warteschlangen verwaltet werden. Alle 

144


Prozesse einer Prioritätsklasse befinden sich in einer Warteschlange, die nach einer 

Round-Robin Strategie abgearbeitet wird. Zunächst wird allen Prozessen der 

höchsten Priorität die CPU zugeteilt bis die Warteschlange leer ist. Dann kommen 

die Prozesse mit der nächstniedrigeren Priorität zum Zuge. Die Prioritäten werden 

fortlaufend neu berechnet (multilevel-feedback-queue). Die Prioritäten der 

Prozesse, die in einem gewissen Zeitabschnitt viel Rechenzeit verbraucht haben, 

werden erniedrigt; Prozesse, die lange gewartet haben, erhalten eine höhere Priorität. 

¯ Zeitscheibenstrategie pro Warteschlange bis Warteschlange leer; dann Scheduling 

mit nächst niedrigerer Warteschlange. 

¯ dynamische Berechnung der Prozesspriorität: 

ÙÔÖÓ ÍËÊÈÊÁÇ Ô ÔÙ ÔÒ 

p_cpu ist die Prozessornutzung des rechnenden Prozesses und wird alle 10 ms 

um 1 inkrementiert. 

p_nice ist ein vom Benutzer bestimmter Gewichtungsfaktor (-20 p_nice 

20). 

USER_PRIO ist die Priorität, die dem Prozess beim Start zugeteilt worden ist. 

Der Wert von p_cpu wird jede Sekunde angepasst 

Ô ÔÙ ÐÓ ÐÓ Ô ÔÙ ÔÒ 

load ist eine Abschätzung der CPU-Auslastung. 

Die Anpassung (2) sorgt dafür, dass die bisher verbrauchte Rechenzeit nach 

einer gewissen Zeit nicht mehr ins Gewicht fällt. Das "short-term-scheduling" 

unterstützt das interaktive Arbeiten am Rechner. Die Prioritäten von Prozessen, 

die lange auf die Ausführung von E/A-Operationen warten, werden erhöht. 

Dagegen werden die Prioritäten von Prozessen, die wesentliche CPU-Zeiten auf 

sich vereinigen, verringert. Dies bedeutet zusammenfassend, dass ”interaktive” 

Prozesse den ”Batch”-Prozessen vorgezogen werden. 

4.4.4 Thread Scheduling 

Die Prozessorzuteilung von Threads hängt von deren Art der Realisierung 

(siehe Seite 137) ab. 

User-Threads 

Realisierung der Threads im Benutzeradressraum Kern hat keine Kenntnis 

bzgl. der Threads. BS-Scheduler wählt nur Prozess aus. Laufzeitsystem des 

145


Prozesses wählt rechenwilligen Thread des Prozesses aus; es kann ein beliebiges 

Scheduling-Verfahren (siehe Seite 141) für Prozesse verwendet werden. Da 

auf der Ebene des Laufzeitsystems keine Zeitunterbrechungen (clock interrupts) 

bearbeitet werden (sie werden auf Betriebssystem-Ebene bearbeitet), können 

Threads so lange laufen, bis sie selbst die CPU freiwillig aufgeben, d.h. ein 

Thread kann vom Laufzeitsystem aufgrund des Ablaufs einer Zeitscheibe nicht 

unterbrochen werden. 

¯ Java Virtual Machines verwenden unterbrechendes Prioritäten-Scheduling für 

Threads; 

10 ist die höchste und 1 die niedrigste Priorität; 

Ein rechenwilliger höher priorer Thread führt zur Unterbrechung eines 

rechnenden niedriger prioren Thread ("unterbrechender Scheduler"). 

Weiterhin kann ein Thread auch freiwillig die CPU aufgeben ("cooperative 

scheduler"). Probleme treten auf, wenn Threads die gleiche Priorität haben. 

Falls ein cooperative Scheduler verwendet wird, ist der aktuelle Thread 

solange rechnend, bis er freiwillig die CPU aufgibt. Falls er dies nicht 

macht, sind die anderen rechenwilligen Threads nur wartend (Gefahr des 

Verhungerns). 

Ein unterbrechender Thread-Scheduler wird in gewissen Zeitabständen 

den aktuell rechnenden Thread unterbrechen, und andere Threads gleicher 

Priorität auswählen. 

Das Ablauf-Verhalten hängt vom Scheduling Verfahren der jeweiligen JVM 

Implementierung ab, z.B. Windows verwendet unterbrechendes Thread 

Scheduling, während der Mac cooperative Thread Scheduling realisiert 

(möglicherweise anders bei MacOS 10). 

Kernel-Threads 

Realisierung der Threads im Systemadressraum 

nächsten auszuführenden Thread aus. 

BS-Scheduler wählt den 

a) Ist ausgewählter Thread demselben Prozess zugeordnet wie der vorher 

rechnende Thread geringer Kontextwechsel. 

b) Ist ausgewählter Thread nicht demselben Prozess zugeordnet wie der 

vorher rechnende Thread aufwendiger Kontextwechsel. In diesem 

Fall findet auch ein Adressraumwechsel statt, d.h. 

Speicherabbildung müssen angepasst werden. 

die Register zur 

146


4.4.5 Mehrschichtiges Scheduling 

Der Scheduler wählt einen der rechenwilligen Prozesse aus. Da diese aber u.U. 

nicht alle im Arbeitsspeicher vorliegen (Speicherknappheit) und ein Einlagern 

eines Prozesses von der Platte in den Arbeitsspeicher aufwendig ist, verfügen 

Systeme häufig über ein Mehr-Schichten Scheduling. 

¯ Short-Term-Scheduler (CPU Scheduler) 

Auswahl eines geeigneten Prozesses aus der Ready-Queue; wird häufig 

aufgerufen; Verfahren siehe oben. 

¯ Long-Term-Scheduler 

Auswahl rechenwilliger neuer Aufträge (meist Jobs aus dem Hintergrundbetrieb 

(batch)) und Einlagerung in den Arbeitsspeicher; Einfügen der Prozesse 

in die Ready-Queue. Scheduler kontrolliert den Multiprogramming-Grad, d.h. 

wieviele Prozesse im Arbeitsspeicher liegen. Long-Term-Scheduler wird relativ 

selten aufgerufen. Wenn ein Prozess das System verläßt, wird dieser Scheduler 

u.U. erst nach mehreren Minuten aufgerufen. 

Kriterium: guten Prozessmix erzielen, d.h. Mischung aus E/Aintensiven 

und rechenintensiven Prozessen (nur E/A-intensiv: Ready- 

Queue häufig leer, CPU nicht ausgelastet, andersherum: E/A-Geräte 

schlecht ausgelastet). 

Long-term Scheduling ist nicht immer vorhanden: z.B. in Unix nicht, jeder 

neue Prozess wird in Arbeitsspeicher geladen. Eine andere Zwischenstufe ist 

Medium-term-Scheduling: bei Überlast werden Prozesse auf Hintergrundspeicher 

ausgelagert (swap out) und später wieder eingelagert (swap in). 

¯ Graphische Darstellung 

147


swap-in 

Long-term 

Scheduler 

Ready Queue 

CPU Scheduler 

E/A-Warteschlange 

Zeit-Interrupt- 

Warteschlange 

Ausführung im 

BS-Kern 

4.4.6 Echtzeit Scheduling 

ausgeswappte 

Prozesse 

neue 

Aufträge 

swap-out 

CPU fertig 

E/A-Befehl 

Zeitscheibe 

abgelaufen 

sleep-Befehl 

Systemaufruf 

In Multimedia-Umgebungen treten die zu verarbeitenden kontinuierlichen Daten 

(Empfangen, Dekodierenen und Anzeigen von Videoframes) in bestimmten, 

meist periodischen Zeitabständen auf. Die Operationen auf diese Daten 

wiederholen sich dabei immer wieder und sollen bis zu einem gewissen 

Zeitpunkt abgeschlossen sein. Prozesse in Multimedia-Anwendungen führen 

oft zeitkritische Operationen aus. Bzgl. des Scheduling existieren zwei 

gegensätzliche Ziele: 

148


a) ein unkritischer Prozess sollte nicht dauerhaft blockiert werden, weil 

zeitkritische Prozesse eine Ressource gänzlich auslasten. Daher sollten 

zeitkritische Prozesse und Verwaltungsarbeiten nicht die gesamte Kapazität 

einer Ressource beanspruchen. 

b) zeitkritische Prozesse dürfen nicht durch Scheduling-Verfahren (Round- 

Robin oder Prioritäten) am zeitkritischen Fortschritt gehindert werden 

Einhaltung von Zeitvorgaben. 

¯ Zuordnung von Kenngrößen zu zeitkritischen Prozessen 

Bereitzeit (ready time): frühestmöglicher Ausführungsbeginn einer 

Aktivität. 

Frist (deadline): spätester Zeitpunkt für die Beendigung einer Aktivität. 

Ausführungszeit: worst-case Abschätzung für das zur vollständigen 

Ausführung einer Aktivität notwendige Zeitintervall. 

In vielen Fällen werden Aktivitäten periodisch ausgeführt. Deshalb werden 

hierzu neben der Ausführungszeit Kenngrößen wie Frequenz der Aktivität 

(Periode) und Versatz des Ausführungsbeginns relativ zum Anfang der Periode 

(Phase) erfasst. 

¯ Earliest Deadline First (EDF) 

Der Prozessor wird immer dem Prozess mit der am nächsten in der Zukunft 

liegenden Frist zugeordnet. Es existieren die beiden Varianten: nichtunterbrechend 

und unterbrechend. Fasst man die Fristen als Prioritäten 

auf, dann entspricht dieses Verfahren im Prinzip dem prioritäten-basierten 

Scheduling. 

– nicht-unterbrechend 

Eine Prozessorzuordnung bleibt bis der Prozess eine blockierende Systemfunktion 

aufruft oder freiwillig die CPU abgibt. Neue eintreffende Prozesse 

mit kürzeren Fristen werden erst beim nächsten Scheduling berücksichtigt. 

– unterbrechend 

Diese Variante führt einen Kontextwechsel durch, wenn ein Prozess mit 

einer kürzeren Frist rechenwillig wird. Man kann zeigen, dass die 

preemptive Variante immer eine Abarbeitungsreihenfolge mit Einhaltung 

aller Zeitvorgaben findet, solange mindestens eine solche Reihenfolge 

existiert. 

¯ Rate-Monotonic Scheduling 

Rate-Monotonic Scheduling (RMS) ist für periodische Prozesse; RMS ordnet 

Prioritäten in Abhängigkeit von der Periode zu. 

149

Schlichter, TU München 4.5. UNTERBRECHUNGSKONZEPT 

1) Prozesse mit der höchsten Frequenz (kleinste Periode) erhalten die 

höchste Priorität. 

2) Prozesse mit der geringsten Frequenz (längste Periode) erhalten die 

niedrigste Priorität. 

Die Priorität ist statisch; sie ändert sich nicht für den Rest der Prozesslaufzeit. 

Prioritäten geben die relative Wichtigkeit eines Prozesses gegenüber der 

Wichtigkeit anderer Prozesse im Rechensystem wider. RMS ist relativ einfach 

zu handhaben und sie erlaubt eine Abschätzung, ob eine Echtzeitanwendung 

auf einer bestimmten Rechenanlage ohne Fristverletzung ausgeführt werden 

kann oder nicht. 

– Auswahl der Prozesse anhand ihrer Priorität. Jedoch auch unter Berücksichtigung 

der anderen Kenngrößen, wie z.B. Bereitzeit. 

– hochfrequente Prozesse werden minimal verzögert. 

– Zerstückelung niederfrequenter Prozesse, da sie häufig wegen hochfrequenter 

Prozesse unterbrochen werden. 

4.5 Unterbrechungskonzept 

Die optimale Ausnutzung und Auslastung aller Geräte eines Rechensystems legt 

Mehrprogrammbetrieb nahe. Zerlegung der Ausführungsphasen eines Programms 

in viele Einzelteile; 

- Aufbrechen der Ausführung eines Prozesses in mehrere Phasen: u.a. 

Rechnen, E/A, Synchronisieren mit Partner. 

- Die Ausführung der Programme wird in der Regel mehrfach unterbrochen. 

4.5.1 Motivation 

Ursachen für Unterbrechungen 

zugeteilte Prozessorzeit ist aufgebraucht; 

benötigte Ressourcen stehen aktuell nicht zur Verfügung; 

ein E/A-Gerät meldet sich zurück; 

ein Fehler tritt auf, z.B. Division durch 0; 

Systemaufruf (wurde bereits als spezielle Unterbrechung eingeführt); 

¯ Bei einer Unterbrechung wird ein gerade aktiver Prozess unterbrochen 

und eine Unterbrechungsbehandlung durchgeführt. Nach Beendigung der 

Unterbrechungsbehandlung kann prinzipiell ein beliebiger rechenbereiter 

Prozess fortgesetzt werden. 

150


¯ Es ist erforderlich, bei der Unterbrechung den Rechnerkernstatus des gerade 

aktiven Prozesses für die spätere Fortsetzung zu speichern. Als Minimum ist 

dabei der Befehlszähler und das Programmstatuswort zu retten, da diese bei 

der Einstellung des neuen Zustandes bei der Unterbrechungsausführung im 

Rechnerkern verändert werden. Weitere Zustandsinformation wird dann in der 

Unterbrechungsbehandlung des Betriebssystems gerettet. 

¯ Forderung: Eine Unterbrechung muss so kontrolliert erfolgen, dass ein 

definierter Prozessstatus festgehalten werden kann. 

4.5.2 Unterbrechungsarten 

Die normale Programmausführung eines Prozessors kann auch durch mehrere 

Arten von Unterbrechungen verändert werden. Man unterscheidet zwischen 

synchronen und asynchronen Unterbrechungen. 

Trap 

Unterbrechung 

synchron asynchron 

Alarme 

(Exception) 

Externe, asynchrone Unterbrechungen 

Interrupt 

Dies sind Unterbrechungen (Interrupts), die von außerhalb des zu unterbrechenden 

Prozesses ausgelöst werden, z.B. E/A-Kanal-"Endmeldung". Asynchrone 

Unterbrechungen sind Ereignisse im Rechensystem, die über besondere Steuerbusleitungen 

an den Prozessor weitergegeben werden. Asynchron bedeutet in 

diesem Kontext, dass der eintreffende Interrupt in keiner kausalen Beziehung zum 

aktuell ausgeführten Befehl steht. 

¯ Der Ablauf im Rechnerkern (RK) wird unterbrochen und eine Unterbrechungsanfangsbehandlung 

des Betriebsystemkerns wird aktiviert. 

151


E/A-Kanal 2 CPU (RK) BS-Kern 

Ende E/A 

Auftrag 

Interne, synchrone Unterbrechungen 

Unterbrechungsbehandlung 

(UBH) 

Dies sind Unterbrechungen (Alarme, Exceptions), die durch den zu unterbrechenden 

Prozess selbst ausgelöst werden, z.B. Division durch 0. Synchrone Unterbrechungen 

sind eine unmittelbare Folge der aktuellen Befehlsausführung. Sie 

können auch explizit durch einen speziellen Befehl (Trap) ausgelöst werden. Mit 

Hilfe von Traps werden Systemdienste im Betriebssystem aufgerufen. Im Fehlerfall 

spricht man auch von Alarmen ("exceptions"). 

¯ Der Ablauf im RK wird unterbrochen und eine Unterbrechungsanfangsbehandlung 

des Systemkerns wird aktiv. 

152


CPU (RK) BS-Kern 

Unterbrechung 

arithmetischer Alarm 


(UBH) 

4.5.3 Behandlung externer Unterbrechungen 

Synchrone und asynchrone Unterbrechungen haben hardwaremäßig die Speicherung 

des aktuellen Prozessorzustandes zur Folge und lösen im Anschluss 

daran einen indirekten Sprung über eine im Speicher befindliche Sprungtabelle 

aus. Dabei ordnet der Prozessor jeder synchronen und asynchronen Unterbrechung 

einen festen Index in der Sprungtabelle zu. An dieser Stelle steht die 

Anfangsadresse der Unterbrechungsroutine, die entsprechende Folgemaßnahmen 

einleitet. Falls möglich (Ausnahme ist z.B. ein arithmetischer Alarm) kann die unterbrochene 

Programmausführung durch die Wiederherstellung des gespeicherten 

Prozessorzustandes zu einem beliebigen, späteren Zeitpunkt fortgesetzt werden. 

Ablauf 

¯ Geräte-Controller meldet Unterbrechung über spezielle Interrupt-Leitung an 

CPU. 

¯ CPU prüft im Befehlszyklus nach jeder Befehlsausführung, ob eine Unterbrechung 

gemeldet wurde. 

¯ Falls Unterbrechung vorliegt: sichern u.a. des aktuellen Befehlszählers, des 

Programmstatusworts und Sprung zu einer Unterbrechunganfangsbehandlung, 

die an festgelegter Speicheradresse steht. Die restlichen Informationen, wie 

Register, werden dann von der Unterbrechungsbehandlung gesichert. 

153


Routine untersucht Unterbrechungsursache, die vom Controller über 

Datenleitung gemeldet wird (Unterbrechungsnummer). 

über Unterbrechungsnummer erfolgt die Auswahl der benötigten Unterbrechungsbehandlungsroutine; 

Nummer ist i.a. Index in eine Tabelle, dem 

Unterbrechungsvektor. 

Vektor enthält Speicheradresse der Unterbrechungsbehandlungsroutine. 

4.5.4 Konflikte 

Konflikte bei Unterbrechungen treten z.B. in folgenden Situationen auf: 

(1) während einer Unterbrechungsbehandlung treten weitere Unterbrechungen 

auf; 

(2) es treffen gleichzeitig mehrere Unterbrechungswünsche ein. 

¯ Beispiel 

E/A-Kanal 1 und E/A-Kanal 2 erledigen beide Aufträge für Prozess A. 

E/A-Kanal 1 Prozess A BS-Kern E/A-Kanal 2 

externe 

Unterbrechung 

Ende E/A 

Auftrag 

¯ Mögliche Konfliktlösungen 


(UBH) 

Konflikt 

externe 

Unterbrechung 

Ende E/A 

Auftrag 

– Andere Unterbrechungen nicht zulassen, d.h. Maskierung von Unterbrechungen; 

anstehende Unterbrechung ignorieren oder vorläufig zurückstellen; 

Problem: u.a. Rechtzeitigkeit der Unterbrechungsbehandlung. 

154


– Interne Unterbrechungen erfolgen stets sofort und geben der zugehörigen 

Unterbrechungsbehandlung dieselbe Priorität, wie sie der unterbrochene 

Ablauf hatte. Die Benutzerprozesse haben die niedrigste Ablaufpriorität, 

nämlich 0. Unterbrechungen von Unterbrechungsbehandlungen sind 

möglich. 

– Externe Unterbrechungen erhalten Prioritäten z.B. (0,...,31) zugeordnet. Die 

aufgerufene Unterbrechungsbehandlung erhält die Priorität (Ablaufpriorität) 

der auslösenden Unterbrechung. 

Eine weitere externe Unterbrechung wird während einer Unterbrechungsbehandlung 

zugelassen, wenn die Priorität der neuen Unterbrechung 

höher als die Ablaufpriorität der gerade aktiven Unterbrechungsbehandlung 

ist. Trifft dieser Fall nicht zu, so wird der Unterbrechungswunsch 

zurückgestellt, bis ein Ablauf mit einer niedrigeren 

Ablaufpriorität aktiv wird. 

Konsequenz: Unterbrechungsroutinen müssen ablaufinvariant sein! 

¯ Integration der Unterbrechungsbehandlung in den Befehlszyklus der CPU 

prüfen ob interne Unterbrechung aufgetreten, 

falls ja, Behandlung der Unterbrechung 

sonst : prüfen ob externe Unterbrechung mit höherer Priorität. Wenn ja 

wähle eine mit höchster Priorität. 

Bei Unterbrechung: sichere alten Zustand, stelle neuen Zustand her und 

führe ersten Befehl der Unterbrechungsbehandlungsroutine aus. 

¯ Beispiel: Festlegungen in der MI 

Die Anzahl und die Anfangsadressen der Unterbrechungsbehandlungen sind 

vom jeweiligen Betriebssystem abhängig. Ein Systemkontrollblock (SCB) 

enthält Startadressen der Unterbrechungsbehandlungsroutinen. Die Adresse 

des SCB wird in einem Register des RK, dem Sonderregister SCBADR, 

gehalten. 

155


U-Nr. Relativadresse U-Priorität Art der Unterbrechung 

1 +0 31 katastrophaler 

Fehler 

2 +4 übernommen Befehlsalarm 

3 +8 übernommen Speicherschutzalarm 

4 +12 übernommen Seite-fehlt-alarm 

5 +16 übernommen Trace 

6 +20 übernommen arithmetischer 

Alarm 

7 +24 übernommen CHMK 

temaufruf)(Sys- 

8 +28 übernommen - (reserviert) 

9 +32 25 Rechnerkernalarm 

10 +36 24 Weckeralarm 

11 +40 23 von 

icherPlattenspe- 

12 +44 22 von Kanal 0 

Empfänger 

13 +48 22 von Kanal 0 

Sender 

14 +52 21 von Kanal 1 

Empfänger 

15 +56 21 von Kanal 1 

Sender 

16 +60 20 von Kanal 2 

Empfänger 

17 +64 20 von Kanal 2 

Sender 

18 +68 19 von Kanal 3 

Empfänger 

19 +72 19 von Kanal 3 

Sender 

Anmerkung 1: Die Unterbrechungsnummern und die Unterbrechungsprioritäten 

stehen nicht im Systemkontrollblock, sondern sie sind den Unterbrechungen 

implizit zugeordnet. Anmerkung 2: Das "Tracing" ist eine Testhilfe auf 

sehr niederer Ebene. Ist "Tracing" eingestellt, dann wird nach jedem Maschinenbefehl 

der Rechnerkern unterbrochen und eine Unterbrechungsbehandlung 

aufgerufen. In dieser UBH kann dann der Status des Rechnerkerns, insbeson- 

156


dere die Werte in den Registern, abgefragt oder ausgedruckt werden. Das 

"Tracing" ist sehr zeitaufwendig und sollte daher auf die nicht getesteten Befehlsfolgen 

im Benutzerprogramm beschränkt werden. Daher wird das "Tracing" 

automatisch ausgeschaltet, während Systemdienste oder allgemeiner Unterbrechungen 

im Systemkern ausgeführt werden, da diese Teile getestet sind 

und da der Benutzer diese Befehlfolgen ohnehin nicht kennt. 

157

Kapitel 5 

Speicherverwaltung 

Der Adressraum ist eine zentrale Abstraktion, die von der Systemsoftware eines 

Rechensystems zur Verfügung gestellt werden muss. Über den Adressraum sind 

alle für die Ausführung eines Anwendungsprogramms notwendigen Operationen 

und Datenstrukturen zugreifbar. Allgemein wird ein Adressraum durch eine 

zusammenhängende Menge von Adressen und deren Inhalte definiert. Die 

maximale Größe eines Adressraums kann aus dem Adressbusaufbau der 

verwendeten Prozessorarchitektur abgeleitet werden. Modernde Rechensysteme 

unterscheiden zwischen den Adressräumen der Programme und dem physischen 

Adressraum (Arbeitsspeicher). 


Dieser Abschnitt beschäftigt sich mit den Adressräumen für Programme und 

deren Abbildung auf den physischen Arbeitsspeicher einer Rechenanlage: 

¯ Programmadressraum vs. Maschinenadressraum. 

¯ Direkte Adressierung, Basisadressierung. 

¯ Virtualisierung des Speichers; virtuelle Adressierung, insbesondere Seitenadressierung. 

5.2 Einführung 

Die unmittelbare Nutzung des physischen Adressraums (Arbeitsspeichers) bei der 

Anwendungsentwicklung ist nicht empfehlenswert. Probleme sind folgende: 

158

Schlichter, TU München 5.2. EINFÜHRUNG 

- Kenntnisse über Struktur und Zusammensetzung des Arbeitsspeichers 

notwendig. 

- Kapazitätsengpässe bei der Arbeitsspeichergröße. Werden die in einem 

Rechensystem bei der Befehlsausführung durch den Rechnerkern auftretenden 

Adressen direkt als reale Speicheradressen interpretiert, so kommt man 

schnell in Kapazitätsengpässe. Die Kapazität des Arbeitsspeichers reicht oft 

nicht aus, um alle Daten darin abzulegen. Deshalb weicht man auf den Hintergrundspeicher 

(Platte) aus, um Teile der Daten eines Prozesses dort abzulegen. 

deshalb Programmerstellung unabhängig von realer Speichergröße und - 

eigenschaften. Abstrahieren von realen Eigenschaften der Hardware. Die 

Handhabung der unterschiedlichen Speicher sollte für die Programmierung 

in höheren Programmiersprachen ohne Belang sein, d.h. der Programmierer 

soll sich nicht explizit um das Nachladen von benötigten Daten vom 

Hintergrundspeicher in den Arbeitsspeicher und umgekehrt kümmern 

müssen. Dies soll automatisch, d.h. transparent für den Programmierer 

geschehen. 

5.2.1 Adressräume 

¯ Maschinenadressraum 

Der Arbeitsspeicher besteht aus einer Folge von fortlaufend nummerierten 

Bytes. Die Nummerierung beginnt bei 0. Die Nummer des Bytes bezeichnet 

man als seine Adresse, genauer als seine physische Speicheradresse oder seine 

Maschinenadresse. 

Die Menge der möglichen Maschinenadressen ist der Maschinenadressraum 

(physischer Adressraum). Man beachte, dass bei der speicherbasierten E/A- 

Architekturvariante (siehe MI) die Register der E/A-Controller auch über 

Maschinenadressen angesprochen werden, d.h. nicht jeder Maschinenadresse 

ist eine Speicherzelle im Arbeitsspeicher zugeordnet. 

¯ Programmadressraum 

Wenn ein Benutzer programmiert, dann benutzt er in seinem Programm 

Adressen, um seine Variablen zu bezeichnen. Diese Adressen nennen wir 

Programmadressen. 

Die Menge der zulässigen Programmadressen ist der Programmadressraum. 

Dieser ist prozessspezifisch, d.h. Programmadressen haben nur Programmlokale 

Bedeutung z.B. als Sprungziele. 

¯ Speicherabbildung 

159


Der Rechnerkern muss vor jedem Zugriff auf Befehle und Operanden 

die jeweiligen Programmadressen in Maschinenadressen umsetzen. Diese 

Umsetzung wird durch Speicherabbildungen geleistet. Die wichtigsten dieser 

Abbildungen werden in den folgenden Abschnitten kurz vorgestellt. 

direkte Adressierung, 

Basisadressierung, 

Seitenadressierung und 

Segment-Seitenadressierung. 

5.2.2 Organisation von Adressräumen 

Im Adressraum einer Anwendung müssen alle für die Programmausführung 

notwendigen Daten zur Verfügung gestellt werden. Darunter fallen der Programmcode 

(Text), der Datenbereich (statische und dynamische Daten) und der 

Laufzeitkeller. Für jede dieser Informationsarten wird ein Bereich im Adressraum 

spezifiziert, deren Platzierung und Größe durch die Adressraumverwaltung 

festgelegt wird. 

¯ Single-Threaded Adressraum 

niedrige 

Adresse 

Programm 

statische 

Daten 

dynamische Daten 

(Halde) 

Keller 

hohe 

Adresse 

Die Bereiche Programmcode und statische Daten verändern sich typischerweise 

während der Programmausführung nicht. Dagegen können der dynamische 

Datenbereich (Halde) und der Laufzeitkeller an Umfang erheblich zunehmen. 

Beim Laufzeitkeller hängen Größenschwankungen und Ausdehnung von der 

maximalen Tiefe der Prozedur/Methodenschachtelung und dem Bedarf an 

lokalen Variablen ab. 

¯ Multi-Threaded Adressraum 

160


niedrige 

Adresse 

Programm 

statische 

Daten 

dynamische Daten 

(Halde) 

Keller 1 

Keller n 

hohe 

Adresse 

Für jeden Kontrollfluss (Thread) wird ein eigener Kellerbereich vorgesehen. 

Der Abstand zwischen den einzelnen Kellern wird meist standardmäßig vom 

System vorgegeben. Unabhängig von der Anzahl der Laufzeitkeller muss 

eine Überschneidung zwischen mehreren Kellern oder zwischen dem untersten 

Keller und der Halde vermieden werden. 

¯ Beispiel - Adressräume 

Moderne Betriebssysteme stellen wenigstens 32 Bit große virtuelle Adressräume 

für die Anwendungen zur Verfügung, die jeweils in mehrere Bereiche 

unterteilt sind. Programmcode, statische Daten, Halde und Laufzeitkeller der 

Anwendung werden jeweils in dem Bereich des Adressraums abgelegt, der der 

Anwendung zugänglich ist. 

4.4 BSD Unix 

Windows 95 

Windows NT 

0 1 GByte 

2 GByte 

3 GByte 

4 GByte 

spezieller Adressbereich (Größe nicht proportional) 

161


Der für die Anwendung nutzbare Adressbereich (weißer Bereich) schwankt 

zwischen ca. 2 GByte und 4 GByte. Bei allen BS wird ein unterschiedlich 

großer Adressbereich am Anfang (Adressen 0 und aufwärts) für jeglichen 

Zugriff gesperrt: bei Windows 95 sind es 4 KByte, bei Windows NT 64 

KByte, bei BSD Unix ist es abhängig vom Rechnertyp (4 - 8 KByte). Durch 

diese Sperrung wird jeder Zugriff auf diesen Bereich und damit insbesondere 

das Dereferenzieren eines Nullzeigers vom System abgefangen und die 

Programmausführung mit einer Fehlermeldung abgebrochen. In Windows 95 

wird zusätzlich der Adressbereich von 4 KByte - 4 MByte von der Nutzung 

durch 32 Bit Anwendungen ausgeklammert (Adressbereich für MS-DOS 

bzw 16 Bit Anwendungen). Im oberen Bereich des virtuellen Adressraums 

wird meist der Betriebssystemcode eingeblendet (z.B. bei Windows 95 im 

Bereich 1 GByte - 2 GByte; dadurch können BS-Funktionen auch ohne 

Adressraumwechsel genutzt werden. Bei BSD Unix und Windows NT/2000 ist 

dieser Bereich vor jeglichem Zugriff durch die Anwendung geschützt (oft wird 

sogar lesender Zugriff unterbunden). Bei Windows 95 besteht dieser Schutz 

nicht, d.h. Anwendungen können das Betriebssystem zum Absturz bringen. 

5.2.3 Fragmentierung 

Unter dem Begriff Fragmentierung versteht man verschiedene Formen der 

Zerstückelung des noch freien und nutzbaren Teils des Adressraums in kleine 

Bereiche. Fragmentierung kann jedesmal dann entstehen, wenn eine neue 

Speicherplatzanforderung aus der Menge noch freier Speicherbereiche mit einem 

einzigen zusammenhängenden Bereich befriedigt werden muss. Unterscheidung 

zwischen externer und interner Fragmentierung. 

¯ Externe Fragmentierung 

Es wechseln sich benutzte und unbenutzte Speicherbereiche innerhalb des 

Adressraums ab. Speicheranforderungen werden jeweils genau erfüllt. 

162


Anforderung 

belegt belegt belegt 

belegt belegt belegt 

belegt 

freie Speicherbereiche 

Im Fall eines Anwendungsadressraums tritt dies beim dynamischen Datenbereich 

(Halde) auf; Fragmentierung entsteht durch die unterschiedlichen 

Speicheranforderungs- und Freigabemuster. Durch zeitaufwendiges Zusammenschieben 

der Belegtbereiche (Kompaktifizieren) entsteht aus vielen kleinen 

Speicherresten ein großer Freibereich. Beim Kompaktifizieren müssen u.U. die 

Adressen in den Programmen angepasst werden (z.B. Verweise auf Absolutadressen). 

¯ Interne Fragmentierung 

Der Speicher ist in Bereiche fester Größe untergliedert und Speicheranforderungen 

werden nur in Vielfachen dieser festen Grundgröße befriedigt. 

163


freier Speicherbereich 

Anforderung 

Der Verschnitt findet innerhalb dieser Bereiche fester Größe statt. Beispielsweise 

kann Plattenspeicher nur blockweise belegt werden; die Blockgröße 

schwankt zwischen 512 Byte und 4-8 Kbyte. Selbst für die Speicherung eines 

einzigen Bytes muss ein ganzer Block belegt werden. 

5.2.4 Forderungen an Adressraumrealisierung 

Aus der Sicht der Anwendungsprogrammierung können für einen Adressraum 

eine Reihe wichtiger Forderungen an dessen Realisierung gestellt werden. 

Hier geht es um den Programmieradressraum für Prozesse, und nicht um den 

Maschinenadressraum (Arbeitsspeicher). 

¯ Homogene und zusammenhängende Adressbereiche. Dies ermöglicht eine 

Programmentwicklung ohne das ansonsten notwendige Wissen über Position, 

Typ und Größe der referenzierbaren Speichermodule und E/A-Controller. 

¯ Größe des genutzten Adressraums unabhängig von der Kapazität des 

physischen Adressraums (Arbeitsspeichers). 

¯ Erkennen fehlerhafter Zugriffe. 

¯ Erkennen von Überschneidungen zwischen Halde und Keller sowie zwischen 

mehreren Laufzeitkellern. 

164

Schlichter, TU München 5.3. SPEICHERABBILDUNGEN 

¯ Schutz funktionstüchtiger Anwendungen gegenüber fehlerhaften Anwendungen. 

Hier geht es darum, dass die Adressbereiche der Anwendungen und auch 

des Betriebssystems voneinander abgeschottet werden. Ist dieser Schutz nicht 

gewährleistet, können fehlerhafte Programme den Adressraum einer anderen 

Anwendung verändern und damit Folgefehler in dieser auslösen nicht deterministische 

Fehler. Fehler dieser Art sind schwer zu reproduzieren und ihre 

Lokalisierung ist meist extrem schwierig und langwierig. 

¯ Kontrollierbares und kontrolliertes Aufteilen der Speicherressourcen auf alle 

Anwendungen. 

¯ Speicherökonomie, minimale Fragmentierung. Es sollten gängige Techniken 

eingesetzt werden, um die durch dynamische Anforderungen bedingte Speicherfragmentierung 

und den tatsächlichen Speicherbedarf jeder Anwendung 

zu minimieren, z.B. gemeinsame Nutzung von Funktionsbibliotheken durch 

mehrere parallel laufende Anwendungen Funktionsbibliothek muss nur einmal 

geladen werden. 

5.3 Speicherabbildungen 

Dieser Abschnitt behandelt einige Mechanismen zur Abbildung von Programmadressen 

auf Maschinenadressen des Arbeitsspeichers. 

5.3.1 Direkte Adressierung 

Bei der direkten Adressierung werden die Programmadressen direkt als 

Maschinenadressen interpretiert. Es treten drei Probleme auf: 

Verschiebbarkeit, 

Programmgröße, 

Speicherausnutzung. 

Verschiebbarkeit 

In einem Mehrprozesssystem sind i.d.R. mehrere Programme im Arbeitsspeicher. 

Bei direkter Adressierung werden die Programme beim Laden fixiert und müssen 

dann bis zu ihrem Ende an derselben Stelle bleiben. Eine Verschiebung 

ist nicht möglich, da der Benutzer mit Adressen rechnen kann und deshalb 

positionsabhängige Adressen in seinen lokalen Variablen hat. 

165


¯ Problem 

Externe Fragmentierung des Arbeitsspeichers. Sei der Arbeitsspeicher zunächst 

lückenlos mit Programmen P1, P2, P3 gefüllt. 

P1 P2 P3 

Nach Beendigung des Programms P2 entsteht eine Lücke. 

Neue Programme passen u.U. nicht exakt in die zurückgebliebene Lücke. 

Auf diese Weise entstehen immer mehr Lücken. Möglicherweise passen 

Programme nicht mehr in den Arbeitsspeicher, weil keine ausreichend große 

Lücken vorhanden ist, obwohl insgesamt noch ausreichend Platz wäre. Dies 

ist das Problem der externen Fragmentierung des Arbeitsspeichers. Da die 

Programme wegen der direkten Adressen nicht verschiebbar sind, ist eine 

Speicherbereinigung erst möglich, nachdem alle angefangenen Programme 

beendet sind. 

Ein verwandtes Problem tritt bei Programmverdrängungen auf. Das verdrängte 

Programm muss zur weiteren Ausführung später wieder an dieselbe Stelle 

geladen werden, dies ist jedoch in der Regel nicht mehr möglich, da andere 

Programme im benötigten Speicherbereich stehen können. 

¯ Forderung 

In Mehrprogramme/Mehrprozesssystemen müssen daher Programme verschiebbar 

sein. 

Programmgröße 

Programme können wesentlich größer als der verfügbare Arbeitsspeicher werden. 

Bei direkter Adressierung muss der Benutzer sein Programm selbst in Segmente 

zerlegen und diese nach Bedarf selbst nachladen. Man spricht von der 

sogenannten Overlay-Technik (veraltet). Die Overlay-Technik ist aufwendig, 

schwierig und damit auch fehleranfällig. Da die Zerlegung statisch ist, kann 

die Zerlegung des Programms nicht dynamisch an den konkret vorhandenen 

Arbeitsspeicher angepasst werden und damit die jeweilige Maschine gut 

ausnutzen. 

¯ Forderung 

Es muss daher gefordert werden, dass die Programmgröße unabhängig von der 

realen Arbeitsspeichergröße ist. 

166


Speicherausnutzung 

Programme bestehen aus Modulen, die nur zu bestimmten Zeiten verwendet 

werden. Beispielsweise wird bei einer Matrizenmultiplikation nur auf die Module, 

die das Multiplikationsprogramm und auf die Module, die die Daten enthalten, 

zugegriffen. Es ist nun wünschenswert, von einem Programm nur den Ausschnitt 

im Arbeitsspeicher zu halten, der momentan und in naher Zukunft benötigt wird. 

Damit lassen sich mehr Programme im Arbeitsspeicher unterbringen und parallel 

verarbeiten. Dies steigert den Datendurchsatz des Systems. 

¯ Forderung 

Arbeitsspeicher beinhaltet nur die momentan bzw. in naher Zukunft 

notwendigen Ausschnitte des Programms. Nutzen der Lokalitätseigenschaft 

von Programmen: 

durch Datenstrukturen z.B. Arrays, oder 

Programmstrukturen: Prozeduren, Schleifen. 

5.3.2 Basisadressierung 

Die Basisadressierung hat eine einfache Abbildungsvorschrift: 

Maschinenadresse = Basisadresse + Programmadresse 

¯ Die Basisadresse ist programmspezifisch. Sie steht in einem Register des 

Rechnerkerns und ist dem Programm, das im Benutzermodus abläuft, nicht 

zugänglich. Sie wird vom Betriebssystem festgelegt. 

¯ Die Programmadressen aller Programme beginnen jeweils mit Null. Durch die 

Basisadressierung wird das Problem der Verschiebbarkeit gelöst. Die anderen 

Probleme bestehen jedoch weiterhin. Deshalb wird die Basisadressierung in 

modernen Betriebssystemen nicht mehr eingesetzt. 

¯ Speicherverwaltungsstrategien 

Aufgabe: Finden eines zusammenhängenden Arbeitsspeicherbereichs, der groß 

genug ist, um das Programm zu speichern. Mögliche Strategien (siehe 

Seite 57) werden hier nur angerissen. Hier kommen die Strategien zum Einsatz, 

die bereits bei der Haldenverwaltung diskutiert wurden, insbesondere deren 

Vor- und Nachteile. Beispielsweise erfordert best-fit immer den Durchlauf 

durch die gesamte Freibereichsliste. Zusätzlich liefert diese Strategie mit der 

Zeit immer kleinere Fragmente externe Fragmentierung. 

167

Schlichter, TU München 5.4. VIRTUELLER SPEICHER 

– first-fit 

Durchsuche die Liste der Freibereiche vom Anfang an und nimm den ersten 

passenden Frei-Bereich: Spalte nicht benötigten Speicher ab und füge ihn als 

freien Bereich in die Freibereichsliste ein. 

– best-fit 

Durchsuche die Liste der Freibereiche vom Anfang an und nimm den 

passenden Frei-Bereich, der die Speicheranforderungen des Programms am 

besten erfüllt: Spalte nicht benötigten Speicher ab und füge ihn als freien 

Bereich in die Freibereichsliste ein. 

– worst-fit 

Durchsuche die Liste der Freibereiche vom Anfang an und nimm den Frei- 

Bereich, der die Speicheranforderungen des Programms am schlechtesten 

erfüllt: Spalte nicht benötigten Speicher ab und füge ihn als freien Bereich in 

die Freibereichsliste ein. 

5.4 Virtueller Speicher 

Die virtuelle Adressierung wurde Ende der 50er Jahre eingeführt. Viele 

weiterführende Arbeiten erfolgten dann später im Rahmen des Projektes MAC 

und des Systems MULTICS (Vorgänger von UNIX) in den USA in den 60er 

Jahren. Ziel ist 

Virtualisierung des Speichers, 

Verstecken von realen Beschränkungen, wie Speichergröße, 

Speicher als sehr großes Feld gleichartiger Speicherzellen zu betrachten. 

Die Seitenadressierung ("paging") ist die Grundform der virtuellen Adressierung. 

5.4.1 Seitenadressierung 

Ansatz 

Der Programmadressraum, der sogenannte virtuelle Adressraum eines Prozesses 

wird in aufeinanderfolgende Seiten (engl. page) gleicher Größe unterteilt. 

Man spricht deshalb von virtuellen Adressen des Prozesses, anstatt von 

seinen Programmadressen. Gängige Größen für virtuelle Adressräume heutiger 

Architekturen: 

2 32 , also 32-Bit Adressen zum Ansprechen der Speicherzellen. 

Fortgeschrittene Architekturen: 2 64 , also 64-Bit Adressen (z.B. Sun ULTRA- 

Sparc). 

168


Die Seiten sind keine logische Aufteilung des Speichers. Denkaufgabe: was hat 

das für Vor- und Nachteile? 

¯ Der Maschinenadressraum, also der physische Adressraum des Arbeitsspeichers, 

wird in Kacheln (engl. frame) unterteilt. Seiten und Kacheln sind i.d.R. 

gleich groß. Es ist auch möglich, dass die Seitengröße ist ein Vielfaches der 

Kachelgröße ist. Im Folgenden wird von gleichen Größen ausgegangen. Für 

die MI ist als Kachelgröße 512 Byte festgelegt. Dies ist für heutige Architekturen 

zu klein (eher4-8KByte). 

¯ Eigenschaften der Seitenadressierung 

– Die Seiten eines Prozesses können im Arbeitsspeicher oder auf dem 

Hintergrundspeicher (Platte) gespeichert sein. 

– Die Kacheln nehmen die Seiten der Prozesse auf. Wichtig ist, dass sowohl 

die Seiten als auch die sie aufnehmenden Container, die Kacheln, eine 

einheitliche Größe besitzen. Das erleichtert die Speicherverwaltungsaufgabe 

erheblich. 

– Wenn während der Prozessausführung eine virtuelle Adresse des Prozessadressraums 

verwendet wird, so muss die Seite, in der sich die Adresse 

befindet, in einer Kachel des Arbeitsspeichers geladen (eingelagert) sein. Es 

ist eine Abbildungsvorschrift notwendig, die die virtuelle Adresse auf die 

reale Kacheladresse (Maschinenadresse) abbildet. Ein Problem ist: 

woher weiss das BS welche Seite eines Prozesses sich wo im 

Arbeitsspeicher befindet, d.h. welche Kachel welcher Seite zugeordnet 

ist? 

Antwort: Beschreibung der Seiten erforderlich; dazu Verwendung von 

Deskriptoren, die in Tabellen verwaltet werden (Seiten-Kacheltabelle). 

– Die Zuordnung, welche Seite in welcher Kachel gespeichert ist, und wo sich 

die Seite auf dem Hintergrundspeicher befindet, erfolgt mittels der Seiten- 

Kacheltabelle, die die Seitendeskriptoren enthält. Die Zuordnung von Seite 

zu Kachel kann sich im Laufe eines Programmablaufes ändern. 

– Befindet sich bei einer Befehlsausführung die erforderliche Seite nicht im 

Arbeitsspeicher, so löst ein solcher Zugriff eine Unterbrechung aus 

Seitenfehler Einlagerung der Seite bei Bedarf ("Demand Paging"). Der 

Seitenfehler ist eine synchrone Unterbrechung, die vom Betriebssystem zu 

behandeln ist, d.h. die geforderte Seite ist in den Arbeitsspeicher zu laden. 

Man spricht deshalb auch vom Demand Paging. Nach dem erfolgreichen 

Laden der Seite wird der Befehl, der zum Alarm führte, erneut ausgeführt. 

Der gesamte Vorgang heißt Seiteneinlagerung (engl. paging). 

169


– Falls eine Seite eingelagert werden muss, aber gleichzeitig bereits alle 

Kacheln des Arbeitsspeichers besetzt sind, so muss eine der eingelagerten 

Seiten aus dem Arbeitsspeicher verdrängt werden. Man spricht von 

der Seitenauslagerung. Die Strategien, die man hierbei einsetzt, heißen 

Seitenersetzungsstrategien. Ziel dieser Strategien ist es, eine möglichst 

günstige Seite auszuwählen, und diese auf den Hintergrundspeicher 

auszulagern. Günstig bedeutet hier, eine Seite, die entweder für den 

Prozessablauf nicht mehr benötigt wird, oder die erst sehr viel später benötigt 

wird, als die anderen Seiten im Arbeitsspeicher. 

¯ virtueller Speicher - Arbeitsspeicher 

Der Zusammenhang zwischen dem virtuellen Speicher, hier den virtuellen 

Adressräumen der Prozesse, und dem Arbeitsspeicher sowie Hintergrundspeichermedien 

wird nachfolgend skizziert. Auf die einzelnen Bereiche gehen wir 

im Folgenden näher ein. Wir gehen hier vereinfachend davon aus, dass auch die 

Blöcke als Einheiten des Hintergrundspeichers die Größe einer Seite besitzen. 

virt. Adressraum von P1 

Seite 1 von 

P1 

Seite 2 von 

P1 

..... 

Seite 1 von 

P2 

Seite 2 von 

P2 

..... 

virt. Adressraum von P2 

Seiten-Kachel 

Tabelle 

... 

... 

... 

... 

... 

... 

... 

... 

Deskriptor 

Kachel 1 

Kachel 2 

Kachel 3 

Kachel 4 

Kachel 5 

... 


mit Kacheln 

Auslagern 

Einlagern 

Hintergrundspeicher 

mit Blöcken 

¯ Vorteile 

Bei der Seitenadressierung werden durch eine flexible Speicherabbildung alle 

Probleme der direkten Adressierung (siehe Seite 165) gelöst. 

Programme können: 

verschoben werden, 

größer als der Arbeitsspeicher sein, 

auch ausschnittsweise im Arbeitsspeicher sein. 

D.h. die 

170


– Zusätzliche positive Eigenschaften 

£ Es können gemeinsame Speicherbereiche zwischen Prozessen realisiert 

werden. Programme können gemeinsame Speicherbereiche haben, 

beispielsweise bei gemeinsamen Daten nebenläufiger Prozesse. Auch 

Code-Bereiche können im Hinblick auf eine bessere Speicherausnutzung 

gemeinsam sein, beispielsweise muss der Code eines Compilers nur 

einmal geladen werden, auch wenn ihn mehrere Benutzer gleichzeitig 

verwenden. 

£ Es ist ein differenzierter Zugriffsschutz innerhalb eines Prozesses möglich. 

Zugriffsrechte für einzelne Seiten können unterschiedlich vergeben 

werden. 

Adressabbildung 

Bei der Seitenadressierung erfolgt die Umsetzung der Programmadressen, also die 

Umsetzung der virtuellen Adressen in Maschinenadressen durch eine Abbildung 

von Seiten auf Kacheln. Eine virtuelle Adresse v ist gegeben durch v = (s, w), 

wobei s die Seitennummer und w das Offset in der Seite angibt. Die Adresse 

v wird abgebildet auf die reale Adresse p = (k, w), wobei k die Kachelnummer 

angibt, die die Seite enthält. 

Seitentabellenregister 

Längenregister 

L 

Seiten-Kacheltabelle 

k 

s 

virtuelle Adresse 

s w 

k w 

Adresse im Arbeitsspeicher 

Die Adressrechnung wird von der Hardware, der MMU (Memory Management 

Unit), durchgeführt. D.h. die virtuelle Adresse wird von der CPU nicht direkt 

auf den Speicherbus gelegt, sondern an die MMU (Chip oder mehrere Chips) 

weitergeleitet. Die MMU berechnet die reale Adresse und legt sie auf den Bus. 

Falls s L ist, kann mit Hilfe des Längenregisters sofort ein Adressierungsfehler 

171


entdeckt werden. 

¯ Beispiel für Adressrechnung 

Gegeben sei ein 16-Bit virtueller Adressraum und eine Seitengröße von 4K. 

D.h. der Adressraum zerfällt in 16 Seiten; man benötigt 4 Bit, um die 

Seitennummern zu identifizieren und 12-Bit, um die 4096 Byte innerhalb 

einer Seite zu adressieren. Die Anzahl der Bits von s (Seitennummer) und k 

(Kachelnummer) können sich unterscheiden. Die Zahl der Bits von s hängt von 

der Größe des virtuellen Adressraums ab, während sich die Anzahl der Bits 

von k aus der Größe des Maschinenadressraums ergibt. Damit können s und k 

unterschiedliche lang sein. 

v = 0 0 1 0 0 0 0 0 0 0 0 0 0 1 0 0 

s = 2 

p = 

present/ 

absent Bit 

0 010 1 

1 001 1 

2 110 1 

3 000 1 

4 100 1 

5 011 1 

6 000 0 

7 000 0 

8 000 0 

9 101 1 

10 000 0 

11 111 1 

12 000 0 

13 000 0 

14 000 0 

15 000 0 

Seiten- 

Kacheltabelle 

12 bit offset w 

wird kopiert 

1 1 0 0 0 0 0 0 0 0 0 0 1 0 0 

k = 6 

172



Die Adressabbildung erfolgt mittels der Seiten-Kacheltabelle (SKT). D.h. 

wir benötigen Informationen über die zu verwaltenden Seiten. Dazu wird 

jede Seite eines Prozesses durch einen Seitendeskriptor beschrieben. Die 

Seiten-Kacheltabelle ist i.a. prozessspezifisch. Neben der Zuordnung Seite- 

Kachel enthält ein Seitendeskriptor noch weitere Informationen, wie z.B. die 

Zugriffsrechte und den Zustand der Seite. 

¯ Struktur eines Seitendeskriptor 

Informationen in einem Seitendeskriptor: 

– Zugriffsrechte (R) 

Angabe, ob der Prozess 

- ausführend (x R), 

- lesend (r R), 

- schreibend (s R). 

auf die Seite zugreifen darf. Diese Information wird vom Betriebssystem 

eingetragen und im Rechnerkern vor dem Zugriff ausgewertet. 

– Seite existent (e) 

Es müssen nicht alle Seiten existent sein. Beispielsweise sind oft die 

Seiten zwischen Ende der Halde und Kellerende nicht existent. Generell 

besteht die Vorstellung, dass in einem Adressraum mehrere Objekte (Daten 

oder Programmteile) sind, zwischen denen Lücken liegen können. Seiten 

des Adressraums, in denen keine Objekte sind, sind nicht existent. Wird 

versucht, auf eine nicht existente Seite zuzugreifen, dann gibt es einen 

Speicherschutzalarm. 

– Seite geladen (v) 

Die Abbildung ist gültig (engl. valid ). Die Seite ist also in den 

Arbeitsspeicher geladen, d.h. ihr ist eine Kachel zugeordnet. Es kann auf 

sie zugegriffen werden. Eine nicht geladene, aber existente Seite steht im 

Verdrängungsbereich (engl. swap area) auf dem Plattenspeicher. Soll auf 

eine existente, aber nicht geladene Seite zugegriffen werden, dann löst die 

CPU einen Seitefehltalarm aus, d.h. ein Seitenfehler tritt ein. Die Seite 

wird vom Hintergrundspeicher geladen, und das Programm an der Stelle 

fortgesetzt, die den Seitefehltalarm auslöste. 

– Zugriffsbit (z) 

Das Zugriffsbit (engl. reference bit) dient zur Unterstützung der 

Seitenersetzungsalgorithmen. Es wird von der CPU nach dem Laden der 

Seite gelöscht und bei einem Zugriff auf eine Seite von der CPU gesetzt. 

173


– Veränderungsbit (m) 

Die Seite wurde verändert (modifiziert). Dieses Bit dient ebenfalls zur 

Unterstützung der Seitenersetzungsalgorithmen. Es wird nach dem Laden 

der Seite von der CPU gelöscht und nach einem schreibenden Zugriff auf die 

Seite gesetzt. Beispielsweise könnte eine Verdrängungsstrategie bevorzugt 

Seiten auslagern, die nicht modifiziert wurden, d.h. ein Übertragen der 

Seite auf den Hintergrundspeicher ist nicht notwendig, da die Seite auf dem 

Hintergrundspeicher noch aktuell ist man spart sich den Datentransfer. 

¯ Probleme 

Es gibt einige Probleme mit der Seitenadressierung, die sich auf die 

Speichereffizienz und die Performanz beziehen. 

– Größe der Seiten-Kacheltabelle 

Die Seiten-Kacheltabelle kann sehr groß werden, z.B. bei Seitengröße 4K 

(früher üblich!) ergeben sich für 32-bit Adressraum insgesamt 1 Million 

Seiten pro Prozess. 

Lösung? Mehrstufige Tabellen: Seiten-Kacheltabelle ebenfalls in Seiten 

unterteilen, die ihrerseits in Tabellen gehalten werden. Technisch wird 

bei einem mehrstufigen Verfahren der Seitenanteil der virtuellen Adresse 

in Abhängigkeit von der Stufenzahl weiter unterteilt, z.B. s1, s2,...sn. 

In der Regel wird mit der Adressabbildung ab dem höchstwertigen Bit 

begonnen. Der Anteil s1 definiert den Index für die Seitentabelle erster 

Stufe, s2 den Index für den Anteil zweiter Stufe, etc. 


s1 s2 w 

Deskriptor 

Deskriptor k w 

174


Beispielsweise kann ein 32-Bit Adressraum auf der ersten Stufe in 128 

Seiten (2 7 ) mit je 32 MByte unterteilt werden. Ein Seitentabellen-Deskriptor 

verweist auf eine Seitentabelle, die die 32 MByte große Seite in weitere 

Seiten unterteilt, z.B. 256 KByte. Es muss nicht die gesamte Tabelle im 

Arbeitsspeicher gehalten werden. Das schrittweise Durchlaufen u. U. 

mehrstufiger Seiten-Kacheltabellen nennt man Page-Table Lookup. 

– Performanz 

Schnelle Umrechnung der virtuellen auf realen Adressen erforderlich, da 

Berechnung bei jedem Zugriff notwendig ist! Häufig verwendete Adressen 

werden in einem Schnellzugriffspeicher (cache) der MMU gehalten, dem 

Translation Lookaside Buffer (TLB). Bei jedem Zugriff auf eine virtuelle 

Adresse wird überprüft, ob sich die zugehörige Seite und damit die 

Kacheladresse im TLB befindet. TLB ist als assoziativer Cache organisiert 

(vgl.TGI!), d.h. alle Einträge werden gleichzeitig auf Übereinstimmung 

mit dem Seitenanteil der referenzierten Adresse verglichen. Ist kein 

entsprechender Eintrag in der TLB, erfolgt die Adressabbildung über den 

relevanten Deskriptor der Seiten-Kacheltabelle. Idee ist, dass der TLB 

wenige Einträge enthält (ca. 8). Ein Eintrag enthält eine virtuelle und 

zugeordnete reale Adresse kein aufwändiges Page Table Lookup für TLB- 

Einträge erforderlich. Designziel bei der Verwaltung der TLB-Einträge ist 

eine gute Trefferrate (cache hit). 

¯ Varianten der SKT 

Varianten für den Aufbau einer Seiten-Kacheltabelle. 

– Prozess-spezifisch, Index-basiert (PI) 

Zugriff auf Deskriptor für Seite s über Index i. 

i 

– Prozess-spezifisch, assoziativ (PA) 

Hier wird die Seitennummer mit in den Seitendeskriptor aufgenommen. Die 

SKT ist prozessspezifisch. Es sind nur die geladenen Seiten aufgeführt. 

– Global, assoziativ (GA) 

Es gibt nur eine SKT im System. Da die Seitennummer allein nicht eindeutig 

ist, muss das Prozesskennzeichen (PID), d.h. der eindeutige Prozessname, 

ebenfalls in den Deskriptor aufgenommen werden. Es sind nur die geladenen 

Seiten aufgeführt. Die maximale Anzahl der Elemente dieser SKT ist die 

Anzahl der Kacheln, falls gemeinsame Speicherbereiche der Prozesse nicht 

betrachtet werden. 

– Global, indiziert (GI) 

175


Enthält auch PID und es erfolgt eine Reihung gemäß der Kachelnummer; 

freie Kacheln werden durch einen speziellen Eintrag gekennzeichnet. 

Kacheln, denen keine Seite zugeordnet ist, erhalten einen speziellen Eintrag 

bei PID. Damit enthält die Tabelle so viele Elemente wie Kacheln im 

Arbeitsspeicher vorhanden sind. Da die Angabe der Kachelnummern sich 

aus der Position in der Tabelle ergibt, kann diese Angabe entfallen. 

Seitenfehlerbehandlung 

Der Zugriff auf eine Seite, die nicht im Arbeitsspeicher ist, führt zu einem 

Seitenfehler. 

load M 

Prozess P1 

(1) Zugriff 

(6) Befehl 

erneuert 

Seiten- 

Kacheltabelle 

(2) page fault 

Seitenfehlerbehandlung 

des 

BS 

Ablauf der Seitenfehlerbehandlung 

(5) Aktualisieren 


Kachel 1 

Kachel 2 

Kachel 3 

..... 

(3) Seite auf Hintergrundspeicher 

(4) Einlagern 

Hintergrundspeicher 

mit Blöcken 

1. Beim Zugriff auf eine virtuelle Adresse (z.B. LOAD-Befehl) tritt ein 

Seitenfehler auf. 

2. Die Adressrechnungshardware löst einen Alarm aus, so dass die Unterbrechungsbehandlung 

des BS aktiviert wird. Dieser wird beispielsweise in der 

MMU bei der Adressrechnung ausgelöst. Der Prozesszustand muss gerettet 

werden, u.a. der Befehlszähler und die Registerbelegungen. Weiterhin muss 

der Unterbrechungsbehandlung die Adresse übergeben werden, die den Seitenfehler 

auslöste. 

3. Das BS stellt eine freie Kachel zur Verfügung, lokalisiert die Seite auf der Platte 

und initiiert die Einlagerung der Seite (Lesen von Platte). Falls aktuell keine 

Kachel frei ist, muss eine Seite auf den Hintergrundspeicher verdrängt werden. 

4. Die Seite wird eingelagert. 

176


5. Der Seitendeskriptor wird aktualisiert und verweist jetzt auf die belegte Kachel 

(im Beispiel k = 3). 

6. Der unterbrochene Befehl wird erneut gestartet. Die Daten sind jetzt 

zugreifbar. Dazu muss zunächst wieder der Prozesszustand geladen werden, 

d.h. Befehlszähler, Register etc. Anschließend wird der Befehl fortgeführt, als 

ob keine Unterbrechung stattgefunden hätte. 

Seitenverwaltungsstrategien 

Aufgabe der Arbeitsspeicherverwaltung: Laden der für die Ausführung der 

Prozesse benötigten Seiten in die Kacheln. Es ergeben sich drei strategische 

Aufgaben: 

¯ Ladestrategie 

Frage: welche Seite ist zu Laden? 

– Lösungsansätze 

£ Einzelseitenanforderungsstrategie (on demand): eine Seite wird genau 

dann geladen, wenn auf sie zugegriffen wird und sie sich noch nicht im 

Arbeitsspeicher befindet. 

£ Seiten-Prefetching: Seiten werden im Voraus geladen, um sie sofort bei 

Bedarf verfügbar zu haben. Wann ist Prefetching sinnvoll und was benötigt 

das BS? Beispielsweise am Anfang beim Laden des main-Programms. 

¯ Platzierungsstrategie 

Frage: in welche Kachel ist eine Seite zu Laden? 

– Lösung 

£ keine strategische Entscheidung erforderlich, da alle Kacheln gleichwertig 

sind und damit keine Auswahl getroffen werden muss. Vorteil der 

uniformen Realisierungskonzepte (Seite, Kachel). 

¯ Seitenverdrängungsstrategie 

Frage: welche Seite ist aus dem Arbeitsspeicher zu entfernen, wenn für eine zu 

ladende Seite keine freie Kachel mehr zur Verfügung steht? Im Idealfall baut 

ein Verdrängungsverfahren auf der Referenzlokalität vieler Programme und 

der sich ergebenden Lokalitätsmenge auf. Solange sich die Lokalitätsmenge 

jedes Prozesses im Arbeitsspeicher befindet, ist die Seitenfehlerrate sehr 

177


gering. Auf der Grundlage der Working-Set-Theorie ergibt sich damit 

für ein Seitenverdrängungsverfahren die Aufgabe, bevorzugt solche Seiten 

auszulagern, die nicht in der Lokalitätsmenge enthalten sind. 

– Strategien 

£ FIFO (first-in first-out): Verdrängen der ältesten Seite, einfach zu 

implementieren. Das Verfahren berücksichtigt die Lokalitätsmenge 

nicht. So werden über längere Zeit hinweg häufig referenzierte Seiten 

verdrängt. Umgekehrt bleiben auch wenig referenzierte Seiten im 

Mittel genauso lange im Arbeitsspeicher wie häufig referenzierte Seite. 

Vorsicht bzgl der FIFO-Anomalie, d.h. trotz Vergrössern des zur 

Verfügung stehenden Arbeitsspeichers können u.U. mehr Seitenfehler 

(d.h. Seiteneinlagerungsoperationen) auftreten, als bei kleinerem 

Speicher. (Warum, woran könnte so etwas liegen? Antwort: FIFO beachtet 

nicht, wann die Seite zuletzt benutzt wurde. D.h. eine häufig benutzte 

globale Variable, die zu einem frühen Zeitpunkt eingelagert wurde, könnte 

z.B. dazu führen, dass diese Seite nach dem Entfernen gleich wieder 

eingelagert werden muss.) 

£ LIFO (last-in first-out): Verdrängen der jüngsten Seite, einfach zu 

implementieren. Diese Strategie berücksichtigt Lokalitätseigenschaft von 

Programmen (häufig in Schleifen, Prozeduren Zugriff auf gleiche 

Seiten) nicht. 

£ LRU (Least recently used): Verdrängen der am längsten nicht genutzten 

Seite; wird am häufigsten realisiert, wobei LRU approximiert wird, da 

eine exakte Realisierung zu aufwendig ist. Eine exakte Realisierung ist 

durch spezielle Hardware möglich, die jeder Seite ein Zeitfeld assoziiert 

und dieses bei jedem Zugriff aktualisiert. 

Frage: wie LRU-Verhalten approximieren 

Antwort: Nutzen eines Referenz-Bits (siehe R- 

Bit der Seitendeskriptor-Informationen) pro Seite, das durch Hardware 

bei einem Seitenzugriff gesetzt wird. Jeder Seite wird ein Zähler zugeordnet. 

Das BS inspiziert in regelmäßigen Abständen die Seiten, und 

inkrementiert den Zähler der Seiten mit nicht gesetztem Bit. Für jede 

referenzierte Seite werden dagegen Zähler und R-Bit gelöscht. Verdrängt 

wird immer die Seite mit dem höchsten Zählerstand, da diese 

am längsten nicht referenziert wurde. 

Andere Alternativen sind z.B. Second Chance. 

£ Optimale Strategie: Seite, auf die in Zukunft am längsten nicht 

zugegriffen wird; die optimale Strategie ist unrealistisch, da das zukünftige 

Verhalten i.d.R. nicht bekannt ist. Leistungsdaten dieser Strategie, 

178


d.h. wieviele Seitenfehler treten bei gegebener Arbeitsspeichergröße und 

gegebenen Zugriffscharakteristika von Prozessen auf, gibt Obergrenze für 

Erreichbares an. 

¯ Weitere offene Fragen 

– Wahl einer vernünftigen Seitengröße 

Die Wahl der Seitengröße steht unter widersprüchlichen Zielsetzungen; 

daher ist ein Kompromiss erforderlich. 

1. Je kleiner die Seite, desto rascher die Transfers zwischen ASP und 

Platte. 

2. Je kleiner die Seite, desto geringer der Verschnitt (interne 

Fragmentierung) durch nicht voll ausgenützte Seiten. 

3. Je größer die Seite, desto geringer der Overhead für Transport 

zwischen Arbeitsspeicher und Platte pro Byte (Arm positionieren, 

Warten bis Spur unter Lese-Schreib-Kopf). 

4. Je größer die Seite, desto mehr Information kann zwischen 

Arbeitsspeicher und Platte je Zeiteinheit transportiert werden. 

5. Je größer die Seite, desto seltener Transfers erforderlich. 

£ Beispiele für Seitengrößen: Intel 80386 4K, Pentium II 4K oder 4MB, 

UltraSPARC 8K, 64K, 512K oder 4MB. Tendenz: grössere Seiten. 

Warum? schnelle CPU und großer Arbeitsspeicher, Seitenfehler haben 

großen Einfluss auf Performanz des Rechensystems, deshalb möglichst 

wenige. 

– Seitenflattern 

Seitenflattern (engl. thrashing) tritt auf, wenn im System zuviele Prozesse 

sind, die nebenläufig voranschreiten wollen und Kacheln beanspruchen. 

Gerade verdrängte Seiten müssen zu schnell wieder eingelagert werden, das 

System ist im schlimmsten Fall nur noch mit Ein- und Auslagern beschäftigt. 

5.4.2 Segment-Seitenadressierung 

Unterteilung des Programmadressraums in logische Einheiten unterschiedlicher 

Länge, sogenannte Segmente. Ein Segment umfasst inhaltlich bzw. organisatorisch 

zusammengehörige Speicherbereiche, z.B. Daten, Code und 

Laufzeitkeller-Segment. Im Gegensatz dazu ist die Seiteneinteilung systembedingt 

und vom jeweiligen Programm unabhängig. 

¯ Jedes Segment besitzt eine maximale Größe. Die Länge der einzelnen 

Segmente kann unterschiedlich sein und sich dynamisch verändern. 

179


¯ Jedes Segment wird durch einen Segment-Deskriptor beschrieben. Die 

Segmentdeskriptoren werden in einer Segmenttabelle verwaltet. 

¯ Jedes Segment besteht aus Seiten, die jeweils beginnend mit Null fortlaufend 

numeriert sind. 

¯ Ein Zugriff auf ein nicht existentes Segment führt zum Speicherschutzalarm. 

¯ Um in dieser Situation möglichst kompakte Speicherabbildungstabellen zu 

erhalten, wird die Seiten-Kacheltabelle aufgeteilt. je Segment eine 

eigene Seiten-Kacheltabelle gehalten. Die (Maschinen-) Adressen der Seiten- 

Kacheltabellen werden in einer Segmenttabelle gehalten. 

Segmenttabellenregister 

+ 

sg 

0 

sg 

s w 

Segmenttabelle 


Adresse im 


virtuelle Adresse k w 

Bei der Adressierung der Tabellen muss natürlich jeder Index mit der Länge eines 

Seiten- bzw Segmentdeskriptors (LOP) multipliziert werden. Falls ein Eintrag 4 

Byte lang ist, ergibt sich damit z.B. 

Adresse des Segmentdeskriptors = 

Wert Segmenttabellenregister + sg * 4. 

Entsprechendes gilt auch für die Seiten-Kacheltabelle. 

5.4.3 Speicherverwaltung der MI 

Die Modellmaschine unterstützt neben der direkten Adressierung auch eine 

Seitenadressierung ergänzt um drei wohldefinierte Segmente. 

180 

+ 

0 

s 

k



PCS s w 

0 1 2 22 23 31 

¯ PCS = 0 (P0-Bereich): dieser Bereich enthält das Benutzerprogramm und die 

Daten (Halde). 

¯ PCS = 1 (P1-Bereich): Bereich des Laufzeitkellers des Benutzerprogramms. 

¯ PCS = 2 (Systembereich): dieser Bereich ist in der Regel in allen Prozessen 

einheitlich durch die BS-Komponenten belegt, d.h. das BS ist in jedem 

Programmadressraum. 

¯ PCS = 3: unzulässiger Bereich 

181

Kapitel 6 

Dateisysteme 

Dateisysteme dienen der dauerhaften Speicherung von Programmen und 

Daten. Zum Einsatz kommen magnetische und optische Medien, die im 

Gegensatz zum Arbeitsspeicher auch nach dem Ausschalten der Rechenanlage 

den Datenerhalt sicherstellen. Beispiele von externen Speichermedien sind 

Festplatten, Magnetbänder, CD-ROM (wiederbeschreibbar) und neuerdings auch 

DVDs. Der schlechten Zugriffszeit externer Speichersysteme (im Vergleich zum 

Arbeitsspeicher) steht eine vergleichsweise hohe Kapazität und ein sehr gutes 

Preis-Leistungsverhältnis gegenüber. Zentrale Aufgabe des Dateisystems ist es 

die besonderen Eigenschaften externer Speichermedien optimal umzusetzen und 

Applikationen einen effizienten Zugriff auf die persistent gespeicherten Daten zu 

ermöglichen. Es gelten folgende grundlegende Forderungen 

a) Speicherung großer Informationsmengen (Video) 

b) kein Datenverlust auch bei Prozess- / Systemabsturz 

c) nebenläufiger Zugriff durch mehrere Prozesse 

Neben Dateisystemen gibt es Datenbanksysteme, die aus einer Menge von 

Daten und den zugehörigen Programmen zum Zugriff auf die Daten sowie zur 

Kontrolle der Konsistenz bestehen. Der Zugriff auf die Daten erfolgt immer 

über Operationen des Datenbanksystems, und nicht direkt durch die einzelnen 

Applikationen. 


Dieser Abschnitt beschäftigt sich mit den Mechanismen eines Rechensystems zur 

dauerhaften (persistenten) Speicherung von Programmen und Daten: 

¯ Charakteristika von Dateisystemen. 

182

Schlichter, TU München 6.2. CHARAKTERISTIKA VON DATEISYSTEMEN 

¯ Schichtenmodell eines Dateisystems. 

6.2 Charakteristika von Dateisystemen 

Jedes Dateisystem unterstützt 2 grundlegende Abstraktionen: 

Datei: Behälter für die persistente Speicherung jeglicher Information. 

Information können Daten, der Code ausführbarer Programme, aber auch 

kontinuierliche Daten wie Videoströme sein. Das Dateisystem bietet 

besondere Zugriffsfunktionen an, die der Zugriffscharakteristik externer 

Speicher Rechnung tragen. 

Verzeichnisse: spezielle Dateien zur Strukturierung externer Speichermedien. 

¯ blockorientierter Datentransfer zwischen externem Speicher und Arbeitsspeicher. 

Aufgrund der hohen Zugriffszeiten bei externen Speichermedien ist ein 

kleines Lese- und Schreibgranulat nicht sinnvoll. Daher bilden sogenannte 

Blöcke die kleinste Übertragungseinheit. Typische Blockgrößen: 512 Byte - 

4 KByte. Der Zugriff auf das 1. Byte eines Blocks auf der Festplatte hängt von 

der Positioniergeschwindigkeit ab (im Mittel mehrere Millisekunden), während 

die Zugriffszeit auf die restlichen Bytes von der Umdrehungsgeschwindigkeit 

der Platte abhängt. Zu große Blöcke resultieren in wachsender Information, die 

vom Prozess primär nicht angefordert wurde. 

¯ Charakteristika der Dateinutzung (empirisch ermittelt): 

a) Dateien sind meist klein (wenige KBytes). 

b) Dateien werden häufiger gelesen, seltener geschrieben und noch seltener 

gelöscht. 

c) vornehmlich sequentieller Zugriff. 

d) Dateien werden selten von mehreren Programmen oder Personen 

gleichzeitig benutzt. 

Datei-Zugriffsoperation werden oft gemäß dieser Charakteristika optimiert. Für 

Multimedia verändert sich die Nutzungscharakteristik. 

große Dateien (mehrere GByte). 

gleichmäßige Zugriffsgeschwindigkeit (um Ruckeln zu vermeiden). 

notwendige Übertragungsbandbreite. Zum Beispiel ist bei einer unkomprimierten 

Videoaufzeichnung im Format 1024*768 bei 3 Byte pro Pixel 

und 50 Bildern pro Sekunde eine Übertragungskapazität von 112,5MByte 

pro Sekunde notwendig (Datei hat bereits nach einer Minute eine Größe 

von 6,5 GByte). 

183

Schlichter, TU München 6.3. DATEIEN 

6.3 Dateien 

Dateien bilden in einem Dateisystem die Behälter für die dauerhafte Speicherung 

beliebiger Information. Dabei nutzen nicht nur Benutzerprogramme, sondern 

auch die Systemsoftware greift in vielen Fällen auf Dateien zurück. Beispielsweise 

wird auch die Auslagerung von Seiten des virtuellen Adressraums über 

das Dateisystem auf einer sogenannten Auslagerungsdatei (siehe Windows 9x) 

vorgenommen. 

¯ in den meisten Systemen wird eine Datei als eine Folge von Bytes aufgefasst. 

Eine Datei beginnt mit dem Byte 0 und endet in Abhängigkeit von ihrer Länge 

n mit dem Byte n-1. 

¯ Dateinamen 

in manchen Dateisystemen haben Dateinamen die Form "name.extension". 

Beispiele für extension: Ú ØÑÐ Ô ØÜ 

Ó ÞÔ 

In einigen Betriebssystemen werden die Datei-Extension sematisch interpretiert 

und veranlassen ein bestimmtes Verhalten, z.B. ein Doppel-Click auf eine 

".doc"-Datei startet Microsoft Word. In Unix sind Datei-Extensions nur 

Konventionen. Das Mac Betriebssystem nutzt keine Extensions, um 

Applikationen zu triggern; dort wird eine zusätzliche Ressource-Datei genutzt. 

¯ Dateiaufbau 

Die interne Struktur einer Datei hängt von der jeweiligen Nutzung und 

Zielsetzung ab, z.B. ASCII Datei besteht aus Zeilen, die mit CR, LF 

abgeschlossen sind. MS-DOS verwendet eine Kombination von CR und LF. 

Beispiel einer Archivdatei 

184


Header 

Objekt Modul 

Header 

Objekt Modul 

Header 

Objekt Modul 

Modulname 

Datum 

Owner 

Zugriffsrechte 

Länge 

Ein weiteres Beispiel haben wir bereits beim Aufbau des Objektprogramms 

(siehe Seite 39) für die MI kennengelernt. 

¯ Operationen 

Dateisysteme unterstützen die folgenden grundlegenden Systemaufrufe: 

ÓÔÒ 

Öffnen einer Datei; Ergebnis ist ein Dateideskriptor, über den in 

nachfolgenden Systemaufrufen auf die Datei zugegriffen werden kann. 

Aufruf nach Posix-Standard 

ÒØ ÓÔÒ 

ÓÒ×Ø Ö ÐÒÑ 

ÒØ Ð× 

ÑÓØ ÑÓ 

Ð× spezifiziert die Zugriffsart, z.B. lesend, schreibend, erzeugend, 

anhängend (append); ÑÓ spezifiziert die Zugriffsrechte für neu erzeugte 

Dateien. In Windows NT/2000 wird der Systembefehl ÖØÐ zum 

Öffnen einer Datei bzw. zum Erzeugen einer neuen Datei verwendet. Analog zu 

ÓÔÒ wird als Ergebnis ein Dateideskriptor zurückgegeben (Datentyp Handle). 

Die Anzahl der Dateideskriptoren ist beschränkt. 

ÐÓ× 

Schließen einer Datei; Aufrufparameter ist ein Dateideskriptor. Bei 

Terminierung des Prozesses werden alle offenen Dateien automatisch 

geschlossen. 

185


ÒØ Ö ÒØ Ö ÔÙÖ ÒØ ÑÜ 

ÒØ ÛÖØ ÒØ Ö ÔÙÖ ÒØ Ò 

ÑÜ gibt die Anzahl der Bytes an, die ohne Pufferüberlauf gelesen werden 

können; Ö liefert als Ergebnis die Anzahl der erfolgreich gelesenen Bytes. 

Daneben gibt es noch weitere Operationen, z.B. Positionieren des Dateizeigers 

auf eine bestimmte Position in der Datei (Ð× oder ËØÐÈÓÒØÖ bei 

Win32). 

– Dateipuffer 

Zugriffe auf Dateien erfolgen über einen Dateideskriptor und einen 

Dateipuffer. 

Datei 

Deskriptor 

Dateipuffer 

Dateizeiger 

Puffer 

Pufferposition 

Ortsinformation 

Externer Speicher Datei 

Die für den lesenden und schreibenden Zugriff notwendigen Informationen 

werden in einer eigenen Datenstruktur (Dateipuffer) gespeichert, die 

jedem geöffneten Dateideskriptor zugeordnet wird. Diese Datenstruktur 

enthält neben der Ortsinformation, die Aufschluss über den physischen 

Aufenthaltsort der Datei auf einem externen Speichermedien gibt, einen 

Puffer zur Zwischenspeicherung von Daten. Der Puffer beinhaltet eine Kopie 

eines bestimmten Dateiausschnitts. Die Position dieser Kopie innerhalb der 

Datei speichert der Zeiger Pufferposition. Der Dateizeiger spezifiziert die 

aktuelle Lese-/Schreibposition. 

186

Schlichter, TU München 6.4. MEMORY-MAPPED DATEIEN 

6.4 Memory-Mapped Dateien 

Eine Datei oder Teile davon werden in den virtuellen Adressraum eines Prozesses 

eingeblendet. Das Dateisystem bestimmt einen hinreichend großen Bereich im 

virtuellen Adressraum für den Dateiausschnitt, z.B. zwischen Laufzeitkeller und 

Halde. Für diesen Teilbereich müssen entsprechende Seitentabellendeskriptoren 

initialisiert werden. Nutzung von "Prefetching", um bereits im Voraus 

Dateiblöcke in Seiten zu laden. 

¯ Lese- und Schreiboperationen, sowohl sequentiell als auch wahlfrei, erfolgen 

über virtuelle Adressen. 

¯ Einblendung immer nur Vielfacher ganzer Blöcke einer Datei. 

¯ veränderte Blöcke werden meist aus Effizienzgründen zu einem späteren 

Zeitpunkt zurückgeschrieben. Auf jeden Fall werden die veränderten Blöcke 

beim Schließen der Datei auf den externen Speicher zurückgeschrieben. 

¯ Beispiel der Win32-Programmierschnittstelle: 

ÀÒÐ Ñ 

ÖØÐ ÐÒÑ ÒÖ Ö 

ÐÒ ØÐËÞ 

Ñ ÖØÐÅÔÔÒ ÈÖÓÒÐÝ 

Ö ÅÔÎÛÇÐ Ñ ÐÑÔÖ 

Der Rückgabewert addr speichert die Anfangsadresse der Datei im virtuellen 

Adressraum. In der Regel wählt das Dateisystem den virtuellen Adressbereich 

aus. 

6.5 Verzeichnisse 

Verzeichnisse (engl. directories) erlauben eine hierarchische Strukturierung des 

externen Speichers. 

¯ baumartige Verzeichnisstruktur mit links zwischen Unterbäumen. 

¯ Pfadnamen zur Spezifikation von Dateien und Verzeichnissen. Der vollständige 

und eindeutige Namen einer Datei oder eines Verzeichnisses entsteht durch 

eine Aneinanderreihung aller Verzeichnisnamen beginnend beim Wurzelverzeichnis; 

Unterscheidung zwischen absoluten und relativen Dateinamen. 

¯ typische Operationen: create, delete, opendir, closedir, readdir, rename, link, 

unlink. 

187

Schlichter, TU München 6.6. SCHICHTENMODELL 

6.6 Schichtenmodell 

Ein Dateisystem kann logisch in 3 Schichten unterteilt werden, die zunehmend 

höhere Abstraktionen für die Speicherung persistenter Daten anbieten. 

6.6.1 Datenträgerorganisation 

Dateiverwaltung 

Blockorientiertes Dateisystem 

Datenträgerorganisation 

Unterteilung des gesamten Datenträgers in Blöcke, die von 0 an aufsteigend 

durchnummeriert sind. Das auf MS-DOS aufbauende Dateisystem FAT 

(Windows 95) verwendet lediglich maximal 16 Bit für eine Blocknummer. 

Bei einer ursprünglichen Blockgröße von 512 Byte können damit externe 

Speicher mit bis zu 32 MByte Speicherkapazität angesprochen werden. 

Zusammenfassung von Blöcken zu Clustern (32 KByte), um bis zu 2 GByte große 

Datenträger zu addressieren; Cluster sind die kleinste Zuteilungseinheit interne 

Fragmentierung. 

¯ Verwaltung freier und defekter Blöcke. 

Defekte 

Blöcke 

Freie 

Blöcke 

0 

0 0 1 0 0 0 0 

Block 0 

Block 1 Block 2 Block 3 Block 4 Block 5 

0 1 1 0 0 1 0 0 

Eine gängige Realisierung der Listen für freie und defekte Blöcke besteht in 

zusammenhängenden Bitvektoren, die auf dem Datenträger selbst gespeichert 

werden. Diese Realisierung erlaubt den gleichzeitigen Test von 16, 32 oder 64 

Bitpositionen mit Hilfe von Logikoperatoren des Prozessors. 

188

Schlichter, TU München 6.6. SCHICHTENMODELL 

¯ Blockstruktur 

Superblock 

Freie Blöcke 

Defekte 

Blöcke 

Block 0 Block 1 Block n 

Der Superblock verwaltet alle essentiellen Informationen über den Datenträgeraufbau, 

z.B. eine Magic Nummer für den Typ des Dateisystems, Anzahl der 

Blöcke. Aus Sicherheitsgründen wird der Superblock mehrfach, verteilt über 

den gesamten Datenträger, repliziert. 

6.6.2 Blockorientiertes Dateisystem 

Aufteilung des vorhandenen Speicherplatzes eines logisch durchnummerierten 

Datenträgers auf mehrere Dateien. 

¯ Dateien besitzen interne Namen. 

¯ keine hierarchische Verzeichnisstruktur. Es existieren keine hierarchischen 

Verzeichnisstrukturen, d.h. alle Dateien sind in einer flachen Struktur 

unmittelbar über den internen Dateinamen ansprechbar. 

¯ jede Datei besteht aus einer Menge von Blöcken, die relativ zum Dateianfang 

nummeriert sind. Die Blöcke können entweder zusammenhängend oder 

verteilt über den Datenträger zugeteilt werden. Im ersten Fall kann dies zu 

externer Fragmentierung führen. Die interne Fragementierung hängt von der 

Blockgröße ab. Dateien werden immer in Vielfachen von Blöcken belegt. 

¯ wesentliche Operationen: 

Erzeugen und Löschen von Dateien 

Öffnen und Schließen von Dateien 

Lesen und Schreiben von Blöcken 

6.6.3 Dateiverwaltung 

Bereitstellung von Dateien und Verzeichnissen; Dateien werden über Namen 

identifiziert. Unix verwendet Dateideskriptoren (sogenannte I-Nodes), die alle 

relevanten Dateiattribute einschließlich einer Indexstruktur für die Lokalisierung 

der einzelnen Dateiblöcke enthalten. Die Position der ersten 10 Blöcke einer Datei 

werden direkt im Deskriptor gespeichert. 

189

Schlichter, TU München 6.7. EINBETTUNG DER E/A 

I-Node 

Schutzbits 

Link Count 

uid 

gid 

Größe 

Adressen der 

ersten 10 Blöcke 

einfach indirekt 

zweifach indirekt 

dreifach indirekt 

6.7 Einbettung der E/A 

Die Realisierung abstrakter Geräte und die Definition einer generischen 

Gerätearchitektur ist charakteristisch für viele Betriebssysteme. 

¯ in Unix erfolgt der Zugriff auf praktisch jedes E/A-Gerät über Funktionen des 

Dateisystems. Vor dem eigentlichen Zugriff auf ein Gerät muss dieses analog 

zu einer Datei geöffnet werden. 

¯ in vielen Unix Systemen werden alle Geräte unter dem Teilbaum Ú 

verwaltet. 

¯ der Dateiname charakterisiert den jeweiligen Typ des E/A-Geräts. 

Ú ØØÝ: physische serielle Schnittstelle 

Ú ÔØØÝ : abstrakte serielle Schnittstellen 

Ú : Diskettenstationen 

Ú × : Festplatten 

Ú Ð : Netzkarten 

190

Kapitel 7 

Prozesskommunikation 

Disjunkte Prozesse, d.h. Prozesse, die völlig isoliert voneinander ablaufen, 

stellen eher die Ausnahme dar. Häufig finden Wechselwirkungen zwischen den 

Prozessen statt Prozesse interagieren. Die Unterstützung der Prozessinteraktion 

stellt einen unverzichtbaren Dienst dar. Betrachtet man diese Prozesswechselwirkungen 

genauer, dann lassen sich 2 grundlegende Interaktionsmuster unterscheiden: 

Konkurrenz und Kooperation. Eine Konkurrenzsituation liegt vor, 

wenn sich Prozesse gleichzeitig um ein exklusiv benutzbares Betriebsmittel bewerben 

Prozesssynchronisation. Bei Prozesskooperation geht es darum, dass 

die beteiligten Prozesse gezielt Informationen untereinander austauschen. 


Dieser Abschnitt beschäftigt sich mit den Mechanismen von Rechensystemen 

zum Austausch von Informationen zwischen Prozessen. 

¯ Kommunikationsarten. 

¯ nachrichtenbasierte Kommunikation, insbesondere Client-Server-Modell. Die 

speicherbasierte Kommunikation, d.h. über gemeinsame Speicherbereiche wird 

im Zusammenhang mit Synchronisation (siehe Seite 96) und Semaphoren 

behandelt. 

¯ Netzwerkprogrammierung auf der Basis von Ports und Sockets. 

¯ entfernter Prozeduraufruf. 

191


7.2 Einführung 

Prozessinteraktion kann Rechner-lokal und Rechner-übergreifend stattfinden. 

Prozesse können auf vielfältige Weise Informationen austauschen. 

7.2.1 Kommunikationsarten 

implizit 

1 : 1 

n : 1 

1 : m 

n : m 

Prozesskommunikation 

breitbandig schmalbandig 

explizit 

asnychron 

1 : 1 

1 : m 

n : m 

Ströme 

explizit 

snychron 

RPC 

RMI 

Ereignisse 

Alarme 

Signale 

Die Bandbreite des Kommunikationskanals bestimmt die Datenrate, in der Daten 

zwischen Prozessen ausgetauscht werden können. Breit- bzw. schmalbandig 

bezieht sich hier auf die Menge der ausgetauschten Information und nicht auf 

die Bandbreite des darunterliegenden Kommunikationsnetzes. 

Schmalbandige Kanäle 

Schmalbandige Kanäle werden im Betriebssystem zum Melden von Ereignissen 

oder für die Synchronisation unterstützt. Übertragung von wenigen Bits an 

Information, z.B. Setzen von Flags 

¯ Dienste des Betriebssystems 

Melden von Ereignissen, 

Warten auf Ereignisse, 

Ereignisverwaltung. 

192


Unterbrechungsereignisse und deren Verwaltung in einem Betriebssystem 

wurden bereits eingeführt. 

¯ Beim Ablauf von Prozessen können Alarme entstehen (z.B. arithmetische 

Alarme). Da das BS keine genauen Kenntnisse über den internen 

Berechnungszustand eines Prozesses besitzt, kann man mit den allgemeinen 

Standardalarmbehandlungen des BS einen Prozess höchstens abbrechen. Es ist 

somit sinnvoll, die Alarmbehandlung dem Prozess selber zu überlassen. 

¯ Die Alarme werden über Namen identifiziert, die im BS vereinbart sind. Das 

BS stellt Dienste zur Zustellung von Alarmen zur Verfügung. Bemerkung: 

schmalbandige Informationskanäle sind für den Bereich der Datensicherheit 

problematisch, da sie schwierig zu beherrschen sind. Über diese Kanäle können 

sich Angreifer Informationen über das System beschaffen und ausnutzen. 

Beispiel: Einloggen unter Solaris 7.0 liefert bereits nach Eingabe der Kennung 

Informationen, dass diese Kennung korrekt ist. Lässt sich für einen Passwort- 

Cracking-Angriff ausnutzen. 

Im folgenden werden wir uns vertiefend mit breitbandigen Kommunikationsformen 

beschäftigen, und zwar nicht nur im lokalen Bereich, sondern auch im 

verteilten Bereich. 

Implizite Kommunikation 

Implizite Kommunikation ist eine breitbandige Kommunikationsform. Die 

Kommunikation erfolgt über einen gemeinsamen Speicher (Dateien, Register, 

Datenstrukturen). 

¯ Die Kommunikation findet ohne direkte Unterstützung und ohne Kenntnis des 

BS statt. 

¯ Vorteil: einfach und schnell (kein Kopieren zwischen Adressräumen). 

¯ Nachteil: 

a) gemeinsame Bereiche sind nicht immer vorhanden: z.B. in physisch 

verteilten, vernetzten Systemen gibt es i.d.R. keinen gemeinsamen 

Speicher. Eine Ausnahme bilden sogenannte DSM (Distributed Shared 

Memory) Realisierungen. 

b) gegebenenfalls aufwendiges busy waiting Mischform: Ereigniszustellung, 

d.h. schmalbandige Kommunikation, die das Vorhandensein von Daten 

signalisiert. 

193


¯ Implizite Kommunikationsformen 

Verschiedene Formen der impliziten Kommunikation 

1:1 ein Puffer pro Sender/Empfänger-Paar 

n:1 n Sender senden Nachrichten an einen Empfänger, z.B. 

Sender: Prozesse senden Druckaufträge 

Empfänger: Drucker-Server 

1:m Mitteilung an alle Prozesse (Broadcast, Multicast); 

Broadcast: z.B. Erfragen, wo ein spezieller Dienst angeboten wird; 

Shutdown Message an alle Rechner. 

Multicast: z.B. Nachricht an Gruppe gleichartiger Server. Broadcast und 

Multicast ist in lokalen Netzen mit busartigen Medien (z.B. Ethernet) 

sehr einfach zu realisieren; dort hören alle angeschlossenen Rechner das 

Medium ab. 

n:m n Erzeuger schreiben in Puffer und m Verbraucher lesen aus Puffer. 

n:m Kommunikationsform ist beispielsweise sinnvoll, wenn eine Menge 

gleichartiger Dienste zur Verfügung steht, und ein Auftrag von einem 

beliebigen dieser Dienstanbieter erledigt werden kann. 

194


S1 

prozessspezifischer 

oder 

zentraler 

Puffer 

E1 

1:1 Kommunikation 

Si i-ter Senderprozess 

Ei i-ter Empfängerprozess 

Explizite Kommunikation 

S1 

prozessspezifischer 

oder 

zentraler 

Puffer 

E1 

Sn 

n:1 Kommunikation 

S1 

Briefkasten 

(mail box) 

Sn 

E1 Em 

n:m Kommunikation 

Diese Kommunikationsart wird realisiert durch den Austausch von Nachrichten 

("message passing") nachrichtenbasierte Kommunikation. Die Nachrichtenkommunikation 

ist immer dann die geeignete Kommunikationsform, wenn 

die beteiligten Prozesse in disjunkten Adressräumen liegen, und damit keine 

Möglichkeit haben, auf einen gemeinsamen Speicher zuzugreifen. 

¯ Betriebssystem enthält einen Nachrichtendienst ND (das Kommunikationssystem), 

der den Austausch der Nachrichten zwischen Prozessen realisiert. ND 

unterstützt 2 Systemdienste: 

×Ò ÔÖÓ ×× Ñ Ñ×× 

Ö Ú Ë ÔÖÓ ×× Ñ Ñ×× 

Mittels ×Ò wird eine Nachricht m für den Empfänger E an den 

Nachrichtendienst ND übergeben. Mit Ö Ú entnimmt ein Empfänger E 

die Nachricht m, die vom Sender S gesandt wurde, von ND. Der Absender wird 

gewöhnlich in der Nachricht m codiert. 

¯ prinzipieller Ablauf 

195


Sende 

prozess S 

Nachricht m 

Nachrichten 

dienst ND 

Nachricht m 

Empfänger 

prozess E 

Falls die Prozesse auf unterschiedlichen Rechnern sind, sind die Nachrichtendienste 

der beteiligten Betriebssysteme involviert. In diesem Fall findet eine 

Kommunikation zwischen den beiden Nachrichtendiensten statt. 

¯ Aufbau einer Nachricht 

Eine Nachricht besteht aus 2 grundlegenden Komponenten: 

Nachrichtenkopf: 

Empfängeridentifikation 

Verkehrsinformation, z.B. Sender- und 

Nachrichteninhalt: Nutzlast (payload) 

¯ explizite Kommunikation ist besonders geeignet in verteilten, vernetzten Systemen. 

Die nachfolgenden Abschnitte werden sich mit der nachrichtenbasierten 

Kommunikation, insbesondere in verteilten Systemen beschäftigen. 

7.2.2 Verteilte Systeme 

Bisher haben wir uns mit systemnahen Konzepten von zentralen Systemen 

beschäftigt. Seit Ende der 80er Jahre haben jedoch verteilte Systeme rapide an 

Bedeutung gewonnen. Die Verteilung bezieht sich sowohl auf die Verteilung 

von Hardwarekomponenten (Rechner, Peripherie), als auch auf die Verteilung 

von Daten und Verarbeitung. Im letzteren Fall spricht man von einer verteilten 

Anwendung, d.h. eine Anwendung besteht aus mehreren kooperierenden 

Teilkomponenten, die auf verschiedenen Rechnern ausgeführt werden. 

Ansätze zur Kopplung von Recheneinheiten 

Vielfach CPU- 

Systeme 

eng gekoppelt lose gekoppelt 

Multiprozessoren Multicomputer verteiltes System 

196


Multiprozessor Multicomputer verteiltes System 

Konfiguration nur eigene CPU CPU, Arbeitsspeicher,zschnittstelleNet- 

Peripherie gemeinsam gemeinsam, 

außer Festplatte 

Ort gemeinsames gemeinsamer 

Gehäuse Raum 

Kommunikation gemeinsamer Ar- direkte 

beitsspeicher Verbindung 

Betriebssystem ein gemeinsames getrennt, jedoch 

BS 

gleicher Typ 

kompletter Rechner 

getrennt 

weltweit verteilt 

Netzwerk 

getrennt, vielfach 

unterschiedlich 

Verwaltung eine Organisation eine Organisation viele Organisationen 

Ein Beispiel für ein eng gekoppeltes Multiprozessor System ist die MI bestehend 

aus 4 Rechnerkernen; die Rechnerkerne sind untereinander durch einen Bus 

verbunden. Das Rechensystem wird kontrolliert durch ein gemeinsames 

Betriebssystem; das Betriebssystem teilt Rechnerkerne und Speicherbereiche 

an Prozesse zu; es erfolgt eine parallele Ausführung der Benutzerprogramme; 

jeder RK hat den gerade ablaufenden Prozess im gemeinsamen Arbeitsspeicher. 

Die Einteilung in Multicomputer oder verteiltes System hängt etwas von der 

verwendeten Betrachtungsweise ab. 

Charakteristika verteilter Systeme 

Netze verbinden autonome Rechner; die Rechner sind oft von verschiedenen 

Herstellern mit 

inkompatiblen Datendarstellungen, 

unterschiedlichen Maschinenbefehlsvorräten, und 

verschiedenen Betriebssystemen. 

Die verschiedenen Rechner haben keinen gemeinsamen Speicher, d.h. es ist keine 

Kommunikation über gemeinsame Variable möglich. Kommunikation zwischen 

Prozessen auf verschiedenen Systemen ist nur über Nachrichten möglich (nicht 

über gemeinsamen ASP). 

¯ mehrfache Existenz von verschiedenen Funktionseinheiten (physische, logische). 

Diese können dynamisch verschiedenen Ausführungen zugeteilt werden 

und unabhängig voneinander ablaufen; die Funktionseinheiten können hier 

Rechnerkerne, ASP, periphere Geräte, aber auch Softwarekomponenten sein; 

197

Schlichter, TU München 7.3. NACHRICHTENBASIERTE KOMMUNIKATION 

Funktionseinheiten agieren autonom; Funktionseinheiten können hier auch 

Teilkomponenten einer verteilten Anwendung sein. 

¯ räumliche Verteilung von physischen und logischen Funktionseinheiten. 

Die Funktionseinheiten sind mittels eines oder mehrerer Netze miteinander 

verbunden; dies ermöglicht Kommunikation zur Synchronisation. 

¯ Funktionseinheiten fallen unabhängig voneinander aus. 

¯ Transparenz, z.B. 

Ortstransparenz. Der Benutzer ist sich des Ortes eines Objektes im 

Netz nicht bewusst; Zugriff über einen Namen; Name enthält keine 

Ortsinformation. 

Zugriffstransparenz. Auf alle, lokale oder entfernte, Objekte werden in ein 

und derselben Weise zugegriffen. 

Replikationstransparenz. Der Benutzer oder Prozess greift auf replizierte 

Objekte (ein Objekt existiert in mehreren Kopien) zu, als seien sie nur 

einmal vorhanden, d.h. das Betriebs- bzw. das Ablaufsystem übernimmt 

die Aufgabe, die Kopien des Objekts in einem konsistentem Zustand zu 

halten. Replikation ist insbesondere für die Verfügbarkeit des Systems und 

der Daten von großer Bedeutung. 

¯ kooperative Autonomie bei der Interaktion zwischen den physischen bzw. 

zwischen den logischen Funktionseinheiten. 

7.3 Nachrichtenbasierte Kommunikation 

Bei nachrichtenbasierter Prozessinteraktion tauschen Prozesse gezielt Informationen 

durch Verschicken und Empfangen von Nachrichten aus; ein Kommunikationssystem 

unterstützt an der Schnittstelle wenigstens die Funktionen ×Ò und 

Ö Ú. Nachrichtenkommunikation ist die natürliche Form der Prozessinteraktion 

in Rechnernetzen. Prozesse, die auf verschiedenen Rechnerknoten platziert 

sind, müssen ein physisches Übertragungssystem benutzen, um miteinander in 

Kontakt zu treten. 

7.3.1 Elementare Kommunikationsmodelle 

Klassifikationsschema für die Nachrichtenkommunikation anhand von 2 Dimensionen: 

198


generelles Muster der Nachrichtenkommunikation. 

zeitliche Kopplung der beteiligten Prozesse. 

Klassifikationsschema 

¯ Elementare Kommunikationsmuster sind Meldung und Auftrag. 

Meldung: Einweg Nachricht vom Sender zum Empfänger (unidirektional). 

Die entsprechende Nachrichtentransaktion beginnt mit dem Versenden der 

Nachricht und endet mit der Übergabe an den Empfänger. Zu einer 

Meldung gehört nicht die anschließende Verarbeitung der Nachricht durch 

den Empfänger. 

Auftrag: Zweiweg Nachricht zwischen Sender und Empfänger (bidirektional). 

Sie beginnt mit dem Versenden eines Auftrags an den Empfänger und 

endet mit der Übergabe einer Erfolgsbestätigung über den durchgeführten 

Auftrag an den Sender. Dazwischen liegt die Auftragsbearbeitung auf 

Empfängerseite, die weitere Nachrichten zur Übertragung der Eingabeparameter 

bzw. zur Rückübertragung des Resultates auslösen kann. Im 

einfachsten Fall genügen für einen Auftrag 2 Nachrichten: die Auftragsnachricht 

und die Resultatnachricht, die gleichzeitig als Quittung dient. 

Ausbleibende Quittungen können mittels Timeouts erkannt werden; 

sie sind gleichbedeutend mit negativen Quittungen, die auf Senderseite als 

nicht durchgeführter Auftrag interpretiert wird. 

¯ Synchronität definiert den Kopplungsgrad zwischen Prozessen bei der 

Durchführung einer Nachrichtentransaktion: 

asynchron: Entkopplung des Senders und Empfängers. Dies bedeutet, 

dass ein Sender Nachrichtentransaktionen in schnellerer Folge für einen 

Empfänger erzeugen kann, als dieser in der Lage ist, sie zu bearbeiten. 

Asynchrone Nachrichtenübertragung erfordert deshalb die Pufferung von 

Nachrichten auf dem Übertragungswege zwischen Sender und Empfänger. 

Parallelarbeit ist möglich. 

synchron: beide Prozesse werden zur Nachrichtenübertragung 

synchronisiert. 

Es ist auch möglich das Merkmal Synchronität nicht auf die Nachrichtentransaktion, 

sondern getrennt auf Sender und Empfänger anzuwenden. Damit 

lassen sich asynchrone und synchrone Formen des Nachrichtenversands und 

-empfangs beliebig kombinieren. 

199


Meldung 

¯ Asynchrone Meldung 

Sender wird lediglich bis zur Ablieferung der Meldung an das Nachrichtensystem 

(Kommunikationssystem) blockiert. 

Zeit 

send 

Sender S Nachrichtendienst ND Empfänger E 

Meldung 

receive 

– Nachrichtendienst des Betriebssystems puffert Nachricht; 

Sender S kann seine Ausführung fortsetzen, sobald Nachricht N in den 

Nachrichtenpuffer des ND eingetragen ist. 

S wartet nicht, bis E die Nachricht empfangen hat. 

– Empfänger E zeigt durch receive an, dass er am Empfang der Nachricht N 

interessiert ist. 

Empfänger wird blockiert, bis Sender Nachricht bereit stellt. 

¯ Synchrone Meldung 

Sender und Empfänger von Meldungen sind zeitlich gekoppelt. 

200


Zeit 

send 


Meldung 

Quittung 

receive 

Über die Ablieferung der Nachricht wird der Sender durch eine Quittungsnachricht 

informiert, die zur Aufhebung der Blockade des Senders führt. 

– Rendezvous-Technik: Sender und Empfänger stellen vor Austausch der 

eigentlichen Meldung die Sende- und Empfangsbereitschaft her. In diesem 

Fall braucht die Nachricht nirgends gepuffert werden, sondern sie kann direkt 

vom Adressraum des Senders in den Adressraum des Empfängers übertragen 

werden. Das Erreichen des Rendezvous-Punktes definiert den Zeitpunkt, zu 

dem Sender- und Empfängerseite wechselseitiges Einverständnis über das 

Vorliegen der Sende- und Empfangsbereitschaft erklärt haben. 

Auftrag 

¯ Synchroner Auftrag 

Bearbeitung der Nachricht durch Empfänger und Senden der Resultatnachricht 

sind Teil der Nachrichtentransaktion. 

201


Zeit 


send Auftrag 

receive 

Resultat 

Auftrags 

bearbeitung 

reply 

Synchrone Aufträge schränken die Parallelarbeit zwischen Sender und 

Empfänger noch stärker ein als synchrone Meldungen, da die zeitliche Kopplung 

auch die Bearbeitung der Nachricht umfasst. Diese Kommunikationsform 

wird gerade im Zusammenhang mit dem Client-Server Modell sehr oft 

verwendet. Das RPC-Konzept ("Remote Procedure Call") ist eine sprachbasierte 

Variante der synchronen, auftragsorientierten Kommunikation. 

¯ Asynchroner Auftrag 

Auftrag und Resultat werden als Paar unabhängiger Meldungen verschickt. 

202


Zeit 


send Auftrag 

receive 

receive 

result 

Resultat 

Auftrags 

bearbeitung 

reply 

Zwischen ×Ò und Ö Ú Ö×ÙÐØ kann der Sender u.U. noch weitere 

Aufträge versenden (an den gleichen oder andere Empfänger). 

Vorteile/Nachteile asynchrones Senden 

¯ Vorteile asynchrones Senden 

– nützlich für Realzeitanwendungen. Speziell in Situationen, bei denen 

sendender Prozess nicht blockiert werden darf. 

– ermöglicht parallele Abarbeitung durch Sender und Empfänger. 

– anwendbar zum Signalisieren von Ereignissen. 

¯ Nachteile asynchrones Senden 

– Verwaltung des Nachrichtenpuffers durch BS erforderlich. Überlauf des 

Puffers, Zugriffsprobleme, Absturz von Prozessen. 

– Benachrichtigung des Senders S im Fehlerfall und Behandlung von Fehlern 

ist problematisch. Warum: Sender hat weitergearbeitet, gegebenenfalls 

bereits terminiert; Nachricht kann u.U. nicht mehr wiederholt werden. 

– Entwurf und Nachweis der Korrektheit des Systems ist schwierig. Auftreten 

von Fehlern abhängig von Pufferinhalten und dem Zeitverhalten des 

verteilten Systems (Last des Kommunikationssystems). 

203


7.3.2 Erzeuger-Verbraucher Problem 

Auf der Basis der nachrichtenbasierten Kommunikation wird das Erzeuger- 

Verbraucher Problem mit Hilfe von ×Ò und Ö Ú Operationen realisiert. 

ÖÞÙÖ Ë 


ÔÖÓÙÞÖ ØÒÒØ 

×Ò ØÒÒØ 

 

ÎÖÖÙ Ö 


Ö Ú Ë ØÒÒØ 

ÚÖÖÙ ØÒÒØ 

 

Es existiert kein gemeinsamer Speicherbereich, der bzgl. der Zugriffe von 

Erzeuger und Verbraucher synchroniert werden muss. Die Synchronisation von 

Erzeuger und Verbraucher erfolgt durch das Kommunikationssystem selbst. 

7.3.3 Modellierung durch ein Petrinetz 

Petri-Netze dienen häufig zur Modellierung von Kommunikationsabläufen, 

sogenannten Kommunikationsprotokollen. Sie ermöglichen die Analyse der 

Protokolle, z.B. Erkennung von Verklemmungen. Modellierung einer synchronen 

Kommunikation: 

204


Prozess 1 

send 

message 

wait for 

ack. 

receive 

ack. 

Problem: unendliches Warten 

Sendebereit 

buffer full 

buffer full 

message 

received 

ack. received ack. sent 

pragmatische Lösung mit Hilfe von Timeouts 

receive 

message 

send 

ack. 

Prozess 2 

¯ Sender bzw. Empfänger warten nur eine festgelegte Zeit, Sender: falls kein 

Acknowledgement eintrifft, z.B. erneutes Senden. 

¯ Probleme dabei? u.a. Duplikate müssen vom Empfänger erkannt werden; 

gesendete Nachrichten kommen zu spät an, sind veraltet etc. Gleiche Probleme 

auch in Rechnernetzen: dafür gibt es Protokolle, die die Abläufe genau regeln. 

Sequenznummern können als Nachrichtenidentifikatoren dienen. 

7.3.4 Ports 

Bisher wurde davon ausgegangen, dass ein Prozess eine Nachricht mittels 

Ö Ú in seinen Adressraum entgegennehmen kann. Dazu wurde jedem 

Prozess ein eigener Nachrichtenpuffer für neu eingetroffene, jedoch noch nicht 

abgelieferte Nachrichten zugeordnet. Bisher bestand zwischen Sender und 

Empfänger eine feste Beziehung, die über Prozessidentifikatoren (z.B. Namen 

oder Nummer) hergestellt wurde. Nachteile 

205


Prozessnummern ändern sich mit jedem Neustart. 

Prozessnamen sind nicht eindeutig, z.B. falls Programm mehrmals gestartet 

wurde. 

Deshalb Senden von Nachrichten an Ports. Sie stellen Endpunkte einer 

Kommunikation dar. Sie können bei Bedarf dynamisch eingerichtet und gelöscht 

werden. Dazu existieren folgende Funktionen: 

ÔÓÖØÁ ÖØÈÓÖØ 

ÐØÈÓÖØ ÔÓÖØÁ 

×Ò ÔÓÖØÁ Ñ×× 

Ö Ú ÔÓÖØÁ Ñ×× 

Mittels ÖØÈÓÖØ wird ein neuer Kommunikationsendpunkt eingerichtet und 

mit dem Adressraum des Prozesses (z.B. Empfänger E) verbunden. Andere 

Prozesse, z.B. Sender S, kann nun Nachrichten an den Port des Empfängers 

senden. Die Ö Ú Operation benötigt nun den Parameter portID zur 

Selektion des Ports. Ports sind eine logische Abstraktion der Adressräume; sie 

repräsentieren keine physischen Ports (z.B. serieller oder paralleler Anschluss). 

Der Port agiert hier wie eine Warteschlange für den Empfänger E; die 

Auslieferung der Nachricht kann willkürlich, festgelegt durch die Reihenfolge 

des Eintreffens der Nachrichten, oder festgelegt durch die Nachrichtenprioritäten 

erfolgen. 

¯ ein Port ist mit dem Adressraum des zugehörigen Prozesses verbunden. 

¯ der Empfängerprozess kann sender-spezifische Ports einrichten. Jedem Port 

kann ein eigener Thread zugeordnet werden, der die Nachrichten an diesen 

Port bearbeitet. Im Ruhezustand ist kein Port eingerichtet, d.h. der Empfänger 

kann nur über den fest mit seinem Adressraum assoziierten Nachrichtenpuffer 

angesprochen werden. 

¯ ein Rechner mit einer IP-Adresse unterstützt mehrere tausend Ports. Für das 

TCP-Protokoll sind es 65 535 unterstützte Ports. 

¯ der Name des Port ist für einen Rechner eindeutig. Ein Betriebssystem 

verwaltet eine bestimmte Anzahl von Ports, die es entweder fest oder 

dynamisch verschiedenen Protokollen bzw. deren zugehörigen Applikationen 

zuordnen kann. 

¯ die Portnummern 1 - 1023 sind fest reserviert für bestimmte Protokolle (bzw. 

deren Applikationen). 

¯ Übersicht: fest zugeordnete Ports 

206


Protokoll Port Beschreibung 

FTP 21 Kommandos für Dateitransfer (get, put) 

Telnet 23 interaktive Terminal-Sitzung mit entferntem 

Rechner 

SMTP 25 Senden von Email zwischen Rechnern 

time 37 Time-Server liefert aktuelle Zeit 

finger 79 liefert Informationen über einen Benutzer 

HTTP 80 Protokoll des World Wide Web 

POP3 110 Zugang zu Email durch einen sporadisch 

verbundenen Client 

RMI 1099 Zugang zum Registrieren von entfernten 

Java Objekten. 

7.3.5 Kanäle 

Bisher wurde von einer verbindungslosen Kommunikation ausgegangen, d.h. eine 

Nachricht kann an einen Port geschickt werden. Bei einer verbindungsorientierten 

Kommunikation muss zuerst eine logische Verbindung zwischen den Kommunikationspartner 

eingerichtet werden Kanal ("socket"). 

¯ Einrichtung eines Kanals zwischen Ports, d.h. Verknüpfen zweier Ports. 

¯ bidirektionale Übertragung über Kanäle. Ports sind nicht mehr nur 

Empfangsstellen für Nachrichten, sondern sie dienen auch als Quellen. Damit 

sind komplexere Auftragsbeziehungen zwischen den Kommunikationspartnern 

möglich. Beispielsweise müssen nicht alle benötigten Daten in der 

Auftragsnachricht mitgeschickt werden, sondern sie können bei Bedarf vom 

beauftragten Prozess angefordert werden. 

¯ Die Sende- bzw. Empfangsoperation bezieht sich auf die lokale PortID; 

×Ò ÐÓ Ð ÔÓÖØÁ Ñ×× 

Ö Ú ÐÓ Ð ÔÓÖØÁ Ñ×× 

¯ TCP/IP unterstützt verbindungsorientierte Kommunikation. 

7.3.6 Ströme 

Ströme (engl. streams) sind eine Abstraktion von Kanälen. Sie verdecken die 

tatsächlichen Nachrichtengrenzen. Ein Sender schickt mittels send-Operationen 

Nachrichten an den Empfänger. Die Nachrichten werden jedoch logisch zu 

einem Bytestrom vereinigt, dem man auf Empfangsseite die Nachrichtengrenzen 

207

Schlichter, TU München 7.4. CLIENT-SERVER-MODELL 

nicht mehr entnehmen kann. Der Empfänger kann den Bytestrom in Portionen 

verarbeiten, ohne sich an den ursprünglichen Nachrichtengrenzen zu orientieren. 

Sender 

send (120 Bytes) 



Strom 

1 Byte 

receive (50 Bytes) 

receive (377 Bytes) 

Empfänger 

Bemerkung: breitbandige, verbindungsorientierte Kommunikation kann auch 

für Angriffe in vernetzten Systemen ausgenutzt werden. Ein Beispiel aus der 

Vergangenheit: Angriffe auf Yahoo und amazon.com. Aufbau einer Vielzahl Port- 

Verbindungen, Übertragung großer Datenmengen (1 GB) führte zum Lahmlegen 

des Dienstes ("Denial of Service"). 

¯ BS-Dienste: Verbindungsauf- und -abbau, schreiben in Strom, lesen aus Strom. 

¯ Beispiel: Ströme innerhalb eines Unix-Rechners über Pipe-Konzept: FIFOartiger 

Datentransfer mit Operationen: open pipe, read, write. 

¯ Dienste für Dateizugriffe oder Zugriffe auf Geräte: spezielle Ausprägung der 

stromorientierten Kommunikation. 

¯ I/O in Java basiert auf Ströme. 

Klasse Ú Ó ÇÙØÔÙØËØÖÑ zum Schreiben von Daten 

Klasse Ú Ó ÁÒÔÙØËØÖÑ zum Lesen von Daten 

Spezialisierungen z.B. durch FileOutputStream, BufferedOutputStream oder 

FileInputStream. 

7.4 Client-Server-Modell 

Client-Server Modell basiert i.a. auf der Kommunikationsklasse der synchronen 

Aufträge. Server stellen Dienste zur Verfügung, die von vorher unbekannten 

Clients in Anspruch genommen werden können. 

208

Schlichter, TU München 7.4. CLIENT-SERVER-MODELL 

Zeit 

Client C Server S 

blockiert 

Auftrag 

Resultat 

Ausführung 

Client ruft Operation eines Servers auf; nach Ausführung der Operation wird 

das Ergebnis an Client übergeben. Während der Ausführung der Operation wird 

Ablauf des Client meist unterbrochen. Eine leere Antwort ist möglich, falls die 

Operation kein Ergebnis liefert (z.B. Eintrag einer Informationseinheit in eine 

Datenbank). 

¯ Definitionen 

– Definition: Client 

Ein Client ist eine Anwendung, die auf einer Clientmaschine läuft und i.a. 

einen Auftrag initiiert, und die den geforderten Dienst von einem Server 

erhält. 

Clients sind meist a-priori nicht bekannt. Clients sind oft Benutzerprozesse, 

die dynamisch erzeugt und gelöscht werden. 

– Definition: Server 

Ein Server ist ein Subsystem, das auf einer Servermaschine läuft und einen 

bestimmten Dienst für a-priori unbekannte Clients zur Verfügung stellt. Es 

existiert eine einfache n:1 Auftragsbeziehung zwischen den Clients und 

einem Server. 

– Server sind dedizierte Prozesse, die kontinuierlich folgende Schleife 

abarbeiten. 


Ö Ú ÑÔÒ×ÔÓÖØ ÙØÖ 

Ö ÙØÖ Ù× ÙÒ ÖÞÙ ÒØÛÓÖØÒ Ö Ø 

×ØÑÑ ×ÒÔÓÖØ Ö ÒØÛÓÖØÒ Ö Ø 

×Ò ×ÒÔÓÖØ Ö×ÙÐØØ 

 

209

Schlichter, TU München 7.5. NETZWERKPROGRAMMIERUNG 

Der Empfangsport ist server-lokal; der Sendeport ist lokal beim Client. 

Ein Server kann intern aus einer Menge von Threads aufgebaut sein. Ein 

Thread, der sogenannte Listener wartet auf Aufträge. Er verteilt eintreffende 

Aufträge an sogenannte Worker-Threads, die die Bearbeitung eines Auftrags 

übernehmen. Die Ergebnisse werden direkt vom Worker-Thread an den 

Client weitergeleitet. 

– Client und Server kommunizieren über Nachrichten, wobei beide Systeme 

auf unterschiedlichen Rechnern ablaufen können und über ein Netz 

miteinander verbunden sind. 

¯ Beispiele für Dienste (Services), die mittels Server realisiert werden: 

Dateidienst, Zeitdienst, Namensdienst. 

¯ ein System kann sowohl Client als auch Server sein. 

– Beispiel 

Web 

Browser 

(Applets) 

Client 

Server 

Client 

HTTP 

Web 

Server 

cgi 

7.5 Netzwerkprogrammierung 

Server 

Anwendungs 

Server 

SQL 

Daten 

bank 

Bedingt durch rasche Verbreitung des Internet hat auch das Interesse an Netz- 

Anwendungen sehr zugenommen. Netz-Anwendungen sind verteilte Anwendun- 

210


gen, die jeweils aus mehreren Teilkomponenten bestehen und die im Netz verteilt 

auf verschiedenen Rechensystemen ausgeführt werden. Teilkomponenten sind 

hier nicht einzelne Objekte, sondern komplexe Verarbeitungseinheiten (z.B. ein 

Modul bestehend aus einer Menge von Objekten). Eine verteilte Anwendung 

ist eine Anwendung A, dessen Funktionalität in eine Menge von kooperierenden 

Teilkomponenten A , .., A ,n IN, n 1 zerlegt ist; 

1 n 

Jede Teilkomponente umfasst Daten (interner Zustand) und Operationen, die 

auf den internen Zustand angewendet werden. 

Teilkomponenten A i sind autonome Prozesse, die auf verschiedenen 

Rechensystemen ausgeführt werden können. Mehrere Teilkomponenten 

können demselben Rechensystem zugeordnet werden. 

Teilkomponenten A tauschen über das Netz untereinander Informationen aus. 

i 

Die Teilkomponenten können z.B. auf der Basis des Client-Server Modells realisiert 

werden. Beispiele von verteilten Anwendungen sind Softwaresysteme für 

verteilte Geldautomaten oder Flugbuchungssysteme. Netzwerkprogrammierung 

ist ein Hilfsmittel zur Implementierung verteilter Anwendungen. 

7.5.1 Einführung 

In Berkeley Unix wurde das Konzept von Sockets eingeführt, um die 

Netzwerkprogrammierung zu erleichtern. Sie erlauben jede Netzverbindung 

als einen Strom von Bytes zu betrachten, die gelesen bzw. geschrieben 

werden können. Ein Socket definiert einen einfachen, bidirektionalen 

Kommunikationskanal (siehe Seite 207) zwischen 2 Rechensystemen, mit Hilfe 

dessen 2 Prozesse über ein Netz miteinander kommunizieren können. 

Input Strom 

Client Server 

Output Strom 

Socket Verbindung 

211


Socket Grundlagen 

Sockets abstrahieren von den technischen Details eines Netzes, z.B. Übertragungsmedium, 

Paketgröße, Paketwiederholung bei Fehlern, Netzadressen. Anfänglich 

standen Sockets nur in Unix Umgebungen zur Verfügung. In der Zwischenzeit 

werden sie auch von Windows, dem MacOs und von Java unterstützt. 

¯ Ein Socket kombiniert 2 Ströme, einen Input- und einen Output-Strom. 

¯ Ein Socket unterstützt die folgenden Basisoperationen: 

richte Verbindung zu entferntem Rechner ein ("connect"). 

sende Daten. 

empfange Daten. 

schließe Verbindung. 

assoziiere Socket mit einem Port. 

warte auf eintreffende Daten ("listen"). 

akzeptiere Verbindungswünsche von entfernten Rechnern (bzgl. assoziiertem 

Port). 

Die ersten 4 Operationen sind sowohl für den Client als auch den Server 

relevant (siehe Java's Socket Class), während die letzten 3 Operationen nur 

für einen Server von Bedeutung sind (siehe Java ServerSocket Class). Die 

Endpunkte einer Socket werden durch Ports repräsentiert. 

7.5.2 Server Protokoll 

Ein Server kommuniziert mit einer Menge von Clients, die a priori nicht bekannt 

sind. Ein Server benötigt eine Komponente (z.B. ein Verteiler-Thread (siehe 

Seite 92)), die auf eintreffende Verbindungswünsche reagiert. Diese Komponente 

wird auch Listener genannt. Der Hauptunterschied zwischen Client und Server 

bzgl. der Socket-Verbindung liegt darin, dass ein Server die Assoziierung mit 

einem Port vornimmt und Verbindungswünsche akzeptiert. 

¯ Informeller Ablauf aus Serversicht 

1. Erzeugen eines SocketServer und Binden an einen bestimmten Port. Ein Port 

entspricht einer FIFO Warteschlange. Sie sammelt die Verbindungswünsche 

der Clients. Die maximale Länge ist abhängig vom Betriebssystem, z.B. 50. 

Falls die Warteschlange voll ist, werden keine weiteren Verbindungswünsche 

akzeptiert. 

212


2. Warten auf Verbindungswünsche von Clients. Falls der Client bzgl. einer 

Socketverbindung autorisiert ist, akzeptiert der Server den Verbindungswunsch. 

Der Server wird blockiert, bis die accept-Methode des Servers die 

Verbindung zwischen Client und Server eingerichtet hat. Die beiden Ströme 

der Socketverbindung werden eingerichtet. 

3. Austausch von Daten zwischen Client und Server entsprechend einem 

wohldefinierten Protokoll (z.B. HTTP). 

4. Schließen einer Verbindung (durch Server, durch Client oder durch beide); 

weiter bei Schritt 2. 

¯ Programmstück 

ËÓ Ø ×Ó Ø ÖÖÒ ØÓ ×Ó Ø 

ËÖÚÖËÓ Ø ÔÓÖØ Ø ÔÓÖØ Ø ×ÖÚÖ Ð×ØÒ× ØÓ 

ØÖÝ ß 

ÔÓÖØ ÒÛ ËÖÚÖËÓ Ø 

×Ó Ø ÔÓÖØ ÔØ ÛØ ÓÖ ÐÒØ ÐÐ 

ÓÑÑÙÒ Ø ÛØ ÐÒØ 

×Ó Ø ÐÓ× 

 

Ø ÁÇÜ ÔØÓÒ ß ÔÖÒØËØ ÌÖ 

¯ Für das Abhören des Ports kann ein eigener Verteiler-Thread spezifiziert 

werden; die Bearbeitung übernehmen sogenannte Worker-Threads. Der Unix 

FTP Server erzeugt i.a. für jede Verbindung einen eigenen Prozess, was einen 

großen Overhead verursacht FTP Server können deshalb oft nicht mehr als 

400 offene Verbindungen unterstützen, falls noch vernünftige Antwortzeiten 

erwartet werden. 

7.5.3 Client Protokoll 

Der Client initiiert eine Socket-Verbindung durch Senden eines Verbindungswunsches 

an den Port des Servers. 

Informeller Ablauf aus Clientsicht 

1. Erzeugen einer Socket Verbindung. Dazu muss die Adresse des Servers (z.B. 

Internet-Adresse) und der Port, auf dem der Server wartet, angegeben werden. 

2. Austausch von Daten zwischen Client und Server über die Duplex-Verbindung 

entsprechend einem wohldefinierten Protokoll (z.B. HTTP). 

3. Schließen einer Verbindung (durch Server, durch Client oder durch beide). 

213


Programmstück 

ËÓ Ø ÓÒÒ ØÓÒ ÖÖÒ ØÓ ×Ó Ø 

ØÖÝ ß 

ÓÒÒ ØÓÒ ÒÛ ËÓ Ø ÛÛÛ Ò ØÙÑ 

ÓÑÑÙÒ Ø ÛØ ÐÒØ 

ÓÒÒ ØÓÒ ÐÓ× 

 

Ø ÁÇÜ ÔØÓÒ ß ÔÖÒØËØ ÌÖ 

7.5.4 Bidirektionale Stromverbindung 

Sockets bestehen aus 2 Strömen für die Duplexverbindung zwischen Client 

und Server. Diese beiden Ströme werden automatisch beim Einrichten einer 

Socket-Verbindung erzeugt. Durch die Verwendung von Strömen kann dieselbe 

Programmiermethode verwendet wie bei I/O, Dateizugriff, etc. 

¯ Schreiben auf Socket 

ÚÓ ÛÖØÌÓËÓ Ø ËÓ Ø ×Ó ËØÖÒ ×ØÖ ØÖÓÛ× 

ÁÇÜ ÔØÓÒ ß 

ÓËØÖÑ ×Ó ØÇÙØÔÙØËØÖÑ 

ÓÖ ÒØ ×ØÖ ÐÒØ 

ÓËØÖÑ ÛÖØ ×ØÖ ÖØ 

 

¯ Lesen von Socket 

ËØÖÒ ÖÖÓÑËÓ Ø ËÓ Ø ×Ó ØÖÓÛ× ÁÇÜ ÔØÓÒ ß 

ËØÖÑ ×Ó ØÁÒÔÙØËØÖÑ 

ËØÖÒ ×ØÖ 

Ö 

ÛÐ Ö ËØÖÑ Ö Ò 

×ØÖ ×ØÖ 

ÖØÙÖÒ ×ØÖ 

 

Man beachte, dass ein Byte und Char nicht direkt verglichen werden können. 

Deshalb muss das Byte in ein Char konvertiert werden. Vom Strom wird jeweils 

bis zum nächsten Zeilenende gelesen. Die gelesene Zeile wird als Ergebnis 

zurückgegeben. 

7.5.5 Java Socket Class 

Java unterstützt die beiden grundlegenden Klassen: 

214


Ú ÒØ ËÓ Ø zur Realisierung der Client-Seite einer Socket. 

Ú ÒØ ËÖÚÖËÓ Ø zur Realisierung der Server-Seite einer Socket. 

Client-Seite einer Socket 

¯ Constructor 

ÔÙÐ ËÓ Ø ËØÖÒ Ó×Ø ÒØ ÔÓÖØ 

ØÖÓÛ× ÍÒÒÓÛÒÀÓ×ØÜ ÔØÓÒ ÁÇÜ ÔØÓÒ 

Der Parameter host ist ein Rechnername, z.B. www11.in.tum.de. Falls der 

Domain Name Server den Parameter host nicht auflösen kann, wird die 

Exception ÍÒÒÓÛÒÀÓ×ØÜ ÔØÓÒ ausgelöst. Falls die Socket aus einem 

anderen Grund nicht geöffnet werden kann, wird ÁÇÜ ÔØÓÒ ausgelöst, z.B. 

der entfernte Host akzeptiert keine Verbindungen. Es gibt noch eine Reihe 

anderer Konstruktoren Þ 

ÔÙÐ ËÓ Ø ÁÒØÖ×× Ó×Ø ÒØ ÔÓÖØ ØÖÓÛ× ÁÇÜ ÔØÓÒ 

Das Objekt der Klasse InetAddress umfasst den Rechnernamen und seine IP- 

Adresse, d.h. eine Auflösung durch den Domain Name Server ist nicht mehr 

notwendig. 

¯ Information über eine Socket 

ÔÙÐ ÁÒØÖ×× ØÁÒØÖ×× 

liefert als Ergebnis den Namen und IP-Adresse des entfernten Rechners, zu 

dem die Socket-Verbindung existiert. 

ÔÙÐ ÒØ ØÈÓÖØ 

liefert als Ergebnis die Nummer des Ports, mit dem die Socket-Verbindung 

am entfernten Rechner assoziiert ist. 

ÔÙÐ ÒØ ØÄÓ ÐÈÓÖØ 

liefert als Ergebnis die Nummer des Ports, mit dem die Socket-Verbindung 

am lokalen Rechner assoziiert ist. 

¯ Ein-/Ausgabe 

ÔÙÐ ÁÒÔÙØËØÖÑ ØÁÒÔÙØËØÖÑ ØÖÓÛ× ÁÇÜ ÔØÓÒ 

liefert den InputStream, von dem Daten gelesen werden können. Er 

unterstützt die Methode read zum Lesen der Daten. InputStream ist ein 

Basis-Strom, der mit Hilfe von SubClassing spezialisiert werden kann. 

ÔÙÐ ÇÙØÔÙØËØÖÑ ØÇÙØÔÙØËØÖÑ ØÖÓÛ× ÁÇÜ ÔØÓÒ 

liefert den OutputStream, in dem Daten geschrieben werden können. Er 

unterstützt die Methode write zum Schreiben der Daten. OutputStream ist 

ein Basis-Strom, der mit Hilfe von SubClassing spezialisiert werden kann. 

215

Schlichter, TU München 7.6. REMOTE PROCEDURE CALL 

Die beiden Methoden stehen natürlich auch auf Server-Seite einer Socket- 

Verbindung zur Verfügung. 

Server-Seite einer Socket 

¯ Constructor 

ÔÙÐ ËÖÚÖËÓ Ø ÒØ ÔÓÖØ 

ØÖÓÛ× ÁÇÜ ÔØÓÒ ÒÜ ÔØÓÒ 

erzeugt eine Socket auf Server-Seite und assoziiert sie mit dem Port. Falls 

die Socket nicht an den angegebenen Port gebunden werden kann, wird 

ÒÜ ÔØÓÒ ausgelöst. Es existieren noch weitere Konstruktoren, z.B. 

ÔÙÐ ËÖÚÖËÓ Ø ÒØ ÔÓÖØ ÒØ ÕÙÙÄÒØ 

ØÖÓÛ× ÁÇÜ ÔØÓÒ ÒÜ ÔØÓÒ 

Die Länge der mit dem Port verbundenen Warteschlange wird durch den 

Parameter queueLength angegeben. 

¯ Einrichten/Schließen einer Verbindung 

ÔÙÐ ËÓ Ø ÔØ ØÖÓÛ× ÁÇÜ ÔØÓÒ 

diese Methode blockiert und wartet auf Verbindungswünsche von Clients. 

ÔÙÐ ÚÓ ÐÓ× ØÖÓÛ× ÁÇÜ ÔØÓÒ 

¯ Ein-/Ausgabe 

ÔÙÐ ÁÒÔÙØËØÖÑ ØÁÒÔÙØËØÖÑ ØÖÓÛ× ÁÇÜ ÔØÓÒ 

liefert den InputStream, von dem Daten gelesen werden können. 

ÔÙÐ ÇÙØÔÙØËØÖÑ ØÇÙØÔÙØËØÖÑ ØÖÓÛ× ÁÇÜ ÔØÓÒ 

liefert den OutputStream, in dem Daten geschrieben werden können. 

7.6 Remote Procedure Call 

Realisierung des Client-Server Modells auf der Basis von Auftrags- und 

Antwortnachrichten ist komplex und fehleranfällig, da der Programmierer explizit 

den Code für den Aufbau und die Interpretation der Nachrichten entwerfen und 

implementieren muss. 

Meist wird deshalb die Abstraktion des entfernten Prozeduraufrufs, 

genannt RPC ("remote procedure call") zur Realisierung des Client-Server 

Modells verwendet. 

¯ Lokaler Prozeduraufruf 

216


Aufruf 

Aufrufer Prozedur 

Antwort 

einzelner Prozess 

Eine Prozedur wird traditionell als Mittel zur Strukturierung der Funktionalität 

verwendet; die Implementierung einer Prozedur wird nach außen hin 

verborgen. Bei Prozeduraufruf werden sowohl Daten als auch Ablaufkontrolle 

vom Aufrufer an die Prozedur übergeben. Es findet ein verzahnter Ablauf 

von Aufrufer und Prozedur ("single-threaded execution"). Beide, Aufrufer und 

Prozedur, werden im gleichen Adressraum ausgeführt. RPC ist die Erweiterung 

derselben Art von Kommunikation auf Programme, die auf verschiedenen 

Rechnern ablaufen; der verzahnte Ablauf und Transfer von Daten bleiben 

erhalten. 

¯ RPC ist eine Verallgemeinerung des lokalen Prozeduraufrufs. Ähnlich wie ihn 

höhere Programmiersprachen wie Modula, Pascal oder C unterstützen. 

¯ Das RPC-Konzept ist die sprachorientierte Variante der synchronen, auftragsorientierten 

Kommunikation., d.h. RPC = synchroner Auftrag. 

¯ Definition 

– Remote Procedure Call (nach Nelson 1982) 

"RPC" ist die synchrone Kontrollfluss- und Datenübergabe in Form von 

Prozeduraufrufen und von aktuellen Parametern zwischen Programmen in 

unterschiedlichen Adressräumen über einen schmalen Kanal (im Sinne von 

Durchsatz und Verweilzeit). 

217


synchron: der aufrufende Client blockiert solange bis er vom Server 

eine Rückmeldung nach Ende der Prozedurbearbeitung erhält; in der 

Praxis wird dies nicht so streng durchgeführt, da sonst der Client 

möglicherweise unendlich lange warten müsste (Absturz eines Servers) 

deshalb Timeout. 

Programmiersprache: RPC Aufrufe sind syntaktisch und semantisch in 

eine Programmiersprache eingebettet. 

unterschiedliche Adressräume: für Client und Server können keine netzweit 

eindeutigen Speicheradressen vorausgesetzt werden. Sonderbehandlung 

von Pointer erforderlich. 

schmaler Kanal: RPC Kommunikation findet über einen speziellen 

Interaktionspfad statt (z.B. lokales Netz), der nicht so leistungsfähig ist 

wie der lokale, im eigenen Rechner vorhandene Interaktionspfad. 

– Ablaufkontrolle 

ausführend 

wartend 

ausführend 

Aufruf 

Schnittstelle zum 

entfernten System 

Programm Prozedur 

aufrufender 

Prozess 

Aufruf 

Schnittstelle zum 

entfernten System 

Antwort 

Antwort 

aufgerufener 

Prozess 

wartend 

ausführend 

¯ Lokaler vs. entfernter Prozeduraufruf 

Die Attraktivität des RPC-Konzeptes liegt darin, dass mit dem Prozedurkonzept 

218


vertraute Programmierer nicht umdenken müssen, wenn sie die Interaktion 

zwischen Programmen in disjunkten Adressräumen organisieren. Da es 

prinzipiell unerheblich ist, ob die Adressräume auf einem oder mehreren Rechnerknoten 

installiert sind, bietet sich der RPC-Mechanismus als elementares 

Kommunikationsmittel in verteilten Systemen an. Inzwischen werden RPC- 

Systeme als Laufzeitpakete von gängigen Betriebssystemen und Plattformen 

für verschiedene Sprachen angeboten. 

– Unterschiede zwischen RPC und lokalem Prozeduraufruf 

Bei einem RPC haben beide Prozesse (aufrufender und aufgerufener) 

£ keinen gemeinsamen Adressraum. Damit ist kein Zugriff auf gemeinsame 

globale Daten möglich. Auch ist die Übertragung von Arbeitsspeicheradressen 

problematisch, d.h. call-by-reference" ist i.a. nicht realisierbar. 

Die aufgerufene Prozedur kann mit Zeigern auf einen fremden Adressraum 

wenig anfangen. 

£ keine gemeinsame Ausführungsumgebung. Es sind heterogene Ablaufsysteme 

oder Rechensystem mit unterschiedlichen Datendarstellungen 

möglich. 

£ unterschiedliche Lebensdauer. Üblicherweise sind Clients kurzlebig, 

während Server eher langlebig sind, d.h. sie werden bei Systemstart 

automatisch gestartet. 

£ Fehler, bedingt durch Maschinenausfälle oder Kommunikationsfehler. 

Bei der Programmierung von RPC basierten Anwendungen müssen 

Kommunikationsfehler berücksichtigt werden. 

– Eigenschaften des RPC-Konzepts 

£ einheitliche Aufrufsemantik. Für den Anwendungsprogrammierer gibt 

es keinen Unterschied zwischen dem Aufruf einer lokalen und einer 

entfernten Prozedur. 

£ "type-checking". Die Überprüfung der Datentypen für Parameter und 

Ergebnis findet zur Übersetzungszeit statt. Falls die Kommunikation 

zwischen Client und Server nur auf der Nachrichtenebene durch den 

Programmierer realisiert werden muss, dann erfolgt durch das System 

keine Überprüfung der Datentypen. 

£ volle Parameterfunktionalität. Der Anwendungsprogrammierer muss aus 

Übergabeparameter keine Nachrichtensequenz aufbauen. Jedoch gibt es 

gegenüber lokalen Prozeduraufrufen einige wesentliche Unterschiede. 

219


Beispielsweise gibt es bei lokalen Prozeduraufrufen die üblichen 

Parameterübergaben "call-by-value" und "call-by-reference"; letzters 

kann bei RPC nicht so ohne weiteres bereitgestellt werden, da kein 

gemeinsamer Adressraum existiert. Eine Möglichkeit besteht in dem 

Kopieren der Datenstrukturen zum Server und wieder zurück zum 

Client "call-by-copy/restore". 

£ Optimierung der Antwortzeit. Beim RPC-Mechanismus ist die Anwortzeit 

und nicht der Durchsatz die Größe, die optimiert werden soll. 

£ Transparenz. Transparenz für den Programmierer hinsichtlich der 

Ausnahmebehandlung von Kommunikationsfehler. 

¯ Stubs 

Sowohl auf der Client als auch auf der Serverseite werden Stubs verwendet, 

um die Besonderheiten von RPC-Aufrufen und die Kommunikation mit dem 

Netzwerk Code vom Anwendungsprogramm zu isolieren. 

Aufruf 

Client C Server S 

Antwort 

1 8 

5 4 

Client 

7 

Kommunikations- 

6 

Server 

Stub 

netz 

Stub 

2 3 

Im verteilten Fall sind Client C und Server S nicht zum selben ausführbaren 

Code gebunden (anders im lokalen Fall); ein Stub enthält einen Stellvertreter 

für jede entfernte Prozedur P; der eigentliche, ausführbare Code von P ist 

Teil von S. Stubs übernehmen auch die Konvertierung der Parameter und der 

Ergebnisse zwischen internen und externen Darstellungen, d.h. sie rufen die 

entsprechenden Datentransformations-Prozeduren ("Filter") auf. 

– Client Stub: enthält Stellvertreter Definition von Prozedur P. 

– Server Stub: enthält Stellvertreter Aufruf von Prozedur P 

– Aufgaben der Stubs 

Die Stubs sind gewöhnlich statisch mit dem Hauptprogramm gebunden. 

£ Aufgaben Client Stub 

Im Client Stub werden die Anforderungsnachrichten ("requests") erzeugt 

und an die darunterliegende TCP-Schicht weitergegeben. 

220


Æ Spezifikation der aufgerufenen Prozedur. 

Æ Zuordnung des Aufrufes zu Zielrechner. 

Æ Darstellung der Parameter im Übertragungsformat; Problem: unterschiedliche 

Rechner mit unterschiedlichen Datenformaten. 

Æ Dekodieren der Ergebnisse und Übergabe an den Client. 

Æ Blockierung des Client aufheben. 

£ Aufgaben Server Stub 

Æ Dekodieren des Aufrufs und der Parameter. 

Æ Bestimmung der Aufrufadresse der Prozedur (z.B. mittels einer 

Tabelle). 

Æ Aufruf der Prozedur. Die eigentliche Bearbeitung des Aufrufs erfolgt 

durch Server-Prozeduren. 

Æ Kodierung der Ergebnisse. Quittung, Routing und Wiederholung von 

Übertragungspaketen wird durch das darunterliegende Transportprotokoll 

erledigt. 

¯ Wichtige Fragestellungen 

Im Zusammenhang mit dem RPC-Konzept gibt es eine Reihe von Fragestellungen, 

die behandelt werden müssen. 

– Wer ist für das Schreiben der Stubs verantwortlich?Die manuelle Implementierung 

von Stubs und deren Schnittstellen zum Netzwerk Code ist oft 

aufwendig und fehlerträchtig. Deshalb wird eine automatische Erstellung 

der Schnittstelle zwischen Client und Server aus einer deklarativen Beschreibung 

angestrebt. 

£ Beschreibung der Schnittstelle zwischen Client und Server mit Hilfe 

einer deklarative Beschreibungssprache (z.B. Corba IDL); Generierung 

der Stubs auf der Basis der Schnittstellenbeschreibung RPC Generator. 

£ Erleichtert die Implementierung fehlerfreier Stubs. 

– Woher erfährt der Client die Adresse des Servers, an den er den Aufruf 

schicken muss?Der Server registriert seine Operation, d.h. er exportiert seine 

Schnittstelle. Daraufhin importiert der Client die Serverschnittstelle, d.h. es 

erfolgt ein Binden zwischen Client und Server. Der Bindevorgang selbst 

kann entweder statisch, semi-statisch oder dynamisch ablaufen. 

£ Unterschiedliche Varianten: 

Serveradresse fest verdrahtet im Client-Quellprogramm. 

Anfrage bei einem Namensdienst. Diese Anfrage kann entweder 

am Anfang bei der Client Initialisierung oder vor jedem RPC-Aufruf 

erfolgen. 

221


– Wie können sich Server gegen unautorisierte Zugriffe abschirmen?Dieser 

Aspekt ist insbesondere im Internet, aber auch für Intranets von großer 

Bedeutung. 

£ Ausweisen über Passwörter oder Zertifikate. Im Hauptstudium werden 

die Authentisierungsprotokolle, z.B. Kerberos im Detail besprochen. Ein 

weiterer Aspekt ist die Verschlüsselung des Datenaustausches zwischen 

Client und Server, um die Information gegenüber Dritte geheimzuhalten. 

– Wie geht man Heterogenität um? 

£ Unterschiedliche Rechnerarchitekturen verwenden auch unterschiedliche 

Datendarstellungen, z.B. für integer Zahlen Stubs müssen Daten in ein 

allgemein gültiges Format konvertieren (z.B. XDR). 

– Wie geht man mit Kommunikationsfehler bzw. Rechnerabstürzen 

um?Rechnerabstürze beziehen sich sowohl auf die Client- als auch auf die 

Servermaschine. Beide Rechner können unabhängig voneinander abstürzen. 

Kommunikationsfehler werden teilweise durch das TCP Protokoll behandelt, 

während Serverabstürze durch den Client bzw. das RPC-Ablaufsystem behandelt 

werden müssen. 

222

Kapitel 8 

Sicherheit in Rechensystemen 

In Rechensystemen, die mehreren Benutzern zugänglich sind, ist eine Kontrolle 

des Zugriffs auf das Rechensystem selbst, dessen Dienstleistungen und 

Datenbestände erforderlich. 


Dieser Abschnitt behandelt die Sicherheitsproblematik in zentralen und verteilten 

Rechensystemen. Dazu werden verschiedene Schutzmechanismen auf Betriebssystemebene 

und für verteilte Systeme vorgestellt. 

¯ Zugriffsschutz in Rechensystemen. 

¯ Schutzmatrix, insbesondere Zugriffskontrollisten und Capability-Listen. 

¯ kurze Einführung in Kryprosysteme. 

¯ Authentifizierung in verteilten Systemen. 

Die verschiedenen Aspekte der Sicherheit in Rechensystemen werden nur 

einführend, und nicht erschöpfend behandelt. Für eine detaillierte Behandlung 

der Sicherheitsproblematik sei der Leser auf entsprechende Lehrveranstaltungen 

oder die Literatur verwiesen. 

8.2 Motivation 

Was versteht man unter Sicherheit im Bezug auf Rechensysteme? 

223


Jemand: Unterscheidung von Personen und Gruppen von Personen 

davon abhalten: durch technische und organisatorische Maßnahmen 

einige: Begrenzung durch unser Vorstellungsvermögen 

unerwünschte Dinge zu tun: 

1) nicht autorisiert Daten lesen (Geheimhaltung), 

2) nicht autorisiert Daten schreiben (Integrität), 

3) unter "falscher Flagge" arbeiten (Authentizität), 

4) nicht autorisiert Ressourcen verbrauchen (Verfügbarkeit), 

usw. 

zu tun. 

¯ Unterscheidung zwischen Angriffen von 

innen. Der Angreifer ist in das Rechensystem bereits eingeloggt und 

verschafft sich illegalen Zugriff auf Ressourcen oder Berechtigungen, 

z.B. Systemadministrator-Rechte. Mögliche Angriffstechniken sind 

Trojanische Pferde, Login-Attrappen, die Nutzung von Hintertüren in 

einem Softwaresystem ("trap door") oder die Ausnutzung eines künstlich 

herbeigeführten Pufferüberlaufs. 

außen. Durch die Vernetzung von Rechnern finden verstärkt auch Angriffe 

von entfernten Rechnern über ein Rechnernetz (z.B. das Internet) statt. 

Beispiele für mögliche Angriffstechniken sind sogenannte "war-dialer" 

(Ausprobieren von Telefonnummern und Passwörtern) oder die Verbreitung 

von Viren. 

¯ Beispiel: Login-Attrappe 

Nutzung von Login-Attrappen in Rechnerumgebungen, wo Rechner von 

mehreren Benutzern verwendet werden, um geschützte Benutzerpasswörter zu 

erfassen (z.B. in Informatikhalle der Informatik-Fakultät). 

– Angreifer startet ein Benutzerprogramm, das am Bildschirm einen Login- 

Screen simuliert. Der Angreifer gibt, ohne sich auszuloggen den Rechner 

frei. Da am Bildschirm der Login-Screen angezeigt wird, ist ein 

nachfolgender Benutzer der Meinung, dass der Rechner verfügbar ist (es sitzt 

ja niemand davor und der vorhergehende Benutzer habe durch Ausloggen 

seine Sitzung beendet, da der wohlbekannte Login-Screen angezeigt wird). 

– Der ahnungslose Benutzer tippt Benutzername und sein privates Passwort. 

Angreiferprogramm speichert Benutzername und Passwort in einer 

Datei. 

224


Angreiferprogramm terminiert das aktuelle Shell-Programm ("kill" 

Systemaufruf) Login-Sitzung des Angreifers wird beendet und 

regulärer Login-Screen wird angezeigt. 

Der ahnungslose Benutzer nimmt an, dass er sich beim ersten Eintippen 

seines Namens oder seines Passwortes vertippt hat und gibt die beiden Daten 

erneut ein. Der Angreifer kann auf diese Weise die Passwörter der anderen 

Benutzer erfassen. 

– Abhilfe: Login-Sequenz wird durch Tastensequenz gestartet, die von einem 

Benutzerprogramm nicht erfasst werden kann, z.B. CTRL-ALT-DEL bei 

Windows 2000. Falls ein Benutzer diese Tastensequenz eingibt, wird der 

aktuelle Benutzer automatisch ausgeloggt und das Login-Programm durch 

das Betriebssystem gestartet. Es gibt keinen Weg, um dieses Verhalten des 

Betriebssystems zu umgehen. 

¯ Beispiel: Pufferüberlauf 

Durch einen künstlich herbeigeführten Pufferüberlauf kann ein Angreifer die 

Ausführung seines eigenen Programms veranlassen und oft auch noch die 

Systemadministrator-Berechtigung (root) erlangen. 

– Hintergrund 

Die meisten C-Compiler und Laufzeitsysteme überprüfen nicht die Einhaltung 

der Feldgrenzen. Da viele aktuelle Betriebssysteme auf der Basis von C 

realisiert wurden, ist diese Problematik von großer Bedeutung. 

ÒØ 

Ö ℄ 

 

℄ 

Die Codesequenz ist zwar falsch. Das Laufzeitsystem führt jedoch keine 

Überprüfung durch; der Fehler bleibt unentdeckt. In den meisten Fällen 

führt dieser Fehler über kurz oder lang jedoch zu einem Programmabsturz 

(oft ein Nullpointer). Ein Angreifer kann diese Eigenschaft nutzen, um 

Teile des Laufzeitkellers zu überschreiben. Ein Beispiel wäre, das Feld 

c für die Speicherung des Pfadnamen einer Datei vorzusehen. Da das 

Betriebssystem nur maximal 256 Zeichen pro Pfadenamen unterstützt, ist für 

den Programmierer die Länge von c ausreichend. Ein Angreifer kann nun 

einen Datei-Pfadnamen angeben, der erheblich länger als 256 ist. 

– Veränderung der Rücksprungadresse 

225


Keller 

Variable 

Hauptprogramm 

Programm 

Ablauf 

Hauptprogramm 

SP 

SP 

Variable 

Hauptprogramm 

Rückkehradresse 


von A 

Feld C 

Programm 

nach Aufruf der 

Prozedur A 

C 

SP 

Variable 

Hauptprogramm 

Rückkehradresse 


von A 

Feld C 

Programm 

nach Pufferüberlauf 

Durch sorgfältiges Analysieren und Berechnen des Speicherlayouts kann 

der Angreifer bei Pufferüberlauf die Rückspungadresse der aufgerufenen 

Prozedur überschreiben. Der Angreifer überschreibt den Laufzeitkeller 

von A einschließlich des Feldes C und der Rücksprungadresse. Die neue 

Rücksprungadresse zeigt an den Anfang des Puffers c, an deren Stelle das 

vom Angreifer gewünschte ausführbare Programm steht. Der Angreifer 

überschreibt als nicht nur die Rücksprungadresse, sondern trägt auch sein 

Angriffsprogramm in den Keller des Hostprogramms ein. Beispielsweise 

beinhaltet die Zuweisung an das Feld c nicht den Dateinamen, sondern einen 

ausführbaren binären Programmcode. 

£ Falls das attackierte Programm mit root-Berechtigung (setuid root in 

Unix) abläuft, läuft das aufgerufene Programm im Puffer auch mit root- 

Berechtigung. 

Angreifer kann seiner aufrufenden Shell root-Berechtigung verleihen. 

Dadurch erwirbt der Angreifer Superuser Rechte für seine eigenen 

Programme und hat damit Zugang auf das gesamte Betriebssystem. 

¯ Beispiel: Virus 

Ein Virus ist ein Programm, dessen Code an ein anderes Programm anfügt ist 

und sich auf diese Weise reproduziert. Zusätzlich kann ein Virus noch andere 

Funktionen aufrufen, z.B. Löschen von Dateien, Senden von Nachrichten etc. 

Oft ist die Reproduktion des Virus und die Ausführung der Virusfunktion 

zeitlich getrennt, d.h. die Virusfunktion wird erst nach Eintreten eines 

bestimmten Datums getriggert. Dadurch wird erreicht, dass sich ein Virus 

relativ unbemerkt ausbreiten kann (z.B. über das Internet), ohne dass die 

226 

C


Benutzer bereits frühzeitig merken, dass ihr Rechner mit dem Virus infiziert 

ist. 

Virus schläft bis infiziertes Programm ausgeführt wird. 

Start des infizierten Programms führt zur Virusreproduktion. 

Ausführung der Virusfunktion ist u.U. mit einem zeitlichen Datum 

versehen. 

mögliche Virustypen sind 

– Boot Sector Virus. BIOS liest beim Start des Rechners den Master Boot 

Record (MBR) und führt ihn aus. Ein Boot Sector Virus trägt sich im MBR 

ein und wird damit bei Rechnerstart jeweils ausgeführt. Der ursprüngliche 

MBR Inhalt wird oft auf einen anderen Platz der Festplatte kopiert und 

von Virus automatisch aufgerufen, um den Rechnerstart zu ermöglichen. 

Nach dem Start speichert sich der Virus oft im Speicherbereich des 

Unterbrechungsvektors, um nach jedem Systemaufruf wieder die Kontrolle 

zu erhalten. 

– Macro Virus. Programme wie Word oder Excel erlauben dem Benutzer 

das Schreiben von Macroprogrammen (Visual Basic). Beispielsweise 

kann ein Angreifer für ein Word-Dokument ein Macro schreiben, das 

mit der ÇÔÒ Ð Funktion verbunden ist. Integriert in das Macro 

ist der Virus des Angreifers. Da Macros i.a. alle Systemfunktionen 

des Betriebssystems aufrufen dürfen, hat der Virus Zugriff auf die volle 

Funktionalität. Die Verbreitung erfolgt durch Versenden des Dokuments, 

z.B. als Email Attachment. Öffnen des Dokuments führt zur Ausführung 

des Macros und damit des Virus. 

– Ausführbares Programm als Virus. Das Virusprogramm sucht nach seinem 

Aufruf nach geeigneten ausführbaren Programmen (z.B. "exe Dateien") im 

gesamten Dateiverzeichnis und infiziert diese mit dem Virus; beispielsweise 

durch Überschreiben des Binärprogramms mit dem Virusprogramm. Die 

Länge der Datei wird dadurch verändert (kann genutzt werden durch 

Antivirenprogramme, um den Virus zu erkennen). 

– Verbreitung von Viren 

Früher diente der Austausch von Datenträgern (z.B. Floppy Disk), jetzt das 

Internet 

als Attachment zu Emails 

227

Schlichter, TU München 8.3. SCHUTZMECHANISMEN 

Lesen des Adressbuchs und automatische Generierung von Emails 

mit Virus Attachment an alle Adressbucheinträge (z.B. von Microsoft 

Outlook). Dabei wird oft das Subject-Feld so besetzt, dass der 

Empfänger das Gefühl hat, er empfange eine persönliche Email von 

einem Bekannten. 

8.3 Schutzmechanismen 

Schutz von gespeicherter Information vor Diebstahl, unerwünschter Manipulation 

und Verletzung der Vertraulichkeit ist ein zentrales Anliegen in allen Mehrbenutzersystemen. 

8.3.1 Anforderungen 

Für einen Schutzmechanismus gelten die folgenden Anforderungen 

¯ alle Objekte eines Systems müssen eindeutig und fälschungssicher identifiziert 

werden. Insbesondere muss auch der Aufrufer eines Dienstes eindeutig 

und fälschungssicher identifiziert werden. Dies ist gerade für Client-Server 

Beziehungen von großer Bedeutung, z.B. die eindeutige Identifizierung des 

Client bei Ecommerce Anwendungen. 

¯ externer Benutzer eines Systems muss eindeutig und fälschungssicher 

identifiziert werden Authentifizierung. Die Zuordnung zu einem 

Benutzerprozess muss fälschungssicher sein. 

¯ Zugriff auf Objekte sollte nur über zugehörige Objektverwaltung geschehen. 

¯ Zugriff auf Objekte nur, wenn Zugreifer die nötige Rechte hat. 

¯ Rechte müssen fälschungssicher gespeichert werden; Weitergabe von Rechten 

darf nur kontrolliert erfolgen. 

¯ Prinzip der minimalen Rechte. Jedem Programm oder Benutzer sollen für 

die Objekte nur die Rechte eingeräumt werden, die für die momentane Arbeit 

zwingend erforderlich sind. 

¯ grundlegenden Schutzmechanismen sollen ohne großen Aufwand überprüft 

werden können. Dies bedeutet, dass am besten ein einheitliches Schutzkonzept 

für alle zu schützenden Objekte verwendet wird, und dass die Implementierung 

zentral in einem möglichst kleinen Baustein, einem Schutzkern im Betriebssystem, 

erfolgt. 

228


8.3.2 Ebenen des Zugriffschutzes 

Man unterscheidet die folgenden Ebenen des Zugriffsschutzes. 

Maschinenschutz: Kontrolle des physischen Zugangs zum Rechensystem. 

Beim direkten Zugang erfolgt die Kontrolle typisch durch organisatorische 

und bauliche Maßnahmen. Bei Zugang zu einem Rechner über ein Kommunikationsnetz 

sind spezielle Hardware- und Software-Schutzeinrichtungen 

vorzusehen, z.B. Benutzer meldet seinen Zugangswunsch an und Rechner ruft 

auf einer vorher definierten Nummer zurück (unter der der Benutzer erreichbar 

ist). 

Zugangskontrolle: Kontrolle des logischen Zugangs zum Rechensystem, 

d.h. Ausführung von Aufträgen im Rechensystem. Hier spielt die 

Authentifizierung des Benutzers eine wichtige Rolle, z.B. Passwörter oder 

biometrische Eigenschaften, um den Benutzer eindeutig zu identifizieren. 

Im Rechensystem sind Verfahren notwendig, um die Korrektheit der 

angegebenen Identität zu überprüfen (z.B. Passwort-Datei). 

Berechtigungskontrolle: Kontrolle des Benutzerzugriffs auf einzelne 

Datenbestände und die Ausführung einzelner Dienste. 

Systemschutz: Gewährleistung der Integrität der Schutzmechanismen. Hier 

muss sichergestellt werden, dass die Schutzmechanismen in Hardware und 

Software durch Angreifer nicht modifiziert werden können, um ein Umgehen 

und Aushebeln des Schutzes durchzuführen. 

8.3.3 Schutzmatrix 

Das Konzept der Schutzmatrix wurde von B. Lampson eingeführt. Es verknüpft 

Schutzdomänen mit den zu schützenden Objekten. 

¯ Schutzdomänen 

Definition: Eine Schutzdomäne ist eine Menge von (Objekt, Rechte) Paaren. 

Jedes Paar spezifiziert ein Objekt und eine Menge von Operationen, die auf 

diesem Objekt ausgeführt werden dürfen. Meist entspricht eine Schutzdomäne 

einem Benutzer, d.h. sie gibt an, was dieser Benutzer tun. Negative Rechte, 

d.h. das was er nicht tun darf, werden nicht explizit angegeben. 

229


Domäne 1 Domäne 2 

Datei1[R] 

Datei2[RW] 

Printer1[W] 

Datei3[RW] 

R = read, W = write, X = execute 

Datei1[RWX] 

Datei4[R] 

Floppy1[R] 

Das Beispiel zeigt mehrere Objekte mit Ihren Rechten und ihre Zuordnung 

zu den Domänen. Gleiche Objekte (im Beispiel Datei1) können mit 

unterschiedlichen Rechten unterschiedlichen Domänen zugeordnet werden. 

– Verknüpfung eines Prozesses mit einer Schutzdomäne. Dadurch wird der 

Handlungsspielraum des Prozesses bei seiner Ausführung eingeschränkt. 

Die Zuordnung einer Schutzdomäne zu jedem Prozess geschieht in einer 

allen Zugriffsversuchen vorangeschalteten Authentisierung. Insbesondere 

wird die hinter einem Prozess stehende Identität geprüft, z.B. die Identität 

des Benutzers oder die eines Servers. 

– zu jedem Zeitpunkt wird ein Prozess in einer Schutzdomäne ausgeführt. 

Ein Prozess kann während seiner Ausführung die Schutzdomäne wechseln. 

Dadurch können Prozesse während ihres Lebenszyklus auf unterschiedliche 

Objekte mit unterschiedlichen Rechten zugreifen. 

Beispiel Unix: bei Ausführung eines Systemaufrufs wechselt der Prozess 

vom Benutzermodus in den Systemmodus ("kernel mode") entspricht 

einem Wechsel der Schutzdomäne. Im Systemmodus kann der Prozess 

auf die geschützten Ressourcen des Systems zugreifen. 

– Das Paar (Prozess P, Schutzdomäne D) wird als Subjekt bezeichnet. Subjekte 

sind im Kontext einer Schutzdomäne agierende Prozesse. 

Der Zugriffswunsch eines Subjektes S auf ein Objekt o ist definiert als 

(D, o, a), wobei D die Schutzdomäne und a die Zugriffsart ist. 

– Matrix-Datenstruktur 

Konzeptuell verwendet ein Betriebssystem eine Matrix-Datenstruktur, um 

die Zuordnung Objekt-Schutzdomäne zu verfolgen. 

230


Domäne 

1 

2 

Datei1 

read 

read write 

execute 

Datei2 

read write 

Datei3 

read write 

read write 

Objekt 

Datei4 

read 

Printer1 

write 

write 

Floppy1 

read 

Jedes Matrixelement spezifiziert die Zugriffsarten, die in einer Schutzdomäne 

auf das zugehörige Objekt erlaubt sind. Der Domänenwechsel selbst 

kann mit Hilfe des Matrixmodells realisiert werden. Zum Beispiel können als 

Objekte zusätzlich die Schutzdomänen mit aufgenommen werden. Falls ein 

Wechsel von einer Domäne 1 in eine Domäne 2 erlaubt sein soll, wird in die 

Zeile der Domäne 1 in der Spalte für Objekt Domäne 2 die Zugriffsart "enter" 

eingetragen. 

¯ Schutzmonitor 

Jeder Zugriff (D, o, a) eines Subjektes S wird mit Hilfe eines Schutzmonitors 

überprüft. Der Schutzmonitor prüft anhand seiner intern gespeicherten 

Schutzmatrix, ob in der Zeile von D ein Zugriffsrecht a für das Objekt o existiert. 

Bei positivem Ausgang wird der Zugriff zugelassen, andernfalls wird 

ein Schutzalarm ausgelöst und der Zugriff unterdrückt. Der Schutzmonitor läuft 

meist in einem geschützten Teil des Betriebssystems ab (z.B. Betriebssystemkern). 

Schutzdomäne 

D 

Prozess 

P 

Subjekt 

Benutzermodus 

(D,o1,a) 

Schutzmonitor 

Schutz 

matrix 

Betriebssystem - Systemmodus 

Objekte 

– der Schutzmonitor ist vertrauenswürdig. 

– Subjekte können in keinem Fall auf Objekte unter Umgehung des 

Schutzmonitors zugreifen. 

– neue Prozesse müssen sich gegenüber dem Schutzmonitor authentifizieren. 

Anonyme Prozesse, die noch ohne Schutzdomäne sind, übergeben dem 

231 

o1 

o2 

o3


Schutzmonitor Namen und Passwort des Benutzers, in dessen Auftrag sie 

handeln. Erkennt der Schutzmonitor die Identität an, veranlasst er den 

Betriebssystemkern einen Verweis auf die zugeordnete Schutzdomäne im 

Prozesskontrollblock zu speichern; der Prozess kann nun auf die erlaubten 

Objekten zugreifen. 

¯ Schutzmatrix ist typischerweise sehr groß und dünn besetzt eine direkte 

Implementierung ist deshalb nicht sinnvoll. Deshalb ist man dazu übergegangen 

die Schutzmatrix entweder spaltenweise oder zeilenweise zu speichern, um 

den Speicheraufwand zu reduzieren. Leere Matrixelemente werden nicht 

gespeichert. 

¯ Zugriffskontrollliste 

Zugriffskontrolllisten ("Access Control List", ACL) realisieren die spaltenweise 

Speicherung der Schutzmatrix. 

jedes Objekt o besitzt seine Zugriffskontrollliste. 

Element einer Zugriffskontrollliste (ACL-Element) besteht aus Paar 

(Prozess, Zugriffsarten). Anstelle des Prozesses können als Komponenten 

in einem ACL-Element auch Schutzdomänen verwendet werden. Die 

Verwendung von Schutzdomänen erleichtert die Zusammenfassung von 

Benutzern zu einer Gruppe, die die gleichen Zugriffsrechte besitzen. Jedes 

ACL-Element repräsentiert ein Kontrollrecht für das Objekt o. 

Prozess Benutzer 

A 

Datei D1 A: RW; B: R 

Datei D2 A: R; B: RW; C: R 

Datei D3 B: RWX; C: RX 

B C 

ACL 

Benutzer 

Modus 

System 

Modus 

Neben den allgemeinen Rechten wie Ö, ÛÖØ und Ü ÙØ können auch 

objekt-spezifische Zugriffsarten in die Zugriffskontrollliste des Objektes eingetragen 

werden. Für einen Prozess (Subjekt) sind nur diejenigen Zugriffsarten 

auf das Objekt erlaubt, die in der zugehörigen ACL eingetragen sind. Manche 

Schutzsysteme unterstützen auch Wildcards für die Prozessspezifikation, d.h. 

ein ACL-Element (*, R) bedeutet, dass beliebige Prozesse das Leserecht auf 

das Objekt besitzen. 

232


¯ Capability-Liste 

Capability-Listen ("Zugriffsausweislisten") realisieren die zeilenweise Speicherung 

der Schutzmatrix. 

jeder Prozess besitzt eine Menge von Capabilities, die die erlaubten 

Zugriffe auf Objekte repräsentieren. 

Element einer Capability-Liste besteht aus Paar (Objekt, Zugriffsarten). Ein 

Capability gibt dessen Besitzer gewisse Zugriffsrechte für das Objekt. 

Prozess Benutzer 

A 

D1: RW 

D2: R 

D1: R 

D2: RW 

D3: RWX 

B C 

D2: R 

D3: RX 

Benutzer 

Modus 

System 

Modus 

Capability- 

Liste 

– Capabilities müssen geschützt werden, um Modifikationen durch den Prozess 

selbst zu verhindern. Alternativen sind 

Speicherung im geschützten Bereich des Betriebssystems. 

Capabilities sind zwar im Benutzermodus dem Prozess zugeordnet; sie 

sind jedoch verschlüsselt. Der Prozess kann bei einem Objektzugriff 

dem Schutzmonitor sein zugehöriges Capability vorzeigen, jedoch dieses 

Capability nicht selbst verändern. Eine Änderung darf nur vom 

Schutzmonitor vorgenommen werden. Diese Alternative ist besonders 

für verteilte Systeme geeignet. Beispielsweise schickt ein Client 

zusammen mit seiner Dienstanforderung auch das zugehörige Capability 

an den Server. Das Capability muss sicher übertragen werden (z.B. 

verschlüsselt), damit ein heimliches Kopieren und missbräuchliche 

Nutzung durch andere Prozesse verhindert werden kann. 

– Capabilities können zeitlich begrenzt werden. Auch könnte mit einem 

Capability ein Kontofeld verbunden sein. Bei jeder Verwendung des 

Capability wird das Kontofeld reduziert. Ein Objektzugriff ist nur möglich, 

wenn der Kontostand ausreichend ist. Damit kann ein Capability nur für eine 

begrenzte Anzahl von Zugriffen beschränkt werden. 

233

Schlichter, TU München 8.4. SICHERHEIT IN VERTEILTEN SYSTEMEN 

¯ Zusammenfassung: Zugriffskontrolllisten und Capability-Listen haben in 

gewisser Weise komplementäre Eigenschaften 

ACLs erlauben das selektive Zurücknehmen von Rechten. Für Capabilities 

ist dies eher schwierig, da die Capabilities verteilt den einzelnen Prozessen 

zugeordnet sind, und auch zwischen Prozessen weitergegeben werden 

können. 

Capabilities können weitergegeben werden. Bei der Weitergabe kann der 

Prozess die Zugriffsrechte einschränken. 

8.4 Sicherheit in verteilten Systemen 

In einem zentralen System beruht der Zugriffsschutz letztendlich auf der Kontrolle 

aller Systemkomponenten (Hard-/Software) durch ein einziges, vertrauenswürdiges 

Betriebssystem. Die Kontrolle kann aufgrund der Gestaltung der Schnittstelle 

durch Benutzer nicht umgangen werden. In einem verteilten System gibt es keine 

zentrale Stelle, die alle Subjekte und Objekte kontrollieren kann. Jeder Rechner 

hat sein eigenes Betriebssystem, das in Verantwortung des jeweiligen Rechner- 

Administrators liegt. Dieser kann die Schutzmechanismen durchbrechen und so 

unberechtigten Zugriff zu bestimmten Daten und Ressourcen des Rechnernetzes 

erhalten will. Andere Rechner in einem Rechnernetz werden als nicht vertrauenswürdig 

eingeschätzt. 

8.4.1 Unsicherheitsfaktoren in verteilten Systemen 

Durch das Kommunikationsnetz ergeben sich zusätzliche Unsicherheitsfaktoren 

in verteilten Systemen. 

¯ Anzapfen von Kommunikationspfaden. Diese Gefahr wird insbesondere durch 

die offenen Netze erleichtert. 

¯ Abhören und Verfälschen von Nachrichten. Dazu gehört Kopieren, Verändern 

und Löschen von ganzen bzw. Teilen von Nachrichten sowie das Einfügen von 

falschen Teilen in eine Nachricht. 

¯ Wiederholen von abgehörten und kopierten Nachrichten ("Replay"). 

¯ Verändern der Nachrichtenreihenfolge. 

¯ Modifizieren der Quell- oder der Zieladresse einer Nachricht. 

234


¯ Rechnername und Netzadressen allein sind nicht vertrauenswürdig. Falls 

ein Benutzer komplette Kontrolle über einen Rechner hat, kann er diesen so 

modifizieren, dass er sich für einen anderen Rechner ausgibt. Jemand gibt vor 

ein bestimmter Client zu sein, oder jemand gibt vor ein bestimmter Server zu 

sein. Es ist also die Authentifizierung von Client und Server notwendig. 

¯ Einschleusen von Viren. 

¯ Lahmlegen von Servern durch eine massive Anzahl von Anforderungen (siehe 

Yahoo, Microsoft). Diese "denial-of-service" Attacken können durch die 

automatische Generierung von Anforderungen erreicht werden. 

8.4.2 Sicherheitsanforderungen 

Für den Empfänger einer Nachricht ist nicht nur die Authentizität des Senders 

der Nachricht von Bedeutung, sondern auch die Integrität dieser Nachricht 

bzw. der Nachrichtenreihenfolge, d.h. auch eine spätere Wiederholung einer 

Nachricht kann die Integrität verletzen. Unterscheidung von wesentlichen 

Sicherheitsanforderungen: 

¯ Authentizität 

Nachweis über den Ursprung der Nachricht, Identität des Senders; Authentizität 

von Daten muss garantiert sein, d.h. angebliche Quelle von Daten muss 

tatsächlicher Quelle entsprechen. Beispiel im Web: stammen bestimmte 

Informationen tatsächlich vom gewünschten Anbieter oder hat jemand 

gefälschte Daten untergeschoben? Entsprechendes gilt auch für den Ursprung 

einer Email. 

¯ Vertraulichkeit, Geheimhaltung 

vertrauliche Daten auch bei einer Übertragung über ein öffentliches Netz. Es 

soll Dritten nicht möglich sein, die Daten auszuspähen. Gegebenenfalls ist 

es sogar notwendig, die Tatsache des Kommunikationsaustausches zwischen 2 

Partnern zu verschleiern. Die Tatsache der Kommunikation zwischen 2 Firmen 

kann bereits eine interessante Information für Mitbewerber sein. 

¯ Verbindlichkeit 

Beispielsweise muss der Verkäufer dem Käufer nachweisen können, dass dieser 

einen verbindlichen Auftrag über das Netz getätigt hat. Verbindlichkeit ist 

insbesondere beim elektronischen Handel von Bedeutung. 

235


¯ Integrität 

Daten müssen vor nicht autorisiertem Schreiben geschützt werden; Schreiben 

bedeutet: einfügen, modifizieren, löschen, etc. Falls die übertragenen Daten bei 

der Übertragung manipuliert wurden, sollte dies für den Empfänger aufgrund 

der verletzten Integrität der Daten bemerkbar sein. 

¯ Verfügbarkeit 

Schutz von Systemressourcen vor nicht autorisiertem Zugriff, um Verfügbarkeit 

für autorisierte Benutzer garantieren zu können. 

Systemressourcen: Prozessoren, Speicher, Kommunikationskanäle, Programme, 

etc. 

8.4.3 Kryptographie 

Die Schutzkonzepte in verteilten Systemen basieren auf der Anwendung von 

Verschlüsselungstechniken. 

Kryptosystem 

Definition: Ein kryptographisches System (Kryptosystem) ist ein Tupel (M, C, 

K, E ,D ) mit 

k k 

einem höchstens abzählbaren Klartextraum M 

einem höchstens abzählbaren Chiffretextraum C 

einem höchstens abzählbaren Schlüsselraum K 

einer Familie von Chiffriertransformationen E : M C mit k aus K 

k 

(Verschlüsselung) 

einer Familie von Dechiffriertransformationen D : C M mit k aus K 

k 

(Entschlüsselung). 

A 

Klartext Ciphertext 

x 

E k 

y = E k (x) 

D k 

Klartext 

¯ Es muss gelten 

k K, m M:D (E (m)) = m 

k k 

k ist der Schlüssel, wobei beim public-key Verfahren die Schlüssel zum 

Chiffrieren und Dechiffrieren unterschiedlich sind. Zusätzlich gibt es noch 

236 

x 

B


Forderungen, wie beispielsweise: es müssen einfach und leicht Schlüssel 

aus K gefunden werden können; die Chiffrier-und Dechiffriertransformationen 

müssen effizient berechenbar sein. Die Sicherheit des Systems beruht auf der 

Geheimhaltung von Schlüssel und nicht des Chiffrier- und Dechiffrieralgorithmus. 

¯ Unterscheidung zwischen zwei Klassen von Kryptosystemen: 

symmetrische Kryptosysteme (private-key) 

asymmetrische Kryptosysteme (public-key) 

Bei dem symmetrischen Verfahren haben Sender und Empfänger einen privaten 

Schlüssel, während beim asymmetrischen Verfahren eine Unterscheidung 

gemacht wird zwischen einem öffentlichen Schlüssel zum Verschlüsseln und 

einem privaten Schlüssel zum Entschlüsseln. 

Symmetrische Kryptosysteme (private-key) 

Absender A 

Dokument 

(Klartext) 

Dokument 

(chiffriert) 

chiffrieren 

mit k priv 

Netz 

Empfänger E 

Dokument 

(Klartext) 

dechiffrieren 

mit k priv 

Dokument 

(chiffriert) 

k priv ist ein privater Schlüssel für die Kommunikation zwischen den beteiligten 

Prozessen A und E. 

¯ Beispiel: DES (Data Encryption Standard) 

DES wurde von IBM entwickelt und 1977 von der amerikanischen Regierung 

als offizieller Standard propagiert. DES ging ursprünglich von einer festen 

Schlüssellänge von 56 Bit plus 8 Bit Parität aus; in der Zwischenzeit sind 

Schlüssel 112 Bit und länger. Verfahren gilt als sicher in dem Sinn, dass 

es nur mit sehr großem Aufwand möglich ist, einen Schlüssel zu knacken. 

Eine Verdoppelung der Schlüssellänge erhöht den zum Knacken notwendigen 

237


Aufwand um den Faktor 2 56 . Derzeit spezifiziert eine Standardisierungsgruppe 

einen Nachfolger von DES. 

¯ Schlüsselverteilung 

Problem: Sichere Verteilung der geheimen Schlüssel, d.h. sicherer Austausch 

der geheimen Schlüssel zwischen Absender A und Empfänger E. Dazu 

wird oft ein anderes Kommunikationsmedium gewählt, z.B. ein persönliches 

Treffen, d.h. gesicherter Datenaustausch erfordert gewisse Vorbereitungen, eine 

spontane gesicherte Übertragung ist nicht möglich. 

– Schlüsselverteilungsserver 

Ein Schlüsselverteilungsserver (KDS = key distribution server) generiert für 

die beiden Kommunikationspartner A und E einen gemeinsamen privaten 

Schlüssel und verteilt ihn chiffriert an A und E. 

Kommunikations- 

KDS 

wunsch A und E 

1 2 

Ek (k S ) 

A 

3 

A 

M 

KS KS 4 5 6 

Verschlüsselungs 

einheit 

E k (M) 

S 

E k (k S ) 

E 

Verschlüsselungs 

einheit 

£ Benutzer A und E haben jeweils mit KDS einen gemeinsamen geheimen 

Schlüssel (k A und k E für A bzw. E). Diese geheimen Schlüssel werden 

bereits a-priori festgelegt, z.B. durch Passwort. 

£ KDS generiert auf Anfragen einen Schlüssel für eine Sitzung. Dieser 

Schlüssel dient für die Kommunikation zwischen A und E. Er wird 

typischerweise nur für eine Sitzung verwendet. Für verschiedene 

Kommunikationssitzungen zwischen A und E werden unterschiedliche 

Schlüssel verwendet. 

£ KDS verteilt Sitzungsschlüssel chiffriert an Partner (Schritte 2 und 3). 

£ Partner kommunizieren über gemeinsamen Schlüssel (Schritt 5). 

Asymmetrische Kryptosysteme (public-key) 

Realisierung eines gesicherten Datenaustausches mittels eines Schlüsselpaares 

(k priv ,k pub ) 

238 

M 

B


k priv ist der private Schlüssel, k pub ist der öffentliche Schlüssel 

was mit einem Schlüssel chiffriert wurde, kann mit dem jeweils anderen 

Schlüssel wieder dechiffriert werden. 

Vorteil des asymmetrischen Verfahrens ist, dass der öffentliche Schlüssel 

allgemein bekannt ist, während nur ein Partner (Empfänger oder Sender) 

den privaten Schlüssel kennen muss, d.h. es ist keine Vorbereitung durch 

Austausch von geheimen Schlüsseln notwendig. Das Verschlüsselungs- und 

Entschlüsselungsverfahren ist bekannt. 

Absender A 

Dokument 

(Klartext) 

Dokument 

(chiffriert) 

chiffrieren 

mit k E, pub 

Netz 

Empfänger E 

Dokument 

(Klartext) 

dechiffrieren 

mit k E, priv 

Dokument 

(chiffriert) 

¯ Beispiel: RSA-Verfahren 

RSA Verfahren mit Schlüssellänge 200 bits; Verschlüsselung langsam; 

deshalb oft Kombination mit symmetrischen Verfahren. 

¯ Bestimmung der Schlüssel 

Bedingt durch die Fortschritte in der Hardware, sollte das Schlüsselpaar alle 

zwei Jahre gewechselt werden und auch die Schlüssellänge vergrößert werden. 

– Bestimmung des öffentlichen Schlüssels k pub 

1. selektiere 2 positive (p = 7, q =17) 

2. 

Primzahlen p und q; 

x = (p-1) * (q-1); (x = 96) 

3. bestimme eine Zahl e 

mit e kein Teiler von x; 

(e = 5) 

4. n=p*q; (n = 119) 

5. k = (n, e); 

pub 

(k = (119, 5)) 

pub 

– Bestimmung des privaten Schlüssels k priv 

239


6. bestimme d, so dass 

mod(d*e, x) = 1; 

(d * 5/96 = 1 d = 77) 

7. k = (n, d) 

priv 

(k = (119, 77)) 

priv 

– Berechnung des Chiffretext c aus Klartext m (m = 19), d.h. Klartext wird als 

eine Zahl interpretiert; Anwendung des Schlüssels k pub 

8. c = mod (m e ,n) (c = mod(19 5 , 119) = 

66) 

– Berechnung des Klartext m aus Chiffretext c; Anwendung des Schlüssels 

k 

priv 

9. m = mod (c d ,n) (p = mod(66 77 , 119) = 

19) 

¯ Digitale Unterschrift 

Absender A 

Dokument 

(Klartext) 

chiffrieren 

mit k E, pub 

Dokument 

(chiffriert) 

hash 

Signature 

chiffrieren 

mit k A, priv 

Signature 

(chiffriert) 

Netz 

Dokument 

(Klartext) 

dechiffrieren 

mit k E, priv 

Empfänger E 

Dokument 

(chiffriert) 

gleich ? 

hash 

Signature 

dechiffrieren 

mit k A, pub 

Signature 

(chiffriert) 

Die Unterschrift ("signature") besteht u.a. aus einem Hashcode zum Dokument 

sowie Information über den Absender. 

8.4.4 Authentifizierungsdienst Kerberos 

Kerberos wurde am MIT als Teil des verteilten Systems Athena entwickelt. 

Das Authentifizierungsprotokoll von Kerberos basiert auf dem Protokoll 

von Needham und Schröder; siehe auch Kerberos Web-Site (URL: 

http://web.mit.edu/kerberos/www/) 

240


Motivation 

Kerberos geht von folgenden Komponenten aus 

Client C 

Server S 

Schlüsselverwaltungszentrum KDC ("key distribution center") 

Ticket Server TGS ("ticket granting service") 

Zielsetzung von Kerberos 

¯ ein Client C möchte einen Dienst des Servers S in Anspruch nehmen, dabei 

soll mit Hilfe von KDC und TGS die Geheimhaltungs- und Authentizitätsanforderung 

erfüllt werden. Der Server S muss überzeugt davon sein, dass er mit 

Client C kommuniziert; umgekehrt muss dasselbe aus der Clientperspektive 

gelten. 

¯ KDC verwaltet die geheimen Schlüssel der registrierten Komponenten. KDC 

muss sehr sicher sein und darf auch räumlich für Eindringlinge nicht zugänglich 

sein, d.h. der Rechner des KDC muss in einem gut verschlossenen Raum sein. 

¯ TGS stellt einem Client C während einer Sitzung Tickets für Authentifizierungen 

mit speziellen Servern des verteilten Systems zur Verfügung. 

Sicherheitsobjekte in Kerberos 

Kerberos realisiert die Authentifizierung mittels dreier Sicherheitsobjekte 

1. TGS-Ticket 

ausgestellt von KDC an Client C zur Präsentation beim TGS. Ein TGS- 

Ticket sagt aus, dass Client C erst vor kurzem durch Kerberos authentifiziert 

wurde. Das TGS-Ticket ist zeitlich beschränkt; es beinhaltet auch einen 

Sitzungsschlüssel für die gemeinsame Sitzung zwischen Client und TGS. 

2. Authentifizierer 

erzeugt durch Client C; dient zum Identitätsnachweis des Client sowie der 

zeitlichen Gültigkeit der Kommunikation mit dem Server S. Durch die 

zeitliche Beschränkung sollen Replays einer bereits früher stattgefundenen 

Kommunikation mit Server S unterbunden werden. Das Authentifizierer Objekt 

beinhaltet den Namen von C sowie einen Zeitstempel; beides wird mit dem 

Sitzungsschlüssel verschlüsselt. 

241


3. Sitzungsschlüssel 

erzeugt durch Kerberos für die Kommunikation zwischen Client C und 

Server S. Der Sitzungsschlüssel ist gültig für eine Sitzung. Er dient 

zur Verschlüsselung der Anforderungen und Antworten. Für nachfolgende 

Sitzungen muss von Kerberos ein neuer Sitzungsschlüssel erzeugt werden. 

Protokollablauf zur Authentifizierung 

¯ Nachricht 1 

1 

request 

TGS ticket 

KDC 

C 

TGS 

ticket 

2 

6 

Kerberos 

request Server 4 

ticket 

Server ticket 

3 

Authentifizierer 

Authentifizierer 

C KDC mit Information C, TGS 

Der Client C möchte von TGS für die weitere Kommunikation im verteilten 

System ein Ticket bekommen. Der Client C kann hier ein System oder auch ein 

Benutzer sein. TGS ist der Service, von dem die Tickets für die gewünschten 

Server erhalten werden sollen. 

5 

TGS 

– KDC bestimmt aus seiner Datenbank den geheimen Schlüssel k(C) für 

die Kommunikation zwischen Kerberos und C; KDC erzeugt einen guten 

zufälligen Sitzungsschlüssel k(C, tgs). Der Schlüssel k(C, tgs) gilt nur 

für eine Sitzung von C. Gut bedeutet in diesem Zusammenhang, dass der 

Schlüssel nur den beiden Kommunikationspartnern bekannt ist. k(C) ist der 

geheime Schlüssel von C, z.B. falls C ein Benutzer ist, dient das Passwort als 

geheimer Schlüssel k(C). 

242 

S



KDC C mit Information (k(C, tgs)) k(C) 

(C, TGS, T kdc ,L kdc , k(C, tgs)) k(tgs) 

= ticket(C, TGS) k(tgs) 

– geheimer Schlüssel k(C) wird aus dem Passwort des Benutzers abgeleitet; 

– zweiter Teil der Nachricht wird von C nicht interpretiert, sondern als Ganzes 

an TGS übergeben (d.h. TGS-Ticket). Das Ticket ist mit dem geheimen 

Schlüssel k(tgs) des TGS verschlüsselt. 

T Zeitstempel für Erzeugung des Tickets 

kdc 

L Lebensdauer des Tickets 

kdc 

Das Ticket beinhaltet neben dem Namen des Client auch dessen Adresse 

im verteilten System. In Kerberos sind als Lebensdauer für ein TGS-Ticket 

etwa 8 Stunden vorgesehen. Innerhalb der Gültigkeitsdauer kann C das 

Ticket beliebig oft zur Ticketanforderung für spezielle Server an TGS senden. 

Falls ein Ticket gestohlen wird, kann es nur für eine begrenzte Zeit genutzt 

werden. Ein Ticket ist mit dem geheimen Schlüssel von TGS und Kerberos 

verschlüsselt. Die Trennung von KDC und TGS erfolgt deshalb, damit 

Nachrichten, die mit einem vom Benutzerpasswort abgeleiteten Schlüssel 

verschlüsselt sind, möglichst selten über das Netz übertragen werden. Der 

Client C muss das Benutzerpasswort nicht lokal speichern. 


C TGS mit Information (C, T ) 

C k(C,tgs) 

ticket(C, TGS) 

k(tgs) 

S 

Der 1. Teil der Nachricht dient als Authentifizierer für C. Dieser wird im 

Gegensatz zum Ticket für TGS nur einmal benutzt (deshalb Verwendung 

von T ). Bei der Festlegung von T muss die Übertragungsverzögerung 

C C 

mitberücksichtigt werden. S bezeichnet den gewünschten Server; die 

Komponente C beinhaltet hier wieder die Adresse von C im verteilten System. 

– TGS bestimmt einen zufälligen Sitzungsschlüssel k(C,S), falls 

TGS-Ticket noch gültig ist, 

243



T noch aktuell ist, und 

C 

das Feld C übereinstimmt (im 1. Parameter und Ticket). 

TGS C mit Information (k(C, S)) k(C, tgs) 

(C, S, T tgs , L tgs , k(C, S)) k(S) = 

ticket(C, S) k(S) 

– Der 2. Teil der Nachricht dient als Ticket von C für Server S. 

– k(S) ist der Kerberos bekannte geheime Schlüssel des Server's S. Das Ticket 

beinhaltet auch eine Gültigkeitsdauer, die von TGS bestimmt wird. C 

speichert Ticket und Sitzungsschlüssel in einem sicheren Speicherbereich. 


Die Nachrichten 5 und 6 dienen für C und S zur gegenseitigen Authentifizierung 

C S mit Information (C, T C ) k(C,S) 

ticket(C, S) k(S) 

Der 1. Teil der Nachricht dient wieder als Authentifizierer für C. Falls 

Überprüfung des Feldes C positiv ist, und das Ticket noch gültig ist, akzeptiert 

S den Schlüssel k(C,S) als authentifizierten Sitzungsschlüssel. 


S C mit Information (T C ) k(C,S) 

Die Nachricht dient für C zur Authentifizierung von S. Die weitere 

Kommunikation zwischen C und S erfolgt nun über den geheimen, temporären 

Sitzungsschlüssel. Man bezeichnet T c oft auch als "nonce". 

Problem von Kerberos 

Manipulation der lokalen Uhren der Rechner zur Umgehung der Gültigkeitsdauer 

von Tickets, d.h. Synchronisation der Uhren im verteilten System muss autorisiert 

und authentifiziert durchgeführt werden. 

244


Beispiel: Benutzerlogin mit Kerberos 

1. login Programm der Workstation W sendet Benutzername N an KDC 

2. falls Benutzer bekannt, sendet KDC einen Sitzungsschlüssel k(N) verschlüsselt 

mit dem Benutzerpasswort sowie ein TGS-Ticket. 

3. login Programm fordert Passwort von Benutzer an und entschlüsselt damit 

den Sitzungsschlüssel k(N); falls Passwort korrekt, stimmen entschlüsselter 

Sitzungsschlüssel k(N) und Sitzungsschlüssel k(N) in TGS-Ticket überein; 

4. Passwort kann aus Arbeitsspeicher von W entfernt werden, da für weitere 

Kommunikation nur k(N) und TGS-Ticket verwendet werden; beide dienen nun 

zur Authentifizierung bei TGS, falls Benutzer einen Server S benötigt. 

5. einrichten einer login-Sitzung des Benutzers an Workstation W. Das Passwort 

wird nicht über das Netz geschickt, im Gegensatz zur Basisauthentifizierung 

im WWW. Das Passwort wird aus dem Arbeitsspeicher sofort entfernt, falls 

TGS-Ticket und Sitzungsschlüssel vorhanden sind. 

Animation Kerberos 


8.4.5 Mobiler Code 

Das Internet führt zunehmend zu einer Verbreitung von mobilem Code. Beispiele 

sind 

Web Seiten mit Applets 

Postscript Dateien 

mobile Software-Agenten (z.B. in Ecommerce Anwendungen). 

Ausführung von heruntergeladenem Code birgt Risiken in sich. Beispielsweise 

kann ein Applet bösartigen Code enthalten, das auf Ressourcen der lokalen Umgebung 

zugreift und sie unberechtigterweise modifiziert oder löscht. Methoden (anhand 

von Applets), um mit dieser Problematik umzugehen: 

Sandboxing 

Ausführung des Applets wird auf einen bestimmten virtuellen Adressbereich 

beschränkt. 

245


Für eine Sandbox sind die high-order Bits aller Adressen gleich, d.h. 

angenommen für einen 32 Bit Adressraum werden 256 Sandboxes auf 16 

MByte Grenzen eingerichtet 

für alle Adressen innerhalb einer Sandbox sind die oberen 8 Bits 

identisch. 

¯ jedes Applet erhält zwei Sandboxes: eine Code-Sandbox, eine Daten-Sandbox. 

Die Code-Sandbox darf durch das Applet nicht verändert werden, um die 

Gefahr durch einen sich selbst-modifizierenden Code zu eliminieren. 

¯ nach dem Laden wird Applet-Code überprüft, ob er Befehle enthält, 

die ein Verlassen der Sandbox verursachen. Es werden insbesondere 

Sprungbefehle (JMP) und Systemaufrufe (CALL) untersucht. Sprungbefehle, 

deren Sprungziele erst zur Laufzeit bestimmt werden, können erst vor deren 

Ausführung analysiert werden. 

¯ ein Applet, das die Sandbox-Grenzen verletzt, wird zurückgewiesen. 

Interpretation 

Applet wird als Byte-Code geladen. Jeder Befehl wird vor seiner Ausführung von 

der Java Virtual Machine (JVM) analysiert. 

¯ jeder Systembefehl wird abgefangen und untersucht. Wie die einzelnen 

Systembefehle behandelt werden, hängt von der eingestellten Sicherheits- 

Policy ab. 

für vertrauenswürdige Applets (z.B. geladen von lokaler Festplatte) werden 

Systembefehle ausgeführt. 

nicht vertrauenswürdige Applets (z.B. geladen über Internet) werden 

innerhalb einer Sandbox ausgeführt. 

Signed Code 

Es werden nur Applets von vertrauenswürdigen Quellen geladen und ausgeführt. 

Applets anderer Quellen werden abgelehnt. Der Applet-Code wird mit 

einer digitalen Unterschrift versehen, um zu garantieren, dass der Code der 

vertrauenswürdigen Quelle nicht verändert wurde. 

¯ digitale Unterschrift basiert auf public-key Verfahren. 

246


¯ Erzeugung der Unterschrift durch vertrauenswürdige Quelle 

Hashfunktion erzeugt von Applet-Code eine 128/160 bit Zahl. 

erzeugte Hashzahl wird mit privatem Schlüssel der Quelle verschlüsselt. 

digitale Unterschrift wird mit Applet-Code verschickt. 

¯ Überprüfung der Unterschrift 

Browser führt auf Applet-Code Hashfunktion aus und berechnet selbst 

Hashzahl. 

Browser entschlüsselt Unterschrift mit öffentlichem Schlüssel der vertauenswürdige 

Quelle. 

berechnete Hashzahl und Hashzahl in Unterschrift müssen übereinstimmen. 

Falls die beiden Hashzahlen nicht übereinstimmen, wird die Ausführung des 

Applets abgelehnt. 

247

Kapitel 9 

Zusammenfassung 

Diese Vorlesung beschäftigte sich mit den technischen Aspekten von Rechensystemen. 

Es gab eine Einführung in systemnahe Programmierung. Dabei wurden 

sowohl nicht verteilte als auch verteilte Systeme betrachtet. Insbesondere wurden 

folgende Aspekte behandelt: 

Aufbau von Assemblerprogrammen und hardwarenahen Datenstrukturen. 

Modellierung von Prozessen, z.B. Petrinetze, sowie die Synchronisation von 

Prozessen beim Zugriff auf gemeinsame Ressourcen. 

Verwaltung von Prozessen und deren Zuteilung an den Rechnerkern, um sie 

auszuführen. 

Verwaltung des Arbeitsspeichers aus der Sicht des Betriebssystems (virtuelle 

Speicherverwaltung, Seitenadressierung). 

persistente Speicherung von Information in Dateien. 

Prozesskommunikation in lokalen und verteilten Systemen. 

Sicherheit in zentralen und verteilten Systemen. 

248

Systemnahe Programmierung

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?