Um Klassen threadsicher zu machen, kann man Methoden der Klassen als synchronized deklarieren.  Die Qualifizierung mit synchronized bewirkt, dass zuerst eine begonnene synchronized Methode zu Ende ausgeführt wird, bevor eine neue synchronized Methode in einem anderen Thread begonnen werden kann.  Das heißt, synchronized Methoden können nicht konkurrierend  zueinander ablaufen, sondern werden immer sequentiell nacheinander ausgeführt.  In dieser Ausgabe unserer Kolumne werden wir uns die Details von synchronized genauer ansehen.
 

Threadsichere Klassen

public class IntStack {
 private final int[] array;
 private volatile int cnt = 0;

 public IntStack (int sz) { array = new int[sz]; }

 synchronized public void push (int elm) {
   if (cnt < array.length) array[cnt++] = elm;
   else throw new IndexOutOfBoundsException();
 }

 synchronized public int pop () {
   if (cnt > 0) return(array[--cnt]);
   else throw new IndexOutOfBoundsException();
 }

 synchronized public int peek() {
   if (cnt > 0) return(array[cnt-1]);
   else throw new IndexOutOfBoundsException();
 }

 public int size() { return cnt; }

 public int capacity() { return (array.length); }
}
 

Mutex

 ...
 synchronized(myObject) {
  ... // innerhalb dieses Blocks besteht die Sperre
 }
 ...

Bei der Nutzung von synchronized gibt es in Java gibt es keine andere Möglichkeit, die Sperre des Mutex zu aktivieren oder deaktivieren, obwohl das auf Grund der JVM, die dafür explizite Operationscodes hat, durchaus möglich wäre.

Die Benutzung des Mutex ist in Java so starr an die Blockgrenzen gebunden, weil auf diese Weise sichergestellt ist, dass nicht versehentlich vergessen werden kann, die Sperre eines Mutex  wieder freizugegeben. Durch die Kopplung des Sperrens und Freigebens an Blockgrenzen ist gesichert, dass das Lock auf jeden Fall deaktiviert wird, das bedeutet jedoch nicht, dass das Lock immer zum richtigen (d.h. zum frühest möglichen) Zeitpunkt freigegeben wird.

Die starre Kopplung an Blockgrenzen bringt darüber hinaus funktionale Einschränkungen mit sich: so ist es zum Beispiel nicht möglich, eine zweite Sperre nach einer ersten Sperre so zu aktivieren, dass diese nach der ersten deaktiviert wird. Einen solchen Vorgang nennt man Hand-Over-Hand Locking (siehe Abb. 1).  Das geht in Java nicht; es gibt nur ein geschachteltes Locking (Nested Locking, siehe Abb .2), das den geschachtelten Blockstrukturen entspricht.

Abbildung 1: Hand-Over-Hand Locking

Abbildung 2: Nested Locking

Mit dem JDK 1.5 gibt es an solchen Stellen mehr Flexibilität in der Programmierung. Im nächsten Artikel werden wir diese neuen Möglichkeiten diskutieren. In diesem Artikel beschränken wir uns auf die pre-JDK 1.5 Funktionalität.

synchronized Instanzmethoden und synchronized Blöcke

synchronized public int pop () {
   if (cnt > 0) return(array[--cnt]);
   else throw new IndexOutOfBoundsException();
 }

und

 public int pop() {
    synchronized (this) {
      if (cnt > 0) return(array[--cnt]);
      else throw new IndexOutOfBoundsException();
    }
 }

Schauen wir uns noch einmal die obige pop-Methode daraufhin an, ob man bei ihr den kritischen Bereich verkleinern kann. Aus dem vorhergehenden Artikel wissen wir, dass die für die Thread-Sicherheit relevanten Elemente hier der Zugriff auf den Stackpointer cnt und das Array array, in dem die Werte gespeichert werden, sind. Eine Einschränkung ist, wie oben bereits diskutiert, dass wir einen kritischen Bereich in Java (vor JDK 1.5) nur als Code-Block definieren können. Unter dieser Randbedingung ist das Sperren der ganzen Methode der kleinste mögliche kritische Bereich: die Abfrage der Bedingung  (cnt > 0) und der if-Zweig  (return(array[--cnt]);) müssen zusammen in einem kritischen Bereich sein. Im else-Zweig wird gar nicht auf cnt und array zugegriffen und es ist damit völlig überflüssig, hier noch die Sperre durch das Mutex weiter aufrechtzuerhalten. Aber da die Sperre an Blockgrenzen gebunden ist, geht es nicht anders.

Details der Mutex Sperre

 synchronized public void push (int elm) {
   if (cnt < array.length) array[cnt++] = elm;
   else throw new IndexOutOfBoundsException();
 }

 synchronized public void push (int elm) {
   if (cnt < capacity()) array[cnt++] = elm;
   else throw new IndexOutOfBoundsException();
 }

 public int capacity() { return (array.length); }

Schauen wir uns eine andere Situation an. Nehmen wir an, dass wir unseren IntStack um eine Methode erweitern, die genau dann eine Exception (ValueZeroException) wirft, falls der Wert, der beim pop() zurückkommen würde, 0 ist.  Wir implementieren die Methode folgendermaßen:

synchronized public int popIfNotZero() thows ValueZeroException {
   if (peek()) != 0 return pop();
   else throw new ValueZeroException();
}

Damit sich der oberste Wert des Stacks zwischen der Abfrage durch peek() und dem Herausholen durch pop() nicht ändern kann, müssen die Aufrufe von peek() und pop() beide in einem kritischen Bereich liegen. Der kleinste Block, der diesen kritischen Bereich umgibt, ist die gesamte Methode. Deshalb ist popIfNotZero() als synchronized deklariert.

Was geschieht nun, wenn der Thread innerhalb von popIfNotZero() die Methode peek() aufruft?  Er hält bereits die Sperre des Mutex, da diese aktiviert wurde, als er den Funktionsblock von popIfNotZero() betreten hat.  Andererseits ist die Methode peek() aber auch synchronized, d.h. die Sperre des Mutex soll erneut aktiviert werden.  Ist das ein Problem? Nein.  Die Sperre eines Mutex (und wir sprechen hier immer über ein Mutex, nämlich das von this) kann rekursiv beliebig oft vom selben Thread aktiviert werden. Würde es sich aber um ein anderes Mutex handeln, so bestünde potentiell die Gefahr eines Deadlocks. Diese Problematik werden wir in einem zukünftigen Artikel behandeln.

In der Java Language Specification (/JLS/) ist noch explizit erwähnt, dass die Sperre erst dann inaktiv wird und einen anderen Thread durchläßt, wenn sie genauso häufig deaktiviert wurde, wie sie vorher aktiviert wurde. Bei der Benutzung von synchronized spielt diese Anforderung aber keine Rolle, da Aktivieren und Deaktivieren nur am Blockanfang bzw. -ende desselben Blocks erfolgen kann und so sichergestellt ist, dass die Anzahl gleich ist.

Darüber hinaus kann eine Mutex-Sperre Sperre nur von dem Thread deaktiviert werden kann, der sie vorher aktiviert hat. Auch diese Einschränkung ist lediglich von theoretischer Bedeutung ist, da das Aufheben der Sperre nur implizit am Ende des synchronized-Block erfolgen kann.  Anfang und Ende eines Blocks liegen natürlich immer im  selben Thread.

Monitor

In der prozeduralen Systemprogrammierung gibt es den Begriff des Monitors. Er beschreibt ein Muster (englisch: Pattern),  bei dem die Zugriffe auf eine Ressource dadurch threadsicher gemacht werden, dass alle Zugriffe über Zugriffsmethoden erfolgen, die sich über ein gemeinsames Mutex synchronisieren. Die Designer von Java haben den Begriff Monitor für das Konzept einer Klasse übernommen, deren Instanzen threadsicher sind. Die Ressource besteht dabei aus den Instanzvariablen und die Zugriffsmethoden auf die Ressource sind die Instanzmethoden der Klasse. Wegen dieser Analogie findet sich in der JavaDoc des JDK häufig der Begriff monitor lock.  Damit ist dann das mit dem Objekt assoziierte Mutex gemeint. Im Standardfall der Synchronisierung über this ist ein Monitor Lock gleichzeitig auch das Mutex, das für die Threadsicherheit des Objekts sorgt.

Klassenvariablen und Klassenmethoden

Dabei ist der Zugriff auf Klassenvariablen vom Typ long und double ein wenig problematisch, weil nicht auf Anhieb klar ist, ob und wie man den Zugriff synchronisieren muss. Im letzten Artikel haben wir erwähnt, dass der Zugriff auf long und double Variablen nicht atomar ist. Wenn eine Klasse non-final Klassenvariablen dieser beiden Typen hat, dann kann von mehreren Threads konkurrierend auf diese Klassenvariablen zugegriffen werden.  Da der Zugriff nicht atomar ist, kann er potentiell zu Fehlern führen kann. Diese Fehler können vermieden werden, indem Klassenvariablen vom Typ long und double als volatile deklariert werden.  Der Zugriff auf volatile Variablen ist nämlich atomar.

Leider wird die Lösung mit Hilfe von volatile von verschiedenen älteren JVMs nicht unterstützt; der Zugriff auf volatile Variablen vom Typ long und double ist in diesen JVMs nicht atomar, obwohl er es sein sollte.  Darüber hinaus bedarf das Keyword volatile grundsätzlich einer etwas längeren Diskussion, die wir erst in einem zukünftigen Artikel führen möchten.  Deshalb wollen wir uns an dieser Stelle eine Lösung ansehen, die ohne volatile auskommt.  Sie besteht darin, dass wir den lesenden und schreibenden Zugriff auf Klassenvariablen über Klassenmethoden theadsicher machen

Zur Illustration erweitern wir die Funktionalität unseres IntStacks so, dass er die Anzahl der eigenen Instanzen zählt, d.h. die Zahl der existierenden und noch nicht vom Garbage Collector finalisierten Objekte. Dabei soll „finalisiert“ heißen, dass die finalize() Methode noch nicht aufgerufen wurde. Der Zähler soll vom Typ long sein. Dazu wird man die Implementierung von IntStack folgendermaßen erweitern bzw. verändern:

public class IntStack {
 private static long instanceCnt = 0;

  synchronized private static void incInstance() { instanceCnt++; }

  synchronized private static void decInstance() { instanceCnt--; }

  synchronized public static long numberOfInstances {
   return instanceCnt;
  }

 protected finalize() {
  decInstance();
 }

 public IntStack (int sz) {
  array = new int[sz];
  incInstance();
 }

 // und alle anderen Instanzmethoden wie oben

}

Will man den Zugriff auf Instanzvariblen explizit in einem synchronized-Block schützen, so muss man das Klassenobjekt selbst ermitteln. Dies geht zum Beispiel, indem man auf einem Objekt die Methode getClass() aufruft; sie ist in java.lang.Object definiert. Oder man kann es auch direkt über ein Literal im Java Code ansprechen: <vollqualifizierter Packagename>.<Klassename>.class . Damit ist es auch möglich, den Konstruktor von IntStack threadsicher zu implementieren, ohne incInstance() aufzurufen:

public IntStack (int sz) {
  array = new int[sz];
  synchronized (IntStack.class) { instanceCnt++; }
}

Abweichung vom Standardmuster ?

Wenn man die Instanzvariablen einer Instanz schützen will, muss man für alle kritischen Bereiche das gleiche Mutex (und damit das gleiche Objekt verwenden), damit die Sperren effektiv sind. Auch sollte man für jede Instanz der Klasse ein eigenes Mutex verwenden, weil die Instanzen unabhängig voneinander sind.  Wenn alle Instanzen dasselbe Mutex verwenden würden, dann würden sich die verschiedenen Instanzen gegenseitig blockieren. Durch die Verwendung eines jeweils anderen Mutex pro Instanz wird die Parallelität des Programms hingegen maximiert, weil sich die Instanzen nicht gegenseitig behindern.

Der folgende Code ist ein Beispiel dafür, wie der IntStack mit einem anderen Mutex als dem von this threadsicher gemacht werden kann. Hier wird das Mutex des Objekts myMutex verwendet.

public class IntStack {
 private final int[] myMutex = new int[0];
 private final int[] array;
 private volatile int cnt = 0;

 public IntStack (int sz) { array = new int[sz]; }

 public void push (int elm) {
  synchronized (myMutex) {
   if (cnt < array.length) array[cnt++] = elm;
   else throw new IndexOutOfBoundsException();
  }
 }

 public int pop () {
  synchronized (myMutex) {
   if (cnt > 0) return(array[--cnt]);
   else throw new IndexOutOfBoundsException();
  }
 }

 public int peek() {
  synchronized (myMutex) {
   if (cnt > 0) return(array[cnt-1]);
   else throw new IndexOutOfBoundsException();
  }
 }

 public int size() { return cnt; }

 public int capacity() { return (array.length); }
}

An dieser Stelle sollte man sich noch einmal vergegenwärtigen, dass das Mutex am Objekt und nicht an der Variablen hängt. Man verwechselt dies manchmal, weil die Variable in die runden Klammern hinter das synchronized geschrieben wird. Durch die Verwechslung von Variable und Objekt kann es auch zu Fehlern kommen, weil der Variablen ein anderes Objekt zugewiesen werden kann und damit nach der Zuweisung plötzlich ein anderes Mutex verwendet wird. Aus diesem Grund haben wir in unserer Implementierung die Instanzvariable myMutex final gemacht, damit garantiert immer dasselbe Objekt referenziert wird.

Welche Unterschiede ergeben sich nun dadurch, dass wir vom Standardmuster abweichen und ein eigenes Mutexobjekt verwenden? Ein Unterschied ergibt sich durch die Sichtbarkeit der Mutexobjekts.  Das Aktivieren und Deaktivieren der Sperre kann man auch von außerhalb des Objekts machen, d. h. Sperren und Entsperren entsprechen public Operationen. Da beim Standardmuster das Mutex des Objektes verwendet wird, kann jeder, der Zugriff auf das Objekt hat, die Sperre des Mutex aktivieren. Nehmen wir beispielweise an,  in einem Programm steht der folgende Code:

. . .
synchronized (myIntStack) {
 for(;;) {
   sleep(100000);
  }
}
. . .

Nun mag es wie ein Fehler erscheinen, wenn das Mutex von Außen zugreifbar ist.  Es gibt aber Situationen, in denen die externe Nutzung des Mutex sogar gewollt ist. Um ein Beispiel dafür zu sehen, erweitern wir unseren IntStack (und zwar den mit der Synchronisation nach Standardmuster) um eine Methode iterator(), die einen Iterator vom Typ java.util.Iterator zurückliefert:

public Iterator iterator() {
 return new Iterator() {
  private int i = 0;

  public void hasNext() {
   synchronized (IntStack.this) {
    return (i < cnt);
   }
  }

  public Object next() {
   synchronized (IntStack.this) {
    if (i < cnt) return (new Integer(array[i++]));
    else return null;
   }
  }

  public remove() {
   throw new UnsupportedOperationException();
  }
 };
}

Jetzt kann man in einer beliebigen Klassen die folgende Funktionalität implementieren, die eine Kopie des Inhalt des Stacks in einem int[] zurückgibt:

private static int[] stackToArray(IntStack is) {
 synchronized(is) {
  int[] tmpArray = new int[is.size()];
  Iterator iter = is.iterator;
  for (int i=0; i.hasNext(); i++)
   array[i] = ((Integer) iter.next()).intValue();
 }
}

Fassen wir unsere Erfahrungen mit dem Standardmuster bzw. einer möglichen Abweichung  davon (mit privatem Mutex Objekt) noch einmal zusammen: Immer wenn man dem Nutzer die Möglichkeit geben will (oder sogar muss), mehrere Operationen durch das Mutex des Objekts zu schützen, so wird man das Standardmuster nutzen. Ist dies nicht nötig und möchte man das Mutex nicht für andere zugreifbar halten, wird man ein explizites privates Mutex nutzen.

Die Diskussion, die wir hier für Instanzvariablen und –methoden geführt haben, gilt natürlich in abgewandelter Form auch für Klassenmethoden.
 

Zusammenfassung

Literaturverweise

If you are interested to hear more about this and related topics you might want to check out the following seminar:

Seminar   Concurrent Java - Java Multithread Programming 4 day seminar ( open enrollment and on-site)