J Prozesse und Nebenläufigkeit - Verteilte Systeme

1 Einordnung
J Prozesse und Nebenläufigkeit
Ebene 6
Problemorientierte Sprache
Ebene 5
Assemblersprache
Ebene 4
Betriebssystem
Ebene 3
ISA (Instruction Set Architecture)
Ebene 2
Mikroarchitektur
Ebene 1
Digitale Logik
Ebene 0
Physik
J.1
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
J.2
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
1 Einordnung (2)
2 Motivation
■ Betroffene physikalische Betriebsmittel
■ Mehrprogrammbetrieb (Multiprogramming)
◆ bessere Auslastung der CPU, falls Programme Wartezeiten haben
Prozessor (CPU, Central Processing Unit)
• z.B. bei Ein-, Ausgabe (E/A)
100
Ein-, Ausgabegeräte/
Periphere Geräte
(I/O Devices)
Hauptspeicher
(Memory)
externe
Schnittstellen
(Interfaces)
80
CPU-Auslastung in %
20%
50%
60
80% E/A-Wartezeit
40
Hintergrundspeicher
(Secondary Storage)
20
Anzahl der gleichzeitig bearbeiteten Programme
0 1
2 3
4
nach Tanenbaum, 1995
5
6
7
8
9
10
◆ einfachere Struktur bei großen Anwendungen
J.3
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
J.4
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
2 Motivation (2)
3 Prozesse
■ Mehrbenutzerbetrieb (Multiuser)
■ Terminologie
◆ mehrere Benutzer führen auch mehrere Programme aus
◆ Programm: Folge von Anweisungen und dazugehörigen Daten
◆ ähnlich Mehrprogrammbetrieb
• hinterlegt beispielsweise als Datei auf dem Hintergrundspeicher
◆ Prozess: Programm, das sich in Ausführung befindet,
und seine aktuellen Daten
• jedoch: Unterscheidung von Benutzern und evtl. Zugriffsberechtigungen
• Beachte: ein Programm kann sich mehrfach in Ausführung befinden
■ Prozess stellt Ausführungsumgebung bereit
◆ Adressraum (Schutzumgebung für den Speicher eines Prozesses)
◆ Kontext für Betriebsmittelanforderungen (Speicher, Dateien, etc.)
◆ Prozess als virtueller Prozessor
• Anweisungen des Prozesses werden abgearbeitet
J.5
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
J.6
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
3.1 Repräsentation eines Prozesses
3.2 Prozesswechsel
■ Datenstruktur pro Prozess:
Prozesskontrollblock (Process Control Block; PCB)
■ Konzeptionelles Modell
◆ enthält alle nötigen Daten für einen Prozess
A
B
◆ beispielsweise in UNIX/Linux:
C
D
• Prozessnummer (PID)
vier Prozesse mit eigenständigen Befehlszählern
• verbrauchte Rechenzeit
■ Umschaltung zwischen den Prozessen
• Erzeugungszeitpunkt
• Kontext (Register etc.)
◆ Prozessor kann immer nur einen Prozess abarbeiten
• Speicherabbildung (Information zur Schutzumgebung)
◆ Umschaltung zwischen den Prozessen
• Eigentümer (UID, GID)
• Prozesse erleben Fortschritt ihrer Programmzähler und ihrer ausgeführten
Anweisungen.
• Wurzelverzeichnis, aktuelles Verzeichnis
◆ transparentes Umschalten
• offene Dateien
• Ein Prozess bemerkt die anderen Prozesse zunächst nicht.
• ...
J.7
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
J.8
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
3.2 Prozesswechsel (2)
3.2 Prozesswechsel (3)
■ Prozessumschaltung (Context Switch)
■ Schematische Darstellung von Umschaltungen (Beispiel)
◆ Sichern der Register des laufenden Prozesses inkl. Programmzähler (Kontext),
◆ Auswahl des neuen Prozesses,
blockiert/bereit
Prozess A
blockiert/bereit
Befehlszähler
◆ Ablaufumgebung des neuen Prozesses herstellen
(z.B. Speicherabbildung, etc.),
◆ gesicherte Register laden und
◆ Prozessor aufsetzen (Programmzähler laden).
Prozessumschalter
blockiert/bereit
Prozess B
Zeit
J.9
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
3.2 Prozesswechsel (4)
J.10
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
3.2 Prozesswechsel (5)
■ Prozesswechsel unter Kontrolle der Prozesse
■ Prozesswechsel unter Kontrolle des Betriebssystems
◆ Prozess bestimmt Umschaltungszeitpunkt
◆ Mögliche Eingriffspunkte:
• Konzept der Ko-Routine
• Systemaufrufe
◆ kein transparentes Umschalten
• Unterbrechungen
◆ keine Fairness
◆ Wechsel nach/in Systemaufrufen
• Warten auf Ereignisse
(z.B. Zeitpunkt, Nachricht, Lesen eines Plattenblock)
✱ Wunsch nach fairer Zuteilung des Betriebsmittels „Prozessor“
• Terminieren des Prozesses
◆ Wechsel nach Unterbrechungen
• Ablauf einer Zeitscheibe
• bevorzugter Prozess wurde laufbereit
■ Auswahlstrategie zur Wahl des nächsten Prozesses
◆ Scheduler-Komponente
J.11
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
J.12
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
3.3 Prozesszustände
3.3 Prozesszustände (2)
■ Ein Prozess befindet sich in einem der folgenden Zustände:
■ Zustandsdiagramm
◆ Erzeugt (New)
Prozess wurde erzeugt, besitzt aber noch nicht alle nötigen Betriebsmittel
erzeugt
◆ Bereit (Ready)
Prozess besitzt alle nötigen Betriebsmittel und ist bereit zum Laufen
Scheduler
teilt Prozessor zu
zugelassen
terminiert
bereit
◆ Laufend (Running)
Prozess wird vom realen Prozessor ausgeführt
◆ Blockiert (Blocked/Waiting)
Prozess wartet auf ein Ereignis (z.B. Fertigstellung einer Ein- oder
Ausgabeoperation, Zuteilung eines Betriebsmittels, Empfang einer Nachricht);
zum Warten wird er blockiert
◆ Beendet (Terminated)
Prozess ist beendet; einige Betriebsmittel sind jedoch noch nicht freigegeben
oder Prozess muss aus anderen Gründen im System verbleiben
Grund der Blockade
ist weggefallen
beendet
laufend
Unterbrechung od.
Systemaufruf
impliziter oder
expliziter Warteaufruf
blockiert
wartend
nach Silberschatz, 1994
◆ Scheduler ist der Teil des Betriebssystems, der die Zuteilung des realen
Prozessors vornimmt.
J.13
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
4 Auswahlstrategien
4.1 Kriterien
■ Strategien zur Auswahl des nächsten Prozesses
(Scheduling Strategies)
■ CPU Auslastung
◆ möglichst 100% ausgelastete CPU
◆ Mögliche Stellen zum Treffen von Scheduling-Entscheidungen
1.
Prozess wechselt vom Zustand „laufend“ zum Zustand „blockiert“
(z.B. Ein-, Ausgabeoperation)
2.
Prozess wechselt von „laufend“ nach „bereit“
(z.B. bei einer Unterbrechung des Prozessors)
3.
Prozess wechselt von „blockiert“ nach „bereit“
4.
Prozess terminiert
■ Durchsatz
◆ möglichst hohe Anzahl bearbeiteter Prozesse pro Zeiteinheit
■ Verweilzeit
◆ möglichst geringe Gesamtzeit des Prozesses in der Rechenanlage
■ Wartezeit
◆ möglichst kurze Gesamtzeit, in der der Prozess im Zustand „bereit“ ist
◆ bei 1. und 4. muss Neuauswahl erfolgen
◆ bei 2. und 3. kann Neuauswahl erfolgen
ja
verdrängend
J.14
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
nein
■ Antwortzeit
verdrängend = präemptiv
◆ möglichst kurze Reaktionszeit des Prozesses im interaktiven Betrieb
nicht verdrängend
J.15
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
J.16
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
4.2 First Come, First Served
4.2 First Come, First Served (2)
■ Der erste Prozess wird zuerst bearbeitet (FCFS)
■ Beispiel zur Betrachtung der Wartezeiten
◆ „Wer zuerst kommt ...“
24
3
3
Prozess 1:
Prozess 2:
Prozess 3:
◆ Nicht-verdrängend
■ Warteschlange zum Zustand „bereit“
Zeiteinheiten
◆ Reihenfolge: P1, P2, P3
◆ Prozesse werden hinten eingereiht
◆ Prozesse werden vorne entnommen
P1
▲ Bewertung
P2
bereit
P3
bereit
mittlere Wartezeit: (0+24+27)/3 = 17
◆ fair (?)
laufend
bereit
blockiert
◆ Wartezeiten nicht minimal
◆ nicht für Time-Sharing-Betrieb geeignet
J.17
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
4.2 First Come, First Served (3)
4.2 First Come, First Served (4)
■ Beispiel zur Betrachtung der Wartezeiten
Prozess 1:
Prozess 2:
Prozess 3:
24
3
3
J.18
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
■ Behandlung deblockierte Prozesse
◆ Einreihung an das Ende der Warteschlange
◆ Beispiel:
Zeiteinheiten
• Laufzeitanforderung
◆ Reihenfolge: P2, P3, P1
blockiert
P1
blockiert
P2
P1 bereit
• FCFS-Ablauf auf einem Prozessor (initial: P1 vor P2)
P2
P3
blockiert
P1
P2
mittlere Wartezeit: (6+0+3)/3 = 3
laufend
bereit
blockiert
J.19
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
Warte- P1
schlange: P2
ber.
blockiert
ber.
P2
P1
P1
P2
laufend
bereit
blockiert
J.20
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
4.3 Shortest Job First
4.3 Shortest Job First (2)
■ Kürzester Job wird ausgewählt (SJF)
■ Beispiel: SJF
◆ Länge bezieht sich auf die nächste Rechenphase bis zur nächsten
Warteoperation (z.B. Ein-, Ausgabe)
◆ Laufzeitanforderung
blockiert
P1
■ „bereit“-Warteschlange wird nach Länge der nächsten Rechenphase sortiert
◆ Vorhersage der Länge durch Protokollieren der Länge bisheriger Rechenphasen
(Mittelwert, exponentielle Glättung)
◆ ... Protokollierung der Länge der vorherigen Rechenphase
P2
P3
◆ SJF-Ablauf auf einem Prozessor
■ SJF optimiert die mittlere Wartezeit
blockiert
P1
◆ Da Länge der Rechenphase in der Regel nicht genau vorhersagbar, nicht ganz
optimal.
■ Varianten: verdrängend (PSJF) und nicht-verdrängend
P2
bereit
P3
ber.
Warte- P1
schlange: P3
P3
P2
P1
P2
P1 P2
P2
P2
laufend
bereit
blockiert
J.21
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
4.3 Shortest Job First (3)
4.4 Prioritäten
■ Beispiel: PSJF
■ Prozess mit höchster Priorität wird ausgewählt
(HPF, Highest Priority First)
◆ Laufzeitanforderung
◆ dynamisch — statisch
(z.B. SJF: dynamische Vergabe von Prioritäten gemäß Länge der nächsten
Rechenphase)
(z.B. statische Prioritäten in Echtzeitsystemen; Vorhersagbarkeit von
Reaktionszeiten)
blockiert
P1
P2
P3
◆ verdrängend — nicht-verdrängend
◆ PSJF-Ablauf auf einem Prozessor
P2
P3
Warte- P1
schlange: P3
P2
▲ Probleme
blockiert
P1
J.22
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
bereit
◆ Prioritätenumkehr (Priority Inversion)
ber.
◆ Aushungerung
P3
P2
P1 P3
P3 P2
P2
P2
laufend
bereit
blockiert
J.23
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
J.24
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
4.4 Prioritäten (2)
4.4 Prioritäten (3)
■ Prioritätenumkehr
✱ Lösung
◆ hochpriorer Prozess wartet auf ein Betriebsmittel, das ein niedrigpriorer Prozess
besitzt; dieser wiederum wird durch einen mittelprioren Prozess verdrängt und
kann daher das Betriebsmittel gar nicht freigeben
◆ dynamische Anhebung der Priorität für kritische Prozesse
(im Beispiel: P3 wird von Zeitpunkt 2 bis Zeitpunkt 3 auf hohe Priorität
angehoben)
2
hoch
P2
mittel
P3
niedrig
1
◆ Ein Prozess kommt nie zum Zuge, da immer andere mit höherer Priorität
vorhanden sind.
✱ Lösung
3
Inversionsphase
laufend
bereit
blockiert
■ Aushungerung
Priorität
P1
Zeit
1.
P3 fordert Betriebsmittel an
2.
P1 wartet auf das gleiche Betriebsmittel
3.
P3 gibt Betriebsmittel frei
◆ dynamische Anhebung der Priorität für lange wartende Prozesse
(Alterung, Aging)
J.25
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
4.5 Round-Robin Scheduling
J.26
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
4.5 Round-Robin Scheduling (2)
■ Zuteilung und Auswahl erfolgt reihum
■ Beispiel zur Betrachtung der Wartezeiten
◆ ähnlich FCFS aber mit Verdrängung
Prozess 1:
Prozess 2:
Prozess 3:
◆ Zeitquant (Time Quantum) oder Zeitscheibe (Time Slice) wird zugeteilt
◆ geeignet für Time-Sharing-Betrieb
24
3
3
Zeiteinheiten
◆ Zeitquant ist 4 Zeiteinheiten
◆ Reihenfolge in der „bereit“-Warteschlange: P1, P2, P3
P1
Unterbrechungsleitung
P2
Timer
P3
◆ Wartezeit ist jedoch eventuell relativ lang
0
4
7
10
14
18
22
26
30
mittlere Wartezeit: (6+4+7)/3 = 5,7
J.27
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
J.28
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
4.5 Round-Robin Scheduling (3)
4.5 Round-Robin Scheduling (4)
◆ Zeitscheibengröße 1:
■ Effizienz hängt von der Größe der Zeitscheibe ab
◆ kurze Zeitscheiben: Zeit zum Kontextwechsel wird dominant
0
◆ lange Zeitscheiben: Round-Robin nähert sich FCFS an
■ Verweilzeit und Wartezeit hängt ebenfalls von der Zeitscheibengröße ab
◆ Beispiel: 3 Prozesse mit je 10 Zeiteinheiten Rechenbedarf
5
10
15
20
25
30
Verweil-/Warte28/18
zeit
29/19
30/20
P1
P2
P3
durchschnittliche Verweilzeit: 29 Zeiteinheiten = (28+29+30)/3
durchschnittliche Wartezeit: 19 Zeiteinheiten = (18+19+20)/3
• Zeitscheibengröße 1
◆ Zeitscheibengröße 10:
• Zeitscheibengröße 10
0
5
P1
P2
P3
10
15
10/0
20
25
30
Verweil-/Wartezeit
20/10
30/20
durchschnittliche Verweilzeit: 20 Zeiteinheiten = (10+20+30)/3
durchschnittliche Wartezeit: 10 Zeiteinheiten = (0+10+20)/3
J.29
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
4.6 Multilevel-Queue Scheduling
J.30
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
4.6 Multilevel-Queue-Scheduling (2)
■ Verschiedene Schedulingklassen
■ Beispiel: Solaris/SunOS
◆ z.B. Hintergrundprozesse (Batch) und
Vordergrundprozesse (interaktive Prozesse)
◆ Schedulingklassen
• Systemprozesse
◆ jede Klasse besitzt ihre eigenen Warteschlangen (Queues) und verwaltet diese
nach einer eigenen Schedulingstrategie
◆ zwischen den Klassen gibt es ebenfalls eine Schedulingstrategie
z.B. feste Prioritäten (Vordergrundprozesse immer vor Hintergrundprozessen)
◆ Prozessauswahl
• Real-Time Prozesse
• Time-Sharing Prozesse
• interaktive Prozesse
◆ Scheduling zwischen den Klassen mit fester Priorität
(z.B. Real-Time-Prozesse vor Time-Sharing-Prozessen)
1. Schedulingklasse auswählen
2. in ausgewählter Klasse Prozess auswählen
J.31
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
J.32
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
4.6 Multilevel-Queue-Scheduling (3)
4.7 Multilevel-Feedback-Queue Scheduling
■ Beispiel: Solaris/SunOS (fortges.)
■ Ähnlich Multilevel-Queue-Scheduling
◆ Auswahlstrategien der Schedulingklasen:
◆ Schedulingklassen
• Systemprozesse: FCFS
• meist viele Klassen, doch innerhalb der Klasse gleiche Strategie
(z.B. Round-Robin)
• Real-Time Prozesse: statische Prioritäten
◆ Strategie zur Auswahl der Schedulingklassen
• Time-Sharing und interaktive Prozesse:
ausgefeiltes Verfahren zur Sicherung von:
– kurzen Reaktionszeiten
– fairer Zeitaufteilung zwischen rechenintensiven und
I/O-intensiven Prozessen
– gewisser Benutzersteuerung
realisiert mit Multilevel-Feedback-Queue-Scheduling
• meist prioritätengesteuert mit statischen Prioritäten
(z.B. 1. Klasse vor 2. Klasse)
■ Zusätzlich bei MLFB:
◆ Transfer von Prozessen von einer Klasse in die andere (Feedback)
J.33
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
4.7 Multilevel-Feedback-Queue Scheduling (2)
J.34
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
4.7 Multilevel-Feedback-Queue Scheduling (3)
■ Beispiel:
■ Beispiel: Solaris/SunOS
◆ 5 Schedulingklassen mit eigener Bereit-Warteschlange und Strategie
◆ 60 Schedulingklassen mit jeweils Round-Robin-Strategie
◆ Prozesse können von einer zur anderen Warteschlange transferiert werden
• unterschiedliche Zeitscheibenlänge
◆ Auswahl der Klasse über statische Priorität
• solange Prozesse in hochpriorer Klasse kommen keine anderen zum Zuge
◆ Transfer von Prozessen in andere Klassen/Prioritäten
• Prozesse, die lange rechnen, wandern langsam in Klasse mit niedrigerer
Priorität (bevorzugt interaktive Prozesse)
• Prozesse, die lange warten müssen, wandern langsam wieder in höherpriore
Klassen (Aging)
J.35
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
J.36
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
5 Prozesskommunikation
5 Prozesskommunikation (2)
■ Inter-Process-Communication (IPC)
■ Klassifikation nachrichtenbasierter Kommunikation
◆ mehrere Prozesse bearbeiten eine Aufgabe
◆ Klassen
• Verkürzung der Bearbeitungszeit durch Parallelisierung
(gleichzeitige Nutzung und Bearbeitung von Daten)
• Kanäle (Pipes)
• übersichtlichere Struktur der Anwendung
• Briefkästen, Nachrichtenpuffer (Queues)
• Kommunikationsendpunkte (Sockets, Ports)
• Unterbrechungen (Signals)
■ Kommunikation durch Nachrichten
◆ Nachrichten werden zwischen Prozessen ausgetauscht
◆ Übertragungsrichtung
■ Kommunikation durch gemeinsamen Speicher
• unidirektional
◆ Datenaustausch durch gemeinsam zugreifbare Speicherzellen
• bidirektional (voll-duplex, halb-duplex)
J.37
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
5 Prozesskommunikation (3)
J.38
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
6 Aktivitätsträger (Threads)
■ Mehrere Prozesse zur Strukturierung von Problemlösungen
◆ Übertragungs- und Aufrufeigenschaften
◆ Aufgaben eines Prozesses leichter modellierbar, wenn in mehrere
kooperierende Prozesse unterteilt
z.B. Anwendungen mit mehreren Fenstern (ein Prozess pro Fenster)
z.B. Anwendungen mit vielen gleichzeitigen Aufgaben (Webbrowser)
• zuverlässig — unzuverlässig
• gepuffert — ungepuffert
• blockierend — nichtblockierend
• stromorientiert — nachrichtenorientiert — RPC
◆ Multiprozessorsysteme werden erst mit mehreren parallel laufenden Prozessen
ausgenutzt
z.B. wissenschaftliches Hochleistungsrechnen (Aerodynamik etc.)
◆ Adressierung
• implizit: UNIX Pipes
• explizit: Sockets
◆ Client-Server-Anwendungen unter UNIX: pro Anfrage wird ein neuer Prozess
gestartet
z.B. Webserver
• globale Adressierung: Sockets, Ports
• Gruppenadressierung: Multicast, Broadcast
J.39
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
J.40
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
6.1 Prozesse mit gemeinsamem Speicher
6.2 Aktivitätsträger
■ Gemeinsame Nutzung von Speicherbereichen durch mehrere Prozesse
✱ Alternative:
Aktivitätsträger (Threads) oder
leichtgewichtige Prozesse (Lightweighted Processes, LWPs)
▲ Nachteile
◆ viele Betriebsmittel zur Verwaltung eines Prozesses notwendig
◆ Eine Gruppe von Threads nutzt gemeinsam eine Menge von Betriebsmitteln.
• Dateideskriptoren
• Instruktionen
• Speicherabbildung
• Datenbereiche
• Prozesskontrollblock
• Dateien, Sockets etc.
◆ Prozessumschaltungen sind aufwändig.
◆ Jeder Thread repräsentiert eine eigene Aktivität:
• eigener Programmzähler
✱ Vorteil
• eigener Registersatz
◆ In Multiprozessorsystemen sind echt parallele Abläufe möglich.
• eigener Stack
J.41
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
6.2 Aktivitätsträger (2)
J.42
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
6.3 User-Level-Threads
◆ Umschalten zwischen zwei Threads einer Gruppe ist erheblich billiger als eine
normale Prozessumschaltung.
• Es müssen nur die Register und der Programmzähler gewechselt werden
(entspricht dem Aufwand für einen Funktionsaufruf).
• Speicherabbildung muss nicht gewechselt werden.
■ Implementierung
◆ Instruktionen im Anwendungsprogramm schalten zwischen den Threads hinund her (ähnlich wie der Scheduler im Betriebssystem)
◆ Betriebssystem sieht nur einen Thread
✱ Vorteile
• Alle Systemressourcen bleiben verfügbar.
◆ keine Systemaufrufe zum Umschalten erforderlich
■ Ein UNIX-Prozess ist ein Adressraum mit einem Thread
◆ effiziente Umschaltung
◆ Solaris: Prozess kann mehrere Threads besitzen
◆ Schedulingstrategie in der Hand des Anwenders
■ Implementierungen von Threads
▲ Nachteile
◆ User-level Threads
◆ Bei blockierenden Systemaufrufen bleiben alle User-Level-Threads stehen.
◆ Kernel-level Threads
◆ Kein Ausnutzen eines Multiprozessors möglich
J.43
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
J.44
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
6.4 Kernel-Level-Threads
6.5 Beispiel: LWPs und Threads (Solaris)
■ Implementierung
■ Solaris kennt Kernel-, User-Level-Threads und LWPs
◆ Betriebssystem kennt Kernel-Level-Threads
Adressraum 1
Adressraum 2
Adressraum 3
◆ Betriebssystem schaltet Threads um
User-level
Threads
✱ Vorteile
Solaris LWPs
◆ kein Blockieren unbeteiligter Threads bei blockierenden Systemaufrufen
▲ Nachteile
Kernel-level
Threads
◆ weniger effizientes Umschalten
◆ Fairnessverhalten nötig
(zwischen Prozessen mit vielen und solchen mit wenigen Threads)
Kernel
◆ Schedulingstrategie meist vorgegeben
Prozessor
nach Silberschatz, 1994
J.45
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
J.46
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
7 Parallelität und Nebenläufigkeit
7 Parallelität und Nebenläufigkeit (2)
■ Mehrere Prozessen oder Threads
✱ Nebenläufigkeit
✱ Parallelität
Die Anweisungen zweier Prozesse werden parallel bearbeitet, wenn die
Anweisungen unabhängig voneinander zur gleichen Zeit ausgeführt werden.
◆ parallele Bearbeitung nur auf Multiprozessorsystemen
◆ parallele Bearbeitung ist nebenläufig
• zwei oder mehr Prozessoren können parallel Anweisungen bearbeiten
◆ nebenläufige Bearbeitung auch auf Monoprozessoren möglich
• zeitliche Durchmischung der Befehle mehrerer Prozesse oder Threads
parallele Bearbeitung
• Schedulingstrategie oft unabhängig von den bearbeiteten Befehlen
(z.B. Round Robin, MLFB)
Zeit
Prozessor
Prozessor
Zwei Prozesse heißen nebenläufig, wenn ihre Anweisungen unabhängig
voneinander abgearbeitet werden. Dabei spielt es keine Rolle, ob die
Anweisungen zeitlich durchmischt oder auch echt gleichzeitg bearbeitet
werden.
◆ Monoprozessor
• keine parallele Abarbeitung von Befehlen möglich
J.47
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
nebenläufige Bearbeitung auf Monoprozessor
Zeit
J.48
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
8 Koordinierung
8 Koordinierung (2)
■ Beispiel: zwei Prozesse, Beobachter und Protokollierer
■ Effekte:
◆ Mittels Induktionsschleife werden Fahrzeuge gezählt. Alle 10min druckt der
Protokollierer die im letzten Zeitraum vorbeigekommene Anzahl aus.
int cnt= 0;
◆ Fahrzeuge gehen „verloren“
◆ Fahrzeuge werden doppelt gezählt
■ Ursachen:
Observer
on indication
◆ Befehle einer Programmiersprache werden nicht unteilbar (atomar)
abgearbeitet, da sie auf mehrere Maschinenbefehle abgebildet werden.
◆ Keinesfalls werden mehrere Anweisungen zusammen atomar abgearbeitet.
cnt= cnt+1;
◆ Prozesswechsel innerhalb einer Anweisung oder zwischen zwei
zusammengehörigen Anweisungen können zu Inkonsistenzen führen.
Logger
every 10 minutes
println( "Count="+cnt+"\n" );
cnt= 0;
J.49
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
J.50
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
8 Koordinierung (3)
8 Koordinierung (4)
▲ Fahrzeuge gehen „verloren“
▲ Fahrzeuge werden doppelt gezählt:
◆ Nach dem Drucken wird der Protokollierer unterbrochen. Beobachter zählt
weitere Fahrzeuge. Anzahl wird danach ohne Beachtung vom Protokollierer auf
Null gesetzt.
Observer
Logger
println( "Count="+cnt+"\n" );
cnt= cnt+1;
cnt= cnt+1;
◆ Beobachter will Zähler erhöhen und holt sich diesen dazu in ein Register. Er wird
unterbrochen und der Protokollierer setzt Anzahl auf Null. Beobachter erhöht
Registerwert und schreibt diesen zurück. Dieser Wert wird erneut vom
Protokollierer registriert.
Observer
Logger
MOVE #1, D0
ADD cnt, D0
cnt= 0;
println( "Count="+cnt+"\n" );
cnt= 0;
MOVE D0, cnt
[cnt= cnt+1;]
J.51
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
J.52
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
8 Koordinierung (5)
8 Koordinierung (6)
■ Problem gekoppelt an gemeinsame Nutzung
von Daten oder Betriebsmitteln
■ Koordinierung allgemein:
◆ Einschränkung der zeitlichen Durchmischung von Befehlsfolgen in
nebenläufigen Prozessen/Aktivitätsträgern
✱ Lösung: kritische Abschnitte
◆ letztlich Einschränkung der Nebenläufigkeit
◆ nur einer soll Zugang zu Daten oder Betriebsmitteln haben (gegenseitiger
Ausschluss, Mutual Exclusion, Mutex)
• gezielte Aufgabe der Unabhängigkeit bei der Befehlsausführung
◆ kritische Abschnitte erscheinen als zeitlich unteilbar
✱ Hinweis:
■ Wie kann der gegenseitige Ausschluss in kritischen Abschnitten erzielt
werden?
◆ Vorkehrungen, dass nicht mehrere Prozesse gleichzeitig im kritischen Abschnitt
sind
◆ Im Folgenden wird immer von Prozessen die Rede sein. Koordinierung kann/
muss selbstverständlich auch zwischen Threads stattfinden.
J.53
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
8.1 Gegenseitiger Ausschluss
8.2 Gegenseitiger Ausschluss (2)
■ Lösung des Beispiels
■ Zwei Prozesse wollen regelmäßig kritischen Abschnitt betreten
◆ zwei zusammengehörige kritische Abschnitte
◆ Annahme: Maschinenbefehle sind unteilbar (atomar)
int cnt= 0;
■ 1. Versuch
Observer
on indication
cnt= cnt+1;
Logger
every 10 minutes
J.54
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
int turn= 0;
nur ein Prozess
in einem der
kritischen
Abschnitte
println( "Count="+cnt+"\n" );
cnt= 0;
Prozess 0
while( 1 ) {
while( turn == 1 );
...
/* critical sec. */
...
turn= 1;
Prozess 1
while( 1 ) {
while( turn == 0);
...
/* critical sec. */
...
turn= 0;
... /* uncritical */
}
J.55
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
... /* uncritical */
}
J.56
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
8.2 Gegenseitiger Ausschluss (3)
8.2 Gegenseitiger Ausschluss (4)
▲ Probleme der Lösung
■ 2. Versuch
◆ nur alternierendes Betreten des kritischen Abschnitts durch P0 und P1 möglich
◆ Implementierung ist unvollständig
boolean ready0= false;
boolean ready1= false;
◆ aktives Warten
Prozess 1
Prozess 0
while( 1 ) {
ready0= true;
while( ready1 );
■ Ersetzen von turn durch zwei Variablen ready0 und ready1
◆ ready0 zeigt an, dass Prozess 0 bereit für den kritischen Abschnitt ist
◆ ready1 zeigt an, dass Prozess 1 bereit für den kritischen Abschnitt ist
while( 1 ) {
ready1= true;
while( ready0 );
... /* critical sec. */
... /* critical sec. */
ready0= false;
ready1= false;
... /* uncritical */
... /* uncritical */
}
}
J.57
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
8.2 Gegenseitiger Ausschluss (5)
J.58
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
8.2 Gegenseitiger Ausschluss (6)
■ Gegenseitiger Ausschluss wird erreicht
■ Betrachtung der nebenläufigen Abfolgen
◆ leicht nachweisbar durch Zustände von ready0 und ready1
P0
ready0= true;
while( ready1 ); +
<critical> +
ready0= false;
<noncritical> +
ready0= true;
...
▲ Probleme der Lösung
◆ aktives Warten
◆ Verklemmung möglich
P1
ready1= true;
while( ready0 ); +
<critical> +
ready1= false;
<noncritical> +
ready1= true;
...
+ = mehrfach, mind. einmal
* = mehrfach oder gar nicht
◆ Durchspielen aller möglichen Durchmischungen
J.59
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
J.60
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
8.2 Gegenseitiger Ausschluss (7)
8.2 Gegenseitiger Ausschluss (8)
■ Harmlose Durchmischung
P0
ready0= true;
while( ready1 );
<critical>
<critical> *
ready0= false;
<noncritical> +
ready0= true;
...
■ Verklemmung (Lifelock)
P1
6
P0
P1
ready0= true;
ready1= true;
ausgeführte
ready1= true;
Anweisungen
while( ready0 );
while( ready1 );
while( ready0 ); +
<critical> +
ready1= false;
<noncritical> +
ready1= true;
...
while( ready1 ); +
<critical> +
ready0= false;
<noncritical> +
ready0= true;
...
while( ready0 ); +
<critical> +
ready1= false;
<noncritical> +
ready1= true;
...
J.61
8.2 Gegenseitiger Ausschluss (9)
J.62
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
8.2 Gegenseitiger Ausschluss (10)
■ 3. Versuch (Algorithmus von Peterson, 1981)
■ Algorithmus implementiert gegenseitigen Ausschluss
◆ vollständige und sichere Implementierung
boolean ready0= false;
boolean ready1= false;
int turn= 0;
◆ turn entscheidet für den kritischen Fall von Versuch 2, welcher Prozess nun
wirklich den kritischen Abschnitt betreten darf
◆ in allen anderen Fällen ist turn unbedeutend
Prozess 1
while( 1 ) {
ready1= true;
turn= 0;
while( ready0 &&
turn == 0 );
▲ Problem der Lösung
◆ aktives Warten
✱ Algorithmus auch für mehrere Prozesse erweiterbar
... /* critical sec. */
... /* critical sec. */
ready0= false;
ready1= false;
◆ Lösung ist relativ aufwendig
... /* uncritical */
... /* uncritical */
}
beide Prozesse
warten aktiv
while( ready0 );
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
Prozess 0
while( 1 ) {
ready0= true;
turn= 1;
while( ready1 &&
turn == 1 );
5
}
J.63
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
J.64
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
8.3 Spezielle Maschinenbefehle
8.3 Spezielle Maschinenbefehle (2)
◆ Kritische Abschnitte mit Test-and-Set Befehlen
■ Spezielle Maschinenbefehle können die Programmierung
kritischer Abschnitte unterstützen und vereinfachen
MemoryBit lock= new MemoryBit(false);
◆ Test-and-Set Instruktion
◆ Swap Instruktion
■ Test-and-set
◆ Maschinenbefehl mit folgender Wirkung (Java-ähnliche Syntax)
boolean test_and_set( MemmoryBit lock )
{
boolean tmp= lock.getBit();
lock.setBit(true);
return tmp;
}
Prozess 0
Prozess 1
while( 1 ) {
while(
test_and_set(lock) );
while( 1 ) {
while(
test_and_set(lock) );
... /* critical sec. */
... /* critical sec. */
lock.setBit(false);
lock.setBit(false);
... /* uncritical */
... /* uncritical */
}
}
• Bit wird gesetzt; vorheriger Wert wird zurückgegeben
✱ Code ist identisch und für mehr als zwei Prozesse geeignet
◆ Ausführung ist atomar
J.65
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
8.3 Spezielle Maschinenbefehle (3)
J.66
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
8.3 Spezielle Maschinenbefehle (4)
■ Swap
■ Kritische Abschnitte mit Swap-Befehlen
◆ Maschinenbefehl mit folgender Wirkung
MemoryWord lock= new MemoryWord( 0 );
void swap( MemoryWord mem1, MemoryWord mem2 )
{
int tmp= mem1.getWord();
mem1.setWord( mem2.getWord() );
mem2.setWord( tmp );
}
MemoryWord key= Prozess 0
new MemoryWord( 0 );
while( 1 ) {
key.setWord(1);
while( key.getWord()==1 )
swap( lock, key );
MemoryWord key= Prozess 1
new MemoryWord( 0 );
while( 1 ) {
key.setWord(1);
while( key.getWord()==1 )
swap( lock, key );
... /* critical sec. */
... /* critical sec. */
lock.setWord(0);
... /* uncritical */
lock.setWord(0);
... /* uncritical */
• Inhalt zweier Speicherworte wird vertauscht
◆ Ausführung ist atomar
}
}
✱ Code ist identisch und für mehr als zwei Prozesse geeignet
J.67
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
J.68
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
8.4 Kritik an den bisherigen Verfahren
8.5 Sperrung von Unterbrechungen
✱ Spinlock
■ Sperrung der Systemunterbrechungen im Betriebssystems
◆ bisherige Verfahren werden auch Spinlocks genannt
Prozess 0
◆ aktives Warten
▲ Problem des aktiven Wartens
◆ Verbrauch von Rechenzeit ohne Nutzen
◆ Behinderung „nützlicher“ Prozesse
◆ Abhängigkeit von der Schedulingstrategie
• nicht anwendbar bei nicht-verdrängenden Strategien
Prozess 1
disable_interrupts();
disable_interrupts();
... /* critical sec. */
... /* critical sec. */
enable_interrupts();
enable_interrupts();
... /* uncritical sec. */
... /* uncritical sec. */
◆ nur für kurze Abschnitte geeignet
• schlechte Effizienz bei langen Zeitscheiben
• sonst Datenverluste möglich
◆ nur innerhalb des Betriebssystems möglich
■ Spinlocks kommen heute fast ausschließlich in Multiprozessorsystemen
zum Einsatz
• privilegierter Modus nötig
◆ nur für Monoprozessoren anwendbar
◆ bei kurzen kritischen Abschnitten effizient
◆ Koordinierung zwischen Prozessen von mehreren Prozessoren
• bei Multiprozessoren arbeiten Prozesse eventuell echt parallel
J.69
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
8.6 Semaphor
J.70
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
8.6 Semaphor (2)
■ Ein Semaphor (griech. Zeichenträger) ist eine Datenstruktur des Systems mit
zwei Operationen (nach Dijkstra)
◆ P-Operation (proberen; passeren; wait; down)
■ Operationen des Semaphors
◆ P-Operation
void P()
{
while( s <= 0 );
s--;
}
• wartet bis Zugang frei
◆ V-Operation (verhogen; vrijgeven; signal; up)
• macht Zugang für anderen Prozess frei
◆ Datenstruktur für Zugangssteuerung: Integer-Wert
atomare Funktion
◆ V-Operation
class Semaphore
{
int s;
Semaphore( int init ) { s= init; }
void V()
{
s++;
}
atomare Funktion
void P() { ... }
void V() { ... }
}
J.71
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
J.72
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
8.6 Semaphor (3)
8.6 Semaphor (4)
■ Implementierung kritischer Abschnitte mit einem Semaphor
■ Implementierung als Systemaufrufe im Betriebssystem (nur Monoproz.)
P-Operation
Semaphore lock= new Semaphore( 1 );
Unterbrechungen sperren
...
while( 1 ) {
lock.P();
Prozess 0
...
while( 1 ) {
lock.P();
Prozess 1
s <= 0
ja
nein
ok = false;
... /* critical sec. */
... /* critical sec. */
lock.V();
lock.V();
... /* uncritical */
}
laufenden Prozess in Zustand
blockiert versetzen und in
Warteschlange aufnehmen
s--;
ok = true;
Prozessumschalter ansteuern und
Unterbrechungen freigeben
Unterbrechungen
freigeben
ok ist eine
prozesslokale
Variable
... /* uncritical */
}
▲ Problem:
until: ok == true
◆ Implementierung von P und V
◆ jeder Semaphor besitzt Warteschlange, die blockierte Prozesse aufnimmt
J.73
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
8.6 Semaphor (5)
J.74
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
8.6 Semaphor (6)
✱ Vorteile einer Semaphor-Implementierung im Betriebssystem
V-Operation
Unterbrechungen sperren
◆ Einbeziehen des Schedulers in die Semaphor-Operationen
s++;
◆ kein aktives Warten; Ausnutzen der Blockierzeit durch andere Prozesse
■ Implementierung einer Synchronisierung
alle Prozess aus der Warteschlange
in den Zustand bereit versetzen
◆ zwei Prozesse P1 und P2
Unterbrechungen freigeben
◆ Anweisung S1 in P1 soll vor Anweisung S2 in P2 stattfinden
Prozessumschalter ansteuern
Semaphore lock= new Semaphore( 0 );
◆ Prozesse probieren immer wieder, die P-Operation erfolgreich abzuschließen
◆ Schedulingstrategie entscheidet über Reihenfolge und Fairness
• leichte Ineffizienz durch Aufwecken aller Prozesse
• mit Einbezug der Schedulingstrategie effizientere Implementierungen
möglich
...
S 1;
lock.V();
...
Prozess 1
...
lock.P();
S2;
...
Prozess 2
✱ Zählender Semaphor
J.75
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
J.76
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
8.6 Semaphor (7)
9 Klassische Koordinierungsprobleme
■ Abstrakte Beschreibung von zählenden Semaphoren (PV System)
■ Reihe von bedeutenden Koordinierungsproblemen
◆ für jede Operation wird eine Bedingung angegeben
◆ Gegenseitiger Ausschluss (Mutual exclusion)
• falls Bedingung nicht erfüllt, wird die Operation blockiert
• nur ein Prozess darf bestimmte Anweisungen ausführen
◆ für den Fall, dass die Bedingung erfüllt wird, wird eine Anweisung definiert, die
ausgeführt wird
■ Beispiel: zählende Semaphore
◆ Puffer fester Größe (Bounded buffers)
• Blockieren der lesenden und schreibenden Prozesse,
falls Puffer leer oder voll
◆ Leser-Schreiber-Problem (Reader-writer problem)
Operation
Bedingung
Anweisung
P( S )
S>0
S := S – 1
V( S )
TRUE
S := S + 1
• Leser können nebenläufig arbeiten; Schreiber darf nur alleine zugreifen
◆ Philosophenproblem (Dining-philosopher problem)
• im Kreis sitzende Philosophen benötigen das Besteck der Nachbarn
zum Essen
J.77
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
9.1 Gegenseitiger Ausschluss
9.1 Gegenseitiger Ausschluss (2)
■ Semaphor
■ Abstrakte Beschreibung: binäre Semaphore
◆ eigentlich reicht ein Semaphor mit zwei Zuständen: binärer Semaphor
class BinarySemaphore
{
boolean s;
Semaphore( boolean init ) { s= init; }
void P() {
while( s );
s= true;
}
void V() {
s= false;
}
J.78
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
Operation
Bedingung
Anweisung
P( S )
S≠0
S := 0
V( S )
TRUE
S := 1
atomare Funktion
atomare Funktion
}
◆ zum Teil effizienter implementierbar
J.79
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
J.80
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
9.1 Gegenseitiger Ausschluss (3)
9.1 Gegenseitiger Ausschluss (3)
▲ Problem der Klammerung kritischer Abschnitte
■ Automatische Klammerung wünschenswert
◆ Programmierer müssen Konvention der Klammerung einhalten
◆ Beispiel: Java
◆ Fehler bei Klammerung sind fatal
synchronized( lock ) {
lock.P();
... /* critical sec. */
... /* critical sec. */
führt zu Verklemmung (Deadlock)
}
lock.P();
lock.V();
... /* critical sec. */
führt zu unerwünschter Nebenläufigkeit
lock.V();
J.81
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
9.2 Bounded Buffers
J.82
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
9.2 Bounded Buffers (2)
■ Puffer fester Größe
■ Implementierung mit zählenden Semaphoren
◆ mehrere Prozesse lesen und beschreiben den Puffer
◆ zwei Funktionen zum Zugriff auf den Puffer
◆ beispielsweise Erzeuger und Verbraucher (Erzeuger-Verbraucher-Problem)
(z.B. Erzeuger liest einen Katalog; Verbraucher zählt Zeilen; Gesamtanwendung
zählt Einträge in einem Katalog)
◆ UNIX-Pipe ist solch ein Puffer
• put stellt Zeichen in den Puffer
• get liest ein Zeichen vom Puffer
◆ Puffer wird durch ein Feld implementiert, das als Ringpuffer wirkt
• zwei Integer-Variablen enthalten Feldindizes auf den Anfang und das Ende
des Ringpuffers
■ Problem
◆ ein Semaphor für den gegenseitigen Ausschluss
◆ Koordinierung von Leser und Schreiber
◆ je einen Semaphor für das Blockieren an den Bedingungen „Puffer voll“ und
„Puffer leer“
• gegenseitiger Ausschluss beim Pufferzugriff
• Blockierung des Lesers bei leerem Puffer
• Semaphor full zählt wieviele Zeichen noch in den Puffer passen
• Blockierung des Schreibers bei vollem Puffer
• Semaphor empty zählt wieviele Zeichen im Puffer sind
J.83
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
J.84
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
9.2 Bounded Buffers (3)
9.3 Erstes Leser-Schreiber-Problem
■ Lesende und schreibende Prozesse
char [] buffer= new char[N];
int inslot= 0, outslot= 0;
Semaphore mutex= new Semaphore(1),
empty= new Semaphore(0), full= new Semaphore(N);
◆ ähnlich wie gegenseitiger Ausschluss
◆ Leser können nebenläufig zugreifen (Leser ändern keine Daten)
◆ Schreiber können nur exklusiv zugreifen (Daten sonst inkonsistent)
void put( char c )
{
full.P();
mutex.P();
buffer[inslot]= c;
inslot= (inslot+1)%N;
mutex.V();
empty.V();
}
char get()
{
char c;
■ Erstes Leser-Schreiber-Problem (nach Courtois et al. 1971)
◆ Kein Leser soll warten müssen, es sei denn ein Schreiber ist gerade aktiv
empty.P();
mutex.P();
c= buffer[outslot];
outslot= (outslot+1)%N;
mutex.V();
full.V();
return c;
}
■ Realisierung mit zählenden (binären) Semaphoren
◆ Semaphor für gegenseitigen Ausschluss von Schreibern untereinander und von
Schreiber gegen Leser: write
◆ Zählen der nebenläufig tätigen Leser: Variable readcount
◆ Semaphor für gegenseitigen Ausschluss beim Zugriff auf readcount: mutex
J.85
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
9.3 Erstes Leser-Schreiber-Problem (2)
9.3 Erstes Leser-Schreiber-Problem (3)
Semaphore mutex= new Semaphore(1), write= new Semaphore(1);
int readcount= 0;
Leser
...
mutex.P();
if( ++readcount == 1 )
write.P();
mutex.V();
... /* reading */
...
write.P();
J.86
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
Schreiber
■ Vereinfachung der Implementierung durch spezielle Semaphore?
◆ PV-Chunk Semaphore:
führen quasi mehrere P- oder V-Operationen atomar aus
• zweiter Parameter gibt Anzahl an
■ Abstrakte Beschreibung für PV-Chunk Semaphore:
... /* writing */
write.V();
...
mutex.P();
if( --readcount == 0 )
write.V();
mutex.V();
...
J.87
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
Operation
Bedingung
Anweisung
P( S, k )
S≥k
S := S – k
V( S, k )
TRUE
S := S + k
J.88
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
9.3 Erstes Leser-Schreiber-Problem (4)
9.4 Zweites Leser-Schreiber-Problem
■ Implementierung mit PV-Chunk:
■ Wie das erste Problem aber: (nach Courtois et.al., 1971)
◆ Annahme: es gibt maximal N Leser
◆ Schreiboperationen sollen so schnell wie möglich durchgeführt werden
■ Implementierung mit zählenden Semaphoren
PVChunkSemaphore mutex= new PVChunkSemaphore( N );
◆ Zählen der nebenläufig tätigen Leser: Variable readcount
Leser
Schreiber
...
mutex.P( 1 );
...
mutex.P( N );
... /* reading */
... /* writing */
mutex.V( 1 );
...
mutex.V( N );
...
◆ Zählen der anstehenden Schreiber: Variable writecount
◆ Semaphor für gegenseitigen Ausschluss beim Zugriff auf readcount: mutexR
◆ Semaphor für gegenseitigen Ausschluss beim Zugriff auf writecount: mutexW
◆ Semaphor für gegenseitigen Ausschluss von Schreibern untereinander und von
Schreibern gegen Leser: write
◆ Semaphor für den Ausschluss von Lesern, falls Schreiber vorhanden: read
◆ Semaphor zum Klammern des Leservorspanns: mutex
J.89
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
9.4 Zweites Leser-Schreiber-Problem (2)
9.4 Zweites Leser-Schreiber-Problem (3)
Bit
veSemaphore(1),
Semaphore mutexR=new Semaphore(1), mutexW=new
r te
zu vsuchenicht
mutex=new Semaphore(1);
er s n , d
Semaphore write= new Semaphore(1), read=new Semaphore(1);
teh ies
e n!
int readcount= 0, writecount= 0;
!
Leser
mutex.P(); read.P();
mutexR.P();
if( ++readcount == 1 )
P( &write );
mutexR.V();
read.V(); mutex.V();
J.90
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
Schreiber
mutexW.P();
if( ++writecount == 1 )
read.P();
mutexW.V();
write.P();
■ Vereinfachung der Implementierung durch spezielle Semaphore?
◆ Up-Down–Semaphore:
• zwei Operationen up und down, die den Semaphor hoch- und runterzählen
• Nichtblockierungsbedingung für beide Operationen, definiert auf einer
Menge von Semaphoren
... /* writing */
... /* reading */
mutexR.P();
if( --readcount == 0 )
write.V();
mutexR.V();
...
write.V();
mutexW.P();
if( --writecount == 0 )
read.V();
mutexW.V();
...
J.91
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
J.92
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
9.4 Zweites Leser-Schreiber-Problem (4)
9.4 Zweites Leser-Schreiber-Problem (5)
■ Abstrakte Beschreibung für Up-down–Semaphore
■ Implementierung von Up-Down-Semaphore in Java (Schnittstelle)
Operation
Bedingung
Anweisung
up( S, { Si } )
∑Si ≥ 0
S := S + 1
◆ Klasse UpDownSemaphore kapselt ein Bündel von Einzelsemaphoren
◆ Konstruktorparameter:
• Array mit allen einzelnen Up-Down-Semaphoren und deren Initialisierung
◆ Operationen up und down
i
down( S, { Si } )
• erster Parameter: Nummer der zu bearbeitenden Up-Down-Semaphore
∑Si ≥ 0
• zweiter Parameter: Array mit den Nummern der Semaphore, deren Summe
größer gleich Null sein muss
S := S – 1
i
J.93
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
9.4 Zweites-Leser-Schreiber-Problem (6)
J.94
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
9.5 Philosophenproblem
■ Implementierung mit Up-Down–Semaphoren:
■ Fünf Philosophen am runden Tisch
UpDownSemaphore s= new UpDownSemaphore( new int[3]{0,0,0} );
final int reader= 0, writer= 1, mutexw= 2;
Leser
...
s.down( reader,
new int[1]{writer} );
◆ Philosophen denken oder essen
"The life of a philosopher consists of an
alternation of thinking and eating."
(Dijkstra, 1971)
Schreiber
...
s.down( writer, null );
s.down( mutexw,
new int[2]{mutexw,reader} );
◆ zum Essen benötigen sie zwei Gabeln, die
jeweils zwischen zwei benachbarten
Philosophen abgelegt sind
... /* reading */
... /* writing */
s.up( reader, null );
...
s.up( mutexw, null );
s.up( writer, null );
...
▲ Problem
◆ negative Zähler für Leser (reader) und anstehende Schreiber (writer) sowie
Semaphor für gegens. Ausschluss der Schreiber (mutexw)
J.95
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
◆ Gleichzeitiges Belegen mehrerer Betriebsmittel (hier Gabeln)
◆ Verklemmung und Aushungerung
J.96
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
9.5 Philosophenproblem (2)
9.5 Philosophenproblem (3)
■ Naive Implementierung
■ Problem der Verklemmung
◆ eine Semaphor pro Gabel
◆ alle Philosophen nehmen gleichzeitig die linke Gabel auf und
versuchen dann die rechte Gabel aufzunehmen
Semaphore [] forks= new Semaphore[5] { 1, 1, 1, 1, 1 };
Philosoph 0
Philosoph 1 Philosoph 2Philosoph 3
Philosoph 4
forks[0].P();forks[1].P();
forks[2].P();
forks[3].P();
forks[1].P();forks[2].P();
forks[4].P();
forks[3].P();
forks[4].P();
forks[0].P();
Philosoph i, i ∈ [0, 4]
while( 1 ) {
... /* think */
forks[i].P();
forks[(i+1)%5].P();
◆ System ist verklemmt
... /* eat */
• Philosophen warten alle auf ihre Nachbarn
forks[i].V()
forks[(i+1)%5].V()
}
J.97
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
9.5 Philosophenproblem (4)
J.98
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
9.5 Philosophenproblem (5)
■ Lösung 1: gleichzeitiges Aufnehmen der Gabeln
■ Implementierung mit PV-multiple–Semaphoren
◆ Implementierung mit binären oder zählenden Semaphoren ist nicht trivial
◆ Schnittstelle ähnlich Up-Down-Semaphore-Implementierung
◆ Zusatzvariablen erforderlich
PVMultSemaphore forks=
new PVMultSemaphore( 5, new int[5] {1,1,1,1,1} );
◆ unübersichtliche Lösung
✱ Einsatz von speziellen Semaphoren: PV-multiple–Semaphore
Philosoph i, i ∈ [0, 4]
◆ gleichzeitiges und atomares Belegen mehrerer Semaphoren
◆ Abstrakte Beschreibung:
while( 1 ) {
... /* think */
Operation
Bedingung
Anweisung
P( { Si } )
∀i, S i > 0
∀i, S i = S i – 1
V( { Si } )
TRUE
∀i, S i = S i + 1
forks.P( new int[2]{i, (i+1)%5} );
... /* eat */
forks.V( new int[2]{i, (i+1)%5} );
}
J.99
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
J.100
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
9.5 Philosophenproblem (6)
9.5 Philosophenproblem (7)
■ Lösung 2: einer der Philosophen muss erst die andere Gabel aufnehmen
◆ Ablauf der asymmetrischen Lösung im ungünstigsten Fall
Philosoph 0
Semaphore [] forks= new Semaphore[5] { 1, 1, 1, 1, 1 };
Philosoph i, i ∈ [0, 3]
while( 1 ) {
... /* think */
Philosoph 4
while( 1 ) {
... /* think */
forks[i].P();
forks[(i+1)%5].P();
forks[0].P();
forks[4].P();
... /* eat */
... /* eat */
forks[i].V()
forks[(i+1)%5].V()
forks[0].V()
forks[4].V()
}
Philosoph 1 Philosoph 2Philosoph 3
Philosoph 4
forks[0].P();forks[1].P();
forks[2].P();
forks[3].P();
forks[1].P();forks[2].P();
forks[0].P();
forks[3].P();
forks[4].P();
◆ System verklemmt sich nicht
}
J.101
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
10 Monitore
J.102
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
10.1 Beispiel: Erzeuger-Verbraucher
■ Einfaches Konzept zur Koordinierung (B. Hansen/Hoare 1975)
◆ Ziel: Vermeidung von Koordinierungsfehlern durch falsche Platzierung von
Semaphoren
■ Monitor als programmiersprachliches Konstrukt mit
monitor
{
char buffer[N];
int inslot= 0, outslot= 0, count= 0;
condition notFull, notEmpty;
void put( char c )
{
while( count == N )
wait( notFull );
◆ privaten Variablen
◆ Prozeduren
• laufen immer im gegenseitigen Ausschluss
◆ Condition-Variables zum Blockieren
• Aufruf von signal(c) führt zur Deblockade eines Prozesses blockiert an
Condition-Variable c
J.103
c= buffer[outslot];
outslot= (outslot+1)%N;
count--;
signal( notFull );
return c;
}
}
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
while( count == 0 )
wait( notEmpty );
buffer[inslot]= c;
inslot= (inslot+1)%N;
count++;
signal( notEmpty );
• Aufruf von wait(c) führt zur Blockade an Condition-Variable c
• Blockieren und Deblockieren unter gegenseitigem Ausschluss
– Freigabe der Sperre bei Blockieren
– Belegen der Sperre vor Deblockierung
char get( void )
{
char c;
}
J.104
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
10.2 Beispiel: Java
10.2 Beispiel: Java (2)
■ Threaderzeugung
class buffer
{
char buffer[]= new char[N];
int inslot= 0, outslot= 0, count= 0;
class MyThread extends Thread
{
public void run()
{
... /* thread code */
}
}
synchronized public
void put( char c )
{
while( count == N )
try { wait(); }
catch( ... ) {}
...
synchronized public
char get( void )
{
char c;
while( count == 0 )
try { wait(); }
catch( ... ) {}
buffer[inslot]= c;
inslot=(inslot+1)%N;
count++;
notifyAll();
Thread t= new MyThread();
...
c= buffer[outslot];
outslot= (outslot+1)%N;
count--;
notifyAll();
return c;
}
◆ weitere Möglichkeiten ohne Vererbung (siehe Java-Dokumentation)
}
J.105
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
10.2 Beispiel: Java (3)
■ Jedes Objekt stellt Monitor dar
◆ nur für synchronized Methoden
◆ expliziter Eintritt in den Monitor (lock) durch
synchronized( obj ) { ... }
■ Nur eine implizite Condition-Variable
◆ wait und notify statt wait und signal
◆ notifyAll deblockiert alle am Objekt (Monitor) blockierten Threads
✱ Näheres: siehe Java-Dokumentation
J.107
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
}
J.106
 1997-2004, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005s-TI1-J-Proc.fm, 2005-05-29 22.13] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/