Präsentation herunterladen
Die Präsentation wird geladen. Bitte warten
Veröffentlicht von:Dedrich Leffel Geändert vor über 9 Jahren
1
JAVA/DSM A Platform for Heterogeneous Computing Serge F. Possono M. Technische Universität Muenchen (TUM) Lehr- und Forschungseinheit Informatik X Rechnertechnik und Rechnerorganisation/ Parallelrechnerarchitektur Themensteller:Prof. Dr. Michael GerndtProf. Dr. Michael Gerndt (SS 2001)
2
Übersicht TUM - Design von JAVA/DSM - Einige Programmiermodelle(DSM) - Motivationen
3
Problemstellung Hardware Unterschiede -Verschiedene Darstellung von Daten -Kodeanpassung für jede Architektur
4
Verteilte Beschaffenheit des Systems -heterogene Systeme sind auch verteilte Systeme -Notwendigkeit von Kommunikation zwischen Maschinen -Konvertierung von komplexen Daten
5
Einige Programmiermodelle Message Passing - message passing libraries.Basisfunktionen: send(), receive().Datenkonvertierungsroutinen: pack(), unpack().Keine Unterstützung von komplexen Daten
6
-Remote procedure call (RPC).Schnittstelle mit spezifischen Funktionen.automatisches Ein-/ und Auspacken von Nachrichten. Definition der Schnittstelle.Sichtbarkeit des Darstellungsunterschiedes von Datenwerten
7
-Java/RMI (verbessertes RPC).Referenzierung von Objekten zwischen Maschinen.Referenzierung und Replikation von Objekten möglich.Sichtbarkeit der Kohärenzverwaltung von Objektkopien (Replikationen)
8
DSM Gemeinsamer Adressraum in einem Netzwerk NUMA-Modell Zwei Klassen von DSM - Hardwarebasierte DSM -Softwarebasierte DSM
9
Prozessor Netzwerk Lokaler Speicher DSM Prinzip
10
Hardwarebasierte DSM -Spezielle Hardwareunterstützung für die gemeinsamen Speicher -Anforderung von Daten durch MMU kontrolliert. -z.B. DASH,Alewife
11
Softwarebasierte DSM Seitenbasierte DSM -Linearer gemeinsam genutzter Speicher -Page-Fault Handler fördert Seiten -Probleme: Falshe-Sharing -z.B: IVY,Treadmarks
12
Softwarebasierte DSM Objektbasierte DSM -Strukturierter Adressraum mit gemeinsam genutzten Objekten -Migration und Replikation -Probleme: Zugriff auf die gemeinsamen Daten sehr aufwendig -z.B: Emerald,Clouds
13
Softwarebasierte DSM Shared-Variable DSM -einzelne gemeinsam genutzte Variabeln -drei Klassen von Variabeln *gemeinsame Variabeln global sichtbar *Synchronisationsvariabeln *normale Variabeln (in lokal Speicher)
14
Fähigkeit und Nachteile von DSM.Unsichtbarkeit des verteilten Zustandes des Systems. Zugriff auf komplexe Strukturen mit Zeiger.Sichtbarkeit von Hardwareunterschieden. Gebrauch von Sondercompiler für automatische Datenkonvertierung
15
Treadmarks Ziel - Reduzierung des Kommunikationsumfangs In der Verwaltung von Datenkonsistenz
16
Design von Treadmarks Notwendigkeit der Synchronisation -Vermeidung von „Data Race“ Synchronisationsfunktionen - Locks (acquire,release) - Barriers
17
Lazy Release Konsistenz Konsistenzverwaltung zwischen dem letzten releaser und dem neuen acquirer Verringerung von Kommunikationsumfang
18
Multiple-Writer Protocols Mehrere Schreiber können gleichzeitig auf eine Seite zugreifen Benutzung von Diffs - Reduzierung von Bandwidth
19
Write(X) X: Create twin Make X writable X: twin X: Diff Release:
20
Programmieren mit Treadmarks Die Datei Tmk.h bietet eine Schnittstelle zu Treadmarks Die wichtigsten Funktionen der Schnittstelle: -Startup -Speicher Allokation -Synchronisation -Termination
21
Programmieren mit Treadmarks Die Routine Tmk_startup initialisiert die Treadmarks library und erstellt Prozesse auf anderen Maschinen. Die Routine Tmk_malloc kümmert sich um die Speicherallokation. Mit Tmk_free wird ein Speicherplatz freigegeben. Der Ruf von Tmk_exit beendet einen Prozess
22
Programmieren mit Treadmarks Die Locks werden während die Durchführung von Tmk_startup hergestellt und initialisiert Übernahme der Lockkontrolle: Tmk_lock_acquire (lock_identifier) Locksfreigabe: Tmk_lock_release(lock_identifier)
23
Warum Java ? Portabilität - ArchitekturunabhängigeCodegenerierung (dank JVM) - Unsichtbarkeit der Maschinenarchitektur
24
Warum DSM ? Gemeinsamer Adressraum von physikalisch getrennten Speichern automatischeVerwaltung von Kommunikation zwischen Maschinen
25
Design Von Java/DSM Eine JVM für jeden Maschine (Knoten) Objekte werden in verteiltem Adressraum gespeichert Unterstützung von Java API Keine Migration von Threads zwischen Maschinen Keine Unterschiede zwischen entfernten und lokalen Objekten
26
Speicher Verwaltung Garbage collection wird unabhängig auf jeder Maschine ausgeführt Entfernte Referenzen zu lokalen Objekten sind bekannt um falsche Vernichtung zu vermeiden
27
Garbage Collection Algorithmus Der GC auf jeder Maschine verwaltet zwei Listen Die export Liste für entfernte Referenzen zu lokalen Objekten Die import Liste für Referenzen zu entfernten Objekten Benutzung von „weighted reference counting“
28
Datenkonvertierung Der handle von einem Objekt zeigt auf seinen body und zu einer Struktur, die den Typ von jedem Feld enhält Objekte auf einer Seite haben die gleiche Grösse Der body enthält einen Rückzeiger zum handle
29
Änderungen in JVM Eine Treadmarksroutine ladet den heap Klassen sind in dem gemeinsamen Speicher Jedes Objekt zeigt auf seinen handle (Unterstützung von Datenkonvertierung)
30
Zusammenfassung Hardwareunterschiede und Kommunikationsbedürfnisse Message Passing und DSM lösen nicht alle Probleme Java/DSM hat zu einer leichten Änderung von der JVM geführt
Ähnliche Präsentationen
© 2024 SlidePlayer.org Inc.
All rights reserved.