vs6.1.2 1

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 2

A rep.Obj.

w(x)

CB

sequentiell konsistent:

D

w(y)

r()y

r()y

r()xr()x

A rep.Obj.

w(x)

CB

nicht sequentiell konsistent:

D

w(y) r()x

r()y

r()y r()x

vs6.1.2 3

Idee: Totalgeordnete Rundrufe an die Replikatverwalter

Ausgezeichneter Replikatverwalter arbeitet als Koordinatorwie der Sequencer aus 5.2.3; sein Replikat heißt Primärkopie

Änderungen werden zunächst an der Primärkopie vorgenommenund 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, wartetKlient auf Quittung des Koordinators

Nichtmodifizierende Operation liest unter Umgehung desKoordinators aus der „nächstliegenden“ Kopie!

vs6.1.2 4

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 5

client prim

inc

sec

x

sec

Verletzung der Kausalitätstreue

client

y

x

x x

yy

read

yy

vs6.1.2 6

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 7

client prim

inc

sec

x

sec

Versionierung

client

y

y

x x

yy

read

yy

v5 v5 v5 v5 v5

v6v6v6

v6

v6 v6

v6 v6

v6

v6

vs6.1.2 8

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)

vs6.1.2 9

client prim

set(y)

sec

x

sec

Konsistenzverletzung durch asynchrone Operation

client

x x

yget()

y

v5 v5 v5 v5

v6v5

v6

v6

x

vs6.1.2 10

6.1.3 Kausale Konsistenz(Hutto, Ahamad, 1990)

Def.: Kausale Konsistenz (causal consistency):

Die Effekte kausal abhängiger Schreiboperationenwerden von allen Beteiligten in der gleichen Reihenfolgebeobachtet (nämlich in der Kausalfolge)

Implementierung:

- kausal geordnete Rundrufe (5.2.2)

- keine Primärkopie erforderlich

vs6.1.2 11

A rep.Obj.

w(x)

CB

kausale Konsistenz verletzt:

D

r()x

r()y

r()x

r()x

r()y

A rep.Obj.

w(x)

CB

kausal konsistent(!):

D

w(y)

r()x

r()y

r()y

r()x

w(y)

(Schreiboperationen kausal unabhängig)

vs6.1.2 12

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ührungder Operationen zu den gleichen Ergebnissen

undzum gleichen (abstrakten!) Gesamteffekt führt.(Entsprechend für mehr als zwei Operationen.)

Beobachtung: Kommutierende Operationen können auf verschiedenen Replikaten in verschiedenerReihenfolge ausgeführt werden!

vs6.1.2 13

Abgeschwächte kausale Konsistenz:

Def.: PRAM-Konsistenz (pipelined RAM consistency):

Die Effekte der Schreiboperationen eines Prozesseswerden von allen Beteiligten in der Ausführungsreihenfolgebeobachtet (d.h. Kausalität nicht prozessübergreifend)

Implementierung: FIFO-Rundrufe (5.2.1)(mittels einfacher Nachrichtennumerierung)

Anwendung: z.B. Protokollieren von wichtigen Ereignisseninnerhalb der Prozesse

vs6.1.2 14

A rep.Obj.

w(x)

CB

PRAM-konsistent:

D

r()x

r()x

r()y

r()y

r()x

w(y)

w(z)

r()z

r()z

vs6.1.2 15

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 passiverReplikation), braucht nur der letzte Schreibvorgang vor dem Lesen ausgeführt zu werden.

3. Solche Situationen sind typisch für die Manipulation von Objektenunter Sperrsynchronisation – die wegen der Nichtsequentialität ohnehin an vielen Stellen erforderlich ist.

vs6.1.2 16

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“

vs6.1.2 17

A rep.Obj. CB

schwach konsistent:

D

r()y

r()x

w(x)

w(y)

r()y

sync

sync

vs6.1.2 18

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 19

Def.: (eager) Release Consistency

bei wechselseitigem Ausschluss mit Sperroperationenrequest(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.

vs6.1.2 20

Def.: Lazy Release Consistency:

Schritt 2 unterbleibt.Stattdessen beschafft sich jeder Prozess bei einem request(lock) die aktuellen Daten vom Prozess mit demletzten 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)

vs6.1.2 21

A rep.Obj. CB

„freigabe-konsistent“:

D

acq(L)

r()x

r()y

w(x)

w(y)

acq(L)

rel(L)

rel(L)