Mse Course Student

Eingebettete vernetzte Systeme (IN8014) -
Teil I: Betriebssysteme und Systemsoftware

Johann Schlichter
Institut fr Informatik
TU Mnchen, Munich, Germany
September 2012
Vorlesungsunterlagen
(Student Script
1
)
1
Script generated by Targeteam; Not for general Distribution
Inhaltsverzeichnis
1 bersicht 2
1.1 Ziele dieses Vorlesungsteils . . . . . . . . . . . . . . . . . . . . . 2
1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Anforderungen an Rechensysteme . . . . . . . . . . . . . 3
1.2.2 Struktur eines Rechensystems . . . . . . . . . . . . . . . 5
1.3 Literaturbersicht . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1 Begleitend zur Vorlesung . . . . . . . . . . . . . . . . . . 6
1.3.2 Weiterfhrende Literatur . . . . . . . . . . . . . . . . . . 6
2 Einfhrung 7
2.1 Betriebssystem - berblick . . . . . . . . . . . . . . . . . . . . . 7
2.1.1 BS-Hauptaufgaben . . . . . . . . . . . . . . . . . . . . . 7
2.1.2 Systemprogrammierung . . . . . . . . . . . . . . . . . . 10
2.1.3 Hardwarekomponenten . . . . . . . . . . . . . . . . . . . 11
2.1.4 Betriebsarten . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Betriebssystem-Architektur . . . . . . . . . . . . . . . . . . . . . 13
2.2.1 Monolithischer Ansatz . . . . . . . . . . . . . . . . . . . 13
2.2.2 Mikrokern-Ansatz . . . . . . . . . . . . . . . . . . . . . 15
2.2.3 Beispiel: BS-Architekturen . . . . . . . . . . . . . . . . . 16
2.2.4 Systemaufrufe . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.5 Virtuelle Maschine . . . . . . . . . . . . . . . . . . . . . 19
3 Synchronisation und Verklemmungen 21
3.1 Thread-Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1.1 Charakterisierung von Threads . . . . . . . . . . . . . . . 22
i
Schlichter, TU Mnchen INHALTSVERZEICHNIS
3.2 Synchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.1 Beispiel: gemeinsame Daten . . . . . . . . . . . . . . . . 24
3.2.2 Synchronisierungskonzepte . . . . . . . . . . . . . . . . 26
3.2.3 Semaphore . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.4 Synchronisierung von Java Threads . . . . . . . . . . . . 34
3.3 Verklemmungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3.1 Allgemeines . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3.2 Belegungs-Anforderungsgraph . . . . . . . . . . . . . . . 36
3.3.3 Verklemmungs-Ignorierung . . . . . . . . . . . . . . . . 37
3.3.4 Verklemmungs-Erkennung . . . . . . . . . . . . . . . . . 37
3.3.5 Verklemmungs-Verhinderung . . . . . . . . . . . . . . . 38
3.3.6 Verklemmungs-Vermeidung . . . . . . . . . . . . . . . . 38
3.3.7 Vergleich der Anstze . . . . . . . . . . . . . . . . . . . 41
4 Prozess- und Prozessorverwaltung 42
4.1 Fragestellungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2 Prozessverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.1 Prozesskonzept . . . . . . . . . . . . . . . . . . . . . . . 43
4.2.2 Dispatcher . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2.3 Arbeitsmodi . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2.4 Systemaufrufe . . . . . . . . . . . . . . . . . . . . . . . 50
4.2.5 Realisierung von Threads . . . . . . . . . . . . . . . . . 51
4.3 Prozessorverwaltung . . . . . . . . . . . . . . . . . . . . . . . . 52
4.3.1 Kriterien . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.3.2 Scheduling-Strategien . . . . . . . . . . . . . . . . . . . 54
4.3.3 Thread Scheduling . . . . . . . . . . . . . . . . . . . . . 58
4.3.4 Mehrschichtiges Scheduling . . . . . . . . . . . . . . . . 58
4.3.5 Echtzeit Scheduling . . . . . . . . . . . . . . . . . . . . 60
4.4 Unterbrechungskonzept . . . . . . . . . . . . . . . . . . . . . . . 61
4.4.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.4.2 Unterbrechungsarten . . . . . . . . . . . . . . . . . . . . 61
4.4.3 Behandlung externer Unterbrechungen . . . . . . . . . . 63
4.4.4 Konikte . . . . . . . . . . . . . . . . . . . . . . . . . . 64
ii
5 Speicherverwaltung 67
5.2 Einfhrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.2.1 Adressrume . . . . . . . . . . . . . . . . . . . . . . . . 68
5.2.2 Organisation von Adressrumen . . . . . . . . . . . . . . 68
5.2.3 Fragmentierung . . . . . . . . . . . . . . . . . . . . . . . 70
5.2.4 Forderungen an Adressraumrealisierung . . . . . . . . . . 72
5.3 Speicherabbildungen . . . . . . . . . . . . . . . . . . . . . . . . 72
5.3.1 Direkte Adressierung . . . . . . . . . . . . . . . . . . . . 72
5.3.2 Basisadressierung . . . . . . . . . . . . . . . . . . . . . . 74
5.3.3 Seitenadressierung . . . . . . . . . . . . . . . . . . . . . 75
6 Prozesskommunikation 78
6.2 Einfhrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.2.1 Kommunikationsarten . . . . . . . . . . . . . . . . . . . 78
6.3 Nachrichtenbasierte Kommunikation . . . . . . . . . . . . . . . . 82
6.3.1 Elementare Kommunikationsmodelle . . . . . . . . . . . 82
6.3.2 Erzeuger-Verbraucher Problem . . . . . . . . . . . . . . . 86
6.3.3 Modellierung durch ein Petrinetz . . . . . . . . . . . . . . 87
6.3.4 Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.3.5 Kanle . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.3.6 Strme . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.4 Client-Server-Modell . . . . . . . . . . . . . . . . . . . . . . . . 90
6.5 Netzwerkprogrammierung . . . . . . . . . . . . . . . . . . . . . 92
6.5.1 Einfhrung . . . . . . . . . . . . . . . . . . . . . . . . . 93
6.5.2 Server Protokoll . . . . . . . . . . . . . . . . . . . . . . 94
6.5.3 Client Protokoll . . . . . . . . . . . . . . . . . . . . . . . 95
6.5.4 Bidirektionale Stromverbindung . . . . . . . . . . . . . . 95
6.5.5 Java Socket Class . . . . . . . . . . . . . . . . . . . . . . 96
7 Zusammenfassung 99
iii
Prof. J. Schlichter
Lehrstuhl fr Angewandte Informatik / Kooperative Systeme, Fakultt fr
Informatik, TU Mnchen
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 Ziele dieses Vorlesungsteils
Diese Vorlesung beschftigt sich mit den technischen Aspekten von Rechensyste-
men und der Informationsverarbeitung, nmlich der systemnahen Programmie-
rung. Dabei werden in diesem Teil der Vorlesung vor allem Aspekte allgemeiner
Betriebssysteme und Prozesskommunikation betrachtet. Der 2. Teil der Vorlesung
behandelt dann die Echtzeitaspekte.
Zunchst werden informell die Aufgaben und Eigenschaften eines Betriebssy-
stem dargestellt. Daraus lassen sich die fr die Vorlesung relevanten Begriffe
ableiten. Weiterhin wird kurz auf Hardware-nahe Programme eingegangen.
Im nchsten Teil der Vorlesung erfolgt der bergang von sequentiellen zu
parallelen Systemen. Zu den Themen, die behandelt hier werden, gehren die
Grundlagenprobleme paralleler Systeme und die Verfahren, mit denen diese
gelst werden knnen: Synchronisation, Verklemmungen.
Im Anschluss daran werden Konzepte und Verfahren von Betriebssystemen,
die der wesentliche Teil der Konkretisierung paralleler Systeme sind, behan-
delt. Insbesondere geht es um die Arbeitsspeicherverwaltung (Arbeitsspeicher-
verwaltung, "main memory management"), die Prozessverwaltung und die Pro-
zessorzuteilung sowie Mechanismen zur Kontrolle der Nebenlugkeit.
Prozesse existieren nicht in Isolation, sondern die Kommunikation zwischen den
Prozessen ist von zentraler Bedeutung fr Lsung vieler Problemstellungen.
Der Austausch von Information zwischen Prozessen kann entweder speicher-
basiert oder ber Nachrichten erfolgen. Die nachrichtenbasierte Prozesskom-
2
Schlichter, TU Mnchen 1.2. MOTIVATION
munikation ist gerade fr verteilte Rechensysteme, wo Prozesse ber ein (lo-
kales oder globales) Rechnernetz miteinander kommunizieren, von groer Be-
deutung. Wichtige Aspekte sind hierbei das Client-Server Modell und die Netz-
werkprogrammierung.
1.2 Motivation
Aufgabe der Informatik ist es, Rechensysteme zu entwickeln und diese Anwen-
dern als leistungsfhige Hilfsmittel fr Lsungen ihrer Informationsverarbei-
tungsprobleme zur Verfgung zu stellen.
1.2.1 Anforderungen an Rechensysteme
Rechensysteme sind
offene, dynamische, technische Systeme
mit Fhigkeiten zur Speicherung und zur
Verarbeitung von Information, die fr Anwendungen und Anwender nutzbar
zur Verfgung gestellt werden sollen.
Offenes System
Ein Rechensystem R ist ein offenes System sagt zweierlei aus:
R ist als System eine durch Zusammenfassung gebildete, abgegrenzte Einheit,
wo zwischen innen (R) und auen (U(R)) unterschieden wird.
R hat eine (offene) Schnittstelle, mit der Einwirkungen von U(R) auf R und
Einwirkungen von R auf U(R) mglich sind.
Schnittstelle eines Rechensystems
3
Umgebung
U(R)
Rechensystem R
Schnittstelle R - U(R)
Dynamisches System
Eigenschaften des Rechensystems R ndern sich mit der Zeit
Beschreibung des Verhaltens von R.
Technisches System
Das Rechensystem ist mit hardware- und softwaretechnischen Mitteln realisiert.
Informationsspeicherung und -verarbeitung
4
Information
Daten
Information
Daten
Nachricht
Wissen
Reprsentation Interpretation
1.2.2 Struktur eines Rechensystems
Datenbank World Wide Web Email
Shell bersetzer Dateisystem
Betriebssystem
Maschinensprache
Mikroprogramme / festverdrahtete Programme
physische Komponenten und Gerte
Hardware
Systemprogramme
Anwendungs-
programme
Darstellung von Programmen in maschinennaher Form fr bestimmte Anwen-
5
Schlichter, TU Mnchen 1.3. LITERATURBERSICHT
dungen auch heute noch unerllich, beispielsweise fr den bersetzerbau, ein-
gebettete Systeme oder fr systemnahe Programmierung in Teilen des Betriebs-
systems.
Thema der Vorlesung ist systemnahe Programmentwicklung; nebenluge
("concurrent") Ausfhrung von mehreren Teilablufen Nichtdeterminismus.
1.3 Literaturbersicht
Literatur, die als Basis fr diesen Vorlesungsteil verwendet wird.
1.3.1 Begleitend zur Vorlesung
Andrew S. Tanenbaum, "Modern Operating Systems", Prentice Hall, 2008;
dazu gibt es eine deutsche bersetzung
Andrew S. Tanenbaum, "Moderne Betriebssysteme", Pearson Studium,
2009
Abraham Silberschatz, Peter Galvin, Greg Gagne, " Operating System
Concepts. Operating System Concepts", Wiley & Sons, 2009
1.3.2 Weiterfhrende Literatur
Albrecht Achilles, "Betriebssysteme - Eine kompakte Einfhrung mit Linux",
Springer, 2006
Eduard Glatz, "Betriebssysteme - Grundlagen, Konzepte, Systemprogrammie-
rung", dpunkt.verlag, 2010
William Stallings, "Operating Systems - Internals and Design Principals",
Pearson International Edition, 2011
George Coulouris, Jean Dollimore, Tim Kindberg, "Distributed Systems -
Concepts and Design", Addison-Wesley, 2012
Andrew S. Tanenbaum, Marten van Steen, "Verteilte Systeme - Grundlagen und
Paradigmen", Pearson Studium, 2007
6
Kapitel 2
Einfhrung
Denition eines Betriebssystems nach DIN 44300:
Das Betriebssystem wird gebildet durch die Programme eines digitalen
Rechensystems, die zusammen mit den Eigenschaften der Rechenanlage die
Grundlage der mglichen Betriebsarten des digitalen Rechensystems bilden
und insbesondere die Ausfhrung von Programmen steuern und berwachen.
2.1 Betriebssystem - berblick
Ein Betriebssystem realisiert die Schnittstelle zwischen dem Benutzer und der
physischen Rechenanlage. Aus der Sicht des Benutzers entsteht durch ein Be-
triebssystemeine virtuelle Maschine. Fr 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 gehren zu den klassi-
schen Aufgabenstellungen der Systemprogrammierung. Je nach Art der Hardware
gibt es sehr unterschiedliche Typen von Betriebssystemen. Sie reichen von Be-
triebssystemen fr Grorechner, ber Server-BS bis hin zu PC-Betriebsystemen
und eingebetteten Betriebssystemen (z.B. in einem Android Smartphone).
2.1.1 BS-Hauptaufgaben
Ein Betriebssystem (engl. operating system) erfllt folgende Hauptaufgaben:
Veredeln der Hardware (Virtualisierung).
Steuerung und Kontrolle der Programmausfhrung.
7
Schlichter, TU Mnchen 2.1. BETRIEBSSYSTEM - BERBLICK
Interprozesskommunikation.
Verwaltung der Ressourcen (Speicher, CPU, Platten, Netz etc.) Betriebssy-
stem kann als Ressourcenverwalter gesehen werden.
Ressourcenklassen
Ein Rechensystem kann als strukturierte Sammlung von Ressourcenklassen
betrachtet werden, wobei jede Klasse durch Dienste des Betriebsystems
kontrolliert wird.
Zentral Ressourcen Periphere Ressour-
cen
Aktive Ressourcen Prozessoren (CPUs) Kommunikationseinheiten
wie Endgerte ( Tasta-
tur, Drucker, Monitor,
Maus) und Netzwerk
(lokal, entfernt)
Passive Ressourcen Arbeitsspeicher Speichereinheiten wie
Festplatten, CD, DVD
Anbieten von Diensten in Form von Schnittstellen, so dass die Ressourcen
genutzt werden knnen Hardwareunabhngige Programmierschnittstelle,
z.B. gerteunabhngige Ein-/Ausgabefunktionen.
Sicherheitsmechanismen.
Arbeitsmodi des Betriebssystems
Operationen des Betriebssystems und der Hardware mssen vor Programmier-
fehlern in Anwendungsprogrammen geschtzt werden Einfhrung eines Pri-
vilegiensystems.
Benutzermodus (user mode): Ausfhrung von Benutzerprogrammen,
kein direkter Hardware-Zugriff, keine privilegierten Befehl, nur virtuelle
Adressen.
Systemmodus (kernel mode): Ausfhrungsmodus der Dienste des BS-
Kerns, privilegierte Befehle erlaubt.
Benutzermodus Systemmodus
begrenzte Auswahl von Maschinen-
befehlen
alle ausfhrbaren Maschinenbefehle
Hardwarezugriff nur ber BS Vollzugriff auf Hardware
kein bzw. nur lesender Zugriff auf
Systemcode oder Daten
exklusiver Zugriff auf Systemcode
und Daten
8
Benutzerprozess
Betriebssystemkern
Ausfhrung
Benutzerprozess
System
Aufruf
Ausfhrung
Systemdienst
Rckkehr von
System Aufruf
Benutzermodus
Systemmodus
Struktureller Aufbau
Speicher
verwaltung
Prozess
verwaltung
Datei
system
Scheduler &
Dispatcher
EA-
System
Unterbrechungs-
System
Hardware
Konfiguration
Betriebssystem-Schnittstelle
Z
u
g
a
n
g
s
k
o
n
t
r
o
l
l
e
Benutzer-
Prozesse
System-
Prozesse
Schnittstelle zur Systemumgebung
berechtigte
Benutzer
berechtigte
Benutzer
login
zu berprf.
Benutzer
Ein anderer Blickwinkel
9
NY Times, Sept, 3, 1997: A decade ago, an "operating system" was just the
basic piece of software that ruled the machine and allowed it to manipulate
les, converse with any peripherals, and start up programs. That was when a
computer was just a nerd toy, not the foundation for the most vital part of of
our economy. But today, an "operating system" is much more a vote over who
gets to be the richest men in the world. Windows means Microsoft, Java means
Sun, while MacOs means That Steve Jobs wont go broke saving Apple. Linux
means no one gets rich because the OS is free, thanks to the help of many
volunteers.
2.1.2 Systemprogrammierung
Die Programmierung eines Betriebssystems gehrt zu dem Bereich der System-
programmierung.
Denition
Die Systemprogrammierung befasst sich mit der Darstellung, der Realisierung,
den Eigenschaften und der Konstruktion derjenigen Algorithmen fr ein
Rechensystem, die die Bearbeitung und Ausfhrung von Benutzerprogrammen
unter vorgegebenen Qualittsgesichtspunkten organisieren, d.h. steuern und
kontrollieren, und zum Teil selbst durchfhren.
direkte Nutzung der generischen Systemprogrammierschnittstelle des BS.
meist in Programmiersprache C.
Qualittskriterien knnen z.B. sein:
Zuverlssigkeit der durchgefhrten Berechnung (Behandlung von System-
crashs, Netzausfllen, fehlerhafter Nachrichtenbermittlung etc.).
Efzienz 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 Auftrge besitzen z.B.
eine Deadline bis zu der sie ausgefhrt sein mssen.
Durchsetzung von Sicherheitsanforderungen: Schutz der Daten und Informa-
tionen vor unberechtigten Zugriffen und Einsichtnahme.
Benutzerfreundlichkeit: bequeme Formulierungsmglichkeit von Benutzer-
auftrgen.
10
2.1.3 Hardwarekomponenten
Das Betriebssystem ist sehr eng mit der Hardware des Rechensystems verknpft,
auf dem es ausgefhrt wird. Es erweitert den Befehlssatz des Rechners und
verwaltet seine Ressourcen.
Deshalb an dieser Stelle einen kurzen berblick ber den Aufbau eines
Rechensystems.
CPU
Drucker
Northbridge Arbeitsspeicher
Systembus Speicherbus
USB
AGP
PCI Bus
EA-Karte
Grafik
EA-Karte
Sound
Southbridge
IDE
Festplatte
ISA Bus
(Maus,
Tastatur)
EA-Karte
LAN
PCI = Peripheral Component Interconnect
ISA = Industry Standard Architecture
USB = Universal Serial Bus
AGP = Accelerated Graphics Port (Anschluss von schnellen Grakkarten).
2.1.4 Betriebsarten
Beim Betrieb von Rechenanlagen knnen bzgl. des Zusammenwirkens von Be-
nutzer und Rechensystem die Betriebsweisen Stapelverarbeitung, Dialogbetrieb,
Transaktionsbetrieb und Echtzeitbetrieb unterschieden werden.
11
Stapelbetrieb
Das Rechensystem verarbeitet Strme von Auftragspaketen (engl. batch pro-
cessing). Ein Benutzer deklariert vollstndig alle Teile eines Auftragspaketes,
bevor es in das System eingegeben wird. Anschlieend wird das Auftragspa-
ket durch das Rechensystem abgearbeitet, ohne dass der Benutzer noch Ein-
ussmglichkeiten hat. Bei Auftreten eines Fehlers muss i.a. nach der Korrektur
das gesamte Auftragspaket nochmals gestartet werden. Auftragspakete knnen
in Unterabschnitte zerfallen, z.B. Teilprogrammablufe. Diese Betriebsart war
in den Anfngen von Rechenanlage sehr verbreitet (Nutzung von Lochkarten
und Lochstreifen).
Dialogbetrieb
Im Dialogbetrieb (engl. Timesharing) erteilt der Benutzer dem Betriebssystem
einen Auftrag nach dem anderen im Dialog. Innerhalb eines Benutzerauftrags
ndet 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.
Transaktionsbetrieb
Bewltigung einer Vielzahl von kleinen Aufgaben in krzester Zeit, z.B.
Bankberweisungen oder Buchungen. Dabei muss die Bearbeitung folgende
Kriterien, wie sie auch von Datenbanken bekannt sind, erfllen: Atomaritt,
Konsistenz, Isolation, Dauerhaftigkeit (engl. ACID), d.h. die Bearbeitung muss
entweder vollstndig ablaufen oder keinerlei nderung verursachen (Alles-
oder-nichts Prinzip).
Echtzeitbetrieb
In der Prozesssteuerung (automatische Fertigungssysteme, Roboter) und im
Multimediabereich sind die Reaktionszeiten des Betriebssystems von groer
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) bentigt ein Betriebssystem, das gewisse Echtzeitfhigkeiten hat.
Videos mssen mit einer bestimmten Geschwindigkeit abgespielt werden. Die
Bilder drfen an das Abspielprogramm nicht zu langsam (ansonsten ruckelt
12
Schlichter, TU Mnchen 2.2. BETRIEBSSYSTEM-ARCHITEKTUR
das Videobild) und nicht zu schnell ausgeliefert werden (sonst gehen bei
Pufferberlauf Videobilder verloren). Unterscheidung zwischen
harte Echtzeitsysteme: Reaktionszeit darf nicht berschritten werden.
weiche Echtzeitsysteme: gewisse Toleranzen bzgl. der Abweichung sind
erlaubt.
2.2 Betriebssystem-Architektur
In der Praxis ndet man einige verschiedene BS-Architekturkonzepte, wobei der
monolithische Ansatz und zunehmend auch der Mikrokern-Ansatz am weitesten
verbreitet sind.
2.2.1 Monolithischer Ansatz
Das Betriebssystem besteht aus einer umfangreichen Menge an Funktionen,
die sich bei Bedarf gegenseitig aufrufen knnen. Die Funktionen werden in
einem groen BS-Kern zusammengefasst. Der BS-Kern wird durch Aufruf von
Systemdiensten betreten.
BS-Kern arbeitet im Systemmodus.
Er hat hohe Ablaufprioritt.
Er ist permanent im Arbeitsspeicher.
13
Anwendung
Benutzerprozess
Anwendung
Benutzerprozess
Benutzer-Modus
(User Mode)
System-Modus
(Kernel Mode)
Systemdienste
(Hauptprozedur)
Hardware
Hilfs
funktionen
komplexe, monolithische Betriebssystem sind sehr schwierig zu warten und zu
erweitern.
Geschichtete Systeme
Einen Ausweg aus der Problematik monolithischer Systeme bieten geschichtete
Systeme;
das Betriebssystem besteht aus einer Hierarchie abstrakter Maschinen.
Jede Schicht hat wohldenierte Schnittstellen und eine wohldenierte
Aufgabe
Reduktion der Systemkomplexitt.
14
Anwendungen
abstrakte Maschine N
Funktionsschnittstelle
abstrakte Maschine N - 1
abstrakte Maschine 0
Rechnerhardware
Schicht N
Schicht N-1
Schicht 0
2.2.2 Mikrokern-Ansatz
Der Trend moderner Betriebssystem geht hin zu einem Mikrokern-Ansatz. Im
Mikrokern sind nur mehr Basismechanismen, z.B. Prozesskommunikation (Aus-
tausch von Nachrichten), CPU-Zuteilung. Mglichst viele Subsysteme sind als
Systemprozesse auerhalb des Mikrokerns realisiert. Sie laufen im Benutzer-
modus 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 aus-
gefhrt. Bentigt ein Prozess (Client) eine Dienstleistung schickt er eine Anfor-
derung an einen anderen Prozess (Server), der die Dienstleistung erfllt und die
Antwort an den Client zurckgibt. Die Kommunikation zwischen den beteiligten
Prozessen erfolgt ber den Mikrokern. Durch die Ausgliederung in Serverpro-
zesse ist eine Trennung von Mechanismus und Strategie mglich. Die Strategien
werden in Serverprozessen im Benutzermodus realisiert, whrend der Mikrokern
wenige Basismechanismen umfasst.
15
Einfaches Austauschen von Subsysteme ermglicht die einfache Anpas-
sung von Systemanforderungen.
Benutzer-Modus
(User Mode)
System-Modus
(Kernel Mode)
Mikrokern
Hardware
Benutzer
Programm
Prozess
Server
Memory
Server
File
Server
Netzwerk
Server
Display
Server
Anforderung
Antwort
2.2.3 Beispiel: BS-Architekturen
Unix Betriebssystem
Die nachfolgende Abbildung skizziert die wesentlichen Komponenten des
Unix Betriebssystems. Der Unix-BS-Kern enthlt die Datei-, Prozess- und
Prozessorverwaltung, die Speicherverwaltung und die Gerte-Treiber.
Hardware
Gerte Treiber
Datei
System
Unterbrechungs
behandlung
Prozess
verwaltung
Prozessor
verwaltung
Arbeitsspeicher
verwaltung
Systemschnittstelle
u.a. open,close, read, write; fork, exec, kill, ...
Programme Shells
Bibliotheken
(z.B. lib.a)
Betriebs-
systemkern
Programmier-
schnittstelle
Benutzungs-
schnittstelle
16
Windows NT Betriebssystem
Mit Hilfe von HAL wird versucht, die meisten Maschinenabhngigkeiten zu
verbergen. HAL prsentiert dem restlichen BS abstrakte Hardwaregerte (z.B.
Systembus, Arbeitsspeicher etc).
Hardware
Hardware Abstraction Layer (HAL)
Kernel
Object
Manager
Security
Manager
Process
Manager
Local
Procedure
Call Facility
Virtual
Memory
Manager
System Services
I/O Manager
File
Systems Cache Mgr
Device
Drivers
Network
Drivers
Hardware Manipulation
User Mode
Kernel Mode
Win32
Subsystem
Security
Subsystem
OS/2
Subsystem
Posix
Subsystem
Logon
Process
OS/2 Client Win32 Client Posix Client
Systemaufrufe
NT Executive
Protected
Subsysteme
(Servers)
Applications
System Interface (DLL)
Linux Betriebssystem
Linux begann Anfang der 1990er Jahre als eine Unix Variante fr den IBM PC;
erste Version durch Linus Torvalds (1991).
Linux ist frei und Quellcode ist verfgbar.
kollaborative Weiterentwicklung durch Open Source Community.
kein Mikrokern-Ansatz, jedoch modulare Struktur.
dynamic linking.
Module sind hierarchisch organisiert.
jeder Modul ist durch 2 Datenstrukturen beschrieben.
17
Modulbeschreibung, u.a Modulname, Gre, Zahl der exportierten Symbo-
le und referenzierte Module.
Symbol-Tabelle.
Prozesse
Processes &
scheduler
System
calls
Signals
Virtual
memory
Traps
faults
Physical
memory
device driver
(Char)
Interrupt
Device driver
(Block)
File system
Network
protocols
Network
driver
user mode
kernel mode
CPU Main memory terminal disk
Network interface
controller
2.2.4 Systemaufrufe
Die Schnittstelle zwischen dem Betriebssystem und den Benutzerprogrammen
wird durch eine Menge von Systemaufrufen (engl. system calls) gebildet. Sie
stellen fr Benutzerprogramme die einzige Schicht zum Zugriff auf Dienste des
Betriebssystems and damit zur Nutzung der Hardware dar.
in Benutzerprogrammen werden Systemaufrufe nicht direkt verwendet, sondern
dies erfolgt ber die Einbindung von Systembibliotheken, z.B. C-Library.
18
main ( ) {
--------------
printf ("hello);
--------------
}
-------------
printf erledigt Formatierung
--------------
Systemaufruf
Anwendung
Bibliotheksfunktion
-------------
write (1, "hello, 5);
--------------
Betriebssystemkern
Z.B. Zugriff auf Festplatte
Hardware
Benutzermodus
Systemmodus
Systemaufruf fhrt zum bergang vom Benutzermodus in den Systemmodus.
Beispiele von Systemaufrufen
Prozessmanagement: fork, waitpid, exit.
Dateimanagement: open, close, read, write.
Verzeichnismanagement: mkdir, rmdir, link, mount.
Gertemanagement: request/release device, get/set device attributes.
Kommunikationsmanagement: send/receive messages, create/delete
connection.
2.2.5 Virtuelle Maschine
Virtualisierungskonzept erlaubt die gleichzeitige Bereitstellung mehrerer Be-
triebssysteme auf einem Rechner.
Isolierung der virtuellen Maschinen.
gemeinsame Nutzung von Dateien mglich.
Beispiel VMware (URL: http://www.vmware.com/).
19
Hardware
CPU Arbeitsspeicher E/A-Gerte
Host Betriebssystem
(Linux)
Applikation Applikation Applikation
Virtualisierungsschicht
Gast-Betriebssystem
(free BSD)
virtuelle CPU
virtueller Speicher
virtuelle Gerte
Gast-Betriebssystem
(Windows XP)
virtuelle CPU
virtueller Speicher
virtuelle Gerte
Die Java Virtual Machine (JVM) speziziert einen abstrakten Computer, auf dem
Java Programme ausgefhrt werden. JVM ist ein Softwaresystem, das auf dem
Host-Betriebssystem ausgefhrt wird.
20
Kapitel 3
Synchronisation und
Verklemmungen
Historisch gesehen war der Ausgangspunkt eine Ein-Benutzer, Ein-Programm
Rechenanlage und zwar ohne ein Betriebssystem, das die Ausfhrung von
Programmen koordiniert. Fr die Ausfhrung von mehreren Programmen,
insbesondere wenn sie parallel ausgefhrt werden sollen, sind eine Reihe von
organisatorischen Manahmen notwendig. Die angesprochenen organisatorischen
Aufgaben sind wesentlicher Bestandteil der Aufgaben eines Betriebssystems
und die Programmierung eines Betriebssystems gehrt zu dem Bereich der
systemnahen Programmierung. Typischerweise nden in einem allgemeinen
Rechensystem eine Vielzahl paralleler Ablufe statt, die miteinander koordiniert
werden mssen.
3.1 Thread-Konzept
Threads sind ein BS-Konzept fr die Realisierung von nebenlugen Aktionen
in einem Rechensystem. Threads (Kontrollsse) beschreiben die Aktivitten in
einem Rechensystem. Sie knnen als virtuelle Prozessoren aufgefasst werden, die
jeweils fr die Ausfhrung eines zugeordneten Programms in einem Adressraum
verantwortlich sind. Threads konkurrieren um die physische CPU, um ablaufen
zu knnen. In traditionellen Umgebungen hat jeder Prozess genau einen Thread,
der den Kontrolluss des Prozess reprsentiert, whrend in Multithreaded-
Umgebungen ein Prozess mehrere Threads besitzen kann.
21
Schlichter, TU Mnchen 3.1. THREAD-KONZEPT
Prozess
Thread
Thread
Benutzer
Adressraum
Betriebssystem
3.1.1 Charakterisierung von Threads
Aus BS-Sicht ist ein Prozess deniert
durch einen Adressraum.
eine darin gespeicherte Handlungsvorschrift in Form eines sequentiellen
Programms (Programmcode).
einen oder mehreren Aktivittstrgern, die dynamisch die Handlungsvor-
schrift ausfhren Threads.
Motivation
Ein Thread ist die Abstraktion eines physischen Prozessors; er ist ein Trger einer
sequentiellen Aktivitt. Grnde fr die Einfhrung von Threads:
mehrere Threads ermglichen Parallelitt innerhalb eines Prozesses unter
Nutzung des gemeinsamen Adressraums.
Aufwand fr Erzeugen und Lschen von Threads ist geringer als fr Prozesse.
Threads fhren nicht so einen groen 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
Leichtgewichtsprozesse ("light weight processes"), da sie erheblich weniger
Verwaltungsinformation als normale Prozesse ("heavy weight processes")
bentigen.
Verbesserung der Performanz der Applikationsausfhrung durch Nutzung
mehrerer Threads. Dieses Argument ist besonders dann von Bedeutung, wenn
22
Schlichter, TU Mnchen 3.1. THREAD-KONZEPT
die Applikation (und damit der zugehrige Prozess) sowohl CPU- als auch E/A-
intensive Aktivitten beinhaltet. E/A-Wartezeiten innerhalb einer Applikation
knnen 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 Verfgung
steht).
Threads ermglichen bei einem Multiprozessor-Rechensystem echte Paralleli-
tt innerhalb einer Applikation.
Prozess vs. Thread
Prozesse und Threads haben unterschiedliche Zielsetzungen:
Prozesse gruppieren Ressourcen,
Threads sind Aktivittstrger, die zur Ausfhrung einer CPU zugeteilt
werden.
Threadspezische Information
Jeder Thread umfasst eine Reihe von Informationen, die seinen aktuellen
Zustand charakterisieren:
Befehlszhler, aktuelle Registerwerte, Keller, Ablaufzustand des Thread.
Prozessspezische Information
Die nachfolgende Information/Ressourcen wird von allen Threads eines
Prozesses geteilt. Jeder Thread des Prozesses kann sie verwenden bzw. darauf
zugreifen.
Adressraum, globale Variable, offene Dateien, Kindprozesse (z.B. erzeugt
mit fork), eingetroffene Alarme bzw. Interrupts, Verwaltungsinformation
Beispiel: Web-Server
Ein Prozess kann mehrere Threads umfassen, die unterschiedliche Aufgaben ber-
nehmen. Beispielsweise kann ein Web-Server einen Verteiler-Thread ("dispat-
cher") und mehrere Server-Threads ("worker-thread") umfassen.
23
Schlichter, TU Mnchen 3.2. SYNCHRONISATION
Web-Serverprozess
Benutzer
Adressraum
Betriebssystem
Verteiler-
Thread
Server-
Thread
Netzwerk-Verbindung
Anforderung
Auf diese Weise ist es mglich den Server als eine Menge von sequentiellen
Threads zu realisieren. Der Verteiler-Thread ist eine unendliche Schleife, die die
Schnittstelle fr 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.
Alle Server-Threads nutzen den gemeinsamen Web-Cache.
3.2 Synchronisation
Eine wichtige Systemeigenschaft betrifft die Synchronisation paralleler Ereignis-
se. Mehrere Prozesse (oder Threads) konkurrieren um eine gemeinsame Ressour-
ce (CPU), oder greifen auf gemeinsame Daten zu.
3.2.1 Beispiel: gemeinsame Daten
P1 und P2 sind nebenluge Prozesse, die in einem Multiprozessorsystem parallel
ablaufen. Die Variable x ist gemeinsame Variable. Prozess P1 luft auf CPU 0
mit Prozess P2 auf CPU 1 gleichzeitig ab. Das Problem ergibt sich auch bei
quasiparallelem Ablauf (zeitliche Verschrnkung der Arbeit der Prozesse). Z sei
ein Zeitpunkt nach Ausfhrung der Aktionen A und B. Welchen Wert hat x zum
Zeitpunkt Z?
24
Das Ergebnis des Ablaufs kann je nach zeitlichem Ablauf x = 1, 2, 3 sein.
Der grundlegende Nichtdeterminismus der Nebenlugkeit wegen der Asynchro-
nitt schlgt hier auf die Ergebnisse der Prozesse durch.
int x; x = 0
Prozess P1 Prozess P2
A: x = x + 1
B: x = x + 2
Zeitpunkt Z
Mgliche Ablufe
Das Ergebnis ist vom zeitlichen Ablauf abhngig. Es sind folgende Flle mglich:
Fall 1
P1 liest x = 0, erhht, speichert x = 1;
P2 liest x = 1, erhht, speichert x = 3; => Wert von x = 3
Fall 2
P2 liest x = 0, erhht, speichert x = 2;
P1 liest x = 2, erhht, speichert x = 3; => Wert von x = 3
Fall 3
P1 und P2 lesen x = 0;
P1 erhht, speichert x = 1;
P2 erhht, speichert x = 2; => Wert von x = 2
Fall 4
P1 und P2 lesen x = 0;
P2 erhht, speichert x = 2;
P1 erhht, speichert x = 1; => Wert von x = 1
25
Verhinderung des Nichtdeterminismus nur dadurch mglich, dass man garantiert,
dass die Vernderung von x in den beiden Prozessen unter wechselseitigem
Ausschluss (engl. mutual exclusion) erfolgt.
Der Zugriff auf gemeinsame Ressourcen, z.B. auf gemeinsame Variable, muss
koordiniert werden. Bei exklusiven Ressourcen wird die Nutzung sequentialisiert.
Prozess P1:
main () {
.......
region x do
x = x + 1:
end region
........
}
Prozess P2:
main () {
.......
region x do
x = x + 2:
end region
........
}
3.2.2 Synchronisierungskonzepte
Ziel: Einfhrung wichtiger Realisierungskonzepte zur Synchronisierung paralleler
Ablufe. Dazu Konkretisierung des Prozessbegriffs.
Anforderungen fr wechselseitigen Ausschluss
Folgende Anforderungen sind an eine Realisierung des wechselseitigen Aus-
schlusses (w.A.) zu stellen:
Die kritischen Abschnitte der Prozesse sind wechselseitig auszuschlieen.
Eine Realisierung des w.A. darf nicht von einer Annahme ber die Reihenfolge,
in der die Prozesse ihre kritischen Abschnitte ausfhren, abhngen.
Eine Realisierung des w.A. darf nicht von Annahmen ber die Ausfhrungszeit
der Prozesse abhngen.
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
auszufhren.
26
Jede Realisierung des w.A. bentigt eine Basis, mit festgelegten atomaren, d.h.
nicht teilbaren Operationen.
Konzepte fr wechselseitigen Ausschluss
Unterbrechungssperre
Der Ablauf des Prozesses darf nicht unterbrochen werden.
In Ein-Prozessorsystemen (1 CPU) kann es ausreichend sein, mit Enable und
Disable Interrupt Operationen dafr zu sorgen, dass der Prozess, der einen
kritischen Abschnitt ausfhrt, dabei nicht unterbrochen wird.
Realisierung mit Unterbrechungssperre ist ntzlich fr den Betriebssystem-
kern, aber sollte nicht fr allgemeine Benutzerprogramme zur Verfgung ste-
hen.
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 dieses Wortes. Diese beiden
Operationen werden als atomare, unteilbare Sequenz ausgefhrt.
Sei a die zu untersuchende Speicherzelle; der Wert 1 in der Speicherzelle
kann dahingehend interpretiert werden, dass der Zugang in den kritischen
Bereich nicht mglich ist.
Befehl "TSL R, a" entspricht dann
Register R = inhalt von a;
a = 1
Falls R = 1 ist, ist der kritische Bereich bereits belegt, andernfalls war er
frei und er wurde vom ausfhrenden Prozess belegt.
Problem: wie Atomaritt bei Rechensystem mit mehreren CPUs gewhr-
leistet?
Lsung: Die CPU, die die TSL-Instruktion ausfhrt, blockiert den
Speicherbus, um andere CPUs (Multi-Prozessorumgebung) daran zu
hindern, auf die Speichereinheit zuzugreifen.
27
Dienste mit passivem Warten
Unterscheidung zwischen
aktivem Warten: Prozess muss periodisch selber prfen, ob die Vorausset-
zungen zum Weiterarbeiten erfllt sind.
passivem Warten: Prozess wird in Warte-Zustand versetzt und aufgeweckt,
wenn das Ereignis, auf das er wartet, eingetreten ist.
Methoden oder Dienste, so dass unter Mithilfe des Betriebssystems ein
Prozess in den Zustand wartend bergefhrt wird.
beim Eintreten eines passenden "Weckereignisses" wird der Prozess
vom Betriebssystem vom Zustand wartend in den Zustand rechenbereit
bergefhrt.
Beispiel: Java wait und notify.
Semaphor-Konzept
Das Semaphor-Konzept ermglicht die Realisierung des w.A. auf einem h-
heren Abstraktionslevel als die bereits angesprochenen Hardwareoperationen.
Zur Realisierung wird aber auf diese wieder zurckgegriffen. Realisierung von
Semaphoren mit aktivem und passivem Warten mglich.
Monitor-Konzept
Das Monitor-Konzept basiert auf der Idee, die in einem kritischen Bereich
bearbeiteten Daten zusammen mit den darauf denierten Zugriffsoperationen
in einer sprachlichen Einheit - dem Monitor - zusammenzufassen.
soll Probleme, wie sie bei der Programmierung von Semaphoren auftreten,
vermeiden.
zu einem Zeitpunkt hchstens ein Prozess innerhalb des Monitors aktiv.
28
Initialisierungscode
Operationen
Gemeinsame Daten
Warte
schlange
Denition von Bedingungsvariablen zur Spezikation anwendungsspezi-
scher Bedingungen.
Operationen auf Bedingungsvariable cond
cond.wait(): Prozess wird wartend gesetzt.
cond.signal(): ein wartender Prozess wird aktiviert.
3.2.3 Semaphore
Semaphore wurden 1968 von Dijkstra eingefhrt. Ein Semaphor (Signalmast) ist
eine ganzzahlige Koordinierungsvariable s, auf der nur die drei vordenierten
Operationen (Methoden) zulssig sind:
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 ausgefhrt.
Sei s die Koordinierungsvariable, dann sind die P und V Operationen wie
nachfolgend deniert.
Die Operation mssen mit Hilfe von Systemdiensten so realisiert werden, dass
sie wechselseitig ausgeschlossen ausgefhrt werden. Vorsicht: hier gibt es keine
ganz einheitliche Denition in der Literatur fr die beiden Operationen. Mgliche
Realisierung auf Hardware-Ebene mittels des Test-and-Set Maschinenbefehls.
29
Informelle Charakterisierung
public void P (int s) {
s = s - 1;
if ( s < 0 ) { Prozess in die Menge der bzgl. s wartenden
Prozesse einreihen }
}
public void V (int s) {
s = s + 1;
if ( s 0 ) { fhre genau einen der bzgl. s wartenden
Prozesse in den Zustand rechenwillig ber }
}
Binres Semaphor: die Kontrollvariable s nimmt nur boolesche Werte an.
man spricht auch von Mutex.
Mutex in Posix
Ein Posix Mutex ist als binres Semaphor eine einfache Sperre, die die
Nutzung gemeinsamer Ressourcen absichert.
pthread_mutex_init(mutex) initialisiert und konguriert ein Mutex.
pthread_mutex_lock(mutex) entspricht der P-Operation; sperrt ein
Mutex.
pthread_mutex_unlock(mutex) entspricht der V-Operation; gibt ein
Mutex frei.
Mutex Objekte und Semaphore mit Integer Werten stehen auch in Windows
zur Verfgung.
Einsatz von Semaphoren
Notation: Zur Vereinfachung gehen wir im Folgenden von einem vordenierten
Typ semaphor(int s) aus, der die P und V Operationen als vordenierte,
atomare Methoden anbietet. Semaphor-Objekte werden als Instanzen bezglich
des Typs semaphor erzeugt, wobei bei der Instantiierung das Semaphor mit dem
Parameter s initialisiert wird.
Zugang zu kritischen Abschnitten
Realisierung der kritischen Abschnitte von Prozessen, in denen auf eine
exklusiv benutzbare Ressource X zugegriffen wird:
1. Denition eines Semaphor-Objekts wa: semaphor(1), d.h. Initialisierung der
Kontrollvariable des Semaphor-Objekts wa mit 1.
30
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 Lsungen des wechselseitigen Ausschlusses sind mit
dem Semaphor-Konzept aus folgenden Grnden erfllt:
Wechselseitiger Ausschluss fr alle kritischen Abschnitte. Aufgrund der
Initialisierung der Koordinierungsvariablen mit 1 kann sich stets nur ein
Prozess in einem kritischen Abschnitt benden.
keine Reihenfolge-Annahmen.
keine Ausfhrungszeit-Annahmen.
kein Verhungern.
Beispiel Erzeuger-Verbraucher
Im Modellierungsteil wurde das Erzeuger-Verbraucher-Problem 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.
Lsung dieses Problems mittels Semaphor.
Variante 1
Zugriff auf Puffer W erfolgt durch Semaphor wa: semaphor(1);
Erzeuger E:
while (true) {
produziere
wa.P
schreibe nach W
wa.V
}
Verbraucher V:
while (true) {
wa.P
entnimm aus W, falls Element da; sonst warte
wa.V
verarbeite
}
31
Problem: es kann eine Verklemmung auftreten, wenn der Verbraucher wa.P
ausfhrt und warten muss, weil der Puffer kein Element enthlt.
Variante 2
Einfhren eines zustzlichen Semaphors voll: semaphor(0), das die Datenele-
mente im Puffer zhlt:
Erzeuger E:
while (true) {
produziere
wa.P
schreibe nach W
wa.V
voll.V
}
Verbraucher V:
while (true) {
voll.P
wa.P
entnimm aus W
wa.V
verarbeite
}
Fr den Erzeuger ergibt sich natrlich ein analoges Problem, falls der Puffer W
nur eine beschrnkte Kapazitt besitzt.
Variante 3
Einfhren eines zustzlichen Semaphors leer: semaphor(n), das die Anzahl der
freien Elemente im Puffer zhlt:
Erzeuger E:
while (true) {
produziere Einheit;
leer.P;
wa.P;
schreibe Einheit nach W;
wa.V;
voll.V;
}
Verbraucher V:
while (true) {
voll.P;
wa.P;
entnimm Einheit aus W
wa.V
leer.V;
verarbeiteEinheit;
}
wa.semaphor(1); //kontrolliert den Zugang zum kritischen Bereich
voll.semaphor(0); //zhlt die Anzahl der Einheiten im Puffer
leer.semaphor(n); //zhlt die Anzahl der freien Pufferpltze
32
Beispiel Philosophenproblem
Zu den klassischen Synchronisationsproblemen zhlt das Problem der speisenden
Philosophen ("Dining Philosophers"). In einem Elfenbeinturm leben fnf
Philosophen. Der Tageszyklus eines jeden Philosophen besteht abwechselnd aus
Essen und Denken. Die fnf Philosophen essen an einem runden Tisch, auf dem in
der Mitte eine Schssel voller Reis steht. Jeder Philosoph hat seinen festen Platz
an dem Tisch und zwischen zwei Pltzen liegt genau ein Stbchen. Das Problem
der Philosophen besteht nun darin, dass der Reis nur mit genau zwei Stbchen
zu essen sind. Darber hinaus darf jeder Philosoph nur das direkt rechts und das
direkt links neben ihm liegende Stbchen zum Essen benutzen. Das bedeutet, dass
zwei benachbarte Philosophen nicht gleichzeitig essen knnen.
1
0
4
3
2
0
1
2
3
4
Realisierung mit Semaphoren
Variante 1
Fr eine Lsung des Philosophenproblems seien die folgenden 5 Semaphore
deniert: stab_0, stab_1, ...., stab_4, wobei jedes der 5 Semaphore mit 1
initialisiert ist. Jeder Philosoph j, mit j {0,...,4}, fhre den folgenden
Algorithmus aus:
philosoph_j:
while (true) {
Denken;
stab_i.P; mit i = j
stab_i.P; mit i = j + 1 mod 5
Essen
stab_i.V; mit i = j
stab_i.V; mit i = j + 1 mod 5
}
33
Variante 2
Nur vier Philosophen drfen gleichzeitig zu ihrem linken Stbchen
greifen. Dies wird durch Einfhrung eines weiteren Semaphors tisch:
semaphor(4), das mit 4 initialisiert wird, erreicht. Der "Anweisungsteil"
jedes Philosophen wird zustzlich mit tisch.P und tisch.V geklammert.
Es ergibt sich also folgende Lsung: Jeder Philosoph j, mit j {0,...,4} fhrt
den folgenden Algorithmus aus:
philosoph_j:
while (true) {
Denken;
tisch.P
stab_i.P; mit i = j
stab_i.P; mit i = j + 1 mod 5
Essen
stab_i.V; mit i = j
stab_i.V; mit i = j + 1 mod 5
tisch.V
}
3.2.4 Synchronisierung von Java Threads
Java untersttzt synchronisierte Methoden.
public synchronized void methodname(...) { ... }
Eine synchronisierte Methode kann nur exklusiv von einem Java Thread betreten
werden.
Beispiel TakeANumber Class
Nur ein Thread kann zu einem Zeitpunkt eine Nummer ziehen
class TakeANumber {
private int next = 0; //next place in line
public synchronized int nextNumber() {
next = next + 1; return next;
} //nextNumber
} //TakeANumber
34
public class Customer extends Thread {
private static int number = 1000; //initial customer ID
private int id;
private TakeANumber takeANumber;
public Customer(TakeANumber gadget) {
id = ++number;
takeANumber = gadget;
} //Customer constructor
public void run() {
try {
sleep( (int)(Math.random() * 1000) );
System.out.println("Customer "+id+" takes ticket " +
takeANumber.nextNumber());
} catch ......
} //run
} //Customer
public class Bakery {
public static void main(String args[]) {
System.out.println("Starting Customer threads");
TakeANumber numberGadget = new TakeANumber();
.........
for (int k = 0; k < 5; k++) {
Customer customer = new Customer(numberGadget);
customer.start();
}
} // main
} //Bakery
Java Monitor
Ein Monitor ist ein Java-Objekt, das synchronisierte Methoden enthlt.
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.
Whrend das Objekt gesperrt ist, knnen keine anderen synchronisierten
Methoden des Objekts aufgerufen werden.
Kritische Abschnitte knnen in Java als Objekte mit den zugehrigen
synchronisierten Methoden speziziert werden.
35
Schlichter, TU Mnchen 3.3. VERKLEMMUNGEN
3.3 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 knnen.
Verklemmungen knnen durch die gemeinsame Verwendung von Ressourcen
(synonym verwenden wir auch den Begriff Betriebsmittel), wie z.B. CPU,
Arbeitsspeicher, E/A-Gerte, Dateien auftreten.
Der Austausch von Information ber gemeinsame Speicherbereiche ist eine
huge Situation (speicherbasierte Prozessinteraktion), die bei unkorrekter
Verwendung von Synchronisationsoperationen (z.B. P und V bei Semaphoren)
leicht zu Verklemmungen fhren kann; siehe die Variante 1 des Erzeuger-
Verbraucher Lsungsansatzes. Dieser Abschnitt skizziert nur die Anstze zur
Erkennung, Vermeidung und Verhinderung von Verklemmungen.
3.3.1 Allgemeines
Es lsst sich zeigen, dass die folgenden Bedingungen notwendig und hinreichend
dafr sind, dass eine Verklemmung auftreten kann.
1. Die gemeinsam benutzbaren Ressourcen knnen nicht parallel genutzt werden,
d.h. sie sind nur exklusiv benutzbar.
2. Die zugeteilten/belegten Ressourcen knnen 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 nchste Prozess in der Kette bentigt, d.h. zirkulre
Wartebedingung.
3.3.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.
36
Beispiel
Seien P = {P1, ... , Pn} Prozesse und R= {R1, ... , Rm} Ressourcen, z.B. n = 3
und m = 4. Beispiel eines Belegungs/Anforderungsgraphen.
P1 R1
fordert
R2
belegt
P2
belegt
fordert
R3
fordert
P3
belegt
R4
belegt
3.3.3 Verklemmungs-Ignorierung
In vielen Systemen wird eine Vogel-Strau-Politik in bezug auf die Deadlock-
problematik verfolgt, d.h. es werden keine Manahmen eingesetzt, sondern es
wird gehofft, dass alles gut geht. In Unix wird diese Philosophie z.B. bei der Ver-
waltung der Prozesstabelle verfolgt.
3.3.4 Verklemmungs-Erkennung
In der Praxis hug angewendete Strategie: Verklemmungen in Kauf nehmen, sie
erkennen und beseitigen.
Erkennungs-Algorithmus
Ansatz 1: Suche nach Zyklen im Belegungs/Anforderungsgraph.
Ansatz 2: Prfen, ob es eine Reihenfolge fr die Ausfhrung der Prozesse gibt,
so dass alle Prozesse terminieren knnen.
Vorgehen fr Ansatz 2
1. Starte mit Prozessmenge P, die alle Prozesse enthlt,
2. suche Prozess p aus P, dessen zustzliche Anforderungen im aktuellen
Zustand erfllbar 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,
37
6. falls P = und in Schritt 2 kein Prozess mehr gefunden wird, dessen
Anforderungen erfllbar sind, dann terminiert die Suche; P enthlt die Menge
der verklemmten Prozesse.
Ausung einer Verklemmung in der Regel durch Abbruch einzelner Prozesse.
3.3.5 Verklemmungs-Verhinderung
Die Verhinderungssverfahren beruhen darauf, dass man durch die Festlegung von
Regeln dafr sorgt, dass mindestens eine der fr das Auftreten von Deadlocks
notwendigen Bedingungen nicht erfllt ist.
Festgelegte lineare Reihenfolge
Bedingung "Zyklus tritt auf" in Belegungs-/ Anforderungsgraph darf nicht
erfllt werden. Dazu wird eine lineare Ordnung ber den Ressourcen deniert:
R1 < R2 < ... Rm.
Die Prozesse drfen dann Ressourcen nur gem dieser Ordnung anfordern,
d.h. ein Prozess, der Ressource Ri belegt, darf nur Ressourcen Rj anfordern,
fr die gilt: Rj > Ri.
Andere Mglichkeiten sind:
a) Zuteilung aller bentigten Ressourcen zu einem Zeitpunkt.
b) zwangsweiser Entzug aller belegter Ressourcen, falls eine Ressourcen-
Anforderung nicht erfllt werden kann.
c) Spooling: nur der Spooler Prozess hat als einziger die Ressource
zugeteilt; Zugriffe anderer Prozesse gehen ber diesen Prozess. Beispiel
ist das Spooling von Druckauftrgen.
3.3.6 Verklemmungs-Vermeidung
Die Vermeidungsverfahren basieren auf der Idee,
die zuknftigen Betriebsmittelanforderungen von Prozessen zu analysieren
(bzw. diese geeignet abzuschtzen) und
solche Zustnde zu verbieten (sie also zu verhindern), die zu Verklemmungen
fhren knnten.
Ein Beispiel ist der Bankiers-Algorithmus, der 1965 von Dijkstra entwickelt
wurde.
38
Veranschaulichung des Algorithmus
Veranschaulichung des Verfahrens anhand eines Bankenszenarios.
Ausgangspunkt
Idee: Verwaltung von nur einer Ressourcen-Klasse, nmlich 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 Verfgung stehende
Geldmenge des Bankiers ist.
Bankier hat weniger Geld als die Summe dieser Kreditrahmen.
Kunden knnen jederzeit Geld in der Hhe ihres jeweiligen Kreditrahmens
fordern, mssen aber ggf. in Kauf nehmen, dass der Bankier diese Forderung
erst nach endlicher Zeit erfllt.
Aufgabe des Bankiers
Verleihen des Geldes so, dass jeder Kunde seine Geschfte in endlicher Zeit
durchfhren kann und Kunden mglichst parallel bedient werden.
Idee: Reihenfolge fr Kreditvergabe nden, so dass selbst bei denkbar un-
gnstigsten Kreditforderungen die Durchfhrung aller Geschfte sicherge-
stellt ist.
ungnstigster Fall: alle Kunden fordern Geld bis zu ihrem jeweiligen max.
Kreditrahmen, ohne Kredite zurckzuzahlen.
Grobes Vorgehen
1. falls ein Kunde (Prozess) eine Anforderung hat, die aktuell erfllbar ist,
so teilt man das Geld (die Ressource) probeweise zu und
2. untersucht fr den sich damit ergebenden Zustand, ob jetzt eine
Verklemmung vorliegt, indem
3. fr alle anderen Kunden von deren ungnstigsten Anforderungen
ausgegangen wird und
4. ein Erkennungs-Algorithmus ausgefhrt wird.
Falls keine Verklemmung auftritt, kann die Zuteilung tatschlich erfolgen,
anderenfalls knnte bei einer Zuteilung ein Deadlock auftreten (muss aber
nicht), weshalb die Anforderung nicht erfllt wird.
39
Beispiel
Ausgangspunkt ist die folgende Situation der vier Kunden A, B, C, D(Einheiten
jeweils in Tausend Euro):
Kunde aktueller Kredit max. Kreditrahmen
A 1 6
B 1 5
C 1 4
D 4 7
Es seien noch 3 Einheiten (Tausend Euro) in der Bank als Kredit verfgbar.
Annahme: Kunde C fordere eine weitere Einheit als Kredit an. Diese
Anforderung wird probeweise zugeteilt und mndet nicht in einemDeadlock,
da zuerst C (max noch 2 Einheiten bis Kreditrahmen) bedient werden kann.
Wenn C seine Einheiten wieder zurckgezahlt hat, knnen B oder D und
schlielich A bedient werden.
40
3.3.7 Vergleich der Anstze
Ansatz Verfahren Vorteile Nachteile
Erkennung periodischer
Aufruf des
Erkennungs
Algorithmus
Prozesserzeugung
wird nicht verz-
gert; erleichtert
interaktive Reak-
tion
Verlust durch Ab-
bruch
Verhinderung feste Reihefolge
bei der Zuteilung
keine Verklem-
mungsanalyse
zur Laufzeit
notwendig; ber-
prfung whrend
bersetzung
keine inkremen-
tellen Anfragen
fr Ressourcen
mglich
Zuteilung aller
Ressourcen auf
einmal
keine Premp-
tion (Entzug)
von Ressourcen
notwendig; gut
fr Prozesse mit
einzelner Aktivi-
ttsphase (single
burst)
inefzient;
verzgert Pro-
zesserzeugung;
Bedarf fr Res-
sourcen muss
bekannt sein
Vermeidung Bankiers-
Algorithmus
keine Premp-
tion (Entzug)
von Ressourcen
notwendig
zuknftiger
Bedarf muss
bekannt sein;
Prozesse knnen
lngere Zeit
blockiert werden
41
Kapitel 4
Prozess- und Prozessorverwaltung
Ein Prozess ist der Ablauf eines Programms in einem Rechensystem. Dieser
Ablauf ist eine Verwaltungseinheit im jeweiligen Betriebssystem.
4.1 Fragestellungen
Dieser Abschnitt gibt eine kurze Einfhrung in eine der wichtigen Verwaltungs-
aufgaben eines Betriebssystems:
Verwaltung von Prozessen.
Verwaltung des Prozessors, d.h. Zuteilung der CPU an rechenbereite Prozesse
(Scheduling).
Unterbrechungskonzept.
4.2 Prozessverwaltung
Dieser Abschnitt behandelt das Prozesskonzept, Datenstrukturen zur Beschrei-
bung des aktuellen Prozesszustandes sowie Dienste zum Aufruf von Systemfunk-
tionen.
Prozesse reprsentieren eine Aktivitt; sie haben ein Programm, Eingaben,
Ausgaben und einen Zustand.
42
Schlichter, TU Mnchen 4.2. PROZESSVERWALTUNG
4.2.1 Prozesskonzept
Wir unterscheiden Benutzerprozesse, die Anwendungsprogrammen in Ausfh-
rung entsprechen, und Systemprozesse, die Programme/Dienste des Betriebssy-
stems durchfhren.
a) Jeder Prozess besitzt einen eigenen Prozessadressraum.
b) Spezielle Systemprozesse sind die Dmonen (engl. daemon); das sind
Hilfsprozesse, die stndig existieren, die meiste Zeit aber passiv sind.
Dienste der Prozessverwaltung
Die Prozesse werden durch das Betriebssystem verwaltet.
Auslsende Ereignisse fr die Erzeugung eines Prozesses
Initialisierung des Systems.
Systemaufruf zum Erzeugen eines Prozesses durch einen anderen Prozess.
Benutzeranforderung zum Starten eines neuen Prozesses (Start einer
Applikation).
Auslsung eines Stapelauftrags (Batch Job).
Formen der Terminierung von Prozessen
Normale Beendigung (freiwillig).
Vorzeitige Beendigung bei einem durch den Prozess selbst erkannten Fehler
(freiwillig).
Vorzeitige Beendigung bei einem katastrophalen Fehler, erkannt durch das
BS (unfreiwillig).
Terminierung durch einen anderen Prozess (unfreiwillig).
Prozess-Auswahl, Strategien zur Prozessorzuteilung: Scheduling.
Prozessor-Anbindung; Dispatching.
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
(struct) speziziert. Ein PCB (process control block) enthlt i.d.R. folgende
Informationen:
43
eindeutiger Name, z.B. fortlaufende Nummerierung des Prozesses (z.B. pid in
Unix)
Name des Benutzers, dem der Prozess zugeordnet ist
der momentane Prozesszustand (wartend, rechnend, rechenwillig, ...)
falls der Prozess rechnend ist, Angabe der zugeordneten CPU
falls der Prozess wartend ist, eine Spezikation des Ereignisses, auf das der
Prozess wartet (z.B. Adresse eines Semaphors).
die Ablaufprioritt des Prozesses
die Inhalte der programmierbaren Register (die Anzahl ist abhngig von der
jeweiligen CPU-Architektur), z.B. Kellerpointer.
die Inhalte der Register, in denen die Anfangsadresse und Lnge der pro-
zessspezischen Speicherabbildungstabellen enthalten sind (virtuelle Adressie-
rung).
das Programmstatuswort (PSW).Beispiele fr dem Inhalt des PWSs sind der
Ablaufmodus (Benutzer- oder Systemmodus), die momentane Ablaufprioritt,
die Adressierungsart im Benutzermodus (virtuelle oder direkte Adressierung)
und die Ergebnisse der letzten Vergleichsoperation auf Maschinenebene
(sogenannte Condition-Code Register, z.B. das N-Register (Ergebnis der letzten
Operation negativ).
PCB unter Linux ist durch die Struktur task_struct speziert; deniert unter
include/linux/sched.h .
Prozesslisten
Die Prozesse werden in Zustandslisten verwaltet, die als verkettete Liste der PCBs
realisiert sind.
fr E/A-Gerte (z.B. Platte, Terminal) existiert i.d.R. jeweils eine eigene
Warteschlange, die die PCBs der wartenden Prozesse enthlt.
44
Rechnend
Rechenwillig
Wartend
Prozessidentifikation
Registerzustand
Scheduling Information (z.B.
Prioritt)
Adressrauminformation
Sonstiges
nchster PCB
Ready-Queue
Prozesskontrollblock PCB
Zustandsmodell
Das Prozess-Zustandsmodell unterscheidet neben den bereits vorgestellten
Zustnden 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").
rechnend
wartend
rechenwillig
ausgelagert
ready
assign
block
add retire
resign
swap out
swap in
Zustandsbergnge sind:
add: ein neu erzeugter Prozess wird zu der Menge der rechenwilligen Prozesse
hinzugefgt;
assign: als Folge eines Kontextwechsels wird dem Prozess die CPU zugeordnet;
45
block: aufgrund eines EA-Aufrufs oder einer Synchronisationsoperation wird der
Prozess wartend gesetzt;
ready: nach Beendigung der angestoenen Operation wechselt der Prozess in den
Zustand rechenwillig; er bewirbt sich erneut um die CPU;
resign: dem rechnenden Prozess wird die CPU entzogen; er bewirbt sich
anschlieend erneut um die CPU;
retire: der aktuell rechnende Prozess terminiert;
swap out: der Prozess wird auf die Festplatte ausgelagert;
swap in: der Prozess wird von der Festplatte in den Arbeitsspeicher geladen.
Prozesserzeugung
Ein Prozess kann andere Prozesse erschaffen. Diese sind die Kindprozesse (child
process) und der Erschaffer ist der Vater (parent process). Vater
kann auf Beendigung von Kind warten, oder
parallel weiterlaufen.
Prozesserzeugung: 2 Vorgehensweisen
Windows NT: Vaterprozess veranlasst eine Reihe von Systemaufrufen, die
das Kind entstehen lassen.
Unix: Vater klont sich mit Systemaufruf fork(); Kind ndert selbst sein
Aufgabe.
Unix Prozesserzeugung
Aufruf von fork() fhrt zu einem fast exakten Duplikat des Vaterprozesses.
Unterschiede sind
unterschiedlicher process identier (PID)
der Ergebniswert von fork()
Vater: PID des Kindprozesses
Kind: 0
Beispielprogramm
#include <stdio.h>
46
int main(int argc, char *argv[]) {
char *myname = argv[1];
int cpid = fork();
if cpid == 0 {
printf("The child of %s is %d\n", myname, getpid());
.......
return (0);
} else {
printf("My child is %d\n", cpid);
/* wird vom Vaterprozess durchlaufen */
.....
return(0);
}
}
Kind hat vieles mit dem Vater gemeinsam:
liest dieselben Dateien, gleicher Benutzername, benutzt dieselben Daten
Unix Kind fngt mit dem Code des Vaters an und ndert sich dann
Systemaufruf exec(): ersetzt das Programmbild des Vaters mit einem
anderen.
Beispielprogramm fr exec
#include <stdio.h>
int main(int argc, char *argv[]) {
char *myname = argv[1];
int cpid = fork();
if cpid == 0 {
int rc;
rc = execl("/bin/ls", "ls", "-l", (char *) 0);
printf("Fehler bei execl Aufruf: %d\n", rc);
exit(1)
} else {
/* wird vom Vaterprozess durchlaufen */
}
}
Prinzipablauf
Mit der Systemfunktion wait wartet der Vaterprozess auf den Kindprozess.
wait vor Beendigung des Kindes: Vater ist blockiert.
wait nach Beendigung des Kindes: Kind wird nach Beendigung zum
Zombieprozess.
47
Vater
fork
Vater
Kind
wait
exit
Vater
Vater
fork
Vater
Kind
wait
exit
Vater
Zombieprozess
Linux untersttzt den Systemaufruf clone() zur Erzeugung neuer Thread-
Kopien.
Prozesse und Vererbung
Bei der Verwaltung von Vater-/Kindprozess sind eine Reihe von Entscheidungen
zu treffen:
Ausfhrung
Vaterprozess und Kind werden gleichzeitig ausgefhrt, oder
der Vaterprozess wartet darauf, dass das Kind beendet wird
Ressourcen
Vater und Kind teilen sich alle Ressourcen.
Vater und Kind teilen sich einen Teil der Ressourcen.
Vater und Kind haben keine Ressourcen gemeinsam.
Adressraum
Das Kind ist ein Duplikat des Vaters.
Das Kind fhrt durch automatisches Laden ein neues Programm aus (exec-
Systemaufruf).
Threads
Das Kind dupliziert alle Threads des Vaters.
Das Kind dupliziert nur den Thread des Vaters, der die fork-Operation
ausgelst hat.
48
4.2.2 Dispatcher
Aufgabe des Dispatchers: Realisieren der Zustandsbergnge zwischen rechnend
und rechenwillig: Prozessor binden und entbinden. Dazu ist ein Kontextwechsel
erforderlich.
Kontextwechsel
CPU wird entzogen und einer anderen Aktivitt zugeteilt; ein Kontextwechsel ist
erforderlich, falls der rechnende Prozess P1 in den Zustand wartend oder z.B.
durch Prozessorentzug in den Zustand rechenwillig bergefhrt wird.
Problem
aktueller Ausfhrungskontext des Prozesses muss gesichert werden und
Kontext des nchsten rechenbereiten Prozesses muss geladen werden.
Achtung: je umfangreicher ein PCB ist, desto "teurer" sind Prozesswechsel,
d.h. das Umschalten der CPU zwischen den Prozessen.
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.
4.2.3 Arbeitsmodi
Ziel fr den Betrieb von Rechensystemen: kontrollierter Zugriff auf Hardware-
komponenten nur durch BS. Dadurch soll verhindert werden, dass Benutzer oder
Softwaresysteme Hardwarekomponenten unsachgem nutzen, und implizit an-
dere nebenluge Aktivitten schdigen.
Lsung: alle Zugriffe auf Hardware nur ber privilegierte Befehle zulssig;
Frage: wer darf privilegierte Befehle ausfhren Antwort: Prozesse in einem
privilegierten Modus.
Herkmmlich unterscheidet man zwischen dem Benutzer- (engl. user mode) und
dem Systemmodus (engl. kernel mode).
Benutzermodus
49
Es sind nur die nicht privilegierten Befehle verfgbar. Damit ist der Zugriff auf
Prozessadressraum und unkritische Register, wie Befehlszhler, Indexregister
mglich. Benutzerprozesse werden im Benutzermodus ausgefhrt. Kritische
Register, ber die der Kontext eines Prozesses beeinusst werden kann
(z.B. Ablaufprioritt, Arbeitsmodus) knnen nur im Systemmodus verndert
werden. Wird versucht, einen privilegierten Befehl auszufhren, gibt es einen
Befehlsalarm.
Systemmodus
Es sind auch die privilegierten Befehle verfgbar (z.B. Anhalten der Maschine,
Verndern der Ablaufprioritt). Die Dienste des Betriebssystemkerns werden
im Systemmodus ausgefhrt.
Nutzung der Hardware-Komponenten nur ber Dienste des BS: Aufruf eines
BS-Dienstes ber spezielle Befehle: den Systemaufruf.
4.2.4 Systemaufrufe
Ein Systemaufruf ist eine Funktion, die von einem Benutzerprozess aufgerufen
wird, um einen BS-Kerndienst aufzufhren.
1. Der Systemaufruf berprft 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), aus-
gefhrt. Diese Instruktion identiziert ber einen Operanden den gewnsch-
ten Systemdienst.
3. Bei Ausfhrung der Trap-Instruktion wird der Zustand des Benutzerprozes-
ses gerettet und es ndet ein Wechsel in den Systemmodus statt.
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) Schlieen beider Dateien
(8) Ausgabe auf Bildschirm
50
Durch die Verwendung von Laufzeitroutinen ergibt sich eine hhere Abstrakti-
onsebene Aufruf einer Routine, die die notwendigen Systemaufrufe durch-
fhrt.
4.2.5 Realisierung von Threads
Es existieren zwei grundlegende Anstze, 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.
Prozess Thread
Laufzeit-
system
Benutzer
Adressraum
(Benutzermodus)
BS-Kern
System
Adressraum
(Systemmodus)
Prozess-
tabelle
Thread
tabelle
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.
Problem: Systemaufruf eines Threads blockiert die anderen Threads des
Prozesses.
Problem: wie wird einem Thread die CPU entzogen?
51
Schlichter, TU Mnchen 4.3. PROZESSORVERWALTUNG
im System-Adressraum
Neben den Prozessen werden im BS-Kern auch alle Threads verwaltet.
Prozess Thread
Benutzer
Adressraum
(Benutzermodus)
BS-Kern
System
Adressraum
(Systemmodus)
Prozess-
tabelle
Thread
tabelle
Thread-Tabelle speichert Informationen (Register, Zustand, etc.) ber Threads.
Prozessorzuteilung im BS-Kern erfolgt an Threads.
Der Systemaufruf eines Threads blockiert nicht die anderen Threads des
Prozesses.
4.3 Prozessorverwaltung
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 Verfgung.
Prozessablauf besteht aus einer Sequenz von alternierenden CPU- und E/A-
Perioden.
Zeitliche Verschrnkung der Prozessbearbeitung bei einer CPU.
52
Zeit
Prozess A
BS-Kern
Prozess B
A hat CPU
Unterbrechung
BS-Kern
hat CPU
Zuweisung
CPU an B
Unterbrechung
A hat CPU
B hat CPU
BS-Kern
hat CPU
Zuweisung
CPU an A
4.3.1 Kriterien
Der Scheduler whlt aus der Menge der rechenwilligen Prozesse den nchsten
auszufhrenden Prozess aus. Es existieren unterschiedliche Verfahren die von der
jeweiligen Prozessorverwaltungsstrategie abhngen. Mgliche Leistungskriterien
fr ein Schedulingverfahren:
Fairness.
Efzienz, Prozessorauslastung.
Antwortzeit fr interaktive Benutzer (Dialogverarbeitung).
Wartezeit, insbesondere fr Batch-Jobs (Stapelverarbeitung).
Ausfhrungszeit, d.h. Zeitspanne von Auftragsbeginn bis Auftragsende.
Abschlusszeit, insbesondere fr Realzeitsysteme.
Durchsatz, Anzahl der Auftrge pro Zeiteinheit.
Kriterien der Betriebsarten
Die Ziele der Schedulingverfahren hngen von der Umgebung und den
Betriebsarten des Rechensystems ab.
53
Alle Systeme
Fairness - jeder Prozess bekommt Rechenzeit der CPU.
Balance - alle Teile des Systems sind ausgelastet.
Policy Enforcement - Scheduling Policy wird nach auen sichtbar
durchgefhrt.
Stapelbetrieb
Durchsatz - maximiere nach Auftrge pro Zeiteinheit.
Ausfhrungszeit - minimiere die Zeit von Start bis zur Beendigung.
CPU-Belegung - belege CPU konstant mit Auftrgen.
Dialogbetrieb - interaktive Systeme
Antwortzeit - antworte schnellstmglich auf Anfragen.
Proportionalitt - Erwartungshaltung der Nutzer bercksichtigen.
Echtzeitsysteme
Abschlusszeit - kein Verlust von Daten.
Vorhersagbarkeit - Qualittsverlust bei Multimedia vermeiden.
4.3.2 Scheduling-Strategien
Es werden zwischen zwei Klassen unterschieden: nicht-unterbrechende (nonpre-
emptive) und unterbrechende Strategien (preemptive).
nicht unterbrechend: Scheduling nur dann mglich, wenn der rechnende
Prozess blockiert wird oder wenn er terminiert, d.h. Prozess behlt 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 hherer Prioritt oder Prozess geht in
Wartezustand.
54
Zeitscheibenstrategie
Die Zeitscheibenstrategie (Round Robin) ist unterbrechend. Ziel ist die
gleichmige Verteilung der Rechenzeit auf rechenwillige Prozesse. Round Robin
ist eine weit verbreitete preemptive Schedulingvariante. Das Verfahren ordnet
jedem rechenwilligen Prozess ein deniertes Zeitquantum (Zeitscheibe) zu. In 4.3
BSD Unix betrgt 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 fr ein festgelegtes
Zeitquantum q gebunden und sptestens 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.
falls q zu gro: Round Robin wird zu einem reinen FCFS Scheduling
(First Come First Served), da die Wahrscheinlichkeit fr einen Aufruf eines
blockierenden Systemdienst steigt.
Typische Werte fr q: 10 bis 100 Millisekunden.
Fr q = 100 ms gilt bei 1 MIPS Maschine (Million Instructions/Second): ca.
100.000 Instruktionen/q.
Prioritten
Diese Strategie ist i.a. unterbrechend. Sie basiert darauf, an die Prozesse Priorit-
ten zu vergeben. Die Priorittenvergabe kann dabei statisch oder dynamisch sein.
Die Priorittenstrategie kann unterbrechend und nicht-unterbrechend sein. Im er-
sten Fall wird der Ablauf eines Prozesses unterbrochen, wenn ein anderer Prozess
mit hherer Prioritt rechenwillig wird. Im zweiten Fall behlt der Prozess die
CPU solange bis er entweder eine blockierende Systemfunktion aufruft oder die
CPU freiwillig abgibt.
Prioritten sind i.a. ein festgelegter Zahlenbereich, z.B. 0, ..., 7.
55
Statische Priorittenvergabe
jeder Prozess besitzt fr die Dauer seiner Existenz eine feste Prioritt.
Problem: Gefahr des Verhungerns von Prozessen mit niedriger Prioritt
Lsung: Erhhung der Prioritt von lange wartenden Prozessen, d.h.
dynamische Prioritten.
Dynamische Priorittenvergabe
die Prioritten der Prozesse knnen sich dynamisch verndern, d.h. sie werden
in gewissen Zeitabstnden neu berechnet.
Idee: lange Wartezeiten bercksichtigen (Erhhen die Prioritt).
Prozesse mit groem CPU-Verbrauch sinken in Prioritt.
E/A-intensive Prozesse steigen in Prioritt (damit E/A-Gerte und CPU
parallel genutzt werden).
Zeitscheibenstrategien und Priorittenvergabe knnen zu efzienten Verwal-
tungsstrategien kombiniert werden.
Windows XP Scheduling
Windows XP nutzt eine Prioritten-basierte, unterbrechende Strategie. Pro-
zess/Thread mit hchster Prioritt wird ausgefhrt, bis
er terminiert, oder
er seine Zeitscheibe ausgeschpft hat, oder
eine Blockierung (Systemaufruf, E/A) auftritt.
Es werden Prioritten von 0 - 31 unterschieden, die in verschiedene Klassen
eingeteilt werden
Echtzeit hoch ber
normal
normal unter
normal
idle
zeit kri-
tisch
31 15 15 15 15 15
hchste 26 15 12 10 8 6
ber
normal
25 14 11 9 7 5
normal 24 13 10 8 6 4
unter
normal
23 12 9 7 5 3
niedrigst 22 11 8 6 4 2
idle 16 1 1 1 1 1
56
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 ndet nur statt, wenn der Prozess eine blockierende
Systemfunktion aufruft oder der Prozess die CPU freiwillig abgibt.
Es kann eine hohe CPU Auslastung erreicht werden.
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) fhrt die Prozessorzuteilung in der Reihenfolge der
wachsenden Rechenphasen ("CPU-Burst") zu, d.h. Prozess mit krzester, nchster
Rechenphase erhlt Prozessor als nchster.
anwendbar, falls die Dauer der nchsten 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. Fr Stapelbetrieb
geeignet, da dort Information ber Rechenzeiten zur Verfgung stehen
(Benutzer geben bei Batch-Jobs Rechenzeit an).
Fr interaktive Prozesse wird die Lnge der nchsten Rechenphase ("Burst")
geschtzt:
S
n+1
= 1/n
n
i=1
T
i
T
i
= Ausfhrungszeit der i-ten Rechenphase.
57
S
i
= Schtzung fr die i-te Rechenphase.
S
1
= Schtzung fr die erste Rechenphase.
Anpassung der Berechnung
S
n+1
= (1/n) * T
n
+ (n-1)/n * S
n
4.3.3 Thread Scheduling
Die Prozessorzuteilung von Threads hngt von deren Art der Realisierung ab.
User-Threads
Realisierung der Threads im Benutzeradressraum Kern hat keine Kenntnis
bzgl. der Threads. BS-Scheduler whlt nur Prozess aus. Laufzeitsystem des
Prozesses whlt rechenwilligen Thread des Prozesses aus; es kann ein beliebiges
Scheduling-Verfahren (siehe Seite 54) fr Prozesse verwendet werden.
Java Virtual Machines verwenden unterbrechendes Prioritten-Scheduling fr
Threads;
10 ist die hchste und 1 die niedrigste Prioritt;
Kernel-Threads
Realisierung der Threads im Systemadressraum BS-Scheduler whlt den
nchsten auszufhrenden Thread aus.
a) Ist ausgewhlter Thread demselben Prozess zugeordnet wie der vorher
rechnende Thread geringer Kontextwechsel.
b) Ist ausgewhlter Thread nicht demselben Prozess zugeordnet wie der
vorher rechnende Thread aufwendiger Kontextwechsel.
4.3.4 Mehrschichtiges Scheduling
Der Scheduler whlt 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, verfgen
Systeme hug ber ein Mehr-Schichten Scheduling.
58
Short-Term-Scheduler (CPU Scheduler)
Auswahl eines geeigneten Prozesses aus der Ready-Queue; wird hug
aufgerufen; Verfahren siehe oben.
Long-Term-Scheduler
Auswahl rechenwilliger neuer Auftrge (meist Jobs aus dem Hintergrundbe-
trieb (batch)) und Einlagerung in den Arbeitsspeicher; Einfgen der Prozesse
in die Ready-Queue.
Graphische Darstellung
Long-term
Scheduler
neue
Auftrge
swap-in
CPU Scheduler
E/A-Warteschlange
Zeit-Interrupt-
Warteschlange
CPU
fertig
E/A-Befehl
Zeitscheibe
abgelaufen
sleep-Befehl
Systemaufruf
Ready Queue
ausgeswappte
Prozesse
swap-out
Ausfhrung im
BS-Kern
59
4.3.5 Echtzeit Scheduling
In Multimedia-Umgebungen treten die zu verarbeitenden kontinuierlichen Daten
(Empfangen, Dekodierenen und Anzeigen von Videoframes) in bestimmten, meist
periodischen Zeitabstnden auf. Die Operationen auf diese Daten wiederholen
sich dabei immer wieder und sollen bis zu einem gewissen Zeitpunkt abgeschlos-
sen sein. Prozesse in Multimedia-Anwendungen fhren oft zeitkritische Operatio-
nen aus. Bzgl. des Scheduling existieren zwei gegenstzliche Ziele:
a) ein unkritischer Prozess sollte nicht dauerhaft blockiert werden, weil
zeitkritische Prozesse eine Ressource gnzlich auslasten.
b) zeitkritische Prozesse drfen nicht durch Scheduling-Verfahren (Round-
Robin oder Prioritten) am zeitkritischen Fortschritt gehindert werden
Einhaltung von Zeitvorgaben.
Zuordnung von Kenngren zu zeitkritischen Prozessen
Bereitzeit (ready time): frhestmglicher Ausfhrungsbeginn einer
Aktivitt.
Frist (deadline): sptester Zeitpunkt fr die Beendigung einer Aktivitt.
Ausfhrungszeit: worst-case Abschtzung fr das zur vollstndigen
Ausfhrung einer Aktivitt notwendige Zeitintervall.
Earliest Deadline First (EDF)
Der Prozessor wird immer dem Prozess mit der am nchsten in der
Zukunft liegenden Frist zugeordnet. Es existieren die beiden Varianten: nicht-
unterbrechend und unterbrechend.
nicht-unterbrechend
Eine Prozessorzuordnung bleibt bis der Prozess eine blockierende System-
funktion aufruft oder freiwillig die CPU abgibt. Neue eintreffende Prozesse
mit krzeren Fristen werden erst beim nchsten Scheduling bercksichtigt.
unterbrechend
Diese Variante fhrt einen Kontextwechsel durch, wenn ein Prozess mit einer
krzeren Frist rechenwillig wird.
Rate-Monotonic Scheduling
Rate-Monotonic Scheduling (RMS) ist fr periodische Prozesse; RMS ordnet
Prioritten in Abhngigkeit von der Periode zu.
1) Prozesse mit der hchsten Frequenz (kleinste Periode) erhalten die
hchste Prioritt.
2) Prozesse mit der geringsten Frequenz (lngste Periode) erhalten die
niedrigste Prioritt.
60
Schlichter, TU Mnchen 4.4. UNTERBRECHUNGSKONZEPT
Auswahl der Prozesse anhand ihrer Prioritt.
hochfrequente Prozesse werden minimal verzgert.
Zerstckelung niederfrequenter Prozesse, da sie hug wegen hochfrequen-
ter Prozesse unterbrochen werden.
4.4 Unterbrechungskonzept
Die optimale Ausnutzung und Auslastung aller Gerte eines Rechensystems legt
Mehrprogrammbetrieb nahe. Zerlegung der Ausfhrungsphasen eines Programms
in viele Einzelteile;
- Aufbrechen der Ausfhrung eines Prozesses in mehrere Phasen: u.a.
Rechnen, E/A, Synchronisieren mit Partner.
- Die Ausfhrung der Programme wird in der Regel mehrfach unterbrochen.
4.4.1 Motivation
Ursachen fr Unterbrechungen
zugeteilte Prozessorzeit ist aufgebraucht;
bentigte Ressourcen stehen aktuell nicht zur Verfgung;
ein E/A-Gert meldet sich zurck;
ein Fehler tritt auf, z.B. Division durch 0;
Systemaufruf (wurde bereits als spezielle Unterbrechung eingefhrt);
Bei einer Unterbrechung wird ein gerade aktiver Prozess unterbrochen
und eine Unterbrechungsbehandlung durchgefhrt. Nach Beendigung der
Unterbrechungsbehandlung kann prinzipiell ein beliebiger rechenbereiter
Prozess fortgesetzt werden.
Es ist erforderlich, bei der Unterbrechung den CPU Status des gerade aktiven
Prozesses fr die sptere Fortsetzung zu speichern.
Forderung: Eine Unterbrechung muss so kontrolliert erfolgen, dass ein
denierter Prozessstatus festgehalten werden kann.
4.4.2 Unterbrechungsarten
Die normale Programmausfhrung eines Prozessors kann auch durch mehrere
Arten von Unterbrechungen verndert werden. Man unterscheidet zwischen
synchronen und asynchronen Unterbrechungen.
61
Unterbrechung
synchron asynchron
Trap
Alarme
(Exception)
Interrupt
Externe, asynchrone Unterbrechungen
Dies sind Unterbrechungen (Interrupts), die von auerhalb des zu unterbrechen-
den Prozesses ausgelst werden, z.B. E/A-Kanal-"Endmeldung".
Der Ablauf im Rechnerkern (RK) wird unterbrochen und eine Unterbrechungs-
anfangsbehandlung des Betriebsystemkerns wird aktiviert.
E/A-Kanal 2 CPU (RK) BS-Kern
Ende E/A
Auftrag
Unterbrechungs-
behandlung (UBH)
Interne, synchrone Unterbrechungen
Dies sind Unterbrechungen (Alarme, Exceptions), die durch den zu unterbrechen-
den Prozess selbst ausgelst werden, z.B. Division durch 0.
62
Der Ablauf im RK wird unterbrochen und eine Unterbrechungsanfangsbehand-
lung des Systemkerns wird aktiv.
CPU (RK) BS-Kern
Unterbrechungs-
behandlung (UBH)
Unterbrechung
arithmetischer Alarm
Beispiele von internen Unterbrechungen
Speicherschutzalarm: Prozess greift auf Speicherbereich zu, der nicht
vorhanden ist oder auf den er nicht zugreifen darf.
Befehlsalarm: dem Operationscode des Maschinenbefehls ist keine Opera-
tion zugeordnet.
Seitefehltalarm: Seite der virtuellen Adresse ist nicht im Arbeitsspeicher.
arithm. Alarm: arithm. Operation kann nicht ausgefhrt werden, z.B.
Division durch 0.
Systemaufruf: kontrollierter bergang in das Betriebssystem.
4.4.3 Behandlung externer Unterbrechungen
Synchrone und asynchrone Unterbrechungen haben hardwaremig die Speiche-
rung des aktuellen Prozessorzustandes zur Folge und lsen im Anschluss daran
einen indirekten Sprung ber eine im Speicher bendliche Sprungtabelle aus. Da-
bei 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 Folgemanahmen einleitet. Falls
mglich (Ausnahme ist z.B. ein arithmetischer Alarm) kann die unterbrochene
Programmausfhrung durch die Wiederherstellung des gespeicherten Prozessor-
zustandes zu einem beliebigen, spteren Zeitpunkt fortgesetzt werden.
63
Ablauf
Gerte-Controller meldet Unterbrechung ber spezielle Interrupt-Leitung an
CPU.
CPU prft im Befehlszyklus nach jeder Befehlsausfhrung, ob eine Unterbre-
chung gemeldet wurde.
Falls Unterbrechung vorliegt: sichern u.a. des aktuellen Befehlszhlers, des
Programmstatusworts und Sprung zu einer Unterbrechunganfangsbehandlung,
die an festgelegter Speicheradresse steht.
Routine untersucht Unterbrechungsursache, die vom Controller ber
Datenleitung gemeldet wird (Unterbrechungsnummer).
ber Unterbrechungsnummer erfolgt die Auswahl der bentigten Unter-
brechungsbehandlungsroutine; Nummer ist i.a. Index in eine Tabelle, dem
Unterbrechungsvektor.
Vektor enthlt Speicheradresse der Unterbrechungsbehandlungsroutine.
4.4.4 Konikte
Konikte bei Unterbrechungen treten z.B. in folgenden Situationen auf:
(1) whrend einer Unterbrechungsbehandlung treten weitere Unterbrechun-
gen auf;
(2) es treffen gleichzeitig mehrere Unterbrechungswnsche ein.
Beispiel
E/A-Kanal 1 und E/A-Kanal 2 erledigen beide Auftrge fr Prozess A.
64
Unterbrechungs-
behandlung (UBH)
E/A-Kanal 1 Prozess A BS-Kern E/A-Kanal 2
Ende E/A
Auftrag
externe
Unterbrechung
externe
Unterbrechung
Ende E/A
Auftrag
Konflikt
Mgliche Koniktlsungen
Andere Unterbrechungen nicht zulassen, d.h. Maskierung von Unterbrechun-
gen; anstehende Unterbrechung ignorieren oder vorlug zurckstellen; Pro-
blem: u.a. Rechtzeitigkeit der Unterbrechungsbehandlung.
Interne Unterbrechungen erfolgen stets sofort und geben der zugehrigen
Unterbrechungsbehandlung dieselbe Prioritt, wie sie der unterbrochene
Ablauf hatte.
Externe Unterbrechungen erhalten Prioritten z.B. (0,...,31) zugeordnet. Die
aufgerufene Unterbrechungsbehandlung erhlt die Prioritt (Ablaufprioritt)
der auslsenden Unterbrechung.
Eine weitere externe Unterbrechung wird whrend einer Unterbre-
chungsbehandlung zugelassen, wenn die Prioritt der neuen Unterbre-
chung hher als die Ablaufprioritt der gerade aktiven Unterbrechungs-
behandlung ist. Trifft dieser Fall nicht zu, so wird der Unterbrechungs-
wunsch zurckgestellt, bis ein Ablauf mit einer niedrigeren Ablaufprio-
ritt aktiv wird.
Integration der Unterbrechungsbehandlung in den Befehlszyklus der CPU
65
prfen ob interne Unterbrechung aufgetreten,
falls ja, Behandlung der Unterbrechung
sonst : prfen ob externe Unterbrechung mit hherer Prioritt. Wenn ja
whle eine mit hchster Prioritt.
Bei Unterbrechung: sichere alten Zustand, stelle neuen Zustand her und
fhre ersten Befehl der Unterbrechungsbehandlungsroutine aus.
66
Kapitel 5
Speicherverwaltung
Der Adressraum ist eine zentrale Abstraktion, die von der Systemsoftware eines
Rechensystems zur Verfgung gestellt werden muss. ber den Adressraum sind
alle fr die Ausfhrung eines Anwendungsprogramms notwendigen Operationen
und Datenstrukturen zugreifbar. Allgemein wird ein Adressraum durch eine
zusammenhngende Menge von Adressen und deren Inhalte deniert. Die
maximale Gre eines Adressraums kann aus dem Adressbusaufbau der
verwendeten Prozessorarchitektur abgeleitet werden. Modernde Rechensysteme
unterscheiden zwischen den Adressrumen der Programme und dem physischen
Adressraum (Arbeitsspeicher).
5.1 Fragestellungen
Dieser Abschnitt beschftigt sich mit den Adressrumen fr Programme und
deren Abbildung auf den physischen Arbeitsspeicher einer Rechenanlage:
Programmadressraum vs. Maschinenadressraum.
Direkte Adressierung, Basisadressierung.
Virtualisierung des Speichers; virtuelle Adressierung, insbesondere Seiten-
adressierung (nur sehr kurz).
5.2 Einfhrung
Die unmittelbare Nutzung des physischen Adressraums (Arbeitsspeichers) bei der
Anwendungsentwicklung ist nicht empfehlenswert. Probleme sind folgende:
67
Schlichter, TU Mnchen 5.2. EINFHRUNG
- Kenntnisse ber Struktur und Zusammensetzung des Arbeitsspeichers
notwendig.
- Kapazittsengpsse bei der Arbeitsspeichergre.
deshalb Programmerstellung unabhngig von realer Speichergre und -
eigenschaften.
5.2.1 Adressrume
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.
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 zulssigen Programmadressen ist der Programmadressraum.
Dieser ist prozessspezisch, d.h. Programmadressen haben nur Programm-
lokale Bedeutung z.B. als Sprungziele.
Speicherabbildung
Die CPU 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
5.2.2 Organisation von Adressrumen
Im Adressraum einer Anwendung mssen alle fr die Programmausfhrung not-
wendigen Daten zur Verfgung gestellt werden. Darunter fallen der Programmco-
68
de (Text), der Datenbereich (statische und dynamische Daten) und der Laufzeit-
keller. Fr jede dieser Informationsarten wird ein Bereich im Adressraum spezi-
ziert, deren Platzierung und Gre durch die Adressraumverwaltung festgelegt
wird.
Single-Threaded Adressraum
Programm
statische
Daten
dynamische Daten
(Halde)
Keller
niedrige
Adresse
hohe
Adresse
Multi-Threaded Adressraum
Programm
statische
Daten
dynamische Daten
(Halde)
niedrige
Adresse
hohe
Adresse
Keller n Keller 1
Fr jeden Kontrolluss (Thread) wird ein eigener Kellerbereich vorgesehen.
Der Abstand zwischen den einzelnen Kellern wird meist standardmig vom
System vorgegeben. Unabhngig von der Anzahl der Laufzeitkeller muss eine
berschneidung zwischen mehreren Kellern oder zwischen dem untersten
Keller und der Halde vermieden werden.
Beispiel - Adressrume
Moderne Betriebssysteme stellen wenigstens 32 Bit groe virtuelle Adressru-
me fr die Anwendungen zur Verfgung, die jeweils in mehrere Bereiche un-
terteilt sind. Programmcode, statische Daten, Halde und Laufzeitkeller der An-
wendung werden jeweils in dem Bereich des Adressraums abgelegt, der der
Anwendung zugnglich ist.
69
Windows 32 bit Adressierung
0 4 GByte 3 GByte 2 GByte 1 GByte
Linux 32 bit Adressierung
spezieller Adressbereich (Gre nicht proportional)
5.2.3 Fragmentierung
Unter dem Begriff Fragmentierung versteht man verschiedene Formen der
Zerstckelung des noch freien und nutzbaren Teils des Adressraums in kleine
Bereiche. Unterscheidung zwischen externer und interner Fragmentierung.
Externe Fragmentierung
Es wechseln sich benutzte und unbenutzte Speicherbereiche innerhalb des
Adressraums ab. Speicheranforderungen werden jeweils genau erfllt.
70
belegt belegt belegt
Anforderung
belegt belegt belegt belegt
freie Speicherbereiche
Interne Fragmentierung
Der Speicher ist in Bereiche fester Gre untergliedert und Speicheranforde-
rungen werden nur in Vielfachen dieser festen Grundgre befriedigt.
Anforderung
freier Speicherbereich
71
Schlichter, TU Mnchen 5.3. SPEICHERABBILDUNGEN
5.2.4 Forderungen an Adressraumrealisierung
Aus der Sicht der Anwendungsprogrammierung knnen fr einen Adressraum
eine Reihe wichtiger Forderungen an dessen Realisierung gestellt werden.
Hier geht es um den Programmieradressraum fr Prozesse, und nicht um den
Maschinenadressraum (Arbeitsspeicher).
Homogene und zusammenhngende Adressbereiche.
Gre des genutzten Adressraums unabhngig von der Kapazitt des
physischen Adressraums (Arbeitsspeichers).
Erkennen fehlerhafter Zugriffe.
Erkennen von berschneidungen zwischen Halde und Keller sowie zwischen
mehreren Laufzeitkellern.
Schutz funktionstchtiger Anwendungen gegenber fehlerhaften Anwendun-
gen. Hier geht es darum, dass die Adressbereiche der Anwendungen und auch
des Betriebssystems voneinander abgeschottet werden. Ist dieser Schutz nicht
gewhrleistet, knnen fehlerhafte Programme den Adressraum einer anderen
Anwendung verndern und damit Folgefehler in dieser auslsen nicht de-
terministische 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.
Speicherkonomie, minimale Fragmentierung.
5.3 Speicherabbildungen
Dieser Abschnitt behandelt einige Mechanismen zur Abbildung von Programm-
adressen 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,
Programmgre,
Speicherausnutzung.
72
Verschiebbarkeit
In einem Mehrprozesssystem sind i.d.R. mehrere Programme im Arbeitsspeicher.
Bei direkter Adressierung werden die Programme beim Laden xiert und mssen
dann bis zu ihrem Ende an derselben Stelle bleiben.
Problem
Externe Fragmentierung des Arbeitsspeichers. Sei der Arbeitsspeicher zunchst
lckenlos mit Programmen P1, P2, P3 gefllt.
P1 P2 P3
Nach Beendigung des Programms P2 entsteht eine Lcke.
Forderung
In Mehrprogramme/Mehrprozesssystemen sollten daher Programme verschieb-
bar sein.
Programmgre
Programme knnen wesentlich grer als der verfgbare 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).
Forderung
Die Programmgre sollte unabhngig von der realen Arbeitsspeichergre ist.
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 wnschenswert, von einem Programm nur den Ausschnitt
im Arbeitsspeicher zu halten, der momentan und in naher Zukunft bentigt wird.
Damit lassen sich mehr Programme im Arbeitsspeicher unterbringen und parallel
verarbeiten. Dies steigert den Datendurchsatz des Systems.
73
Forderung
Arbeitsspeicher beinhaltet nur die momentan bzw. in naher Zukunft notwen-
digen Ausschnitte des Programms. Nutzen der Lokalittseigenschaft von Pro-
grammen:
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 programmspezisch.
Die Programmadressen aller Programme beginnen jeweils mit Null. Durch die
Basisadressierung wird das Problem der Verschiebbarkeit gelst. Die anderen
Probleme bestehen jedoch weiterhin.
Der Arbeitsspeicher besteht aus zwei Klassen:
Belegtbereiche: Speicherbereiche sind Programmen zugeordnet. Verwaltung
in Belegtliste.
Freibereiche: Speicherbereiche, die momentan keinem Programm zugeord-
net sind, d.h. frei sind. Verwaltung Freibereichsliste.
Speicherverwaltungsstrategien
Aufgabe: Finden eines zusammenhngenden Arbeitsspeicherbereichs, der gro
genug ist, um das Programm zu speichern.
rst-t
Durchsuche die Liste der Freibereiche vom Anfang an und nimm den ersten
passenden Frei-Bereich: Spalte nicht bentigten Speicher ab und fge ihn als
freien Bereich in die Freibereichsliste ein.
next-t
Durchsuche die Liste der Freibereiche nach rst-t, jedoch beginne die Suche
dort, wo man bei der letzten Suche aufgehrt hat.
74
best-t
Durchsuche die Liste der Freibereiche vom Anfang an und nimm den
passenden Frei-Bereich, der die Speicheranforderungen des Programms am
besten erfllt: Spalte nicht bentigten Speicher ab und fge ihn als freien
Bereich in die Freibereichsliste ein.
worst-t
Durchsuche die Liste der Freibereiche vom Anfang an und nimm den Frei-
Bereich, der die Speicheranforderungen des Programms am schlechtesten
erfllt: Spalte nicht bentigten Speicher ab und fge ihn als freien Bereich in
die Freibereichsliste ein.
Buddy-Systeme
Speicheranforderungen werden in Gren von Zweierpotenzen vergeben,
d.h. eine Anforderung wird auf die nchste Zweierpotenz aufgerundet
Anforderung 280 Bytes Belegung von 512 Bytes = 2
9
am Anfang besteht der Arbeitsspeicher aus einem groen Stck.
Speicheranforderung von 2
k
: ist Speicherbereich dieser Gre vorhanden,
dann Unterteilung eines Speicherbereichs der Gre 2
k+1
in 2 Speicherbe-
reiche der Gre 2
k
Bytes.
Freigabe eines Speicherbereichs von 2
k
: falls auch entsprechendes
Partnerstck frei ist, dann Verschmelzung der beiden Speicherbereiche zu
einem Speicherstck der Gre 2
k+1
.
5.3.3 Seitenadressierung
Die virtuelle Adressierung wurde Ende der 50er Jahre eingefhrt. Ziel ist
Virtualisierung des Speichers,
Verstecken von realen Beschrnkungen, wie Speichergre,
Speicher als sehr groes Feld gleichartiger Speicherzellen zu betrachten.
Die Seitenadressierung ("paging") ist die Grundform der virtuellen Adressierung.
Ansatz
Der Programmadressraum, der sogenannte virtuelle Adressraum eines Prozesses
wird in aufeinanderfolgende Seiten (engl. page) gleicher Gre unterteilt. Man
spricht deshalb von virtuellen Adressen des Prozesses, anstatt von seinen
Programmadressen.
75
Der Maschinenadressraum, also der physische Adressraum des Arbeitsspei-
chers, wird in Kacheln (engl. frame) unterteilt. Seiten und Kacheln sind i.d.R.
gleich gro.
Eigenschaften der Seitenadressierung
Die Seiten eines Prozesses knnen im Arbeitsspeicher oder auf dem
Hintergrundspeicher (Platte) gespeichert sein.
Die Kacheln nehmen die Seiten der Prozesse auf.
Wenn whrend der Prozessausfhrung eine virtuelle Adresse des Prozess-
adressraums verwendet wird, so muss die Seite, in der sich die Adresse be-
ndet, in einer Kachel des Arbeitsspeichers geladen (eingelagert) sein.
Die Zuordnung, welche Seite in welcher Kachel gespeichert ist, und wo sich
die Seite auf dem Hintergrundspeicher bendet, erfolgt mittels der Seiten-
Kacheltabelle, die die Seitendeskriptoren enthlt.
Seite nicht im Arbeitsspeicher Seitenfehler Einlagerung der Seite bei
Bedarf ("Demand Paging").
Falls alle Kacheln belegt Auslagern einer Seite gem einer Seitenerset-
zungsstrategie.
Ziel dieser Strategien ist es, eine mglichst gnstige Seite auszuwhlen, und
diese auf den Hintergrundspeicher auszulagern. Mgliche Strategien:
FIFO (rst-in rst-out): Verdrngen der ltesten Seite, einfach zu
implementieren.
LRU (Least recently used): Verdrngen der am lngsten nicht genutzten
Seite; wird am hugsten realisiert, wobei LRU approximiert wird, da eine
exakte Realisierung zu aufwendig ist.
virtueller Speicher - Arbeitsspeicher
Der Zusammenhang zwischen dem virtuellen Speicher, hier den virtuellen
Adressrumen der Prozesse, und dem Arbeitsspeicher sowie Hintergrundspei-
chermedien wird nachfolgend kurz skizziert. Wir gehen hier vereinfachend da-
von aus, dass auch die Blcke als Einheiten des Hintergrundspeichers die Gre
einer Seite besitzen.
76
Seite 1 von
P1
Seite 2 von
P1
.....
virt. Adressraum von P1
Seite 1 von
P2
Seite 2 von
P2
.....
virt. Adressraum von P2
...
...
...
...
...
...
...
...
Deskriptor
Seiten-Kachel
Tabelle
Kachel 1
Kachel 2
Kachel 3
Kachel 4
Kachel 5
...
Arbeitsspeicher
mit Kacheln
Hintergrundspeicher
mit Blcken
Auslagern
Einlagern
Vorteile
Bei der Seitenadressierung werden durch eine exible Speicherabbildung alle
Probleme der direkten Adressierung (siehe Seite 72) gelst. D.h. die
Programme knnen:
verschoben werden,
grer als der Arbeitsspeicher sein,
auch ausschnittsweise im Arbeitsspeicher sein.
Zustzliche positive Eigenschaften
Es knnen gemeinsame Speicherbereiche zwischen Prozessen realisiert
werden.
Es ist ein differenzierter Zugriffsschutz innerhalb eines Prozesses mglich.
77
Kapitel 6
Prozesskommunikation
Disjunkte Prozesse, d.h. Prozesse, die vllig isoliert voneinander ablaufen, stellen
eher die Ausnahme dar. Hug nden Wechselwirkungen zwischen den Prozessen
statt Prozesse interagieren. Die Untersttzung der Prozessinteraktion stellt
einen unverzichtbaren Dienst dar.
6.1 Fragestellungen
Dieser Abschnitt beschftigt sich mit den Mechanismen von Rechensystemen
zum Austausch von Informationen zwischen Prozessen.
Kommunikationsarten.
nachrichtenbasierte Kommunikation, insbesondere Client-Server-Modell.
Netzwerkprogrammierung auf der Basis von Ports und Sockets.
6.2 Einfhrung
Prozessinteraktion kann Rechner-lokal und Rechner-bergreifend stattnden.
Prozesse knnen auf vielfltige Weise Informationen austauschen.
6.2.1 Kommunikationsarten
78
Prozesskommunikation
breitbandig schmalbandig
Ereignisse
Alarme
Signale
implizit
explizit
asnychron
explizit
snychron
1 : 1
n : 1
1 : m
n : m
1 : 1
1 : m
n : m
Strme
RPC
RMI
Die Bandbreite des Kommunikationskanals bestimmt die Datenrate, in der Daten
zwischen Prozessen ausgetauscht werden knnen.
Schmalbandige Kanle
Schmalbandige Kanle werden im Betriebssystem zum Melden von Ereignissen
oder fr die Synchronisation untersttzt. bertragung von wenigen Bits an
Information, z.B. Setzen von Flags
Dienste des Betriebssystems
Melden von Ereignissen,
Warten auf Ereignisse,
Ereignisverwaltung.
Beim Ablauf von Prozessen knnen Alarme entstehen (z.B. arithmetische
Alarme).
Die Alarme werden ber Namen identiziert, die im BS vereinbart sind. Das
BS stellt Dienste zur Zustellung von Alarmen zur Verfgung.
Implizite Kommunikation
Implizite Kommunikation ist eine breitbandige Kommunikationsform. Die
Kommunikation erfolgt ber einen gemeinsamen Speicher (Dateien, Register,
Datenstrukturen).
79
Die Kommunikation ndet ohne direkte Untersttzung und ohne Kenntnis des
BS statt.
Vorteil: einfach und schnell (kein Kopieren zwischen Adressrumen).
Nachteil:
a) gemeinsame Bereiche sind nicht immer vorhanden: z.B. in physisch
verteilten, vernetzten Systemen gibt es i.d.R. keinen gemeinsamen
Speicher.
b) gegebenenfalls aufwendiges busy waiting Mischform: Ereigniszustel-
lung, d.h. schmalbandige Kommunikation, die das Vorhandensein von Da-
ten signalisiert.
Implizite Kommunikationsformen
Verschiedene Formen der impliziten Kommunikation
1:1 ein Puffer pro Sender/Empfnger-Paar
n:1 n Sender senden Nachrichten an einen Empfnger, z.B.
Sender: Prozesse senden Druckauftrge
Empfnger: 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.
n:m n Erzeuger schreiben in Puffer und m Verbraucher lesen aus Puffer.
80
prozess-
spezifischer
oder
zentraler
Puffer
S1
E1
1:1 Kommunikation
Si i-ter Senderprozess
Ei i-ter Empfngerprozess
prozess-
spezifischer
oder
zentraler
Puffer
S1
E1
n:1 Kommunikation
Sn
Briefkasten
(mail box)
S1
n:m Kommunikation
Sn
E1 Em
Explizite Kommunikation
Diese Kommunikationsart wird realisiert durch den Austausch von Nachrichten
("message passing") nachrichtenbasierte Kommunikation. Die Nachrichten-
kommunikation ist immer dann die geeignete Kommunikationsform, wenn die
beteiligten Prozesse in disjunkten Adressrumen liegen, und damit keine Mg-
lichkeit haben, auf einen gemeinsamen Speicher zuzugreifen.
Betriebssystem enthlt einen Nachrichtendienst ND (das Kommunikationssy-
stem), der den Austausch der Nachrichten zwischen Prozessen realisiert. ND
untersttzt 2 Systemdienste:
send (E: process, m: message)
receive (S: process, m: message)
Mittels send wird eine Nachricht m fr den Empfnger E an den
Nachrichtendienst ND bergeben. Mit receive entnimmt ein Empfnger E die
Nachricht m, die vom Sender S gesandt wurde, von ND. Der Absender wird
gewhnlich in der Nachricht m codiert.
prinzipieller Ablauf
81
Schlichter, TU Mnchen 6.3. NACHRICHTENBASIERTE KOMMUNIKATION
Sende
prozess S
Nachrichten
dienst ND
Empfnger
prozess E
Nachricht m Nachricht m
send receive
Falls die Prozesse auf unterschiedlichen Rechnern sind, sind die Nachrichten-
dienste der beteiligten Betriebssysteme involviert. In diesem Fall ndet eine
Kommunikation zwischen den beiden Nachrichtendiensten statt.
Aufbau einer Nachricht
Eine Nachricht besteht aus 2 grundlegenden Komponenten:
Nachrichtenkopf: Verkehrsinformation, z.B. Sender- und
Empfngeridentikation
Nachrichteninhalt: Nutzlast (payload)
explizite Kommunikation ist besonders geeignet in verteilten, vernetzten
Systemen.
6.3 Nachrichtenbasierte Kommunikation
Bei nachrichtenbasierter Prozessinteraktion tauschen Prozesse gezielt Informatio-
nen durch Verschicken und Empfangen von Nachrichten aus; ein Kommunikati-
onssystem untersttzt an der Schnittstelle wenigstens die Funktionen send und
receive. Nachrichtenkommunikation ist die natrliche Form der Prozessinterak-
tion in Rechnernetzen. Prozesse, die auf verschiedenen Rechnerknoten platziert
sind, mssen ein physisches bertragungssystem benutzen, um miteinander in
Kontakt zu treten.
6.3.1 Elementare Kommunikationsmodelle
Klassikationsschema fr die Nachrichtenkommunikation anhand von 2 Dimen-
sionen:
generelles Muster der Nachrichtenkommunikation.
zeitliche Kopplung der beteiligten Prozesse.
Klassikationsschema
Elementare Kommunikationsmuster sind Meldung ("signal") und Auftrag
("request").
82
Meldung: Einweg Nachricht vom Sender zum Empfnger (unidirektional).
Auftrag: Zweiweg Nachricht zwischen Sender und Empfnger (bidirektio-
nal). Sie beginnt mit dem Versenden eines Auftrags an den Empfnger und
endet mit der bergabe einer Erfolgsbesttigung ber den durchgefhrten
Auftrag an den Sender.
Synchronitt deniert den Kopplungsgrad zwischen Prozessen bei der
Durchfhrung einer Nachrichtentransaktion:
asynchron: Entkopplung des Senders und Empfngers.
synchron: beide Prozesse werden zur Nachrichtenbertragung
synchronisiert.
Meldung
Asynchrone Meldung
Sender wird lediglich bis zur Ablieferung der Meldung an das Nachrichtensy-
stem (Kommunikationssystem) blockiert.
83
Sender S Nachrichtendienst ND Empfnger E
Zeit
send
receive
Meldung
Nachrichtendienst des Betriebssystems puffert Nachricht;
Sender S kann seine Ausfhrung fortsetzen, sobald Nachricht N in den
Nachrichtenpuffer des ND eingetragen ist.
S wartet nicht, bis E die Nachricht empfangen hat.
Empfnger E zeigt durch receive an, dass er am Empfang der Nachricht N
interessiert ist.
Empfnger wird blockiert, bis Sender Nachricht bereit stellt.
Synchrone Meldung
Sender und Empfnger von Meldungen sind zeitlich gekoppelt.
Zeit
send
receive
Meldung
Quittung
84
ber die Ablieferung der Nachricht wird der Sender durch eine Quittungsnach-
richt informiert, die zur Aufhebung der Blockade des Senders fhrt.
Rendezvous-Technik: Sender und Empfnger stellen vor Austausch der
eigentlichen Meldung die Sende- und Empfangsbereitschaft her.
Auftrag
Synchroner Auftrag
Bearbeitung der Nachricht durch Empfnger und Senden der Resultatnachricht
sind Teil der Nachrichtentransaktion.
Zeit
send
receive
Auftrag
Resultat
Auftrags
bearbeitung
reply
Synchrone Auftrge schrnken die Parallelarbeit zwischen Sender und Emp-
fnger noch strker 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.
Asynchroner Auftrag
Auftrag und Resultat werden als Paar unabhngiger Meldungen verschickt.
85
Zeit
send
receive
Auftrag
Resultat
Auftrags
bearbeitung
reply receive
result
Vorteile/Nachteile asynchrones Senden
Vorteile asynchrones Senden
ntzlich fr Realzeitanwendungen.
ermglicht parallele Abarbeitung durch Sender und Empfnger.
anwendbar zum Signalisieren von Ereignissen.
Nachteile asynchrones Senden
Verwaltung des Nachrichtenpuffers durch BS erforderlich.
Benachrichtigung des Senders S im Fehlerfall und Behandlung von Fehlern
ist problematisch.
Entwurf und Nachweis der Korrektheit des Systems ist schwierig.
6.3.2 Erzeuger-Verbraucher Problem
Auf der Basis der nachrichtenbasierten Kommunikation wird das Erzeuger-
Verbraucher Problem mit Hilfe von send und receive Operationen realisiert.
86
Erzeuger S:
while (true) {
produziere Dateneinheit;
send (E, Dateneinheit);
}
Verbraucher E:
while (true) {
receive (S, Dateneinheit);
verbrauche Dateneinheit;
}
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.
6.3.3 Modellierung durch ein Petrinetz
Petri-Netze dienen hug zur Modellierung von Kommunikationsablufen,
sogenannten Kommunikationsprotokollen. Sie ermglichen die Analyse der
Protokolle, z.B. Erkennung von Verklemmungen. Modellierung einer synchronen
Kommunikation:
Prozess 1
Sendebereit
send
message
receive
message
buffer full
Prozess 2 wait
for
ack.
message
received
buffer full
receive
ack.
send
ack.
ack. received ack. sent
87
Problem: unendliches Warten
Pragmatische Lsung mit Hilfe von Timeouts
Sender bzw. Empfnger warten nur eine festgelegte Zeit, Sender: falls kein
Acknowledgement (Quittung) eintrifft, z.B. erneutes Senden.
Probleme dabei? u.a. Duplikate mssen vom Empfnger erkannt werden;
gesendete Nachrichten kommen zu spt an, sind veraltet etc.
6.3.4 Ports
Bisher bestand zwischen Sender und Empfnger eine feste Beziehung, die ber
Prozessidentikatoren (z.B. Namen oder Nummer) hergestellt wurde. Nachteile
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 knnen bei Bedarf dynamisch eingerichtet und gelscht
werden. Dazu existieren folgende Funktionen:
portID = createPort();
deletePort(portID);
send(E.portID, message);
receive(portID, message);
ein Port ist mit dem Adressraum des zugehrigen Prozesses verbunden.
der Empfngerprozess kann sender-spezische Ports einrichten.
ein Rechner mit einer IP-Adresse untersttzt mehrere tausend Ports.
der Name des Ports ist fr einen Rechner eindeutig.
die Portnummern 1 - 1023 sind fest reserviert fr bestimmte Protokolle (bzw.
deren Applikationen).
bersicht: fest zugeordnete Ports
88
Protokoll Port Beschreibung
FTP 21 Kommandos fr Dateitransfer (get, put)
Telnet 23 interaktive Terminal-Sitzung mit entfern-
tem Rechner
SMTP 25 Senden von Email zwischen Rechnern
time 37 Time-Server liefert aktuelle Zeit
nger 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.
6.3.5 Kanle
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 Kommuni-
kationspartner eingerichtet werden Kanal ("socket").
Einrichtung eines Kanals zwischen Ports, d.h. Verknpfen zweier Ports.
bidirektionale bertragung ber Kanle.
Die Sende- bzw. Empfangsoperation bezieht sich auf die lokale PortID;
send(local portID, message);
receive(local portID, message);
TCP/IP untersttzt verbindungsorientierte Kommunikation.
6.3.6 Strme
Strme (engl. streams) sind eine Abstraktion von Kanlen. Sie verdecken die
tatschlichen Nachrichtengrenzen. Ein Sender schickt mittels send-Operationen
Nachrichten an den Empfnger. Die Nachrichten werden jedoch logisch zu
einem Bytestrom vereinigt, dem man auf Empfangsseite die Nachrichtengrenzen
nicht mehr entnehmen kann. Der Empfnger kann den Bytestrom in Portionen
verarbeiten, ohne sich an den ursprnglichen Nachrichtengrenzen zu orientieren.
89
Schlichter, TU Mnchen 6.4. CLIENT-SERVER-MODELL
Sender
Empfnger
Strom
1 Byte
send (120 Bytes)
send (74 Bytes)
send (233 Bytes)
receive (50 Bytes)
receive (377 Bytes)
BS-Dienste: Verbindungsauf- und -abbau, schreiben in Strom, lesen aus Strom.
Dienste fr Dateizugriffe oder Zugriffe auf Gerte: spezielle Ausprgung der
stromorientierten Kommunikation.
I/O in Java basiert auf Strme.
Klasse java.io.OutputStream zum Schreiben von Daten
Klasse java.io.InputStream zum Lesen von Daten
Spezialisierungen z.B. durch FileOutputStream, BufferedOutputStream oder
FileInputStream.
6.4 Client-Server-Modell
Client-Server Modell basiert i.a. auf der Kommunikationsklasse der synchronen
Auftrge. Server stellen Dienste zur Verfgung, die von vorher unbekannten
Clients in Anspruch genommen werden knnen.
Client-Server Architektur
90
Schlichter, TU Mnchen 6.4. CLIENT-SERVER-MODELL
Client C Server S
Zeit
Auftrag
Resultat
Ausfhrung
blockiert
Denitionen
Denition: Client
Ein Client ist eine Anwendung, die auf einer Clientmaschine luft und i.a.
einen Auftrag initiiert, und die den geforderten Dienst von einem Server
erhlt.
Clients sind meist a-priori nicht bekannt. Clients sind oft Benutzerprozesse,
die dynamisch erzeugt und gelscht werden.
Denition: Server
Ein Server ist ein Subsystem, das auf einer Servermaschine luft und einen
bestimmten Dienst fr a-priori unbekannte Clients zur Verfgung stellt.
Server sind dedizierte Prozesse, die kontinuierlich folgende Schleife
abarbeiten.
while (true) {
receive (empfangsport, auftrag);
fhre Auftrag aus und erzeuge Antwortnachricht;
bestimme sendeport fr Antwortnachricht;
send (sendeport, resultat);
}
Client und Server kommunizieren ber Nachrichten, wobei beide Systeme
auf unterschiedlichen Rechnern ablaufen knnen und ber ein Netz
miteinander verbunden sind.
Beispiele fr Dienste (Services), die mittels Server realisiert werden:
Dateidienst, Zeitdienst, Namensdienst.
91
Schlichter, TU Mnchen 6.5. NETZWERKPROGRAMMIERUNG
Multi-Tier
ein System kann sowohl Client als auch Server sein.
Client
Server
Client
Server
Beispiel
HTTP cgi
Web
Browser
(Applets)
Web
Server
Anwendungs
Server
Daten
bank
SQL
6.5 Netzwerkprogrammierung
Bedingt durch rasche Verbreitung des Internet hat auch das Interesse an Netz-
Anwendungen sehr zugenommen. Netz-Anwendungen sind verteilte Anwendun-
gen, die jeweils aus mehreren Teilkomponenten bestehen und die im Netz verteilt
auf verschiedenen Rechensystemen ausgefhrt 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 Funktionalitt in eine Menge von kooperierenden Teil-
komponenten A
1
, .., A
n
, n IN, n > 1 zerlegt ist;
92
Jede Teilkomponente umfasst Daten (interner Zustand) und Operationen, die
auf den internen Zustand angewendet werden.
Teilkomponenten A
i
sind autonome Prozesse, die auf verschiedenen Rechen-
systemen ausgefhrt werden knnen. Mehrere Teilkomponenten knnen dem-
selben Rechensystem zugeordnet werden.
Teilkomponenten A
i
tauschen ber das Netz untereinander Informationen aus.
Die Teilkomponenten knnen z.B. auf der Basis des Client-Server Modells
realisiert werden.
6.5.1 Einfhrung
In Berkeley Unix wurde das Konzept von Sockets eingefhrt, um die Netzwerk-
programmierung zu erleichtern. Sie erlauben jede Netzverbindung als einen Strom
von Bytes zu betrachten, die gelesen bzw. geschrieben werden knnen. Ein Socket
deniert einen einfachen, bidirektionalen Kommunikationskanal zwischen 2 Re-
chensystemen, mit Hilfe dessen 2 Prozesse ber ein Netz miteinander kommuni-
zieren knnen.
Client Server
Output Strom
Input Strom
Socket Verbindung
Socket Grundlagen
Sockets abstrahieren von den technischen Details eines Netzes, z.B. bertra-
gungsmedium, Paketgre, Paketwiederholung bei Fehlern, Netzadressen. An-
fnglich standen Sockets nur in Unix Umgebungen zur Verfgung. In der Zwi-
schenzeit werden sie auch von Windows, dem MacOs und von Java untersttzt.
Ein Socket kombiniert 2 Strme, einen Input- und einen Output-Strom.
93
Ein Socket untersttzt die folgenden Basisoperationen:
richte Verbindung zu entferntem Rechner ein ("connect").
sende Daten.
empfange Daten.
schliee Verbindung.
assoziiere Socket mit einem Port.
warte auf eintreffende Daten ("listen").
akzeptiere Verbindungswnsche von entfernten Rechnern (bzgl. assoziier-
tem Port).
6.5.2 Server Protokoll
Ein Server kommuniziert mit einer Menge von Clients, die a priori nicht bekannt
sind. Ein Server bentigt eine Komponente (z.B. ein Verteiler-Thread), die auf
eintreffende Verbindungswnsche reagiert.
Informeller Ablauf aus Serversicht
1. Erzeugen eines SocketServer und Binden an einen bestimmten Port. Ein Port
entspricht einer FIFO Warteschlange. Sie sammelt die Verbindungswnsche
der Clients. Die maximale Lnge ist abhngig vom Betriebssystem, z.B. 50.
Falls die Warteschlange voll ist, werden keine weiteren Verbindungswnsche
akzeptiert.
2. Warten auf Verbindungswnsche von Clients. Falls der Client bzgl. einer
Socketverbindung autorisiert ist, akzeptiert der Server den Verbindungs-
wunsch. Der Server wird blockiert, bis die accept-Methode des Servers die
Verbindung zwischen Client und Server eingerichtet hat. Die beiden Strme
der Socketverbindung werden eingerichtet.
3. Austausch von Daten zwischen Client und Server entsprechend einem
wohldenierten Protokoll (z.B. HTTP).
4. Schlieen einer Verbindung (durch Server, durch Client oder durch beide);
weiter bei Schritt 2.
Programmstck
94
Socket socket; //reference to socket
ServerSocket port; //the port the server listens to
try {
port = new ServerSocket(10001, ...);
socket = port.accept(); //wait for client call
// communicate with client
socket.close()
}
catch (IOException e) {e.printStackTrace();}
Fr das Abhren des Ports kann ein eigener Verteiler-Thread speziziert
werden; die Bearbeitung bernehmen sogenannte Worker-Threads.
6.5.3 Client Protokoll
Der Client initiiert eine Socket-Verbindung durch Senden eines Verbindungswun-
sches an den Port des Servers.
Informeller Ablauf aus Clientsicht
1. Erzeugen einer Socket Verbindung.
2. Austausch von Daten zwischen Client und Server ber die Duplex-Verbindung
entsprechend einem wohldenierten Protokoll (z.B. HTTP).
3. Schlieen einer Verbindung (durch Server, durch Client oder durch beide).
Programmstck
Socket connection; //reference to socket
try {
connection = new Socket("www11.in.tum.de", 10001);
........ // communicate with client
connection.close()
}
catch (IOException e) {e.printStackTrace();}
6.5.4 Bidirektionale Stromverbindung
Sockets bestehen aus 2 Strmen fr die Duplexverbindung zwischen Client
und Server. Diese beiden Strme werden automatisch beim Einrichten einer
95
Socket-Verbindung erzeugt. Durch die Verwendung von Strmen kann dieselbe
Programmiermethode verwendet wie bei I/O, Dateizugriff, etc.
Schreiben auf Socket
void writeToSocket(Socket sock, String str) throws
IOException {
oStream = sock.getOutputStream();
for (int k = 0; k < str.length(); k++)
oStream.write(str.charAt(k));
}
Lesen von Socket
String readFromSocket(Socket sock) throws IOException {
iStream = sock.getInputStream();
String str = "";
char c;
while ( (c = (char) iStream.read()) != \n)
str = str + c;
return str;
}
6.5.5 Java Socket Class
Java untersttzt die beiden grundlegenden Klassen:
java.net.Socket zur Realisierung der Client-Seite einer Socket.
java.net.ServerSocket zur Realisierung der Server-Seite einer Socket.
Client-Seite einer Socket
Constructor
public Socket(String host, int port)
throws UnknownHostException, IOException
Der Parameter host ist ein Rechnername, z.B. www11.in.tum.de. Falls der
Domain Name Server den Parameter host nicht ausen kann, wird die
Exception UnknownHostException ausgelst. Falls die Socket aus einem
anderen Grund nicht geffnet werden kann, wird IOException ausgelst, z.B.
96
der entfernte Host akzeptiert keine Verbindungen. Es gibt noch eine Reihe
anderer Konstruktoren, z.B.
public Socket(InetAddress host, int port) throws IOException
Das Objekt der Klasse InetAddress umfasst den Rechnernamen und seine IP-
Adresse, d.h. eine Ausung durch den Domain Name Server ist nicht mehr
notwendig.
Information ber eine Socket
public InetAddress getInetAddress();
liefert als Ergebnis den Namen und IP-Adresse des entfernten Rechners, zu
dem die Socket-Verbindung existiert.
public int getPort();
liefert als Ergebnis die Nummer des Ports, mit dem die Socket-Verbindung
am entfernten Rechner assoziiert ist.
public int getLocalPort();
liefert als Ergebnis die Nummer des Ports, mit dem die Socket-Verbindung
am lokalen Rechner assoziiert ist.
Ein-/Ausgabe
public InputStream getInputStream() throws IOException;
liefert den InputStream, von dem Daten gelesen werden knnen. Er
untersttzt die Methode read zum Lesen der Daten. InputStream ist ein
Basis-Strom, der mit Hilfe von SubClassing spezialisiert werden kann.
public OutputStream getOutputStream() throws IOException;
liefert den OutputStream, in dem Daten geschrieben werden knnen. Er
untersttzt die Methode write zum Schreiben der Daten. OutputStream ist
ein Basis-Strom, der mit Hilfe von SubClassing spezialisiert werden kann.
Server-Seite einer Socket
Constructor
public ServerSocket(int port)
throws IOException, BindException
erzeugt eine Socket auf Server-Seite und assoziiert sie mit dem Port.
97
Einrichten/Schlieen einer Verbindung
public Socket accept() throws IOException
diese Methode blockiert und wartet auf Verbindungswnsche von Clients.
public void close() throws IOException
Ein-/Ausgabe
public InputStream getInputStream() throws IOException;
liefert den InputStream, von dem Daten gelesen werden knnen.
public OutputStream getOutputStream() throws IOException;
liefert den OutputStream, in dem Daten geschrieben werden knnen.
98
Kapitel 7
Zusammenfassung
Dieser Vorlesungsteil beschftigte sich mit Aspekten des Betriebssystems und
der systemnahen Programmierung. Insbesondere wurden folgende Aspekte
behandelt:
ein allgemeiner berblick ber Betriebssysteme, Betriebssystemarchitekturen.
Synchronisation von Prozessen beim Zugriff auf gemeinsame Ressourcen.
Verwaltung von Prozessen und deren Zuteilung an die CPU, um sie
auszufhren.
einfache Verwaltung des Arbeitsspeichers aus der Sicht des Betriebssystems.
Prozesskommunikation in lokalen und verteilten Systemen.
99

Mse Course Student

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Mse Course Student

Hochgeladen von

Copyright:

Verfügbare Formate

Eingebettete vernetzte Systeme (IN8014) -

Teil I: Betriebssysteme und Systemsoftware

Das könnte Ihnen auch gefallen