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

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

Broadcast

ƒ Übersicht

??

ƒ Anwendungen

ƒ idealisierte Sicht (gleichzeitiger Empfang; kein Verlust von Einzelnachrichten)

ƒ Fehlerproblematik

ƒ Vorbeugung gegen Fehler mit ACK, NACK

ƒ Algorithmus für „reliable Broadcast“

ƒ Redundanz („Fluten“ des Netzes) zur Erhöhung der Fehlertoleranz

ƒ Effizienz / Kosten (Zahl von Einzelnachrichten)

ƒ FIFO-Broadcasts

ƒ zwei nacheinander ausgeführte Broadcasts ein und desselben Senders erreichen alle Empfänger in Sendereihenfolge

ƒ nicht stark genug, um „akausale“ Beobachtungen zu verhindern

FIFO-Ordnung bei Multicast

ƒ Alle Broadcast-Nachrichten eines (d.h.: ein und des ( selben) Senders an eine Gruppe kommen bei allen Mitgliedern der Gruppe in FIFO-Reihenfolge an

Wdh

Broadcast (b)

ƒ Kausale Broadcasts

ƒ kausale Abhängigkeit zweier Nachrichten

ƒ „causal order“: Nachrichtenempfang „respektiert“ kausale Abhängigkeit von Nachrichten (ist also „kausaltreu“)

ƒ „globalisiertes“ FIFO

ƒ Atomare Broadcasts

ƒ logisch gleichzeitiger Empfang der Einzelnachrichten eines Broadcasts

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

Kausale

Nachrichtenabhängigkeit

ƒ Definition: Nachricht Y hängt kausal von Nachricht X ab, wenn es im Raum-Zeit-Diagramm einen von links nach rechts verlaufenden Pfad gibt, der vom Sendeereignis von X zum Sendeereignis von Y führt.

Wdh

Kausaler Broadcast

Zweck: Wahrung von Kausalität bei der Kommunikation

ƒ Definition: Kausale Reihenfolge („causal order“): Wenn eine Nachricht N kausal von einer Nachricht M abhängt, und ein Prozess P die Nachrichten N und M empfängt, dann muss er M vor N empfangen haben

ƒ „Kausale Reihenfolge“ (bzw.

„kausale Abhängigkeit“) las- sen sich insbesondere auch

Wdh

auf Broadcastsanwenden

ƒ Kausale Reihenfolge impliziert FIFO-Reihenfolge:

kausale Reihenfolge ist eine Art „globales FIFO“

Gegenbeispiel:

Keinekausalen Broadcasts!

M

M N

N N

N M

M

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

Wdh

Atomarer Broadcast: Beispiel

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

Wdh

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

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 ( idealer“) speicherbasierter Kommunikation:

ƒ Vergleich mit („idealer“) 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“

beim Multicast

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

Dynamische Multicastgruppen

ƒ 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 (logischen) Ein- und Austrittszeitpunkte jedes Gruppenmitglieds übereinstimmen

ƒ Eintritt und Austritt sollen atomarerfolgen

Weitere

Kommunikationspardigmen

Wir besprechen nachfolgend 3 p g weitere Aspekte p : 1. Push-Paradigma

2. Publish & Subscribe

3. Tupelräume (und JavaSpaces)

Push-Paradigma

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

„Request / Reply“)-Paradigma, bei dem

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

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

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

ƒ Unangefragt (vom Client) schickt der Server etwas

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

Publish & Subscribe

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

ü ht T I f ti ( h l“)

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

ƒ Subscriber erhält automatisch (aktualisierte) Information vom Publisher (= Server), sobald diese zur Verfügung steht

ƒ push vom Publisher bzw. „callback“ des Subscribers durch Publisher

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 hinsichtlich

ƒ 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 Teilnehmer hat vollständige Kopie des Tupelraums; schnelle Zugriffe, jedoch hoher Synchronisationsaufwand) Tupelraums; schnelle Zugriffe, jedoch hoher Synchronisationsaufwand) 3) aufgeteilter Tupelraum(jeder Teilnehmer 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

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

Wechselseitiger

Ausschluss

(Mutual Exclusion, „Mutex“)

ƒ Koordination, wenn viele wollen, aber nur einer darf , ,

ƒ „Streit“ um exklusives Betriebsmittel, z.B.:

ƒ konkrete Ressource (z.B. gemeinsamer Datenbus)

ƒ abstrakte Ressource (z.B. ein „Termin“

in einem verteilten Terminkalendersystem)

ƒ „kritischer Abschnitt“ in einem nebenläufigen Programm

ƒ Es gibt klassische Lösungen bei shared memory

ƒ z.B. Semaphoreund Monitore(ÆBetriebssystemtheorie)

ƒ sind in unserem Kontext aber nicht interessant

Zentraler Manager?

ƒ Hier: Nachrichtenbasiertes System konkurrierender Prozesse y

ƒ Idee: Manager, der die Ressource (in fairer Weise!) zuordnet

ƒ ein Prozess bewirbtsich um die Ressource mit „request“

ƒ wartet dann auf Erlaubnis(„grant“)

ƒ teilt schliesslich Freigabeder Ressource dem Manager mit

„release“ mit

M

2) grant

ƒ Vergleichsweise einfach und wenige Nachrichten, aber

ƒ potentiellerEngpass

ƒ single point of failure

1) request 3) release

garantiert Fairness

ƒ Der Manager-Prozess hält eine (zeitlich geordnete) g ( g ) Warteschlange („Queue“) von Requests:

ƒ Denkübung:

Was heisst Fairnessaber genau?

Replizierte Warteschlange?

ƒ Idee für eine dezentrale Lösung: globale Warteschlange

ƒAlle Prozesse sollen die gleiche Sicht der „virtuell globalen“ Warte- schlange haben

ƒAlle Prozesse sollen die gleiche Sicht der „virtuell globalen“ Warte- schlange haben

g g g

bei jedem Prozess replizieren

schlange haben

ƒKonsistenzwird mit (vielen) Nachrichten und logischer Zeit erreicht (Ænächste schlange haben

ƒKonsistenzwird mit (vielen) Nachrichten und logischer Zeit erreicht (Ænächste

schlangen mit Zeitstempeln

V t

V t

ƒ Voraussetzung:

FIFO-Kommunikation

ƒ Alle Nachrichten tragen (eindeutige!) Zeitstempel

ƒ Request- und Release-Nachrichten immer an alle senden (FIFO B d t)

ƒ Voraussetzung:

FIFO-Kommunikation

ƒ Alle Nachrichten tragen (eindeutige!) Zeitstempel

ƒ Request- und Release-Nachrichten immer an alle senden (FIFO B d t) (FIFO-Broadcast)

ƒ Requests werden bestätigt („ack“) (FIFO-Broadcast)

ƒ Requests werden bestätigt („ack“)

Für Zeitstempel zwei Varianten:

1) globale Realzeit 2) injektive Lamport-Zeit

Das ist besonders interessant, da dann auf synchronisierte Uhren verzichtet werden kann

Der Algorithmus (Lamport 1978)

1) Bewerbung um Betriebsmittel: Request mit Zeitstempel und

Ab d ll d d i i Q i fü

Wieso sind garantiert:

1) Safety(zu jedem Zeit- punkt höchstens einer), 2) Fairness(jeder Request Wieso sind garantiert:

1) Safety(zu jedem Zeit- punkt höchstens einer), 2) Fairness(jeder Request

Denkübungen:

Denkübungen:

ƒ Wieso ist FIFOnotwendig?

ƒ Wo geht (bei Lamport-Zeit) die Uhrenbedingungein?

ƒ Wieso ist FIFOnotwendig?

ƒ Wo geht (bei Lamport-Zeit) die Uhrenbedingungein?

Absender an alle senden und in eigene Queue einfügen 2) Bei Empfang eines Request: Request in

eigene Queue einfügen, ack versenden 3) Bei Freigabedes Betriebsmittels:

Aus eigener Queue entfernen und Release an alle versenden

4) Bei Empfang eines Release: Zugehörigen

3(n-1) Nach- richtenpro Bewerbung (n = Zahl der Prozesse) 3(n-1) Nach- richtenpro Bewerbung (n = Zahl der Prozesse) 2) Fairness(jeder Request

wird „schliesslich“ erfüllt)?

2) Fairness(jeder Request wird „schliesslich“ erfüllt)?

) p g g g

Request aus eigener Queue entfernen

5) Ein Prozess darf das Betriebsmittel nutzen, wenn:

a) der eigene Request der früheste in seiner Queue ist b) und er bereits von jedem anderen Prozess

(irgendeine) spätere Nachricht bekommen hat (Frühester Request ist global eindeutig ֜die beiden Bedingungen garantieren, dass kein früherer Request mehr kommt (wieso?))

Algorithmus (Ricart / Agrawala, 1981)

ƒ Nur 2(n-1) ( ) Nachrichten

1. Sende Request (mit log. Zeit- stempel!) an alle n-1 anderen 2. Dann auf n-1 Replies warten,

danach Betriebsmittel nutzen

ƒ Bei Eintreffen einer Request-Nachricht:

ƒ wenn nicht selbst beworben oder der

1.

request reply

request reply

2.

ƒ wenn nicht selbst beworben oder der Sender „ältere Rechte“ (bzgl. logischer Zeit!) hat, dann Reply sofort schicken

ƒ ansonsten Reply erst später (im Sinne von Release) schicken, nach Erfüllen des eigenen Requests (d.h. exklusivem Zugriff) Nur älteste Bewerbung setzt sich überall durch!

Denkübungen: Safety? Fairness? Deadlockfreiheit? FIFO-Kanäle notwendig?

Resümee

ƒ Kausal atomare Broadcasts

ƒ virtuelle Synchronität

ƒ Multicast

ƒ dynamische Gruppen, „hidden channels“

ƒ Push-Prinzip und Publish & Subscribe

ƒ Tupelräume

ƒ Linda-Modell, JavaSpaces

ƒ Wechselseitiger Ausschluss (mit logischer Zeit)

ƒ replizierte Warteschlangen von Lamport (request, reply, ack)