236 6 Fortgeschrittene Java-Konzepte für Nebenläufigkeit ***

Transkript

1 236 6 Fortgeschrittene Java-Konzepte für Nebenläufigkeit *** Der Aufzählungstyp ThreadState Ab der Java-Version 5 sind die möglichen Zustände eines thread in dem Aufzählungstyp ThreadState definiert (siehe Abb ). Durch den Aufruf der getstate()-operation kann für ein Thread-Objekt ermittelt werden, in welchem Zustand sich ein thread gerade befindet. «enumeration» ThreadState NEW RUNNABLE BLOCKED WAITING TIMED_WAITING TERMINATED Abb : Mit der Version 5 erhält der Aufzählungstyp ThreadState Einzug in das Java-API. Damit lässt sich der aktuelle Zustand eines thread bequem abfragen Caches & Synchronisation *** In Java hat jeder thread einen lokalen Speicher, in dem er Anweisungen ausführt und Variablen ablegt. Der lokale Speicher wird regelmäßig, aber nicht atomar mit dem Hauptspeicher synchronisiert. Der lokale Speicher bildet die Cache-Architekturen moderner Prozessoren ab. Aufgrund der Caches müssen Zugriffe auf Variablen immer oder nie synchronisiert werden. Es reicht nicht aus, nur die schreibenden Zugriffe zu synchronisieren. Initialisierung bei Bedarf Beispiel: Rechtschreib- Prüfung In bestimmten Situationen ist es sinnvoll, ein Objekt nicht sofort bei der Erzeugung zu initialisieren, sondern so lange zu warten, bis es tatsächlich erforderlich ist. Dies ist immer dann der Fall, wenn die Initialisierung sehr zeit- oder speicheraufwändig ist und die zu initialisierenden Strukturen nicht in jedem Fall benötigt werden. Ein gutes Beispiel ist die Rechtschreib-Prüfung einer Textverarbeitung. Sie wird nur dann benötigt, wenn der Benut-

2 6.4 Java-Threads im Details *** 237 zer sie explizit anstößt, was nicht zwangsläufig bei jeder Ausführung der Anwendung der Fall sein muss. Für die Nutzung der Rechtschreib-Prüfung muss eine Wortliste von der Festplatte geladen werden. Dieser recht zeitaufwändige Vorgang sollte nur dann durchgeführt werden, wenn wirklich ein Text korrigiert werden soll. Wenn die Wortliste allerdings einmal benötigt wird, wird sie mit hoher Wahrscheinlichkeit viele Male hintereinander benutzt, da ein ganzer Text Wort für Wort zu überprüfen ist. Diese Prüfungen können problemlos parallel von mehreren threads durchgeführt werden, da auf die Wortliste nur lesend zugegriffen wird. Eine Implementierung der Rechtschreib-Prüfung könnte wie folgt aussehen Nutzung nie oder sehr häufig public class Rechtschreib-Prüfung public static HashSet wortliste = null; public boolean test( String testwort ) //wenn dies der erste Aufruf von test() ist, //muss das wörterbuch geladen werden if(wortliste == null ) //Wörterbuch wurde noch nicht geladen synchronized( this ) //noch einmal prüfen if( wortliste == null ) HashSet temp = new HashSet(); //lade Wörter in die Liste wortliste = temp; //Jetzt ist das Wörterbuch auf jeden Fall //im Speicher return wortliste.contains( testwort ); Diese Art der Implementierung wird Doppeltest-Prinzip (double test idiom) genannt. Doppeltest- Prinzip

3 238 6 Fortgeschrittene Java-Konzepte für Nebenläufigkeit *** Ein ausführender thread prüft, ob die Wortliste geladen wurde. Wenn ja, benutzt er sie ohne Synchronisation. Falls nicht, wird das Objekt gesperrt. Anschließend wiederholt der thread die Prüfung noch einmal, da ein anderer thread die Liste inzwischen geladen haben könnte. Falls nicht, wird die Liste geladen. Die HashMap wird zunächst über eine lokale Variable referenziert. Erst nach Abschluss des Ladevorgangs wird die geladene Wortliste dem Attribut zugewiesen und steht so anderen threads zur Verfügung. Referenz-Zuweisungen sind gemäß der Java-Sprachspezifikation atomar. Wenn die Abfrage innerhalb des synchronized-blocks nicht wiederholt würde, könnte es zu einer Wettkampfbedingung kommen, bei der die Wortliste zweimal geladen wird. Überlegen Sie sich eine solche Situation. Die Implementierung mit Hilfe des Doppeltest-Prinzips ist sehr effizient, hat aber einen Nachteil: sie ist nicht thread-safe. Der Grund für diesen»schönheitsfehler«ist nicht offensichtlich, sondern verbirgt sich in der Sprachspezifikation von Java. thread-lokaler Speicher Gemäß der Java-Sprachspezifikation hat jeder thread einen lokalen Speicher, in dem er alle lesenden und schreibenden Zugriffe auf Daten ausführt: Beim Lesen eines Wertes wird dieser vom zentralen Arbeitsspeicher in den thread-lokalen Speicher geladen und von dort gelesen. Beim Schreiben eines Wertes wird dieser erst in den thread-lokalen Speicher geschrieben und erst später in den zentralen Arbeitsspeicher übertragen, wo er für andere threads sichtbar ist. Ein Zeitpunkt für diesen Übertrag ist das Verlassen eines synchronized-blocks durch den thread. Die Sperre des Objekts wird dann erst nach vollständiger Übertragung der Daten wieder freigegeben.

4 6.4 Java-Threads im Details *** 239 Der thread-lokale Speicher wird sowohl für den Stapel, als auch für die Halde genutzt. Der Stapel ist dabei unkritisch, da ein thread nie auf den Stapel eines anderen zugreift. Im Falle der Rechtschreib-Prüfung kann folgende Situation eintreten: Ein thread hat die Wortliste geladen und das Attribut wortliste auf das gerade initialisierte HashSet-Objekt gesetzt. Die Zuweisung fand im thread-lokalen Speicher statt. Beim Verlassen des synchronized-blocks werden die Daten aus dem thread-lokalen Speicher in den zentralen Arbeitsspeicher zurückgeschrieben. Neben der Änderung des Attributs wortliste muss auch die gesamte Wortliste übertragen werden. Sie befindet sich zunächst ja auch im thread-lokalen Speicher. Die Übertragung dieser relativ großen Datenmenge erfolgt nicht atomar. Es ist auch nicht definiert, ob zuerst das HashSet-Objekt übertragen und dann das Attribut gesetzt wird, oder das Attribut irgendwann vorher oder zwischendurch aktualisiert wird. Wenn das Attribut aktualisiert wurde, das HashSet-Objekt aber noch nicht vollständig übertragen wurde, könnte ein anderer thread das HashSet-Objekt bereits nutzen. Diese befindet sich dann aber in einem völlig undefinierten Zustand. lokaler Speicher für Stapel und Halde Beispiel: undefinierte Wortliste Um diese Art von Wettkampfbedingungen zu vermeiden, sollte wenn möglich die folgende Regel befolgt werden: vollständig synchronisieren Alles oder nichts synchronisieren Es werden stets entweder alle Zugriffe auf eine Variable synchronisiert werden oder gar keine. Es reicht nicht aus, ausschließlich die schreibenden Zugriffe zu synchronisieren. Eine Ausnahme von dieser Regel sollte nur dann gemacht werden, wenn es sich um eine einzige Variable eines elementaren Datentyps handelt. Tipp

5 240 6 Fortgeschrittene Java-Konzepte für Nebenläufigkeit *** Man könnte nun auf die Idee kommen, eine boolesche Va- riable einzuführen, mit deren Hilfe geprüft werden kann, ob die Wortliste bereits geladen wurde. Dadurch wird die Abfrage if( wortliste == null ) zwar vermieden, die Problematik bleibt jedoch unverändert. keine Flags verwenden WRONG WAY Schreiben Sie die Rechtschreibkorrektur mit einer booleschen Variablen zur Prüfung, ob die Wortliste bereits geladen wurde. Machen Sie sich dann klar, dass es immer noch zu einer Wettkampfbedingung durch den thread-lokalen Speicher kommen kann. Beispiel: Rechtschreib- Prüfung korrekt synchronisiert Eine korrekt synchronisierte Implementierung der Rechtschreibkorrektur sieht wie folgt aus: public class Rechtschreib-Prüfung public static HashSet wortliste = null; public boolean test( String testwort ) //wenn dies der erste Aufruf von test() ist, //muss das wörterbuch geladen werden synchronized( this ) //Wörterbuch wurde noch nicht geladen if( wortliste == null ) HashSet temp = new HashSet(); //lade Wörter in die Liste wortliste = temp; //Jetzt ist das Wörterbuch auf jeden Fall //im Speicher return wortliste.contains( testwort ); Performance der neuen Implementierung Die neue Implementierung ist nicht vollständig nebenläufig. Es kann immer nur ein thread abfragen, ob die Wortliste geladen wurde. Da dies bei allen außer bei der ersten Abfrage der Fall ist, bedeutet dies in den meisten Fällen eine unnötige Synchronisation. Allerdings verbringt jeder thread nur einen kurzen Moment innerhalb des synchronized-blocks. Es

6 6.4 Java-Threads im Details *** 241 wird nur eine if-abfrage durchgeführt. Die wesentlich aufwändigere Suche des Testwortes in der Wortliste kann hingegen nebenläufig durchgeführt werden. Sollte die korrekt synchronisierte Version wirklich zu langsam sein, kann das Doppeltest-Prinzip verwendet werden. Allerdings muss der lokale Speicher des thread dabei berücksichtigt werden. Die folgende Variante ist schwer zu verstehen. Sie sollte nur eingesetzt werden, wenn das Doppeltest-Prinzip aus Geschwindigkeitsgründen wirklich notwendig ist. public class Rechtschreib-Prüfung public static HashSet wortliste = null; private static Object sperre = new Object(); nebenläufige Variante Beispiel: korrekt implementiertes Doppeltest-Prinzip public boolean test( String testwort ) //wenn dies der erste Aufruf von test() ist, //muss das wörterbuch geladen werden if(wortliste == null ) //Wörterbuch wurde noch nicht geladen synchronized( this ) //noch einmal prüfen if( wortliste == null ) HashSet temp = null; synchronized( sperre ) temp = new HashSet(); //lade Wörter nach temp //hier wird das Objekt, auf das temp zeigt aus dem //lokalen Speicher in den Hauptspeicher übertragen //die folgende Anweisung ist eine atomare Zuweisung wortliste = temp; //hier braucht nichts mehr aus dem //lokalen Speicher übertragen zu werden //Jetzt ist das Wörterbuch auf jeden Fall im Speicher return wortliste.contains( testwort );

7 242 6 Fortgeschrittene Java-Konzepte für Nebenläufigkeit *** Thread-lokaler Speicher und Caches Welche Gründe hatten die Entwickler von Java, dieses Verhalten in der Spezifikation zu manifestieren? Der Grund ist eine wesentlich bessere Performance einer Java-Anwendung. verschiedene Geschwindigkeiten Cache-Speicher Moderne Prozessoren arbeiten wesentlich schneller als alle anderen System-Komponenten. Wenn für eine Berechnung Daten aus dem Arbeitsspeicher geholt werden müssen, vergeht aus Sicht des Prozessors eine lange Zeit zwischen Anforderung und Lieferung. Es ist zwar möglich, schnelleren Speicher zu bauen, allerdings würde ein System dadurch wesentlich teurer werden. Heutige PCs oder Workstations haben mehrere Cache-Ebenen zwischen Arbeitsspeicher und Prozessor. Der Prozessor greift nicht direkt auf den Arbeitsspeicher zu, sondern auf einen Cache-Speicher, den 1st Level- oderl1-cache (siehe Abb ). Der L1-Cache ist schneller aber auch kleiner als der Arbeitsspeicher. Ausgeklügelte Vorhersage-Verfahren sorgen dafür, dass die vom Prozessor benötigten Daten meistens im Cache liegen und nicht erst aus dem Arbeitsspeicher geladen werden müssen. Der 2nd Level- oder L2-Cache zwischen L1-Cache und Arbeitspeicher ist größer und langsamer als der L1-Cache, aber kleiner und schneller als der Arbeitsspeicher. Einige Systeme haben noch einen L3-Cache. Prozessor L1-Cache L2-Cache L3-Cache Arbeitsspeicher Abb : Zur Beschleunigung von Speicherzugriffen liegen zwischen Prozessor und Arbeitsspeicher mehrere Ebenen von Cache-Speichern. Entkopplung von Prozessoren Bei Mehrprozessor-Systemen können die einzelnen Cache- Ebenen von mehreren Prozessoren gemeinsam genutzt oder

8 6.4 Java-Threads im Details *** 243 für jeden Prozessor einzeln ausgelegt sein (siehe Abb ). Hier sind im Prinzip beliebige Kombinationen denkbar. Man sagt z.b., zwei Prozessoren sind auf der L1-Cache- Ebene entkoppelt, wenn jeder seinen eigenen L1-Cache hat, sie sich aber den L2-Cache teilen. Hat jeder Prozessor seinen eigenen Cache, wird klar, warum jeder thread einen lokalen Speicher, nämlich den Cache haben muss. Ohne die Möglichkeit, die Daten eines thread in einem Cache zwischenspeichern zu können, müssten alle Lese- und Schreibzugriffe des Prozessors den Cache umgehen und direkt auf dem Arbeitsspeicher arbeiten. Die Verarbeitungsgeschwindigkeit würde dramatisch sinken. Prozessor 1 Prozessor 2 L1-Cache L1-Cache L2-Cache Arbeitsspeicher Abb : In dem gezeichten System hat jeder Prozessor einen L1-Cache. Sie nutzen den L2-Cache aber gemeinsam. Natürlich muss es nicht zwangsläufig thread-lokalen Speicher in einem System geben. Auf einer Einprozessor-Maschine ist dies wahrscheinlich nicht der Fall. Ein Grundsatz für die nebenläufige Programmierung in Java ist aber, dass keine Annahmen über die Anzahl der physischen Prozessoren oder die Umschaltung zwischen threads gemacht werden sollten. Der thread-lokale Speicher fällt in die gleiche Kategorie. Da die Sprachspezifikation ihn vorsieht, sollten Programme so geschrieben werden, dass sie damit zurecht kommen. für threadlokalen Speicher programmieren Sicherung von run() gegen versehentlichen Aufruf *** Die run()-operation eines thread ist öffentlich. Daher kann sie versehentlich statt der start()-operation auf-