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/