JavaParty

Universität Karlsruhe (TH)
Forschungsuniversität · gegründet 1825
Rechnerbündel
(Cluster Computing)
Wintersemester 2005/06
Prof. Dr. Walter F. Tichy
Thomas Moschny
Inhalt
• JavaParty: „Javas Begleiter für verteiltes
Rechnen“
• Java-Konzepte für parallele und
verteilte parallele Systeme
• Ziele und Funktionsweise von JavaParty
• Schneller entfernter Methodenaufruf KaRMI
• Schnelle Objektserialisierung uka.transport
• Transparente maschinenüberspannende Kontrollfäden
• Replizierte, verteilte Objekte
• JavaParty Anwendungen
• Die ursprüngliche Version dieses Foliensatzes stammt von Bernhard Haumacher.
Universität Karlsruhe (TH)
Forschungsuniversität
·
gegründet 1825
Vorlesung Rechnerbündel · W. F. Tichy, Th. Moschny
2
Wissenschaftliches Rechnen
mit Java
Ja
va
• klares, objektorientiertes Konzept
G
• Sprachdesign
• automatische Speicherbereinigung
•
•
•
•
•
ra
nd
e.
or
g
Portabilität: Java Virtuelle Maschine
reicher Fundus an Bibliotheken
Basis -Infrastruktur für verteiltes Rechnen
breite Akzeptanz
Java wird gelehrt und gelernt
Universität Karlsruhe (TH)
Forschungsuniversität
·
gegründet 1825
Vorlesung Rechnerbündel · W. F. Tichy, Th. Moschny
3
DSM Systeme
• DSM „gaukelt“ transparent für die Anwendung
einen gemeinsamen Speicher vor.
Applikation
Betriebssystem
der beteiligten
Rechenknoten
DSM Abstraktion
P
P
P
P
M
M
M
M
Netzwerk
Universität Karlsruhe (TH)
Forschungsuniversität
·
gegründet 1825
Vorlesung Rechnerbündel · W. F. Tichy, Th. Moschny
4
Java DSM Systeme
• z.B. Java/DSM (auf TreadMarks)
Java Anwendung
Java virtuelle Maschine
Betriebssystem
der beteiligten
Rechenknoten
DSM Abstraktion
P
P
P
P
M
M
M
M
Netzwerk
Universität Karlsruhe (TH)
Forschungsuniversität
·
gegründet 1825
Vorlesung Rechnerbündel · W. F. Tichy, Th. Moschny
5
Java DSM Systeme
• Von DSM geerbte Probleme
• Deckungsproblem der Speicherkonsistenz des DSM
mit den Speicherkonsistenz-Anforderungen der
virtuellen Maschine
• Anpassungen an die Java VM notwendig?
• False Sharing
• Java Objekte sind nicht deckungsgleich mit Speicherseiten
• „Viele kleine“ Objekte in Java verschärfen das Problem
• Ausweg: Objektbasiertes DSM (Objekte statt Seiten),
aber:
• Standard Java VM nicht mehr einsetzbar
• nicht mehr plattformunabhängig
Universität Karlsruhe (TH)
Forschungsuniversität
·
gegründet 1825
Vorlesung Rechnerbündel · W. F. Tichy, Th. Moschny
6
JavaParty Ansatz
• Keine besondere Anforderung an das
Betriebsystem
• einzige Voraussetzung: Java VM verfügbar
• Basiert auf Standard Java VM („pure Java“)
• Sprache JavaParty ist eine reine QuellcodeTransformation JavaParty → Java.
• Das Laufzeitsystem ist in Java implementiert.
• Spiegelt dem Anwendungsprogramm eine
verteilte Virtuelle Maschine vor
• Entfernte Objekte werden transparent in der
Umgebung verteilt.
Universität Karlsruhe (TH)
Forschungsuniversität
·
gegründet 1825
Vorlesung Rechnerbündel · W. F. Tichy, Th. Moschny
7
JavaParty Ansatz
• JavaParty erzeugt die Illusion einer verteilten
Java VM.
Verteilte JavaParty
Laufzeitumgebung
JavaParty Applikation
VM
VM
VM
VM
P
P
P
P
M
M
M
M
Standard Java VM
pro Knoten
Netzwerk
Universität Karlsruhe (TH)
Forschungsuniversität
·
gegründet 1825
Vorlesung Rechnerbündel · W. F. Tichy, Th. Moschny
8
Java für parallele Systeme
• Java ist gut geeignet für parallele
Programmierung bei gemeinsamem Speicher
(SMP Modell)
• Parallele Kontrollfäden sind in die Sprache integriert
• java.lang.Thread
• Synchronisationsmechanismen als Sprachprimitive
• synchronisierte Methoden “synchronized void foo()”
• synchronisierte Blöcke “synchronized (obj) { ... }”
• Inter -Thread - Kommunikation
• java.lang.Object: wait() & notify()
Universität Karlsruhe (TH)
Forschungsuniversität
·
gegründet 1825
Vorlesung Rechnerbündel · W. F. Tichy, Th. Moschny
9
Java für verteilte parallele
Systeme
• Keine Sprachunterstützung, aber Bibliotheken:
• Alternative 1: Socketbibliothek (java.net)
☹Keine entfernten Objektreferenzen
• Nur Kommunikationsendpunkte
☹Keine Methodenaufrufe an entfernt liegende Objekte
• Kommunikation über Botschaften
• Implementierung eines eigenen Kommunikationsprotokolls
☹Keine automatische Speicherbereinigung
Universität Karlsruhe (TH)
Forschungsuniversität
·
gegründet 1825
Vorlesung Rechnerbündel · W. F. Tichy, Th. Moschny
10
Java für verteilte parallele
Systeme
• Alternative 2: Entfernter Methodenaufruf java.rmi.*
☺Entfernte Referenzen auf Objekte
☺Kein eigenes Kommunikationsprotokoll notwendig
☺Verteilte automatische Speicherbereinigung
☹Explizite Namensbindung (registry)
☹Kein entfernter Zugriff auf Instanzvariablen, statische Methoden
und statische Variablen
☹Deklaration zusätzlicher Ausnahmebedingungen
☹Explizite Objektplazierung durch lokale Erzeugung
☹Keine Ortstransparenz
☹Keine Objektmigration
→nur geeignet für Client-Server-Programmierung
Universität Karlsruhe (TH)
Forschungsuniversität
·
gegründet 1825
Vorlesung Rechnerbündel · W. F. Tichy, Th. Moschny
11
JavaParty
• Vorteile:
☺Keine explizite Namensbindung
☺Entfernter Zugriff auf die gesamte Klasse möglich
☺Keine zusätzlichen Ausnahmebedingungen
☺Entfernte Objekterzeugung, Platzierungsstrategien
☺Ortstransparenz
☺Objektmigration
☺Übernimmt Javas Thread -Konzept
Universität Karlsruhe (TH)
Forschungsuniversität
·
gegründet 1825
Vorlesung Rechnerbündel · W. F. Tichy, Th. Moschny
12
JavaParty
• JavaParty =
• Verallgemeinert Javas Programmiermodell für eine
potentiell verteilte virtuelle Maschine.
• Verteilt transparent Java-Objekte und Threads.
• Vorteile:
• Verbirgt Architekturdetails der Hardware-Plattform
(SMP, DMP, Cluster, Cluster aus SMP).
• Erleichtert Umstieg zu DMPs oder heterogenen
Systemen.
• Benutzt Javas (RMIs) entfernten Methodenaufruf.
Universität Karlsruhe (TH)
Forschungsuniversität
·
gegründet 1825
Vorlesung Rechnerbündel · W. F. Tichy, Th. Moschny
13
Abläufe beim entfernten
Methodenaufruf
VM1 VM2
Klient
x=
RMI
ss. foo(a, b)
Stu
b
Stellvertreter
Stellvertreter ss
entfernte
Referenz
Dienstgeber
Dienstgeber
Dienstgeber
Objekt
Objekt
foo(a, b)
Verpacken / Auspacken
von Parametern
foo() ~ Methode Nr. 3
Ske
leto
n
Skelett
Skelett kk
generiert
Referenzverwaltung
Transportschicht
Netzwerk
Netzwerk
Universität Karlsruhe (TH)
Forschungsuniversität
·
gegründet 1825
Vorlesung Rechnerbündel · W. F. Tichy, Th. Moschny
14
RMI: Applikationsanpassungen
• Ausgangscode
class
class OverdrawnException
OverdrawnException extends
extends Exception
Exception {}
{}
public
public class
class BankAccount
BankAccount {{
public
public static
static int
int blz;
blz;
public
public int
int acountNumber;
acountNumber;
public
public void
void deposit(float
deposit(float amount)
amount)
{{ ...
}
... }
public
public void
void withdraw(float
withdraw(float amount)
amount) throws
throws OverdrawnException
OverdrawnException
{{ ...
... }}
public
public float
float balance()
balance()
{{ ...
}
... }
}}
BankAccount
BankAccount bb == new
new BankAccount(
BankAccount( ...
... );
);
b.deposit(100);
b.deposit(100);
Universität Karlsruhe (TH)
Forschungsuniversität
·
gegründet 1825
Vorlesung Rechnerbündel · W. F. Tichy, Th. Moschny
15
RMI: Applikationsanpassungen
• Deklaration der entfernt aufrufbaren Schnittstelle
import
import java.rmi.Remote;
java.rmi.Remote;
import
import java.rmi.RemoteException;
java.rmi.RemoteException;
public
public interface
interface BankAccountIntf
BankAccountIntf extends
extends Remote
Remote {{
/**
/** Zugriffsmethode
Zugriffsmethode für
für blz
blz */
*/
public
public int
int getBLZ()
getBLZ() throws
throws RemoteException;
RemoteException;
/**
/** Zugriffsmethode
Zugriffsmethode für
für acountNumber
acountNumber */
*/
public
public int
int getAccountNumber()
getAccountNumber() throws
throws RemoteException;
RemoteException;
public
public void
void deposit(float
deposit(float amount)
amount) throws
throws RemoteException;
RemoteException;
public
void
withdraw(float
amount)
public void withdraw(float amount)
throws
throws OverdrawnException,
OverdrawnException, RemoteException;
RemoteException;
public
public float
float balance()
balance() throws
throws RemoteException;
RemoteException;
}}
Universität Karlsruhe (TH)
Forschungsuniversität
·
gegründet 1825
Vorlesung Rechnerbündel · W. F. Tichy, Th. Moschny
16
RMI: Applikationsanpassungen
• Änderung der Implementierungsklasse
import
import java.rmi.RemoteException;
java.rmi.RemoteException;
import
import java.rmi.server.UnicastRemoteObject;
java.rmi.server.UnicastRemoteObject;
public
public class
class BankAccount
BankAccount extends
extends UnicastRemoteObject
UnicastRemoteObject
implements
implements BankAccountIntf
BankAccountIntf
{{
public
public int
int getBLZ()
getBLZ() {return
{return blz;
blz; }}
public
public int
int getAccountNumber()
getAccountNumber() {return
{return accountNumber;
accountNumber; }}
public
public void
void deposit(float
deposit(float amount)
amount) throws
throws RemoteException
RemoteException
{{ ...
... }}
public
public void
void withdraw(float
withdraw(float amount)
amount)
throws
throws RemoteException,
RemoteException, OverdrawnException
OverdrawnException
{{ ...
... }}
public
public float
float balance()
balance() throws
throws RemoteException
RemoteException
{{ ...}
...}
}}
Universität Karlsruhe (TH)
Forschungsuniversität
·
gegründet 1825
Vorlesung Rechnerbündel · W. F. Tichy, Th. Moschny
17
RMI: Applikationsanpassungen
server-side
String
String url
url == "rmi://myserver.nowhere.com/account";
"rmi://myserver.nowhere.com/account";
try
try {{
BankAccount
BankAccount bb == new
new BankAccount(
BankAccount( ...
... );
);
java.rmi.Naming.bind(url,
b);
java.rmi.Naming.bind(url, b);
}}
catch
catch (RemoteException
(RemoteException r)
r) {{ ...}
...}
catch
catch (java.net.MalformedURLException
(java.net.MalformedURLException m)
m) {{ ...
... }}
catch
catch (java.rmi.AlreadyBoundException
(java.rmi.AlreadyBoundException a)
a) {{ ...
... }}
client-side
• Anpassungen bei Erzeugung und Benutzung
try
try {{
BankAccount
BankAccount bb == (BankAccount)
(BankAccount)
java.rmi.Naming.lookup(url);
java.rmi.Naming.lookup(url);
b.deposit(100);
b.deposit(100);
}}
catch
catch (RemoteException
(RemoteException ex)
ex) {{ ...
... }}
catch
catch (NotBoundException
(NotBoundException ex)
ex) {{ ...
... }}
catch
catch (MalformedURLException
(MalformedURLException ex)
ex) {{ ...
... }}
Universität Karlsruhe (TH)
Forschungsuniversität
·
gegründet 1825
Vorlesung Rechnerbündel · W. F. Tichy, Th. Moschny
18
Dasselbe Beispiel mit JavaParty
class
class OverdrawnException
OverdrawnException extends
extends Exception
Exception {}
{}
public
public remote
remote class
class BankAccount
BankAccount {{
public
public static
static int
int blz;
blz;
public
public int
int acountNumber;
acountNumber;
public
public void
void deposit(float
deposit(float amount)
amount)
{{ ...
... }}
public
public void
void withdraw(float
withdraw(float amount)
amount) throws
throws OverdrawnException
OverdrawnException
{{ ...
... }}
public
public float
float balance()
balance()
{{ ...
... }}
}}
BankAccount
BankAccount bb == new
new BankAccount(
BankAccount( ...
... );
);
b.deposit(100);
b.deposit(100);
Universität Karlsruhe (TH)
Forschungsuniversität
·
gegründet 1825
Vorlesung Rechnerbündel · W. F. Tichy, Th. Moschny
19
Dasselbe Beispiel mit JavaParty
• Änderungsvolumen:
• hier: nur 2%
• dagegen 75% bei RMI-oder bei Socket-Version.
• Es wird eine Quellcode-Transformation
vorgenommen.
• Diese Arbeit kann ein mechanischer Übersetzer
machen.
• Rückführung auf RMI und pures Java
• Das transformierte Programm ist genauso portabel wie
die ursprüngliche Anwendung.
Universität Karlsruhe (TH)
Forschungsuniversität
·
gegründet 1825
Vorlesung Rechnerbündel · W. F. Tichy, Th. Moschny
20
Die JavaParty Transformation
JavaParty Code
JavaParty Übersetzer:
Transformation
Java + RMI
RMI Stub Generator
Std. Java-Übersetzer
Portabler ByteCode
Universität Karlsruhe (TH)
Forschungsuniversität
·
gegründet 1825
Vorlesung Rechnerbündel · W. F. Tichy, Th. Moschny
21
JavaParty: Transparente
entfernte Objekte
Eine (entfernte) Klasse R besteht aus
Instanz -Methoden
statischen Methoden
Konstruktoren
public int foo(int x) {}
static int bar(int x) {}
public R() {}
r.foo(42);
R.bar(42)
new R()
„entfernte Klasse“
„KonstruktorObjekte“
I
M
R
(
✓)
Instanz -Variablen
statischen Variablen
int a;
static int b;
r.a = 13;
R.b = 13;
„generierte get- und set-Methoden“
Universität Karlsruhe (TH)
Forschungsuniversität
·
gegründet 1825
Vorlesung Rechnerbündel · W. F. Tichy, Th. Moschny
22
JavaParty: Bestandteile der
Transformation
• Instanzenanteil…
• wird transformiert in Instanzenobjekt.
• repräsentiert ein entferntes Objekt.
• enthält dessen
• Instanzenvariablen,
• nicht-statische Methoden.
• ist entfernt zugreifbar über RMI
• über eine generierte entfernte Schnittstelle.
• Zusätzlich werden set()- und get()- Methoden für die
Instanzvariablen generiert.
• Die RMI-Ausnahmebedingungen werden intern behandelt.
Universität Karlsruhe (TH)
Forschungsuniversität
·
gegründet 1825
Vorlesung Rechnerbündel · W. F. Tichy, Th. Moschny
23
JavaParty: Bestandteile der
Transformation
• Statischer Anteil…
• wird transformiert in Klassenobjekt.
• repräsentiert die entfernte Klasse,
• enthält also deren
• statische Variablen,
• statische Methoden.
• existiert genau einmal in der verteilten Umgebung,
• entspricht der Semantik einer Java-Klasse, ausgedehnt auf die
verteilte Umgebung
• ist entfernt zugreifbar über RMI
• über eine generierte entfernte Schnittstelle.
• Zusätzlich werden set()- und get()- Methoden für die statischen
Variablen generiert.
• Die RMI-Ausnahmebedingungen werden intern behandelt.
Universität Karlsruhe (TH)
Forschungsuniversität
·
gegründet 1825
Vorlesung Rechnerbündel · W. F. Tichy, Th. Moschny
24
JavaParty: Bestandteile der
Transformation
• Konstruktoren…
• werden transformiert in Konstruktorobjekte.
• erlauben entferntes Anlegen von Objekten.
• Pro Knoten und entfernter Klasse existiert genau ein
Konstruktorobjekt.
• ist entfernt zugreifbar über RMI
• über eine generierte entfernte Schnittstelle.
• Pro Konstruktor der Klasse wird eine Fabrikmethode
generiert.
Universität Karlsruhe (TH)
Forschungsuniversität
·
gegründet 1825
Vorlesung Rechnerbündel · W. F. Tichy, Th. Moschny
25
Zugriff auf ein entferntes Objekt
in JavaParty
Stellvertreter (JavaParty -Handle): uniformer Zugriff auf entfernte Klasse + Migration
JP
Handle für R mit Signatur der Originalklasse
foo(...)
new R(...)
static bar(...)
RMI
RMI Stub
RMI Stub
entfernter
JP
RMI Stub
Methodenaufruf
RMI Skeleton
RMI Skeleton
RMI Skeleton
Instanz
Implementierung
Klassen
Implementierung
Konstruktor
Objekt
Universität Karlsruhe (TH)
Forschungsuniversität
·
gegründet 1825
Vorlesung Rechnerbündel · W. F. Tichy, Th. Moschny
26
Objektmigration in JavaParty
Handle für R
RMI Stub
RMI Skeleton
Instanz
Implementierung
Universität Karlsruhe (TH)
Forschungsuniversität
·
gegründet 1825
RMI Stub
VM1
VM2
migrate
+redirect
Vorlesung Rechnerbündel · W. F. Tichy, Th. Moschny
RMI Skeleton
Instanz
Implementierung
27
Klassendiagramm nach der
JavaParty Transformation
remote class T { ... }
remote class R extends T { ... }
RemoteObject
RemoteObject
java
java.rmi.Remote
.rmi.Remote
java.rmi.server.UnicastRemoteObject
java.rmi.server.UnicastRemoteObject
extends
implements
TT_instance_intf
_instance_intf
TT
T_class_intf
T_class_intf
R
R_instance_intf
_instance_intf
R
R
Universität Karlsruhe (TH)
Forschungsuniversität
·
gegründet 1825
T_class_impl
T_class_impl
R_instance_impl
R_instance_impl
R_class_intf
R_class_intf
JP Fassade
T_instance_impl
T_instance_impl
R_class_impl
R_class_impl
RMI Implementierung
Vorlesung Rechnerbündel · W. F. Tichy, Th. Moschny
28
Das Laufzeitsystem
• Die JavaParty-Transformation benutzt
• Methodenfernaufruf (RMI)
• Objektserialisierung (Marshalling)
• Problem: Methodenaufrufe mit Objektargumenten über
Ethernet dauern Millisekunden.
• RMI ist nicht „cluster-tauglich“
• Fokus von RMI liegt auf WAN-/Internet-Applikationen
• mit anonymen Klienten,
• instabilen Netzwerken,
• unterstützt nur Ethernet.
• Fokus der Objektserialisierung:
• persistente Speicherung,
• Objektversendung zu anonymen Klienten.
Universität Karlsruhe (TH)
Forschungsuniversität
·
gegründet 1825
Vorlesung Rechnerbündel · W. F. Tichy, Th. Moschny
29
Das Laufzeitsystem
• Javas Objektserialisierung…
• ist extrem benutzerfreundlich:
• Der Programmierer muss im wesentlichen nur "extends
Serializable" hinzufügen.
• Die Objektserialisierung benutzt dafür dynamische TypIntrospektion.
• ist zur persistenten Objektspeicherung geeignet,
• speichert ausführliche Typinformation.
• Nicht für Netzwerkübertragung optimiert:
• keine optimierter Zugriff auf Sende- und Empfangspuffer
• keine Wiederverwendung von übertragener Typinformation in
Folgeaufrufen
Universität Karlsruhe (TH)
Forschungsuniversität
·
gegründet 1825
Vorlesung Rechnerbündel · W. F. Tichy, Th. Moschny
30
Effiziente Objektserialisierung
uka.transport
450
t
400
sp
ar
350
300
ge
250
150
100
95
%
200
Exemplarisch: Zeit für
einen einfachen entfernten
Methodenaufruf in µs.
Ohne Typintrospektion
Schlanke Typ-Codierung
Direkter Pufferzugriff
50
Ohne Typ-Wiederholung
0
Universität Karlsruhe (TH)
Forschungsuniversität
·
gegründet 1825
Vorlesung Rechnerbündel · W. F. Tichy, Th. Moschny
31
Effizienter entfernter
Methodenaufruf: KaRMI
• KaRMI ist ein Ersatz für RMI, der speziell auf den Einsatz in
Rechnerbündeln hin ausgelegt ist.
• Benutzt die effiziente Objektserialisierung uka.transport.
• uka.transport bietet außerdem eine steckbare Transportschicht mit
Adaptern für
• Ethernet
• Myrinet / GM
• Myrinet / ParaStation
• KaRMI implementiert einen schnellen transparenter lokaler
Methodenaufruf an entfernten Objekten.
• …also an solchen, die zwar semantisch entfernt, aber physikalisch lokal
sind, d.h. sich in derselben virtuellen Maschine befinden.
• KaRMI integriert die RMI Stellvertreter (Stubs) und die JavaParty
Stellvertreter (Handles) in eine Klasse.
Universität Karlsruhe (TH)
Forschungsuniversität
·
gegründet 1825
Vorlesung Rechnerbündel · W. F. Tichy, Th. Moschny
32
Transparente maschinenüberspannende Kontrollfäden (1)
• Während eines Fernaufrufs wechselt der Kontrollfluss auf
einen anderen Knoten.
• Problem: Java Threads sind an ihre virtuelle Maschine gebunden.
• RMI: Simulation durch mehrere lokale Kontrollfäden
VM 1
VM 2
Objekt a Objekt b
Objekt c
t1
t1 ≠ t3
Universität Karlsruhe (TH)
Forschungsuniversität
·
gegründet 1825
Client
Server
Server
Client
t2
t3
Vorlesung Rechnerbündel · W. F. Tichy, Th. Moschny
33
Transparente maschinenüberspannende Kontrollfäden (2)
• Problem: t1 und t3 haben keine Beziehung
• Sperren, die t1 besitzt, können von t3 nicht betreten werden
• KaRMI-Lösung: Verwende einen eindeutigen
Stellvertreter t1 für den maschinenüberspannenden
Kontrollfaden auf VM 1.
VM 1
VM 2
Objekt a Objekt b
Objekt c
t1
Client
Server
Server
Client
t2
t1
Universität Karlsruhe (TH)
Forschungsuniversität
·
gegründet 1825
Vorlesung Rechnerbündel · W. F. Tichy, Th. Moschny
34
Replizierte Objekte (1)
• Entfernte Objekte…
• sind auf bestimmten Knoten angelegt.
• Sie können migriert werden, aber das ist eine teure Operation.
• werden an ihrem aktuellen Aufenthaltsort benutzt.
• verursachen Fernzugriffe bei ihrer Verwendung.
• Lokale (Java-) Objekte…
• sind auf den Knoten beschränkt, auf dem sie angelegt wurden.
• sind nur lokal, dafür aber schnell und direkt zugreifbar.
• werden bei Übergabe in entferntem Methodenaufruf kopiert.
• Neu: Transparent replizierte Objekte…
•
•
•
•
sind auf allen Knoten lokal (als Kopie) verfügbar.
werden lokal angesprochen.
gibt es pro Knoten genau einmal.
werden über Synchronisation konsistent gehalten.
Universität Karlsruhe (TH)
Forschungsuniversität
·
gegründet 1825
Vorlesung Rechnerbündel · W. F. Tichy, Th. Moschny
35
Replizierte Objekte (2)
• Deklaration mittels neuem Schlüsselwort "replicated".
• Es wird immer eine ganze Klasse (d.h. als repliziert
gekennzeichnet).
• Anlegen eines replizierten Objektes: "new P"
• liefert "echte" Java-Referenz auf das lokale Replikat
• kein Proxy-Objekt,
• kein Umschreiben von Variablenzugriffen in get()/set()-Methoden.
• Implizit werden Replikate auf allen (anderen) Knoten angelegt.
• in Fernaufrufen werden allerdings die Referenzen durch die
Referenz im Zielknoten ersetzt.
• Synchronisation: Neue Schlüsselwörter "shared",
"exclusive" und "collective".
• Neue/erweiterte Semantik für die Synchronisation
replizierter Objekte.
Universität Karlsruhe (TH)
Forschungsuniversität
·
gegründet 1825
Vorlesung Rechnerbündel · W. F. Tichy, Th. Moschny
36
Replizierte Objekte (3)
• Warum benötigt man neue/erweiterte Semantik
für die Synchronisation?
• (Standard-)Java-Synchronisation ist immer exklusiv.
Für Replikation nicht sinnvoll, denn:
• Replikation eingeführt insbesondere für verteilten Lesezugriff.
• Wenn immer nur ein Zugriff erlaubt wäre, ginge mögliche
Parallelität verloren.
• Wenn vor jedem Zugriff alle anderen Replikate gesperrt
werden müssten, wäre der Zugriff nicht mehr lokal.
• Javas Synchronisationsprimitive unterstützen kein
Protokoll, das viele Leser, aber höchstens einen
Schreiber zulässt.
Universität Karlsruhe (TH)
Forschungsuniversität
·
gegründet 1825
Vorlesung Rechnerbündel · W. F. Tichy, Th. Moschny
37
Replizierte Objekte (4)
• Neue Synchronisationsmodi für repl. Objekte:
• Paralleler, verteilt lokaler Lesezugriff
• viele Leser über eine "geteilte" Sperre
• verwende shared synchronized(p) überall
• Exklusiver lokaler Schreibzugriff
•
•
•
•
ein Schreiber über eine "exklusive" Sperre
anschließende Zustandsfortschreibung aller Replikate
verwende shared synchronized(p) sonst
verwende exclusive synchronized(p) beim Schreiber
• Kollektive Modifikation
• viele Schreiber auf nicht überlappenden Teilen des Replikates
• anschließende Zustandsfortschreibung aller Replikate
• verwende collective synchronized(p) überall
• Modi dürfen nicht gemischt werden!
• Hier nur grober Überblick, weitere Details wichtig: z.B. Signale.
Universität Karlsruhe (TH)
Forschungsuniversität
·
gegründet 1825
Vorlesung Rechnerbündel · W. F. Tichy, Th. Moschny
38
JavaParty Anwendungen
• Partnerprojekt am IPD Gruppe Lockemann:
• Paralleles DataMining auf Rechnerbündeln in JavaParty
• SQL- und DataMining-Anfragen mit visueller Anfrageoberfläche
• Parallelisierung:
• Kontrollparallelität: Operatoren
• Datenparallelität: Tabellenzerteilung (Partitionierung)
• Kooperation mit dem Impact Projekt
• Fragestellung: Wie kann allgemein ein datenparalleler
Algorithmus (SPMD) formuliert werden, der auf einem verteilten
Objektgraphen operiert?
• Website: http://impact.sourceforge.net: Explicit Time Integration
General Purpose Finite Element Program
• In neueren Versionen von JavaParty Unterstützung für replizierte
Objekte (siehe vorne).
Universität Karlsruhe (TH)
Forschungsuniversität
·
gegründet 1825
Vorlesung Rechnerbündel · W. F. Tichy, Th. Moschny
39
JavaParty: Zusammenfassung
• JavaParty bietet
• Javas Programmiermodell verallgemeinert für eine potentiell
verteilte virtuelle Maschine
• Beherrschung des verteilter Adressraumes durch transparente
entfernte Objekte
• entfernte maschinenüberspannende Kontrollfäden nutzen
Rechenleistung
• optimiertes Kommunikationssystem durch
•
•
•
•
effiziente Objektserialisierung
schnellen entfernten Methodenaufruf
schnellen entfernten Methodenaufruf für lokale Objekte
Ausnutzung von schnellen Netzwerktechnologieen
• Replikation bietet Ansätze für datenparallele JavaParty-
Programme.
Universität Karlsruhe (TH)
Forschungsuniversität
·
gegründet 1825
Vorlesung Rechnerbündel · W. F. Tichy, Th. Moschny
40