Thread Synchronisierung

Transkript

1 Synchronisierung Interaktion zwischen s Kritischer Bereich und gegenseitiger Ausschluss Das Erzeuger-Verbraucher Schema mit und ohne Warteschlange Deadlocks Einführung 2 von 46 Interagierende s Zwei oder mehrere s laufen nicht unabhängig voneinander, sie interagieren Sie brauchen z.b. dieselbe Ressource oder dieselbe Variable konkurrieren Der eine wartet z.b. auf Daten eines anderen s kooperieren Konkurrieren Lösungsansatz Es muss sichergestellt werden, dass nur einer zu einem Zeitpunkt "dran" ist Kooperieren Lösungsansatz Es braucht einen Mechanismus, um einem anderen eine "Nachricht" zu übermitteln, dass der Verarbeitungsschritt/die Verarbeitung abgeschlossen ist. z.b. join um zu "signalisieren", dass der beendet wurde. wait -> wartet auf "Nachricht" von anderem nach Zustandswechsel (später) Konkurrierende s Gegenseitiger Ausschluss 3 von 46 4 von 46

2 Konkurrierende s Beispiel konkurrierende s: Beispiel Zähler class Konto { private double kontostand; Konto (double x) { kontostand x; einzahlen abheben Zwei s greifen auf eine gemeinsame Variable zu Sie verändern dessen Wert unabhängig voneinander Sie "konkurrieren" um die Variable Bereich in der auf solche Variablen zugegriffen wird, wird als kritischer Abschnitt bezeichnet void einzahlen(double x) { kontostand kontostand + x; Wechsel Wechsel void abheben(double x) { kontostand kontostand - x; Zähler- Zähler- z1 z1 for(25 for(25 mal){ mal){ x x sv.getandinccount(); sv.getandinccount(); Ausgabe Ausgabe (x); (x); Kritischer Abschnitt Kritischer Abschnitt SharedVars SharedVars sv sv int int count0; count0; int int getandinccount(){ getandinccount(){ int int i i count; count; sleep(1); sleep(1); count count i+1; i+1; return return i; i; Zähler- Zähler- z2 z2 for(25 for(25 mal){ mal){ x x sv.getandinccount(); sv.getandinccount(); Ausgabe Ausgabe (x); (x); absichtliche Verstärkung des absichtliche Verstärkung des Problems: Zwischen dem Lesen und Problems: Zwischen dem Lesen und Schreiben der var count greift der Schreiben der var count greift der andere auf die gleiche, noch andere auf die gleiche, noch unveränderte Variable count, zu! unveränderte Variable count, zu! 5 von 46 6 von 46 konkurrierende s Gegenseitiger Ausschluss. Beispiel 1: Zähler (nicht im Script!) Erwünschte Ausgabe: Zaehler 1, x0 Zaehler 2, x1 Zaehler 1, x2 Zaehler 2, x3 Zaehler 1, x4 Zaehler 2, x5 Zaehler 2, x6 Zaehler 2, x7 Zaehler 1, x8 Zaehler 2, x9 Zaehler 1, x10 Zaehler 2, x11 Zaehler 1, x12 Zaehler 2, x13 Zaehler 1, x14 Zaehler 2, x15... Die gemeinsame Variable soll immer Die gemeinsame Variable soll immer erhöht werden und jeder Wert nur erhöht werden und jeder Wert nur einmal dargestellt, egal, welcher einmal dargestellt, egal, welcher zugreift zugreift tatsächliche Ausgabe: Zaehler 2, x0 Zaehler 1, x0 Zaehler 1, x1 Zaehler 2, x1 Zaehler 1, x2 Zaehler 2, x2 Zaehler 1, x3 Zaehler 2, x3 Zaehler 2, x4 Zaehler 1, x4 Zaehler 2, x5 Zaehler 1, x5 Zaehler 2, x6 Zaehler 1, x6 Zaehler 1, x7 Zaehler 2, x7... Falsch! Probleme durch sich konkurrierende s wie vorhin beschrieben müssen in Programmen verhindert werden Prinzipielle Idee: man definiert kritische Bereiche, in denen zu jedem Zeitpunkt höchstens ein sein darf Gegenseitiger Ausschluss Mutual Exclusion (Mutex) Tritt ein in einen solchen Bereich ein, so darf der nächste erst eintreten, wenn der erste den Bereich verlassen hat (muss warten) Die getandinccount, einzahlen, abheben Methoden sind solcher kritische Bereiche 7 von 46 8 von 46

3 Kritischer Bereich In Java kann mit synchronized eine Methode als kritischer Bereich definiert werden Implementation ZählerZ class ZaehlerTest { class ZaehlerTest { static void main(string[] args) { static void main(string[] args) { // Vars auf die beide s zugreifen können // Vars auf die beide s zugreifen können SharedVars sharedvar new SharedVars(); SharedVars sharedvar new SharedVars(); // s kreieren und Starten // s kreieren und Starten Zaehler z1 new Zaehler(1, sharedvar); Zaehler z1 new Zaehler(1, sharedvar); Zaehler z2 new Zaehler(2, sharedvar); Zaehler z2 new Zaehler(2, sharedvar); z1.start(); z1.start(); z2.start(); z2.start(); Lösung: Lösung: synchronize synchronize exklusiver exklusiver Zugriff Zugriff auf auf die die Methode Methode getandinccount getandinccount synchronized int getandinccount() Damit funktionieren beide Beispiele auch mit sleep richtig 9 von 46 class Zaehler extends { class SharedVars { class Zaehler extends { class SharedVars { int zahlerid; private int count0; int zahlerid; private int count0; int x; int x; SharedVars sv; // Referenz auf Objekt mit shared Vars SharedVars sv; // Referenz auf Objekt mit shared Vars synchronized int getandinccount(){ int getandinccount(){ Zaehler(int id, SharedVars s) { // Constructor int i count; Zaehler(int id, SharedVars s) { // Constructor int i count; zahlerid id; // für die Ausgabe // Um Fehler zu provozieren zahlerid id; // für die Ausgabe // Um Fehler zu provozieren sv s; // Referenz auf das Shared-Object.sleep(1); sv s; // Referenz auf das Shared-Object.sleep(1); catch (Exception e ){; catch (Exception e ){; count i+1; count i+1; void run(){ return i; void run(){ return i; for (int i0; i<25;i++){ for (int i0; i<25;i++){ x sv.getandinccount(); x sv.getandinccount(); System.out.println("Zaehler "+ System.out.println("Zaehler "+ zahlerid+", i "+i+", x"+x); zahlerid+", i "+i+", x"+x); 10 von 46 Monitor Bei einer synchronized Methode passiert in Java folgendes: Es wird für das entsprechende Objekt ein sog. Monitor erzeugt Regel: es darf sich jeweils nur ein im Monitor befinden Die synchronized Methoden sind die Eingänge in den Monitor Der Monitor verwaltet einen Lock/Warteschlange für das Objekt (Objekt wird zu Monitor) Warteschlange Warteschlange read(data) read(data) write(data) write(data) (Monitor-)Objekt Geschützte Geschützte Daten Daten Monitor running/ running/ runnable runnable locked unlock Lock/Sperre Lock/Sperre für für alle alle anderen anderen synchronized blocked blocked Geschützte Geschützte Daten Daten Nur ein darf sich gleichzeitig im Monitor befinden Alle andern müssen warten, d.h. werden in Warteschlange eingeordnet Falls der (eine) die Methode verlässt kommt der nächste wartende dran etc. Bemerkungen: Ein Monitor pro Objekt befindet ein sich einmal im Monitor können beliebige andere synchronized Methoden aufgerufen werden Alle andern (nicht synchronized) Methoden der Klasse können beliebig aufgerufen werden Generell: synchronized-bereiche sind möglichst klein zu halten (gegenseitige -Blockierung Minderung der Recheneffizienz) 11 von von 46

4 Beispiel Clock (Version 1 mit TickTock1) Kooperierende s Synchronisierung TickTock-Objekt: verwaltet das Tick-Signal () und regelt den Zugriff darauf via zwei synchronized Methoden tick() und waitfortick() Minute- (Konsument): wartet auf Signal (Aufruf von waitfortick()) vom Sekunde- und zählt die Minuten hoch Sekunde- (Produzent): zählt bis 60 Sekunden und gibt dann ein Signal (Aufruf von tick()) an den Minute boolean ; boolean ; 13 von von 46 Version 1 mit TickTock1: Quellcode Zwei Probleme mit der 1. Version der Uhr Run-Methode Run-Methode des des s s Second Second void run() { void run() { while (true) { while (true) {.sleep(1000); // 1 Sek. warten.sleep(1000); // 1 Sek. warten catch catch (InterruptedException (InterruptedException e) e) { { if if (seconds (seconds 59) 59) { // nach 60 Sek { // nach 60 Sek minutetick.tick(); // Tick-Signal senden minutetick.tick(); // Tick-Signal senden seconds 0; // Sek. zuruecksetzen seconds 0; // Sek. zuruecksetzen else else {seconds++; {seconds++; screen.display(seconds screen.display(seconds + + " " Sekunden",10,20); Sekunden",10,20); Run-Methode Run-Methode des des s s Minute Minute void run() { void run() { while (true) { while (true) { minutetick.waitfortick(); // Auf Tick warten minutetick.waitfortick(); // Auf Tick warten if if (minutes (minutes 59) 59) { { minutes minutes 0; // Nach 1h Minuten zuruecksetzen 0; // Nach 1h Minuten zuruecksetzen else else {minutes++; {minutes++; screen.display(minutes screen.display(minutes + + " " Minuten",10,60); Minuten",10,60); class class TickTock1 TickTock1 implements implements TickTock TickTock { { private private boolean boolean false; false; // // Signal-Variable Signal-Variable synchronized synchronized void void waitfortick() waitfortick() { { while while (!){; (!){; // // wartet wartet bis bis true true false; false; synchronized synchronized void void tick() tick() { Busy-wait-Schleife; { Busy-wait-Schleife; true; true; 1. waitfortick() ist als Busy-Wait implementiert: while(!) {; // leere Busy-Wait-Schleife ständige CPU Auslastung durch den wartenden sollte vermieden werden 2. Programm hängt sich nach 59 Sekunden auf wieso? Minute- ruft waitfortick() auf und wartet in dieser synchronized Methode Sekunde- kann die synchronized Methode tick() gar nie mehr aufrufen ist blockiert Deadlock (später) 15 von von 46

5 Lösung: Schlafen und Wecksignale wait Anstatt einer aktiver Busy-Wait-Schleite legt sich der blockierte im Monitor schlafen wait() Solange er schläft, dürfen andere s den Monitor betreten Wenn ein anderer die Signal-Variable verändert hat, kann er einen der schlafenden s wecken, damit er den Schlaf-Grund überprüfen kann notify () Die Klasse Object stellt Methoden wait() und notify()/notifyall() zur Verfügung Beziehen sich immer auf das Objekt, in dem sie erzeugt wurden Dürfen nur innerhalb eines synchronized Programmteil aufgerufen werden (wenn ein das Monitor betreten hat) ; d.h. ein kann sich innerhalb des Monitors schlafen legen und solange er schläft, dürfen andere s den Monitor betreten in waitin wait- Zustand Zustand read(data) read(data) write(data) write(data) synchronized Monitor-Objekt Geschützte Geschützte Daten Daten Der, der wait() aufruft, legt sich schlafen (Zustand blocked) bezüglich des Objekts, in dem er wait() aufruft läuft erst weiter, wenn er wieder geweckt wird (durch notify() oder notifyall() von einem anderen ) verbraucht keine CPU-Zeit begibt sich in die Warteschlange des Objekts, in dem er sich befindet andere s können synchronized Bereiche des Objekts verwenden Nach dem Aufwecken muss der zuerst selbst wieder den an die Reihe kommen d.h. versuchen Monitor zu betreten 17 von von 46 notify notifyall notify(): erzeugt ein Wecksignal im Objekt, in welchem notify() aufgerufen wird notifyall() weckt alle im Objekt schlafende s auf sicherer, aber verbraucht mehr Rechenleistung. Schläft kein bezüglich des Objekts, so passiert nichts Schläft ein bezüglich des Objekts, so wird dieser geweckt (Zustand wird runnable) Schlafen mehrere s bezüglich des Objekts, so wird irgendeiner von diesen geweckt Ein aufgeweckter wird wie alle anderen nicht blockierten s irgendwann wieder CPU-Zeit erhalten und im Programm nach dem wait()- Aufruf weiterfahren wenn man (einfaches) Notify verwendet, kann es im Fall von mehreren wartenden s zu sog. race conditions kommen. Vergleiche auch race conditions in der Elektrotechnik, z.b. bei Flip-Flops Um die zu vermeiden man überprüft in einer Schleife immer wieder die Variable (in einer synchronized Methode) Falls nicht gewünschter Wert, dann legt man sich wieder schlafen (wait) derjenige der die Variable setzt weckt alle schlafenden s auf (notifyall); der erste der an die Reihe kommt setzt die Variable gleich zurück alle andern aufgeweckten s legen sich gleich wieder schlafen 19 von von 46

6 Monitor: Wait und Notify TickTock2 running/ running/ runnable runnable wait() notify() blocked blocked Minute verwendet wait() "öffnet" Monitor für andere Sekunde hat weiterhin Zugang zum Monitor und kann setzen (+notify) wait notify Jedes Objekt hat eine Warteschlange wait() fügt den aktuellen in die Warteschlange des Objektes ein notify() weckt den ersten in der Warteschlange notifyall() weckt alle s der Warteschlange Beachte: Bei der Version 2. wartet der Second - jedoch nicht, bis der Konsument ( Minute - ) das Tick-Signal abgeholt hat. Dies spielt in diesem Fall keine Rolle. 21 von von 46 TickTock2 TickTock2 class TickTock2 implements TickTock { private boolean false; synchronized void waitfortick() { while (!){ wait(); catch (InterruptedException e) { System.err.println("Exception"); false; Ist false Ist false schlafen legen und lock frei machen(wait()) schlafen legen und lock frei machen(wait()) synchronized void tick() { true; notifyall(); Sekunde- setzt true und führt notify() aus, um Sekunde- setzt true und führt notify() aus, um einen allfällig schlafenden aufzuwecken einen allfällig schlafenden aufzuwecken waitfortick(): Ist false, so wartet der Minute- (wait()) tick(): Sekunde- setzt true und führt notify() aus, um einen allfällig schlafenden aufzuwecken race Conditions in waitfortick(): Wieso nicht: if (!) { wait();... Würde hier zwar funktionieren, ist im Allgemeinen aber nicht garantiert! Falls mehrere s warten kann die Bedingung wieder false werden, bevor der an der Reihe ist Generell immer die while-variante verwenden 23 von von 46

7 Reservationsschema TickTock3 eine einmalig verfügbare Ressource wird von mehreren s geteilt wenn ein die Ressource belegt hat, dann müssen alle andern warten der gibt am Schluss die Ressource wieder frei Boolean inuse false; void synchronized waitforressource(){ while (inuse){ wait(); catch (InterruptedException e) { inuse true; void synchronized releaseressource(){ inuse false; notify(); Theoretisch gibt es ein weiteres Problem: wenn Minuten- zu langsam Minuten-Tick kann verloren gehen Gegenseitige Synchronisation notwendig: der Sekunde- wartet zusätzlich, bis der Minute- das Tick-Signal abgeholt hat Damit ist der Sekunde- sicher, dass der Minute- nachkommt Minute- wartet, bis Sekunden- das Produkt bereitstellt. Sekunden- wartet bis, bis Minuten- das Produkt abgeholt hat, bevor er das neue bereitstellt. Dies entspricht der sauberen und vollständigen Lösung des Erzeuger- Verbraucher Schemas (später) 25 von von 46 TickTock3 class TickTock3 implements TickTock { // Vollständige Lösung des Produzent-Konsument-Problems private boolean false; synchronized void waitfortick() { // wartet auf Nachricht while (!){ wait(); // warte auf catch (InterruptedException e) { System.err.println("Exception"); // hier Produkt abnehmen false; notifyall(); synchronized void tick() { // wartet bis abgeholt while(){ wait(); // warte bis Konsument abgeholt hat catch (InterruptedException e) { System.err.println("Exception"); // hier Produkt bereitstellen true; notifyall(); neu in der Version 3 neu in der Version 3 gleich wie in der Version 2 gleich wie in der Version 2 Erzeuger-Verbraucher Producer-Consumer 27 von von 46

8 Erzeuger-Verbraucher Erzeuger-Verbraucher Anwendungen wartet bis etwas fertig (erzeugt, berechnet, etc) wurde 1: Produzent while(true){ Item produzieren; Warten, bis letztes Elem. abgeholt; Gemeinsames Objekt blockieren; Elem. bereitstellen; Gemeinsames Objekt freigeben; Konsument wecken; 2: Konsument while(true){ Warten, bis nächstes Elem. produziert ist Gemeinsames Objekt blockieren; Elem. abholen; Gemeinsames Objekt freigeben; Produzent wecken; Beispiel von kooperierenden s Klassisches Beispiel: Erzeuger-Verbraucher Schema Platz für ein Datenelement: Ein (Produzent) erzeugt Daten für einen anderen (Konsument) Der Konsument holt die Daten ab, muss aber warten, bis diese bereit sind Hat der Produzent die Daten erzeugt, so muss er ebenfalls warten, bis der Konsument die Daten abgeholt hat und kann erst dann wieder produzieren Dadurch kann der Produzent den Konsumenten nicht mit Daten überfluten Beispiel: Uhr Produzent Produzent Ein zählt die Sekunden, ein anderer die Minuten Daten- Daten- Buffer Buffer (gemeins.. (gemeins.. Objekt) Objekt) Konsument Konsument Nach jeweils 60 Sekunden schickt der erste dem zweiten ein tick-signal, wodurch der zweite eine Minute weiter zählt Kommunikation via ein gemeinsames Objekt (TickTock) Sekunden Erzeuger Minuten Verbraucher 29 von von 46 Erzeuger-Verbraucher mit Buffer Erzeuger-Verbraucher mit Buffer Beispiel: Simulation eines Restaurants Bestellung 5 Bestellung 5 Bestellung 4 Bestellung 4 Bestellung 3 Bestellung 3 Bestellung 2 Bestellung 2 Bestellung 1 Bestellung 1 Anwendungen Computer erzeugt Daten - Drucker verbraucht Daten Netzwerk erzeugt Daten - Browser verbraucht Daten Erzeuger und Verbraucher verarbeiten Daten unregelmässig Beschreibung Kellnerin schreibt Bestellungen auf einen Zettel und hängen diesen an ein Anschlagbrett Der Koch nimmt jeweils eine Bestellung ab und verarbeitet sie Es hat nur bestimmt Anzahl Plätze für Bestellungen am Anschlagbrett; ggfs. müssen Gäste also warten, bis wieder ein Platz frei wird. Implementierung: Anschlagbrett wird durch eine Warteschlange (Queue) simuliert Array mit Strings Guest-: jede Sekunde eine Bestellung in die Warteschlange Koch-: nimmt vorderste Bestellung aus der Warteschlange und verarbeitet diese, Verarbeitungszeit 1 Sekunde Produzent Produzent 1: Produzent while(true){ Item produzieren; Warten, bis Platz in Buffer Gemeinsames Objekt blockieren; Item zu Warteschlange hinzufügen Gemeinsames Objekt freigeben; Konsument wecken; Daten-Buffer Daten-Buffer Warteschlange Warteschlange 2: Konsument while(true){ Warten, bis Buffer nicht leer Gemeinsames Objekt blockieren; Item aus Warteschlange holen; Gemeinsames Objekt freigeben; Produzent wecken; Konsument Konsument 31 von von 46

9 Erzeuger-Verbraucher mit Buffer Der Ringbuffer FIFO Grundsätzlich wie ohne Warteschlange mit folgenden Änderungen: Es gibt eine gemeinsame Warteschlange Der Produzent füllt Daten in die Warteschlange Der Konsument holt Daten aus der Warteschlange Der Produzent muss nur warten, wenn die Warteschlange voll ist Der Konsument muss nur warten, wenn die Warteschlange leer ist kann z.b. mit einer Zählvariable kontrolliert werden 33 von 46 n-1 0 outindex inindex Meist verwendete Datenstruktur für Buffer Initialisierung: private int size; private int inindex 0; private int outindex 0; private int noofitems 0; private String[] content; class Buffer /* FIFO */{ Buffer(int s) {size s; content new String[s]; synchronized void put(string s) { while (noofitems size) { wait(); catch (InterruptedException e) { content[inindex] s; inindex (inindex+1) % size; noofitems++; notifyall(); synchronized String get() { while (noofitems 0) { wait(); catch (InterruptedException e) { String s content[outindex]; outindex (outindex+1) % size; noofitems--; notifyall(); return s; 34 von 46 Erzeuger-Verbraucher mit Buffer Analyse der Pizzeria-Simulation Erzeuger class Producer extends { Producer (String n, String[] production, Buffer buf, int s) { name n; buffer buf; items production; speed s; void run() { for (int i0 ; i<items.length ; i++) { System.out.println (name + " producing..."); buffer.put(items[i]); private String[] items; private String name; private Buffer buffer; Verbraucher class Consumer extends { Consumer (String n, Buffer buf, int s) { name n; buffer buf; speed s; void run() { while (true) { String s buffer.get(); if (s.equals("")) break; System.out.println(name + " consuming \"" + s + '\"'); private String name; private Buffer buffer; 35 von Fall: Queue ist weder voll noch leer Guest/Koch werden in enter/remove werden nie wait() aufrufen Wecksignale (notify()) am Ende werden ignoriert 2. Fall: Queue ist leer remove vom Koch- wird wait()aufrufen wartet auf Wecksignal enter vom Guest- wird kein wait() aufrufen Wecksignal vom Guest- wird Koch- aufwecken, dieser kann weiterlaufen nachdem der Guest- die remove-methode verlassen hat 3. Fall: Queue ist voll enter vom Guest- wird wait()aufrufen wartet auf Wecksignal enter vom Koch- wird kein wait() aufrufen Wecksignal vom Koch- wird Guest- aufwecken, dieser kann weiterlaufen nachdem der Koch- die enter-methode verlassen hat 36 von 46

10 Der Stack LIFO class Stack /* LIFO */ { int[10] buffer; int anz0; synchronized void put(int x) { while(anz10) wait(); catch(interrubtedexception e){return; buffer[anz]x; anz++; notifyall(); das letzte Element, das eingegeben wurde wird zuerst retourniert synchronized void get() { while(anz0) wait(); catch(interrubtedexception e){return; int xbuffer[anz]; anz--; notifyall(); return(x); Verklemmung, Deadlock 37 von von 46 Deadlock Verklemmung: Dead Lock Wenn sich s gegenseitig blockieren spricht man von einem Deadlock Auch im echten Leben solche Situationen werden mit "Intelligenz" gelöst Blockieren bedeutet hier nicht kurzfristig blockieren (wie z.b bei wait/notify), sondern unauflösbar blockieren Deadlocks müssen immer dann in Betracht bezogen werden, wenn verschiedene s auf gemeinsame Ressourcen zugreifen Gehören zu den häufigsten Problemen beim multi-threaded Programmieren Beispiel: 1. Fall der Uhr: Minute_ macht Busy-Wait in der synchronized Methode waitfortick() und behält den Lock Sekunde- kann deshalb die synchronized Methode tick() nicht ausführen, welche das Busy-Wait beenden würde Konnte mit einem wait/notify einfach gelöst werden Dining Philosophers 39 von von 46

11 KlassischerDeadlock: Dining Philosophers Deadlock Situation 5 Philosophen, die denken und essen, sitzen an einem runden Tisch Zum Essen braucht ein Philosoph 2 Essstäbchen (Gabeln) Insgesamt gibt es nur 5 Essstäbchen Wer essen will, nimmt zuerst die linke, dann die rechte Essstäbchen Ist ein Essstäbchen besetzt, so wartet er, bis sie frei wird Wie kann hier ein Deadlock auftreten? ja: alle haben das linke Essstäbchen in der Hand Alle s warten auf die Freigabe einer Ressource, die ein anderer reserviert hat Es blockieren sich alle gegenseitig Generelles Muster: Teil der Ressourcen werden gehalten Anderer Teil ist blockiert (werden von anderen s gehalten) Lee braucht noch Wang hat hat 41 von von 46 Lösungen Strategien zur Vermeidung von Deadlocks Deadlocks auflösen angeforderte Ressource nach einer gewissen Zeit wieder frei geben und (gleich) erneut probieren führt ev. nicht zu Ziel schwierig (wie lange soll man warten) Nur eine Ressource anfordern -> keine Problem Problem nur, wenn mehrere Ressourcen inkrementel angefordert werden man hat die eine und wartet auf andere Deadlocks erst gar nicht aufkommen lassen Deadlocks vermeiden Z.B. Ein Philosoph verhält sich anders und nimmt erst die rechte, dann die linke Stächen es können nicht alle genau ein Stäbchen in der Hand halten ein Deadlock ist nicht möglich Haben Sie einen anderen Lösungsvorschlag für das Problem? Mögliche Strategien: nicht inkrementel anfordern Strategie 1 Alle Ressourcen gleich am Anfang anfordern Nachteil: zu lange blockiert, Strategie 2 Programmverlaufabhängigkeiten nicht berücksichtigt Alle Ressourcen auf einen Schlag anfordern Nachteil: länger blockiert als nötig Programmverlaufabhängigkeiten nur teilweise berücksichtigt 43 von von 46

12 ...Strategien zur Vermeidung von Deadlocks Zusammenfassung Synchronisierung Strategie 3 mit inkrementel angeforderter Ressourcen wenn nicht alle bekommen -> Ressourcen wieder freigeben und neu versuchen Nachteil: das "Spielchen" kann unendlich lange dauern Lee S1, S2 Wang S2, S1 braucht Lee noch Wang hat hat S1 S2 Verfeinerungen der Strategie 3 falls es nicht geklappt hat, eine zufällige Zeit lang warten z.b. TCP/IP CSCD Protokoll Interagierende s Konkurrierende-> synchronized Kooperierende -> wait(), notify(),notifyall Deadlocks Strategie 4 Alle fordern die Ressourcen in der gleichen Reihenfolge an bewährt und einfach wenn Reihenfolge definierbar 45 von von 46