Reaktive Programmierung Vorlesung 16 vom : Theorie der Nebenläufigkeit

Transkript

1 18:13: [16] Reaktive Programmierung Vorlesung 16 vom : Theorie der Nebenläufigkeit Christoph Lüth & Martin Ring Universität Bremen Sommersemester 2015

2 2 [16] Organisatorisches Wir sind umgezogen! Martin Ring: MZH 1362 Christoph Lüth: MZH 1361

3 3 [16] Fahrplan Teil I: Grundlegende Konzepte Teil II: Nebenläufigkeit Teil III: Fortgeschrittene Konzepte Bidirektionale Programmierung: Zippers and Lenses Eventual Consistency Robustheit, Entwurfsmuster Theorie der Nebenläufigkeit

4 4 [16] Theorie der Nebenläufigkeit Nebenläufige Systeme sind kompliziert Nicht-deterministisches Verhalten Neue Fehlerquellen wie Deadlocks Schwer zu testen Reaktive Programmierung kann diese Fehlerquellen einhegen Theoretische Grundlagen zur Modellierung nebenläufiger Systeme zur Spezifikation (CSP) aber auch als Berechnungsmodell (π-kalkül)

5 5 [16] Temporale Logik, Prozessalgebren und Modelchecking Prozessalgebren und temporale Logik beschreiben Systeme anhand ihrer Zustandsübergänge Ein System ist dabei im wesentlichen eine endliche Zustandsmaschine M = S, Σ, mit Zustandsübergang S Σ S Temporale Logiken reden über eine Zustandsmaschine Prozessalgebren erlauben mehrere Zustandsmaschinen und ihre Synchronisation Der Trick ist Abstraktion: mehrere interne Zustandsübergänge werden zu einem Zustandsübergang zusammengefaßt

6 6 [16] Einfache Beispiele Einfacher Kaffee-Automat: P = 10c coffee P Kaffee-Automat mit Auswahl: P = 10c coffee P 20c latte P Pufferprozess: COPY = left?x right!x COPY NB. Eingabe (c?x) und Ausgabe (c!x) sind reine Konvention.

7 7 [16] CSP: Syntax Gegeben Prozeßalphabet Σ, besondere Ereignisse, τ P ::= Stop a P µ P.F (P) fundamentale Operationen P Q P Q externe und interne Auswahl P Q P Q synchronisiert parallel P Q unsynchronisiert parallel P \ hiding Skip P; Q sequentielle Komposition

8 8 [16] Externe vs. interne Auswahl Interne Zustandsübergänge (τ) sind nicht beobachtbar, aber können Effekte haben. Vergleiche: a b Stop a c Stop a b Stop a c Stop a (b Stop c Stop) a (b Stop c Stop)

9 Beispiel: ein Flugbuchungssystem Operationen des Servers: Nimmt Anfragen an, schickt Resultate (mit flid) Nimmt Buchungsanfragen an, schickt Bestätigung (ok) oder Fehler (fail) Nimmt Stornierung an, schickt Bestätigung Unterschied zwischen interner Auswahl (Server trifft Entscheidung), und externer Auswahl (Server reagiert) SERVER = query?(from, to) result!flid SERVER booking?flid (ok SERVER fail SERVER) cancel?flid ok SERVER Eingabe (c?x) und Ausgabe (c!a) sind reine Konvention 9 [16]

10 Beispiel: ein Flugbuchungssystem Operationen des Servers: Nimmt Anfragen an, schickt Resultate (mit flid) Nimmt Buchungsanfragen an, schickt Bestätigung (ok) oder Fehler (fail) Nimmt Stornierung an, schickt Bestätigung Unterschied zwischen interner Auswahl (Server trifft Entscheidung), und externer Auswahl (Server reagiert) SERVER = query result SERVER booking (ok SERVER fail SERVER) cancel ok SERVER Eingabe (c?x) und Ausgabe (c!a) sind reine Konvention 9 [16]

11 10 [16] Beispiel: ein Flugbuchungssystem Der Client: Stellt Anfrage wenn der Flug richtig ist, wird er gebucht; oder es wird eine neue Anfrage gestellt. CLIENT = query result (booking ok CLIENT CLIENT ) Das Gesamtsystem Client und Server synchronisiert: SYSTEM = CLIENT SERVER

12 10 [16] Beispiel: ein Flugbuchungssystem Der Client: Stellt Anfrage wenn der Flug richtig ist, wird er gebucht; oder es wird eine neue Anfrage gestellt. CLIENT = query result (booking ok CLIENT CLIENT ) Das Gesamtsystem Client und Server synchronisiert: SYSTEM = CLIENT SERVER Problem: Deadlock Es gibt Werkzeuge (Modelchecker, z.b. FDR), um solche Deadlocks in Spezifikationen zu finden

13 10 [16] Beispiel: ein Flugbuchungssystem Der Client: Stellt Anfrage wenn der Flug richtig ist, wird er gebucht; oder es wird eine neue Anfrage gestellt. CLIENT = query result (booking (ok CLIENT fail CLIENT ) CLIENT ) Das Gesamtsystem Client und Server synchronisiert: SYSTEM = CLIENT SERVER Problem: Deadlock Es gibt Werkzeuge (Modelchecker, z.b. FDR), um solche Deadlocks in Spezifikationen zu finden

14 11 [16] Ziele der Semantik von Prozesskalkülen Reasoning about processes by their external behaviour Untersuchung von Verfeinerung (Implementation) deadlock: Keine Transition möglich livelock: Divergenz Grundlegender Begriff: Äquivalenz (Gleichheit) von Prozessen

15 12 [16] Operationale Semantik für CSP (I) Definition: Labelled Transition System (LTS) Ein labelled transition system (LTS) ist L = (N, A, ) mit Menge N der Knoten (Zustände), Menge A von Labels und Relation { a N N} a A von Kanten (Zustandsübergänge). Hier: N = P,A = Σ {, τ}, definiert wie folgt: e P a P[a/e] a comms(e) P Q τ P P Q τ Q

16 Operationale Semantik für CSP (II) P τ P P Q τ P Q P a P P Q a P a τ P x P P \ B τ P x B Q τ Q P Q τ P Q Q a Q P Q a Q a τ P x P P \ B x P \ B x B 13 [16]

17 14 [16] Operationale Semantik für CSP (III) P P τ P Q τ P Q P a P P Q a P Q a P a P Q a Q P Q a a P Q Q τ Q P Q τ P Q a Q Q P Q a a P Q

18 15 [16] Denotationale Semantik für CSP Operationale Semantik erklärt das Verhalten, erlaubt kein Reasoning Denotationale Semantik erlaubt Abstraktion über dem Verhalten Für CSP: Denotat eines Prozesses ist: die Menge aller seiner Traces die Menge seiner Traces und Acceptance-Mengen die Menge seiner Traces und seiner Failure/Divergence-Mengen

19 16 [16] Anwendungsgebiete für CSP Modellierung nebenläufiger Systeme (Bsp: ISS) Verteilte Systeme und verteilte Daten Analyse von Krypto-Protokollen Hautpwerkzeug: der Modellchecker FDR