5.1.2 Sequentielle Konsistenz 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 [ 6] ) vs5.1.2

Idee: Totalgeordnete Rundrufe an die Replikatverwalter   Ausgezeichneter Replikatverwalter arbeitet als Koordinator wie der Sequencer aus 4.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! vs5.1.2

1. Jede Kopie hat die gleiche Geschichte. Beobachtungen: 1. Jede Kopie hat die gleiche Geschichte. 2. Koordinator ist Engpaß – 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!) Daher: vs5.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 vs5.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 (4.2.2) HIER weiter vs5.1.2

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 (4.2.2) - keine Primärkopie erforderlich vs5.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! vs5.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 (4.2.1) (mittels einfacher Nachrichtennumerierung) Anwendung: z.B. Protokollieren von wichtigen Ereignissen innerhalb der Prozesse vs5.1.2

1. Aktualisieren einer Kopie muß erst dann abgeschlossen sein, 5.1.4 Schwache Konsistenz Beobachtungen: 1. Aktualisieren einer Kopie muß 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. vs5.1.2

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

Def.: (eager) Release Consistency bei wechselseitigem Ausschluß 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. vs5.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) vs5.1.2