Atomarer Broadcast

(kausalen) Broadcasts?

ƒ Beispiel: Aktualisierung einer replizierten Variablen x: p g p

Konkrete Problemursache:

ƒ Broadcasts werden nicht überall „gleich- zeitig“ empfangen

ƒ dies führt lokal zu verschiedenen Emp- fangsreihenfolgen

ƒ Abstrakte Ursache:

ƒ die Nachrichtenübermittlung erfolgt (erkennbar!) nicht-atomar

ƒ Æ Auch kausale Broadcasts haben keine „ideale“ Semantik

(im Sinne einer Illusion von speicherbasierter Kommunikation) fangsreihenfolgen

Atomarer Broadcast

ƒ Definition: Wenn zwei Prozesse P

und P

beide die Nachrichten M und N empfangen, dann empfängt P

die Nachricht M vor N genau dann, wenn P

die Nachricht M vor N empfängt

ƒ Anschaulich: Nachrichten eines Broadcasts werden

„überall quasi gleichzeitig“ empfangen

ƒ Beachte: „Atomar“ heisst hier nicht „alles oder nichts“

(wie etwa beim Transaktionsbegriff von Datenbanken)

Atomarer Broadcast: Beispiel

Beachte: das Senden wird nicht Äquivalent bzgl. „Gummiband-Transformation“

Beachte: das Senden wird nicht als Empfang der Nachricht beim Sender selbst gewertet

Realisierung von

atomarem Broadcast

1. Lösung: Zentraler „Sequencer“, der Reihenfolge festlegt g q , g g

Sequencer ist allerdings ein potentieller Engpass!

ƒ „Unicast“ vom Sender zum Sequencer

ƒ Multicast vom Sequencer an alle

ƒ Sequencer wartet jew. auf Acknowledgements von allen

ƒ oder genügt hierfür ein FIFO-Broadcastohne Acknowledgements?

atomarem Broadcast

2. Lösung: Token, das auf einem (logischen) Ring kreist

und gecrashte Prozesse

ƒ Token führt eine Sequenznummer (inkrementiert beim Senden); so wer- den alle Broadcasts global nummeriert

ƒ Tokenverlust(z.B. durch Prozessor- Crash) durch Timeoutsfeststellen (Vorsicht: Gefahr, dass dabei Token

b i htli h d lt i d!)

•Token = Senderecht (Token weitergeben!)

•Broadcast selbst z.B. über ein zugrunde liegendes broadcastfähiges Medium

ƒ Empfänger wissen, dass Nachrichten entsprechendder (in den Nachrich- ten mitgeführten Sequenznummer) ausgeliefertwerden müssen

ƒ Bei Lückenin den Nummern: dem Token einen Wiederholungswunsch mitgeben (Sender erhält damit implizit ein NACK bzw. ACK)

unabsichtlich verdoppelt wird!)

ƒ Einen gecrashten Prozess (der z.B.

das Token nicht entgegennimmt) aus dem logischen Ring entfernen

ƒ Variante(z.B. bei vielen Teilnehm- ern): Token auf Anforderung direkt zusenden (broadcast: „Token bitte zu mir“), dabei aber Fairness beachten

Wie „gut“ ist atomarer Broadcast?

1) Ist atomar 1) Ist atomar auch kausal?

2) Ist atomar

wenigstens FIFO? 3) Ist atomar + FIFO evtl. kausal?

Fazit: Semantik von Broadcast

ƒ Atomare Übermittlung g ֜ kausale Reihenfolge g

ƒ Atomare Übermittlung ֜ FIFO-Reihenfolge

ƒ Atomare Übermittlung + FIFO ֜ kausale Reihenfolge

ƒ Bemerkung zu vorheriger Seite: nicht nur 3), sondern auch 1) ist ein (Gegen)beispiel, da M, N FIFO-Broadcast ist

ƒ Vergleich mit speicherbasierter Kommunikation:

ƒ Vergleich mit speicherbasierter Kommunikation:

ƒ Kommunikation über gemeinsamen Speicher ist atomar

(alle „sehen“ das Geschriebene gleichzeitig – so sie hinschauen)

ƒ Kommunikation über gemeinsamen Speicher wahrt Kausalität (Wirkung tritt unmittelbar mit dem Schreibereignis als Ursache ein)

Kausaler atomarer Broadcast

ƒ Der speicherbasierten Kommunikation vergleichbares p g Kommunikationsmodell per Nachrichten:

kausaler atomarer Broadcast

ƒ kausaler Broadcast + atomarer Broadcast

ƒ Man nennt daher kausale, atomare Übermittlung auch virtuell synchrone Kommunikation

ƒ Denkübung: realisieren die beiden Implementierungen „zentraler Sequencer“ bzw. „Token auf Ring“ die virtuell syn. Kommunikation?

Stichwort: Virtuelle Synchronität

ƒ Idee: Ereignisse finden zu verschiedenen Realzeitpunkten statt, aber zur gleichen logischen Zeit

ƒ logische Zeit berücksichtigt nur die Kausalstrukturder Nachrichten und Ereignisse; die exakte Lage der Ereignisseauf dem „Zeitstrahl“

ist verschiebbar(Dehnen / Stauchen wie auf einem Gummiband)

ƒ Innerhalb des Systems ist synchron (im Sinne von

„gleichzeitig“) und virtuell synchron nicht unterscheidbar

ƒ identische Kausalbeziehungen

ƒ identische Kausalbeziehungen

ƒ identische totale Ordnung aller Ereignisse

ƒ Konsequenz: Nur mit Hilfe Realzeit / echter Uhr könnte ein externer Beobachter den Unterschied feststellen

ƒ Den Begriff „logische Zeit“ werden wir später noch genauer fassen (mehr dazu dann wieder in der Vorlesung „Verteilte Algorithmen“)

Broadcast –

schematische Übersicht

ƒ Warum nicht einziger Broad- cast, der alles kann? „Stärkere Semantik“ hat auch Nachteile:

ƒ Leistungseinbussen

ƒ weniger potentielle Parallelität

ƒ aufwändiger zu implementieren

ƒ Bekannte „Strategie“: Bekannte „Strategie :

ƒ man begnügt sich daher, falls es der Anwendungskontext ge- stattet, oft mit einer billigeren, aber weniger perfekten Lösung

ƒ Motto: so billig wie möglich, so „perfekt“ wie nötig

ƒ man sollte aber die Schwächen einer Billiglösung kennen!

ƒ ֜grössere Vielfalt ֜komplexer bzgl. Verständnis und Anwendung

Multicast

ƒ Multicast = Broadcast an eine Teilmenge von Prozessen

ƒ diese Teilmenge wird „Multicast-Gruppe“ genannt

ƒ Zweck von Multicast-Gruppen

ƒ „selektiver Broadcast“

ƒ Vereinfachung der Adressierung (z.B. statt Liste von Einzeladressen)

ƒ Verbergen der Gruppenzusammensetzung nach aussen

ƒ „logischer Unicast“: Gruppen ersetzen Individuen„logischer Unicast : Gruppen ersetzen Individuen (z.B. für transparente Replikation)

ƒ Alles, was zur Broadcastsemantik gesagt wurde, gilt (innerhalb der Gruppe) auch bzgl. Multicastsemantik:

ƒ zuverlässiger Multicast, FIFO-Multicast, kausaler Multicast, atomarer Multicast, kausaler atomarer Multicast

Problem der „Hidden Channels“

Kausalitätsbezüge verlassen (z.B. durch Gruppenüberlap- pung) die Multicastgruppe und kehren später wieder

ƒ Soll nun das Senden von B als kausal abhängig vom Senden von A gelten?

ƒ Global gesehen ist das der Fall, innerhalb der Gruppe ist

eine solche Abhängigkeit jedoch nicht erkennbar

Dynamische Gruppen

ƒ Bei dynamischen Gruppen können Prozesse jederzeit der y pp j Gruppe beitreten oder aus der Gruppe austreten

ƒ Crashkann als eine besondere Austrittsform modelliert werden

ƒ Und wenn dies während des Ablaufs einer Multicast- Operation geschieht?

ƒ haben verschiedene Sender an die Gruppe die gleiche Sicht bzgl. der Gruppenzusammensetzung?

bzgl. der Gruppenzusammensetzung?

ƒ Man wünscht sich

:

ƒ die Gruppe soll bei allen (potentiellen) Sendern an die Gruppe hinsichtlich der Ein- und Austrittszeitpunkte jedes Gruppenmitglieds übereinstimmen

ƒ Eintritt und Austritt sollen atomarerfolgen

Push-Paradigma / Publish & Subscribe

ƒ „Push“ im Unterschied zum klassischen „Pull-“ (bzw. (

„Request / Reply“)-Paradigma, bei dem

ƒ Clients die gewünschte Information aktiv anfordern müssen,

ƒ sie aber nicht wissen, ob bzw. wann sich eine Information geändert hat,

ƒ dadurch periodisches Nachfragen („polling“) beim Server notwendig ist

ƒ Push: „event driven“ ↔ pull: „demand driven“

ƒ Subscriber (= Client) meldet sich für den Empfang des

gewünschten Typs von Information („channel“) an

Push-Paradigma /

Publish & Subscribe (2)

ƒ Subscriber erhält automatisch (aktualisierte) Information,

b ld di V fü t ht

sobald diese zur Verfügung steht

ƒ „callback“ des Subscribers (= Client) durch den Publisher (= Server)

ƒ „Publish“ entspricht Multicast

ƒ „subscribe“ entspricht dann einem Beitritteiner Multicast-Gruppe

Tupelräume

ƒ Gemeinsam genutzter („virtuell globaler“) Speicher g ( g ) p

ƒ Blackboard- oder Marktplatz-Modell

ƒ Daten können von beliebigen Teilnehmern eingefügt, gelesen und entfernt werden

ƒ relativ starke Entkoppelung der Teilnehmer

ƒ Tupel = geordnete Menge typisierter Datenwerte

ƒ Entworfen 1985 von Entworfen 1985 von D. Gelernter D. Gelernter

ƒ Operationen:

ƒ out (t): Einfügen eines Tupels t in den Tupelraum

ƒ in (t): Lesen und Löschen von t aus dem Tupelraum

ƒ read (t): Lesen von t im Tupelraum

Tupelräume (2)

ƒ Inhaltsadressiert („Assoziativspeicher“) ( p )

ƒ Vorgabe eines Zugriffsmusters (bzw. „Suchmaske“) beim Lesen, da- mit Ermittlung der restlichen Datenwerte eines Tupels („wild cards“)

ƒ Beispiel: int i,j; in(„Buchung“, ?i, ?j) liefert ein „passendes“ Tupel

ƒ analog zu einigen relationalen Datenbankabfragesprachen

ƒ Synchrone und asynchrone Leseoperationen

ƒ ‘in’ und ‘read’ blockieren, bis ein passendes Tupel vorhanden ist

ƒ ‘inp’ und ‘readp’ blockieren nicht, sondern liefern als Prädikat („passendes Tupel vorhanden?“) ‘wahr’ oder ‘falsch’ zurück

Tupelräume (3)

ƒ Mit Tupelräumen sind auch die üblichen Kommuni- p kationsmuster realisierbar, z.B. Client-Server:

Zuordnung des

„richtigen“ Clients über die client_Id

Tupelräume (4)

ƒ Kanonische Erweiterungen des Modells

ƒ Persistenz(Tupel bleiben nach Programmende erhalten)

ƒ Transaktionseigenschaft(wichtig, wenn mehrere Prozesse parallel auf den Tupelraum bzw. gleiche Tupel zugreifen)

ƒ Problem: effiziente, skalierbare Implementierung?

1) zentraleLösung: Engpass

2) replizierter Tupelraum(jeder Rechner hat vollständige Kopie des Tupelraums; schnelle Zugriffe, jedoch hoher Synchronisationsaufwand) Tupelraums; schnelle Zugriffe, jedoch hoher Synchronisationsaufwand) 3) aufgeteilter Tupelraum(jeder Rechner hat einen Teil des

Tupelraums; ‘out’- Operationen können z.B. lokal ausgeführt werden, ‘in’ evtl. mit Broadcast)

ƒ Kritik: globaler Speicher ist der strukturierten Programmierung und der Verifikation abträglich

ƒ unüberschaubare potentielle Seiteneffekte

JavaSpaces

ƒ „Tupelraum“ für Java

ƒ gespeichert werden Objekte →neben Daten auch „Verhalten“

ƒ Tupel entspricht Gruppen von Objekten

ƒ Operationen

ƒ write: mehrfache Anwendung erzeugt verschiedene Kopien

ƒ read

ƒ readifexists: blockiert (im Gegensatz zu read) nicht; liefert u.U. ‘null’

ƒ takeifexists

ƒ notify: Benachrichtigung (mittels eines Ereignisses), wenn ein passendes Objekt in den JavaSpace geschrieben wird

JavaSpaces (2)

ƒ Teil von Jini

ƒ Kommunikation zwischen entfernten Objekten

ƒ Transport von Programmcode vom Sender zum Empfänger

ƒ gemeinsame Nutzung von Objekten

ƒ persistente Speicherung von Objekten (aber keine Festlegung, ob eine Implementierung fehlertolerant ist und einen Crash überlebt)

ƒ Semantik: Reihenfolge der Wirkung von Operationen g g p verschiedener Threads ist nicht festgelegt

ƒ selbst wenn ein write vor einem read beendet wird, muss read nicht notwendigerweise das lesen, was write geschrieben hat

Logische Zeit wechselseitiger und

A hl

Ausschluss

Zeit?

Ich halte ja eine Uhr für über- j flüssig. Sehen Sie, ich wohne ja ganz nah beim Rathaus.

Und jeden Morgen, wenn ich ins Geschäft gehe, da schau ich auf die Rathausuhr hinauf, wie viel Uhr es ist, und da mer-

k h’ l h f d

ke ich’s mir gleich für den gan- zen Tag und nütze meine Uhr nicht so ab. -- Karl Valentin

Kommt Zeit, kommt Rat

1. Volkszählung: Stichzeitpunkt g p in der Zukunft

ƒ liefert eine gleichzeitige „Beobachtung“ im Nachhinein

2. Kausalitätsbeziehung zwischen Ereignissen („Alibi-Prinzip“)

ƒ Ausschluss potentieller K lität

Kausalität

ƒ wurde Y später als X ge- boren, dann kann Y un- möglich Vater von X sein

Kommt Zeit, kommt Rat (2)

3. Fairer wechselseitiger Ausschluss g

ƒ bedient wird derjenige, wer am längsten wartet

4. Viele weitere nützliche Anwendungen von „Zeit“ in unserer verteilten realen Welt

ƒ z.B. kausaltreue Beobachtung durch „Zeitstempel“ der Ereignisse

ƒ Zeit ist vor allem natürlich auch dann wichtig, wenn es um Interaktionen mit der realen Welt geht

ƒ Prozesssteuerung, Realzeitsysteme, Cyber Physical Systems,…

Eigenschaften der „Realzeit“

Struktureigenschaften eines „natürlichen“ Zeitpunktmodells: g p

ƒ asymmetrisch (Zeit ist „gerichtet“)

ƒ transitiv

ƒ irreflexiv

ƒ linear

ƒ unbeschränkt („Zeit ist ewig“: Kein Anfang oder Ende)

ƒ dicht (es gibt immer einen Zeitpunkt dazwischen)

ƒ kontinuierlich

lineare Ordnung („später als“)

ƒ kontinuierlich

ƒ metrisch

ƒ vergeht „von selbst“

Æjeder Zeitpunkt wird schliesslich erreicht

t1 t2 t3 t4 t5

Eigenschaften der „Realzeit“ (2)

ƒ Ist das Zeitpunktmodell p adäquat? Oder sind Zeit- intervalle besser?

ƒ wann tritt das Ereignis (?) „Sonne wird rot“ am Abend ein?

ƒ Welche Eigenschaften benötigen wir wirklich?

ƒ Idee: „billigeren“ Ersatz für fehlende globale Realzeit konstruieren (z.B.: sind die reellen / rationalen / ganzen Zahlen gute Modelle?)

ƒ wann genügt welche Form „logischer“ statt „echter“ Zeit?

ƒ dazu vorher klären: was wollen wir mit „Zeit“ anfangen?

Raum-Zeitdiagramme und die Kausalrelation

Bezeichnung oft:

Interessant dabei: von links nach rechts verlaufende „Kausalitätspfade“

Bezeichnung oft:

„happened before“

ƒ eingeführt von Leslie Lamport (1978)

ƒ aber Vorsicht: damit ist nicht direkt eine „zeitli- che“ Aussage getroffen!

Definiere eine Kausalrelation p auf der Menge aller Ereignisse:

ƒ Es sei x

y genau dann, wenn:

1) x und y auf dem gleichen Prozess stattfinden und x vor y kommt, oder 2) xist ein Sendeereignisund ykorrespondierendes Empfangsereignis, oder 3)

׌

links von

zur gleichen Nachricht gehörend

von Ereignissen

ƒ Zweck: Ereignissen E eine Zeit geben g g

ƒ welche Zeit zwischen Ereignissen herrscht, ist irrelevant

ƒ gesucht ist also eine Abbildung C: E → („C“ steht für „Clock“)

ƒ  genügt hier, oder ist nicht nötig, wie wir sehen werden

ƒ C(e) nennt man den Zeitstempel von e

ƒ wenn C(e) < C(e’), dann nennt man e früher als e’

Ordnungsho-

ƒ Sinnvolle Forderung: Uhrenbedingung: e p e’ ֜ C(e) < C(e’)

ƒ Interpretation („Zeit ist kausaltreu“):

Kann ein Ereignis e ein anderes Ereignis e’ beeinflussen, dann muss e einen kleineren Zeitstempel als e’ haben

momorphismus

Logische Uhren von Lamport

ƒ C: (E, p ) → (,<)

Communications of the ACM 21(7), 558-565, 1978: Time, Clocks, and the Ordering of Events in a Distributed System

Zeitstempel-Zuordnung

ƒ e p e’ ֜ C(e) < C(e’)

Uhrenbedingung

ƒ Protokoll zur Implementierung der Uhrenbedingung:

ƒ bei jedem Ereignis tickt die lokale Uhr (= Zähler“)bei jedem Ereignis tickt die lokale Uhr ( „Zähler )

ƒ Sendeereignis: Uhrwert mitsenden (ÆZeitstempel der Nachricht)

ƒ Empfangsereignis: Uhr = max(Uhr, Zeitstempel der Nachricht) (zuerst max, danach erst tickt die Uhr)

ƒ Behauptung: Protokoll respektiert Uhrenbedingung

ƒ Beweis: Entlang von Kausalitätspfaden wächst logische Zeit monoton...

Lamport-Zeit: Nicht-Injektivität

ƒ Abbildung ist nicht injektiv g j

ƒ wäre wichtig z.B. für: „Wer die kleinste Zeit hat, der gewinnt“

ƒ Lösung: lexikographische Ordnung (C(e),i), wobei i die Prozessnummer bezeichnet, auf dem e stattfindet

ƒ Def.: (a,b) < (a’,b’) ֞a<a’ שa=a’ רb<b’ (ist lineare Ordnung!) E 

ƒ Alle Ereignisse haben nun verschiedene Zeitstempel

ƒ Abbildung ist injektiv

ƒ jede (nicht-leere) Menge von Ereignissen hat nun ein „frühestes“

ƒ Abb. (E, p ) → (×,<) respektiert die Uhrenbedingung

Umkehrung der Uhrenbedingung?

ƒ Wieso gilt folgendes eigentlich nicht? eso g t o ge des e ge t c c t e p e’ ֞ C(e) < C(e’)

ƒ Was kann man überhaupt über die beiden Ereignisse e und e’ sagen, wenn man die Zeitstempel C(e) und C(e’) vergleicht?

ƒ Kann man eine andere Art von Zeitstempeln finden, für die die Umkehrung der Uhrenbedingung gilt?

ƒ wofür wäre das nützlich?

Resümee (7a)

ƒ Atomare Broadcasts

ƒ logisch gleichzeitiger Empfang der Einzelnachrichten eines Broadcasts

ƒ Realisierung über zentralen Sequencer bzw. Token auf einem logischen Ring

ƒ Kausal atomare Broadcasts

ƒ virtuelle Synchronität

ƒ Multicast

ƒ dynamische Gruppen, „hidden channels“

Resümee (7b)

ƒ Push-Prinzip p und Publish & Subscribe

ƒ Tupelräume

ƒ Linda-Modell

ƒ JavaSpaces

ƒ Logische Zeit

ƒ Raum-Zeitdiagramme, Ereignisse, Kausalrelation

ƒ Zeitstempel von EreignissenZeitstempel von Ereignissen

ƒ Uhrenbedingung (als Ordnungshomomorphismus)

ƒ Logische Uhren von Lamport

ƒ Definition

ƒ Realisierung

ƒ injektive Abbildung, eindeutige Zeitpunkte