Threads Kritische Bereiche Reales Beispiel Deadlocks Wait/Notify. Programmieren II. Martin Schultheiß. Hochschule Darmstadt Sommersemester 2011

Transkript

1 Programmieren II Martin Schultheiß Hochschule Darmstadt Sommersemester 2011

2 1 Threads 2 Kritische Bereiche 3 Reales Beispiel 4 Deadlocks 5 Wait/Notify

3 Nebenläufigkeit Moderne Betriebssysteme unterstützen das Prinzip der Nebenläufigkeit. Dies bedeutet, dass Prozesse parallel ausgeführt werden können.

4 Nebenläufigkeit Moderne Betriebssysteme unterstützen das Prinzip der Nebenläufigkeit. Dies bedeutet, dass Prozesse parallel ausgeführt werden können. Nur auf Multiprozessor-Systemen können Prozesse echt parallel ablaufen. Ansonsten laufen diese nur quasi-parallel ab, indem das Betriebssystem den einzelnen Prozessen regelmäßig kleine Portionen CPU-Zeit zuordnet, so dass diese als gleichzeitig ablaufend erscheinen.

5 Nebenläufigkeit Moderne Betriebssysteme unterstützen das Prinzip der Nebenläufigkeit. Dies bedeutet, dass Prozesse parallel ausgeführt werden können. Nur auf Multiprozessor-Systemen können Prozesse echt parallel ablaufen. Ansonsten laufen diese nur quasi-parallel ab, indem das Betriebssystem den einzelnen Prozessen regelmäßig kleine Portionen CPU-Zeit zuordnet, so dass diese als gleichzeitig ablaufend erscheinen. Da ein einzelner Prozess selten ständig 100 % der CPU-Zeit benötigt, ist hiermit oft kein wesentlicher Geschwindigkeitsverlust feststellbar.

6 Threads Neben Multitasking (quasi-parallele Ausführung unabhängiger Prozesse mit eigenem Adressraum) unterstützen moderne Betriebssysteme auch Multithreading.

7 Threads Neben Multitasking (quasi-parallele Ausführung unabhängiger Prozesse mit eigenem Adressraum) unterstützen moderne Betriebssysteme auch Multithreading. Hier laufen innerhalb eines Programms mehrere Ausführungsstränge (Threads, dt. Fäden) nebenläufig ab.

8 Threads Neben Multitasking (quasi-parallele Ausführung unabhängiger Prozesse mit eigenem Adressraum) unterstützen moderne Betriebssysteme auch Multithreading. Hier laufen innerhalb eines Programms mehrere Ausführungsstränge (Threads, dt. Fäden) nebenläufig ab. Diese Thread besitzen zwar einen eigenen Stack, teilen sich aber die sonstigen Ressourcen des Programms. Da die Threads den gleichen Adressraum verwenden, ist somit eine direkte Kommunikation zwischen Threads möglich. Threads können sich so aber auch negativ beeinflussen. Daher müssen manchmal kritische Bereiche geschützt werden, was wieder zu Verklemmungen (deadlock) führen kann.

9 Schaubild

10 Threads in Java Java unterstützt seit jeher Threads, sogar unter Betriebssystemen, die nicht multithreaded sind (dann übernimmt die JVM die Threadverwaltung, d. h. Threadumschaltung einschließlich Stackverwaltung).

11 Threads in Java Java unterstützt seit jeher Threads, sogar unter Betriebssystemen, die nicht multithreaded sind (dann übernimmt die JVM die Threadverwaltung, d. h. Threadumschaltung einschließlich Stackverwaltung). Für Java-Threads existiert die Klasse Thread. Diese erwartet ein Objekt, das das Interface Runnable implementiert.

12 Threads in Java Java unterstützt seit jeher Threads, sogar unter Betriebssystemen, die nicht multithreaded sind (dann übernimmt die JVM die Threadverwaltung, d. h. Threadumschaltung einschließlich Stackverwaltung). Für Java-Threads existiert die Klasse Thread. Diese erwartet ein Objekt, das das Interface Runnable implementiert. Runnable definiert dabei die abstrakte Methode run(), die ein Objekt dann implementieren muss. Ein Thread wird dann mit start () gestartet, wobei dieser dann für das Objekt, das Runnable implementiert, die Methode run() nebenläufig ausführt.

13 Beispiel Runnable r1 = new Runnable ( ) { p u b l i c void run ( ) { f o r ( i n t i =0; i <100000; i++) { double summe = 0. 0 ; f o r ( i n t j =0; j <100; j++) summe += Math. s i n (Math. i f ( i %1000 == 0) System. out. p r i n t l n (new Date ( ) ) ; ; Runnable r2 = new Runnable ( ) { p u b l i c void run ( ) { f o r ( i n t i =0; i <100000; i++) { double summe = 0. 0 ; f o r ( i n t j =0; j <100; j++) summe += Math. s i n (Math. i f ( i %1000 == 0) System. out. p r i n t l n ( i ) ; ;

14 Starten der Threads Im vorigen Beispiel werden zwei Runnable-Objekte angelegt, die in einer Schleife Sinuswerte aufaddieren (dies dient hier ausschließlich zum Verbraten von Rechenzeit) und regelmäßig Meldungen auf der Konsole aufgeben.

15 Starten der Threads Im vorigen Beispiel werden zwei Runnable-Objekte angelegt, die in einer Schleife Sinuswerte aufaddieren (dies dient hier ausschließlich zum Verbraten von Rechenzeit) und regelmäßig Meldungen auf der Konsole aufgeben. Damit die Methoden run() beider Objekte parallel ablaufen, werden diese nun per Thread gestartet: new Thread ( r1 ). s t a r t ( ) ; new Thread ( r2 ). s t a r t ( ) ; Nun erscheinen die Ausgaben der beiden Treads miteinander vermischt auf der Konsole.

16 Unterbrechen von Threads Die beiden Threads im vorigen Beispiel laufen solange, bis bei beiden Runnable-Objekten run() fertig ist (und solange läuft das Programm auch in der JVM, auch wenn main schon zu Ende ist).

17 Unterbrechen von Threads Die beiden Threads im vorigen Beispiel laufen solange, bis bei beiden Runnable-Objekten run() fertig ist (und solange läuft das Programm auch in der JVM, auch wenn main schon zu Ende ist). Ein Thread kann mit interrupt () zum Beenden aufgefordert werden. In diesem Fall wird ein Interrupt-Flag gesetzt. Dass die Methode run() hierauf reagiert, muss aber selber implementiert werden.

18 Unterbrechen von Threads Die beiden Threads im vorigen Beispiel laufen solange, bis bei beiden Runnable-Objekten run() fertig ist (und solange läuft das Programm auch in der JVM, auch wenn main schon zu Ende ist). Ein Thread kann mit interrupt () zum Beenden aufgefordert werden. In diesem Fall wird ein Interrupt-Flag gesetzt. Dass die Methode run() hierauf reagiert, muss aber selber implementiert werden. Im folgenden Beispiel werden 2 Sekunden lang Zufallszahlen ausgegeben. Hierbei wird eingeführt, dass Thread auch Runnable implementiert, man also von Thread erben und dort run() überladen kann.

19 Beispiel für interrupt() Thread t = new Thread ( ) p u b l i c void run ( ) { while (! i s I n t e r r u p t e d ( ) ) System. out. p r i n t l n (Math. random ( ) ) ; ; t. s t a r t ( ) ; try { Thread. s l e e p ( ) ; catch ( InterruptedException e ) { f i n a l l y { t. i n t e r r u p t ( ) ;

20 Treads und Dämonen Die JVM führt ein Programm solange aus, solange noch Threads des Programms aktiv sind. Dies führt dazu, dass ein Programm noch weiter laufen kann, auch wenn die Methode main (...) abgearbeitet ist (d. h. der Hauptthread des Programms zu Ende ist).

21 Treads und Dämonen Die JVM führt ein Programm solange aus, solange noch Threads des Programms aktiv sind. Dies führt dazu, dass ein Programm noch weiter laufen kann, auch wenn die Methode main (...) abgearbeitet ist (d. h. der Hauptthread des Programms zu Ende ist). Solche Threads werden als User Thread bezeichnet. Wenn also der Hauptthread endet, wird die JVM nicht beendet, solange noch User Threads laufen.

22 Treads und Dämonen Die JVM führt ein Programm solange aus, solange noch Threads des Programms aktiv sind. Dies führt dazu, dass ein Programm noch weiter laufen kann, auch wenn die Methode main (...) abgearbeitet ist (d. h. der Hauptthread des Programms zu Ende ist). Solche Threads werden als User Thread bezeichnet. Wenn also der Hauptthread endet, wird die JVM nicht beendet, solange noch User Threads laufen. Demgegenüber kann ein Thread als Demon Thread gekennzeichnet werden, durch Aufruf von setdemon(true) vor dem Starten des Threads. Diese werden von der JVM nicht beachtet, sobald also nur noch Dämonen laufen, wird die Anwendung endgültig beendet.

23 Konflikte bei konkurrierenden Threads Während Threads zwar ihren eigenen Stack besitzen, greifen Sie ansonsten auf den selben Adressbereich zu. Sie teilen sich also Daten!

24 Konflikte bei konkurrierenden Threads Während Threads zwar ihren eigenen Stack besitzen, greifen Sie ansonsten auf den selben Adressbereich zu. Sie teilen sich also Daten! Dies muss bei der Programmierung berücksichtigt werden. Es kann passieren, dass in einem Thread Daten geändert werden, während ein anderer Daten verarbeitet (und dabei implizit davon ausgeht, dass die zu Daten sich während der Verarbeitung nicht ändern).

25 Konflikte bei konkurrierenden Threads Während Threads zwar ihren eigenen Stack besitzen, greifen Sie ansonsten auf den selben Adressbereich zu. Sie teilen sich also Daten! Dies muss bei der Programmierung berücksichtigt werden. Es kann passieren, dass in einem Thread Daten geändert werden, während ein anderer Daten verarbeitet (und dabei implizit davon ausgeht, dass die zu Daten sich während der Verarbeitung nicht ändern). Probleme treten immer dann auf, wenn mitten in solch einem kiritschen Bereich eine Threadumschaltung passiert. Die Aufgabe des Programmierers besteht also darin, solche kritischen Bereiche zu identifizieren und zu schützen.

26 Beispiel p u b l i c c l a s s K o n f l i k t 1 extends Thread { p r i v a t e s t a t i c double x p u b l i c void run ( ) { while (! i s I n t e r r u p t e d ( ) ) { double x_lokal = Math. random ( ) ; x = x_lokal ; double summe = 0 ; f o r ( i n t i =0; i <100; i++) summe+=math. s i n (Math. ra i f ( x!= x_lokal ) System. out. format ( "Ups : x=%10.8 f x_ lokal =%10 x, x_lokal ) ;

27 Analyse Eigentlich sieht der Code der Methode run() sehr harmlos aus. Die lokale Variable x_lokal wir auf einen zufälligen Wert gesetzt, dieser wird auch dem statischen Attribut x zugewiesen. Anschließend werden einige Sinus-Werte berechnet, um Rechenzeit zu verbrauchen.

28 Analyse Eigentlich sieht der Code der Methode run() sehr harmlos aus. Die lokale Variable x_lokal wir auf einen zufälligen Wert gesetzt, dieser wird auch dem statischen Attribut x zugewiesen. Anschließend werden einige Sinus-Werte berechnet, um Rechenzeit zu verbrauchen. Eigentlich sollte die Bedingung x!=x_lokal niemals zutreffen. Laufen jedoch mehrere Threads gleichzeitig new K o n f l i k t 1 ( ). s t a r t ( ) ; new K o n f l i k t 1 ( ). s t a r t ( ) ; so kann es passieren, dass zwischen Zuweisung und Abfrage durch den ersten Thread der zweite das gemeinsam benutzte Attribut x ändert, während x_lokal des ersten sich nicht ändert, da diese im eigenen Stackbereich des Threads liegt.

29 Schützen kritischer Bereiche Im vorigen Beispiel stellt der Code zwischen Zuweisen an das statische Attribut und Testen auf Gleichheit mit der lokalen Variable einen kritischen Bereich dar. Hier muss sicher gestellt werden, dass dieser von einem Thread immer komplett durchlaufen wird und ein anderer Thread hier nicht gleichzeitig eindringen kann.

30 Schützen kritischer Bereiche Im vorigen Beispiel stellt der Code zwischen Zuweisen an das statische Attribut und Testen auf Gleichheit mit der lokalen Variable einen kritischen Bereich dar. Hier muss sicher gestellt werden, dass dieser von einem Thread immer komplett durchlaufen wird und ein anderer Thread hier nicht gleichzeitig eindringen kann. Kritische Bereiche können in Java mit einem Monitor geschützt werden. Solch ein Monitor besitzt einen Lock-Mechanismus, der verriegelt wird, wenn ein Thread den kritischen Bereich betritt, und wieder entriegelt, wenn er den Bereich verlässt.

31 Schützen kritischer Bereiche Im vorigen Beispiel stellt der Code zwischen Zuweisen an das statische Attribut und Testen auf Gleichheit mit der lokalen Variable einen kritischen Bereich dar. Hier muss sicher gestellt werden, dass dieser von einem Thread immer komplett durchlaufen wird und ein anderer Thread hier nicht gleichzeitig eindringen kann. Kritische Bereiche können in Java mit einem Monitor geschützt werden. Solch ein Monitor besitzt einen Lock-Mechanismus, der verriegelt wird, wenn ein Thread den kritischen Bereich betritt, und wieder entriegelt, wenn er den Bereich verlässt. Java kennt dabei zwei wesentliche Methoden zum Schutz kritischer Bereiche: Direkt über ein Lock-Objekt, über ein synchronized für einen Bereich mit einem beliebigen Objekt als Monitor.

32 Beispiel mit Lock p u b l i c c l a s s K o n f l i k t 2 extends Thread { p r i v a t e s t a t i c Lock l o c k = new ReentrantLock ( ) ; p r i v a t e s t a t i c double x p u b l i c void run ( ) { while (! i s I n t e r r u p t e d ( ) ) { double x_lokal = Math. random ( ) ; l o c k. l o c k ( ) ; x = x_lokal ; double summe = 0 ; f o r ( i n t i =0; i <100; i++) summe+=math. s i n (Math. ra i f ( x!= x_lokal ) System. out. p r i n t l n ( "Ups" ) ; l o c k. unlock ( ) ;

33 Das Interface Lock Das Interface Lock (dessen wichtigste Implementierung die Klasse ReentrantLock ist) besitzt folgende Methoden: void lock() wartet so lange, bis der kritische Bereich betreten werden kann und verriegelt ihn.

34 Das Interface Lock Das Interface Lock (dessen wichtigste Implementierung die Klasse ReentrantLock ist) besitzt folgende Methoden: void lock() wartet so lange, bis der kritische Bereich betreten werden kann und verriegelt ihn. boolean trylock() betritt den kritischen Bereich, falls er frei ist, und verriegelt ihn. Wartet nicht! Gibt true zurück, falls der Bereich betreten wurde, sonst false.

35 Das Interface Lock Das Interface Lock (dessen wichtigste Implementierung die Klasse ReentrantLock ist) besitzt folgende Methoden: void lock() wartet so lange, bis der kritische Bereich betreten werden kann und verriegelt ihn. boolean trylock() betritt den kritischen Bereich, falls er frei ist, und verriegelt ihn. Wartet nicht! Gibt true zurück, falls der Bereich betreten wurde, sonst false. boolean trylock(long time, TimeUnit unit) wartet die angegebene Zeit auf das Betreten, unterbrechbar.

36 Das Interface Lock Das Interface Lock (dessen wichtigste Implementierung die Klasse ReentrantLock ist) besitzt folgende Methoden: void lock() wartet so lange, bis der kritische Bereich betreten werden kann und verriegelt ihn. boolean trylock() betritt den kritischen Bereich, falls er frei ist, und verriegelt ihn. Wartet nicht! Gibt true zurück, falls der Bereich betreten wurde, sonst false. boolean trylock(long time, TimeUnit unit) wartet die angegebene Zeit auf das Betreten, unterbrechbar. void lockinterruptibly() wirkt wie lock, aber unterbrechbar.

37 Das Interface Lock Das Interface Lock (dessen wichtigste Implementierung die Klasse ReentrantLock ist) besitzt folgende Methoden: void lock() wartet so lange, bis der kritische Bereich betreten werden kann und verriegelt ihn. boolean trylock() betritt den kritischen Bereich, falls er frei ist, und verriegelt ihn. Wartet nicht! Gibt true zurück, falls der Bereich betreten wurde, sonst false. boolean trylock(long time, TimeUnit unit) wartet die angegebene Zeit auf das Betreten, unterbrechbar. void lockinterruptibly() wirkt wie lock, aber unterbrechbar. void unlock() entriegelt den kritischen Bereich.

38 Schützen mit synchronized Der alternative Weg zum Schutz eines kritischen Bereiches besteht in dem Verwenden von synchronized.

39 Schützen mit synchronized Der alternative Weg zum Schutz eines kritischen Bereiches besteht in dem Verwenden von synchronized. Hierbei kann ein Bereich als synchronisiert gekennzeichnet werden, der von keinem anderen Thread betreten werden darf, während er von einem Thread durchlaufen wird. Für die Synchronisation wird hierbei ein beliebiges Monitor-Objekt verwendet.

40 Schützen mit synchronized Der alternative Weg zum Schutz eines kritischen Bereiches besteht in dem Verwenden von synchronized. Hierbei kann ein Bereich als synchronisiert gekennzeichnet werden, der von keinem anderen Thread betreten werden darf, während er von einem Thread durchlaufen wird. Für die Synchronisation wird hierbei ein beliebiges Monitor-Objekt verwendet. Die grundlegende Syntax lautet dabei synchronized ( obj ) {.... (NB: Es ist natürlich sinnlos, ein Objekt als Monitor-Objekt zu verwenden, das je Thread lokal ist.)

41 Beispiel für synchronized p u b l i c c l a s s K o n f l i k t 3 extends Thread { p r i v a t e s t a t i c Object o = new Object ( ) ; p r i v a t e s t a t i c double x p u b l i c void run ( ) { while (! i s I n t e r r u p t e d ( ) ) { double x_lokal = Math. random ( ) ; synchronized ( o ) { x = x_lokal ; double summe = 0 ; f o r ( i n t i =0; i <100; i++) summe+=math. s i n (Mat i f ( x!= x_lokal ) System. out. p r i n t l n ( "Ups" ) ;

42 Beispiel Im Folgenden soll für ein reales Beispiel geprüft werden, wo die kritischen Bereiche liegen.

43 Beispiel Im Folgenden soll für ein reales Beispiel geprüft werden, wo die kritischen Bereiche liegen. Eine generische Klasse BoundedArrayList hat die Klasse ArrayList als Vorbild, soll aber die Zahl der Elemente in der Liste auf die Zahl max beschränken.

44 Code p u b l i c c l a s s BoundedArrayList<T> { p u b l i c f i n a l s t a t i c i n t max = 1 0 ; p r i v a t e Object [ ] data = new Object [ max ] ; i n t s i z e = 0 ; p u b l i c void add (T t ) { i f ( s i z e==max) throw new ArrayIndexOutOfBoundsExcepti data [ s i z e ++] = t ; p u b l i c void remove ( i n t index ) { i f ( index <0 index>=s i z e ) throw new ArrayIndexOutOfBoundsException ( index ) ; f o r ( i n t i=index ; i<s i z e - 1 ; i++) data [ i ]= data [ i +1]; data [ s i z e -1]= n u l l ; s i z e - - ;

45 Code p u b l i c T get ( i n t index ) { i f ( index <0 index>=s i z e ) throw new ArrayIndexOutOfBoundsException ( index ) ; return (T) data [ index ] ; p u b l i c void s e t ( i n t index, T t ) { i f ( index <0 index>=s i z e ) throw new ArrayIndexOutOfBoundsException ( index ) ; data [ index ] = t ; p u b l i c i n t g e t S i z e ( ) { return s i z e ;

46 Analyse Wo liegen hier nun die kritischen Bereiche? add prüft zunächst, ob die Liste voll ist, und hängt dann ein Element an. Was ist, wenn noch ein Platz frei ist, ein Thread erfolgreich prüft, dass noch Platz ist, aber vor dem Anhängen ein anderer Thread zuvor kommt und den letzten Platz schon belegt?

47 Analyse Wo liegen hier nun die kritischen Bereiche? add prüft zunächst, ob die Liste voll ist, und hängt dann ein Element an. Was ist, wenn noch ein Platz frei ist, ein Thread erfolgreich prüft, dass noch Platz ist, aber vor dem Anhängen ein anderer Thread zuvor kommt und den letzten Platz schon belegt? remove kopiert diverse Elemente hin und her. Hier wäre es fatal, wenn währenddessen ein anderer Thread etwas an einem dieser Element ändert.

48 Analyse Wo liegen hier nun die kritischen Bereiche? add prüft zunächst, ob die Liste voll ist, und hängt dann ein Element an. Was ist, wenn noch ein Platz frei ist, ein Thread erfolgreich prüft, dass noch Platz ist, aber vor dem Anhängen ein anderer Thread zuvor kommt und den letzten Platz schon belegt? remove kopiert diverse Elemente hin und her. Hier wäre es fatal, wenn währenddessen ein anderer Thread etwas an einem dieser Element ändert. get und set prüfen zuerst, ob der Index im gültigen Bereich liegt. Danach werden Operationen mit Datenelementen getätigt. Was ist, wenn zwischen Prüfen auf gültigen Index und Datenoperation in einem anderen Thread ein Element gelöscht wird?

49 Schützen kompletter Methoden Die Methoden add, remove, get und set sind komplett kritisch. Diese müssen also über das Objekt this synchronisiert werden.

50 Schützen kompletter Methoden Die Methoden add, remove, get und set sind komplett kritisch. Diese müssen also über das Objekt this synchronisiert werden. Dies kann z. B. wie folgt geschehen: p u b l i c void add (T t ) { synchronized ( t h i s ) { i f ( s i z e==max) throw new ArrayIndexOutOfBoundsException ( max ) ; data [ s i z e ++] = t ; oder kürzer p u b l i c synchronized void add (T t ) { i f ( s i z e==max) throw new ArrayIndexOutOfBoundsException ( max ) ; data [ s i z e ++] = t ;

51 Verklemmungen Solange es nur einen Lock bzw. nur ein Objekt gibt, über das kritische Bereiche synchronisiert werden, tauchen keine Probleme auf.

52 Verklemmungen Solange es nur einen Lock bzw. nur ein Objekt gibt, über das kritische Bereiche synchronisiert werden, tauchen keine Probleme auf. Gibt es aber z. B. mehrere Locks, so kann es in der Praxis zu Verklemmungen bzw. deadlocks kommen. Hier blockiert das Programm (oder ein Teil des Programms), wenn es zu einer Situation kommt, wo Threads einen Lock besitzen und darauf warten, dass ein anderer frei wird, dieser jedoch von einem Thread gehalten wird, der wieder darauf wartet, dass ein anderer frei wird,...

53 Das Philosophenproblem Eine solche Verklemmung wird musterhaft durch das Philosphenproblem beschrieben: Mehrere Philosophen sitzen an einem runden Tisch und wollen Spaghetti essen.

54 Das Philosophenproblem Eine solche Verklemmung wird musterhaft durch das Philosphenproblem beschrieben: Mehrere Philosophen sitzen an einem runden Tisch und wollen Spaghetti essen. Zwischen zwei Philosophen liegt jeweils eine Gabel, die beide sich teilen.

55 Das Philosophenproblem Eine solche Verklemmung wird musterhaft durch das Philosphenproblem beschrieben: Mehrere Philosophen sitzen an einem runden Tisch und wollen Spaghetti essen. Zwischen zwei Philosophen liegt jeweils eine Gabel, die beide sich teilen. Zum Essen laufen folgende Schritte ab:

56 Das Philosophenproblem Eine solche Verklemmung wird musterhaft durch das Philosphenproblem beschrieben: Mehrere Philosophen sitzen an einem runden Tisch und wollen Spaghetti essen. Zwischen zwei Philosophen liegt jeweils eine Gabel, die beide sich teilen. Zum Essen laufen folgende Schritte ab: Der Philosoph nimmt die linke Gabel in die Hand (ggfls. wartet er, bis sie frei ist),

57 Das Philosophenproblem Eine solche Verklemmung wird musterhaft durch das Philosphenproblem beschrieben: Mehrere Philosophen sitzen an einem runden Tisch und wollen Spaghetti essen. Zwischen zwei Philosophen liegt jeweils eine Gabel, die beide sich teilen. Zum Essen laufen folgende Schritte ab: Der Philosoph nimmt die linke Gabel in die Hand (ggfls. wartet er, bis sie frei ist), dann nimmt er die rechte Gabel in die Hand (sobald sie frei ist),

58 Das Philosophenproblem Eine solche Verklemmung wird musterhaft durch das Philosphenproblem beschrieben: Mehrere Philosophen sitzen an einem runden Tisch und wollen Spaghetti essen. Zwischen zwei Philosophen liegt jeweils eine Gabel, die beide sich teilen. Zum Essen laufen folgende Schritte ab: Der Philosoph nimmt die linke Gabel in die Hand (ggfls. wartet er, bis sie frei ist), dann nimmt er die rechte Gabel in die Hand (sobald sie frei ist), er isst, bis er satt ist,

59 Das Philosophenproblem Eine solche Verklemmung wird musterhaft durch das Philosphenproblem beschrieben: Mehrere Philosophen sitzen an einem runden Tisch und wollen Spaghetti essen. Zwischen zwei Philosophen liegt jeweils eine Gabel, die beide sich teilen. Zum Essen laufen folgende Schritte ab: Der Philosoph nimmt die linke Gabel in die Hand (ggfls. wartet er, bis sie frei ist), dann nimmt er die rechte Gabel in die Hand (sobald sie frei ist), er isst, bis er satt ist, beide Gabeln werden wieder abgelegt.

60 Das Philosophenproblem Eine solche Verklemmung wird musterhaft durch das Philosphenproblem beschrieben: Mehrere Philosophen sitzen an einem runden Tisch und wollen Spaghetti essen. Zwischen zwei Philosophen liegt jeweils eine Gabel, die beide sich teilen. Zum Essen laufen folgende Schritte ab: Der Philosoph nimmt die linke Gabel in die Hand (ggfls. wartet er, bis sie frei ist), dann nimmt er die rechte Gabel in die Hand (sobald sie frei ist), er isst, bis er satt ist, beide Gabeln werden wieder abgelegt. Nach dem Essen wird jeweils eine Denkpause eingelegt, bis der Philosoph wieder hungrig wird.

61 Schaubild Bild: Benjamin D. Esham, Wikipedia

62 Implementierung import java. u t i l. concurrent. l o c k s. Lock ; p u b l i c c l a s s Philosoph extends Thread { p r i v a t e Lock l i n k s ; p r i v a t e Lock r e c h t s ; p u b l i c Philosoph ( S t r i n g name, Lock l i n k s, Lock r e c h t s ) { super (name ) ; t h i s. l i n k s = l i n k s ; t h i s. r e c h t s = r e c h t s ; p r i v a t e void debug ( S t r i n g message ) { System. out. p r i n t l n ( getname()+" : "+message ) ;

63 Implementierung (Gabeln nehmen, hinlegen) p r i v a t e void nehmegabeln ( ) throws InterruptedException { l i n k s. l o c k ( ) ; // Zwischen dem Aufnehmen der Gabeln v e r g e h t etwas Z Thread. s l e e p ( 5 ) ; r e c h t s. l o c k ( ) ; p r i v a t e void legegabelnhin ( ) { l i n k s. unlock ( ) ; r e c h t s. unlock ( ) ;

64 Implementierung (Essen, denken) p r i v a t e void e s s e ( ) throws InterruptedException { i n t dauer ; // Esse f ü r b i s zu 100ms dauer = ( i n t ) (100*Math. random ( ) ) ; debug ( " Essen f ü r "+dauer+"ms" ) ; Thread. s l e e p ( dauer ) ; p r i v a t e void denke ( ) throws InterruptedException { i n t dauer ; // Denke f ü r b i s zu 100ms dauer = ( i n t ) (100*Math. random ( ) ) ; debug ( "Denken f ü r "+dauer+"ms" ) ; Thread. s l e e p ( dauer ) ;

65 Implementierung p u b l i c void run ( ) { while (! i s I n t e r r u p t e d ( ) ) { try { debug ( "Gabeln aufnehmen" ) ; nehmegabeln ( ) ; e s s e ( ) ; debug ( "Gabeln h i n l e g e n " ) ; legegabelnhin ( ) ; denke ( ) ; catch ( InterruptedException e ) { legegabelnhin ( ) ; i n t e r r u p t ( ) ;

66 Analyse Im einfachsten Fall kann man mit zwei Philosophen arbeiten, die sich gegenüber sitzen: Lock l 1 = new ReentrantLock ( ) ; Lock l 2 = new ReentrantLock ( ) ; new Philosoph ( "P1", l1, l 2 ). s t a r t ( ) ; Thread. s l e e p ( 3 0 ) ; new Philosoph ( "P2", l2, l 1 ). s t a r t ( ) ;

67 Analyse Im einfachsten Fall kann man mit zwei Philosophen arbeiten, die sich gegenüber sitzen: Lock l 1 = new ReentrantLock ( ) ; Lock l 2 = new ReentrantLock ( ) ; new Philosoph ( "P1", l1, l 2 ). s t a r t ( ) ; Thread. s l e e p ( 3 0 ) ; new Philosoph ( "P2", l2, l 1 ). s t a r t ( ) ; Beim Ausführen bemerkt man, dass nach mehr oder weniger langer Zeit keiner der Philosophen mehr essen kann. Denn beide halten die linke Gabel in der Hand und warten auf die rechte die dummerweise gerade vom anderen Philosophen festgehalten wird.

68 Lösungsmöglichkeit Die Ursache für die Verklemmung in diesem Fall liegt in der Reihenfolge des Aufnehmens der Gabeln. Um diese aufzulösen, kann man eine Goldene Gabel einführen, die grundsätzlich zuerst aufgenommen werden muss, auch wenn sie rechts liegt.

69 Lösungsmöglichkeit Die Ursache für die Verklemmung in diesem Fall liegt in der Reihenfolge des Aufnehmens der Gabeln. Um diese aufzulösen, kann man eine Goldene Gabel einführen, die grundsätzlich zuerst aufgenommen werden muss, auch wenn sie rechts liegt. Übrigens reicht auch bei mehr als zwei Philosophen eine einzige goldene Gabel aus.

70 Lösungsmöglichkeit Die Ursache für die Verklemmung in diesem Fall liegt in der Reihenfolge des Aufnehmens der Gabeln. Um diese aufzulösen, kann man eine Goldene Gabel einführen, die grundsätzlich zuerst aufgenommen werden muss, auch wenn sie rechts liegt. Übrigens reicht auch bei mehr als zwei Philosophen eine einzige goldene Gabel aus. Dies bedeutet: Letztlich ist ein einziger Philosoph (der links von der goldenen Gabel) dafür verantwortlich, ob alle Philosophen verhungern müssen oder nicht!

71 Strategie zur Implementierung Zur Lösung wird nur eine neue Klasse geschaffen: p u b l i c c l a s s GoldenLock extends ReentrantLock { Diese dient rein zur Markierung einer Gabel als golden.

72 Strategie zur Implementierung Zur Lösung wird nur eine neue Klasse geschaffen: p u b l i c c l a s s GoldenLock extends ReentrantLock { Diese dient rein zur Markierung einer Gabel als golden. Nun wird in der Methode nehmegabeln() sichergestellt, dass abweichend vom Normalfall die rechte Gabel zuerst aufgenommen wird, wenn sie aus Gold ist.

73 Änderung in nehmegabeln() p r i v a t e void nehmegabeln ( ) throws InterruptedException { Lock f i r s t ; Lock second ; i f ( r e c h t s i n s t a n c e o f GoldenLock ) { f i r s t = r e c h t s ; second = l i n k s ; e l s e { f i r s t = l i n k s ; second = r e c h t s ; f i r s t. l o c k ( ) ; // Zwischen dem Aufnehmen der Gabeln vergeht etwas Z e i t Thread. s l e e p ( 2 0 ) ; second. l o c k ( ) ;

74 Austausch von Signalen über Threads In den bisherigen Beispielen wurde direkt mit den Lock-Objekten gearbeitet.

75 Austausch von Signalen über Threads In den bisherigen Beispielen wurde direkt mit den Lock-Objekten gearbeitet. Zusätzlich existiert aber die Möglichkeit, dass Threads sich gezielt schlafen legen können, bis sie von einem anderen Thread benachrichtigt werden, dass sie ihre Arbeit fortsetzen können.

76 Austausch von Signalen über Threads In den bisherigen Beispielen wurde direkt mit den Lock-Objekten gearbeitet. Zusätzlich existiert aber die Möglichkeit, dass Threads sich gezielt schlafen legen können, bis sie von einem anderen Thread benachrichtigt werden, dass sie ihre Arbeit fortsetzen können. Dies wird seit Java 1.0 über die Methoden wait und notify angeboten. Seit Java 5 kann man aber Objekte vom Typ Condition verwenden, die weitere Möglichkeiten und mehr Komfort bieten.

77 Das Interface Condition Objekte, die Condition implementieren, stellen folgende Methoden zur Verfügung await() Diese Methode legt den aktuellen Thread schlafen und sorgt dafür, dass er wieder aufwacht, wenn er über das Condition-Objekt benachrichtigt wird.

78 Das Interface Condition Objekte, die Condition implementieren, stellen folgende Methoden zur Verfügung await() Diese Methode legt den aktuellen Thread schlafen und sorgt dafür, dass er wieder aufwacht, wenn er über das Condition-Objekt benachrichtigt wird. signal() weckt einen Thread auf, der auf das Condition-Objekt wartet.

79 Das Interface Condition Objekte, die Condition implementieren, stellen folgende Methoden zur Verfügung await() Diese Methode legt den aktuellen Thread schlafen und sorgt dafür, dass er wieder aufwacht, wenn er über das Condition-Objekt benachrichtigt wird. signal() weckt einen Thread auf, der auf das Condition-Objekt wartet. signalall() benachrichtigt alle schlafenden Threads.

80 Das Interface Condition Objekte, die Condition implementieren, stellen folgende Methoden zur Verfügung await() Diese Methode legt den aktuellen Thread schlafen und sorgt dafür, dass er wieder aufwacht, wenn er über das Condition-Objekt benachrichtigt wird. signal() weckt einen Thread auf, der auf das Condition-Objekt wartet. signalall() benachrichtigt alle schlafenden Threads.

81 Das Interface Condition Objekte, die Condition implementieren, stellen folgende Methoden zur Verfügung await() Diese Methode legt den aktuellen Thread schlafen und sorgt dafür, dass er wieder aufwacht, wenn er über das Condition-Objekt benachrichtigt wird. signal() weckt einen Thread auf, der auf das Condition-Objekt wartet. signalall() benachrichtigt alle schlafenden Threads. Condition-Objekte werden von Lock-Objekten erzeugt: Lock l o c k = new ReentrantLock ( ) ; Condition cond = l o c k. newcondition ( ) ; Von await existieren zeitgesteuerte Varianten analog zu trylock.

82 Vorgehen Erzeugen eines Lock-Objekts lock

83 Vorgehen Erzeugen eines Lock-Objekts lock Erzeugen eines Condition-Objekts: Condition cond = lock.newcondition()

84 Vorgehen Erzeugen eines Lock-Objekts lock Erzeugen eines Condition-Objekts: Condition cond = lock.newcondition() Threads dürfen nur dann in Warteposition geschoben werden, wenn sie den Lock besitzen. Es muss also zunächst lock. lock() aufgerufen werden!

85 Vorgehen Erzeugen eines Lock-Objekts lock Erzeugen eines Condition-Objekts: Condition cond = lock.newcondition() Threads dürfen nur dann in Warteposition geschoben werden, wenn sie den Lock besitzen. Es muss also zunächst lock. lock() aufgerufen werden! Mit cond.await() wird gewartet (und der Lock wieder freigegeben!), bis der Thread von einem anderen mit cond.signal () bzw. cond.signalall () benachrichtigt wird.

86 Vorgehen Erzeugen eines Lock-Objekts lock Erzeugen eines Condition-Objekts: Condition cond = lock.newcondition() Threads dürfen nur dann in Warteposition geschoben werden, wenn sie den Lock besitzen. Es muss also zunächst lock. lock() aufgerufen werden! Mit cond.await() wird gewartet (und der Lock wieder freigegeben!), bis der Thread von einem anderen mit cond.signal () bzw. cond.signalall () benachrichtigt wird. Der Thread wartet nun, bis er den Lock wieder hat und setzt die Arbeit fort.

87 Vorgehen Erzeugen eines Lock-Objekts lock Erzeugen eines Condition-Objekts: Condition cond = lock.newcondition() Threads dürfen nur dann in Warteposition geschoben werden, wenn sie den Lock besitzen. Es muss also zunächst lock. lock() aufgerufen werden! Mit cond.await() wird gewartet (und der Lock wieder freigegeben!), bis der Thread von einem anderen mit cond.signal () bzw. cond.signalall () benachrichtigt wird. Der Thread wartet nun, bis er den Lock wieder hat und setzt die Arbeit fort. Am Ende das lock. unlock() nicht vergessen!

88 Beispiel: Erzeuger und Verbraucher Im folgenden Beispiel soll ein System aus Erzeugern und Verbrauchern realisiert werden. Zentraler Punkt ist eine Warteschlange, die Daten aufnehmen und wieder abgeben kann.

89 Beispiel: Erzeuger und Verbraucher Im folgenden Beispiel soll ein System aus Erzeugern und Verbrauchern realisiert werden. Zentraler Punkt ist eine Warteschlange, die Daten aufnehmen und wieder abgeben kann. Mehrere Erzeuger können dort Daten abliefern.

90 Beispiel: Erzeuger und Verbraucher Im folgenden Beispiel soll ein System aus Erzeugern und Verbrauchern realisiert werden. Zentraler Punkt ist eine Warteschlange, die Daten aufnehmen und wieder abgeben kann. Mehrere Erzeuger können dort Daten abliefern. Mehrere Verbraucher können Daten abholen.

91 Beispiel: Erzeuger und Verbraucher Im folgenden Beispiel soll ein System aus Erzeugern und Verbrauchern realisiert werden. Zentraler Punkt ist eine Warteschlange, die Daten aufnehmen und wieder abgeben kann. Mehrere Erzeuger können dort Daten abliefern. Mehrere Verbraucher können Daten abholen. Falls die Schlange voll ist, warten die Erzeuger, bis ein Verbraucher Nachricht gibt, dass er ein Element entfernt hat.

92 Beispiel: Erzeuger und Verbraucher Im folgenden Beispiel soll ein System aus Erzeugern und Verbrauchern realisiert werden. Zentraler Punkt ist eine Warteschlange, die Daten aufnehmen und wieder abgeben kann. Mehrere Erzeuger können dort Daten abliefern. Mehrere Verbraucher können Daten abholen. Falls die Schlange voll ist, warten die Erzeuger, bis ein Verbraucher Nachricht gibt, dass er ein Element entfernt hat. Ist die Schlange leer, warten die Verbraucher, bis ein Erzeuger Nachricht gibt, dass er ein Element erzeugt hat.

93 Klasse WarteSchlange p u b l i c c l a s s WarteSchlange { p r i v a t e f i n a l i n t MAX = 1 0 ; p r i v a t e Queue<String > daten = new LinkedList <String >(); Lock l o c k = new ReentrantLock ( ) ; Condition n i c h t V o l l = l o c k. newcondition ( ) ; Condition nichtleer = l o c k. newcondition ( ) ; p u b l i c void f u e l l e ( S t r i n g s ) throws InterruptedException l o c k. l o c k ( ) ; try { while ( daten. s i z e ()==MAX) n i c h t V o l l. await ( ) ; daten. add ( s ) ; nichtleer. s i g n a l A l l ( ) ; f i n a l l y { l o c k. unlock ( ) ;

94 Klasse WarteSchlange (Forts.) p u b l i c S t r i n g l e e r e ( ) throws InterruptedException { l o c k. l o c k ( ) ; try { while ( daten. s i z e ()==0) nichtleer. await ( ) ; S t r i n g r e s u l t = daten. p o l l ( ) ; n i c h t V o l l. s i g n a l A l l ( ) ; return r e s u l t ; f i n a l l y { l o c k. unlock ( ) ;

95 Klasse Erzeuger p u b l i c c l a s s Erzeuger extends Thread { p r i v a t e WarteSchlange q ; p u b l i c Erzeuger ( S t r i n g name, WarteSchlange q ) { super (name ) ; t h i s. q = q p u b l i c void run ( ) { while (! i s I n t e r r u p t e d ( ) ) { try { Date date = new Date ( ) ; S t r i n g msg = S t r i n g. format ( "%tt %10.8 f ", date, Math. System. out. p r i n t l n ( getname()+" s c h r e i b t "+msg ) ; q. f u e l l e (msg ) ; Thread. s l e e p ( ( i n t ) ( Math. random ( ) * ) ) ; catch ( InterruptedException e ) { i n t e r r u p t ( ) ;

96 Klasse Verbraucher p u b l i c c l a s s Verbraucher extends Thread { p r i v a t e WarteSchlange daten ; p u b l i c Verbraucher ( S t r i n g name, WarteSchlange daten ) { super (name ) ; t h i s. daten = daten p u b l i c void run ( ) { while (! i s I n t e r r u p t e d ( ) ) { try { System. out. p r i n t l n ( getname()+" e r h i e l t "+daten. l e e Thread. s l e e p ( ( i n t ) (Math. random ( ) * ) ) ; catch ( InterruptedException e ) { i n t e r r u p t ( ) ;

97 Klasse Main p u b l i c c l a s s Main { p r i v a t e f i n a l s t a t i c WarteSchlange q = new WarteSchlange ( p u b l i c s t a t i c void main ( S t r i n g [ ] args ) { new Erzeuger ( "E1", q ). s t a r t ( ) ; new Erzeuger ( "E2", q ). s t a r t ( ) ; new Verbraucher ( "V1", q ). s t a r t ( ) ; new Verbraucher ( "V2", q ). s t a r t ( ) ; new Verbraucher ( "V3", q ). s t a r t ( ) ;

98 Analyse Die beiden interessanten Punkte der Anwendung liegen an den Stellen, an denen die Erzeuger bzw. Verbraucher schlafen gelegt werden: while (daten. size()==max) nichtvoll.await(); while (daten. size()==0) nichtleer.await();

99 Analyse Die beiden interessanten Punkte der Anwendung liegen an den Stellen, an denen die Erzeuger bzw. Verbraucher schlafen gelegt werden: while (daten. size()==max) nichtvoll.await(); while (daten. size()==0) nichtleer.await(); Warum while und nicht if?

100 Analyse (Forts.) Wird ein Element verbraucht, so werden mit nichtvoll. signalall () alle wartenden Erzeuger benachrichtigt, dass wieder ein Platz frei ist. Nun bekommt einer der Erzeuger zufällig als erstes den Lock wieder und erzeugt ein neues Element. Kommt dann der nächste Erzeuger wieder daran, kann es sein, dass trotz Signals die Schlange also immer noch voll ist, wenn zwischenzeitlich kein anderer Verbraucher dran kam. Daher muss geprüft werden, ob der Thread nicht direkt weiter warten muss!

101 Analyse (Forts.) Wird ein Element verbraucht, so werden mit nichtvoll. signalall () alle wartenden Erzeuger benachrichtigt, dass wieder ein Platz frei ist. Nun bekommt einer der Erzeuger zufällig als erstes den Lock wieder und erzeugt ein neues Element. Kommt dann der nächste Erzeuger wieder daran, kann es sein, dass trotz Signals die Schlange also immer noch voll ist, wenn zwischenzeitlich kein anderer Verbraucher dran kam. Daher muss geprüft werden, ob der Thread nicht direkt weiter warten muss! Die gleiche Logik gilt bei den Verbrauchern. Hier muss ebenfalls geprüft werden, ob das gerade angekommene Element nicht schon von einem anderen Verbraucher genommen wurde.