Einführung in die Informatik 3

Transkript

1 Einführung in die Informatik 3 Benjamin Gufler Erstellt mit L A TEX

2 II

3 Inhaltsverzeichnis III Systeme und systemnahe Programmierung 1 1 Prozesse, Interaktion, Koordination in verteilten Systemen Prozesse Aktionsstrukturen als Prozesse Strukturierung von Prozessen Sequentielle Prozesse und Spuren Zerlegen von Prozessen in Teilprozesse Aktionen als Zustandsübergänge Systembeschreibungen durch Mengen von Prozessen Petri-Netze Prozessalgebra Synchronisation und Koordination von Agenten Beschreibung von Prozessen mit Prädikaten Programmiersprachen zur Beschreibung Parallelität in anweisungsorientierten Programmiersprachen Kommunikation durch Nachrichtenaustausch Nachrichtenaustausch über gemeinsame Variablen Sprachmittel zum Erzeugen paralleler Abläufe Nebenläufigkeit in Java Thread-Erzeugung in Java Synchronisation in Java Betriebssysteme und systemnahe Programmierung Grundlegende Betriebssystem Aspekte Aufgaben eines Betriebssystems Betriebsarten Ein einfaches Betriebssystem für den Stapelbetrieb Ein einfaches Betriebssystem für Multiplexbetrieb Benutzerrelevante Aspekte eines Betriebssystems Kommandosprache des Betriebssystems Benutzerverwaltung Zugriff auf Rechenleistung Dateiorganisation und Verwaltung Übertragungsdienste Das Client Server Modell Middleware Zuverlässigkeit und Schutzaspekte Betriebsmittelverteilung Prozessorvergabe Hauptspeicherverwaltung Betriebsmittelvergabe im Mehrprogrammbetrieb Zuteilung der E/A Geräte III

4 IV INHALTSVERZEICHNIS 2.4 Techniken der Systemprogrammierung Unterbrechungskonzept Koordination und Synchronisation Segmentierung Seitenaustauschverfahren Verschiebbarkeit von Programmen Simultane Benutzbarkeit von Unterprogrammen Steuerung von E/A Geräten Kommunikationsdienste Betriebssystem Strukturen Interpretation und Übersetzung von Programmiersprachen Lexikalische Analyse Zerteilen von Programmen Kontextbedingungen Semantische Behandlung

5 Teil III Systeme und systemnahe Programmierung 1

6

7 3 Hintergrund: Systemprogramme (Betriebssysteme) Telekommunikation Rechnernetze eingebettete Systeme ( Software zur Steuerung technischer Systeme) Weiteres Anliegen: Beschreibung von allgemeinen diskreten (digitalen) Systemen (Bsp.: Geschäftsprozesse)

8 4

9 Kapitel 1 Prozesse, Interaktion, Koordination in verteilten Systemen Wir behandeln verteilte, parallel ablaufende, interaktive (diskrete) Systeme. Definition: System Unter einem System verstehen wir eine von ihrer Umgebung abgegrenzte Anordnung von aufeinander einwirkenden Komponenten. Wichtige Begriffe: Systeme: führen Aktionen aus Parallelität: Aktionen finden möglicherweise nebeneinander (gleichzeitig) statt (Nebenläufigkeit) Prozess / Ablauf: Die Anordnung der Aktionen im Ablauf eines Systems und ihre kausalen Abhängigkeiten Interaktion / Kommunikation: (Koordination, Synchronisation etc.) Zustand: Eine Sicht auf Systeme ist die Zuordnung eines Zustands und von Zustandsübergängen Struktur / Verteilung: Aufgliederung eines Systems in Komponenten (Subsysteme) Zeit: Oftmals als diskrete Zeit verstanden Schnittstellen / Interfaces: Markieren die Interaktion (Wirkung) an Systemgrenzen (am Übergang von zwei oder mehreren Systemen) 1.1 Prozesse Wir betrachten diskrete Prozesse, aufgebaut aus Aktionen, die in kausalen Beziehungen stehen. Etwas enger wird der Begriff Prozess in der Systemprogrammierung verwendet. Dort ist ein Prozess der Vorgang eines Programms in Ausführung Aktionsstrukturen als Prozesse Ein Prozess besteht aus einer Reihe von Aktionen. 5

10 6 KAPITEL 1. PROZESSE, INTERAKTION, KOORDINATION... off_hook(3) free(3) off_hook(2) free(2) dial(3, 2) busy(3) on_hook(3) ring(3) off_hook(3) connected(3) busy(3) dial(2, 3) ringtone(2) connected(2) on_hook(2) on_hook(3) Abbildung 1.1: Aktionsstruktur Beispiel: Telefonanlage Telefone: t {1, 2,... } Aktionen: off hook(t) on hook(t) dial(t, t ) ring(t) stopring(t) free(t) busy(t) ringtone(t) connected(t) abheben des Hörers an Telefon t auflegen wählen der Nummer t an t läuten aufhören zu läuten Freizeichen Partner besetzt beim Partner klingelts Telefon ist verbunden Aktionsstruktur (Abb. 1.1): Definiert einen Ablauf im Telefonsystem Ein Prozess ist ein gerichteter azyklischer Graph, dessen Knoten mit Aktionen markiert sind ( Aktionsgraphen ). Typischerweise kommen in Prozessen gewisse Aktionen mehrfach vor. Deshalb verwenden wir den Begriff des Ereignisses. Ein Ereignis ist ein innerhalb eines Prozesses einmaliger Vorgang, der der Ausführung (Instanz) einer Aktion entspricht. Ein Prozess entspricht einer Ablaufstruktur p 0 = (E 0, 0, α 0 ), wobei: E 0 Menge von Ereignissen 0 partielle Ordnung auf E 0 α 0 Abbildung E 0 A, wobei A eine Menge von Aktionen ist Wir nennen zwei Ereignisse e 0, e 1 E 0 in p 0 parallel bzw. kausal unabhängig, wenn gilt (e 0 0 e 1 ) (e 1 0 e 0 ) Anderenfalls nennen wir die Ereignisse zueinander sequentiell. Sequentieller Prozess: Aktionsstruktur, in der alle paarweisen Ereignisse sequentiell sind. Beobachtung: Programme mit vorgegebener Eingabe definieren Prozesse. Aktionen atomare Befehle, Anweisungen

11 1.1. PROZESSE 7 Ereignisse Instanz: Ausführung eines Befehls Sequentielle Programme entsprechen sequentiellen Prozessen. Forderung: Jeder Prozess ist endlich fundiert, d.h. zu jedem Ereignis ist die Menge der Vorgänger endlich. Deutungsmöglichkeiten der Relation : echt kausale Deutung (Wirkursache) zeitliche Reihenfolge nicht-parallele Ereignisse Strukturierung von Prozessen Ein Prozess p 1 = (E 1, 1, α 1 ) heißt Teilprozess von p 2 = (E 2, 2, α 2 ), wenn: E 1 E 2 1 = 2 E1 E 1 α 1 = α 2 E1 p 1 heißt Präfix von p 2, wenn darüber hinaus gilt e E 2, d E 1 : e 2 d e E 1 Wir schreiben dann p 1 p 2 (ist partielle Ordnung). Lemma: Für jeden endlich fundierten Prozess p 1 = (E 1, 1, α 1 ) gilt: Die Menge seiner endlichen Präfixe M = {p : p p 1 p endlich} bestimmt den Prozess p 1 eindeutig. Insbesondere gilt p 1 = sup M. Beweis: Sei p 2 = (E 2, 2, α 2 ) ebenfalls obere Schranke von M. Dann gilt E 1 E 2, denn E 1 = {E 0 : (E 0, 0, α 0 ) M} Da 1 und α 1 auf E 1 mit 2 und α 2 übereinstimmen, gilt p 2 p 1. Sequentialisierung von Prozessen: p 1 heißt Sequentialisierung von p 2, falls gilt: E 1 = E 2 e, d E 1 : e 2 d e 1 d α 1 = α 2 Eine Sequentialisierung heißt vollständig, wenn p 1 sequentiell ist, d.h. wenn E 1 hinsichtlich 1 eine Kette bildet. Satz: Jeder endliche fundierte Prozess p 0 ist duch die Menge seiner vollständigen Sequentialisierungen eindeutig bestimmt. Ein Prozess p 1 heißt Verfeinerung von p 0, wenn es eine injektive Abbildung γ : E 1 E 0 gibt mit e, d E 1 : γ(e) γ(d) e 1 d γ(e) 0 γ(d) In der Praxis treten Prozesse auf, die sehr umfangreich und unübersichtlich sind. Beispiel: Workflow in betriebswirtschaftlichen Anwendungen Rechenvorgänge in Rechenanlagen

12 8 KAPITEL 1. PROZESSE, INTERAKTION, KOORDINATION... Verkehrsgeschehen Datenübertragungen (Telekommunikation) Ein Ziel der Prozessmodellierung ist eine übersichtliche und strukturierte Darstellung. Eine Methode: Vereinfachung und Abstraktion. nur sequentielle Prozesse betrachten nur endliche Prozesse betrachten Prozesse als komponiert aus Teilprozessen betrachten Sequentielle Prozesse und Spuren Sequentieller Prozess: Kausalordnung ist lineare Ordnung. Sequentielle Prozesse lassen sich durch endliche und unendliche Sequenzen von Aktionen darstellen - die explizite Betrachtung von Ereignismengen erübrigt sich. Wir sprechen von Spuren oder Strömen von Aktionen: Sei A Aktionsmenge; die Menge der Ströme über A ist definiert durch A ω = A A A entspricht der Menge der Sequenzen der Form a 1 a 2 a 3..., genauer: der Abbildung a : N \ {0} A. Durch A ω können wir jeden sequentiellen Prozess als Spur darstellen. Wir können die Konkatenation auf A ω erweitern: Präfixordnung auf A ω : Für einen sequentiellen Prozess ist die Spur einfach zu definieren: a 1... a n b 1... = a 1... a n b 1... a 1... b 1... = a 1... s 1 s 2 s 3 A ω : s 1 s 3 = s 2 a 1 a 2 a 3... spur(p) = a 1 a 2 a 3... Für einen nicht sequentiellen Prozess definieren wir die Menge seiner Spuren: Achtung: spuren(p) := {spur(p ) : p ist vollständige Sequentialisierung von p} Durch den Übergang von Prozessen zu Spuren verlieren wir Informationen über die Nebenläufigkeit. Systeme können wir durch die Menge ihrer Prozesse P definieren. Die Menge der Spuren von P ist definiert durch Spuren(P ) := spuren(p) Eine andere Vereinfachung erhalten wir, wenn wir nur endliche Prozesse betrachten. Sei P eine Menge von Prozessen (Beschreibung eines Systems). Die Menge der endlichen Anfangsprozesse ist definiert durch Mea(P ) = {p : p p p endlich} p P p P Beide Vereinfachungen lassen sich kombinieren: Spuren(Mea(P )) Menge der Spuren der endlichen Anfangsprozesse

13 1.1. PROZESSE 9 send recieve send recieve send recieve Abbildung 1.2: Prozess Beispiel: (s. Abb. 1.2) Spur: < send send send recieve recieve... > Achtung: Durch die Menge Spuren(Mea(P )) können wir insbesondere nicht charakterisieren, welche Aktionen unendlich oft auftreten müssen (zumindest in bestimmten Fällen). Dies führt auf den Begriff der Fairness: Eine Spur s A ω heißt fair für eine Menge von Prozessen P, wenn es einen Prozess p P gibt mit spur(p ) = s p ist Sequentialisierung von p Die Spur s A ω heißt unfair, wenn es einen unendlichen Prozess p P und ein unendliches Anfangsstück p p gibt, so dass s spuren(p ) und s nicht fair für P ist Zerlegen von Prozessen in Teilprozesse Wir wollen Prozesse strukturieren, indem wir sie in zusammengehörige Teilprozesse zerlegen oder umgekehrt aus Teilprozessen zusammensetzen. Wir betrachten Porzesse p i = (E i, i, α i ) i = 0, 1, 2 Wir sagen, p 0 ist sequentiell zusammengesetzt aus p 1 gefolgt von p 2, falls gilt: E 0 = E 1 E 2 e 1 E 1 e 2 E 2 : e 1 0 e 2 α 0 E1 = α 1 α 0 E2 = α 2 0 E1 E 1 = 1 0 E2 E 2 = 2 Wir schreiben dann isseq(p 0, p 1, p 2 ). Wir können auch Prozesse parallel zerlegen bzw. parallel zusammensetzen. Dabei verwenden wir eine gewisse Menge gemeinsamer Aktionen S A. Dies sind Aktionen, die in beiden Teilprozessen auftreten (die quasi gemeinsam ausgeführt werden). Wir sagen, Prozess p 0 ist aus p 1 und p 2 über die gemeinsamen Aktionen

14 10 KAPITEL 1. PROZESSE, INTERAKTION, KOORDINATION... S A parallel zusammengesetzt, wenn gilt: E 0 = E 1 E 2 E 1 E 2 = {e E 0 : α 0 (e) S} α 0 E1 = α 1 α 0 E2 = α 2 0 = ( 1 2 ) Transitive Hülle (d.h. 0 E1 E 1 = 1 0 E2 E 2 = 2 ). Wir schreiben dann ispar(p 0, p 1, p 2, S) Aktionen als Zustandsübergänge Neben der Beschreibung von Systemen durch die Prozesse, die deren Abläufe bilden, können wir Systeme auch durch Zustände und ihr Verhalten durch Zustandsänderungen modellieren. Wir geben für ein System einen Zustandsraum an und deuten Aktionen in Prozessen als Zustandsänderungen. Wir definieren hierfür nichtdeterministische Zustandsautomaten mit Transitionsaktionen: S Menge von Zuständen (Zustandsraum) A Menge von Transitionsaktionen R S A S eine Zustandsübergangsrelation S 0 Menge von möglichen Anfangszuständen Seien σ 0, σ 1 S und a A gegeben. (σ 0, a, σ 1 ) drückt aus, dass im Zustand σ 0 Aktion a ausgeführt werden kann und dies zum Nachfolgezustand σ 1 führen kann. Das heißt, in einem Zustand können mehrere Transitionsaktionen zu unterschiedlichen Nachfolgezuständen führen. Der Automat ist nichtdeterministisch. a Wir schreiben σ 0 σ1 für (σ 0, a, σ 1 ) R. Jedem Zustandsautomaten lassen sich Spuren zuordnen. Eine Folge a i, 1 i k mit k N { } ist eine endliche oder unendliche Aktionsspur des Zustandsautomaten, falls eine Folge von Zuständen σ i existiert mit σ 0 S 0 und σ a i i 1 σi für alle 1 i k. Eine Aktion a A heißt deterministisch, wenn für jeden Zustand σ S höchstens ein Nachfolgezustand σ 1 S existiert mit σ a σ 1. Eine Aktion a A heißt total, wenn für jeden Zustand σ S ein Nachfolgezustand σ 1 S existiert mit σ a σ 1. Totalen, deterministischen Aktionen können wir (totale) Zustandsänderungsabbildungen zuordnen. Sei S eine Menge von Zuständen, A eine Menge von Aktionen. Wir ordnen jeder Aktion a A eine Zustandsänderung zu: ϱ : A (S S) Jede Aktion a A definiert durch ϱ(a) eine Abbildung auf Zuständen. Endlichen sequentiellen Prozessen lassen sich Zustandsänderungsabbildungen zuordnen.

15 1.1. PROZESSE 11 Beispiel: 1 x := 10; 2 y := 0; while x > 0 do 4 y := y + x; x := x od Ereignisse Aktionen Zustand x y a 0 x := 10; 10? b 0 y := 0; 10 0 a 1 (x > 0)? 10 0 b 1 y := y+x; c 1 x := x-1; ϱ(y := 10)(n, m) = (n, 0) ϱ(x := 10)(n, m) = (10, m) ϱ(y := y + x)(n, m) = (n, n + m) ϱ(x := x 1)(n, m) = (n 1, m) Frage: Welche Zustandsübergänge können ohne Schwierigkeit zeitlich parallel ausgeführt werden? Wir sagen, Aktionen a, b A seien im Konflikt, wenn sie nicht problemlos nebeneinander ausgeführt werden können. Beispiel: Konflikt bei parallelen Zuweisungen 1. x := x+1 2. x := x*2 Aktionen (1) und (2) sind im Konflikt. Bei paralleler Ausführung kann dem Prozess keine Zustandsänderung eindeutig zugewiesen werden. Modellierung: Die Relation Conflict A A gibt für jedes Paar von Aktionen a 1, a 2 A an, ob Konflikt bestehen. Im Falle von Zuweisungen ist Conflict wie folgt definiert (Bernstein Bedingung): Die Zuweisungen 1. x1,..., xn := E1,..., En 2. y1,..., ym := F1,..., Fm sind konfliktfrei, falls jede Programmvariable xi nicht in der Anweisung (2) vorkommt und jede Programmvariable yi nicht in der Anweisung (1) vorkommt. Gilt die Bernsteinbedingung, dann ist die Reihenfolge der Ausführung der beiden Zuweisungen ohne Einfluss auf den Endzustand. Für konfliktfreie Aktionen a 1, a 2 A setzen wir voraus:

16 12 KAPITEL 1. PROZESSE, INTERAKTION, KOORDINATION... dass die zugehörigen Zustandsübergänge unabhängig sind, d.h. die Reihenfolge der Ausführung spielt keine Rolle: ϱ(a 1 ) ϱ(a 2 ) = ϱ(a 2 ) ϱ(a 1 ) a 1, a 2 können problemlos zeitlich nebenläufig (parallel) ausgeführt werden. Wir schreiben a 1 a 2 für die Aktion der Parallelausführung der Aktionen a 1 und a 2. Unter der Voraussetzung der Konfliktfreiheit: ϱ(a 1 a 2 ) = def ϱ(a 1 ) ϱ(a 2 ) Parallele Komposition konfliktfreier Aktionen a 1, a 2 A führt keine neuen Konflikte ein, d.h. ((a 1, a 3 ) Conflict) ((a 2, a 3 ) Conflict) ((a 1 a 2, a 3 ) Conflict) Damit gilt bei paralleler Komposition konfliktfreier Aktionen für die induzierte Zustandsänderung: a 1 a 2 = a 2 a 1 (a 1 a 2 ) a 3 = a 1 (a 2 a 3 ) Ist die Konfliktfreiheit verletzt, so kann über die Wirkung der Parallelausführung keine Aussage gemacht werden. p = (E 0, 0, α) heißt konfliktfrei, falls alle konfliktträchtigen Aktionen nur bei nicht parallelen Paaren von Ereignissen auftreten, d.h. e, d E 0 : (α(e), α(d)) Conflict e 0 d d 0 e Gegeben sei eine Zustandsmenge S, Aktionen A und eine Zustandsübergangsrelation R. R lässt sich auf endliche Prozesse und Spuren erweitern. Spuren: Seien σ 0, σ 1, σ 2 S, a A und s 1, s 2 S Sequenzen von Aktionen. Induktive Definition der Zustandsübergänge für Spuren über die Länge der Sequenzen: σ 0 σ 0 ε σ0 a σ1 σ 0 a σ 1 s σ 1 s 0 σ1 σ 2 s 1 σ2 σ 1 s 2 0 Wir erweitern die Zustandsübergangssicht auf endliche Prozesse. Wieder definieren wir eine Zustandsübergangsrelation für Prozesse. Sei P ein Prozess; wir schreiben p σ 0 σ1, um auszudrücken, dass bei Ausführung der Aktionen in P ausgehend vom Zustand σ 0 der Zustand σ 1 erreicht werden kann. Sei s eine Sequenz von Aktionen, die einer Sequentialisierung des endlichen Prozesses s p P entspricht und es gelte σ 0 σ1. Dann und nur dann gelte auch σ 0 σ1. Die Reihenfolge der Aktionen in der Sequentialisierung kann bewirken, dass unterschiedliche Zustände erreicht werden. Wir sprechen von Nichtdeterminismus, der sich aus der Zufälligkeit der Hintereinanderausführung paralleler Ereignisse bzw. der zugeordneten Aktionen ergibt. σ2 1.2 Systembeschreibungen durch Mengen von Prozessen Ein Prozess beschreibt einen einzelnen Ablauf eines Systems. In der Regel besitzt ein System viele Abläufe (unter Umständen unendlich viele). Damit wird ein System durch eine Menge von Abläufen beschrieben.

17 1.2. SYSTEMBESCHREIBUNGEN DURCH MENGEN VON PROZESSEN 13 PN 1 PN b e a d c f Abbildung 1.3: Petri-Netze Beispiel: Programme besitzen i.d.r. für unterschiedliche Eingaben unterschiedliche Abläufe. Wir betrachten exemplarisch drei Möglichkeiten zur Beschreibung von Systemen: Petri-Netze formale Beschreibungssprachen Prädikatenlogik Alle drei Ansätze beschreiben Mengen von Abläufen Petri-Netze (eingeführt 1962 von C. A. Petri in seiner Dissertation) Beispiel: (s. Abb. (1.3)) Abläufe in PN 1 mit Anfangsmarkierung 1 auf 1, 0 auf 2: Abläufe in PN 2 : b a c a c a b... c a c a b a b... e d e d e... f f f Petri-Netz: gegeben durch: T 0 endliche Menge von Transitionen P 0 endliche Menge von Plätzen R (T 0 P 0 ) (P 0 T 0 ) Flussrelation Das Tripel (T 0, P 0, R) definiert ein Petri-Netz. Die Belegung eines Petri-Netzes entspricht einer Abbildung: b : P 0 N 0 natürlichzahlige Belegung Stellen- / Transitionsnetze b : P 0 B boolesche Belegung Bedingungs- / Ereignisnetze Eine Belegung definiert einen Zustand des Petri-Netzes. Das Schalten einer Transition definiert einen Zustandsübergang ( ) ( ) 1 b Eine Menge K T 0 von Transitionen heißt für eine natürlichzahlige Belegung schaltbereit, wenn gilt: {k K : (p, k) R} b(p) p P 0

18 14 KAPITEL 1. PROZESSE, INTERAKTION, KOORDINATION... v h l p Abbildung 1.4: Erzeuger Verbraucher Modell Falls K schaltbereit für die Belegung b ist, so führt das Schalten von K auf die Belegung b mit b (p) = b(p) {k K : (p, k) R} + {k K : (k, p) R} Bei booleschen Petri-Netzen definiert sich die Schaltbereitschaft ganz analog, nur, dass jetzt alle Zielplätze für jede Transition K mit false belegt sein müsen. Ansonsten entspricht true der 1 und false der 0. Lemma: Sequentialisierung Ist K schaltbereit für eine Belegung b und gilt K = K 1 K 2 K 1 K 2 = so sind auch K 1 und K 2 schaltbereit für b. Wir schreiben b K b, falls durch Schalten von K die Belegung b in b übergeführt wird (Zustandsübergang). Feststellung: Die Übergänge sind deterministisch. (mit den Bezeichnungen wie oben) K b 1 K 0 b1 b 2 K 1 b2 b 0 b2 Beispiel: Petri-Netz des Erzeuger Verbraucher Systems (1.4)) Ablauf (ohne die strichlierte Erweiterung): (vgl. Abb. p l p l p l... h v h v h... Die Erweiterung des Netzes stellt sicher, dass hole (h) und liefere (l) nie parallel ausgeführt werden. Jedes Petri-Netz mit einer gegebenen Anfangsbelegung definiert eine Menge von Prozessen. Die Aktionen dieser Prozesse entsprechen den Transitionen. Seien b und b Belegungen eines Petri-Netzes und sei p ein Prozess. Wir schreiben b p b wenn das Netz mit Belegung b den endlichen Prozess p ausführen kann und dies in die Belegung b führt. Diese Relation definieren wir induktiv (sozusagen Induktion über die Anzahl der Ereignisse im Prozess p): 1. Der leere Prozess p (d.h. der Prozess mit leerer Ereignismenge) hat folgenden Übergang: b p b.

19 1.2. SYSTEMBESCHREIBUNGEN DURCH MENGEN VON PROZESSEN 15 b a x y c Abbildung 1.5: Petri-Netz 2. Sei p ein Prozess mit trivialer Kausalitätsordnung (jedes Ereignis ist nur für sich selbst kausal) und alle Ereignisse sind unterschiedlich markiert. Dann gilt b p b genau dann, wenn die Menge {α(e) : e Ereignismenge zu p} schaltbereit ist und von b zu b führt. Für jeden Prozess p = (E 0, 0, α 0 ), auf den nicht die Bedingungen (1) und (2) p zutreffen, gilt b 0 b1 genau dann, wenn für jede nichttriviale Zerlegung von p in ein Präfix p 1 p und einen Restprozess p 2 = p E0\E 1 eine Belegung b existiert, so p 1 dass gilt b 0 b b p2 b 1. p Beobachtungen: Gilt b 0 b1, dann gilt für jede Sequentialisierung p von p p ebenfalls b 0 b 1. Achtung: Die Umkehrung gilt in der Regel nicht! Auch für Petri-Netze ist der Begriff der Fairness von Interesse: Für ein Petri- Netz mit gegebener Anfangsbelegung heißt ein unendlicher Ablauf unfair, wenn eine Transition nur endlich oft schaltet, obwohl sie unendlich oft schaltbereit ist. Die Menge der Belegungen eines Petri-Netzes N bezeichnen wir mit BE(N). Für eine gegebene Anfangsbelegung ( Anfangszustand ) sind bestimmte Belegungen durch Schalten von Transitionen erreichbar, andere nicht. Die Menge der im Netz N vom Anfangszustand b 0 aus erreichbaren Belegungen definieren wir wie folgt: } p R(N, b 0 ) = {b BE(N) : p : p endlich b 0 b ( Beispiel: Fairness x ) ( y = 0 ) 1 : (s. Abb. (1.5)) Mögliche Schaltvorgänge bei Anfangszustand a c a b a b a c... fair a b a b a b a b... unfair a c a b a b a b... unfair Menge der erreichbaren Zustände: {( ( 0 1), 1 )} 0 Es gilt: x + y = 1 (Systeminvariante). Mengen von Zuständen lassen sich durch Prädikate q : BE(N) B charakterisieren. Eine Systeminvariante für das Netz N mit Anfangsbelegung b 0 ist ein Prädikat q, für das gilt: b BE(N) : b R(N, b 0 ) q(b) Idee: Systeminvarianten charakterisieren, welche kritischen Zustände nicht eingenommen werden. Die Gültigkeit einer Invariante für ein Petri-Netz beweisen wir wie folgt:

20 16 KAPITEL 1. PROZESSE, INTERAKTION, KOORDINATION... Menge aller Zustaende q Menge der erreichbaren Zustaende Abbildung 1.6: Zustände und Invarianten 1. q(b 0 ) 2. b, b BE(N) t T 0 : q(b) b t b q(b ) Achtung: Diese Beweismethode funktioniert für bestimmte Invarianten nicht, wenn für nicht erreichbare Zustände b BE(N)\R(N, b 0 ) die Aussage (2) nicht beweisbar ist (vgl. Abb. (1.6)). Ausweg: Wir suchen eine Invariante q mit der Eigenschaft b BE(N) : q (b) q(b) (wobei für q die Beweismethode funktioniert). Im Zweifel können wir immer q (b) = b R(N, b 0 ) wählen. Beispiel: Erzeuger Verbraucher Problem Können l und h gleichzeitig schalten? Ist t 1 Invariante? Hilfsinvariante: t Im Anfangszustand: t + 1 = 1 Beobachtung: Jede Transition lässt t + 1 unverändert Hilfsinvariante ist ok t 1. Petri-Netze sind in der Regel nicht deterministisch! Für eine gegebene Belegung b gibt es in der Regel viele unterschiedliche Belegungen, die über die einzelnen Transaktionen erreicht werden können. Unterschiedliche Transitionen (insbesondere bei Konflikten) können schalten. Petri-Netze sind der vielleicht einfachste Formalismus, in dem wir die typischen Probleme verteilter Systeme studieren können: Struktur der Systeme Prozesse, die auf dem System ablaufen (Prozesssicht) Zustandsraum, Zustandsübergänge, Menge der erreichbaren Zustände Fairness Typische Fragestellungen für ein System (u.u. modelliert durch ein Petri-Netz): 1. Welche Eigenschaften haben erreichbare Zustände? (Invarianten) Ist die Menge der erreichbaren Zustände endlich? 2. Ist Nebenläufigkeit (gleichzeitiges Schalten) für bestimmte Transitionen ausgeschlossen? 3. Können Belegungen erreicht werden, von denen aus gewisse oder alle Transitionen nie wieder schalten werden (Verklemmung, Deadlock) 4. Sind alle Abläufe fair?

21 1.2. SYSTEMBESCHREIBUNGEN DURCH MENGEN VON PROZESSEN 17 Beobachtung: Jedes Petri-Netz mit Anfangszustand definiert einen Zustandsübergangsautomaten für die Menge der erreichbaren Belegungen / Zustände. Die Übergänge entsprechen dem Schalten von Transitionen. Jedem Petri-Netz mit Anfangsbelegung kann solch ein Automat zugeordnet werden. Allerdings drücken diese Automaten die Nebenläufigkeit in Prozessen nicht mehr aus. Wir beschränken uns auf sequentielle Prozesse Prozessalgebra Wir können Prozesse und damit verteilte, parallel ablaufende Systeme auch durch Sprachen (Terme) beschreiben. Ein Spezialfall sind Programmiersprachen. Wir betrachten eine vereinfachte Programmiersprache zur Beschreibung von Prozessen. Wir sprechen von Prozessalgebra (Nache Ideen von C.A.R. Hoare: CSP, Communicating Sequential Processes, R. Milner: CCS, Calculus of Communicating Systems). Wir definieren die Sprache der CSP-Agenten: agent ::=skip action agent ; agent agent or agent agent agent agent id agent id :: agent Beispiel: Ampel mit Aktionen rot, gelb, grün: Agentenidentifikatoren: ampel:: (rot; gelb; grün; ampel) Dies entspricht dem Agenten mit Identifikator ampel, für den die Gleichung ampel = rot; gelb; grün; ampel (Rekursion) gilt. ampel beschreibt den folgenden Prozess: rot gelb grün rot... Beispiel: Fahrkartenautomat Aktionen: Zielwahl Preisanzeige Geldeinwurf Kartenausgabe Rückgeldausgabe Abbruch Agent, der den Automaten beschreibt: 1 automat :: Zielwahl; 2 Preisanzeige; ((Geldeinwurf; 4 ((Kartenausgabe Rueckgeldausgabe) or Abbruch)) or Abbruch);

22 18 KAPITEL 1. PROZESSE, INTERAKTION, KOORDINATION... Prozesse für den Automaten: Zielwahl Preisanzeige Abbruch... Zielwahl Preisanzeige Geldeinwurf Abbruch Die Sprache der Agenten ist eine Prozessbeschreibungssprache. Da wir aus gegebenen Termen der Spache Agent durch or, ; und neue Agenten bilden können, sprechen wir von einer Prozessalgebra. Agenten beschreiben Mengen von Prozessen. Um genau festzulegen, welche Prozesse durch einen gegebenen Agenten beschrieben werden, führen wir (ähnlich wie für Belegungen bei Petri-Netzen) eine Relation t p t ein, die ausdrückt, dass Agent t den Prozess p ausführen kann und sich dadurch verhält wie durch den Agenten t beschrieben. Dies wird durch folgende Regeln festgelegt: 1. Jeder Agent kann den leeren Prozess p ausführen: 2. Sei a eine Aktion. t p t a pa skip wobei p a der Prozess mit nur einem Ereignis e sei mit α(e) = a. 3. Auswahl: 4. Sequentielle Komposition: 5. Parallele Komposition: t 1 p t t 1 or t 2 p t t 2 p t t 1 or t 2 p t t 1 p t t 1 ; t 2 p t ; t 2 p 1 p 2 t 1 skip t2 t isset(p, p1, p 2 ) t 1 ; t 2 p t p 1 t 1 t p 2 1 t 2 t p 2 ispar(p, p 1, p 2, ) t 1 t 2 t 1 t 2 p 1 p 2 t 1 skip t2 skip ispar(p, p1, p 2, ) t 1 t 2 Algebraisch: 1 skip skip = skip 2 skip; t = t; skip = t => skip; skip = skip t1 t2 = t2 t1 4 (t1 t2) t3 = t1 (t2 t3) skip t = t P (t) = {p : t : t p t } Menge der Prozesse, die der Agent t ausführen kann. S(t) = spuren(p) p P (t) p skip skip Zwei Aktionen t, t sind spuräquivalent, falls S(t) = S(t ) oder prozessäquivalent, falls P (t) = P (t ).

23 1.2. SYSTEMBESCHREIBUNGEN DURCH MENGEN VON PROZESSEN 19 a1 b1 b2 c a2 b3 Abbildung 1.7: Ablauf des Beispielagenten 6 a b = (a; b) or (b; a) Achtung: Bestimmte Agenten führen nie nach skip! 6. Rekursion t[x :: t/x] p t x :: t p t Alle Fragen, die wir für Petri-Netze gestellt haben, können wir analog für Agenten stellen. Wir sagen, von t ist t erreichbar, wenn t p t für einen Prozess p gilt. Beispiele: Ampel ampel :: rot; gelb; grün; ampel rot prot skip gelb p gelb skip grün pgrün skip rot prot skip rot; gelb prot skip; gelb rot prot skip gelb p gelb skip isseq(p, p rot, p gelb ) rot; gelb p skip Menge der erreichbaren Agenten ( Zustände ): ampel prot gelb; grün; ampel ampel prot;p gelb grün; ampel ampel prot;p gelb;p grün ampel q :: a; q a; (q :: q; q) p0 q :: a; q q :: a; q p0 q :: a; q Synchronisation und Koordination von Agenten Für Agenten t1 und t2 gilt, dass diese in t1 t2 ihre Aktionen / Prozesse unabhängig voneinander ausführen. Damit wir in der Lage sind, kausale Beziehungen zwischen den Prozessen von t1 und t2 herzustellen, verwenden wir eine Menge S A von gemeinsamen Aktionen (englisch: handshake ). Wir definieren nun eine parallele Komposition mit gemeinsamen Ereignissen, gekennzeichnet durch die Aktionen in der Synchronisationsmenge S. Wir schreiben t1 S t2 für den Agengen, der Prozesse ausführt, die sich parallel aus den Prozessen von t1 und t2 zusammensetzen, wobei jedoch alle Ereignisse in diesen Prozessen für t1 und t2, die mit Aktionen aus S markiert sind, gemeinsame Ereignisse sind. Damit unterscheiden wir in den Prozessen p 1 für Agent t1 und p 2 für t2 zwischen den Ereignissen, die beide unabhängig parallel ausführen (das sind die Ereignisse mit Aktionen aus A\ S) und den Ereignissen, die die Agenten gemeinsam ausführen (die Ereignisse mit Aktionen aus S).

24 20 KAPITEL 1. PROZESSE, INTERAKTION, KOORDINATION... a1 b1 a1 b1 p v p v p v p v p a2 b2 a2 b2 a2 Abbildung 1.8: Ablauf mit gegenseitigem Ausschluss von Aktionen Beispiel: (a1; c; a2) {c} ((b1 b2); c; b3) Ablauf: s. Abb. (1.7) Definition der parallelen Komposition: p 1 t 1 t p 2 1 t 2 t p 2 ispar(p, p 1, p 2, S) t 1 S t 2 t 1 S t 2 p 1 p 2 t 1 skip t2 skip ispar(p, p1, p 2, S) t 1 S t 2 Beispiel: Gegenseitiger Ausschluss für Aktionen b1, b2: [(t1 :: a1; p; b1; v; t1) (t2 :: a2; p; b2; v; t2)] {p,v} sema :: p; v; sema Ablauf: s. Abb. (1.8) Probleme: p skip Es kann passieren, dass ein Agent im obigen Beispiel nie ein p ausführt, da ihm der Partnerprozess ständig zuvorkommt. Verklemmung: (a; c) {c,d} (b; d) Die Agenten stimmen in den synchronisierten Aktionen nicht überein, es ist kein Fortschritt nach Ausfühung der Aktionen a und b mehr möglich. Wir sprechen von einer Verklemmung Beschreibung von Prozessen mit Prädikaten Wir beschreiben ein System durch eine Menge von Prozessen. Eine gängige Beschreibung von Mengen erhalten wir durch Prädikate. q : Prozesse B (wobei Prozesse die Menge der Prozesse über einer gegebenen Menge A von Aktionen sei). Wesentliche Frage: Wie Prädikate auf Prozessen definieren? 1. Wir nutzen die Präfixordnung. 2. Wir definieren für einen Prozess p Prozesse und für eine Aktion a A die Zahl #(a, p) ( Anzahl der Aktionen a in p): #(a, p) = {e E 0 : α 0 (e) = a} wobei p = (E 0, 0, α 0 ). Es ist #(a, p) N 0 { }. Erweiterung auf Teilmengen K A: #(K, p) = a K #(a, p) Oft ist es von Interesse, nicht über den unendlichen Prozess p, sondern über Eigenschaften seiner endlichen Präfixe p p zu reden: 0 #(a 1, p ) #(a 2, p ) 1 p p, p endlich a 1 und a 2 bilden eine kausale Kette

25 1.2. SYSTEMBESCHREIBUNGEN DURCH MENGEN VON PROZESSEN 21 Weiteres Prädikat: Gegenseitiger Ausschluss von Aktionen b 1 und b 2 : gga(b 1, b 2, p) = e, e E 0 : α 0 (e) = b 1 α 0 (e ) = b 2 (e 0 e ) (e e) Wichtiges Mittel, um Prädikate über sequentiellen Prozessen zu definieren: Temporale Logik. Betrachten wir Prädikate über Prozessen (und damit über Systemen) mit unendlichen Abläufen, so können wir zwei Klassen von Aussagen unterscheiden: Sicherheitseigenschaften: Dies sind Eigenschaften, bei denen ein Verstoß stets durch eine endliche Beobachtung nach endlich vielen Schritten festgestellt werden kann. Lebendigkeitseigenschaften: Dies sind Eigenschaften, bei denen wir einen Verstoß nicht durch endliche Beobachtung feststellen können, sondern nur durch Betrachtung des unendlichen Gesamtprozesses. Beobachtung: Jede Systemeigenschaft (in der Regel eine Mischung aus Sicherheitsund Lebendigkeitseigenschaft) lässt sich zerlegen in eine reine Sicherheits- und eine reine Lebendigkeitseigenschaft. Beispiel: Sicherheits- und Lebendigkeitseigenschaften für einen Lift: Sicherheitseigenschaften: Solange der Lift fährt, sind alle Türen geschlossen. Stockwerktüren sind geschlossen, wenn der Lift nicht in diesem Stockwerk hält. Lift hält nur auf Anforderung.... Lebendigkeitseigenschaften: Bei Anforderung hält der Lift irgendwann im entsprechenden Stockwerk, falls er nicht blockiert wird. Bei Fahranforderung schließt die Tür irgendwann, falls sie nicht blockiert wird.... Wie formal ausdrücken? Sicherheitseigenschaften: Invarianten des Systems auf Zuständen bei Prozessen: Prädikate, die für alle endlichen Präfixe gelten. q gilt als Sicherheitseigenschaft für den Prozess p, wenn p p, p endlich q(p ) gilt. Lebendigkeitseigenschaften: Wir definieren für Zusicherungen auf Zuständen (oder Prozessen) folgende Aussage: Seien Q, P Zusicherungen. Q leads to P heißt für unser System: Ist das System in einem Zustand, in dem Q gilt, dann ist es irgendwann (nach endlich vielen Schritten) in einem Zustand, in dem P gilt. true leads to P steht für: Das System erreicht immer irgendwann einen Zustand, in dem P gilt.

26 22 KAPITEL 1. PROZESSE, INTERAKTION, KOORDINATION Programmiersprachen zur Beschreibung kooperierender / kommunizierender Systeme / Prozesse Programme, insbesondere anweisungsorientierte, beschreiben Prozesse. Beispiel: 1 var nat x := 10; 2 while true do x := x+1 4 od Invariante: x 10. Lebendigkeitseigenschaften: true leads to x = 100 n N : x = n leads to x > n Allerdings sind diese Prozesse sequentiell. Wir führen nun Sprachmittel ein, um parallele Prozesse durch Programme beschreiben zu können Parallelität in anweisungsorientierten Programmiersprachen Voneinander logisch unabhängige Anweisungen können wir ohne Probleme parallel ausführen. Wir schreiben S 1 S n für eine parallele Anweisung. Dies steht für: führe die Anweisungen S 1,..., S n parallel aus. Beispiel: x := x + 1; z := x 2 y := y 1 Solche Anweisungen können unabhängig voneinander ausgeführt werden, da sie keine gemeinsamen Variablen verwenden ( Bernstein-Bedingung ). {x = 0 z = 0} x := x + 1 z := x 2 {x = 1 (z = 0 z = 1)} Feststellung: Falls in S 1,..., S n gemeinsame Programmvariablen auftreten (dies sind Programmvariablen, die in mindestens einer Anweisung geschrieben und in mindestens einer weiteren Anweisung gelesen oder geschrieben werden), so lässt sich über den Endzustand der Ausführung nichts aussagen, wenn man nichts über die Granularität (Atomizität) der Anweisungen weiß. Fazit: Zusätzliche Hilfsmittel (Konstrukte der Programmiersprache) sind erforderlich, um Parallelität zu kontrollieren, zu steuern und zu koordinieren. Dabei sind wir an folgenden Ausdrucksmöglichkeiten interessiert: 1. Sicherstellung der Ausführung bestimmter Anweisungen ohne unerwartete Einflüsse durch parallel ablaufende Programme (ohne Unterbrechung) Konzept der unteilbaren Anweisung / Aktion (atomare Anweisung): gegenseitiger Ausschluss.

27 1.3. PROGRAMMIERSPRACHEN ZUR BESCHREIBUNG Nutzereingabe Sensoren Controller reaktives Programm gesteuertes System ("Regelstrecke") Ausgabe fuer den Nutzer Aktuatoren Abbildung 1.9: reaktives System 2. Warten auf das Eintreten gewisser Bedingungen (kann nicht einfach durch if erreicht werden, da if nicht zu Warten führt, sondern zu sofortiger Fortsetzung der Berechnung abhängig vom Wert der Bedingung). 3. Nachrichtenaustausch: Zwischen den parallel ablaufenden Anwendungen wollen wir Informationen austauschen. Achtung: Auch beim Arbeiten mit atomaren Anweisungen kann durch Parallelität Nichtdeterminismus auftreten, durch die Zufälligkeit der relativen Geschwindigkeit der Ausführung. Durch die Konzepte paralleler Prozesse können wir auch Anweisungen schreiben, die Vorgänge in der Umgebung eines Rechners steuern und überwachen. Wir sprechen von reaktiven Systemen / Programmen (z.b. Steuerung technischer Vorgänge durch Rechner (Controller) und ihre Software: mobile Telefone, Haushaltsgeräte, Automobiltechnik, Avionik, Robotik,... ). Eine Zahl: 98% aller programmierbaren Prozessoren laufen eingebettet / reaktiv. Definition: reaktiv Ein Program heißt reaktiv, wenn es auf Ereignisse seiner Umgebung reagiert und somit technische oder organisatorische Vorgänge steuert. Dies erfordert: Sensoren: Vorrichtungen, die Ereignisse erkennen und in digitale Signale umsetzen Aktuatoren: Geräte, die digitale Signale in Steueranweisungen umsetzen Für solche Systeme sind Echtzeitanforderungen typisch. Das heißt, dass die Systeme zeitbezogen reagieren. Wir unterscheiden zwei Kategorien: Weiche Echtzeitanforderungen: keine scharfen Zeitschranken (z.b. Telefon) Harte Echtzeitanforderungen: Wenn diese nicht eingehalten werden, treten katastrophale Fehler auf. (z.b. Motorsteuerung, Airbag, ABS, Robotik) 1 - x := 0; 2 x := 1; while x <> 0 do 4 y := y+1 od - Terminiert dieses Programm? Wenn ja, welchen Wert haben x und y?

28 24 KAPITEL 1. PROZESSE, INTERAKTION, KOORDINATION... Die parallele Anweisung terminiert, falls alle parallel laufenden Programme terminieren. Zwei Fälle für unser Beispiel: 1. Die while Bedingung wird nicht ausgewertet, solange x = 0 gilt. Dann terminiert die Wiederholungsanweisung und damit das ganze parallele Programm nicht. 2. Die while Bedingung wird ausgewertet, wenn x = 1 gilt. Das Programm terminiert. Dann hat x den Wert 1 und y hat einen beliebigen Wert. Frage: Wie Information zwischen parallel ablaufenden Programmen austauschen? Wir unterscheiden grundsätzlich zwei Möglichkeiten: Nachrichtenaustausch / Austausch von Signalen gemeinsame Variablen Kommunikation durch Nachrichtenaustausch Eine grundlegende Form der Kommunikation besteht im Austausch von Nachrichten. Dabei unterscheiden wir: den Sender (Nachrichtenquelle) den / die Empfänger der Nachricht. In der Regel haben wir einen Sender einen ( point to point), viele oder alle ( Broadcasting) Empfänger. Wir konzentrieren uns auf den Fall ein Sender, ein Empfänger. Wichtige Frage: Wie Nachrichten adressieren? direkt Empfänger adressieren über Nachrichtenmedien (Briefkästen, Kanäle etc.) Wir verwenden Nachrichtenkanäle. Deklaration / Vereinbarung eines Kanals: channel m c mit: m Kanalsorte Sorte der Nachrichten, die über den Kanal gesendet werden c Kanalidentifikator Operationen / Anweisungen für Kanäle: send E on c Senden einer Nachricht receive v on c Empfangen einer Nachricht und Ablegen in v mit: c Kanalidentifikator E Ausdruck von der Sorte des Kanals v Programmvariable von der Sorte des Kanals

29 1.3. PROGRAMMIERSPRACHEN ZUR BESCHREIBUNG Sender Empfaenger Beispiel: Erzeuger / Verbraucher 1 - channel m c; 2 var m x, z := x0, z0; - while not B(x) do 4 receive x on c; consume(x) 6 od while not B(x) do 8 producenext(z); send z on c 10 od proc consume = (m x): 2 if x <> 0 then r := x * r 4 fi 6 proc producenext = (var m x): if x <> 0 then 8 x := x-1 fi 10 B(x) = (x = 0) 12 m = nat Sender: schickt die Zahlen x0-1, x0-2,..., 0 Empfänger: multipliziert die Zahlen in r auf. Wichtige Fragen: 1. Was passiert, wenn receive v on c ausgeführt wird und keine Nachricht vorliegt? Prinzipielle Möglichkeiten: (a) Es wird eine leere Nachricht zurückgegeben. (b) Es wird gewartet, bis eine Nachricht vorliegt. Wir wählen den Fall (b). 2. Was passiert, wenn send E on c ausgeführt wird, aber kein Empfänger bereit ist, die Nachricht zu empfangen? (a) Die Nachricht geht verloren. (b) Es wird gewartet, bis ein Empfänger bereit ist und dann wird die Nachricht übergeben (Telefonprinzip, Handshaking, synchroner Nachrichtenaustausch).

30 26 KAPITEL 1. PROZESSE, INTERAKTION, KOORDINATION... (c) Die Nachricht wird gesendet, gegebenenfalls zwischengepuffert (d.h. in einem Puffer / einer Warteschlange zwischengespeichert), bis ein Empfänger empfangsbereit ist (d.h. eine receive Anweisung ausführt) (asynchroner Nachrichtenaustausch). Für (c) gibt es Varianten, falls die Puffergröße endlich beschränkt ist. Konvention: receive v on c und send E on c stehen für asynchronen, v? c und E! c für nachrichtensynchronen Nachrichtenaustausch. Achtung: Bei synchroner Arbeitsweise treten leicht Verklemmungen auf! 1 - send E1 on c1; 2 receive x1 on c2 send E2 on c2; 4 receive x2 on c1 - keine Verklemmung 1 - E1! c1; 2 x1? c2 E2! c2; 4 x2? c1 - Verklemmung Auch bei Regelung, wie viele der parallel ablaufenden Programme einen Kanal nutzen dürfen, können wir unterschiedliche Festlegungen treffen. 1. Pro Kanal gibt es genau ein Programm, das sendet, und ein Programm, das empfängt (exklusive Nutzung des Kanals). kein Nichtdeterminismus 2. Mehrere Sender: - send 1 on c send 2 on c receive x on c - Empfänger kann zuerst 1 oder zuerst 2 empfangen. Nichtdeterminismus 3. Mehrere Empfänger: - send 1 on c receive x on c receive y on c - Einer der Empfänger erhalt die Nachricht welcher, ist nicht festgelegt. Nichtdeterminismus Fazit: Beim asynchronen wie beim synchronen Austausch von Nachrichten entsteht Nichtdeterminismus, wenn parallel gesendet oder parallel empfangen wird. Beim asynchronen Nachrichtenaustausch findet ein Informationsfluss nur in eine Richtung statt vom Sender zum Empfänger. Anders beim synchronen Nachrichtenaustausch: Die Tatsache, dass eine Nachricht synchron übergeben wurde, liefert dem Sender die Information, dass der Empfänger eine entsprechende Anweisung ausgeführt hat. Im asynchronen Fall ist diese Form der Rückkopplung durch Rückkanäle zu übermitteln. Beispiel: Asynchrone Kommunikation mit Rückkopplung 1 sort ack = {ack}; 2 proc sender = (channel m c, channel ack a): 4 - var m z = z0; var ack y = ack; 6 while not B(z) do

31 1.3. PROGRAMMIERSPRACHEN ZUR BESCHREIBUNG c c Sender a Medium a Empfaenger Abbildung 1.10: Entkopplung von Sender und Empfänger durch ein Medium Sender Medium Empfaenger ack on a m on c ack on a m on c Abbildung 1.11: Message Sequence Chart producenext(z); 8 receive y on a; send z on c 10 od - 12 proc receiver = (channel m c, channel ack a): - var m x := z0; 14 while not B(x) do send ack on a; 16 receive x on c; consume(x) 18 od - 20 channel m c, channel ack a; - sender (c, a) receiver (c, a) - Frage: Wie können wir Sender und Empfänger besser entkoppeln? 1 proc medium = (channel m c, c, channel ack a, a ): 2 - var m t := t0; var ack test = ack; 4 while true do send ack on a; 6 - receive test on a receive t on c - ; send t on c 8 od - Frage: Wie muss das Medium formuliert werden, um Sender und Empfänger noch stärker zu entkoppeln? Diese Muster der Zusammenarbeit können anschaulich in Interaktionsdiagrammen (Message Sequence Charts, MSC) beschrieben werden (s. Abb. (1.11)). Zusammenarbeit: - sender (c, a) medium (c, c, a, a ) receiver (c, a ) - Auch das Steuern und Regeln von Systemen (Stichwort: eingebettete Systeme ) kann über Nachrichtenaustausch modelliert werden.

32 28 KAPITEL 1. PROZESSE, INTERAKTION, KOORDINATION... Crashsensor Speedsensor c s Airbag Controller a p Zuend mechanismus Panel Abbildung 1.12: Airbagsteuerung Beispiel: Airbagsteuerung (ohne Echtzeitbetrachtung) 1 sort crashsignal = {ok, crash, error}; 2 proc airbagcontroller = (channel crashsignal c, p, a, 4 channel nat s): - var nat speed := 0; 6 var bool on := true; var crashsignal cs := ok; 8 while on do - receive speed on s receive cs on c - ; 10 if cs = ok then send ok on p 12 elif cs = crash then if speed > 20 then 14 send crash on a else 16 send crash on p; on := false 18 fi else 20 send error on p; on := false 22 fi od - Obwohl in diesem Programm das wichtige Thema Echtzeit ausgespart ist, wird die Logik des Auslöseverhaltens doch sichtbar. Mit den soweit verfügbaren Sprachmitteln können wir nicht alternativ auf Nachrichten von unterschiedlichen Kanälen warten. Dafür benötigen wir ein weiteres Sprachmittel. Dieses Konzept der Guarded Communication Commands geht zurück auf die Guarded Commands von Edsger Dijkstra (+ 2002) und CSP von Tony Hoare. gcc ::=do igcom od if igcom fi igcom ::= gcom { gcom } gcom ::= exp : send exp on id then statement exp : receive id on id then statement exp : exp! id then statement exp : id? id then statement Beispiel: Nachrichtenweiche 1 sort weiche = {links, rechts, alle};

33 1.3. PROGRAMMIERSPRACHEN ZUR BESCHREIBUNG var weiche w := alle; var m v :=...; 4 do w <> links: receive v on y then send v on r 6 [] w <> rechts: receive v on x then send v on r [] true: receive w on z then nop 8 od Nachrichtenaustausch über gemeinsame Variablen Tritt in parallel ablaufenden Programmen eine Variable in einem Programm auf der linken Seite einer Zuweisung ( wird geschrieben ) und in mindestens einem weiteren Programm auf (gelesen oder geschrieben), dann sprechen wir von einer gemeinsamen Variablen. Bei gemeinsamen Variablen ist es entscheidend, festzulegen, welche Anweisungen atomar ( in einem Stück, ununterbrochen, unteilbar ) ausgeführt werden, da die Verzahnung der Anweisungen Auswirkungen auf das Ergebnis hat. Darüber hinaus wollen wir die Ausführung bestimmter Anweisungen zurückstellen, bis gewisse Bedingungen gelten. Diese Forderungen erreichen wir durch folgendes Sprachkonstrukt: await E then S endwait (bewachter kritischer Bereich) mit: E boolescher Ausdruck, Wächter S Anweisung, kritischer Bereich Beispiel: 1 var nat x, y := 0, 0; 2 - await y > 0 then x := x+1 endwait await true then y := y+1 endwait - Hier ist y gemeinsame Programmvariable. Die Anweisung wird wie folgt ausgeführt: Sobald die Bedingung E wahr ist, wird die Anweisung S als unteilbare Aktion ausgeführt. Falls E nicht wahr ist (dabei erfolgt auch die Auswertung von E als atomarer Schritt), wird gewartet, bis E zutrifft. Achtung: Die Auswertung von E auf wahr und die Ausführung von S wird ebenfalls als unteilbare Aktion gesehen. wenn mit der Ausführung von S begonnen wird, ist E sicher wahr. Falls E nie wahr wird, ist die Ausführung des Programms für immer blockiert. Beispiel: Parallele Berechung der Fakultät 1 var bool taken, var nat y, x, z := true, 1, n, 0; 2 - while n > 0 do await taken then taken, z := false, n endwait; 4 n := n-1 od 6 while x > 1 do await not taken then taken, x := true, z endwait; 8 y := y*x od -

34 30 KAPITEL 1. PROZESSE, INTERAKTION, KOORDINATION... Gemeinsame Variablen ( shared variables ): taken, z Wichtig: Hier kommen gemeinsame Variablen nur innerhalb von await Anweisungen vor. Die Feststellung, ob eine Variable als gemeinsame Variable benutzt wird, ist syntaktisch überprüfbar. Ob alle gemeinsamen Variablen nur innerhalb von await Anweisungen auftreten, ist auch syntaktisch überprüfbar. Auch wenn der Zugriff auf gemeinsame Variablen durch await geschützt wird, kann Nichtdeterminismus auftreten: 1 var bool taken, var nat x, y := false, 0, 0; 2 - await true then if not taken then 4 taken := true; x := 1 6 fi endwait 8 await true then if not taken then 10 taken, y := true, 1 fi 12 endwait - Nachbedingung: {taken ((x = 1 y = 0) (x = 0 y = 1))} Zusammenhang zum Nachrichtenaustausch: Asynchroner Nachrichtenaustausch kann durch eine Warteschlange als gemeinsame Variable in Programmen modelliert werden. channel m c steht für var queue m c := emptyqueue send E on c steht für await true then c := stock(c, E) endwait receive v on c steht für await c <> emptyqueue then v, c := first(c), rest(c) endwait Eines der frühen Mittel zur Synchronisation von parallel ablaufenden Programmen sind Semaphore. Ein ganzzahliges (genau natürlichzahliges) Semaphor entspricht einer Variablen der Sorte nat, die nur in einer genau festgelegen Weise verändert und gelesen werden darf. Deklaration eines Semaphors: sema nat x := n; Operationen: 1 proc P = (sema nat x): 2 await x > 0 then x := x-1 endwait 4 proc V = (sema nat x): await true then x := x+1 endwait Beispiel: Erzeuger / Verbraucher durch Semaphore 1 sema nat s1, s2 := 0, 1; 2 var m x, y, z := x0, y0, z0; - while not B(x) do 4 P(s1); x := y; 6 V(s2);

35 1.3. PROGRAMMIERSPRACHEN ZUR BESCHREIBUNG p 0 p 1 p 4 p 2 p 3 Abbildung 1.13: Fünf Philosophen consume(x) 8 od while not B(z) do 10 producenext(z); P(s2); 12 y := z; V(s1); 14 od - Gemeinsame Variablen: s1, s2, y Jetzt ist die Frage, ob der Zugriff auf gemeinsame Variablen geschützt ausgeführt wird, keine syntaktische Eigenschaft mehr, sondern Teil der Logik des Programms. Boolesche Semaphore: 1 sema bool s := b; 2 proc P = (sema bool s): 4 await s then s := false endwait 6 proc V = (sema bool s): await true then s := true endwait Beispiel: Problem der fünf dinierenden Philosophen (englisch: dining philosophs) Jeder Philosoph braucht zwei Gabeln, um zu essen. Jeder Philosoph isst und denkt abwechselnd. 1. Lösung: Wir verwenden await 1 var array [0:4] bool gabeln; 2 gabeln[0],..., gabeln[4] := true,..., true; 4 proc philo = (nat i): while true do 6 think; await gabeln[i] and gabeln[i+1 mod 5] then 8 gabeln[i], gabeln[i+1 mod 5] := false, false endwait; 10 eat; await true then 12 gabeln[i], gabeln[i+1 mod 5] := true, true endwait

36 32 KAPITEL 1. PROZESSE, INTERAKTION, KOORDINATION od 16 - philo(0)... philo(4) - Ziel des parallelen Programms zur Synchronisation der Philosophen: Deadlock ( zyklische Wartezustände ) vermeiden! Starvation vermeiden! Kein Programm verhungert, indem es nie zum Zug kommt. Sind die Synchronisationsmittel fair? Schwache Fairness: Wenn jemand unbeschränkt lange wartet und die Fortsetzungsbedingung immer wahr ist, dann kommt er schließlich zum Zug. Starke Fairness: Wenn jemand unbeschränkt lange wartet und die Fortsetzungsbedingung immer wieder wahr wird, dann kommt er schließlich zum Zug. Kritischer Bereich wird geschützt. Stehen nur Semaphore zur Verfügung (kein await), so wird es schwierig, die Wartebedingung auszudrücken. 2. Lösung (1 Semaphor) 1 sema nat s := 1; 2 proc philo = (nat i): - var bool ready := false; 4 while true do think; 6 ready := false; while not ready do 8 P(s); if gabeln[i] and gabeln[i+1 mod 5] then 10 gabeln[i], gabeln[i+1 mod 5] := false, false; ready := true 12 fi; V(s) 14 od; eat; 16 P(s); g[i], g[i+1 mod 5] := true, true; 18 od - Lösung ohne busy wait : Jede Gabel entspricht einem Semaphor. 1 array[0:4] sema nat g; 2 g[0],..., g[4] := 1,..., 1; proc philo = (nat i): 4 - while true do think; 6 P(g[i]); P(g[i+1 mod 5]); 8 eat; V(g[i]); 10 V(g[i+1 mod 5]); od -

37 1.3. PROGRAMMIERSPRACHEN ZUR BESCHREIBUNG Achtung: Deadlock, falls alle Philosophen gleichzeitig die linke Gabel aufnehmen! Lösungsidee: Bei Philosoph 4 die Anweisungen P(g[0]) und P(g[4]) vertauschen. Beobachtungen: 1. Gabel 4 ist frei oder einer der Philosophen 3 oder 4 hat beide Gabeln. 2. Gabel 3 ist frei oder Philosoph 2 hat beide Gabeln oder Philosoph 3 hat sie. Konsequenz: Einer der Philosophen ist immer essbereit oder die Gabeln für ihn sind frei. kein Deadlock! (Präzise Argumentation: über Invarianten) 3. Lösung: Jeder hungrige Philosoph trägt sich in eine Warteschlange ein. 1 array[0:4] sema nat k; 2 k[0],..., k[4] := 0,..., 0; var queue nat q := emptyqueue; 4 proc philo = (nat i): - while true do 6 think; P(s); 8 q := stock (q, i); V(s); 10 P(k[i]); P(s); 12 g[i], g[i+1 mod 5] := false, false; V(s); 14 eat; P(s); 16 g[i], g[i+1 mod 5] := true, true; V(s); 18 od - 20 proc manage =: - var bool busy = false; 22 var nat i := 0; while true do 24 P(s); if q <> emptyqueue then 26 i, q, busy := first(q), rest(q), true fi; 28 V(s); P(s); 30 if g[i] and g[i+1 mod 5] then V(h[i]); 32 busy := false; fi 34 V(s) od - Frage: Behindern sich die Philosophen mehr als unbedingt erforderlich? Ein Sprachelement, das die synchronisierte Arbeitsweise mit gemeinsamen Variablen regelt (ohne Semaphoren oder await) sind Monitore (nach C.A.R. Hoare, Per Brinch-Hansen). Idee: In einem Monitor werden wie in einem Objekt in der objektorientierten Programmierung gemeinsame Variablen gekoppelt. Zugriff auf gekapselte Variablen erfolgt nur über Prozeduren (in der Objektorientierung Methoden).