6.1.2 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] ) vs6.1.2

sequentiell konsistent: nicht sequentiell konsistent: A rep.Obj. w(x) C B nicht sequentiell konsistent: D w(y) r()x r()y A B rep.Obj. C D w(x) w(y) r()y r()y r()x r()x vs6.1.2

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! vs6.1.2

1. Jede Kopie hat die gleiche Geschichte. 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!) vs6.1.2

Verletzung der Kausalitätstreue Klient sek prim sek Klient inc 1 1 1 2 2 2 read 1 ! 2 2 vs6.1.2

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 vs6.1.2

Replikation mit Versionierung Klient sek prim sek Klient v5 v5 v5 v5 v5 inc 1 1 1 2 v6 v6 v6 2 v6 2 v6 v6 v6 v6 read 2 v6 2 v6 2 vs6.1.2

 Sequentielle Konsistenz gewährleistet 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) Kommunikation unter Klienten: Es wird nichts zurückgestellt, nur Maximumbildung der Versionnummer vs6.1.2

Konsistenzverletzung durch asynchrone Operation Klient sek prim sek Klient v5 v5 v5 v5 1 1 1 set(2) get() v5 2 v6 1 ! v6 2 v6 vs6.1.2

Def.: Kausale Konsistenz (causal consistency): (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 vs6.1.2

kausale Konsistenz verletzt: kausal konsistent(!): rep.Obj. w(x) C B kausal konsistent(!): D w(y) r()x r()y (Schreiboperationen kausal unabhängig) A B rep.Obj. C D w(x) r()x w(y) r()x r()y r()y r()x vs6.1.2

wenn keine nebenläufigen Operationen auf Objekt 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! vs6.1.2

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) (mittels einfacher Nachrichtennumerierung) Anwendung: z.B. Protokollieren von wichtigen Ereignissen innerhalb der Prozesse „Entspricht“ FIFO-Ordnung von Rundrufen PRAM: Bezeichnung eigentlich nur bei verteiltem gemeinsamen Speicher, Schreiboperationen eines Prozesses in Pipeline abgearbeitet ohne auf Beendigung zu warten vs6.1.2

PRAM-konsistent: A B rep.Obj. C D w(x) r()x w(y) w(z) r()y r()x r()z vs6.1.2

1. Aktualisieren einer Kopie muss erst dann abgeschlossen sein, 6.1.4 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. Nicht jeder Prozess muss tatsächlich alle Schreiboperationen sehen, diese implizieren die bisherigen Modelle 3. Solche Situationen sind typisch für die Manipulation von Objekten unter Sperrsynchronisation – die wegen der Nichtsequentialität ohnehin an vielen Stellen erforderlich ist. vs6.1.2

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.: Synchronisation erzwingt „temporäre sequentielle Konsistenz“ aller dadurch betroffenen Replikate „synch“-Operation ist die einzige Operation eines Synchronisationsobjektes Synchronistationsoperation wird „irgendwann“ aufgerufen, es erfolgt kein wechselseitiger Ausschluss o.ä. Einer kommt zuerst, überall gleich wahrgenommen a) Prozess kann erzwingen, dass seine neuen Werte überall hin propagiert werden 2. b) Prozess kann erzwingen, dass er die neuesten Werte hat vs6.1.2

schwach konsistent: A B rep.Obj. C D w(x) w(y) sync r()y r()x sync vs6.1.2

System weiß beim sync-Aufruf nicht, ob Prozess am Beginn 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: vs6.1.2

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. im Gegensatz zur schwachen Konsistenz hier Ausschlusssynchronisation Durch das Warten beim Austritt wird sichergestellt, dass der nächste, der eintritt, die aktuellen Werte vorfindet (allerdings nur die während wechselseitigem Ausschluss modifizierten) Andere Änderungen während Sperre nicht erlaubt vs6.1.2

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) Verringert Kommunikationsaufwand insbesondere, wenn kritischer Abschnitt in Schleife vs6.1.2

„freigabe-konsistent“: rep.Obj. C D req(L) w(x) w(y) rel(L) req(L) r()y rel(L) r()x vs6.1.2