Verteilte Algorithmen TI5005 - Benutzer-Homepage

Verteilte Algorithmen TI5005
Th. Letschert
TH Mittelhessen Gießen
University of Applied Sciences
Modelle und Notationen
Systeme, Anwendungen, Algorithmen
Verteiltes System
Ein verteiltes System besteht aus einer Menge von Prozessen die durch ein
Kommunikationsnetzwerk verbunden sind. Verteilte Systeme sind in der Regel
modularisiert (oft in Schichten) und stellen Dienste (z.B. Kommunikationsdienste)
zur Verfügung. Man unterscheidet oft:
 Verteilte Infrastruktur / Infrastruktur für verteilte Anwendungen
 Verteilte Anwendung / Dienst für Endbenutzer auf Basis einer Infrastruktur
Verteiltes Programm
Ein verteiltes Programm besteht aus n Prozessen die nur durch
Nachrichtenaustausch miteinander kommunizieren.
Verteilte Programme implizieren eine Programmiersprache für verteilte
Anwendungen – etwas das wenig verbreitet ist.
Verteilte Systeme / Anwendungen werden meist in einer Kombination von
unterschiedlichen Notationen definiert (Programmcode in unterschiedlichen
Sprachen + Annotationen + Konfigurationsdateien ...)
Verteilter Algorithmus
Ein verteilter Algorithmus besteht aus einer Menge von lokalen Algorithmen die
jeweils als sequentielle Prozesse auf einem oder (in Kopie) auf mehreren
Prozessoren ausgeführt werden können.
Verteilte Algorithmen werden mit Bezug auf eine Modell der Verteiltheit definiert
und in einer geschlossen Pseudo-Code Notation beschrieben
Seite 2
Modell
Welche Berechnungen können mit welchen Algorithmen in einer solchen Konstellation
ausgeführt werden?
werden:
KommunikationsMedium
Das hängt von der Art des
Kommunikationsmediums und der Knoten ab:
– verlustfreie / verlustbehaftete
Kommunikation
– Laufzeit der Nachrichten,
Zuverlässigkeit der Übertragung
– Broadcast möglich / nicht möglich
– Ausfall eines Knotens möglich oder
nicht möglich
– etc.
Modell
Verteilte Algorithmen werden darum stets unter Angabe der
Rahmenbedingungen / des Kontextes definiert, unter denen
sie agieren. Dies bezeichnet man als „Modell“.
Seite 3
In nicht verteilten
Systemen ist das Modell
selbstverständlich und
muss nicht explizit
erwähnt werden.
Modell
Systeme und (System-) Modelle
– System
 konkrete Konstellation an Komponenten, Medien, ....
 beliebig viele Variationen an Verhalten und Fähigkeiten möglich
– Modell
 Definiert / hat normierte Eigenschaften
 Charakterisiert Klassen von Systemen
 Macht sinnvolle / allgemein gültige Aussagen möglich
z.B.: Algorithmus X terminiert bei verlustfreier synchroner Kommunikation und
fehlerfrei arbeitenden Komponenten.
 Erlaubt eine Konzentration auf das Wesentliche / Beherrschbare ...
Angenommen, die Komponenten können ausfallen, aber dann senden sie gar keine
Nachrichten mehr ...
 Erleichtert eine Modularisierung der Problemlösung
„Das Problem verfälschter Nachrichten behandeln wir an anderer Stelle“ ...
Seite 4
Modell
Wozu Modelle
– Verstehen der Realität durch deren Modellierung
– Planungen / Vorhersagen
– Simulationen
Arten von Modellen
– Analytische Modelle = Formale Modelle
Beschreiben wie etwas ist, vereinfachte Beschreibungen der Realität
Vor allem in den Naturwissenschaften: z.B. mathematische Formeln in der Physik
– Analoge Modelle
Nachbauten mit ähnlichen Eigenschaften wie das Modellierte
z.B. Holzmodell eines geplanten Autos
deutlich machen / untersuchen bestimmter Eigenschaften
Seite 5
Modell
Arten von analytischen / formalen Modellen
– Diskrete Ereignis-Modelle (discrete event models)
Beschreiben das Modellierte über dessen Reaktion auf externe Ereignisse
Oft als Transitionssysteme
– Kontinuierliche Modelle (continuous models)
Beschreiben das Problem mathematisch
Oft in Form von Differentialgleichungen
Seite 6
Modell
Modelle in der Informatik
Modell als erfundene Realität
Modell simuliert eine wünschenswerte Realität. Beispiele:
– virtueller Speicher
simuliert / modelliert sehr großen Hauptspeicher
auf der Basis: kleiner HSP + Platte
– Verbindung auf Schicht-4
simuliert / modelliert verlustfreie (eventuell strom-orientierte) Kommunikation
auf der Basis: gestörter Austausch von Paketen + Fehler-Protokoll + ...
Prozess,
agiert in der
Modellwelt
Anwendung,
agiert in der
Modellwelt
Modell:
Adressraum mit 4 GB
realisiert
durch
Modell: verlustfreie
Ende-zu-Ende Kommunikation
realisiert
durch
Speicherverwaltung
im BS
Seite 7
Protokolle der
Schichten 1-4
Modelle und verteilte Systeme
Modelle und verteilte Systeme
Modell als Beschreibung möglicher Realitäten
Definition von normierten (zulässigen / wünschenswerten)
Umgebungen
– wesentliche Eigenschaften
– interessante Eigenschaften
interessant weil wichtig
... weil verstehbar / beherrschbar
... noch nicht gelöst (Modularisierung)
Untersuchung von
Problemklassen in
Modellwelten
(=normierten
Umgebungen)
Modell als wünschenswerte oder konstruierte Realität
– wünschenswerte Realität:
Komponentenmodelle:
Entfernte Prozeduren,
entfernte Objekte,
mobile Objekte,
entfernte Dienste,
....
Völlig / weitestgehend transparente Verteilung
Seite 8
Anwendung
Modell
Verstecken der
System-Vielfalt in
normierten
Modellen
Modell und verteilte Systeme
Wesentliche Modellaspekte bei verteilten Systemen
Was muss modelliert werden: Eine Kollektion von Elementen die sich gegenseitig Nachrichten
zusenden können, und die zusätzlich interne Aktionen ausführen können, bei denen sie ihren
Zustand und damit ihre Reaktion auf zukünftige Nachrichten ändern können.
Welche Aspekte hat ein solches Modell:
– Aktivität
Wer ist aktiv, welcher Art sind die aktiven Elemente
– Topologie
Welche Beziehungen bestehen zwischen den aktiven Elementen
– Kommunikation
Welche Art ist die Kommunikation zwischen den aktiven Elementen
– Synchronität
Welches zeitliche Verhalten haben Kommunikationen und lokale Aktivitäten der
Elemente: werden die Aktionen synchron (=gleichzeitig) ausgeführt
– Fehlverhalten
Welche Fehler können bei einer Kommunikation oder im Verhalten der aktiven
Elementen auftreten
Seite 9
Modell und verteilte Systeme
Modellaspekt aktive Elemente
Wer ist aktiv, welcher Art sind die aktiven Elemente (Knoten, Prozesse)
– sequentielle Prozesse
aktiver Prozess / Thread
– Aktoren
reaktiv: aufrufbare Funktion + Zustand
Seite 10
Modell und verteilte Systeme
Modellaspekt Topologie
Welcher Art sind die Beziehungen zwischen den aktiven Elementen
– fixe Prozessstruktur mit fixen Bekanntschaften
System = Graph aus Knoten und Kanten
– dynamische Bekanntschaften
System = Netz mit wechselnden Kanten
– dynamische Prozessstruktur
System = Knoten können hinzukommen oder verschwinden,
Kanten neu hinzukommen oder gekappt werden.
Seite 11
Modell und verteilte Systeme
Modellaspekt Kommunikation
Wie erfolgt die Kommunikation
– synchrone Kommunikation
Senden und / oder Empfangen erfolgt „gleichzeitig“
– asynchrone Kommunikation
Senden und / oder Empfangen sind entkoppelt (Puffer, Kanäle, o.Ä.)
Nachrichten werden mit begrenzter maximaler Laufzeit zugestellt oder es gibt keine
maximale Laufzeit
Nachrichten werden immer (irgendwann) zugestellt oder es gibt Verluste
– FIFO oder nicht FIFO
Früher (auf einem Kanal) gesendete Nachrichten werden auch garantiert früher
empfangen oder nicht.
– Punkt-zu-Punkt oder Broadcast
Kann eine Nachricht stets nur an einen Empfänger oder an viele gleichzeitig zugestellt
werden.
– Was kann gesendet werden
Nur Werte,
auch Referenzen
auch aktive Elemente (Prozesse)
Seite 12
asynchrones Modell
Asynchrones Standardmodell
– asynchroner Nachrichtenübertragung und statische Topologie:
Standardmodell für verteilte Algorithmen ohne Annahmen über das zeitliche
Verhalten der Aktivitäten (Prozesse) und der Nachrichten
– Informale Beschreibung:
Ein verteiltes System (im asynchronen Modell) besteht aus:
 einer fixen Menge von Prozessen: P1, P2, ... Pn
mit festen Bekanntschaften
 die Prozesse haben keinen gemeinsamen Ressourcen: Speicher, Takt, Uhr, ...
und besitzen (bei Bedarf) eine lokale Uhr mit der
 jedem lokalen Ereignis eine
lokale Zeit zugeordnet werden kann
 die Prozesse kommunizieren durch den Austausch von Nachrichten
 Nachrichten

sind Werte (keine Referenzen / keine Prozesse)

beliebige aber endliche Laufzeit

überholen sich nicht auf dem Weg von Pi nach Pj (FIFO-Kanäle)
Seite 13
asynchrones Modell
Definition eines verteilten Systems im asynchronen Modell
Ein verteiltes System besteht (in diesem Modell) aus einer fixen Menge von
Prozessen die
 intern rein sequentiell agieren (als Folge atomarer interner oder externer
Ereignisse)
 die Nachrichten senden und empfangen können (externe Ereignisse)
 die interne Berechnungen ausführen können (interne Ereignisse)
 Sende- und Empfangsoperationen sind entkoppelt.
Seite 14
synchrones Modell
Definition eines verteilten Systems im synchronen Modell
Ein verteiltes System besteht (in diesem Modell) aus einer fixen Menge von
Prozessen die
 intern rein sequentiell agieren (als Folge atomarer interner oder externer
Ereignisse)
 die Nachrichten austauschen können: Gleichzeitiges Senden und Empfangen
als atomare Aktion (externes Ereignis)
 die interne Berechnungen ausführen können (interne Ereignisse)
 Sende und Empfangsoperationen sind gekoppelt.
Synchrone Modelle werden im Hardware-nahen Bereich
bevorzugt. Hardware-Komponenten beeinflussen sich
gegenseitig immer nur direkt. Asynchrone Modelle können
auf synchrone Modelle abgebildet werden.
Asynchrone Modelle werden im anwendungsnäheren Bereich
bevorzugt.
Seite 15
Notationen für (a-) synchrones Modell
Notationen für die Definition eines verteilten Systems
– Notationen
Die Notation legt fest:
 Welche Ausdrucksmittel sind bei der Definition eines verteilten Systems möglich /
erlaubt.
– Notationen für die Definition der Prozesse:
Zwei grundlegend unterschiedliche Notations-Varianten:
 Ereignis-orientiert oder
 Kontroll-orientiert
– Notationen für die Definition der Toplogie:
Die Topologie definiert die
 Identität:
Wie viele und mit welchem Namen
 Typ:
Welche lokalen Algorithmen werden ausgeführt
 Bekanntschaft: Wer kann wem wie Nachrichten senden
Varianten der Topologie:
 Statisch: Topologie fix während der Lebenszeit des verteilten Systems
 Dynamisch: Topologie kann sich während der Lebenszeit des verteilten Systems
ändern
Seite 16
Notationen / Prozessdefinition
Prozesse – Kontrollorientierte Notation
Die aktiven Elemente werden als sequenzielle Prozesse definiert.
Beispiel:
channel input( char ), output( char[ 0..MAXLINE ] );
process CharToLine:
char[] line; int i=0;
do
true : receive input( line[i] ) -> {
do
line[i] != CR && i < MAXLINE-1 -> {
i++;
receive input( line[i] );
}
od
send output(line);
i = 0;
}
od
Der Prozess
CharToLine packt
Zeichen zu Zeilen
zusammen
Zeichen
input
CharToLine
output
Zeilen
Seite 17
Notationen / Prozessdefinition
Prozesse – Ereignis-orientierte Notation
Die aktiven Elemente werden als Zuordnung Ereignis ~> Aktion definiert.
Beispiel:
channel input( char ), output( char[ 0..MAXLINE ] );
Der Prozess
CharToLine packt
Zeichen zu Zeilen
zusammen
process CharToLine:
Zeichen
char[] line; int i=0;
// Ereignis: Empfang von CR
receive input( CR ) -> { send output(line);
}
// Ereignis: Empfang eines beliebigen anderen Zeichens
receive input( c ) -> {
line[i] = c ;
if i < MAXLINE -> i++;
else
send output(line);
i = 0;
}
input
CharToLine
output
Zeilen
Die Ereignis-orientierte Spezifikation eines Prozesses
ist natürlich nichts anderes als die Definition eines
erweiterten endlichen Automaten.
Seite 18
Notationen / Prozessdefinition
Prozesse – (Nicht-) Determinismus
Ereignisorientierte Notation
Impliziter Nichtdeterminismus
Prozess wartet darauf, dass irgendein Ereignis eintritt und führt die entsprechende
Aktion aus
Mehrere Ereignisse gleichzeitig: Die Auswahl des Ereignisses das (zuerst) bearbeitet
wird, ist nicht spezifiziert.
Gelegentlich (Modelle zur Simulation mit Zeit): Gleichzeitig eintreffende Ereignisse
führen zu speziellen Ereignissen.
Kontroll-orientierte Notation
Nichtdeterminismus muss explizit modelliert werden
Prozess führt stets eine bestimmte Anweisung aus.
Problematisch, wenn nicht klar ist, welche Nachricht eintrifft.
Gelegentlich über-spezifiziert.
Spezielle „nicht-determinstische“ Sprachkonstrukte werden eingesetzt:
z.B. Dijkstras Guarded Commands
Seite 19
Notationen / Prozessdefinition
(Nicht-) Determinismus: Dijkstras Guarded Commands
Nichtdeterministische if-Anweisung
if Alternativen fi
Alternative ::= guard -> Action
 eine Alternative mit zutreffendem guard wird ausgeführt
 mehrere Alternativen auswählbar: nichtdeterministische Auswahl
Guarded-Command
do Alternativen od
Alternative ::= guard -> Action
 endet wenn kein guard zutrifft ist
 mehrere Alternativen auswählbar: nichtdeterministische Auswahl
dann erneute Ausführung
Guarded Communication
Alternative ::= guard : communication -> Action
 endet wenn kein guard zutrifft ist
 mehrere Alternativen auswählbar:
1. Mehrere Kommunikationsanweisungen ausführbar:
=> nicht-deterministische Auswahl
2. Keine Kommunikationsanweisungen ausführbar:
=> Warten
if
fi
do
od
do
od
Seite 20
guard1
-> Aktion1
guard2
-> Aktion2
....
guard1
-> Aktion1
guard2
-> Aktion2
....
guard1 : Comm1
-> Aktion1
guard2 : Comm2
-> Aktion2
....
Notationen / Prozessbindung
Prozess-Bekanntschaften
statische Prozessbekanntschaften
Prozesse haben statische (d.h. im Quellcode fixierte) Namen
Sende- (und eventuell auch Empfangs-) Operationen beziehen
sich auf einen bestimmten Kommunikationspartner
Einfach und sinnvoll wenn das verteilte System komplett als
ein „Programm“ definiert werden kann oder soll
Die Bekanntschafts-Bindung der Prozesse ist statisch
Port-Konzept
Prozesse definieren Ports
Sende- (und eventuell auch Empfangs-) Operationen im Code beziehen sich auf Ports
Vor der Laufzeit werden die Ports über „Kanäle“ verbunden
Notwendig und sinnvoll wenn Systeme (Prozess-Netze) durch das Verbinden von
Instanzen von Prozessdefinitionen erzeugt werden.
Die Bekanntschafts-Bindung der Prozesse ist semi-dynamisch
Prozessreferenzen
Prozesse können über Referenzen angesprochen werden
Prozessreferenzen können kommuniziert werden
Sende- (und eventuell auch Empfangs-) Operationen beziehen sich Prozessreferenzen
Notwendig und sinnvoll wenn Prozesse zur Laufzeit erzeugt werden können
Die Bekanntschafts-Bindung der Prozesse ist dynamisch
Seite 21
Notationen / Prozessbindung
Beispiel statische Prozessbekanntschaft:
def process P :: // definiere Prozess (­Instanz)
var x = 1
do forever Q ! x
// sende an Q
x = x+1
od
end
def process Q :: // definiere Prozess (­Instanz)
var y
do forever Q ? y
// empfange von P
print(y)
od
end
start P
start Q Seite 22
CSP-Notation zum Senden
und Empfangen
Sende v an Prozess P
v!P
Empfange in v Wert von
Prozess P
v?P
CSP: „Communication
Sequential Processes“. Sehr
einflussreiches Buch von
Tony Hoare aus den
1980ern.
Notationen / Prozessbindung
Beispiel Port-Konzept: semi-dynamische Bekanntschafts-Bindung
Phase 1
Definition
+ Definition der Netztopologie
Prozessdefinitionen:
3 Prozess-Typen
Phase 2
Konfiguration
Netz: 7 Prozess-Instanzen, 6 Kanäle
Phase 3
Ausführung
Ausführung des Systems
Seite 23
Notationen / Prozessbindung
Beispiel Port-Konzept: semi-dynamische Bekanntschafts-Bindung
def process P :: // definiere Prozess (­Typ)
var x = 1
channel out // Portdefinition
do forever out ! x // sende an Kanal out
x = x+1
od
end
Definition
Prozessdefinitionen
Erzeugen von Prozessen,
direktes Ansprechen von
Prozessinstanzen nicht
möglich.
def process Q :: // definiere Prozess (­Typ)
var y
channel in // Portdefinition
do forever in ? y // empfange aus Kanal in
print(y)
od
end Konfiguration
def channel c // definiere Kanal
p1 = new P(out=c) // definiere / erzeuge Prozesse (Prozessinstanzen)
p2 = new Q(in=c) // verbinde Ports mit Kanal
start p1
start p2
Ausführung
Seite 24
Notationen / Prozessbindung
Beispiel dynamische Bekanntschafts-Bindung
def process P(q: process) :: var x = 1
do forever q ! x
x = x+1
od
end
Prozessdefinition,
Erzeugen von Prozessen,
an jeder Stelle möglich
def process Q(p: process) :: var y
do forever p ? y
print(y)
od
end def process M :: var p = new P
var q = new Q
start p(q)
start q(p)
end
start new M
Seite 25