vs6.2 1

6.2 Objektpufferung(caching)

= dynamische, ad-hoc-Replikation einer Primärkopie: Zugriffswilliger beschafft sich temporär eine lokale Kopie

cache oderPufferspeicher = Bereich zum Unterbringen lokaler Kopien

im Prozessor: Register, z.B. für Teil des Kellers

im Prozessor: Hauptspeicherpuffer für Speicherblöcke

im Arbeitsspeicher: Rahmen für Seiten aus Externspeicher

im Dateisystem: Text- und Bilddateien von Webserver

vs6.2 2

6.2.1 Snoopy Cache

(auch snooping cache) in Mehrprozessorsystemen

Speicher(Primärkopien). . . . . . .

Prozessoren

Bus

Objekt = Speicherblock

Operation = Lese/Schreibzugriff auf SpeicherzelleImplementierung: Hardware

Zugriff auf Adresse a veranlasst Caching des Blocks, der a enthält;

gegebenenfalls wird dafür ein anderer Blockverdrängt

Cache Cache Cache

vs6.2 3

Schreibzugriff:

1. Block wird im Cache modifiziert.

2. Block wird im Speicher modifiziert (write-through).

3. Alle Prozessoren sind „neugierig“ (snoopy): sie „schnüffeln“ (to snoop) am Bus, bekommen den Schreibvorgang mit (vgl. Ethernet-Rundruf!) und ändern ihre Kopien (falls vorhanden) entsprechend.

Cache Coherence = Sequentielle Konsistenz wegen Totalordnung des HW-Rundrufs (!)

Variante: Kopie löschen statt ändern (somit „write-invalidate statt write-update“,und somit mehr passive als aktive Replikation),reduziert den Schreibverkehr

vs6.2 4

Objekt = Seite (gemäß Adressabbildungs-Hardware, MMU)

Operation = Lese/Schreibzugriff auf SpeicherzelleImplementierung: Software (Betriebssystem)

6.2.2 Verteilter Virtueller Speicher(distributed shared memory, DSM)

Kooperation mit anderen Prozessen durch Zugriff auf gemeinsamen Speicherbereich

"echter" gemeinsamer Speicher nur begrenzt realisierbar

Laufzeitsystem sorgt für transparenten Datenabgleich Probleme: Konsistenz, effiziente Implementierung

vs6.2 5

im Vergleich zur Kommunikation über Nachrichten– kein Marshalling (auf Benutzerseite)– Verwendung von Zeigern– Möglichkeit der Persistenz, asynchrone Kooperation– keine geschützten Adressräume– Kommunikationsaufwand im Code nicht sichtbar

vs6.2 6

Implementierung– auf System mit seitenorientiertem virtuellen

Speicher oder auch spezieller Hardware– write-invalidate, d.h. mit Löschen obsoleter

Kopien,sonst müsste jeder(!) Schreibzugriff auf eine replizierte Seite über Betriebssystem und Netz gehen)

– somit mit passive Replikation– ohne feste Primärkopie– mögliches Problem: thrashing ("Seitenflattern")

vs6.2 7

Beispielsystem: Ivy(Li/Hudak 1986, Yale)

Rechner mit seitenbasierter MMU, Seiten können mit Rechten "none", "read-only" oder "read-write" versehen werden

Versucht ein Prozess P auf eine Seite zuzugreifen, für die er nicht genügend Rechte hat, erzeugt er eine Seitenfehler. Dieser wird vom DSM-Laufzeitsystem abgefangen, die Seite mit den entsprechenden Rechten besorgt und der letzte Befehl von P neu gestartet

vs6.2 8

für eine Seite gilt: – ein Prozess hat Schreibzugriff, alle andere haben

keinen Zugriff, oder– ein oder mehrere Prozesse haben Lesezugriffe,

weitere können Leserecht anfordern

Ein Prozess ist Eigentümer der Seite, entweder der eine schreibende oder einer der lesenden Prozesse, dies ist die "Primärkopie"

Ein oder mehrere Prozesse mit einer gültigen Kopie der Seite bilden die Kopiemenge

vs6.2 9

Prozess P führt Schreibzugriff aus;sofern er noch kein Schreibrecht hat:– Seitenfehler– P wird Eigentümer der Seite– Seite wird bei alle Prozessen der Kopiemenge

entwertet;Kopiemenge ist jetzt {P}

– Seite wird mit Schreibrecht bei P platziert– letzte Anweisung von P wird neu gestartet

vs6.2 10

Prozess P führt Lesezugriff aus;sofern er noch kein Leserecht hat:– Seitenfehler– Seite vom Eigentümer mit Leserecht zu P kopiert– Kopiemenge erweitert um P– letzte Anweisung von P neu gestartet

gewährleistet sequentielle Konsistenz

Details und weitere DSM-Systeme: Coulouris et al.: Verteilte Systeme

vs6.2 11

Objekt: auf der Halde, mit oder ohne Datenabstraktion

Operation: gemäß Schnittstelle bzw. Typsystem der Sprache

Implementierung: Software (Laufzeitsystem oder Middleware (8))

6.2.3 Programmiersprachlich definierte Objekte(object caching)

Anwendungsprogrammierung ohne expliziten Umgang mit Nachrichten

Laufzeitsystem versendet um empfängt die notwendigen Nachrichten

vs6.2 12

Beispiele

Tupel in einem Tupel-Raum (z.B. Linda, JavaSpaces)– Kooperation über gemeinsamen Tupel-Raum– Prozesse können Tupel lesen, hinzufügen und

löschen– unterschiedliche Tupel-Typen

("müller", 5938) ("pi", 3.14) (27, 13)– Adressierung der Tupel durch "Suchanfrage"

<name, id> = take <string, 5938> Abstrakte Daten-Objekte:

– Fernaufruf (remote invocation, 8.1)