Parallel Programming

Condition Queues

http://n.ethz.ch/~klauserc/FS10/PP/

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 – FragenVorteile/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.

ProducerFlagBuffer 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

ConsumerFlagBuffer 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?

ProducerFlagBuffer 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

ConsumerFlagBuffer 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?

ProducerFlagBuffer 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

ConsumerFlagBuffer 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, 3 2, 1, 0

5, 4 3

5 4

2, 1 0

2 1

Zusammenführen (merging)

Beispiel

L1: 0 5

L2: 3 4 45

Ausgabe:

Per Definition

0 3 4 5 45

Vergleichen

Kopieren

Zeiger bewegen

Fertig!

Zusammenführen, Beispiel

0, 1, 2, 3, 4, 5

3, 4, 5 0, 1, 2

4, 5 3

5 4

1, 2 0

2 1

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-Messungn t 1 2 4 8 16 32 … 51

2100´000 ×

500´000 ×

1´000´000

⋮

100´000´000n ≔ Länge der Listet ≔ 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 Vorgangend = 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 meantimetry { 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 (32Bit vs. 64Bit)

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?