Nochmal Ausschluß

GUAVA: EIN JAVADIALEKT OHNE
NICHT DETERMINISTICHE
EFFEKTE
NICOLAS NGANDEU
Seminar: Objektorientierte Programmiersprachen
WS 03/04
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
Guava: ein Javadialekt
2
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
Guava: ein Javadialekt
3
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.
Guava: ein Javadialekt
4
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.
Guava: ein Javadialekt
5
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
Guava: ein Javadialekt
6
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
Guava: ein Javadialekt
7
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.
Guava: ein Javadialekt
8
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
Guava: ein Javadialekt
9
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
Guava: ein Javadialekt
10
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)
Guava: ein Javadialekt
11
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
Guava: ein Javadialekt
12
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.
Guava: ein Javadialekt
13
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.
Guava: ein Javadialekt
14
DIE PROGRAMMIERSPRACHE GUAVA
Die Klassenkategorien - Klassenhierarchie

Die abstrakte Klasse „Instance“ ist
die Wurzel des Vererbungsbaums.

Alle konkreten Klassen sind
Unterklassen der 3 Klassenkategorien.

Zwischen der Klasse „Instance“ und
der Klassenkategorien befinden sich
Interface-Kategorien (----)

Jede Klassenkategorien implementiert
2 Interface-Kategorien
Guava: ein Javadialekt
15
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.
Guava: ein Javadialekt
16
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
Guava: ein Javadialekt
17
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
Guava: ein Javadialekt
18
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
Guava: ein Javadialekt
19
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)
Guava: ein Javadialekt
20
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 BucketObjekten von verschiedenen
Listen zu
 ermöglicht erhebliche
Verbesserungen.
Guava: ein Javadialekt
21
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“.
Guava: ein Javadialekt
22
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
Guava: ein Javadialekt
23
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.
Guava: ein Javadialekt
24
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 readonly
 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-parameterGuava: ein Javadialekt
deklariert werden
25
DIE PROGRAMMIERSPRACHE GUAVA
2.2.4 – Regions
BEISPIEL II (Syntax)

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.
Guava: ein Javadialekt
26
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
Guava: ein Javadialekt
27
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.
Guava: ein Javadialekt
28
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
Guava: ein Javadialekt
29
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.
Guava: ein Javadialekt
30
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;
}
Guava: ein Javadialekt
31
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???
Guava: ein Javadialekt
32
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);
}
}
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.

default.duplicate() liefert
Guava: ein Javadialekt
33
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.
Guava: ein Javadialekt
34
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???
Guava: ein Javadialekt
35
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.
Guava: ein Javadialekt
36
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
Guava: ein Javadialekt
37
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
Guava: ein Javadialekt
38
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
Guava: ein Javadialekt
39
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
Guava: ein Javadialekt
40
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 „twophase-lock“ für „read“-Methoden zu benutzen, die parallel laufen.

Außerdem gelten noch folgenden Regeln:
Guava: ein Javadialekt
41
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.
Guava: ein Javadialekt
42
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.

Guava: ein Javadialekt
43
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
Guava: ein Javadialekt
44
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.
Guava: ein Javadialekt
45
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“ Transaktionssystem ähnlich ist
Guava: ein Javadialekt
46
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)
Guava: ein Javadialekt
47
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.
Guava: ein Javadialekt
48
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
Guava: ein Javadialekt
49
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
Guava: ein Javadialekt
50
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
Guava: ein Javadialekt
51
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.
Guava: ein Javadialekt
52
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
Guava: ein Javadialekt
53
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
Guava: ein Javadialekt
54
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
Guava: ein Javadialekt
55
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)
Guava: ein Javadialekt
56
Zusammenfassung

Guava ist eine Java-ähnliche Sprache, die eine echte Monitorabstraktion 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
Guava: ein Javadialekt
57
Zusammenfassung

Es ist wichtig zu sagen, dass nur die Komplexität von MultiThreading 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.
Guava: ein Javadialekt
58
ENDE!!!
DANKE FÜR IHRE AUFMERKSAMKEIT