10.4 Synchronisation
10.4.1 Synchronisationsprobleme
Wenn man sich mit Nebenläufigkeit beschäftigt, muß
man sich in aller Regel auch mit Fragen der Synchronisation
nebenläufiger Prozesse beschäftigen. In Java erfolgt die
Kommunikation zweier Threads auf der Basis gemeinsamer Variablen,
die von beiden Threads erreicht werden können. Führen beide
Prozesse Änderungen auf den gemeinsamen Daten durch, so müssen
sie synchronisiert werden, denn andernfalls können undefinierte
Ergebnisse entstehen.
|
Wir wollen uns als einleitendes Beispiel ein kleines Programm ansehen,
bei dem zwei Threads einen gemeinsamen Zähler hochzählen:
001 /* Listing1009.java */
002
003 public class Listing1009
004 extends Thread
005 {
006 static int cnt = 0;
007
008 public static void main(String[] args)
009 {
010 Thread t1 = new Listing1009();
011 Thread t2 = new Listing1009();
012 t1.start();
013 t2.start();
014 }
015
016 public void run()
017 {
018 while (true) {
019 System.out.println(cnt++);
020 }
021 }
022 }
|
Listing1009.java |
Listing 10.9: Zwei Zählerthreads
|
 |
|
|
Läßt man das Programm eine Weile laufen, könnte es
beispielsweise zu folgender Ausgabe kommen:
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
33 <-- Nanu? Wo ist die 32?
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
32 <-- Ach so, hier!
58
59
Beide Prozesse greifen unsynchronisiert auf die gemeinsame Klassenvariable
cnt zu. Da die Operation System.out.println(cnt++);
nicht atomar ist, kommt es zu dem Fall, daß die Operation
mitten in der Ausführung unterbrochen wird und der Scheduler
mit dem anderen Thread fortfährt. Erst später, wenn der
unterbrochene Prozeß wieder Rechenzeit erhält, kann er
seinen vor der Unterbrechung errechneten Zählerwert von 32 ausgeben.
Sein Pendant war in der Zwischenzeit allerdings bereits bis 56 fortgefahren.
Um diese Art von Inkonsistenzen zu beseitigen, bedarf es der Synchronisation
der beteiligten Prozesse.
10.4.2 Monitore
Zur Synchronisation nebenläufiger Prozesse hat Java das Konzept
des Monitors implementiert. Ein Monitor ist die Kapselung eines
kritischen Bereichs (also eines Programmteils,
der nur von jeweils einem Prozeß zur Zeit durchlaufen werden
darf) mit Hilfe einer automatisch verwalteten Sperre. Diese Sperre
wird beim Betreten des Monitors gesetzt und beim Verlassen wieder
zurückgenommen. Ist sie beim Eintritt in den Monitor bereits
von einem anderen Prozeß gesetzt, so muß der aktuelle
Prozeß warten, bis der Konkurrent die Sperre freigegeben und
den Monitor verlassen hat.
Das Monitor-Konzept wird mit Hilfe des in die Sprache integrierten
Schlüsselworts synchronized
realisiert. Durch synchronized
kann entweder eine komplette Methode oder ein Block innerhalb einer
Methode geschützt werden. Der Eintritt in den so deklarierten
Monitor wird durch das Setzen einer Sperre auf einer Objektvariablen
erreicht. Bezieht sich synchronized
auf eine komplette Methode, wird als Sperre der this-Pointer
verwendet, andernfalls ist eine Objektvariable explizit anzugeben.
Anwendung von synchronized auf einen Block von Anweisungen
|
Wir wollen uns diese Art der Verwendung an einem Beispiel ansehen,
welches das oben demonstrierte Synchronisationsproblem löst.
Die naheliegende Lösung, die Anweisung System.out.println(cnt++);
durch einen synchronized-Block
auf der Variablen this
zu synchronisieren, funktioniert leider nicht. Da der Zeiger this
für jeden der beiden Threads, die ja unterschiedliche Instanzen
repräsentieren, neu vergeben wird, wäre für jeden Thread
der Eintritt in den Monitor grundsätzlich erlaubt.
Statt dessen verwenden wir die aus Kapitel 7
bekannte Methode getClass,
die uns ein Klassenobjekt beschafft (ein und dasselbe für alle
Instanzen), mit dem wir die Klassenvariable cnt
schützen können:
001 /* Listing1010.java */
002
003 public class Listing1010
004 extends Thread
005 {
006 static int cnt = 0;
007
008 public static void main(String[] args)
009 {
010 Thread t1 = new Listing1010();
011 Thread t2 = new Listing1010();
012 t1.start();
013 t2.start();
014 }
015
016 public void run()
017 {
018 while (true) {
019 synchronized (getClass()) {
020 System.out.println(cnt++);
021 }
022 }
023 }
024 }
|
Listing1010.java |
Listing 10.10: Synchronisation von Threads mit Klassenobjekten
|
|
|
|
Nun werden alle Zählerwerte in aufsteigender Reihenfolge ausgegeben.
Anwendung von synchronized auf eine Methode
Ein anderer Fall ist der, bei dem der Zugriff auf ein Objekt selbst
synchronisiert werden muß, weil damit zu rechnen ist, daß
mehr als ein Thread zur gleichen Zeit das Objekt verwenden will.
|
Im folgenden werden die potentiellen Probleme am Beispiel eines Zählerobjekts
erläutert, dessen Aufgabe es ist, einen internen Zähler
zu kapseln, auf Anforderung den aktuellen Zählerstand zu liefern
und den internen Zähler zu inkrementieren. Hierbei handelt es
sich um eine Aufgabe, die beispielsweise in der Datenbankprogrammierung
sehr häufig vorkommt, um Schlüsselnummern zu generieren.
Typischerweise wird das Synchronisationsproblem dadurch verschärft,
daß die Verwendung des Zählers einige vergleichsweise langsame
Festplattenzugriffe erforderlich macht. In unserem Beispiel wird der
Zähler von fünf Threads verwendet. Die Langsamkeit und damit
die Wahrscheinlichkeit, daß der Scheduler die Zugriffsoperation
unterbricht, wird in unserem Beispiel durch eine Sequenz eingestreuter
Fließkommaoperationen erhöht:
001 /* Listing1011.java */
002
003 class Counter1011
004 {
005 int cnt;
006
007 public Counter1011(int cnt)
008 {
009 this.cnt = cnt;
010 }
011
012 public int nextNumber()
013 {
014 int ret = cnt;
015 //Hier erfolgen ein paar zeitaufwendige Berechnungen, um
016 //so zu tun, als sei das Errechnen des Nachfolgezählers
017 //eine langwierige Operation, die leicht durch den
018 //Scheduler unterbrochen werden kann.
019 double x = 1.0, y, z;
020 for (int i= 0; i < 1000; ++i) {
021 x = Math.sin((x*i%35)*1.13);
022 y = Math.log(x+10.0);
023 z = Math.sqrt(x+y);
024 }
025 //Jetzt ist der Wert gefunden
026 cnt++;
027 return ret;
028 }
029 }
030
031 public class Listing1011
032 extends Thread
033 {
034 private String name;
035 private Counter1011 counter;
036
037 public Listing1011(String name, Counter1011 counter)
038 {
039 this.name = name;
040 this.counter = counter;
041 }
042
043 public static void main(String[] args)
044 {
045 Thread t[] = new Thread[5];
046 Counter1011 cnt = new Counter1011(10);
047
048 for (int i = 0; i < 5; ++i) {
049 t[i] = new Listing1011("Thread-"+i,cnt);
050 t[i].start();
051 }
052 }
053
054 public void run()
055 {
056 while (true) {
057 System.out.println(counter.nextNumber()+" for "+name);
058 }
059 }
060 }
|
Listing1011.java |
Listing 10.11: Eine unzureichend synchronisierte Zählerklasse
|
|
|
|
Das Ergebnis des Programms ist - wie nicht anders zu erwarten - schlecht,
denn es werden sehr viele doppelte Schlüssel produziert. Ein
Beispiellauf brachte bereits in den ersten 15 Aufrufen 6 doppelte
Zählerwerte:
10 for Thread-2
11 for Thread-4
10 for Thread-0
10 for Thread-1
11 for Thread-2
11 for Thread-3
12 for Thread-4
13 for Thread-0
14 for Thread-1
15 for Thread-2
16 for Thread-3
17 for Thread-4
18 for Thread-0
19 for Thread-1
20 for Thread-2
Auch hier gibt es eine einfache Lösung für das Synchronisationsproblem.
Eine einfache Markierung der Methode nextNumber
als synchronized
macht diese zu einem Monitor und sorgt dafür, daß der komplette
Code innerhalb der Methode als atomares Programmfragment behandelt
wird. Eine Unterbrechung des kritischen Abschnitts durch einen anderen
Thread ist dann nicht mehr möglich:
001 public synchronized int nextNumber()
002 {
003 int ret = cnt;
004 //Hier erfolgen ein paar zeitaufwendige Berechnungen, um so
005 //zu tun, als sei das Errechnen des Nachfolgezählerstandes
006 //eine langwierige Operation, die leicht durch den
007 //Scheduler unterbrochen werden kann.
008 double x = 1.0, y, z;
009 for (int i= 0; i < 1000; ++i) {
010 x = Math.sin((x*i%35)*1.13);
011 y = Math.log(x+10.0);
012 z = Math.sqrt(x+y);
013 }
014 //Jetzt ist der Wert gefunden
015 cnt++;
016 return ret;
017 }
|
Listing 10.12: Synchronisieren der Zählermethode
Durch das synchronized-Attribut
wird beim Aufruf der Methode die Instanzvariable this
gesperrt und damit der Zugriff für andere Threads unmöglich
gemacht. Erst nach Verlassen der Methode und Entsperren von this
kann nextNumber wieder von anderen
Threads aufgerufen werden.
|
Diese Art des Zugriffschutzes wird in Java von vielen Klassen verwendet,
um ihre Methoden thread-sicher zu machen. Nach Aussage der
Sprachspezifikation kann davon ausgegangen werden, daß die gesamte
Java-Klassenbibliothek in diesem Sinne thread-sicher ist. |
|
|
|
10.4.3 wait und notify
Neben dem Monitorkonzept stehen mit den Methoden wait
und notify
der Klasse Object
noch weitere Synchronisationsprimitve zur Verfügung. Zusätzlich
zu der bereits erwähnten Sperre, die einem Objekt zugeordnet
ist, besitzt ein Objekt nämlich auch noch eine Warteliste.
Dabei handelt es sich um eine (möglicherweise leere) Menge von
Threads, die vom Scheduler unterbrochen wurden und auf ein Ereignis
warten, um fortgesetzt werden zu können.
Sowohl wait
als auch notify
dürfen nur aufgerufen werden, wenn das Objekt bereits gesperrt
ist, also nur innerhalb eines synchronized-Blocks
für dieses Objekt. Ein Aufruf von wait
nimmt die bereits gewährten Sperren (temporär) zurück
und stellt den Prozeß, der den Aufruf von wait
verursachte, in die Warteliste des Objekts. Dadurch wird er unterbrochen
und im Scheduler als wartend markiert. Ein Aufruf von notify
entfernt einen (beliebigen) Prozeß aus der Warteliste des Objekts,
stellt die (temporär) aufgehobenen Sperren wieder her und führt
ihn dem normalen Scheduling zu. wait
und notify
sind damit für elementare Synchronisationsaufgaben geeignet,
bei denen es weniger auf die Kommunikation als auf die Steuerung der
zeitlichen Abläufe ankommt.
|
Das folgende Beispiel demonstriert den Einsatz von wait
und notify
an einem Producer/Consumer-Beispiel.
Ein Prozeß arbeitet dabei als Produzent, der Fließkommazahlen
»herstellt«, und ein anderer als Konsument, der die produzierten
Daten verbraucht. Die Kommunikation zwischen beiden erfolgt über
ein gemeinsam verwendetes Vector-Objekt,
das die produzierten Elemente zwischenspeichert und als Medium für
die wait-/notify-Aufrufe
dient:
001 /* Listing1013.java */
002
003 import java.util.*;
004
005 class Producer1013
006 extends Thread
007 {
008 private Vector v;
009
010 public Producer1013(Vector v)
011 {
012 this.v = v;
013 }
014
015 public void run()
016 {
017 String s;
018
019 while (true) {
020 synchronized (v) {
021 s = "Wert "+Math.random();
022 v.addElement(s);
023 System.out.println("Produzent erzeugte "+s);
024 v.notify();
025 }
026 try {
027 Thread.sleep((int)(100*Math.random()));
028 } catch (InterruptedException e) {
029 //nichts
030 }
031 }
032 }
033 }
034
035 class Consumer1013
036 extends Thread
037 {
038 private Vector v;
039
040 public Consumer1013(Vector v)
041 {
042 this.v = v;
043 }
044
045 public void run()
046 {
047 while (true) {
048 synchronized (v) {
049 if (v.size() < 1) {
050 try {
051 v.wait();
052 } catch (InterruptedException e) {
053 //nichts
054 }
055 }
056 System.out.print(
057 " Konsument fand "+(String)v.elementAt(0)
058 );
059 v.removeElementAt(0);
060 System.out.println(" (verbleiben: "+v.size()+")");
061 }
062 try {
063 Thread.sleep((int)(100*Math.random()));
064 } catch (InterruptedException e) {
065 //nichts
066 }
067 }
068 }
069 }
070
071 public class Listing1013
072 {
073 public static void main(String[] args)
074 {
075 Vector v = new Vector();
076
077 Producer1013 p = new Producer1013(v);
078 Consumer1013 c = new Consumer1013(v);
079 p.start();
080 c.start();
081 }
082 }
|
Listing1013.java |
Listing 10.13: Ein Producer-/Consumer-Beispiel mit wait und notify
|
|
|
|
Um die Arbeitsverteilung zwischen den Prozessen etwas interessanter
zu gestalten, werden beide gezwungen, nach jedem Schritt eine kleine
Pause einzulegen. Da die Wartezeit zufällig ausgewählt wird,
kann es durchaus dazu kommen, daß der Produzent eine größere
Anzahl an Elementen anhäuft, die der Konsument noch nicht abgeholt
hat. Der umgekehrte Fall ist natürlich nicht möglich, da
der Konsument warten muß, wenn keine Elemente verfügbar
sind. Eine Beispielsitzung könnte etwa so aussehen:
Produzent erzeugte Wert 0.09100924684649958
Konsument fand Wert 0.09100924684649958 (verbleiben: 0)
Produzent erzeugte Wert 0.5429652807455857
Konsument fand Wert 0.5429652807455857 (verbleiben: 0)
Produzent erzeugte Wert 0.6548096532111007
Konsument fand Wert 0.6548096532111007 (verbleiben: 0)
Produzent erzeugte Wert 0.02311095955845288
Konsument fand Wert 0.02311095955845288 (verbleiben: 0)
Produzent erzeugte Wert 0.6277057416210464
Konsument fand Wert 0.6277057416210464 (verbleiben: 0)
Produzent erzeugte Wert 0.6965546173953919
Produzent erzeugte Wert 0.6990053250441516
Produzent erzeugte Wert 0.9874467815778902
Produzent erzeugte Wert 0.12110075531692543
Produzent erzeugte Wert 0.5957795111549329
Konsument fand Wert 0.6965546173953919 (verbleiben: 4)
Produzent erzeugte Wert 0.019655027417308846
Konsument fand Wert 0.6990053250441516 (verbleiben: 4)
Konsument fand Wert 0.9874467815778902 (verbleiben: 3)
Produzent erzeugte Wert 0.14247583735074354
Konsument fand Wert 0.12110075531692543 (verbleiben: 3)
|
Durch eine konstante Pause nach jedem produzierten Element könnte
der Produzent bewußt langsamer gemacht werden. Der schnellere
Konsument würde dann einen Großteil seiner Zeit damit verbringen,
festzustellen, daß keine Elemente verfügbar sind. Zwar
würde das Beispiel (in leicht modifizierter Form) auch ohne den
Einsatz von wait/notify
funktionieren. Durch ihre Verwendung aber ist der Konsumentenprozeß
nicht gezwungen, aktiv zu warten, sondern wird vom Produzenten
benachrichtigt, wenn ein neues Element verfügbar ist. Der Rechenzeitbedarf
reduziert sich dadurch auf einen Bruchteil dessen, was andernfalls
benötigt würde. |
|
|
|