6.2 Objektpufferung (caching)

6.2 Objektpufferung (caching) = dynamische, ad-hoc-Replikation einer Primärkopie: Zugriffswilliger beschafft sich temporär eine lokale Kopie cacheoder Pufferspeicher = 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

Cache Cache Cache Zugriff auf Adresse a veranlasst Caching des Blocks, der a enthält; gegebenenfalls wird dafür ein anderer Blockverdrängt 6.2.1 Snoopy Cache (auch snooping cache) in Mehrprozessorsystemen Objekt = Speicherblock Operation = Lese/Schreibzugriff auf Speicherzelle Implementierung: Hardware Prozessoren Speicher (Primärkopien) . . . . . . . Bus vs6.2

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

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 Objekt = Seite (gemäß Adressabbildungs-Hardware, MMU) Operation = Lese/Schreibzugriff auf Speicherzelle Implementierung: Software (Betriebssystem) vs6.2

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

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

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

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

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

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

6.2.3 Programmiersprachlich definierte Objekte(object caching) Objekt: auf der Halde, mit oder ohne Datenabstraktion Operation: gemäß Schnittstelle bzw. Typsystem der Sprache Implementierung: Software (Laufzeitsystem oder Middleware (8)) • Anwendungsprogrammierung ohne expliziten Umgang mit Nachrichten • Laufzeitsystem versendet um empfängt die notwendigen Nachrichten vs6.2

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) vs6.2

6.2 Objektpufferung (caching)