Vs6.21 6.2 Objektpufferung (caching) = dynamische, ad-hoc-Replikation einer Primärkopie: Zugriffswilliger beschafft sich temporär eine lokale Kopie cache.

Präsentation zum Thema: "Vs6.21 6.2 Objektpufferung (caching) = dynamische, ad-hoc-Replikation einer Primärkopie: Zugriffswilliger beschafft sich temporär eine lokale Kopie cache."—  Präsentation transkript:

1 vs6.21 6.2 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

2 vs6.22 6.2.1 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

3 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

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

5 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

6 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")

7 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

8 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

9 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

10 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

11 vs6.211 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

12 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)