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

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

vs6.23 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.24 Objekt = Seite (gemäß Adressabbildungs-Hardware, MMU) Operation = Lese/Schreibzugriff auf Speicherzelle Implementierung: Software (Betriebssystem) 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.25 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.26 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.27 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.28 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.29 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.210 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.211 Objekt: auf der Halde, mit oder ohne Datenabstraktion Operation: gemäß Schnittstelle bzw. Typsystem der Sprache Implementierung: Software (Laufzeitsystem oder Middleware (  8)) Programmiersprachlich definierte Objekte (object caching) Anwendungsprogrammierung ohne expliziten Umgang mit Nachrichten Laufzeitsystem versendet um empfängt die notwendigen Nachrichten

vs6.212 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" = take Abstrakte Daten-Objekte: –Fernaufruf (remote invocation,  8.1)