Infrastruktur und Betriebssysteme III. Martin Plümicke

Transkript

1 Infrastruktur und Betriebssysteme III Martin Plümicke 25. Februar 2002

2 Inhaltsverzeichnis 1 Einführung in Betriebssysteme 3 2 Überblick Systemkomponenten Prozess Management Hauptspeicherverwaltung Datei Systeme I/O Systeme Shell Systemaufrufe Prozesskontrolle Filemanipulation Gerätemanipulation Informationsverwaltung Kommunikation Java Virual Machine Programmiersprache API Virtuelle Maschine Prozesse Einführung Threads Vorteile von Threads Userlevel und Kernel-Threads Java Threads CPU Prozess Scheduling (Prozessablaufplanung) First Come, First Served (FCFS) Kürzester Auftrag zuerst Prioritäts Scheduling Round Robin Algorithmus Mehrstufiges Scheduling Java Thread Scheduling Prozesssynkronisation Aktives Warten Peterson Lösung TSL Instruktion

3 3.4.4 Zustandsveränderungen von Prozessen Semaphore Kritische Regionen Monitore Prozesssynkronisation in Java Klassische Synkronisationsprobleme Deadlocks I/O Systeme Dateisysteme I/O Systeme Datei Systeme Memory Management System Paging Segmentierung Reale Betriebssysteme Unix Linux Windows NT

4 3.4 Prozesssynkronisation In diesem Abschnitt wollen wir die Probleme betrachten, die möglicherweise eintreten können, wenn Prozesse miteinander kommunizieren. Kritische Bereiche Betrachten wir zunächst ein Beispiel, um uns mögliche Schwierigkeiten bei der Prozesskommunikation deutlich zu machen. In der Regel wird in Unix Systemen das Drucken durch folgenden Mechanismus geregelt: Es gibt eine Druckerqueue in die verschiedene Prozesse Druckaufträge eintragen dürfen. Der Druckerdeamon (Prozess, der das Ausdrucken ausführt) arbeitet die Queue dann Schritt für Schritt ab. Möchte nun ein Prozess einen Druckauftrag erteilen, so stellt er an die Queue die Anfrage nach dem nächsten freien Platz und erhält eine Adresse. Wenn nun in diesem Moment der Scheduler entscheidet diesen Prozess auf rechenbereit zu setzen und ein nächster Prozess ebenfalls einen Druckauftrag erteilen will. Dieser neue Prozess erhält nun die gleiche Adresse und schreibt seinen Druckauftrag an diese Adresse. Nun kommt der erste Prozess wieder zum Zuge. Er schreibt nun seinerseits den Druckauftrag an diese Adresse und der Druckauftrag des zweiten Prozesses geht verloren. Worin liegt in diesem Beipsiel nun das Problem? Das Problem ist, dass beide Prozesse auf eine Variable, nämlich die Variable des nächsten freien Platzes in der Queue zugreifen. Also brauchen wir um das Problem zu lösen so etwas wie einen wechselseitigen Ausschluss, der es immer nur einem Prozess erlaubt für eine bestimmte Zeit auf eine solche Variable zuzugreifen. Man nennt die Abschnitte eines Programms, die auf solche kritischen Resource zugreifen Kritische Bereiche. Der wechselseitige Ausschluss sollte grundsätzlich folgenden vier Bedingungen genügen. 1. Zu jedem Zeitpunkt darf sich nur ein Prozess in seinem kritischen Bereich befinden 2. Es dürfen keine Annahmen über Ausführgeschwindigkeit und oder Anzahl der Prozessoren gemacht werden. 3. Kein Prozess der sich außerhalb seines kritischen Bereichs befindet darf einen anderen Prozess blockieren. 4. Kein Prozess soll unendlich lange auf seine Fortführung warten müssen. Die erste Bedingung ist die Bedingung für die Lösung des benannten Problems. Die zweite Bedingung soll die Portabilität und Anwendbarkeit unter verschiedenen Rahmenbedingungen (z.b. es werden mehr oder weniger Prozesse auf dem Rechner gleichzeitig abgearbeitet) ermöglichen. Die dritte Bedingung ist eine Effizienzbedingung und die vierte Bedingung stellt sicher, dass sich ein System durch den wechselseitigen Ausschluss nicht selber blockiert Aktives Warten Einen ersten Ansatz dieses Problem zu lösen bietet das aktive Warten. Betrachten wir die zwei C Programmstücke in Abbildung In den beiden Programmstücken ist die Variable turn eine Variable auf die beide Prozesse gleichermaßen zugreifen können. Dies lässt sich beispielsweise durch das Thread-Konzept (vgl. Kapitel 3.2) realisieren. Wenn nun Prozess 1 in einen kritischen Bereich eintreten will, so wird die Variable turn auf 0 geprüft. Ist sie ungleich 0 bleibt der Prozess in der While Schleife bis die Variable den Wert 0 annimmt. Die Variable turn wird durch Prozess

5 Prozess 1: Prozess 2: while (TRUE) { while (TRUE) { while (turn!=0) while (turn!=1) ; ; critical_section(); critical_section(); turn = 1; turn = 0; noncritical_section(); noncritical_section(); Abbildung 3.13: Aktives Warten 2 auf 0 gesetzt, wenn er seinen kritischen Bereich verlässt. Dann kann auch Prozess 1 in seinen kritischen Bereich eintreten. Nun ist es aber Prozess 2 unmöglich wiederum in seinen kritischen Bereich einzutreten, solange turn nicht auf 1 gesetzt wird. Der Ansatz des aktiven Wartens ist eine Lösung des Problems, sollte aber nur dann verwendet werden, wenn sicher ist, dass die Prozesse jeweils nicht allzulange warten müssen, weil das aktive Warten Rechenzeit verbraucht. Außerdem wird verlangt, dass Prozesse streng abwechselnd in ihre kritischen Bereiche eintreten, was in der Regel auch nicht den gegebenen Problemen entspricht Peterson Lösung Peterson hat 1981 vorgeschlagen zwei Prozeduren zu benutzen, die jeweils aufgerufen werden, wenn ein Prozess in seinen kritischen Bereich eintritt bzw. wenn er ihn wieder verlässt. In dieser void enter_region (int process) int other; { other = 1 - process; interested [process] = 1; loser = process; /* loser ist immer der */ /* Zweite der kommt */ while (loser = process && interested [other]); void leave_region (int process) { interested [process] = 0; Abbildung 3.14: Peterson Lösung Lösung haben die Prozesse die Nummern 0 und 1. Betrachten wir einen Prozess, der gerade in die Prozedur enter region eintritt. Zunächst wird der andere Prozess festgestellt. Dann wird das Feld interested für den betrachteten Prozess gesetzt. Und nun erhält die Variable loser die Prozessnummer des betrachteten Prozesses. Hat nun auch der andere Prozess Interesse in seinen kritischen Bereich einzutreten (interested [other] = 1), so ist entweder der andere Prozess in seinem kritischen Bereich, dann muss der betrachtete Prozess warten. Wenn der andere Prozess aber auch gerade versucht in seinen kritschen Bereich einzutreten, so wird loser umgesetzt und der betrachtete Prozess kann in seinen kritschen Bereich eintreten. Verlässt der andere Prozess

6 durch leave region seinen kritischen Bereich, so wird interested [other] = 0 gesetzt und der betrachtete Prozess kann in seinen kritischen Bereich eintreten. Dieser Ansatz erlaubt, dass Prozesse nicht unbedingt abwechselnd in ihre kritischen Bereiche eintreten müssen. Es wird aber auch hier aktiv gewartet. Aufgabe: Implementieren Sie die Peterson Lösung in Java. Gegeben sei dazu das folgende Interface MutualExclusion public interface MutualExclusion { public void enter_region(int process); public void leave_region(int process); Programmieren Sie die Lösung als Klasse, die MutualExclusion implementiert. Hinweis: Sie müssen die Variablen auf die mehrere Threads zugreifen können als volatile deklarieren. Programmieren Sie einen Thread, der in seiner Methode run in den kritischen Bereich eintritt und ihn wieder verlässt. Programmieren Sie eine Klasse, die mehrere Threads anlegt und startet Testen Sie ihr Programm, indem Sie innerhalb des kritsichen Bereichs einen Ausgabeaufruf einfügen, der eindeutig anzeigt, welcher Thread im Moment abgearbeitet wird. Kommentieren Sie einmal die Aufrufe von enter region und leave region aus und beobachten Sie den Unterschied TSL Instruktion Für den nächsten Ansatz setzten wir voraus, dass die Maschinensprache einen Test and Set Lock Befehl (TSL) enthält. Der TSL Befehl kopiert den Inhalt einer bestimmten Adresse in ein Register und setzt den Inhalt der Adresse auf einen Wert ungleich 0. Diese Operation erfolgt ungeteilt. Es ist also keine Unterbrechung zwischen kopieren und Wert auf ungleich 0 setzen möglich. Als Lösung geben wir nun ein Stück Pseudo Assembler Code an: enter_region: tsl flag, register ; kopiere flag in register und setze flag auf 1 cmp register, #0 ; war flag gleich 0 bne enter_region ; falls nicht gleich, verzweige ; nach enter_region, also warte ret ; Eintritt in kritischen Bereich ok leave_region move #0, flag ret ; lösche flag Auch die Lösung mit dem TSL Befehl hat den Nachteil, dass sie aktives Warten benutzt. Das heißt es wird zum einen Rechenzeit verschwendet. Zum anderen birgt das aktive Warten aber auch noch weitere Gefahren in sich. Wenn zum Beispiel der Scheduler einem Prozess sehr viel Rechenzeit zuteilt, der gerade aktiv wartet, kann das das Computersystem extem bremsen und ggf. sogar blockieren, wenn aus irgendeinem Grund der Prozess der sich in seinem kritischen Bereich befindet nicht mehr in den rechnenden Zustand versetzt wird.

7 3.4.4 Zustandsveränderungen von Prozessen Eine weitere Idee wäre Prozesse anstatt sie aktiv warten zu lassen in den blockierten Zustand zu versetzen. Dann kann es auch nicht mehr vorkommen, dass ein Prozess, der sich im aktiven Warten befindet, sehr viel Rechenzeit zugeordet bekommt. Betrachten wir dazu ein weiteres Beispiel das auf kritische Resourcen zugreift, das Erzeuger Verbraucher Problem 2 void producer () { int item; while(1) /* N = max. Pfuffergroesse */ { produce_item(&item); /* erzeuge Eintrag */ if (count == N) /* Wenn Puffer voll, */ sleep(); /* lege Dich schlafen */ enter_item(item); /* trage erzeugtes Element in Puffer ein */ count = count + 1; /* erhöhe Anzahl der Puffereinträge */ if (count == 1) /* War der Puffer leer, */ wakeup(consumer) /* so wecke den Verbraucher */ void consumer () { int item; while (1) { if (count == 0) /* Wenn Puffer leer, */ sleep(); /* lege Dich schlafen */ remove_item(&item); /* entnehme Eintrag aus dem Puffer */ count = count - 1; /* vermindere Anzahl der Puffereinträge */ if (count == N - 1) /* War Puffer voll, */ wakeup(producer); /* wecke Erzeuger auf */ consume_item(); /* verarbeite Eintrag */ Abbildung 3.15: Erzeuger Verbraucher Problem mit kritischen Resourcen In dem C Programm in Abblidung 3.15 wird davon ausgegangen, dass in C Betriebssystemstemaufrufe sleep, welcher sich selber blockiert (schlafen legt), und wakeup(process), welcher den Prozess process vom blockierten in den rechenbereiten Zustand überführt (aufweckt), existieren. Vergleiche Abbildung 3.2. Das Beispiel in Abbildung 3.15 führt genauso wie das Druckerbeipiel am Anfang des Kapitels möglicherweise zu großen Problemen. Nehmen wir an, der Verbraucher stellt im Moment fest, dass count den Wert 0 hat, legt sich aber noch nicht schlafen, sondern wird vom Scheduler in den rechenbereiten Zustand gesetzt. Der Scheduler setzt nun den Erzeuger in den rechnenden Zustand. Der Erzeuger setzt die Variable count auf 1 und sendet an den rechenbereiten Zustand consumer eine wakeup Signal. Dieser ignoriert dieses Signal, weil er ja wach ist und legt sich schlafen, wenn er vom Scheduler wieder in der rechnenden Zustand versetzt wird. Der Erzeuger arbeitet dann bis der Puffer voll ist und legt sich auch schlafen. Nun sind beide Prozesse blockiert und das System arbeitet nicht mehr. Wir haben einen Deadlock erreicht. 2 Bsp.: cat file1 file2 more.

8 3.4.5 Semaphore Zur Lösung dieses Problems hat E. W. Dijkstra 1965 vorgeschlagen sogenannte Semaphore einzuführen. Semaphore sind Integer-Variablen auf denen zwei Operationen up und down definiert sind. up und down sind Verallgemeinerungen von sleep und wakeup. Wird down auf eine Variable mit größer als 0 angewandt, so wird der Wert um 1 erniedrigt. Wird down auf 0 angewandt so legt sich der Prozess schlafen. Die Operation up angewandt auf einen Semaphor der den Wert 0 enthält, weckt einen (zufällig ausgewählten) Prozess aus, der sich bezüglich des Semaphors schlafen gelegt hat, und weckt ihn auf. Der Wert bleibt 0. Ist kein Prozess bezüglich des Semaphors blockiert, wird der Semaphor um 1 erhöht. Sowohl die up- als auch die down Operation sind atomare Operationen. Das heißt es ist nicht möglich die Ausführung von up oder down zu unterbrechen. Dies ist entscheidend, um das aufgezeigte Problem zu lösen. Betrachten wir nun die Lösung des Erzeuger Verbraucher Problems mit Hilfe von Semaphoren (Abbildung 3.16). In der Lösung des Erzeuger Verbraucher Problems werden drei Semaphore eingesetzt. Der Semaphor empty zählt die leeren Puffereinträge und legt den Erzeuger schlafen, falls der Puffer voll ist. Der Semaphor full zählt die Puffereinträge und legt den Verbraucher schlafen, falls der Puffer leer ist. Der Semaphor mutex stellt sicher, dass sich immer nur ein Prozess in seinem kritischen Bereich befindet. Dieser Semaphor nimmt nur die Werte 0 und 1 an. Man nennt ihn deshalb auch binären Semaphor. Das Konzept der Semaphoren direkt beispielsweise in der Sprache C zu programmieren bringt einige Probleme bei der Fehlersuche mit sich. Betrachten wir zum Beispiel den Fehler, dass ein Programmierer versehentlich up und down verwechselt: up(mutex)... critical_section()... down(mutex) Durch diesen Fehler ist es möglich, dass sich verschiedene Prozesse gemeinsamen in ihren kritischen Bereichen befinden. Der Fehler führt möglicherweise selten zu falschen Ergebnissen, weil er sich nur dann auswirkt, wenn sich tatsächlich verschiedene Prozesse gleichzeitig in ihren kritischen Bereichen befinden. Außerdem ist der Fehler nur sehr schwer reproduzierbar. Ein weiterer möglicher Programmierfehler wäre, dass man ausversehen zweimal die down Operationen verwendet: down(mutex)... critical_section()... down(mutex) Das Programm würde in diesem Fall immer mit einem Deadlock enden, denn der Prozess wird immer nachdem er den kritischen Bereich verlassen schlafengelegt. Um das Auftreten von Fehlern dieser Art zu minimieren, gibt es eine ganze Reihe von Konstrukten in höheren Programmiersprachen, die es ermöglichen, Lösungen auf einer höheren Ebene anzugeben. Wir werden hier das Konzept der Kritischen Regionen und der Monitore vorstellen Kritische Regionen Zunächst führt man in einer höheren Programmiersprache 3 ein zusätzliches Schlüsselwort shared ein, mit dessen Hilfe man Variablen deklariert, auf die verschiedene Prozesse zugreifen dürfen: 3 Wir verwenden hier eine pascal ähnliche Systax und deuten damit eine gegenüber C höhere Programmiersprache an.

9 typedef int semaphore; semaphore mutex = 1; /* kontolliert Eintritt in kritischen Bereich */ semaphore empty = N; /* zählt leere Puffereinträge */ semaphore full = 0; /* zählt volle Puffereinträge */ void producer () { int item; while(1) { produce_item(&item); /* erzeuge Eintrag */ down (&empty); /* wenn Puffer nicht voll, erniedrige empty, sonst lege Dich schlafen */ down (&mutex); /* falls anderer Prozess auf den Puffer zugreift, lege Dich schlafen, sonst erniedrige mutex */ enter_item(item); /* trage erzeugtes Element in Puffer ein */ up(&mutex); /* falls anderer Prozess auf den Puffer zugreifen wollte, wecke ihn auf, sonst erhöhe mutex */ up(&full); /* falls anderer Prozess leeren Puffer vorgefunden hatte, wecke ihn auf, sonst erhöhe full */ void consumer () { int item; while (1) { down (&full) ; /* wenn Puffer nicht leer, erniedrige full, sonst lege Dich schlafen */ down (&mutex); /* falls anderer Prozess auf den Puffer zugreift, lege Dich schlafen, sonst erniedrige mutex */ remove_item(&item); /* entnehme Eintrag aus dem Puffer */ up(&mutex); /* falls anderer Prozess auf den Puffer zugreifen wollte, wecke ihn auf, sonst erhöhe mutex */ up(&empty); /* falls anderer Prozess vollen Puffer vorgefunden hatte, wecke ihn auf, sonst erhöhe empty */ consume_item(); /* verarbeite Eintrag */ Abbildung 3.16: Lösung des Erzeuger Verbraucher Problems mit Semaphoren

10 var v : shared T; Hier wird eine Variable v von Typ T deklariert, auf die mehrere Prozesse zugreifen können. Auf Variablen, die als shared deklariert sind, darf man nur innerhalb von Region Umgebungen zugreifen: region v when B do S; Die Semantik der Region Umgebungen ist so festgelegt, dass solange das Programmstück S ausgeführt wird, kein anderer Prozess auf die Variable v zugreifen darf. B ist ein boole scher Ausdruck, der erfüllt sein muss, damit der Prozess mit S nt. Als ein Beispiel für die Region Umgebungen wollen wir nun das Erzeuger Verbraucher Problem implementieren (Abbildung 3.17). var queue : shared record pool : array [0..N] of integer; start, end, count : integer end procedure producer; var item : integer; produce_item(item); region queue when count < N do enter_item(item); end; (* producer *) procedure consumer; var item : integer; region queue when count > 0 do remove_item (item); consume_item(item); end; (* consumer *) Abbildung 3.17: Erzeuger Verbraucher Problem in der Region Umgebung Betrachten wir nun eine mögliche Übersetzung der Region Umgebungen: region x when B do S; In Abbildung 3.18 ist in C mit Semaphoren eine Übersetzung angegeben. Die Übersetzung implementiert eine Warteschleife die jeweils alle Prozesse die zum Start der Region Umgebungen kommen zunächst durch eine zweistufige Warteschleife schickt, wenn die Bedingung B (noch) nicht erfüllt ist. Schritt für Schritt wird für die wartenden Prozesse die Bedingung wieder geprüft. Drei binäre Semaphoren sind wie folgt vorinitialisiert: mutex = 1, first = 0, second = 0. Zunächst wird der Prozess bezüglich first schlafen gelegt. Wenn nun ein anderer Prozess S verläßt, wird dieser Prozess durch up aufgeweckt. Der so aufgeweckte Prozess weckt dann in der zweiten Stufen alle Prozesse auf, die sich bezüglich first

11 down(mutex) while (not B) { first-count = first-count + 1; if (second-count > 0) up(second); else up(mutex); down(first); first-count = first-count - 1; second-count = second-count + 1; if (first-count > 0) up(first); else up(second); down(second); second-count = second-count - 1; S; if (first-count > 0) up(first); else { if (second-count > 0) up(second); else up(mutex); Abbildung 3.18: Implementierung der Region Umgebung schlafen gelegt haben. Diese so aufgeweckten Prozesse legen sich nun bezüglich second schlafen. Der letzte Prozess der bezüglich first aufgeweckt wurde, weckt seinerseits einen Prozess auf, der sich bezüglich second schlafen gelegt hat. Für diesen aufgeweckten Prozess wird die Bedingung B erneut überprüft. Wenn B erfüllt ist, durchläuft der betrachtete Prozess das Programmstück S. Die Variablen first-count und second-count beinhalten die Anzahl der im Moment bezüglich des jeweiligen Semaphors schlafen gelegten Prozesse. Man muss die Warteschleife zweistufig programmieren, weil sich sonst mehrere wartende Prozesse ständig gegenseitig aufwecken würden, ohne dass ein anderer Prozess seinen kritischen Bereich verlassen hätte. Damit wäre die Implementierung falsch Monitore Ein Monitor ist ebenfalls ein Konstrukt einer höheren Programmiersprache. In einem Monitor werden mehrere Prozeduren und Variablen zusammengefaßt. Die Idee ist nun, dass in jedem Monitor eines Programms sich gleichzeitig immer nur ein Prozess befinden darf. Falls ein weiterer Prozess in den Monitor eintreten will, muss er sich schlafen legen und warten bis der andere Prozess den Monitor verlassen hat. Auf Variablen, die in einem Monitor deklariert sind, dürfen immer nur Prozeduren des gleichen Monitors zugreifen. Dieses Konzept stellt sicher, dass sich immer nur ein Prozess innerhalb eines Monitors befindet. Für die Programmierung ist das aber nicht ausreichend. Es sollte zusätzlich durch Befehle möglich sein, Prozesse zu blockieren und wieder aufzuwecken. Dazu führt man einen neuen Typ von Variablen ein: condition. Es gibt zwei Operationen wait und signal, die auf Variablen vom Typ condition anwendbar sind. Die

12 Operation wait blockiert einen Prozess bezüglich einer condition Variablen. signal weckt einen beliebigen Prozess bezüglich einer condition Variablen wieder auf. Nehmen wir nun an ein Prozess P weckt einen Prozess Q auf. In dieser Situation gibt es mehrere Möglichkeiten, die eintreten können: 1. P wartet bis Q den Monitor verlässt oder blockiert wird. 2. Q wartet bis P den Monitor verlässt oder blockiert wird. In der Praxis gibt es verschiedene Implementierungen. Wir werden später eine Implementierungen für Fall 2 angeben. In der existierenden Programmiersprache Concurrent Pascal sind Monitore aber beispielsweise so realisiert, dass P sofort den Monitor verlässt, wenn Q aufgeweckt wurde. Das bedeutet allerdings, dass jeder Prozess innerhalb eines Monitors nur ein signal senden kann. Betrachten wir nun einen Lösungsansatz für das Erzeuger Verbraucher Problem mit einem Monitor (Abbildung 3.19). Wir müssen zwei neue Prozeduren enter und remove einführen, die beide in dem gleichen Monitor implementiert sind. Abschließend geben wir noch eine mögliche Übersetzung von Monitoren an. Für jeden Monitor führen wir einen Semaphor mutex ein (initialiert mit 1). Beim Eintreten in dem Monitor muss down( mutex ) ausgeführt werden. Zusätzlich wird noch ein Semaphor next und eine Integer-Variable next-count eingeführt, welche die Prozesse zählt, die auf den Eintritt in den Monitor warten. Jede Prozedur F eines Monitors wird dann übersetzt nach: down(mutex); Rumpf von F ; if next-count > 0 up(next); else up(mutex); Für jede condition Variable x wird ein Semaphor x-sem und eine Integer-Variable x-count eingeführt (beide mit 0 initialiert). Die Operation wait(x) wird dann wie folgt implementiert: x-count = x-count + 1; if next-count > 0 up(next); else up(mutex); down(x-sem); x-count = x-count - 1; Bleibt noch die Übersetzung der Operation signal(x): if x-count > 0 { next-count = next-count + 1; up(x-sem); down(next) next-count = next-count - 1;

13 monitor ProducerConsumer var full, empty : condition; count : integer; procedure enter(item : integer); if count = N then wait(full); enter_item(item); count := count + 1; if count = 1 then signal(empty) end; (* enter *) procedure remove(var item : integer); if count = 0 then wait(empty); remove_item(item); count := count - 1; if count = N -1 signal(full); end; (* remove *) end; (* ProducerConsumer *) procedure producer; var item : integer; produce_item(item); enter(item); end; (* producer *) procedure consumer; var item : integer; remove(item); consume_item(item); end; (* consumer *) Abbildung 3.19: Lösung des Erzeuger Verbraucher Problem mit einem Monitor Prozesssynkronisation in Java In Java gibt es ebenfalls die Möglichkeit durch wechselseitigen Ausschluss auf kritische Bereiche zuzugreifen. Neben der Peterson Lösung (Abschnitt 3.4.2) bietet Java die Möglichkeit kritische Bereiche als Methoden durch das Schlüsselwort synchronized zu realisieren. In Java besitzt jedes Objekt genau ein Lock 4. Wenn ein Objekt referenziert wird (Zugriff auf das Objekt selbst, ein Attribut oder eine Methode des Objekts), wird der Lock üblicherweise ignoriert. Nur wenn die 4 Unter einem Lock kann man sich ein Bit vorstellen, das entweder gesetzt oder nicht gesetzt ist

14 Methode auf die zugegriffen wird durch synchronized ausgezeichnet ist, wird der Lock betrachtet. Ist in diesem Fall der Lock von einem anderen Thread bereits gesetzt worden, so wird der aktuelle Thread blockiert und in eine Menge von wartenden Threads eingetragen. Wenn der Lock nicht gesetzt ist, so setzt der aktuelle Thread den Lock und arbeitet die synchronized Methode ab. Beim Verlassen der Methode wird der Lock wieder aufgehoben. Wenn nun die Menge der wartenden Threads nicht leer ist, so wird ein zufälliger Thread bestimmt, der dann den Lock setzt und in den rechenbereiten Zustand überführt wird. Betrachten wir im Folgenden das Erzeuger Verbraucher Problem implementiert in Java. Zunächst die Klasse BoundedBuffer, die den Speicher (Buffer) mit ihren Methoden enter item und remove item (Abbildung 3.20). In den Methoden enter item und remove item werden, wenn der Speicher voll bzw. leer ist jeweils die Methode wait aufgerufen. Die Methode wait ist eine Methode der Klasse Object. Sie hat die Eigenschaften: 1. Der derzeitige Lock wird aufgehoben. 2. Der Thread wird in den blockierten Zustand überführt. 3. Der Thread wird in die Menge der wartenden Threads bezüglich des waits eingefügt 5. Am Ende der beiden Methoden wird jeweils die Methode notify aufgerufen. Auch diese Methode hat die Klasse BoundedBuffer von der Klasse Object geerbt. Die Methode notify hat folgende Eigenschaften: 1. Es wird zufällig ein Prozess aus der Menge der bezüglich wait in diesem Objekt blockiert wurden ausgewählt. 2. Er wird in in die Menge der auf einen Lock wartenden Threads eingefügt. Die Klasse Producer (Abbildung 3.21) ist für die Produktion der Speichereinträge verantwortlich. Es werden Objekte der Klasse NewItem in Abhängigkeit einer int Variablen angelegt. Diese werden dann durch den Aufruf der Methode enter item in den Speicher eingetragen. Die Klasse Consumer (Abbildung 3.22) ist das Gegenstück zu Consumer und funktioniert analog. Bleibt noch eine Klasse, die die Erzeuger Verbraucher Implementierung steuert: BufferServer (Abbildung 3.23). Es werden jeweils die Threads Producer und Consumer gestartet. Aufgabe 1. Implementieren Sie eine Klasse Semaphor in Java. Semaphor soll die Methoden up und down beinhalten. 2. Implementieren sie das Erzeuger Verbraucher Problem mit den im 1. Teil der Aufgabe implementierten Semaphoren. 3. Ändern Sie ihre Erzeuger Verbraucher Implementierung so, dass der wechselseitige Ausschluss statt durch einen binären Semaphor mutex, durch ihre Implementierung der Peterson Lösung realisiert wird. 5 Diese Menge ist eine unterschiedliche Menge zu der Menge der wartenden Threads, die auf einen Lock wartet.

15 public class BoundedBuffer { private static final int BUFFER_SIZE = 5; private int count, in, out; private Object[] buffer; public BoundedBuffer() { count = 0; in = 0; out = 0; buffer = new Object[BUFFER_SIZE]; public synchronized void enter_item(object item) { while (count == BUFFER_SIZE) { try { wait(); catch (InterruptedException e) { ++count; buffer[in] = item; in = (in + 1) % BUFFER_SIZE; notify(); public synchronized Object remove_item() { Object item; while (count == 0) { try { wait(); catch (InterruptedException e) { --count; item = buffer[out]; out = (out + 1) % BUFFER_SIZE; notify(); return item; Abbildung 3.20: Bounded Buffer

16 public class Producer extends Thread { private BoundedBuffer buffer; public Producer(BoundedBuffer b) { buffer = b; public void run () { NewItem n; int i = 0; while (true) { n = new NewItem(i); buffer.enter_item(n); System.out.println("Entered: " + n.getstring()); i++; Abbildung 3.21: Producer public class Consumer extends Thread { private BoundedBuffer buffer; public Consumer(BoundedBuffer b) { buffer = b; public void run () { NewItem n; int i = 0; while (true) { n = (NewItem)buffer.remove_item(); System.out.println("Removed: " + n.getstring()); Abbildung 3.22: Consumer Klassische Synkronisationsprobleme Zum Abschluss des Abschnitts über Prozesssynkronisation wollen wir noch ein klassisches Syncronisationsproblem darstellen.

17 public class BufferServer { public static void main (String[] args) { BoundedBuffer server = new BoundedBuffer(); Producer producerthread = new Producer(server); Consumer consumerthread = new Consumer(server); producerthread.start(); consumerthread.start(); Abbildung 3.23: Steuert die Erzeuger Verbraucher Implementierung Essende Philosophen Dieses Problem wurde von Dijkstra gestellt: Für fünf Philosophen besteht das Leben nur aus abwechselnden Phasen des Essens und des Denkens. Wenn ein Philosoph hungrig wird, versucht er in beliebiger Reihenfolge nacheinander sein linkes und sein rechtes Stäbchen aufzunehmen. Hat er erfolgreich beide Stäbchen aufgenommen, ist er eine Weile, legt dann die Stäbchen wieder ab und setzt das Denken fort. Übersetzt in die Welt der Prozesssynkronisation bildet jeder Philosoph einen Prozess, der nacheinander Abbildung 3.24: Essende Philosophen das linke bzw. das rechte Stäbchen aufnimmt. Angenommen alle Philosophen nehmen zunächst das linke Stäbchen auf. Dann kann keiner mehr sein rechtes Stäbchen aufnehmen. Wir haben einen Deadlock erreicht. Eine Idee dieses Problem zu lösen wäre, dass jeder Philosoph das linke Stäbchen wieder ablegt, wenn das rechte nicht mehr aufgenommen werden kann. Der Philosoph wartet dann eine bestimmte Zeit und versucht es erneut. Nun kann es passieren, dass alle Philosophen gleichzeitig starten. Dann ergibt sich ebenfalls keine Lösung, weil sie dann immer gleichzeitig Stäbchen aufnehmen und wieder hinlegen. Diesen Zustand nennt man Verhungern. Eine mögliche Lösung wäre die Wartezeit zufällig zu wählen. In der Regel wird das zur Lösung führen. Allerdings ist dies eine unsichere Lösung, die bei kritischen Steuerungen, wie Flugzeugen oder Atomkraftwerken sicher nicht angebracht ist. Eine sichere Lösung ist die Benutzung von Hilfsmitteln der Prozesssynkronisation. Wir geben nun eine Lösung mit Monitoren an. Das Array state repräsentiert den Zustand des jeweiligen Philosophen. Das Array besteht aus Bedingungsvaraiblen. Die zugehörigen Prozess werden in der Prozedur pickup blockiert, falls ein Nachbar eines

18 monitor dining-philosphers var state : array [0..4] of (thinking, hungry, eating); var self : array [0..4] of condition; procedure pickup(i : 0..4); state[i] := thinking; test(i); if state[i] <> eating then wait(self[i]) end; (* pickup *) procedure putdown(k : 1..4); state[i] := thinking; test(i+4 mod 5); test(i+1 mod 5); end; (* putdown *) procedure test(k : 0..4); if state[k+4 mod 5] <> eating and state[k] = hungry and state[k+1 mod 5] <> eating then state[k] := eating; signal(self[k]); end (* then *) end; (* test *) (* Monitor Initialisierung *) for i := 0 to 4 do state[i] := thinking; end (* monitor *) Abbildung 3.25: Lösung mit Monitoren für das essende Philosophen Problem hungrigen Philosophen gerade ist. Wenn nun ein Philosoph das Essen beendet (Prozedur putdown) wird überprüft, ob ein Nachbar hungrig ist (blockiert ist). Nach Möglichkeit wird dieser dann aufgeweckt in den essenden Zustand versetzt. Für weitere interessante klassische Syncronisationsprobleme sei auf die Literatur verwiesen [?,?].