Vs6.1.21 6.1.2 Sequentielle Konsistenz (Lamport 1979) Def.: Sequentielle Konsistenz (sequential...
-
Upload
dieter-henige -
Category
Documents
-
view
220 -
download
0
Transcript of Vs6.1.21 6.1.2 Sequentielle Konsistenz (Lamport 1979) Def.: Sequentielle Konsistenz (sequential...
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)