Parallel Programming Condition Queues

Heute 1. Lösung zu Assignment 2 2. Condition Queues Was sind Condition Queues ? Wann sind Condition Queues sinnvoll ? Wie verwendet man Condition Queues ? 3. Ausblick auf Assignment 3

1. – ASSIGNMENT 2

Teil 2 – Fragen Frage : Wieso reicht es nicht, die Methoden read und write ` synchronized ` zu machen ? Antwort : Dadurch wird nur verhindert, dass Producer und Consumer gleichzeitig schreiben / lesen. Hat keinen Einfluss auf die Reihenfolge der Operationen.

Teil 2 – Fragen Frage : Würde es ausreichen in den Methoden read und write anstelle von synchronized eine Bool sche Variable als Guard zu verwenden ? Antwort : Nein ! read und write sind keine atomaren Operationen ! Bonus : Warum ist i++ nicht atomar ?

Teil 3 – Fragen Frage : Reicht synchronized ( this ) in den jeweiligen run - Methoden von Producer und Consumer ? Antwort : Nein, denn this ist jeweils an ein anderes Objekt gebunden. Zwei unabhängige locks Schliessen sich gegenseitig nicht aus

Teil 3 – Fragen Frage : Welches Objekt sollte stattdessen als gemeinsamer Monitor verwendet werden ? Antwort : Egal, solange beide das selbe Objekt verwenden. Am einfachsten nimmt man die gemeinsame Instanz von UnsafeBuffer.

Source Code

Teil 3 – Fragen Vorteile / Nachteile von Synchronisation der Producer / Consumer gegenüber Synchronisation des Buffers ? Vorteile : Man kann beliebige Buffer verwenden ( auch UnsafeBuffer ) Ermöglicht zusätzliche Aktionen, die ausgeführt werden müssen, bevor andere Threads den Buffer verwenden Nachteile Mehr Aufwand Fehleranfällig ( besonders wenn neue Prozesse hinzukommen )

2. – CONDITION QUEUES

Condition queue Intrinsic queue Eine Erweiterung des Monitor - Locks in Java Situation : Thread fährt nur unter folgenden Bedingungen fort 1. Exklusiven Zugriff auf eine Resource ( Lock ) 2. Preconditions erfüllt Wie geht man mit Situationen um, wo (2.) nicht erfüllt ist ?

Conditiont Queue (Abstrakt) void run() { //aquire lock while(!BEDINGUNG) { //release lock //let other threads fix precondition //re-aquire lock } //lock && precondition yay! … }

Condition Queues (Konkret) void run() { synchronized(this) { while(!BEDINGUNG) { wait(); // this.wait() } //lock && precondition yay! … } //end-synchronized } //end-run

Condition Queues - Kommunikation synchronized void write ( int d ) { while ( isFull ) { wait (); } data = d ; isFull = true ; notifyAll (); } synchronized int read() { while(!isFull) { wait(); } int d = data; isFull = false; notifyAll(); return d; }

notify versus notifyAll a.notifyAll weckt alle Threads, die auf a warten ( via a.wait() ) Die geweckten Threads verlangen alle exlusiven Lock auf a. Konkurrieren auch mit allen anderen Threads, die diesen Lock wollen Jeder Thread wird einmal die Chance haben, fortzufahren ( Deadlock / Livelock ausgenommen )

notify versus notifyAll a.notify weckt einen (!) der Threads, die auf a warten ( via a.wait() ) Welcher der wartenden Threads aufgeweckt wird, hängt von der Implementierung ab ( könnte auch zufällig sein ) Verlangen Lock auf a ; konkurrieren mit allen anderen Threads, die ebenfalls Lock auf a wollen. Andere wartende Threads bleiben wartend bis jemand sie notified

notify vs. notifyAll - Empfehlung Einfacher Grundsatz : Immer notifyAll Erweiterter Grundsatz : Wenn ihr darüber nachdenken müsst, ob notify anstatt notifyAll funktioniert, nehmt notifyAll Szenario für notify : Es ist egal welcher Thread aufgeweckt wird. Beispiel : Pool von Workerthreads. Es spielt keine Rolle welcher der Worker aufgeweckt wird. Jeder kann die Arbeit verrichten.

Producer FlagBuffer buf; void run() { for(int counter = 0; counter < 10000; i++) { if(buf.isFull) { buf.wait(); } synchronized(buf) { buf.write(counter); buf.isFull = true; } }//end-for }//end-run Consumer FlagBuffer buf; void run() { while(true) { if(!buf.isFull) buf.wait(); synchronized(buf) { int counter = buf.read)); buf.isFull = false; if(counter >= 9999) { return; } //consume counter … }//end-while }//end-run Ist dieser Code korrekt ?

Producer FlagBuffer buf; void run() { for(int counter = 0; counter < 10000; i++) { synchronized(buf) { while(buf.isFull) buf.wait(); buf.write(counter); buf.isFull = true; notifyAll(); } //end-synchronized } //end-for } //end-run Consumer FlagBuffer buf; void run() { while(true) { synchronized(buf) { while(!buf.isFull) buf.wait(); int counter = buf.read)); buf.isFull = false; if(counter >= 9999) { return; } notifyAll(); } //end-synchronized //consume counter … } //end-while } //end-run Ist dieser Code korrekt ?

Producer FlagBuffer buf; void run() { synchronized(buf) { for(int counter = 0; counter < 10000; i++) { while(buf.isFull) buf.wait(); buf.write(counter); buf.isFull = true; buf.notifyAll(); } //end-for }//end-synchronized }//end-run Consumer FlagBuffer buf; void run() { while(true) { synchronized(buf) { while(!buf.isFull) buf.wait(); int counter = buf.read)); buf.isFull = false; if(counter >= 9999) { return; } buf.notifyAll(); }//end-synchronized //consume counter … }//end-while }//end-run Ist dieser Code korrekt ?

Richtig oder falsch? notify() weckt nur einen der wartenden Threads, während notifyAll() alle weckt a.wait() darf nur aufgerufen werden, wenn der aktuelle Thread den Lock auf a hält. a.notify() weckt einen der auf a wartenden Threads und lässt ihn um den Lock auf a konkurrieren.

3. – ASSIGNMENT 3

Mergesort Gegeben : Liste L mit n Zahlen ( int ) Gesucht : Sortierte Liste L Algorithmus : Teile L auf in zwei Listen der Länge n /2 Sortiere jede der Unterlisten rekursiv mit Mergesort Führe die zwei sortierten Unterlisten zusammen Ende der Rekursion : Listen mit nur 1 Element

Beispiel (Zerlegung) 5, 4, 3, 2, 1, 0 5, 4, 32, 1, 0 5, , 10 21

Zusammenführen (merging) Beispiel L 1:05 L 2:3445 Ausgabe : Per Definition Vergleichen Kopieren Zeiger bewegen Fertig !

Zusammenführen, Beispiel 0, 1, 2, 3, 4, 5 3, 4, 50, 1, 2 4, , 20 21

Mergesort, parallelisiert Welche Teile des Algorithmus können parallelisiert werden ? Unterlisten sortieren Zwei Unterlisten zusammenführen Synchronisationsprobleme ? Zwei Unterlisten erst zusammenführen, wenn sie fertig sortiert sind Performance Anzahl Threads Länge der Liste

Performance-Messung n t … ´ 000 × 500 ´ 000 × 1 ´ 000 ´ ´ 000 ´ 000 n Länge der Liste t Anzahl Threads Frage : Wieviele Threads sind optimal ?

Wie misst man Zeit? System.currentTimeMillis() Nicht jede Millisekunde aktualisiert Nicht auf Millisekunden genau System.nanoTime() Präzision in Nanosekunden Nicht auf Nanosekunden genau Für uns ist currentTimeMillis() gut genug

Wie misst man Zeit long start; long end; start = System.currentTimeMillis(); //zu messender Vorgang end = System.currentTimeMillis(); System.out.println(Time elapsed: + (end-start));

Auf einen Thread warten Welche Möglichkeiten kennt ihr ? Busy wait ( in Schleife überprüfen, ob Thread fertig ; Assignment 3) Condition Queues ( wait(), notifyAll() ) Warten bis der Thread sich selbst beendet : t.join()

t.join() Thread t = new Thread(myRunnable); t.start(); //do our own stuff in the meantime try { t.join(); //wait for the other thread to catch up } catch(InterruptedException e) { /* ignore */ } t.join(); t.start();

Zu beantwortende Fragen Ist die parallele Version schneller ? Nicht selbstverständlich : Verwaltungsaufwand Wieviele Threads bieten optimale Performance ? Welchen Einfluss haben CPU Modell CPU Taktfrequenz Anzahl Cores verfügbarer Arbeitsspeicher verfügbarer Adressraum (32 Bit vs. 64 Bit )

Unangenehme Realität Ideale Welt N Prozessoren führen zu einem N - fachen Anstieg der Rechenleistung Realität Jeder zusätzliche Prozessor muss auch verwaltet werden. Viele Abläufe können erst gar nicht parallelisiert werden ( rein Sequentiell ) Kommunikation / Synchronisation können Wartezeiten zur Folge haben

FRAGEN?