Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Vs6.1.21 6.1.2 Sequentielle Konsistenz (Lamport 1979) Def.: Sequentielle Konsistenz (sequential consistency): Effekt/Ergebnisse einer verteilten Programmausführung.

Ähnliche Präsentationen


Präsentation zum Thema: "Vs6.1.21 6.1.2 Sequentielle Konsistenz (Lamport 1979) Def.: Sequentielle Konsistenz (sequential consistency): Effekt/Ergebnisse einer verteilten Programmausführung."—  Präsentation transkript:

1 vs Sequentielle Konsistenz (Lamport 1979) Def.: Sequentielle Konsistenz (sequential consistency): Effekt/Ergebnisse einer verteilten Programmausführung auf repliziertem Objekt = Effekt/Ergebnisse einer äquivalenten sequentiellen Ausführung auf nichtrepliziertem Objekt (impliziert Serialisierbarkeit des nichtreplizierten Objekts; Bestandteil von one-copy serializability [  7] )

2 vs Arep.Obj. w(x) CB sequentiell konsistent: D w(y) r()y r()x Arep.Obj. w(x) CB nicht sequentiell konsistent: D w(y) r()x r()y r()x

3 vs Idee:Totalgeordnete Rundrufe an die Replikatverwalter  Ausgezeichneter Replikatverwalter arbeitet als Koordinator wie der Sequencer aus 5.2.3; sein Replikat heißt Primärkopie Änderungen werden zunächst an der Primärkopie vorgenommen und dann an die Sekundärkopien weitergeleitet Sowohl aktive als auch passive Replikation möglich (passiv ist besser, wenn Replikate dynamisch kommen und gehen!) Operationen synchron oder asynchron; falls synchron, wartet Klient auf Quittung des Koordinators Nichtmodifizierende Operation liest unter Umgehung des Koordinators aus der „nächstliegenden“ Kopie!

4 vs Beobachtungen: 1. Jede Kopie hat die gleiche Geschichte. 2. Koordinator ist Engpass – es sollte also „mehr Leseoperationen als Schreiboperationen“ geben. 3. Kausalitätstreue und Unabhängigkeitstreue wären gewährleistet, wenn es keine Leseoperationen gäbe (aber dann wäre die Replikation sinnlos!)

5 vs clientprim inc sec x Verletzung der Kausalitätstreue client y x xx y y read yy

6 vs Modifiziertes Verfahren (Tanenbaum 1995): Durchnumerierung der Versionen des Objekts mit Rundrufzähler des Koordinators Jede Station merkt sich die höchste Versionsnummer, von der sie Kenntnis hat, als lokal aktuelle Versionsnummer a Aktuelle Versionsnummer wird mit jeder Nachricht, die nicht an den Koordinator geht, als Nummer v mitgeschickt Ein Server (außer dem Koordinator), der von einem Klienten eine Nachricht (= Lesewunsch) mit v > a erhält, bearbeitet die Nachricht erst dann, wenn er vom Koordinator eine Nachricht mit der Nummer v erhalten und bearbeitet hat Bemerkung: Versionsnummer = Logische Uhr des Objekts

7 vs clientprim inc sec x Versionierung client y y xx y y read yy v5 v6

8 vs Eigenschaften: Sequentielle Konsistenz gewährleistet bei Abwesenheit asynchroner Operationen Achtung: Etwaige Kommunikation unter den Klienten ist nicht kausalitätstreu - sofern nicht durch zusätzliche Maßnahmen gewährleistet (5.2.2)

9 vs clientprim set(y) sec x Konsistenzverletzung durch asynchrone Operation client xx y get() y v5 v6 v5 v6 x

10 vs Kausale Konsistenz (Hutto, Ahamad, 1990) Def.:Kausale Konsistenz (causal consistency): Die Effekte kausal abhängiger Schreiboperationen werden von allen Beteiligten in der gleichen Reihenfolge beobachtet (nämlich in der Kausalfolge) Implementierung: - kausal geordnete Rundrufe (5.2.2  ) keine Primärkopie erforderlich

11 vs Arep.Obj. w(x) CB kausale Konsistenz verletzt: D r()x r()y r()x r()y Arep.Obj. w(x) CB kausal konsistent(!): D w(y) r()x r()y r()x w(y) (Schreiboperationen kausal unabhängig)

12 vs Anwendung: - wenn keine nebenläufigen Operationen auf Objekt - oder wenn nebenläufige Operationen kommutieren Def.:Zwei Operationen op1, op2 eines ADT kommutieren, op1 | op2, wenn jede nebenläufige Ausführung der Operationen zu den gleichen Ergebnissen und zum gleichen (abstrakten!) Gesamteffekt führt. (Entsprechend für mehr als zwei Operationen.) Beobachtung:Kommutierende Operationen können auf verschiedenen Replikaten in verschiedener Reihenfolge ausgeführt werden!

13 vs Abgeschwächte kausale Konsistenz: Def.:PRAM-Konsistenz (pipelined RAM consistency): Die Effekte der Schreiboperationen eines Prozesses werden von allen Beteiligten in der Ausführungsreihenfolge beobachtet (d.h. Kausalität nicht prozessübergreifend) Implementierung: FIFO-Rundrufe (5.2.1  )5.2.1 (mittels einfacher Nachrichtennumerierung) Anwendung: z.B. Protokollieren von wichtigen Ereignissen innerhalb der Prozesse

14 vs Arep.Obj. w(x) CB PRAM-konsistent: D r()x r()y r()x w(y) w(z) r()z

15 vs Schwache Konsistenz Beobachtungen: 1. Aktualisieren einer Kopie muss erst dann abgeschlossen sein, wenn sie tatsächlich gelesen wird. 2. Wenn eine Kopie ohne Lesen nacheinander mehrfach überschrieben wird, (ohne Berücksichtigung des aktuellen Werts, z.B. bei passiver Replikation), braucht nur der letzte Schreibvorgang vor dem Lesen ausgeführt zu werden. 3. Solche Situationen sind typisch für die Manipulation von Objekten unter Sperrsynchronisation – die wegen der Nichtsequentialität ohnehin an vielen Stellen erforderlich ist.

16 vs Def.:Schwache Konsistenz (weak consistency): 1. Synchronisationsobjekte sind sequentiell konsistent. 2. Bei Zugriff eines Prozesses auf ein Synchronisations- objekt wird sichergestellt, dass a) alle vorangegangenen Schreiboperationen des Prozesses auf allen Replikaten abgeschlossen sind b) alle Schreiboperationen anderer Prozesse auf den lokalen Replikaten abgeschlossen sind M.a.W.: Synchronisationsoperation erzwingt „temporäre Konsistenz“

17 vs Arep.Obj.CB schwach konsistent: D r()y r()x w(x) w(y) r()y sync

18 vs Nachteil: System weiß beim sync-Aufruf nicht, ob Prozess am Beginn oder am Ende einer Folge von Schreiboperationen. Effizientere Implementierung möglich, wenn zwei getrennte Operationen für Betreten und Verlassen eines kritischen Abschnitts verwendet werden. Daher:

19 vs Def.:(eager) Release Consistency bei wechselseitigem Ausschluss mit Sperroperationen request(lock)/release(lock) : 1. Im kritischen Abschnitt wird nur auf die lokalen Replikate der manipulierten Objekte zugegriffen. 2. Beim release werden die aktuellen Werte propagiert (passive Replikation), und es wird auf die Bestätigungen von allen Replikaten gewartet.

20 vs Def.:Lazy Release Consistency: Schritt 2 unterbleibt. Stattdessen beschafft sich jeder Prozess bei einem request(lock) die aktuellen Daten vom Prozess mit dem letzten release(lock) (entbehrlich falls gleicher Prozess) Effekt von Release Consistency: Sequentielle Konsistenz der unter Sperrsynchronisation manipulierten Objekte (Weitere schwache Konsistenzmodelle siehe Tanenbaum/van Steen 2002)

21 vs Arep.Obj.CB „freigabe-konsistent“: D acq(L) r()x r()y w(x) w(y) acq(L) rel(L)


Herunterladen ppt "Vs6.1.21 6.1.2 Sequentielle Konsistenz (Lamport 1979) Def.: Sequentielle Konsistenz (sequential consistency): Effekt/Ergebnisse einer verteilten Programmausführung."

Ähnliche Präsentationen


Google-Anzeigen