Verteilte Algorithmen TI5005

Transkript

1 Verteilte Algorithmen TI5005 Th. Letschert TH Mittelhessen Gießen University of Applied Sciences Modelle und Notationen

2 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

3 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.

4 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

5 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

6 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

7 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

8 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

9 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

10 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

11 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

12 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

13 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

14 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

15 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

16 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

17 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

18 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

19 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

20 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...

21 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

22 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.

23 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

24 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 def channel c Konfiguration // 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

25 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