2.8 Schwache Konsistenz (3) 2.8 Schwache Konsistenz (4)

2.8 Schwache Konsistenz (3) 

■ 

Beispiel 

P1 

W 1 (x)a 

W 1 (x)b Sync 1 

P2 

P3 

Sync 2 

W 2 (x)c 

R 3 (x)b 

R 3 (x)a 

t 

P4 

Sync 4 

49 

R 4 (x)b 

R 4 (x)b 

◆ Annahme: 

• Sequenz der Synchronisation ist: Sync 1 , Sync 4 , Sync 2 

◆ System ist schwach konsistent 

Verteilte Betriebssysteme 

© 2003-2004, Franz J. Hauck, Vert. Sys., Univ. Ulm [2003w-VBS-F-Repl.fm, 2003-12-17 09.04] 

Reproduktion oder Verwendung dieser Unterlage bedarf in jedem Fall der Zustimmung des Autors. 

F 


■ 

Vertrag (Weak Consistency) 

◆ Aufrufe von synchronisiere() sind sequentiell konsistent. 

◆ Vor dem Aufruf von synchronisiere() werden alle vorherigen 

Schreiboperationen abgeschlossen. 

◆ Mit dem Aufruf von synchronisiere() werden alle späteren Lese- und 

Schreiboperationen verzögert bis alle synchronisiere()-Aufrufe 

abgeschlossen sind. 

■ 

Erläuterung 

◆ „vorherige“ und „spätere“ bezieht sich auf die Sequenz der sequentiellen 

Konsistenz 

◆ gesamter Datenspeicher wird synchronisiert 




F 

50


■ 

■ 

Einfache Implementierung 

◆ zentraler Server regelt Reihenfolge der Synchronisationen 

◆ bei Synchronisation: 

• lokaler Datenspeicher verschickt pro Variablenobjekt seinen letzten 

Schreibwert (falls vorhanden) an zentralen Server 

• lokaler Datenspeicher enthält Schreibwerte anderer Prozesse für 

verschiedene lokale Variablenobjekte vom zentralen Server 

Komplexere Implementierung 

◆ Aktualisierung kann laufend erfolgen 

◆ bei Synchronisation: 

• Sicherstellung, dass alle Aktualisierungen von lokalen Schreibzugriffen 

erfolgt sind 

• Sicherstellung, dass alle Aktualisierungen von entfernten 

Schreibzugriffen vorheriger Synchronisationen empfangen wurden 




F 

51 


▲ 

★ 

Nachteil 

◆ Datenspeicher kann nicht unterscheiden zwischen 

• Beginn eines Blocks von Lesezugriffen 

(Synchronisation für aktuelle Werte) 

• Ende eines Blocks von Schreibzugriffen 

(Verteilen der geschriebenen Werte) 

Aufgeteilte Synchronisierungsanweisungen 




F 

52

2.9 Release-Consistency 

■ 

Zwei Operationen zum Synchronisieren 

◆ acquire(): Eintritt in einen Lese-, Schreibblock (kritischer Abschnitt) 

• Blockierung bis alle lokalen Datenkopien aktualisiert 

◆ release(): Austritt aus einem Lese-, Schreibblock 

• Verteilen der geschriebenen Werte 

■ Vertrag (Gharachorloo et al., 1990) 

◆ Aufrufe von acquire() und release() sind FIFO-konsistent. 

◆ Vor dem Lesen und Schreiben werden alle vorherigen acquire()-Aufrufe 

abgeschlossen. 

◆ Vor einem release()-Aufruf werden alle Lese- und Schreiboperationen 

des Prozesses abgeschlossen. 




F 

53 

2.9 Release-Consistency (2) 

★ 

■ 

■ 

Vorteil 

◆ Lese- und Schreiboperationen können laxer gehandhabt werden 

◆ Verteilung geschriebener Werte nur am Ende eines Zugriffsblocks 

Implementierung 

◆ Beispiel mit zentralem Koordinator: 

◆ acquire() entspricht einer Sperrung des kritischen Abschnitts 

• zentraler Koordinator weiß über Sperrungen 

◆ release() verteilt geschriebene Werte an alle 

• anschließend Freigabe der Sperre 

Verknüpfung der Konsistenz mit Nebenläufigkeitskontrolle 

◆ Beispiel: Aktualisierung der Adressdaten eines Personenobjekts unter 

gegenseitigem Ausschluss 




F 

54

2.10 Entry-Consistency 

■ 

★ 

■ 

Wie Release-Consistency 

◆ aber: Verteilen geschriebener Werte erst kurz vor Zugriff (acquire()) 

◆ Synchronisierungsvariablen gebunden an eine Menge von Daten 

• getrennte Synchronisierung erforderlich 

Vorteil 

◆ mehrfaches Durchlaufen des kritischen Abschnitts in einem Prozess 

erfordert kein Verteilen der Werte 


◆ Eignerschaft an Synchronisierungsvariablen 

◆ Eigner kann acquire() durchführen und Werte schreiben 

◆ mit Übertragung der Eignerschaft werden assoziierte Datenwerte 

übertragen 

◆ Nur-Lese-Zugriffe möglich (Invalidierungen notwendig) 




F 

55 

2.10 Entry-Consistency (2) 

■ Vertrag (Bershad et al., 1993) 

◆ Vor dem Aufruf von acquire() müssen alle Aktualisierungen der 

geschützten Daten abgeschlossen sein. 

◆ Mit dem Aufruf von acquire() muss der aktuelle Prozess exklusiver 

Eigner der Synchronisationsvariable sein. 




F 

56

3 Client-zentrierte Konsistenzmodelle 

■ 

■ 

★ 

Bisher 

◆ Konsistenz globaler Daten 

Häufiger Fall 

◆ seltene und zentrale Aktualisierung der Daten 

◆ z.B. Namensdienst 

◆ z.B. Webseiten 

Suche nach vereinfachten Konsistenzmodellen 

◆ betrachtet aus der Sicht eines Client 

Prozesse 

Replikate 

Datenspeicher 

Kommunikationsnetz 




F 

57 

3.1 Eventual-Consistency 

■ 

■ 

Idee 

◆ Daten werden letztendlich irgendwann konsistent 

Aktualisierung setzt sich nach gewisser Zeit durch 

◆ Beispiel: geänderte Webseite wird nach gewisser Zeit veraltete Version in 

lokalen Browsercaches ersetzen 

◆ Beispiel: Secondary-DNS-Server erhält nach gewisser Zeit neue 

Namensbindungen 




F 

58

3.1 Eventual-Consistency (2) 

■ 


◆ Durchsetzung der aktualisierten Werte 

• Epidemische Protokolle 

◆ Push-Modell 

• nach Time-Out/periodisch werden Daten an alle Replikate gesandt 

• z.B. Zonenaktualisierung in DNS 

◆ Pull-Modell 

• nach Time-Out/periodisch holen Replikate neueste Daten 

• z.B. Web-Cache 

◆ Push-Pull-Modell 

• gegenseitige Aktualisierung zwischen Replikaten 




F 

59 

3.1 Eventual-Consistency (3) 

▲ 

Nachteil 

◆ Problem, falls verschiedene Replikate angefragt werden 

◆ Beispiel: erst Primary-DNS-Server, dann Secondary (mit veralteten Daten), 

dann wieder Primary 

• bisherige Daten: name=1.2.3.4 

• Aktualisierung im Primary aber noch nicht im Secondary: name=4.3.2.1 

• Client sieht zwischendurch veraltete Adresse 




F 

60

3.2 Monotonic-Reads 

■ 

■ 

■ 

Vertrag 

◆ Falls ein Prozess einen Wert a aus Datum x gelesen hat, dann wird er 

künftig weiterhin a oder einen neueren Wert lesen. 

Ähnlich FIFO-Konsistenz jedoch hier bezogen auf Leseoperationen 

Beispiel 

◆ Mailbox: Werte sind Menge von eingegangenen Nachrichten 

◆ bei Monotonic-Reads: 

• bei Betrachtung des Mailbox-Replikats A ist Nachricht x eingegangen 

• bei späterer Betrachtung des Mailbox-Replikats B ist Nachricht x 

ebenfalls eingegangen (und evtl. zusätzliche weitere Nachrichten) 

• Nachricht x kann nicht nicht vorhanden sein, wenn schonmal gesehen 




F 

61 

3.2 Monotonic-Reads (2) 

■ 

Beispiel (fortges.) 

P1 

Add 1 (x)a 

Add 1 (x)b 

Aktualisierungsnachrichten 

Stores 

S1 

S2 

a 

b 

a:b 

a:b 

t 

Client 

P2 

R 2 (x)a 

R 4 (x)a:b 

◆ Zugriff des Client zunächst auf S1 

• sieht Nachricht a in Mailbox 

◆ zweiter Lesezugriff auf S2 würde Nachricht a nicht zeigen 

• Monotonic-Reads-Konsistenz verhindert das 




F 

62

3.2 Monotonic-Reads (3) 

■ 

Mögliche Implementierung 

◆ Schreibzugriffe mit global eindeutigem Identifikator versehen 

◆ pro Client Verwaltung einer Identifikatormenge 

• Read-Set: Identifikatoren der gelesenen Schreibzugriffe 

◆ Lesezugriff 

• Store vergleicht Read-Set mit eigenen Aktualisierungen 

• nur wenn alle vorhanden, darf gelesen werden 

• Store übergibt neue Identifikatoren zur Vergrößerung des Read-Sets 




F 

63 

3.3 Monotonic-Writes 

■ 

■ 

■ 

Vertrag 

◆ Schreiboperation setzt sich durch bevor nächste Schreiboperation 

ausgeführt wird. 

Impliziert FIFO-Konsistenz 

◆ Prozesse sehen Schreibzugriffe in der Reihenfolge des schreibenden 

Prozesses 


◆ Verwaltung einer Identifikatormenge für Schreibzugriffe des Client 

• Write-Set 

◆ Schreibzugriff 

• Store vergleicht Write-Set mit eigenen Aktualisierungen 

• nur wenn alle vorhanden, darf geschrieben werden 




F 

64

3.3 Monotonic-Writes (2) 

■ 

Zweite mögliche Implementierung 

◆ Sequenznummern für Aktualisierungen 

◆ Replikat merkt sich letzte Sequenznummer bei Aktualisierung 

• Aktualisierungen mit zu hoher Nummer wird verzögert 

◆ Client-Zugriff 

• Client merkt sich eigene Sequenznummer 

• Vergleich eigene Sequenznummer mit Sequenznummer des Replikats 

• falls Sequenznummer des Replikats kleiner, besteht Gefahr von 

Non-monotonic Reads 

– Warten bis Replikat andere Sequenznummer hat 

– anderes Replikat benutzen 

• falls Sequenznummer des Replikats größer: 

– als eigene Sequenznummer übernehmen 




F 

65 

3.3 Monotonic-Writes (3) 

■ Beispiel mit Sequenznummern 

P1 Add 1 (x)a Add 1 (x)b Aktualisierungsnachrichten 

35 36 

Stores 

S1 

a 

a:b 

S2 

34 35 36 

a a:b 

34 35 36 

t 

Client 

P2 

34 

R 2 (x)a 

35 

R 4 (x)a:b 

36 

◆ verhindert falsche Aktualisierungsreihenfolge in den Stores 

• Monotonic-Writes-Konsistenz 

◆ verhindert Lesen veralteter Daten 

• Monotonic-Reads-Konsistenz 




F 

66

3.4 Read-Your-Writes-Consistency 

■ 

■ 

■ 

Vertrag 

◆ Ein geschriebener Wert a in Datum x wird vom gleichen Prozess sofort 

gelesen, egal welchen Store er benutzt. 

Gegenbeispiel 

◆ veränderte Webseite nicht sofort im Browser sichtbar 

◆ keine Read-Your-Writes-Consistency 


◆ schreibender Prozess muss Rückmeldung über Aktualisierung abwarten 




F 

67 

3.5 Writes-follow-Reads-Consistency 

■ 

■ 

Vertrag 

◆ Schreibzugriffe eines Prozesses erfolgen auf einer Kopie nur dann, wenn 

die Kopie den Wert des letzten Lesezugriffs des Prozesses erreicht hat. 

Beispiel 

◆ News-System (Schwarzes Brett für Nachrichten) 

◆ Schreiben eines Antwortartikels als Reaktion eines Originalartikels 

◆ Antwortartikel wird nur dann lokal geschrieben, wenn Originalartikel 

ebenfalls lokal vorhanden 




F 

68

4 Platzierung von Replikaten 

■ 

Installation von Replikaten 

◆ dynamische und statische Installation 

◆ verschiedene Strategien 

permanente Replikate 

serverinitiierte Replikate 

clientinitiierte Replikate 

nach Tanenbaum, van Steen 




F 

69 

4.1 Permanente Replikate 

■ 

Statische Installation der Replikate 

◆ durch Administratoren 

• z.B. DNS-Server: Primary- und Secondary-Server 

• z.B. Website- und FTP-Site-Mirroring (gespiegelte Server) 

4.2 Serverinitiierte Replikate 

■ 

Dynamische Installation durch Aktionen des Server 

◆ dynamische Verbesserung der Performanz und Skalierbarkeit 

• z.B. dynamische Platzierung neuer Web-Caches in Provider- 

Netzwerken 

◆ Ergänzung zu permanenten Replikaten 

• evtl. schwächere Konsistenzmodelle für serverinitiierte Replikate als für 

permanente Replikate 




F 

70

4.3 Clientinitiierte Replikate 

■ 

Dynamische Installation durch Aktionen des Client 

◆ clientseitige Caches 

• z.B. DNS-Caching-Server 

• z.B. Cache im Web-Browser 

◆ Ergänzung zu serverinitiierten Replikaten 

• evtl. schwächere Konsistenzmodelle für clientinitiierte Replikate als für 

serverinitiierte Replikate 

◆ sinnvoll nur bei gutem Lese-/Schreibverhältnis 

◆ gemeinsame Nutzung von clientinitiierten Replikaten nur bei gutmütigem 

Zugriffsmuster sinnvoll 

• gemeinsam genutzte Daten sind Voraussetzung 




F 

71 

5 Aktualisierungsmethoden 

■ 

■ 

■ 

Implementierungsalternativen für Konsistenzmodelle 

Art der Aktualisierung 

◆ Verteilung von Aktualisierungshinweisen 

◆ Verteilung der aktualisierten Werte 

◆ Verteilung der aktualisierenden Operation 

Implementierungsstruktur 

◆ Primärkopie-Verfahren 

◆ replizierte Aktualisierungsverfahren 




F 

72

2.8 Schwache Konsistenz (3) 2.8 Schwache Konsistenz (4)

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?