Synchronisationsmodul - Prozesse

Transkript

1 Synchronisationsmodul - Prozesse alois.schuette@h-da.de Alois Schütte 26. September / 124

2 Inhaltsverzeichnis Ein Prozess kann als die Abstraktion eines Programms, das von einem Prozessor ausgeführt wird, angesehen werden. Hier wird behandelt, was Prozesse sind inklusive Prozesskommunikation, -synchronisation. 1 Prozessmodell 2 3 IPC Probleme 2 / 124

3 Prozessmodell Prozessmodell 1 Prozessmodell Prozesszustände Abstraktion des Prozessmodells in Java 2 3 IPC Probleme 3 / 124

4 Prozessmodell Prozessmodell Um zu verstehen, wie unterschiedliche Aktivitäten scheinbar gleichzeitig ablaufen, braucht man ein Modell eines sich in Ausführung befindenden Programms. Ein (sequentieller) Prozess ist ein sich in Ausführung befindendes (sequentielles) Programm zusammen mit: dem aktuellen Wert des Programmzähler, den Registerinhalten, den Werten der Variablen und dem Zustand der geöffneten Dateien und Netzverbindungen. Konzeptionell besitzt jeder Prozess seinen eigenen Prozessor - in der Praxis wird aber immer der reale Prozessor zwischen den Prozessen hinund hergeschaltet. 4 / 124

5 Prozessmodell Sichtweisen Beim Mehrprogrammbetrieb mit 4 Programmen (A-D) ergeben sich damit folgende Sichtweisen: 5 / 124

6 Prozessmodell Prozess-Hierarchie Ein Betriebssystem mit einen solchen Prozessmodell muss in der Lage sein, dass von einem (Initial-) Programm andere Prozesse erzeugt werden können. In Unix dient dazu der fork-systemaufruf. Beim Hochfahren des Betriebssystems werden dann alle erforderlichen Prozesse erzeugt für Systemdienste, wie Scheduler, Dateidienst, Terminaldienst,... 6 / 124

7 Prozessmodell Prozesszustände Prozesszustände Eine Aufgabe des Betriebssystems ist das Multiplexen des physischen Prozessors. Diese Aufgabe übernimmt der Scheduler zusammen mit dem Dispatcher. Prozesse können sich in verschiedenen Zustände befinden. 1 rechnend (running) der Prozessor ist dem Prozess zugeteilt 2 bereit (ready) der Prozess ist ausführbar, aber ein anderer Prozess ist gerade rechnend 3 blockiert (waiting) der Prozess kann nicht ausgeführt werden, da er auf ein externes Ereignis wartet (z.b. Benutzer hat Taste auf Tastatur gedrückt) Diese Zuständen bilden eine Entscheidungsgrundlage für die Auswahl eines geeigneten Kandidaten bei einem Prozesswechsel. 7 / 124

8 Prozessmodell Prozesszustände Zustandsübergänge 1 Prozess wartet auf externes Ereignis 2 Scheduler wählt anderen Prozess aus, da die Zeitscheibe des Prozesses abgelaufen ist 3 Scheduler wählt diesen Prozess aus 4 externes Ereignis ist eingetreten 5 ein neuer Prozess wird erzeugt 6 der Prozess terminiert 6 rechnend blockiert bereit 4 5 Die Zustandsübergänge werden vom Dispatcher durchgeführt, die Auswahl eines rechenbereiten Prozesses übernimmt der Scheduler. 8 / 124

9 Prozessmodell Prozesszustände Modell für Prozesssystem Damit ergibt sich ein Modell für ein Prozesssystem, bei dem die unterste Schicht die Unterbrechungen behandelt und das Scheduling der Prozesse inklusive Erzeugung und Abbrechen von Prozessen erledigt; alle anderen Prozesse befinden sich auf gleicher Ebene darüber und haben einen sequentiellen Kontrollfluss. Somit gibt es stets einen Wechsel von Aktivitäten eines (User-)Prozesses und des Kerns. Prozesse n User-Modus Kernel-Modus Dispatcher / Scheduler 9 / 124

10 Prozessmodell Abstraktion des Prozessmodells in Java Abstraktion des Prozessmodells in Java Um Eigenschaften und Probleme mit Prozessen zeigen zu können, werden Algorithmen in der Vorlesung in Java (oder C) beschrieben. Betrachtet werden Java-Threads als Abstraktion von Prozessen eines Rechners: Java Prozess Threads Rechner Prozesse gemeinsamer Speicher Speicher Deshalb wird hier zunächst gezeigt, wie in Java Threads erzeugt werden können. 10 / 124

11 Prozessmodell Abstraktion des Prozessmodells in Java 2 Threads in einem Prozess Stack Adreßraum des Java-Prozesses 2 Ausführungsstränge (Threads) der Kode von T1 und T2 ist im Textsegment T1 und T2 greifen auf den selben Speicher (Data, Heap) zu. T1 T2 Heap Data Text 11 / 124

12 Prozessmodell Abstraktion des Prozessmodells in Java Erzeugen und Starten vonjava-threads Beim Start eines Java Programms wird ein Prozess erzeugt, der einen Thread enthält, der die Methode main der angegebenen Klasse ausführt. Der Code weiterer Threads muss in einer Methode mit Namen run realisiert werden. public void run () { // Code wird in eigenem Thread ausgeführt } Ein Programm, das Threads erzeugt, erbt von der Klasse Thread und überschreibt die Methode run() (auf Interfaces wird später eingegangen): 12 / 124

13 Prozessmodell Abstraktion des Prozessmodells in Java Hello World MyThread.java 1 public class MyThread extends Thread { 2 public void run () { 3 System. out. println (" Hello World "); 4 } 6 public static void main ( String [] args ) { 7 MyThread t = new MyThread (); 8 t. start (); 9 } 10 } Die Methode start() ist in der Klasse thread definiert und startet den Thread, genauer die Methode run(). Somit wird zunächst ein Thread erzeugt (new...), dann durch start die Methode run aufgerufen und somit Hello World ausgegeben. 13 / 124

14 Prozessmodell Abstraktion des Prozessmodells in Java mehrere Threads Werden mehrere Thread erzeugt, so ist die Ausführungsreihenfolge nicht vorhersehbar! Loop1.java 1 public class Loop1 extends Thread { 2 private String myname ; 3 public Loop1 ( String name ) { 4 myname = name ; 5 } 7 public void run () { 8 for ( int i = 1; i <= 10000; i ++) { 9 System. out. println ( myname + " (" + i + ")"); 10 } 11 } 13 public static void main ( String [] args ) { 14 Loop1 t1 = new Loop1 (" Thread 1"); 15 Loop1 t2 = new Loop1 (" Thread 2"); 16 Loop1 t3 = new Loop1 (" Thread 3"); 17 t1. start (); 18 t2. start (); 19 t3. start (); 20 } 21 } 14 / 124

15 Prozessmodell Abstraktion des Prozessmodells in Java Threads in komplexen Klassenhierarchien Wenn sich die Methode run() in einer Klasse befinden soll, die selbst bereits aus einer anderen Klasse abgeleitet ist, so kann diese Klasse nicht zusätzlich von Thread abgeleitet werden (Java unterstützt keine Mehrfachvererbung). In diesem Fall kann das Interface Runnable des Package java.lang verwendet werden. MyRunnableThread.java 1 public class MyRunnableThread implements Runnable { 2 public void run () { 3 System. out. println (" Hello World "); 4 } 5 public static void main ( String [] args ) { 6 MyRunnableThread runner = new MyRunnableThread (); 7 Thread t = new Thread ( runner ); 8 t. start (); 9 } 10 } 15 / 124

16 Prozessmodell Abstraktion des Prozessmodells in Java Threadtermination Ein Thread terminiert, wenn seine run()-methode (bzw. die Methode main() im Fall des Ursprungs-Thread) beendet ist. Sind alle von einem Prozess initiierten Threads beendet, so terminiert der Prozess (falls es kein Dämon ist). Die Klasse Thread stellt eine Methode isalive bereit, mit der abfragbar ist, ob ein Thread noch lebt (schon gestartet und noch nicht terminiert ist). Damit könnte aktives Warten etwa wie folgt programmiert werden: 1 // MyThread sei aus Thread abgeleitet 2 MyThread t = new mythread (); 3 t. start (); 4 while (t. isalive ()) 5 ; 6 // hier ist jetzt : t. isalive == false, der Thread t ist terminiert Man sollte es so aber nie tun, da aktives Warten sehr rechenintensiv ist. wieso? 16 / 124

17 Prozessmodell Abstraktion des Prozessmodells in Java Warten bis Thread beendet ist Wenn in einer Anwendung auf das Ende eines Thread gewartet werden muss, etwa um die Rechenergebnisse des Thread weiterzuverarbeiten, kann die Methode join der Klasse Thread benutzt werden. Der Thread wird blockiert, bis der Thread, auf den man wartet, beendet ist. 1 // MyThread sei aus Thread abgeleitet 2 MyThread t = new mythread (); 3 t. start (); 4 t. join (); // blockiert, bis t beendet ist. 5 // auch hier jetzt : t. isalive == false, der Thread t ist terminiert wieso ist das besser? 17 / 124

18 Prozessmodell Abstraktion des Prozessmodells in Java Verwendung von join zum Abfragen von Ergebnissen Das folgende Beispiel verwendet Threads, um ein grosses Feld von Boolean zu analysieren, indem mehrere Threads parallel arbeiten, wobei je Thread ein Bereich des Feldes bearbeitet wird T1:1 T2:3 T3:0 T4:4 main: 8 18 / 124

19 Prozessmodell Abstraktion des Prozessmodells in Java 1 class Service implements Runnable { 2 private boolean [] array ; 3 private int start ; 4 private int end ; 5 private int result ; 7 public Service ( boolean [] array, int start, int end ) { 8 this. array = array ; 9 this. start = start ; 10 this. end = end ; 11 } 13 public int getresult () { 14 return result ; 15 } 17 public void run () { 18 for ( int i = start ; i <= end ; i ++) { 19 if( array [i]) 20 result ++; 21 } 22 } 23 } 19 / 124

20 Prozessmodell Abstraktion des Prozessmodells in Java 1 public class AsynchRequest { 2 private static final int ARRAY_SIZE = ; 3 private static final int NUMBER_OF_SERVERS = 100; 5 public static void main ( String [] args ) { 6 // start time 7 long starttime = System. currenttimemillis (); 9 // array creation, init with random boolean values 10 boolean [] array = new boolean [ ARRAY_SIZE ]; 11 for ( int i = 0; i < ARRAY_SIZE ; i++) { 12 if( Math. random () < 0.1) 13 array [i] = true ; 14 else 15 array [i] = false ; 16 } 18 // creation of array for service objects and threads 19 Service [] service = new Service [ NUMBER_OF_SERVERS ]; 20 Thread [] serverthread = new Thread [ NUMBER_OF_SERVERS ]; 22 int start = 0; 23 int end ; 24 int howmany = ARRAY_SIZE / NUMBER_OF_SERVERS ; 20 / 124

21 Prozessmodell Abstraktion des Prozessmodells in Java 1 // creation of services and threads 2 for ( int i = 0; i < NUMBER_OF_SERVERS ; i++) { 3 end = start + howmany - 1; 4 service [i] = new Service ( array, start, end ); 5 serverthread [i] = new Thread ( service [i ]); 6 serverthread [i]. start (); // start thread i 7 start = end + 1; 8 } 10 // wait for termination of each service ( thread ) 11 try { 12 for ( int i = 0; i < NUMBER_OF_SERVERS ; i++) 13 serverthread [i]. join (); 14 } catch ( InterruptedException e) {} 16 // accumulate service results 17 int result = 0; 18 for ( int i = 0; i < NUMBER_OF_SERVERS ; i++) { 19 result += service [i]. getresult (); 20 } 21 / 124

22 Prozessmodell Abstraktion des Prozessmodells in Java 1 // end time 2 long endtime = System. currenttimemillis (); 3 float time = ( endtime - starttime ) / f; 4 System. out. println (" computation time : " + time ); 6 // print result 7 System. out. println (" result : " + result ); 8 } // main 9 } $ java AsynchRequest Rechenzeit : 0.11 Ergebnis : 9953 $ 22 / 124

23 Prozessmodell Abstraktion des Prozessmodells in Java zum Üben für zu Hause 1 Testen des Verhaltens, wenn NUMBER OF SERVERS mit 1, 10, 100, 1.000, und gesetzt wird und Erklärung des Ergebnisses. 2 Ändern der Metode run() und Test und Erklärung der Auswirkung gegenüber dem Verhalten von 1. public void run () { for ( int i = start ; i <= end ; i ++) { if( array [i]) result ++; } try { Thread. sleep (100); } catch ( InterruptedException e) {} } 23 / 124

24 Prozessmodell Abstraktion des Prozessmodells in Java Beenden von Threads per Programm Die Klasse Thread besitzt die Methode stop(), zum Abbruch von Threads. Die Verwendung ist aber problematisch, da ein inkonsistenter Zustand erreicht werden kann. Dies ist der Fall, wenn der Thread gerade eine synchronized()-methode (später) ausführt und den Zustand eines Objektes verändert und dies aber nicht bis zum Schluss durchführen kann (wegen Stop()). Durch Stopp werden alle Sperren aufgehoben, der Thread konnte aber nicht fertig werden. Eine Abhandlung zum Stoppen von Threads kann nachgelesen werden in threadprimitivedeprecation oder HowToStopThreads. Wir werden später nochmals darauf zurückkommen. 24 / 124

25 1 Prozessmodell 2 Probleme des gemeinsamen Zugriffs Kritischer Bereich Lösungsansätze in Java Semaphore Nachrichtenaustausch 3 IPC Probleme 25 / 124

26 Betriebssysteme stellen unterschiedliche Mechanismen zur Verfügung, mit denen zwei Prozesse kommunizieren können: beide Prozesse können sich den Arbeitsspeicher teilen, oder gemeinsamer Speicher ist nicht verfügbar, es werden externe Medien, wie Dateien verwendet, auf die gemeinsam zugegriffen werden kann. Die Probleme sind aber unabhängig davon, welcher der beiden Mechanismen verwendet wird. Im folgenden werden die Probleme und Lösungen für den Zugriff auf gemeinsam verwendete Ressourcen gezeigt. 26 / 124

27 Probleme des gemeinsamen Zugriffs Probleme des gemeinsamen Zugriffs Wenn mehrere Threads in Java gemeinsam auf Daten zugreifen, müssen sich die einzelnen Threads verständigen, wer wann was machen darf. Dazu werden die Möglichkeiten, die Java bietet, am Beispiel von Buchungen eines Bankkontos gezeigt. Eine Bank wird modelliert durch 4 Klassen: Die Klasse Konto repräsentiert ein Konto mit dem Attribut kontostand und den Methoden zum Setzen und Abfragen des aktuellen Kontostandes. BankOperation.java 1 class Konto { 2 private float kontostand ; 3 public void setzen ( float betrag ) { 4 kontostand = betrag ; 5 } 6 public float abfragen () { 7 return kontostand ; 8 } 9 } 27 / 124

28 Probleme des gemeinsamen Zugriffs Bank Die Klasse Bank hat als Attribut ein Feld von Referenzen auf Konto-Objekte (Konten). Die Methode buchen implementiert einen Buchungsvorgang auf ein Konto. 1 class Bank { 2 private Konto [] konten ; 4 public Bank () { 5 konten = new Konto [100]; 6 for ( int i = 0; i < konten. length ; i++) { 7 konten [i] = new Konto (); 8 } 10 public void buchen ( int kontonr, float betrag ) { 11 float alterstand = konten [ kontonr ]. abfragen (); 12 float neuerstand = alterstand + betrag ; 13 konten [ kontonr ]. setzen ( neuerstand ); 14 } 15 } 28 / 124

29 Probleme des gemeinsamen Zugriffs Bankangestellte Die Klasse Bankangestellte ist aus der Klasse Thread abgeleitet. Der Name der Angestellten wird der Name des Thread, da mehrere Bankangestellte (Threads) für die Bank arbeiten können sollen. Buchungen werden in der run-methode durch Zufallszahlen erzeugt. 1 class BankAngestellte extends Thread { 2 private Bank bank ; 3 public BankAngestellte ( String name, Bank bank ) { 4 super ( name ); this. bank = bank ; 5 start (); 6 } 8 public void run () { 9 for ( int i = 0; i < 10000; i ++) { 10 /* Kontonummer einlesen ; simuliert durch Wahl einer 11 Zufallszahl zwischen 0 und 99 */ 12 int kontonr = ( int )( Math. random ()*100); 13 /* Überweisungsbetrag einlesen ; simuliert durch Wahl einer 14 Zufallszahl zwischen -500 und +499 */ 15 float betrag = ( int )( Math. random ()*1000) - 500; 16 bank. buchen ( kontonr, betrag ); 17 } 18 } 19 } 29 / 124

30 Probleme des gemeinsamen Zugriffs Bankbetrieb In der Klasse Bankbetrieb wird eine Bank mit 2 Bankangestellten simuliert. Die Bankangestellten fangen an zu Arbeiten, wenn die Objekte erzeugt werden (durch new und dann die Methode start im Konstruktor von Bankangestellte). 1 public class Bankbetrieb { 2 public static void main ( String [] args ) { 3 Bank sparkasse = new Bank (); 4 BankAngestellte müller = 5 new BankAngestellte (" Andrea Müller ", sparkasse ); 6 BankAngestellte schmitt = 7 new BankAngestellte (" Petra Schmitt ", sparkasse ); 8 } 9 } sparkasse ist das gemeinsam verwendete Objekt! 30 / 124

31 Probleme des gemeinsamen Zugriffs verlorene Buchungen Bei dieser Bank können aber Buchungen verloren gehen! am Rechner Jede der 2 Bankangestellten bebucht das Konto 1 jeweils 1000 mal mit jeweils 1 EUR Also muss das Konto 1 am Ende des Tages einen Kontostand von 2000 EUR aufweisen! Dieses Problem tritt immer auf, wenn mehrere Threads auf ein gemeinsam nutzbares Objekt (hier das Feld Konto der Klasse Bank) zugreifen und es keine Schutzmechanismen gibt. 31 / 124

32 Probleme des gemeinsamen Zugriffs Verdeutlichung Gehen wir von folgender Situation aus: Andrea Müller bucht -100 EUR auf Konto 47, es sollen also 100 EUR abgebucht werden. Der Kontostand sein 0. Petra Schmitt führt auch Buchungen für Konto 47 aus, es sollen 1000 EUR gutgeschrieben werden. Thread Andrea Müller: 1 public void buchen ( int kontonr =47, float betrag = -100) { Konten[47]=0 2 float alterstand = konten [ kontonr ]. abfragen (); alterstand=0 3 -> Umschalten auf Thread Petra Schmitt 4 float neuerstand = alterstand + betrag ; 5 konten [ kontonr ]. setzen ( neuerstand ); 6 } Thread Petra Schmitt: 1 public void buchen ( int kontonr =47, float betrag =1000) { Konten[47]=0 2 float alterstand = konten [ kontonr ]. abfragen (); alterstand=0 3 float neuerstand = alterstand + betrag ; neuerstand= konten [ kontonr ]. setzen ( neuerstand ); Konten[47]= } 6 -> Umschalten auf Thread Andrea Müller 32 / 124

33 Probleme des gemeinsamen Zugriffs Verdeutlichung Thread Andrea Müller: 1 public void buchen ( int kontonr =47, float betrag = -100) { Konten[47]=0 2 float alterstand = konten [ kontonr ]. abfragen (); alterstand=0 3 -> Weiter nach Unterbrechung 4 float neuerstand = alterstand + betrag ; neuerstand= konten [ kontonr ]. setzen ( neuerstand ); Konten[47]= } Nun ist die Gutschrift, die Petra Schmitt gebucht hat verloren! Der aktuelle Kontostand ist -100 anstatt Die Ursache des Problems ist, dass eine Buchung aus mehreren Java Anweisungen besteht und zwischen diesen Anweisungen zwischen Threads umgeschaltet werden kann. 33 / 124

34 Kritischer Bereich Kritischer Bereich Das gezeigte Problem der verlorenen Buchungen kann auch abstrakt formuliert werden. Der Teil eines Programms, in dem auf gemeinsame Ressourcen zugegriffen wird, wird kritischer Bereich genannt. Zeitkritische Abläufe (wie das Buchen des selben Kontos) können vermieden werden, wenn sich zu keinem Zeitpunkt zwei Prozesse in ihrem kritischen Bereich befinden. Im folgenden werden Lösungsversuche (nicht korrekte) diskutiert. 34 / 124

35 Kritischer Bereich Lösungsversuch 1 (nur eine Anweisung) In der Klasse Bank wird das Buchen durch eine Java Anweisung realisiert: 1 class Konto { 2 private float kontostand ; 3 public void buchen ( float betrag ) { 4 kontostand += betrag ; nur eine Anweisung 5 } also kein Umschalten möglich 6 } 8 class Bank { 9 private Konto [] konten ; 11 public Bank () { 12 konten = new Konto [100]; 13 for ( int i = 0; i < konten. length ; i++) { 14 konten [i] = new Konto (); 15 } 17 public void buchen ( int kontonr, float betrag ) { 18 konten [ kontonr ]. buchen ( betrag ); 19 } 20 } Wie beurteilen Sie den Ansatz? 35 / 124

36 Kritischer Bereich Lösungsversuch 1 Dies ist keine Lösung, denn Java-Programme werden in Bytekode übersetzt. Dabei wird aus der einer Java-Anweisung 1 kontostand += betrag ; schematisch etwa folgender Code: 1 LOAD ( kontostand ); 2 ADD ( betrag ); 3 STORE ( kontostand ); Die JVM führt also 3 Anweisungen aus, wobei dann auch wieder dazwischen umgeschaltet werden kann. 36 / 124

37 Kritischer Bereich Lösungsversuch 2 (Sperrvariable) Die Idee ist die Verwendung von Sperrvariablen: Zu einem Zeitpunkt darf nur eine Angestellte eine Buchung ausführen. Erst wenn die Buchung abgeschlossen ist, darf eine andere Angestellte buchen. Dies ist offensichtlich eine korrekte Lösung: der kritische Bereich wird zu einem Zeitpunkt nur einmal betreten. Ein Implementierungsversuch ist: Alle Klassen entsprechen den des Ausgangsbeispiels; nur die Klasse Bank wird wie folgt geändert. 37 / 124

38 Kritischer Bereich 1 class Bank { 2 private Konto [] konten ; 3 private boolean gesperrt ; 5 public Bank () { 6 konten = new Konto [100]; 7 for ( int i = 0; i < konten. length ; i++) { 8 konten [i] = new Konto (); 9 } 10 gesperrt = false ; 11 } 13 public void buchen ( int kontonr, float betrag ) { 14 while ( gesperrt ); 15 gesperrt = true ; 16 float alterstand = konten [ kontonr ]. abfragen (); 17 float neuerstand = alterstand + betrag ; 18 konten [ kontonr ]. setzen ( neuerstand ); 19 gesperrt = false ; 20 } 21 } Die 3 Anweisungen zum Buchen können nur ausgeführt werden, falls die Bank momentan nicht gesperrt ist. Ist die Bank gesperrt, wartet der Thread, bis sie durch den sperrenden Thread wieder entsperrt wird. Wie bewerten Sie diese Lösung? 38 / 124

39 Kritischer Bereich Diese Realisierung ist auf den ersten Blick korrekt; es gibt aber folgende Probleme: 1 Paralleles Arbeiten wird unmöglich: parallel könnten unterschiedlichen Konten bebucht werden dies ist hier ausgeschlossen. 2 Durch das aktive Warten (while (gesperrt) ;) wird kostbare Rechenzeit aufgewendet, um nichts zu tun. 3 Die Realisierung ist nicht korrekt. Das aktive Warten ist keine unteilbare Aktion, denn der Bytekode sieht etwa wie folgt aus: while ( gesperrt ); 1: LOAD ( gesperrt ); 2: JUMPTRUE 1; gesperrt = true ; 3: LOADNUM ( TRUE ); 4: STORE ( geperrt ) Wenn hierbei zwischen Befehl 1 und 2 umgeschaltet wird und die Sperre frei ist (geperrt=false) so kann ein wartender Thread buchen. Um eine korrekte Lösung in Java zu programmieren, sind in Java Sprachelemente zur Synchronisation verfügbar. 39 / 124

40 Lösungsansätze in Java Lösungsansätze in Java Die erste korrekte (aber ineffiziente) Lösung für die Probleme 2 (aktives Warten) und 3 (verlorene Buchungen) nutzt die Möglichkeit von Java, Methoden als synchronized zu kennzeichnen. Dazu wird einfach die Klasse buchen mit dem Attribut synchronized versehen ansonsten ändert sich nichts. 1 class Bank { 2 private Konto [] konten ; 4 public Bank () { 5 konten = new Konto [100]; 6 for ( int i = 0; i < konten. length ; i++) { 7 konten [i] = new Konto (); 8 } 10 public synchronized void buchen ( int kontonr, float betrag ) { 11 float alterstand = konten [ kontonr ]. abfragen (); 12 float neuerstand = alterstand + betrag ; 13 konten [ kontonr ]. setzen ( neuerstand ); 14 } 15 } 40 / 124

41 Lösungsansätze in Java synchronized Die Java-Superklasse Object beinhaltet als Eigenschaft eine Sperre. Da jede Klasse von Object abgeleitet ist, besitzen alle Klassen diese Eigenschaft. Das Sperren gehorcht dem acquire-release Protokoll : Die Sperre wird gesetzt (acquire), beim Betreten einer synchronized-methode (oder synchronized Blocks) und entfernt (release) bei Verlassen des Blocks (auch bei Verlassen durch eine Exception). 41 / 124

42 Lösungsansätze in Java acquire release Protokoll Wird eine Methode einer Klasse mit synchronized gekennzeichnet, so muss diese Sperre zuerst gesetzt werden, bevor die Methode ausgeführt wird, hier versucht von Thread B. Hat ein anderer Thread A die Sperre bereits gesetzt (seine Methode ist in Ausführung), so wird der aufrufende Thread B blockiert. Das Blockieren ist aber nicht durch aktives Warten realisiert, sondern der Thread B wird beim Thread-Umschalten nicht mehr berücksichtigt. Wenn die Methode des Thread A beendet ist, wird die Sperre entfernt und der Thread B wird wieder beim Scheduling wieder berücksichtigt. Tread A Sperre Object Thread B 42 / 124

43 Lösungsansätze in Java Somit ist das Problem 2 und 3 gelöst. Diese Lösung ist aber ineffizient (Problem 1), da die ganze Bank gesperrt wird, obwohl doch nur Probleme auftauchen, wenn auf das selbe Konto gebucht wird. Dies wird im Beispielprogramm umgesetzt,indem die Java-Eigenschaft, Blöcke als synchronized zu kennzeichnen, verwendet wird. 1 class Bank { public void buchen ( int kontonr, float betrag ) { 5 synchronized(konten[kontonr]) { 6 float alterstand = konten [ kontonr ]. abfragen (); 7 float neuerstand = alterstand + betrag ; 8 konten [ kontonr ]. setzen ( neuerstand ); 9 } 10 } 11 } Ein Block (...) wird dabei mit dem Schlüsselwort synchronized versehen und das Objekt, auf das sich die Sperre bezieht wird danach angegeben. 43 / 124

44 Lösungsansätze in Java Verwendung von synchronized Wenn alle Threads nur lesend auf ein Objekt zugreifen, ist keine Synchronisation erforderlich hier würde durch synchronized ein unnötiger Rechenaufwand erzeugt werden (Setzen und Lösen der Sperre). Generell gilt folgende Regel: Wenn von mehreren Threads auf ein Objekt zugegriffen wird, wobei mindestens ein Thread den Zustand (repräsentiert durch die Werte der Attribute) des Objekts ändert, dann müssen alle Methoden, die auf den Zustand lesend oder schreibend zugreifen, mit synchronized gekennzeichnet werden. 44 / 124

45 Lösungsansätze in Java Test, ob eine Sperre gesetzt ist Der Test, ob eine Sperre gesetzt ist, ist durch holdslock möglich: Main.java 1 public class Main { 2 public static void main ( String [] argv ) throws Exception { 3 Object o = new Object (); 5 System. out. println ( Thread. holdslock (o )); 6 synchronized (o) { 7 System. out. println ( Thread. holdslock (o )); 8 } 9 } 10 } 45 / 124

46 Lösungsansätze in Java Hörsaalübung Welche Ausgabe erzeugt das Programm? Test.java 1 class Even { 2 private int n = 0; 3 public int next () { // POST : next is always even 4 ++n; 5 try { Thread. sleep (( long )( Math. random ()*10)); 6 } catch ( InterruptedException e) { } 7 ++n; 8 return n; 9 } 10 } 11 public class Test extends Thread { 12 private Even e; 13 public Test ( Even e) { this.e = e;} 14 public void run () { 15 for ( int i = 1 ; i <= 1000; i ++) { 16 System. out. println ( getname ()+ ": " + e. next ()); 17 } 18 } 19 public static void main ( String [] args ) { 20 Even e = new Even (); 21 Test t1 = new Test (e); t1. start (); 22 } 23 } 46 / 124

47 Lösungsansätze in Java Hörsaalübung Welche Ausgabe erzeugt das Programm? Test1.java 1 class Even { } 4 public class Test1 extends Thread { 5 private Even e; 6 public Test1 ( Even e) { 7 this.e = e; 8 } 9 public void run () { 10 for ( int i = 1 ; i <= 1000; i ++) { 11 System. out. println ( getname ()+ ": " + e. next ()); 12 } 13 } 14 public static void main ( String [] args ) { 15 Even e = new Even (); 16 Test1 t1 = new Test1 (e); 17 Test1 t2 = new Test1 (e); 18 t1. start (); 19 t2. start (); 20 } 21 } Wie ist das Programm Test1.java abzuändern, so dass die Ausgabe der Intuition der Verwendung der Klasse Even entspricht? 47 / 124

48 Lösungsansätze in Java wait und notify Werden Objekte von mehreren Threads benutzt und dabei deren Zustände verändert, dann gewährleisten synchronized-methoden, dass ein Thread immer einen konsistenten Zustand eines Objektes vorfindet. In vielen Anwendungssituationen ist es erforderlich, dass eine Methode nur dann ausgeführt wird, wenn zusätzlich zum konsistenten Zustand weitere anwendungsspezifische Bedingungen erfüllt sind. 48 / 124

49 Lösungsansätze in Java Beispiel Parkhaus Ein Parkhaus wird modelliert, indem der Zustand durch die aktuell noch freie Parkplätze beschrieben wird und Autos durch Threads mit Methoden Einfahren (enter()) und Ausfahren (leave()) realisiert sind. Beim Einfahren vermindert sich die Anzahl der freien Plätze um 1; beim Ausfahren eines Autos wird sie um 1 erhöht. Die freien Plätze können nicht erhöht werden, wenn das Parkhaus voll ist (freie Plätze == 0). Da ein Parkhaus von mehreren Autos (Threads) benutzt wird und der Zustand (=freie Plätze) durch ein Auto verändert wird, müssen die Methoden enter() und leave() synchronized sein. Zunächst werden zwei vergebliche Versuche, das Problem freie Plätze zu lösen gezeigt, dann eine korrekte Implementierung. 49 / 124

50 Lösungsansätze in Java unkorrekter Versuch ParkingGarageOperation.java 1 class ParkingGarage { 2 private int places ; 3 public ParkingGarage ( int places ) { 4 if ( places < 0) places = 0; this. places = places ; 5 } 6 public synchronized void enter () { // enter parking garage 7 while ( places == 0) ; aktives Warten 8 places - -; 9 } 10 public synchronized void leave () { // leave parking garage 11 places ++; 12 } 13 } Diese Lösung hat zwei Probleme: 1 Aktives Warten führt zu schlechter Performance. 50 / 124

51 Lösungsansätze in Java unkorrekter Versuch ParkingGarageOperation.java 1 class ParkingGarage { 2 private int places ; 3 public ParkingGarage ( int places ) { 4 if ( places < 0) places = 0; this. places = places ; 5 } 6 public synchronized void enter () { // enter parking garage 7 while ( places == 0) ; aktives Warten 8 places - -; 9 } 10 public synchronized void leave () { // leave parking garage 11 places ++; 12 } 13 } Diese Lösung hat zwei Probleme: 1 Aktives Warten führt zu schlechter Performance. 2 Die Lösung arbeitet nicht korrekt, wenn ein Parkhaus einmal voll geworden ist. Wenn ein Auto in ein volles Parkhaus einfahren will (Aufruf Methode enter), dann kann das Parkhaus nicht mehr benutzt werden, weil der Thread wegen synchronized und der while-schleife die Sperre nie mehr freigibt, da kein anderes Auto ausfahren kann (wegen der Sperre). 50 / 124

52 Lösungsansätze in Java unkorrekter Versuch ParkingGarageOperation.java 1 class ParkingGarage { 2 private int places ; 3 public ParkingGarage ( int places ) { 4 if ( places < 0) places = 0; this. places = places ; 5 } 6 public synchronized void enter () { // enter parking garage 7 while ( places == 0) ; aktives Warten 8 places - -; 9 } 10 public synchronized void leave () { // leave parking garage 11 places ++; 12 } 13 } Diese Lösung hat zwei Probleme: 1 Aktives Warten führt zu schlechter Performance. 2 Die Lösung arbeitet nicht korrekt, wenn ein Parkhaus einmal voll geworden ist. Wenn ein Auto in ein volles Parkhaus einfahren will (Aufruf Methode enter), dann kann das Parkhaus nicht mehr benutzt werden, weil der Thread wegen synchronized und der while-schleife die Sperre nie mehr freigibt, da kein anderes Auto ausfahren kann (wegen der Sperre). 50 / 124

53 Lösungsansätze in Java Korrekte Lösung ohne aktives Warten Das aktive Warten auf einen freien Platz ist weder im gesperrten Zustand des Parkhaus-Objektes noch im nicht gesperrten Zustand korrekt. Durch die Methoden wait() und notify() der Klasse Objekt kann das Problem gelöst werden. public class Object {... public final void wait () throws InterruptedException {...} public final void notify () {...} } Diese beiden Methoden müssen auf ein Objekt angewendet werden, das durch synchronized gesperrt ist, ansonsten tritt die Ausnahme IllegalMonitorStateException auf. 51 / 124

54 Lösungsansätze in Java wait, notify, notifyall Ein wait bewirkt die folgenden Aktionen: 1 Der laufende Thread blockiert. 2 Wenn der laufende Thread unterbrochen wurde, wird die Ausnahme InterruptedException erzeugt. 3 Die JVM fügt den laufenden Thread in eine Menge (Waitingset) ein, die mit dem Objekt assoziiert ist. 4 Der synchronization Lock für das Objekt wird freigegeben (released), alle anderen Locks bleiben erhalten. 52 / 124

55 Lösungsansätze in Java wait, notify, notifyall Ein notify bewirkt die folgenden Aktionen: 1 Ein zufälliger Thread t wird aus dem Waitingset des Objektes ausgewählt. 2 t muss den Lock des Objektes wieder erhalten, d.h. Er blockiert solange, bis der Thread der notify aufgerufen hat, den Lock besitzt oder bis ein anderer Thread, der den Lock hält, ihn freigegeben hat. 3 t wird nach erhalten des Lock nach seinem wait weitermachen. Ein notifyall arbeitet genauso, nur dass alle Threads im Waitingset ausgewählt werden (Achtung: nur einer kann aber weitermachen, da die anderen ja auf den Erhalt des Lock warten. sind. 53 / 124

56 Lösungsansätze in Java wait, notify, notifyall 54 / 124

57 Lösungsansätze in Java wait, notify, notifyall 55 / 124

58 Lösungsansätze in Java wait, notify, notifyall 56 / 124

59 Lösungsansätze in Java wait, notify, notifyall 57 / 124

60 Lösungsansätze in Java wait, notify, notifyall 58 / 124

61 Lösungsansätze in Java Parkhaus mit korrekter Lösung ParkingGarageOperation.java 1 class ParkingGarage { 2 private int places ; 4 public ParkingGarage ( int places ) { 5 if ( places < 0) 6 places = 0; 7 this. places = places ; 8 } 10 public synchronized void enter () { // enter parking garage 11 while ( places == 0) { 12 try { 13 wait (); 14 } catch ( InterruptedException e) {} 15 } 16 places - -; 17 } 19 public synchronized void leave () { // leave parking garage 20 places ++; 21 notify (); 22 } 23 } 59 / 124

62 Lösungsansätze in Java Parkhaus mit korrekter Lösung 1 class Car extends Thread { 2 private ParkingGarage parkinggarage ; 4 public Car ( String name, ParkingGarage p) { 5 super ( name ); 6 this. parkinggarage = p; 7 start (); 8 } 10 public void run () { 11 while ( true ) { 12 try { 13 sleep (( int )( Math. random () * 10000)); // drive before parking 14 } catch ( InterruptedException e) {} 15 parkinggarage. enter (); 16 System. out. println ( getname ()+ ": entered "); 17 try { 18 sleep (( int )( Math. random () * 20000)); // stay into the garage 19 } catch ( InterruptedException e) {} 20 parkinggarage. leave (); 21 System. out. println ( getname ()+ ": left "); 22 } 23 } 24 } 60 / 124

63 Lösungsansätze in Java Parkhaus mit korrekter Lösung 1 public class ParkingGarageOperation { 2 public static void main ( String [] args ){ 3 ParkingGarage parkinggarage = new ParkingGarage (10); 4 for ( int i =1; i <= 40; i ++) { 5 Car c = new Car (" Car "+i, parkinggarage ); 6 } 7 } 8 } 61 / 124

64 Lösungsansätze in Java wait() und notifyall() Probleme mit wait() und notify() entstehen, wenn mehrere Threads in der Warteschlange stehen und der falsche Thread geweckt wird. Dies wird am Erzeuger-Verbraucher Problem demonstriert. 62 / 124

65 Lösungsansätze in Java Erzeuger-Verbraucher Problem Ein Erzeuger (producer) will Werte an einen Verbraucher (consumer) senden. Erzeuger und Verbraucher sind Threads. Die Werte, die ausgetauscht werden, sind in einem Puffer (implementiert durch Integervariable) abgelegt, auf die beide Threads Zugriff haben. Der Erzeuger verwendet die Methode put(), um einen Wert in den Puffer zu schreiben; der Verbraucher kann einen Wert aus dem Puffer durch die Methode get() lesen. 63 / 124

66 Lösungsansätze in Java Erzeuger-Verbraucher Problem Bei der Realisierung darf es nicht vorkommen, dass ein Wert verloren geht, etwa weil der Erzeuger einen neuen Wert in den Puffer schreibt, bevor der Verbraucher den alten Wert gelesen hat. Weiterhin darf ein Wert nicht mehrmals gelesen werden, etwa wenn der Verbraucher erneut liest, bevor der Erzeuger einen neuen Wert geschrieben hat. Diese Problematik soll durch Warten realisiert werden: der Erzeuger wartet mit dem Schreiben, bis der Verbraucher den Wert gelesen hat; der Verbraucher wartet, bis ein neuer Wert in den Puffer geschrieben ist. 64 / 124

67 Lösungsansätze in Java Unkorrekte Lösung Der Puffer wird durch die Klasse Buffer mit den Attributen data (Werte) und available (Flag zeigt an, ob Daten bereit stehen) und den Methoden put() und get() realisiert. 65 / 124

68 Lösungsansätze in Java ProduceConsume.java 1 class Buffer { 2 private boolean available = false ; 3 private int data ; 5 public synchronized void put ( int x) { 6 while ( available ) { 7 try { 8 wait (); 9 } catch ( InterruptedException e) {} 10 } 11 data = x; 12 available = true ; 13 notify (); 14 } 16 public synchronized int get () { 17 while (! available ) { 18 try { 19 wait (); 20 } catch ( InterruptedException e) {} 21 } 22 available = false ; 23 notify (); 24 return data ; 25 } 26 } 66 / 124

69 Lösungsansätze in Java Erzeuger und Verbraucher werden als Threads modelliert, wobei im Konstruktor eine Referenz auf das gemeinsam benutzte Objekt (buffer) übergeben wird. Der Erzeuger produziert 100 Werte, der Verbraucher konsumiert 100 Werte. 1 class Producer extends Thread { 2 private Buffer buffer ; 3 private int start ; 5 public Producer ( Buffer b, int s) { 6 buffer = b; 7 start = s; 8 } 10 public void run () { 11 for ( int i=start ; i<start +100; i++) { 12 buffer. put (i); 13 } 14 } 15 } 67 / 124

70 Lösungsansätze in Java 1 class Consumer extends Thread { 2 private Buffer buffer ; 4 public Consumer ( Buffer b) { 5 buffer = b; 6 } 8 public void run () { 9 for ( int i=0; i <100; i++) { 10 int x = buffer. get (); 11 System. out. println (" got " + x); 12 } 13 } 14 } 68 / 124

71 Lösungsansätze in Java In der Klasse ProduceConsume werden ein Puffer, ein Erzeuger und ein Verbraucher erzeugt und die beiden Threads gestartet. 1 public class ProduceConsume { 2 public static void main ( String [] args ) { 3 Buffer b = new Buffer (); 4 Consumer c = new Consumer (b); 5 Producer p = new Producer (b, 1); 6 c. start (); 7 p. start (); 8 } 9 } Ein Aufruf des Programms bewirkt also: $ java ProduceConsume got 1 got 2 got 3 got 4 got 5... got 100 $ 69 / 124

72 Lösungsansätze in Java Normalerweise hat man die Situation, dass mehrere Erzeuger und mehrere Verbraucher parallel arbeiten: ProduceConsume2.java 1 public class ProduceConsume2 { 2 public static void main ( String [] args ) { 3 Buffer b = new Buffer (); 4 Consumer c1 = new Consumer (b); 5 Consumer c2 = new Consumer (b); 6 Consumer c3 = new Consumer (b); 7 Producer p1 = new Producer (b, 1); 8 Producer p2 = new Producer (b, 101); 9 Producer p3 = new Producer (b, 201); 10 c1. start (); 11 c2. start (); 12 c3. start (); 13 p1. start (); 14 p2. start (); 15 p3. start (); 16 } 17 } 70 / 124

73 Lösungsansätze in Java Ein Lauf des Programms kann folgende Ausgabe bewirken (das hängt von Betriebssystem und Java-Version ab): $ java ProduceConsume2 got 1 got 101 got 2 got 102 got 103 got 201 got 3 got 104 got got 230 got 231 got 33 got 8 got 232 D.h. das Programm bleibt stehen, es passiert nichts mehr; es wird keine neue Ausgabe mehr erzeugt, das Programm ist aber noch nicht beendet. Dieses Verhalten wurde verursacht, da durch notify() der falsche Thread geweckt wurde. 71 / 124

74 Lösungsansätze in Java Ein Lauf des Programms kann folgende Ausgabe bewirken (das hängt von Betriebssystem und Java-Version ab): $ java ProduceConsume2 got 1 got 101 got 2 got 102 got 103 got 201 got 3 got 104 got got 230 got 231 got 33 got 8 got 232 D.h. das Programm bleibt stehen, es passiert nichts mehr; es wird keine neue Ausgabe mehr erzeugt, das Programm ist aber noch nicht beendet. Dieses Verhalten wurde verursacht, da durch notify() der falsche Thread geweckt wurde. 71 / 124

75 Lösungsansätze in Java Erklärung 1 Alle Verbraucher c1, c2 und c3 können laufen. Da der Puffer anfänglich leer ist, werden alle 3 Threads durch wait() innerhalb get() blockiert und in die Warteschlange des Objektes b aufgenommen. 2 Nun startet der Thread p1, der eine Wert in den Puffer b ablegt und einen Verbraucher weckt, nehmen wir an c1. Nun hat die Warteschlange und der Puffer folgendes Aussehen: 72 / 124

76 Lösungsansätze in Java Erklärung 1 Alle Verbraucher c1, c2 und c3 können laufen. Da der Puffer anfänglich leer ist, werden alle 3 Threads durch wait() innerhalb get() blockiert und in die Warteschlange des Objektes b aufgenommen. 2 Nun startet der Thread p1, der eine Wert in den Puffer b ablegt und einen Verbraucher weckt, nehmen wir an c1. Nun hat die Warteschlange und der Puffer folgendes Aussehen: 72 / 124

77 Lösungsansätze in Java Erklärung 3 p1 läuft weiter und will einen Wert in den Puffer schreiben. Da der Puffer voll ist, blockiert er und wird in die Warteschlange eingereiht: 4 Nehmen wir an, es wird auf den Erzeuger p2 umgeschaltet. Da der Puffer immer noch voll ist, wird auch p2 blockiert. Dies wiederholt sich für p3: 73 / 124

78 Lösungsansätze in Java Erklärung 3 p1 läuft weiter und will einen Wert in den Puffer schreiben. Da der Puffer voll ist, blockiert er und wird in die Warteschlange eingereiht: 4 Nehmen wir an, es wird auf den Erzeuger p2 umgeschaltet. Da der Puffer immer noch voll ist, wird auch p2 blockiert. Dies wiederholt sich für p3: 73 / 124

79 Lösungsansätze in Java Erklärung 5 Der einzige Thread, auf den nun noch umgeschaltet werden kann, ist der vorher geweckte Thread c1. Der nimmt nun einen Wert aus dem Puffer. Dann wird einer der Threads in der Warteschlange geweckt, gehen wir von c2 aus. 6 c1 arbeitet weiter und will einen Wert aus dem Puffer nehmen; der Puffer ist leer, also wird c1 blockiert und es steht noch immer kein Wert im Puffer: 74 / 124

80 Lösungsansätze in Java Erklärung 5 Der einzige Thread, auf den nun noch umgeschaltet werden kann, ist der vorher geweckte Thread c1. Der nimmt nun einen Wert aus dem Puffer. Dann wird einer der Threads in der Warteschlange geweckt, gehen wir von c2 aus. 6 c1 arbeitet weiter und will einen Wert aus dem Puffer nehmen; der Puffer ist leer, also wird c1 blockiert und es steht noch immer kein Wert im Puffer: 74 / 124

81 Lösungsansätze in Java Erklärung 7 Der Thread, auf den als einziges umgeschaltet werden kann, ist der Verbraucher c2. Er versucht einen Wert zu lesen, der Puffer ist leer, also blockiert er: Da nun alle Thread in der Warteschlange sind, kann keiner weiter arbeiten, das Programm steht. Schritt 5 hat außerdem gezeigt : der Verbraucher c1 hat einen anderen Verbraucher (c2) geweckt. Dies war der falsche Thread. 75 / 124

82 Lösungsansätze in Java Erklärung 7 Der Thread, auf den als einziges umgeschaltet werden kann, ist der Verbraucher c2. Er versucht einen Wert zu lesen, der Puffer ist leer, also blockiert er: Da nun alle Thread in der Warteschlange sind, kann keiner weiter arbeiten, das Programm steht. Schritt 5 hat außerdem gezeigt : der Verbraucher c1 hat einen anderen Verbraucher (c2) geweckt. Dies war der falsche Thread. Die Lösung des Problems kann nun darin bestehen, dass nicht ein Thread, sondern alle Thread geweckt werden. Da nur einer ausgewählt wird und jeder in einer while-schleife prüft, ob er arbeiten kann, wird das funktionieren. 75 / 124

83 Lösungsansätze in Java Erklärung 7 Der Thread, auf den als einziges umgeschaltet werden kann, ist der Verbraucher c2. Er versucht einen Wert zu lesen, der Puffer ist leer, also blockiert er: Da nun alle Thread in der Warteschlange sind, kann keiner weiter arbeiten, das Programm steht. Schritt 5 hat außerdem gezeigt : der Verbraucher c1 hat einen anderen Verbraucher (c2) geweckt. Dies war der falsche Thread. Die Lösung des Problems kann nun darin bestehen, dass nicht ein Thread, sondern alle Thread geweckt werden. Da nur einer ausgewählt wird und jeder in einer while-schleife prüft, ob er arbeiten kann, wird das funktionieren. 75 / 124

84 Lösungsansätze in Java Korrekte Lösung durch wait-notifyall Die Klasse Objekt besitzt neben dem einfachen notify(), eine weitere Methode zum Aufwecken von Threads: notifyall() weckt alle in der Warteschlange eines Objekts befindlichen Threads. Die korrekte Lösung besteht also darin, notify() durch notifyall() zu ersetzen: ProduceConsume3.java 1 class Buffer {... 2 public synchronized void put ( int x) { 3 while ( available ) { 4 try { wait ();} catch ( InterruptedException e) {} 5 } 6 data = x; 7 available = true ; 8 notifyall (); 9 } 10 public synchronized int get () { 11 while (! available ) { 12 try { wait ();} catch ( InterruptedException e) {} 13 } 14 available = false ; 15 notifyall (); 16 return data ; 17 } 18 } 76 / 124

85 Lösungsansätze in Java Regel für notifyall Prinzipiell kann man immer notify() durch notifyall() ersetzen, die Umkehrung allerdings wäre falsch (wie im letzten Beispiel gesehen). Die Methode notifyall() ist zu verwenden, wenn mindestens eine der beiden folgenden Situationen zutrifft: 1 In der Warteschlange befinden sich Threads, mit unterschiedlichen Wartebedingungen (z.b. Puffer leer, Puffer voll). Dann kann bei Verwendung von notify() der falsche Thread geweckt werden. 2 Durch die Veränderung des Zustands eines Objekts können mehrere Threads weiterlaufen (Wert im Puffer - alle wartenden Verbraucher können arbeiten). 77 / 124

86 Semaphore Semaphore 1965 wurde von Dijkstra das Konzept der Semaphore zur Synchronisation vorgeschlagen. Eine Semaphore ist eine Integervariable, deren Wert Null anzeigt, dass kein Prozess (Thread) mehr zu wecken ist, ein Wert grösser Null bedeutet, dass Wecksignale zu berücksichtigen sind. Als Operationen wurde definiert DOWN (=p) und UP (=v). Down prüft, ob der Semaphore größer als Null ist, dann wird der Wert vermindert; ist der Wert Null, wird der Thread schlafen gelegt und die DOWN-Operation ist beendet. UP inkrementiert den Semaphore. Sowohl UP als auch DOWN sind dabei atomare Operationen, d.h. es ist sichergestellt, dass während der Ausführung der Operation kein anderer Thread auf den Semaphore zugreifen kann. 78 / 124

87 Semaphore Semaphore Implementierung in Java Semaphore.java public class Semaphore { private int value ; public Semaphore ( int init ) { if( init < 0) init = 0; value = init ; } public synchronized void p() { Dijkstra s operation p=down while ( value == 0) { try { wait (); } catch ( InterruptedException e) {} } value - -; } } public synchronized void v() { Dijkstra s operation v=up value ++; notify (); } 79 / 124

88 Semaphore Gegenseitiger Ausschluss mit Semaphoren Gegenseitiger Ausschluss bezeichnet eine Situation, in der ein bestimmtes Programmstück zu einer Zeit von höchstens einem Thread ausgeführt werden darf. In Java kann dazu eine synchronized Methode verwendet werden: auf ein Objekt kann dadurch zu einem Zeitpunkt nur von einem Thread zugegriffen werden. Hier soll nun nicht mit synchronized gearbeitet werden, sondern es wird eine Klasse mit einer Semaphore verwendet. Als kritischen Abschnitt bezeichnet man das Programmstück, das von höchstens einem Thread betreten werden darf. 80 / 124

89 Semaphore Gegenseitiger Ausschluss mit Semaphoren Im folgenden Beispiel werden die Aktionen, die ein Thread im kritischen Abschnitt ausführt simuliert durch eine Sleep-Operation. In einer realen Anwendung würde hier das Codefragment stehen, das auf die gemeinsamen Objekte zugreift. Der kritische Abschnitt wird durch Semaphore geschützt, indem 1 vor Betreten die Semaphor-Methode down(), 2 danach die Methode up() aufgerufen wird. 81 / 124

90 Semaphore MutualExclusion.java 1 class MutexThread extends Thread { 2 private Semaphore mutex ; 4 public MutexThread ( Semaphore mutex, String name ) { 5 super ( name ); 6 this. mutex = mutex ; 7 start (); 8 } 10 public void run () { 11 while ( true ) { 12 mutex.p (); 13 System. out. println (" kritischen Abschnitt betreten : " 14 + getname ()); 15 try { sleep (( int )( Math. random () * 100));} 16 catch ( InterruptedException e) {} 17 mutex.v (); 18 System. out. println (" kritischen Abschnitt verlassen : " 19 + getname ()); 20 } 21 } 22 } 82 / 124

91 Semaphore MutualExclusion.java 1 public class MutualExclusion { 2 public static void main ( String [] args ) { 3 int nothreadsincriticalsection =1; 4 if ( args. length!= 1) { 5 System. err. println ( 6 " usage : java MutualExclusion <NoThreadsInCriticalSection >"); 7 System. exit (1); 8 } else 9 nothreadsincriticalsection = Integer. parseint ( args [0]); 10 Semaphore mutex = new Semaphore ( nothreadsincriticalsection ); 11 for ( int i = 1; i <= 10; i ++) { 12 new MutexThread ( mutex, " Thread " + i); 13 } 14 } 15 } 83 / 124

92 Semaphore Der Aufruf zeigt, dass stets nur so viele Threads im kritischen Abschnitt sind, wie man beim Aufruf angegeben hat: 1 $ java MutualExclusion 1 2 kritischen Abschnitt betreten : Thread kritischen Abschnitt verlassen : Thread kritischen Abschnitt betreten : Thread kritischen Abschnitt verlassen : Thread kritischen Abschnitt betreten : Thread kritischen Abschnitt verlassen : Thread kritischen Abschnitt betreten : Thread kritischen Abschnitt verlassen : Thread $ java MutualExclusion 3 12 kritischen Abschnitt betreten : Thread kritischen Abschnitt betreten : Thread kritischen Abschnitt betreten : Thread kritischen Abschnitt verlassen : Thread kritischen Abschnitt betreten : Thread kritischen Abschnitt verlassen : Thread kritischen Abschnitt betreten : Thread kritischen Abschnitt verlassen : Thread kritischen Abschnitt betreten : Thread / 124

93 Semaphore Frage Was passiert durch Aufruf von $ java MutualExclusion 0 85 / 124

94 Semaphore Hörsaalübung Ändern Sie das letzte Programm (EvenThread) so ab, dass die Klasse Even ohne synchronized- Methoden auskommt. Verwenden Sie dazu Semaphore. Test.java 1 class Even { 2 private int n = 0; 3 public int next () { // POST : next is always even 4 ++n; 5 try { Thread. sleep (( long )( Math. random ()*10)); 6 } catch ( InterruptedException e) { } 7 ++n; 8 return n; 9 } 10 } 86 / 124

95 Semaphore Bearbeitungsreihenfolge von Threads festlegen In vielen Anwendungen ist es erforderlich, dass Threads parallel arbeiten und dennoch eine Abarbeitungsreihenfolge einzuhalten ist. Dabei starten alle Threads gleichzeitig, führen gewisse Aktionen aus und müssen dann warten, bis andere Threads Aktivitäten abgeschlossen haben. Insgesamt lassen sich solche Abhängigkeiten durch einen Graphen darstellen: 1 Knoten sind Threads, 2 eine Kante existiert von einem Thread T1 zu T2, falls T1 seine Aktivitäten beendet haben muss, bevor T2 starten kann. Das folgende Beispiel demonstriert eine solche Situation. 87 / 124

96 Semaphore Die Umsetzung in Java erfolgt durch Semaphore: Für jede Abhängigkeit (Kante im Graph) wird eine Semaphore verwendet. Die Semaphoren sind in einem Array sems zusammengefasst, so dass die nebenstehend gezeigten Abhängigkeiten definiert sind. Bevor eine Aktion ausgeführt wird, wird die p()-methode für alle Semaphoren, die den eingehenden Kanten entsprechen, ausgeführt; nach der Aktion die v()-methode auf allen Semaphoren der ausgehenden Kanten. Der Einfachheit halber bekommen alle Threads eine Referenz auf das Semaphoren-Array, auch wenn nicht alle Threads jede Semaphore benutzen. 88 / 124

97 Semaphore Aus Sicht des Threads i werden folgende Aktionen ausgeführt: 1 i führt p()-operation aus: Warten auf v-operation von i-1 2 i-1 hat v()-operation ausgeführt: i kann Aktion ausführen 3 i führt v-operation aus: i+1 kann aktiv werden 89 / 124

98 Semaphore TimingRelation.java 1 class T1 extends Thread { 2 private Semaphore [] sems ; 4 public T1( Semaphore [] sems ) { 5 this. sems = sems ; 6 start (); 7 } 9 private void a1 () { 10 System. out. println ("a1"); 11 try { 12 sleep (( int )( Math. random () * 10)); 13 } catch ( InterruptedException e) {} 14 } 16 public void run () { 17 a1 (); 18 sems [0]. v (); 19 sems [1]. v (); 20 sems [2]. v (); 21 } 22 } 90 / 124

99 Semaphore TimingRelation.java 1 class T2 extends Thread { 2 private Semaphore [] sems ; 4 public T2( Semaphore [] sems ) { 5 this. sems = sems ; 6 start (); 7 } 9 private void a2 () { 10 System. out. println ("a2"); 11 try { 12 sleep (( int )( Math. random () * 10)); 13 } catch ( InterruptedException e) {} 14 } 16 public void run () { 17 sems [0]. p (); 18 a2 (); 19 sems [3]. v (); 20 } 21 } 91 / 124

100 Semaphore TimingRelation.java 1 class T3 extends Thread { 2 private Semaphore [] sems ; 4 public T3( Semaphore [] sems ) { 5 this. sems = sems ; 6 start (); 7 } 9 private void a3 () { 10 System. out. println ("a3"); 11 try { 12 sleep (( int )( Math. random () * 10)); 13 } catch ( InterruptedException e) {} 14 } 16 public void run () { 17 sems [1]. p (); 18 a3 (); 19 sems [4]. v (); 20 } 21 } 92 / 124

101 Semaphore TimingRelation.java 1 class T4 extends Thread { 2 private Semaphore [] sems ; 4 public T4( Semaphore [] sems ) { 5 this. sems = sems ; 6 start (); 7 } 9 private void a4 () { 10 System. out. println ("a4"); 11 try { 12 sleep (( int )( Math. random () * 10)); 13 } catch ( InterruptedException e) {} 14 } 16 public void run () { 17 sems [2]. p (); 18 a4 (); 19 sems [5]. v (); 20 } 21 } 93 / 124

102 Semaphore TimingRelation.java 1 class T5 extends Thread { 2 private Semaphore [] sems ; 4 public T5( Semaphore [] sems ) { 5 this. sems = sems ; 6 start (); 7 } 9 private void a5 () { 10 System. out. println ("a5"); 11 try { 12 sleep (( int )( Math. random () * 10)); 13 } catch ( InterruptedException e) {} 14 } 16 public void run () { 17 sems [3]. p (); 18 sems [4]. p (); 19 sems [5]. p (); 20 a5 (); 21 } 22 } 94 / 124

103 Semaphore TimingRelation.java 1 public class TimingRelation { 2 public static void main ( String [] args ) { 3 Semaphore [] sems = new Semaphore [6]; 4 for ( int i = 0; i < 6; i ++) { 5 sems [i] = new Semaphore (0); 6 } 7 new T4( sems ); 8 new T5( sems ); 9 new T1( sems ); 10 new T2( sems ); 11 new T3( sems ); 12 } 13 } $ java TimingRelation a1 a3 a2 a4 a5 $ java TimingRelation a1 a2 a3 a4 a5 $ 95 / 124

104 Nachrichtenaustausch Nachrichtenaustausch Die bisher betrachteten Primitive haben vorausgesetzt, dass es einen gemeinsam nutzbaren Speicher gibt. Die Idee des Nachrichtenaustausch ist es, ein Kommunikationsmedium (etwa ein Netz, einen Bus) zu verwenden, so dass ein Prozess (Sender) einem anderen Prozess (Empfänger) eine Nachricht sendet. Beide Prozesse synchronisieren sich automatisch, indem der Empfänger wartet, bis er eine Nachricht erhalten hat. 96 / 124

105 Nachrichtenaustausch Nachrichtenaustausch Die bisher betrachteten Primitive haben vorausgesetzt, dass es einen gemeinsam nutzbaren Speicher gibt. Die Idee des Nachrichtenaustausch ist es, ein Kommunikationsmedium (etwa ein Netz, einen Bus) zu verwenden, so dass ein Prozess (Sender) einem anderen Prozess (Empfänger) eine Nachricht sendet. Beide Prozesse synchronisieren sich automatisch, indem der Empfänger wartet, bis er eine Nachricht erhalten hat. Als Kommunikationsprimitive sind erforderlich: send(destination, &message) und receive(source, &message). 96 / 124

106 Nachrichtenaustausch Nachrichtenaustausch Die bisher betrachteten Primitive haben vorausgesetzt, dass es einen gemeinsam nutzbaren Speicher gibt. Die Idee des Nachrichtenaustausch ist es, ein Kommunikationsmedium (etwa ein Netz, einen Bus) zu verwenden, so dass ein Prozess (Sender) einem anderen Prozess (Empfänger) eine Nachricht sendet. Beide Prozesse synchronisieren sich automatisch, indem der Empfänger wartet, bis er eine Nachricht erhalten hat. Als Kommunikationsprimitive sind erforderlich: send(destination, &message) und receive(source, &message). Diese Thematik wird u.a. in der Vorlesung Verteilte Systeme behandelt. Hier wird wieder mittels Java auf Message Queues und Pipes eingegangen. 96 / 124

107 Nachrichtenaustausch Nachrichtenaustausch Die bisher betrachteten Primitive haben vorausgesetzt, dass es einen gemeinsam nutzbaren Speicher gibt. Die Idee des Nachrichtenaustausch ist es, ein Kommunikationsmedium (etwa ein Netz, einen Bus) zu verwenden, so dass ein Prozess (Sender) einem anderen Prozess (Empfänger) eine Nachricht sendet. Beide Prozesse synchronisieren sich automatisch, indem der Empfänger wartet, bis er eine Nachricht erhalten hat. Als Kommunikationsprimitive sind erforderlich: send(destination, &message) und receive(source, &message). Diese Thematik wird u.a. in der Vorlesung Verteilte Systeme behandelt. Hier wird wieder mittels Java auf Message Queues und Pipes eingegangen. 96 / 124

108 Nachrichtenaustausch Nachrichtenaustausch Zunächst wird ein Puffer mit n Elemente definiert, der es erlaubt, Daten fester Grösse zwischen Sender und Empfänger auszutauschen. Dann wird gezeigt, wie Daten beliebiger Länger transferiert werden können. 97 / 124

109 Nachrichtenaustausch Puffer mit n Elementen Der Erzeuger fügt Daten am Pufferende (Position tail ) ein. Der Verbraucher entnimmt den Wert am Pufferanfang (an Position 0 head ) und reorganisiert den Puffer, d.h. alle Elemente werden nach oben verschoben. Was halten Sie von dieser Lösung? 98 / 124

110 Nachrichtenaustausch Puffer mit n Elementen Das Reorganisieren kann vermieden werden, wenn der Puffer zyklisch organisiert wird: 99 / 124

111 Nachrichtenaustausch Puffer in Java BufferN.java 1 public class BufferN { 2 private int head ; 3 private int tail ; 4 private int numberofelements ; 5 private int [] data ; 7 public BufferN ( int n) { 8 data = new int [n]; 9 head = 0; 10 tail = 0; 11 numberofelements = 0; 12 } } 100 / 124

112 Nachrichtenaustausch Puffer in Java BufferN.java 1 public synchronized void put ( int x) { 2 while ( numberofelements == data. length ) { 3 try { 4 wait (); 5 } catch ( InterruptedException e) {} 6 } 7 data [ tail ++] = x; 8 if( tail == data. length ) 9 tail = 0; 10 numberofelements ++; 11 notifyall (); 12 } Wenn der Puffer voll geworden ist, muss die Methode put() warten. Die Schleife ist erforderlich, da wir notifyall() verwenden müssen. Wenn eine freie Position vorhanden ist, wird der Wert gespeichert und die Variable tail zyklisch inkrementiert, danach wird ein wartender Thread geweckt. 101 / 124

113 Nachrichtenaustausch Puffer in Java BufferN.java 1 public synchronized int get () { 2 while ( numberofelements == 0) { 3 try { 4 wait (); 5 } catch ( InterruptedException e) {} 6 } 7 int result = data [ head ++]; 8 if( head == data. length ) 9 head = 0; 10 numberofelements - -; 11 notifyall (); 12 return result ; 13 } Die Methode get() funktioniert analog. 102 / 124

114 Nachrichtenaustausch Message Queues Nun wird gezeigt, wie Daten beliebiger Länge ausgetauscht werden können. Dabei muss die Nachrichtengrenze bewahrt bleiben, d.h. wird z.b. Byte-Array gesendet so wird exakt diese Menge an Daten empfangen: 103 / 124

115 Nachrichtenaustausch Message Queues MessagaQueue.java 1 public class MessageQueue { 2 private byte [][] msgqueue = null ; 3 private int qsize = 0; // size of message queue as 4 // number of entries ( not number of bytes ) 5 private int head = 0; 6 private int tail = 0; 8 public MessageQueue ( int capacity ) { 9 if( capacity <= 0) 10 return ; 11 msgqueue = new byte [ capacity ][]; 12 } } Damit der Sender die Orginal Nachricht bearbeiten kann, nachdem er sie gesendet hat, wird zuerst eine Kopie erstellt. 104 / 124

116 Nachrichtenaustausch Message Queues MessageQueue.java 1 public synchronized void send ( byte [] msg ) { 2 while ( qsize == msgqueue. length ) { 3 try { 4 wait (); 5 } catch ( InterruptedException e) {} 6 } 8 msgqueue [ tail ] = new byte [ msg. length ]; // copy message 9 // and store the copy 10 for ( int i = 0; i < msg. length ; i++) 11 msgqueue [ tail ][ i] = msg [i]; 12 qsize ++; 13 tail ++; 14 if( tail == msgqueue. length ) 15 tail = 0; 16 notifyall (); 17 } 105 / 124

117 Nachrichtenaustausch Message Queues MessagaQueue.java 1 public synchronized byte [] receive () { 2 while ( qsize == 0) { 3 try { 4 wait (); 5 } catch ( InterruptedException e) {} 6 } 7 byte [] result = msgqueue [ head ]; 8 msgqueue [ head ] = null ; 9 qsize - -; 10 head ++; 11 if( head == msgqueue. length ) 12 head = 0; 13 notifyall (); 14 return result ; 15 } Durch ein Applet kann das Verhalten von MessagaQueue demonstriert werden. 106 / 124

118 Nachrichtenaustausch Pipes Message Queues bewahren die Nachrichtengrenzen; deshalb wird diese Art der Kommunikation auch nachrichtenorientiert genannt. Demgegenüber ist es für den Empfänger einer Nachricht bei streamorientierten Kommunkation nicht möglich, die einzelnen Nachrichten zu unterscheiden, die an der Kommunikation beteiligt sind. Diese Verhalten verdeutlicht die Kommunikation über Pipes (mit einem Byte-Array fester Grösse) pipe 107 / 124

119 Nachrichtenaustausch Pipe in Java Pipe.java 1 public class Pipe { 2 private byte [] buffer = null ; 3 private int bsize = 0; 4 private int head = 0; 5 private int tail = 0; 7 public Pipe ( int capacity ) { 8 if( capacity <= 0) 9 return ; 10 buffer = new byte [ capacity ]; 11 } } 108 / 124

120 Nachrichtenaustausch Die send()-operation, die Daten in eine Pipe schreibt, muss als atomare Operation realisiert werden: wenn die Nachricht grösser ist, als der noch verfügbar freie Platz in der Pipe, muss der Sender blockieren, bis ein Empfänger durch receive() Platz in der Pipe gemacht hat. Pipe.java 1 public synchronized void send ( byte [] msg ) { 2 if( msg. length <= buffer. length ) { 3 // sent as atomic operation 4 while ( msg. length > buffer. length - bsize ) { 5 try { wait (); 6 } catch ( InterruptedException e) {} 7 } 9 // copy message into buffer 10 for ( int i = 0; i < msg. length ; i++) { 11 buffer [ tail ] = msg [i]; 12 tail ++; 13 if( tail == buffer. length ) 14 tail = 0; 15 } 16 bsize += msg. length ; 17 notifyall (); 18 } else { / 124

121 Nachrichtenaustausch Wenn die gesamte Länge der Nachricht grösser ist, als die Kapazität der Pipe, so wird die Nachricht in kleine Stücke geteilt und jeweils nur ein Stück gesendet. 1 public synchronized void send ( byte [] msg ) { else { // send in portions 4 int offset = 0; 5 int stilltosend = msg. length ; 6 while ( stilltosend > 0) { 7 while ( bsize == buffer. length ) { 8 try { wait (); 9 } catch ( InterruptedException e) {} 10 } 11 int sendnow = buffer. length - bsize ; 12 if( stilltosend < sendnow ) sendnow = stilltosend ; 13 for ( int i = 0; i < sendnow ; i++) { 14 buffer [ tail ] = msg [ offset ]; 15 tail ++; 16 if( tail == buffer. length ) tail = 0; 17 offset ++; 18 } 19 bsize += sendnow ; stilltosend -= sendnow ; 20 notifyall (); 21 } 22 } 23 } 110 / 124

122 Nachrichtenaustausch Beim Empfang einer Nachricht, muss blockiert werden, bis Daten in der Pipe verfügbar sind. Ein Parameter beim receive() gibt die erwartete Grösse der Nachricht an; wenn weniger Daten in der Pipe sind, wird nicht blockiert, sondern nur der verfügbare Teil gelesen. Pipe.java 1 public synchronized byte [] receive ( int nobytes ) { 2 while ( bsize == 0) { 3 try { 4 wait (); 5 } catch ( InterruptedException e) {} 6 } 7 if( nobytes > bsize ) 8 nobytes = bsize ; 9 byte [] result = new byte [ nobytes ]; 10 for ( int i = 0; i < nobytes ; i++) { 11 result [i] = buffer [ head ]; 12 head ++; 13 if( head == buffer. length ) 14 head = 0; 15 } 16 bsize -= nobytes ; 17 notifyall (); 18 return result ; 19 } 20 } 111 / 124

123 IPC Probleme IPC Problem 1 Prozessmodell 2 3 IPC Probleme Problem speisender Philosophen Lese-Schreiber Problem Das Problem des schlafenden Friseurs 112 / 124

124 IPC Probleme Problem speisender Philosophen Problem speisender Philosophen (Dijkstra, 1965) Fünf Philosophen sitzen um einen runden Tisch. Jeder hat einen Teller mit Spagetti vor sich auf dem Teller. Zwischen jedem Teller liegt eine Gabel. Um Essen zu können, braucht man immer zwei Gabeln. Das Leben eines Philosophen besteht aus Essen und Denken. Wenn ein Philosoph hungrig wird, versucht er die linke und rechte Gabel zu nehmen und zu Essen. Das Problem: Es ist ein Programm für einen Philosophen zu finden, das, auf alle Philosophen angewendet, nie dazu führt, dass einer der Philosophen verhungert. 113 / 124

125 IPC Probleme Problem speisender Philosophen Dieses Problem ist typisch für Betriebssysteme: es verdeutlicht den Wettbewerb um eine begrenzte Anzahl von exklusiv nutzbaren Betriebsmitteln, wie CPU oder E/A Geräte. Eine offensichtliche (aber nicht korrekte) Lösung in C ist: 1 const int N =5; 2 philosophers ( int i) { 3 while ( true ) { 4 think (); 5 takefork (i); // take left fork 6 take_fork (( i+1)% N); // take right fork 7 eat (); 8 putfork (i); // put left fork back 9 putfork (( i+1)% N); // put right fork back 10 } 11 } Die Funktion takefork() wartet, bis die entsprechende Gabel frei ist und nimmt dann die Gabel. Ist die Gabel nicht frei, wird eine Zeit lang gewartet und erneut versucht, die Gabel zu nehmen. Was halten Sie von dieser Lösung? 114 / 124

126 IPC Probleme Problem speisender Philosophen 1 const int N =5; 2 philosophers ( int i) { 3 while ( true ) { 4 think (); 5 takefork (i); // take left fork 6 take_fork (( i+1)% N); // take right fork 7 eat (); 8 putfork (i); // put left fork back 9 putfork (( i+1)% N); // put right fork back 10 } 11 } Die Lösung funktioniert nicht, wenn z.b. alle Philosophen gleichzeitig die linke Gabel nehmen, da niemand die rechte Gabel nehmen kann und so alle verhungern (Deadlock). 115 / 124