GUAVA: EIN JAVADIALEKT OHNE NICHT DETERMINISTICHE EFFEKTE NICOLAS NGANDEU Seminar: Objektorientierte Programmiersprachen WS 03/04.

Präsentation zum Thema: "GUAVA: EIN JAVADIALEKT OHNE NICHT DETERMINISTICHE EFFEKTE NICOLAS NGANDEU Seminar: Objektorientierte Programmiersprachen WS 03/04."—  Präsentation transkript:

1 GUAVA: EIN JAVADIALEKT OHNE NICHT DETERMINISTICHE EFFEKTE NICOLAS NGANDEU Seminar: Objektorientierte Programmiersprachen WS 03/04

2 Guava: ein Javadialekt2 GLIEDERUNG  1- EINLEITLUNG  2- DIE PROGRAMMIERSPRACHE GUAVA 2.1- Klassenkategorien 2.2- Beispiele  3- COMPILER-CHECKING 3.1- „Region-“Checking 3.2- Reads & Updates Checking 3.3- „Global-“ Checking  4- PERFORMANCE 4.1- Nebenläufigkeit beim Lesen 4.2- Sperrgranülarität 4.3- Optimierung der Synchronisation 4.4- Objektmodel Verbesserungen  5- Mehr Beispiele  6- ZUSAMMENFASSUNG

3 Guava: ein Javadialekt3 EINLEITUNG  Guava ist ein Dialekt von Java, mit besonderen Regeln :  Nebenläufige Prozesse können nur durch synchronisierte Methoden auf die Daten zugreifen.  Ist durch 3 besondere Arten von Klassen spezifiziert:  Monitors  Values  Objects

4 Guava: ein Javadialekt4 EINLEITUNG  Was ist das Problem? Java ist OOP die nebenläufige Prozesse zulässt  Aber!! - Sie „müssen“ nicht synchronisiert werden - Nicht synchronisierte nebenläufige Prozesse  bessere Laufzeit. - Durch das aktuelle „Java Memory Modell“ Konflikte bei unsynchronisierten nebenläufigen Speicherzugriffen. Ergebnis  Die Anwendung des „nicht Sequenzialitäts- Konzeptes“ mit Java: * Sehr kompliziert * Zahlreiche Anomalien wurden festgestellt.

5 Guava: ein Javadialekt5 EINLEITUNG  Was kann Guava??  erlaubt Optimierungsverfahren für den Java Compiler.  Beim „Multithreading“ kann Compiler selbständig Optimierungen entwickeln, wie „Double Checks Reads“  Überblick über die Syntax und ihre Semantik.

6 Guava: ein Javadialekt6 GLIEDERUNG  1- EINLEITLUNG  2- DIE PROGRAMMIERSPRACHE GUAVA 2.1- Klassenkategorien 2.2- Beispiele  3- COMPILER-CHECKING 3.1- „Region-“Checking 3.2- Reads & Updates Checking 3.3- „Global-“ Checking  4- PERFORMANCE 4.1- Nebenläufigkeit beim Lesen 4.2- Sperrgranülarität 4.3- Optimierung der Synchronisation 4.4- Objektmodel Verbesserungen  5- Mehr Beispiele  6- ZUSAMMENFASSUNG

7 Guava: ein Javadialekt7 DIE PROGRAMMIERSPRACHE GUAVA  Was ist Guava? Konzipiert worden um die Entwicklung von Nebenläufigen Prozessen zu vereinfachen.  Im Vergleich zu Java, bietet Guava: - Verschiedene Klassenkategorien (Monitors – Values - Objects), die durch ihre bestimmten Interaktionsregeln, die Synchronisation der Daten garantieren - Zusätzliche Schlüsselwörter: * „Read“ & „Update“ für Methoden & Parameter * „Local“ & „Global“ für Methoden (oder Konstruktoren) * „Region“ für Parameter & return-Wert

8 Guava: ein Javadialekt8 DIE PROGRAMMIERSPRACHE GUAVA Die Klassenkategorien  In Java 2 Arten von Daten: 1- Referenzen: sind entweder „null“ oder haben einen „Pointer“ auf eine Instanz einer Klasse 2- Nicht-Referenzen: sind immer Werte mit einem einfachen Typ (int, char). Haben weder Klassen, Methoden, Vererbung noch andere Funktionalitäten eines Objektes.

9 Guava: ein Javadialekt9 DIE PROGRAMMIERSPRACHE GUAVA Die Klassenkategorien  Guava fügt 2 Unterschiede ein: 1- Die nicht-referenzierten Daten werden durch benutzerdefinierte Klassen mit primitivem Typ erweitert. 2- Zwei Arten von Referenzen: * die, die von verschiedenen Threads benutzt werden können * die, für die diese gemeinsamen Benutzungen nicht zulässig sind. P.S: In dieser Arbeit, werden die Ausdrücke Values, Monitors und Objects INSTANZ genant und ganz normale Objekte (die unsynchronisierten Obj.) OBJEKTE genannt

10 Guava: ein Javadialekt10 DIE PROGRAMMIERSPRACHE GUAVA Die Klassenkategorien - Monitors I - MONITORS  Können durch einen oder mehreren Threads benutzt werden  Auf ihren Methoden kann nur sequenziell zugegriffen werden  Operationen auf Monitoren finden immer synchronisiert statt (Methode o. äußere Zugriffe).  Andere Instanzen (Objects & Values) sind immer in einem Monitor enthalten.  „OWNER“  Operationen auf andere Instanzen müssen nicht synchronisiert werden

11 Guava: ein Javadialekt11 DIE PROGRAMMIERSPRACHE GUAVA Die Klassenkategorien - Monitors  Diese Eigenschaften von Monitoren stellen schon eine erhebliche Verbesserung im Vergleich zu Java dar: 1 – Die Vereinfachung von Kodierung (Synchronisation muss nur noch in Monitoren betrachten werden) 2 – Die Performance von nebenläufigen Prozessen wird auch verbessert. (durch die Minderungen von Synchronisationsprozessen)

12 Guava: ein Javadialekt12 DIE PROGRAMMIERSPRACHE GUAVA Die Klassenkategorien - Objects II - OBJECTS:  sind java-ähnlich aber man kann nur sequentiell (oder durch nur einen Thread) auf sie zugreifen.  Sie brauchen keine „synchronised“-Methoden (Schlüsselwort „synchronised“ existiert nicht).  Aufgrund der Nichtsequentialität müssen bestimmte Regeln bezüglich der Interaktion von Monitoren und Values auf Objekten betrachtet werden.  die wichtigsten Regeln: * Jedes Object muß immer in einer bestimmten Instanz enthalten sein. „OWNER“ * Objects dürfen nicht von einem „owner“ zu einem anderen „owner“ wandern * Es dürfen keine Referenzen zwischen Objects mit verschiedenen „owner“ geben

13 Guava: ein Javadialekt13 DIE PROGRAMMIERSPRACHE GUAVA Die Klassenkategorien - Values III -Values Da Objects nicht einwandfrei zwischen Monitors benutzt werden dürfen bietet Guava die Values:  Sie sind direkt in Variablen gespeichert.  Sie sind wie die einfachen Typen von Java (int, char)  sie haben keine Referenz  eine Zuweisung erzeugt eine Kopie des Value  „= =“ überprüft auf die Gleichheit eines Value.

14 Guava: ein Javadialekt14 DIE PROGRAMMIERSPRACHE GUAVA Die Klassenkategorien - Values  Sie haben die Eigenschaften, dass sie sehr komplexe Datenstrukturen darstellen können und dann einwandfrei durch Monitors benutzt werden können.  Ihre Methoden und Attribute können exportiert werden.  Uninitialisiert haben sie immer einen „default-Wert“ und nicht null wie die Referenzen.

15 Guava: ein Javadialekt15 DIE PROGRAMMIERSPRACHE GUAVA Die Klassenkategorien - Klassenhierarchie  Die abstrakte Klasse „Instance“ ist die Wurzel des Vererbungsbaums.  Alle konkreten Klassen sind Unterklassen der 3 Klassen- kategorien.  Zwischen der Klasse „Instance“ und der Klassenkategorien befinden sich Interface-Kategorien (----)  Jede Klassenkategorien implementiert 2 Interface-Kategorien

16 Guava: ein Javadialekt16 DIE PROGRAMMIERSPRACHE GUAVA Die Klassenkategorien - Klassenhierarchie  Mobile wird durch Value & Monitor implementiert  Eine Mobile-Instanz kann durch verschiedene Threads benutzt werden.  Local durch Value & Objekt implementiert:  Sie werden nie von mehreren Threads benutzt  Reference durch Monitor & Objekt:  „by reference“ kopiert.

17 Guava: ein Javadialekt17 GLIEDERUNG  1- EINLEITLUNG  2- DIE PROGRAMMIERSPRACHE GUAVA 2.1- Klassenkategorien 2.2- Beispiele  3- COMPILER-CHECKING 3.1- „Region-“Checking 3.2- Reads & Updates Checking 3.3- „Global-“ Checking  4- PERFORMANCE 4.1- Nebenläufigkeit beim Lesen 4.2- Sperrgranülarität 4.3- Optimierung der Synchronisation 4.4- Objektmodel Verbesserungen  5- Mehr Beispiele  6- ZUSAMMENFASSUNG

18 Guava: ein Javadialekt18 DIE PROGRAMMIERSPRACHE GUAVA BEISPIEL I  Guava Programm das alle 3 Kategorien von Instanzen benutzt.  Ein Hash-Table der von mehreren nebenläufigen Prozessen benutzt werden kann

19 Guava: ein Javadialekt19 DIE PROGRAMMIERSPRACHE GUAVA BEISPIEL I  Klasse SharedHashTable ist als Monitor definiert.  Sie bietet 2 Methoden an: * get(key), die Daten in Abhängigkeit vom key liefert * put(key,data), fügt Tupel Data-key in Hash Table  Key & Data sind vom Typ Mobile  sie sind entweder Value oder Monitor

20 Guava: ein Javadialekt20 DIE PROGRAMMIERSPRACHE GUAVA BEISPIEL I  BucketList ist vom Typ Value  Bietet auch 2 Methoden  Man hätte sie auch als Object definieren können  Nachteile : Bewegung zwischen owner wäre begrenzt  Bucket ist Object (Default wenn keine Erweiterungen)

21 Guava: ein Javadialekt21 DIE PROGRAMMIERSPRACHE GUAVA BEISPIEL I  Jede Liste von Bucket ist in einem BucketList-Objekt.  BucketList ist wiederum in SharedHashTable enthalten  Guava Compiler lässt keine Referenz zwischen Bucket- Objekten von verschiedenen Listen zu  ermöglicht erhebliche Verbesserungen.

22 Guava: ein Javadialekt22 DIE PROGRAMMIERSPRACHE GUAVA BEISPIEL I (Syntax) 2.2.1 - „Read“ & „Update“ Methoden  Alle Methoden müssen entweder als „read“ oder „update“ definiert werden  Default-Wert für Methoden ist „read“.  Die update-Methoden können den Zustand einer Instanz verändern z.B. put() aus SharedHashTable & BucketList  Konstruktoren sind immer „update“.

23 Guava: ein Javadialekt23 DIE PROGRAMMIERSPRACHE GUAVA BEISPIEL I (Syntax) 2.2.2 – Nebenläufige Prozesse in Monitors  Es gibt 2 Arten von Locks: * Update-Locks (Exklusive) * Read-Locks (Nicht Exklusive)  Guava Compiler kann eine „read“-Methode erkennen. z.B. SharedHashTable.get() ist eine „read“-Methode und wird automatisch so kompiliert, dass sie einen „read“-Lock benutzt.  Jede von get() gelieferte Zahl kann nun ohne Sorgen in Nebenläufigen Prozessen benutzt werden

24 Guava: ein Javadialekt24 DIE PROGRAMMIERSPRACHE GUAVA BEISPIEL II  Klasse StringBuffer.  Wird in Guava genau wie in Java implementiert.  Es gibt keine Erweiterung (extends) der Klasse  wird als Object implementiert  ist für single Threads.

25 Guava: ein Javadialekt25 DIE PROGRAMMIERSPRACHE GUAVA BEISPIEL II (Syntax) 2.2.3 - „ Read“ & „Update“ Parameters  In Guava müssen die Methoden spezifizieren, ob sie ihre Parameter updaten oder nicht.  Bei default sind alle Parameter read- only  Ein Parameter bekommt update wenn: * er der Ziel eine Zuweisung ist * eine update-Methode auf ihn aufgerufen wird * er als update-Parameter einer Funktion übergeben wird. z.B. StringBuffer print(): die Methode LocalOutputStream.print ist eine update-Methode (verändert den Zustand des output Streams)  s muss als update-parameter deklariert werden

26 Guava: ein Javadialekt26 DIE PROGRAMMIERSPRACHE GUAVA BEISPIEL II (Syntax) 2.2.4 – Regions  Schon bekannt: * Zugriff auf Object von 2 Verschiedenen Monitoren aus nicht erlaubt  Aber: * Ein Object kann von einem Monitor zum anderen übergeben werden (solange der zweite keine nebenläufige Benutzung durchführt).  Dieses Verhalten von Objekten wird durch die Begriffe: * Region * ownership erklärt.

27 Guava: ein Javadialekt27 DIE PROGRAMMIERSPRACHE GUAVA BEISPIEL II (Syntax)  Alle Objekt besitzen ein owner. (Buckets in BucketList, BucketList in SharedHashTable)  Bei Kompilierung weist Guava jeder Variablen eine Region zu.  Wenn 2 Variablen in derselben Region sind:  sie haben den gleichen owner  sie haben beide keinen owner (wird später erklärt)  In der Praxis können Programmierer Variablen Regionen zuweisen, durch Schlüsselwörter: * Kept * Lent

28 Guava: ein Javadialekt28 DIE PROGRAMMIERSPRACHE GUAVA BEISPIEL II (Syntax)  „kept“-Parameter befinden sich in derselben Region wie „this“  Default-Wert für Methodenparameter Sei MyClass object; - Wenn object ein Parameter der Method ist z.B. myMethod(object,param1); - oder die Methode wird von object aufgerufen z.B. object.myMethod(param1,param2);  objekt und die Parameter der Methoden besitzen denselben owner  befinden sich also in derselben Region.

29 Guava: ein Javadialekt29 DIE PROGRAMMIERSPRACHE GUAVA BEISPIEL II (Syntax)  „ lent“-Parameter befinden sich in einer anderen Region wie „this“  Für den Compiler heißt das: * dieser Parameter darf keinen Pointer (Referenz) zu irgendeiner anderen Komponente besitzen.  Kurz gesagt, „lent“ ist die Gewährleistung, dass es keine Referenz von (oder zu) diesem (Fremd-) Objekt geben wird.  Alle Objektparameter müssen „lent“ sein.  Warum??? - Ohne diese Regel wäre es dann möglich, für ein Objekt der Region A eine Referenz zu einem Objekt der Region B zu besitzen  2 Verschiedene Threads würden durch diese Referenzen zu einem Objekt gleichzeitig zugreifen können

30 Guava: ein Javadialekt30 DIE PROGRAMMIERSPRACHE GUAVA BEISPIEL II (Syntax) Wie funktioniert das???  In der Klasse StringBuffer wird der Parameter „s“ von der Methode append() als „lent“ deklariert.  append() darf keine Referenz von „s“ behalten.  In dem Monitor DataMonitor sieht man, wie StringBuffer.append() benutzt werden kann, um einen StringBuffer Objekt eines Monitors zu übergeben, der jetzt dieses Objekt updaten kann: - appendData kriegt StringBuffer Objekt (target) - target ruft StringBuffer.append() auf und übergibt lokalen StringBuffer „data“  Characters von data werden nach target kopiert - Am Ende: Modifizierte Daten werden in target sichtbar und es ist sichergestellt worden, dass keine nebenläufigen Prozesse da interveniert haben.

31 Guava: ein Javadialekt31 DIE PROGRAMMIERSPRACHE GUAVA BEISPIEL II (Syntax) 2.2.5 – Neue Objekte (new return value)  Eine Methode, die ein neues erzeugtes Objekt liefert, dass keine Referenzen zu anderen Objekten hat, liefert ein sogenanntes „new value“ zurück.  Solche Objekte haben keinen owner. z.B. In Klasse StringBuffer Methode: public “new” StringBuffer duplicate() { StringBuffer b = new StringBuffer(); …………………………… return b; }

32 Guava: ein Javadialekt32 DIE PROGRAMMIERSPRACHE GUAVA BEISPIEL II (Syntax)  Konstruktkoren erzeugen „immer“ neue return value  „immer“????  wenn sie einen „kept“-Parameter haben  dann nicht. weil in diesem Fall ist das neue Objekt in derselben Region wie der Parameter.  Aber es ist immer besser Objekte ohne Region zu erzeugen, damit man sie je nach Gebrauch einer Region zuweisen kann.  Wie macht man das???

33 Guava: ein Javadialekt33 DIE PROGRAMMIERSPRACHE GUAVA BEISPIEL II (Syntax) Sei: class X extends Monitor{ StringBuffer default = new StringBuffer („string“); update void moveString(update StringBuffer input in R, update MyClass out in R){......} update void moveDefault (update MyClass out in R) { moveString(default.duplicate(), out); }  default.duplicate() liefert ein neues StringBuffer-Objekt „b“ ohne Region  „b“ wird als Parameter zu moveString() übergeben  moveString() ist so definiert, dass der erste Parameter (input) in R seien muss  „b“ wird Region R zugewiesen.

34 Guava: ein Javadialekt34 DIE PROGRAMMIERSPRACHE GUAVA BEISPIEL II 2.2.6 – Lokale & Globale Methoden  In Guava haben wir: - Lokale Methoden, die den Zustand eines Monitors nicht verändern können. Sie können nur auf Object und Value arbeiten und sie eventuell verändern - Globale Methoden, die Monitore entweder lesen oder updaten können. Nur diese Veränderungen sind für andere Threads sichtbar.  Default-Wert für alle Object-und Value-Methoden ist „local“.  Methoden aus Monitor-Klassen sind immer „global“ und können nicht als „local“ definiert werden.

35 Guava: ein Javadialekt35 DIE PROGRAMMIERSPRACHE GUAVA BEISPIEL II  In den vorigen Beispielen waren alle Methoden aus DataMonitor und SharedHashTable globale Methoden.  Im Gegenteil dazu, waren die Methoden aus Bucket, BucketList und StringBuffer lokal.  Wie sieht das aus???

36 Guava: ein Javadialekt36 DIE PROGRAMMIERSPRACHE GUAVA BEISPIEL II  Die Methode y.getdefault() ruft eine Monitor-Methode auf variableX (die auch vom Typ Monitor ist)  muss als „global“ deklariert werden.  Da die Transitivität eine Eigenschaft der Globalität ist  müssen alle Methoden die y.getdefault() aufrufen als „global“ definiert werden.  Methoden, die „global update“ Methoden aufrufen müssen selbst als „global update“ definiert werden, auch wenn sie den Zustand ihrer eigenen Instanz nicht verändern. z.B. variableX.move() ist „global update“  y.doMove() muss es auch seien.

37 Guava: ein Javadialekt37 GLIEDERUNG  1- EINLEITLUNG  2- DIE PROGRAMMIERSPRACHE GUAVA 2.1- Klassenkategorien 2.2- Beispiele  3- COMPILER-CHECKING 3.1- „Region-“Checking 3.2- Reads & Updates Checking 3.3- „Global-“ Checking  4- PERFORMANCE 4.1- Nebenläufigkeit beim Lesen 4.2- Sperrgranülarität 4.3- Optimierung der Synchronisation 4.4- Objektmodel Verbesserungen  5- Mehr Beispiele  6- ZUSAMMENFASSUNG

38 Guava: ein Javadialekt38 KOMPILERSKONTROLLEN  In Guava müssen 3 Arten von Regeln sichergestellt werden: - Regionsregeln (Referenzen dürfen ihre Region nicht verlassen) - Lockregeln für Lesen und Schreiben - Global- und Lokalregeln für Methode

39 Guava: ein Javadialekt39 KOMPILERSKONTROLLEN Regionsüberprüfung  Diese Regeln garantieren, dass Objekte nie von mehreren nebenläufigen Prozessen zugegriffen werden können  In der (sehr komplizierten) Flanagan & Abadi Arbeit stellt man fest, das jede Methode: - eine Erlaubnis (Permission) besitzt, die dann sagt, welche Locks definiert sind, wenn die Methode aufgerufen wird. - eine „Protection Annotation“, die den Locks bescheid gibt, wie die Updates ausgeführt werden müssen.  Instanz-Variablen sind nur „spezielle“ Methoden aus dieser Flanagan & Abadi-Arbeit

40 Guava: ein Javadialekt40 KOMPILERSKONTROLLEN Regionsüberprüfung  Jede Variable hat einen Regionstyp und jede Methode (und Konstruktkor) haben eine Regionstypsignatur.  Diese Typ & Typsignaturen tragen dieselben Informationen wie die „Permissions“ und die „Protect Annotations“.  Der Regionstyp ist entweder der Name eines Locks oder null. * wenn null  kein Lock ist auf dieser Variablen definiert und ein Lock muss definiert werden, bevor eine Methode von dieser Variablen aufgerufen wird Regionstyp „r“ für Variable A  „r“ Lock ist aktive.  Regionstyp von „this“ und alle Instanzvariablen = myowner

41 Guava: ein Javadialekt41 KOMPILERSKONTROLLEN Überprüfungen für Reads & Updates  Diese Kontrollen garantieren, dass wenn eine „read“-Methode eines Monitors aufgerufen wird  sie darf kein Update auf Daten durchführen, die dann durch ein zweiter Thread benutzt wären, wenn er diese „read“-Methode auch aufrufen würde.  Es ist sicherer bei einer System-Entwicklung das sogenannte „two- phase-lock“ für „read“-Methoden zu benutzen, die parallel laufen.  Außerdem gelten noch folgenden Regeln:

42 Guava: ein Javadialekt42 KOMPILERSKONTROLLEN Überprüfungen für Reads & Updates  Eine „read“-Methode darf keine „global“ & „update global“ Methoden ausführen  Zustand des Monitors könnte verändert werden  Eine „read“-Methode darf keine Variable deren Regionstyp „myowner“ ist updaten. (es sind Instanzvariablen)  Eine „read“-Methode darf keine Updatemethode aufrufen von einer Variablen deren Regionstyp „myowner“ ist  Eine „read“-Methode darf keine Variable deren Regionstyp „myowner“ ist, an eine „update“-Methoden übergeben  Keine Methode darf eine „update“-Methoden auf Parameter ausrufen, die keine Update-Parameter sind.

43 Guava: ein Javadialekt43 KOMPILERSKONTROLLEN Global- und Lokalenregeln für Methode  Man kann nicht erwarten, dass bei mehreren Aufrufen von „global“- Methoden, immer wieder das gleiche Ergebnis geliefert wird („global“-Methoden sind auf der Monitor-Ebene definiert und sie werden durch mehrere Threads benutzt).  „global“-und „update“-Methoden dürfen nicht von „read“-Methoden aufgerufen werden  Alle „Zugriffe“ aus Monitoren durch Methoden sind bei default „global“  Alle Methoden (oder Konstruktoren), die eine globale Methode (oder Konstruktoren) aufrufen, müssen selbst als „global“ definiert werden.

44 Guava: ein Javadialekt44 GLIEDERUNG  1- EINLEITLUNG  2- DIE PROGRAMMIERSPRACHE GUAVA 2.1- Klassenkategorien 2.2- Beispiele  3- COMPILER-CHECKING 3.1- „Region-“Checking 3.2- Reads & Updates Checking 3.3- „Global-“ Checking  4- PERFORMANCE 4.1- Nebenläufigkeit beim Lesen 4.2- Sperrgranülarität 4.3- Optimierung der Synchronisation 4.4- Objektmodel Verbesserungen  5- Mehr Beispiele  6- ZUSAMMENFASSUNG

45 Guava: ein Javadialekt45 PERFORMANZEN Idempotent: ist eine Methode, deren Ergebnis von ihren Parametern abhängt, und mehrere nacheinender ausgeführte Aufrufe immer das gleiche Ergebnis liefern.  Java: - Hauptproblem ist die Synchronisation von Objekten, die durch Threads gemeinsam benutzt werden. - ist nicht in der Lage „local“-oder „read“ Methoden zu erkennen.  Im Gegenteil Guava: -lokale „read“-Methoden sind immer idempotent, solange ihre Ergebnisse „new value“ sind.

46 Guava: ein Javadialekt46 PERFORMANZEN Parallel Lesen  In multiplen Thread-Systemen ist das parallele Lesen notwendig für gutes Laufzeitverhalten.  In Java muss das parallele Lesen explizit programmiert werden  In Guava wird es vom Compiler automatisch zugelassen und durchgeführt.  Es ist eine Technik, die dem „two-phase-locking“ Transaktions- system ähnlich ist

47 Guava: ein Javadialekt47 PERFORMANZEN Parallel Lesen  Wenn ein Thread einen Monitor benutzt, wird er gelockt. - handelt es sich um eine „update“-Methode wird der konventionell exklusive Lock durchgeführt. - ist es aber eine „read“-Methode, wird der nicht- exklusive read Lock benutzt  kein anderer Thread ein „write“-Lock ausüben kann, aber „read“ Locks zugelassen sind.  Warum???  durch die Guava Regeln sind wir sicher, dass eine „read“- Methode nie einen Update durchführen wird, sie kann nur ihre eigenen Variablen verändern (unsichtbar für andere Threads)

48 Guava: ein Javadialekt48 PERFORMANZEN Sperrgranularität  Es wurde festgestellt, dass eine feine Sperrgranularität die Laufzeit verbessert (feine Sperrgranularität wird in Guava benutzt). z.B. Klasse SharedHashTable Instanzvariable BucketList [] bucket. - jede Methode aus der Klasse verursacht Veränderungen auf den Inhalt von bucket[] (d.h. auf BucketList Instanzen)  Der Compiler macht anstatt ein allgemeines Lock auf bucket[] kleinere Locks auf die bucket[]-Felder.  (bucket[lock])  Verschiedene Threads können gleichzeitig bucket [] benutzen ohne sich gegenseitig zu speren, vorausgesetzt sie greifen aus verschiedenen BucketList Instanzen auf bucket[] zu.

49 Guava: ein Javadialekt49 PERFORMANZEN Optimierung der Synchronisation Was ist die Synchronisation??  „unlock“-Operationen bedeuten in Java, dass alle Veränderungen, die durch einen Thread durchgeführt worden sind jetzt wieder an allen Stellen (für allen anderen Prozesse) sichtbar sein müssen  alle Felder des Cache-Speichers müssen gecheckt und ggf. synchronisiert werden  deswegen sind die synchronisierten Methoden so teuer.  In Guava muß, durch die Regions- und Owner-Prinzipien, eine „unlock“-Operation nur die Änderungen des aktuellen Monitors sichtbar gemacht werden  es wird nur eine bestimmte Adresse im Cache synchronisiert werden.  weniger Kosten

50 Guava: ein Javadialekt50 PERFORMANZEN Objektmodel Verbesserungen  In Java kann jedes Objekt sehr oft gelockt werden  es muss ein Lock-Feld im Header jedes Objektes vorgesehen seien  In Guava brauchen nur Monitore dieses Lock-Feld  Object & Value, die die meistens Instanzen sind, mit denen gearbeitet wird, benötigen keine Lock-Felder (können nicht gelockt werden)  Platzverbesserung im Speicher

51 Guava: ein Javadialekt51 GLIEDERUNG  1- EINLEITLUNG  2- DIE PROGRAMMIERSPRACHE GUAVA 2.1- Klassenkategorien 2.2- Beispiele  3- COMPILER-CHECKING 3.1- „Region-“Checking 3.2- Reads & Updates Checking 3.3- „Global-“ Checking  4- PERFORMANCE 4.1- Nebenläufigkeit beim Lesen 4.2- Sperrgranülarität 4.3- Optimierung der Synchronisation 4.4- Objektmodel Verbesserungen  5- Mehr Beispiele  6- ZUSAMMENFASSUNG

52 Guava: ein Javadialekt52 Mehr Beispielen SYNTAX A – Typkonversion Manche Typkonversionen (Casting) sind erlaubt:  Interfaces dürfen Klassen (Object, Monitor, Value) erweitern, aber alle Instanzen die dieses Interface implementieren, müssen vom Typ dieser Klassen seien.  Arrays sind Unterklassen von Value oder Object  sie können in diesen Klassen oder Interfaces, die sie implementieren (Local, Mobiles und References), gecastet werden.

53 Guava: ein Javadialekt53 Mehr Beispielen SYNTAX B – Umwandlung in Javabytecode B.1- Guavaklassen Wie kann man Guava in ganz normalen Java.class Datei umwandeln  Die Klasseninstanzen Object, Value, Monitor und die Interfaces Local, Mobile und Reference werden alle als Interface dargestellt. (weil die mehrfache Vererbung von Java nicht unterstützt wird. )  „$“ wird benutzt um die Guava-Klassen zu erkennen z.B. $Monitor, $Object,...  Die Synchronisationsmethoden werden nur aus den Klassen, die $Monitor implementieren, aufgerufen

54 Guava: ein Javadialekt54 Mehr Beispielen SYNTAX B – Umwandlung in Javabytecode B.2 – Benutzerdefinierte Klassen & Interfaces  Die abstrakten Klassen $MonitorImpl, $ObjectImpl, und $ValueImpl, werden benutzt, um die korrespondierenden Interfaces ($Monitor, $Value...) zu implementieren.  Klassen, die dann die Guava-Klassen erweitern, werden als Klassen, die diese abstrakten Klassen erweitern, definieren. class SharedHashTable extends Monitor  class SharedHashTable extends $MonitorImpl P.S Man könnten danach haben: class MyClass extends SharedHashTable  Interfaces, die Guava-Klassen erweitern, werden als Interfaces, die dann die neue Guava-Interfaces erweitern, definiert. interface MyInterface extends Value  interface MyInterface extends $Value

55 Guava: ein Javadialekt55 Mehr Beispielen SYNTAX B – Umwandlung in Javabytecode B.3 – Kopieren und Test auf Gleichheit  Alle Unterklassen von Value und Monitor, beinhalten eine Methode copy(), die automatisch generiert wird.  Bei der Zuweisung einer Valuevariable wird die copy()-Methode aufgerufen und eine „Tiefe Kopie“ wird durchgeführt.  Bei Monitor muss die Methode explizit aufgerufen werden  Bei Mobile- oder Instance-Variablen wird bei der Laufzeit entschieden, ob eine Javazuweisung (Referenz) oder eine Kopie durchgeführt wird

56 Guava: ein Javadialekt56 Mehr Beispielen SYNTAX B – Umwandlung in Javabytecode B.4 – Synchronisation  Im Allgemeinen müssen alle Monitor-Methoden synchronisiert werden. Nur „private“-und „protected“-Methoden nicht (sie können nur von „this“ aufgerufen werden und „this“ ist synchronisiert worden)  Zugriffe auf Monitor-Variablen müssen auch in einem synchronized()-Block durchgeführt werden (lockt den Monitor)

57 Guava: ein Javadialekt57 Zusammenfassung  Guava ist eine Java-ähnliche Sprache, die eine echte Monitor- abstraktion unterstützt  das garantiert eine komplette Trennung der Daten.  Bietet auch mehr Datentypen, als Java, die dann zwischen Monitoren getauscht werden können.  Sie unterstützt die Paralleldurchführung von „read“-Methoden  Die Programmierer müssen Klassen-Instanzen in Monitors, Value and Object unterteilen und eine Erweiterung der Javasyntax benutzen

58 Guava: ein Javadialekt58 Zusammenfassung  Es ist wichtig zu sagen, dass nur die Komplexität von Multi- Threading Systemen durch die Guava Verbesserungen vermindert wird.  Bei Multi-Threading Applikationen, bietet Guava eine erhebliche Verbesserung im Vergleich zu Java - die „synchronized“-und „unsynchronized“-Memory Konzepte werden durch das einfache Monitor-Modell ersetzt.

59 ENDE!!! DANKE FÜR IHRE AUFMERKSAMKEIT