Skript Betriebssyteme I SS05Dozent: Prof. Dr. Dieter Zöbel

Verfasst von: Ilka Uerz

Version: 2.12

(aktuelle Version unter www.uni-koblenz.de/~chnee)

Verbesserungsvorschläge und gefundene Fehler bitte an

chnee@uni-koblenz.de

InhaltsverzeichnisInhaltsverzeichnis...............................................................................................................................10 Allgemeines.......................................................................................................................................4

0.2 Konzept BS I + II.......................................................................................................................40.3 Organisatorisches.......................................................................................................................40.4 Infrastruktur zur Nutzbarmachung von Rechnungssystemen....................................................4

1 Einführung.......................................................................................................................................51.1 Aufgabenstellung von BS..........................................................................................................5

1.1.1 Nutzbarmachung des Rechensystems ...............................................................................51.1.2 Zielrichtung bei der Gestaltung..........................................................................................51.1.3 Sicht: Rolle des Vermittlers von Betriebsmitteln..............................................................51.1.4 Sicht: Unterschiedliche Benutzer und Benutzungen..........................................................51.1.4.1 Nutzer der (vorinstallierten) Software (+BS)..................................................................51.1.4.2 Selbständige Nutzer der Anwendungen eines Rechensystems.......................................51.1.4.3 Administratoren von Rechensystemen (z.b. im Rechenzentrum)...................................51.1.4.4 Anwendungsentwickler Schnittstellen............................................................................61.1.4.5 Entwickler von Komponenten (außerhalb des Kerns) z.B. von Treibern.......................61.1.4.6 Entwickler (u. Stratege) bei BS-Entwicklung.................................................................6

1.2 Betriebsarten..............................................................................................................................61.2.1 Stapelbetrieb (batchmode).................................................................................................61.2.2 Dialog- bzw. Gesprächsbetrieb (interactive mode)............................................................61.2.3 Echtzeitbetrieb...................................................................................................................61.2.4 Serverbetrieb im Netz .......................................................................................................6

1.3 Epochen der Betriebsystementwicklung....................................................................................61.4 Meilensteine der BS-Entwicklung.............................................................................................8

2 Aufbauprinzipien von BS...............................................................................................................82.1 Ziele...........................................................................................................................................82.2 Monolithische BS......................................................................................................................82.3 Schalenorientierter Aufbau .......................................................................................................9

2.3.1 Virtuelles Aufbauschema.................................................................................................102.3.2 Partitionierung..................................................................................................................10

2.4 Client-Server-Modell...............................................................................................................102.5 Schema der IPC........................................................................................................................11

3 Genealogie der wichtigsten BS.....................................................................................................123.1 Def. Programmierschnittstelle POSIX.....................................................................................133.2 LINUX.....................................................................................................................................13

3.2.1 Typische Bestandteile einer LINUX-Distribution............................................................133.2.2 Entwicklung ....................................................................................................................133.2.3 Anwendungsbereiche.......................................................................................................13

3.3 Microsoft..................................................................................................................................143.3.1 Entwicklung ....................................................................................................................14

4 Anwendungsbereiche für Betriebssysteme..................................................................................144.1 Entwicklungsformen von Echtzeitbetriebssystemen...............................................................14

4.1.1 Strukturen.........................................................................................................................144.2 Mobile Betriebssysteme...........................................................................................................15

4.2.1 Technische Voraussetzungen...........................................................................................165 Deadlock (Verklemmung).............................................................................................................16

5.1 Problemstellung und Formalisierung.......................................................................................165.2 Vier notwendige und hinreichende Bedingungen für die Existenz eines Deadlock ...............185.3 Bereich DV und Existenz von Deadlocks................................................................................18

1

5.3.1 Deadlocks in der parallelen Programmierung..................................................................185.4 Problem: Verwaltung von Betriebsmitteln..............................................................................18

5.4.1 Bankers Problem .............................................................................................................195.4.2 Scheduler..........................................................................................................................20

5.5 Methoden der Deadlockbehandlung (Zoebel)..........................................................................205.6 Einfache Verfahren zur Deadlockbehandlung.........................................................................22

5.6.1 Vermeidung: Methode zur Berechnung eines sicheren Zustandes..................................236 Parallele Programmierung...........................................................................................................24

6.1 Parallele Prozesse ...................................................................................................................246.1.1 Programmiertechnische Unterscheidung..........................................................................246.1.1.1 Erzeugung paralleler Prozesse am Beispiel der pthread-Bibliothek unter POSIX........246.1.1.2 Synopse von pthread-Funktionen..................................................................................256.1.2 Begriffe............................................................................................................................266.1.3 Berechnungsmodelle........................................................................................................27

6.2 Parallelität und deren notwendige Beschränkungen................................................................286.2.1 Beispiel: Das Erzeuger-Verbraucher-Problem.................................................................286.2.1.1 Invariante: ....................................................................................................................306.2.1.2 Bedeutung der Synchronisierung..................................................................................306.2.1.3 Betrachtung der Invarianten I2 des Erzeuger-Verbraucher-Problems (Mittel zurEinführung kritischer Gebiete)..................................................................................................30

6.3 Entwurf und Verifikation paralleler Prozesse ........................................................................326.3.1 Parallelausführung von Anweisungen (und Abbildung in atomare Anweisungen).........336.3.2 Parallele Ausführung von Anweisungen, die sich nicht in atomare Ausführungenübersetzen lassen.......................................................................................................................336.3.3 Formale Beschreibung der Bedeutung von Programmen (Semantik) angewandt aufparallele Anweisungen..............................................................................................................346.3.3.1 Spezifikation der Parallelanweisung.............................................................................346.3.3.2 Unabhängigkeitsregel....................................................................................................346.3.3.3 Handout "at-most-once", Parallelanweisung, UR.........................................................356.3.3.4 Schwächung..................................................................................................................366.3.4 Konstrukt für die Synchronisierung.................................................................................376.3.4.1 Spezifikation des gegenseitigen Ausschlusses..............................................................376.3.4.2 Programm für den gegenseitigen Ausschluss mit <await....>.......................................38

6.4 Eigenschaften von parallelen Programmen..............................................................................396.4.1 Handout Beispiele zur Fairness........................................................................................40

6.5 Elementare Synchronisierungsmethoden.................................................................................416.5.1 Gütekriterien für eine Lösung .........................................................................................426.5.2 Dekker'sche Lösungen (1966) zum gegenseitigen Ausschluss .......................................426.5.2.1 1. Dekker'sche Lösung .................................................................................................426.5.2.2 Handout 2.-4. Dekker'sche Lösung ..............................................................................436.5.2.3 Lösungen nach Peterson................................................................................................456.5.3 Bedeutung der Lösungen nach Dekker u. Peterson..........................................................466.5.4 Synchronisierung mit Hilfe mächtiger Maschinenbefehle...............................................476.5.4.1 Betreten und Verlassen eines krit. Gebietes mit dem ts(x,y)-Befehl............................476.5.4.2 test_and_set unter Linux...............................................................................................48

6.6 Semaphore...............................................................................................................................496.6.1 Semantik der Semaphoroperationen................................................................................496.6.2 Lösung des Erzeuger-Verbraucher-Problems..................................................................506.6.2.1 Handout E-V-Problem mit Semaphoren.......................................................................506.6.3 Implementierung von Semaphoroperationen via Systemaufruf.......................................50

6.7 Paradigmen der parallelen Programmierung............................................................................51

2

6.7.1 Leser-Schreiber-Problem.................................................................................................516.7.1.1 Fairness bei Semaphoroperationen...............................................................................546.7.2 Das Fünf-Philosophen-Problem.......................................................................................55

6.8 Monitore (Hoare, 1974)...........................................................................................................566.8.1 Monitore und parallele Prozesse .....................................................................................566.8.2 Synchronisierungseigenschaften des Monitors................................................................576.8.2.1 Handout Implementationsteil des Moduls puffer.........................................................596.8.3 Zustandsmodell für Monitore...........................................................................................606.8.4 Entwurf und Verifikation von Programmen mit Monitoren............................................60

7 Modellbildung und Analyse..........................................................................................................627.1 Einführung...............................................................................................................................62

7.1.1 Allgemeine Zielsetzung...................................................................................................647.2 Der Ankunftsprozess (Zufallsprozess).....................................................................................64

7.2.1 Annahmen über den Ankunftsprozess (allgemeingültig).................................................657.2.2 Mittlere Anzahl von Ankünften bis zum Zeitpunkt t.......................................................667.2.3 Zwischenankunftszeiten...................................................................................................667.2.3.1 Verteilung von Zwischenankunftszeiten.......................................................................677.2.4 Markov-Eigenschaft → Eigenschaft der Gedächtnislosigkeit.........................................68

7.3 Eigenschaften der Bedienung...................................................................................................687.3.1 Charakteristische Daten für die Exponentialverteilung X (z.B. ANS(t)).........................69

7.4 Satz von Little..........................................................................................................................697.5 Kendall-Notation (für dienstleistende Systeme)......................................................................707.6 M/M/1-Systeme.......................................................................................................................70

Versionshinweise...............................................................................................................................73

3

0 Allgemeines

0.2 Konzept BS I + IIBS I 4 V + 2 Ü SS 2005"Theorie""operativ"

1. Einführung2. Deadlocks

3. Parallelität + Synchronisierung4. Modellbildung + Analyse

BS II 4 V SS 2006"praktisch" 5. Aufbauprinzipien von BS

6. Komponenten der BS7. Verteilte (Betriebs)Systeme

0.3 OrganisatorischesVorlesung: 17. - 24. KW20. KW Pfingstferien!Übungsblätter Ausgabe: Mittwoch 12 Uhr

Abgabe: Montag 12 Uhr Fach in MB12 Punkte pro Blatt, evtl. 2 Blätter pro WocheKlausur: Freitag, 17.06.05 8:00 Uhr D028

0.4 Infrastruktur zur Nutzbarmachung von Rechnungssystemen• softwaretechnische Struktur

• Betreiberaspekte (Rechenzentrum, ...)• Sicherheitskonzepte

• Verteilte Systeme

• programmiertechnischer Zugang• Konzepte zu Parallelität und Synchronisierung

• Leistung von Dienstleistungssystemen

• Modellbildung und Analyse

4

1 Einführung

1.1 Aufgabenstellung von BS

1.1.1 Nutzbarmachung des Rechensystems • Prozessor

• (Haupt-, Hintergrund-)Speicher

• Geräte• Netzwerke

1.1.2 Zielrichtung bei der Gestaltung• ergonomische Schnittstelle (GUI = Graphic User Interface)

• Ausnutzung von Leistungsfähigkeit (Optimierung von Algorithmen)• Anpassung der BS an unterschiedliche u. wechselnde Aufgaben (z.b. Skalierbarkeit)

• Schutz der Benutzer/Anwendungen vor fehlerhafter und/oder zerstörerischer Benutzung

• Abstraktion der technischen Einzelheiten d. Rechensystems

1.1.3 Sicht: Rolle des Vermittlers von BetriebsmittelnAuch programmiertechnisch (API = Application Programming Interface)

• Prozessor• Speicher• Geräte

• Anwendungssoftware

1.1.4 Sicht: Unterschiedliche Benutzer und Benutzungen

1.1.4.1 Nutzer der (vorinstallierten) Software (+BS)• GUI• Drucker

• Dateibaum

1.1.4.2 Selbständige Nutzer der Anwendungen eines Rechensystems• Installationen• Anbau von Geräten

1.1.4.3 Administratoren von Rechensystemen (z.b. im Rechenzentrum)• Installationsaufwand

• Wartungsaufwand• Schutzmechanismen (Benutzer)

5

1.1.4.4 Anwendungsentwickler Schnittstellen• Nutzung von APIs zum Betriebssystem

• Kenntnis d. Funktionsweise von BS-Komponenten, Datenaustausch, Formate,...

• Nutzung und Manipulation der GUIs

1.1.4.5 Entwickler von Komponenten (außerhalb des Kerns) z.B. von Treibern• Kenntnis der SPI (System Programmers Interface)• Kenntnis zu Datenformaten,...

1.1.4.6 Entwickler (u. Stratege) bei BS-Entwicklung• umfassende Kenntnis von softwaretechnischer Seite (neue Konzepte, z.B. objektorientiert)• Kenntnis des Anwendungsfeldes (Anpassung an Ziele, z.B. der Märkte)

• Entwicklung von SPIs

1.2 Betriebsarten

1.2.1 Stapelbetrieb (batchmode)• Übergabe zusammenhängender Auftragsfolgen (z.B. Verbuchung aller Kontenbewegungen

eines Tages) - Im Aufwind!

1.2.2 Dialog- bzw. Gesprächsbetrieb (interactive mode)• Teilfolgen von Anfragen werden im Dialog behandelt

• Einstieg in Time-Sharing-Betrieb

1.2.3 Echtzeitbetrieb• Aufträge werden (sollen) unter vorgegebenen Zeitbedingungen erledigt (werden), z.B. ABS • eingebettete Systeme

• Systeme treten nicht in Erscheinung

• eingeschränkte Bedienungsstruktur (z.B. Treten der Bremse bei ABS)

• autonome Systeme (mission: haben "Auftrag")

• allgegenwärtige Systeme (ubiquitous systems)• "Rechner als universeller Helfer in allen Lebenslagen"• keine übliche Benutzerschnittstelle ("Ahnung, was der Benutzer braucht")

• Koordination und Kooperation mit Systemen (in der Nähe, mit verwandten Aufgaben,...)

1.2.4 Serverbetrieb im Netz • via Fernaufruf (remote procedure call)

• Abarbeitug vieler Arbeitsaufträge nach dem Client-Server-Paradigma

1.3 Epochen der Betriebsystementwicklung• Tanenbaum

6

• MINIX → LINUX

[Abb1: Zeichnung nach Tanenbaum, geändert von Zöbel]1. elektrische Röhre2. Transistor

3. Informatik als eigenständige Wissenschaft4. hochintegrierte Schaltkreise5. Rechner am WAN

6. Rechner allgegenwärtig• lokaler Rechner = "Tor zur Welt"

• Zusammenwachsen von Telekommunikationsdiensten und Internetdiensten

• Hochleistungsnetzwerke (im LAN, WAN, letzter Kilometer) sehr leistungsfähig • Client-Server-Paradigma

Anwendungsbereiche:(1)Militär, Universitäten(2)Großunternehmen, Banken, Versicherung (IBM), Verwaltung

(3)Rechner in allen Bereichen der Industrie, Steuerungsrechner (Pascal), gesellschaftlicheAuswirkungen der DV

(4)Rechner am Arbeitsplatz, Rechner im privaten Bereich (Siegeszug Microsoft)

7

• 5 M-Modell für Arbeitsplatzrechner• 1 Million instructions per second

• 1 MB Hauptspeicher• 1 Million Bildpunkte

• 1 MBit Datenrate im LAN

• Mehrprogrammbetrieb• virtuelle Adressierung (MMU)• objektorientierte Programmierung

1.4 Meilensteine der BS-Entwicklung• Mehrprogrammbetrieb• virtuelle Adressierung

• Mikrochiparchitektur

• C-S-P

• Multiprozessorbetrieb

2 Aufbauprinzipien von BS

2.1 Ziele• Blickwinkel + Betrachtungsweisen

• Kategorisierung (z.B. Tanenbaum)

2.2 Monolithische BS• Benutzer sieht das BS wie ein geschlossenes Programm(system)• Systemaufruf

[Abb2: Systemaufruf]1. Systemaufruf (read()) wird umgesetzt in einem programmierten Interrupt (trap) und gelangt

ins Betriebssystem2. Die Interruptbehandlung (ISR = interrupt service routine) erkennt den Interrupt und

behandelt ihn (entsprechend der mitgegebenen Parametern); synchrone Abarbeitung

3. Unmittelbare Fortsetzung der Verarbeitung hinter dem Systemaufruf• Systemaufruf unter Linux:

8

int $0x80 (Unterbrechungsvektor 128 + Umschaltung in den KernelModus)syscall number (via Register eax, Identifikation der Interrupts)

ret_from_syscall() lässt Verarbeitung weiterlaufen

2.3 Schalenorientierter Aufbau • funktionaler Aufbau: Hardware-Nähe

1. Prozessverwaltung2. Datenverwaltung3. Speicherverwaltung

4. Geräteverwaltung5. Benutzer&Anwenderprogramme6. GUIs

7. Shells[Abb3: Schalenorientierter Aufbau]

Prozess: Abstraktionsobjekt, Thema vor allem auf Anwenderschale, bei der Entwicklung nach innengetrieben

• Schalenorientierung: Welche Funktion benötigt welche andere Funktion?

[Abb4: Abhängigkeiten, von unten nach oben]

• Strukturierte BS-Entwicklung nach Holt

[Abb5: BS-Entwicklung nach Holt]

9

2.3.1 Virtuelles Aufbauschema

[Abb6: Aufsetzen eines BS B auf die Funktionalität von BS A]Das Aufsetzen von Betriebssystemen kann z.B. bei Großrechnern mit nur rudimentärer grafischerBenutzeroberfläche nützlich sein.

[Abb7: Aufsetzen von z/OS auf den zSeries-Großrechner von IBM]

2.3.2 Partitionierung• Oft im Hochsicherheitsbereich (Bereichen mit hoher Verlässlichkeit) eingesetzt.

• z.B. Lynx OS-178, für Flugzeugindustrie entwickelt:

[Abb8: Beispiel Lynx OS-178]

2.4 Client-Server-Modell• Aufgabe des Kerns: Abwicklung der Nachrichtenübertragung (IPC) zwischen Benutzer- und

Dienstprozessen• Def. Kern: der Teil des BS, der unverzichtbar ist für dessen „Funktionalität“

• Vorteile:• kleiner Kern, wenig fehleranfällig

• saubere Schnittstelle (SPI), abarbeiten der IPC

10

• Speicherverwaltung (hauptsächlich Hauptspeicher)• homogene Behandlung von Benutzer&Dienstprozessen

• klare Objektstruktur, Kapseln mit Schnittstellen: Methoden, die per Nachrichtaufgerufen werden

• nur das muss auf ein BS gepackt werden, was für die Aufgabe notwendig ist(Skalierbarkeit)

• Nachteile:• hoher zeitlicher Aufwand bei der Abwicklung der IPC (IPC kommt häufig vor)

2.5 Schema der IPC

[Abb9: Schema der IPC]

[Abb10: Schema IPC im Netz, z.B. Mach3, QNX]• Bsp.: Mikrokern-BS: QNX

• POSIX-fähig (will programmieren BS-unabhängig machen)

• Kerngrösse 60 kB

[Abb11: Kommunikation zwischen Prozessen von zwei QNX-Kernen]

11

• Aussehen der IPCs

[Abb12: synchroner Nachrichtenaustausch]• reply benötigt kein receive!

3 Genealogie der wichtigsten BS• LINUX ↔ Windows• UNIX ↔ proprietär

• MULTICS (1969) → UNIX (1972, Ken Thompson, Brian Kernighan) C (1972, Kernighan, Ritchie; UNIX in C-Code)

[Abb13:Genealogie von UNIX]

12

• SVID: System V Interface Definition (1986)• OSF: Open System Foundation (1988, AT&T, Sun, IBM, Siemens, IEEE)

• OS/OPEN (199x, POSIX: Portable Operating System for Computer Environments)

3.1 Def. Programmierschnittstelle POSIX• Unabhängig vom BS, UNIX-Nähe scheint durch

• C-Schnittstelle

• 1003.1 POSIX application interface (z.B. read(..))

• 1003.2 POSIX shell & command utilities• 1003.4 POSIX Real-Time extension (z.B. alle Semaphor-Operationen, Erzeugen von

Prozessen)• Auch WinXP hat POSIX-Schnittstelle

3.2 LINUX• monolithisches Makro-Kern-BS• Nachladen von Kernelmodulen (LKM = loadable kernel modules)

3.2.1 Typische Bestandteile einer LINUX-Distribution• Linux Kernel

• KDE-Oberfläche• MySQL

• Gnu-Software: z.B. C/C++ Compiler• Apache, Samba, Zope (Netzwerkdienste)

3.2.2 Entwicklung • 200 registrierte Entwickler

• Code offengeleget• Versionen

• 2.1.x, 2.3.x, 2.5.x,... Entwicklerversionen

• 2.0.x, 2.2.x, 2.4.x,... stabile Versionen

3.2.3 Anwendungsbereiche• Desktop-Bereich• Server

• eingebettete Systeme (embedded LINUX, RT LINUX)• LINUX auf Großrechnern (IBM)

13

3.3 Microsoft

3.3.1 Entwicklung • 1981: MS-DOS 1.0 (12 kByte, Intel 8088), Einbenutzer-orientiert• 1983: MS-DOS 2.0

• 1992: MS-DOS 6.22 (Windows-Technik)• 1985: Windows 1.0 als GUI zu DOS erhältlich• 1987: Windows 2.0

• 1990: Windows 3.0• 1992: Windows 3.1• 1995: Windows 95

• 1998: Windows 98

• 2000: Windows ME1. WindowsNT-Linie

• 1996: Windows NT 4.0• Windows 2000• 2001/2002: WindowsXP

2. Anwendungsklasse Handy, PDA

• 1996: Windows CE 1.0 (gegen PalmOS) • 2000: Windows CE 3.0

4 Anwendungsbereiche für Betriebssysteme1. Echtzeit BS2. Großrechner BS

3. Server BS

4. Mobile BS5. Embedded BS (Kombination aus Echtzeit- und Mobile BS)

4.1 Entwicklungsformen von Echtzeitbetriebssystemen• Lebhafter Bereich der BS-Entwicklung

• z.B. LynxOS, QNX, OSEK (z.B. im Fahrzeugbereich verwendet)

4.1.1 Strukturen• real-time executives

• setzen auf dem BS auf

• unterstützen Mehrprogrammbetrieb (mehrere aktive Prozesse)

14

• unterstützen Zeitfunktionen (zum Wecken von Prozessen)• z.B.: RT-Kernel

• Umbau eines „normalen“ BS zu einem Echtzeit-BS (Kompromiss)• Embedded LINUX

• Solaris

• AIX• Forderung: zeitliche Vorhersagbarkeit für alle BS-Funktionen

• von Grund auf neu entwickelt:

• IRMX, EUROS• POSIX-Erweiterung 1003.1b (real-time extension 1003.1-2001)

• Semaphore

• Memory Mapped Files• Prioritätsbasiertes Scheduling: der rechenbereite Prozess höchster Priorität ist berechtigt,

den Prozessor zu benutzen

• LynxOS hat diesen Standard• Scheduling angewandt auf Threads

• Liste aller Threads (muss manipulierbar sein)

• fixe/veränderbare Priorität (1-32)• Eingriffsmöglichkeiten

• policy: SCHED_FIFO, SCHED_RR

• priority: kann explizit gesetzt werden• aktive Abgabe der Prozessornutzung mit sched_yield(), legt den Prozess „schlafen“,

also ans Ende der Schlange

[Abb14: SCHED_FIFO]• Zeit-Verarbeitung

• Messen von Zeit

• Wecken von Prozessen

4.2 Mobile Betriebssysteme• PDA: personal digital assistant• portable Telefone (Handy)

15

4.2.1 Technische Voraussetzungen• Spezialisierte Mikroprozessoren (ARM,...)• Energie als Betriebsmittel

• eingeschränkte Interaktion mit dem Benutzer• BS nicht austauschbar• Echtzeiteigenschaften

• Kommunikation• z.B. Multimodale Tastatureingabe (z.B.: 2maliges drücken von B: entweder 2 Bs, oder

anderer Buchstabe, der ebenfalls auf B-Taste liegt)

• Marktbetrachtung• PalmOS (für PDA ohne Tastatur)

• Windows CE (SmartphoneOS)

• Linux (z.B. Montavista: embedded Linux für Motorola A760)• Handy

• SymbianOS (früher PSION): Ericson, Motorola, Nokia

• objektorientiert (in C++ geschrieben)

• Marktführer bei Handies• Java2MicroEdition

• Email, SMS, Telefonieren soll Plattformunabhängig sein

5 Deadlock (Verklemmung)

5.1 Problemstellung und FormalisierungUrsprung der Problematik:

• Während ihrer Ausführung greifen Prozesse auf Betriebsmittel zu, die sie ggf. auch exklusivbeanspruchen.

• Prozesse arbeiten sequentiell, Zurücknahme von Operationen ist schwierig, wenn nichtunmöglich.

• Erstes Auftreten von Deadlocks im Zusammenhang mit dem Mehrprogrammbetrieb(Pseudoparallelität) ab 1965, z.B. bei Multics

Beispiel: Deadlock beim exklusiven Zugriff zweier Prozesse auf zwei Dateien.P1:: ... P2:: ...

open(D1) open(D2)

open(D2) open(D1)

... ...

16

close(D2) close(D1)

close(D1) close(D2)

Ist zwar evtl semantisch korrekt, aber man weiß nicht, was wann abläuft.

[Abb15: Entstehung eines Deadlock]

• Grafische Repäsentation eines Deadlocks• Bsp.: Die Prozesse P1 und P2 beanspruchen Zugriff auf D1 und D2.

[Abb16: Darstellung eines Deadlocks durch einen Wartegraphen (process wait graph)]

[Abb17: Vereinfachter Wartegraph]

17

5.2 Vier notwendige und hinreichende Bedingungen für die Existenzeines Deadlock

• (Coffman, Elphik, Shohani, 1971)1. exklusiver Zugriff zu einem Betriebsmittel (mutual exclusion)2. Prozesse besitzen bereits Betriebsmittel und wollen diese behalten (no preemption)

3. Prozesse die Betriebsmittel besitzen warten darauf, weitere zu erhalten, d.h. sie sindblockiert (wait for condition)

4. Es existiert ein Zyklus von Prozessen, die Betriebsmittel besitzen und gleichzeitig auf denBesitz anderer warten.(cyclic wait condition)

5.3 Bereich DV und Existenz von Deadlocks• Betriebssystem-Bereich (klassisch): Besitz und Anforderung von Betriebsmitteln (Speicher,

Geräte,...) in unterschiedlichen Typen und Quantitäten

• Datenbanken:bei der Verarbeitung von Tranksaktionen• parallele Programmierung: Ziel ist es, zyklischen Wartebeziehungen zwischen Prozessen zu

verhindern. (BM-Zugriff, Synchronisierung, Kommunikationsoperationen)

• Netzwerke: Verstopfungen in Netzwerken, bei denen auf Grund von Speicherengpässen keineNachrichten mehr aufgenommen werden können

5.3.1 Deadlocks in der parallelen ProgrammierungBeispiel aus QNX: Basis sind die Kommunikationsoperationen von QNX.

Möglichkeiten: P1:: ... P2:: ...

send(P2,...) send(P1,..)

... ...

Die Prozesse warten aufeinander. → Deadlock

P1:: ... P2:: ...

receive(P2,...) receive(P1,...)

Die Prozesse wollen die Nachrichten voneinander gleichzeitig annehmen: → Deadlock

(Vermeidungsmöglichkeit: reveice(0,..), heißt: Prozess nimmt alle Nachrichten an, die auf ihnwarten; oder synchroner Nachrichtenaustausch (siehe oben.))

5.4 Problem: Verwaltung von Betriebsmitteln[Großbuchstabe gefolgt von Kleinbuchstaben: Vektor. Nur Großbuchstaben: Matrix n x t]

• Modellbildung:

Prozesse: PM = {P1,...,Pn}

BM: Dev = (dev1,...,devt) → t Typen von Betriebsmitteln, devi i ∈ {1,...,t} gibt an, wieviele Exemplare von diesem Typ vorhanden sind. (dev = Devices)

18

• Regeln: Prozesse besitzen Betriebsmittel..• für eine begrenzte Zeitdauer

• exklusiv • nicht entziehbar

• wieder verwendbar

• Verwalter von Betriebsmitteln: Scheduler• Notwendige Informationen Z (Zustand)

• Z = (GOAL, ALLOC, REQ)

• goalij = Maximalforderung von Prozess P i für BM von Typ j• allocij = Prozess besitzt schon BM von Typ j• reqij = BM des Typs j, den P i für die unmittelbare Fortsetzung braucht.

5.4.1 Bankers Problem Betriebsmittel: t = 1 „Geld“ (T €)Scheduler = Banker (1000 T €)

Vertrag: Bank ⇔ Bauherr

• jeder Bauherr kann (nicht sofort, aber schließlich) seine Maximalforderung an Geld (dieausgehandelt wurde) erhalten

300 100 200GOAL = 700 Annahme: ALLOC = 350 NEED = 350

500 400 100

needij := goalij – allocij

remj = devj - ∑ allocij , i ∈PM Rem = Remaining; was die Bank noch übrig hat

hier: Rem = 150Es gibt nur P3, der seine Maximalforderung erhalten kann

Fall:

Jetzt fordert P2 120 T€. Darf die Bank diese Forderung erfüllen?

Betrachtung des Folgezustands Z+:

100 200

ALLOC+ = 470 NEED+ = 230 Rem+ = (30)400 100

19

Im Zustand Z+ kann die Bank keine der Maximalforderungen erfüllen.→ Widerspruch zum Vertrag!

Zur Verdeutlichung Betrachtung von Z++: P1 fordert 40 T€, etc – nicht erfüllbarWas ist mit dem Zustand Z?

• Finde eine Permutation von Prozessen, die nacheinander ihre Maximalforderungen erfüllthaben können: d.h. nachdem P3 alle BM zurückgibt, stehen 550 zur Verfügung, danach P1,danach P2.

5.4.2 Scheduler• Scheduler hat die Aufgabe, nur sichere Zustände zuzulassen.

[Abb18: Abgrenzung sicherer/unsicherer Zustand]• Verzögert im Prinzip die Anforderungen

• Blockade des angeforderten Prozesses

[Abb19: Blockade von Anforderungen durch Scheduler]

5.5 Methoden der Deadlockbehandlung (Zoebel)a) Deadlockerkennung und -beseitigung (detection)

• Man lässt es darauf ankommen, dass Deadlocks auftreten• Notwendig:

1. permanente Prüfung, ob ein Deadlock vorliegt (detection)

2. Abbrechen der verursachenden Prozesse (oder einer Teilmenge) und Zurücksetzen dervon ihnen durchgeführten Aktionen (revocery + rollback)

20

b) Deadlockvermeidung (avoidance)• Bei jeder Betriebsmittelzuordnung wird geprüft, ob der Folgezustand noch sicher ist; dann

ist der Ausgangszustand ebenfalls sicher. • Voraussetzung: Kenntnis aller Prozesse und ihrer Maximalforderungen

c) Deadlockverhinderung (prevention)

• Beim Start eines Prozesses wird geprüft, ob dieser jemals zusammen mit den vorhandenenProzessen einen Deadlock erzeugen kann. Ist das der Fall, wird der Start eines Prozessesverhindert.

• Voraussetzung: Kenntnis aller Prozesse und ihrer Maximalforderungend) Deadlockfreier Systemaufbau

• Deadlocks treten hier nicht auf

• Prozesse verhalten sich nach Regeln (Schemata, Protokolle), die einen Deadlock nichtenstehen lassen

• Beispiel:

• Path expressions: sind nicht hinreichend • Priority Ceiling Protokoll

[Abb20: Methoden der Deadlockbehandlung veranschaulicht]

Schaden Grad anReglementierung

Aufwand Grad derParallelität

Erkennung undBeseitigung

-

Vermeidung +Verhinderung +

21

5.6 Einfache Verfahren zur Deadlockbehandlung• Ansatzpunkt: Außerkraftsetzen einer der vier notwendigen und hinreichenden Bedingungen1. mutual exclusion

• Variante: Leser-Schreiber-Problem

P1\P2 l sl + -s - -

• Typisch: keinerlei Einflussmöglichkeiten2. no preemption

• Typisch: keinerlei Einflussmöglichkeiten3. wait-for condition

• Anwendung: Forderung aller jemals benötigten Betriebsmittel in einer Operation

• „haben und fordern“ existieren nicht mehr

• Es werden Betriebsmittel belegt, die erst viel später gebaucht werden• Parallelität sehr stark reduziert, da evtl andere Prozesse die Betriebsmittel benöten

• Es ist nicht immer möglich, vorher zu sagen, welche Betriebsmittel benötigt werden4. circular-wait condition

• Verhinderung von Zyklen im PWG

• Idee: Hierarchisierung von Betriebsmitteln

• totale Ordnung der Betriebsmittel • Ein Prozess fordert die Betriebsmittel nur der Ordnung entsprechend (aufsteigend) an.

• Ein Prozess kann nur die Betriebsmittel anfordern, die höher in der Hierarchie liegenals die, die er bereits besitzt

• Nachteil:

• Man muss eine Ordnung definieren, also wissen, wer beteiligt ist

• Parallelität geht verloren

• Beispiel: D1 < D2P1:: .... P2:: ....

open(D1) open(D1)

open(D2) open(D2)

......

(open(D1))

P2 benötigt D1 eigentlich erst später, muss aber D1 nach vorne ziehen, da er sonst D2 nicht mehranfordern könnte.

22

5.6.1 Vermeidung: Methode zur Berechnung eines sicheren Zustandes• Algorithmus partitioniert die Prozessmenge

DM[0] = M[0] = Menge der im Zustand Z beendbaren Prozesse

DM[m+1] = Menge der Prozesse, die nach Beendigung der Prozessmenge M[m] und derRückgabe von deren BM beendbar sind

i ∈ PM heißt beendbar, wenn gilt: Needi ≤ Rem + ∑ Allock k ∈ M[m]

1. m = -12. ReserveM[m] = Rem

3. zusammen mit 44. M[m] = DM[m] = ø

5. Reserve[m+1] = Reserve M[m] + ∑ Allock k ∈ DM[m]

6. DM[m+1] = {i ∈ PM | Needi ≤ Reserve M[m+1]} – M[m]

7. M[m+1] = M[m] DM[m+1]8. m = m+1

9. Falls DM[m] ≠ ø weiter bei 5. • sicher: M[m] = PM• unsicher

• Beispiel: PM = {1,2,3,4,5} Dev = {10,12} 6 4 3 27 7 0 5

GOAL = 8 8 ALLOC = 3 3 Rem = (2,1) (Rem = Dev-ALLOC)4 2 1 0 3 2 1 1

[Abb21: Grafische Darstellung]

23

Höhe der „Türme“ = Rem + ∑ Alloc

DM[0] = {5} M[0] = {5} ReserveM[1] = (3,2)DM[1] = {1,4} M[1] = {1,4,5} ReserveM[2] = (7,4)DM[2] = {2} M[2] = {1,2,4,5} ReserveM[3] = (7,9)

DM[3] = {3} M[3] = {1,2,3,4,5} → sicherer Zustand!

6 Parallele Programmierung

6.1 Parallele Prozesse • Prozess:

• programmiertechnisches Abstraktionsobjekt

• eine Folge sequentiell abzuarbeitender Operationen auf einem eigenen Zustandsraum• weitgehende Unabhängigkeit von anderen Prozessen

6.1.1 Programmiertechnische Unterscheidung• Prozesstyp

• programmiertechnische Kapselung einer Aufgabe• z.B. Berechnung der Pixel einer Bildschirmzeile (ray tracing)

• Prozessinstanz

• gehört zu einem spezifischen Prozesstyp• ist ein eigener Zustandsraum zugeordnet• z.B. Berechnung der Bildschirmzeile 10

• Prozessausführung• genauer: eine Prozessinstanz in Ausführung

• z.B. die 10349548-te Berechnung der Zeile 10

6.1.1.1 Erzeugung paralleler Prozesse am Beispiel der pthread-Bibliothek unter POSIX• Sogenannte leichtgewichtige Prozesse • Vorbereitung

• gcc (C-Compiler)

• lpthread

• bsp.c erstellen:

#include <pthread.h>

void f(...){ //Prozesstyp

24

...

}

...

int main() {

erzeuge parallele Prozesse, //Instanzen erzeugen

die die Funktion f ausführen

}

[Abb22: Programmrumpf]

6.1.1.2 Synopse von pthread-FunktionenInt pthread.create(pthread*thread, //thread Zeiger auf pthread

const pthread.attr.t*attr, //Attribute des Prozesses (Record)

void* (*start.routine)(void*), //Prozesstyp hier eine Funktion

void*arg);

Besonderheit: implizierter Aufruf von pthread_exit(void*value_ptr) wenn in einer Funktion„start_routine“ ein return aufgerufen wird

• Status von threads

joinable detachedDer Wert (durch return) desThread wird einer Operationpthread_join() (analog: warte-Operation) bereitgestellt

Freigabe aller BM des Thread(z.B. Stapel)

Synpose: int pthread.join(

pthread*thread,

void** value.ptr) //Rückgabewerte

25

Beispiel:Es soll gezählt werden, wie viele Threads ausgeführt werden

[Abb23: Zählung ausgeführter Threads]

6.1.2 Begriffe• Supercomputing, z.B. Cray

• z.B. Berechnung von Wettervorhersagen• HPC ( High Performance Computing)

• Computer Cluster• z.B. Zuse (32 Linux-PCs); BicMac (1100 Apple PCs, ca. 10 TeraFlop Leistung)

• Grid Computing

• Nutzung der freien Leistung von ungenutzten PCs• unterschiedliche Rechner

• unterschiedliche Betriebssysteme

• unterschiedliche Administrationen• unsicheres Netz

• Zertifizierung notwendig

• Fehlertoleranz• Anwendungen mit hohen Erfordernissen an Rechenleistung (z.B. Rendering)• Verarbeitung dezentral anfallender Daten (z.B. Wettervorhersage)

• collaborative computing: Zusammenarbeit mit gemeinsamem Nutzen (z.B. virtuellerOperationsraum (CAVE))• CAVE: virtuelles Labor, in dem viele Forscher zusammen arbeiten

26

6.1.3 Berechnungsmodelle• Niedrige Abstraktionsebene

• sockets, remote procedure call (ganz niedrige Ebene)

• DCE (distributed computing environment)• höhere Abstraktionsebene

• PVM (parallel virtual machine)

• MPI (manage passing interface)• CORBA (common object request brolar)• Linda

• M. Carreiro, D. Gilernter: Linda in Context (CACM, April 1989 S. 444 – 458)• Philosophie von Linda:

Operationen sind aus Sicht der Prozesse zu betrachten

[Abb24: Tuple space]

• out („Hello“, 3, 1415, true)

Etwas wird in den Tuple Space hineingelegt

• in („Hello“, ?x, ?b) z.B. instanziert mit: in („Hello“, 3,1415, true)

Ein Tupel wird aus dem Tuple Space genommen• rd = read

Ein Tupel wird nur gelesen, nicht herausgenommen

• eval („e_fkt“, 2,91, exp(2,91))Legt eine Aufgabe in den Tuple Space, freier Prozess nimmt sich diese Aufgabe

• Grid computing mit Linda

• Bauhaus• objectiveLinda

27

• JOLTS (Java object Linda Tuple Space)• Condor

[Abb25: Filterung der Prozessanfragen durch LINDA]

6.2 Parallelität und deren notwendige BeschränkungenErzeugung paralleler Prozesse ParallelanweisungP1;

PARBEGIN

P0

...

Pn-1

PAREND

Pn

[Abb26: Kontrollfluß]

andere Schreibweise:

• [P0 || ... || Pn-1]

• [ || Pi] i ∈ {0,..., n-1}|| = "parallel ausgeführt"

6.2.1 Beispiel: Das Erzeuger-Verbraucher-ProblemDEF ARRAY: puffer;

PARBEGIN

erzeuger;

verbraucher;

PAREND

28

Aufgabe: Gegeben seien zwei Prozesse 'erzeuger' und 'verbraucher' und ein gemeinsamer 'puffer'. Der'verbraucher' soll dabei die Daten in der Reihenfolge aus dem 'puffer' entnehmen können, in der siedort vom 'erzeuger' abgelegt werden. Bsp.: Die PIPE in UNIX

Gesucht:

Programmschema, das das Erzeugen und Verbrauchen von Daten als unabhängige Teilaufgabenauffasst.

erzeuger:i := 0;

while (TRUE){

/*erzeuge Datum x */

puffer[i] = x;

i++;

}

verbraucher:j :=0;

while(TRUE){

y = puffer[j];

j++;

/* verbrauche Datum y */

}

Was kann bei dieser Methode schiefgehen, was ist nicht realistisch?• Entnahme von Daten, die noch nicht erzeugt wurden.• Puffer ist eine im Speicher unbeschränkte Datenstruktur

• unkontrollierte Zugriffe• unkontrolliertes Auseinanderlaufen der Prozesse

Verbesserungen:

• Einführung eines beschränkten (zyklischen) Puffers der Länge N:

puffer[i % N] = x y = puffer[j % N]

• Einführung einer Variablen b, die angibt, wie groß die Differenz zwischenb := # erzeugte Daten - # verbrauchte Daten ist.

• Beschränkung der Vorauslaufens von Prozess 'erzeuger' vor dem Prozess 'verbraucher'

natürlich: b ≥ 0 technisch: b ≤ N

29

[Abb27: belegt = b]

6.2.1.1 Invariante: Prädikat, das bei gewissen Schritten der Abarbeitung (paralleler) Programme gefüllt ist. (nach C.F.Meyer)Aus der Vorüberlegung (natürliche und technische) Beschränkungen von b:

I1 ≡ (0 ≤ b ≤N) immer gültigAus der Überlegung, dass ein erzeugtes Datum entweder bereits verbraucht ist oder noch im Pufferenthalten ist:

I2 ≡ (i = j + b) nicht immer gültig

Sei I = I1 ∧ I2

6.2.1.2 Bedeutung der Synchronisierung• aus dem Wort heraus: "Erzwingung von Gleichzeitigkeit" – Es gibt keine richtige Definition

hierfür

• aus der Anschauung: "Erzwingung einer Ordnung der Ausführung (von Anweisungen)" – eineFrage der Granularität, der Parallelität und Synchronisierung

• Korrektheit durch Synchronisierung: die erzwungene Ordnung bei der Ausführung parallelerProzesse garantiert die Gültigkeit der Invarianten.

Grundlegende Operationen bei der Synchronisierung

• ein Prozess verzögert sich selbst:erzeuger: b = N und 'erzeuger' will ein weiteres Datum in den Puffer stellen

verbraucher: b = 0 und der 'verbraucher' will ein weiteres Datum aus dem Puffer nehmen

• ein Prozess stößt einen anderen Prozess anerzeuger: b = 0 und der 'erzeuger' stellt ein Datum in den Puffer

verbraucher: b = N und der 'verbraucher' entnimmt ein Datum aus dem Puffer

→ Synchronisierung bzgl I1 ist nur bei b = N oder b = 0 notwendig

6.2.1.3 Betrachtung der Invarianten I2 des Erzeuger-Verbraucher-Problems (Mittel zurEinführung kritischer Gebiete)

1. Problem: Überlappung der Operationen b++ und b-- (mikroskopisch)

30

[Abb28: Überlappung]2. Problem: Gültigkeitsbereich der Invarianten I2

[Abb29: Gültigkeitsbereich I2]kritische Gebiete:

• Programmabschnitte unterschiedlicher Prozesse, in denen sich zu einem Zeitpunkt nurhöchstens ein Prozess aufhalten darf.

[Abb30: Hier ging verloren, dass b-- auch stattgefunden hat]• Aufgabe von Synchronisierungsoperationen, kritische Gebiete zu erzeugen

[Abb31: Kritische Gebiete beim Erzeuger-Verbraucher-Problem]

31

1) Inkonsistenz bei der Ausführung von b++ und b-- → I2 wird zerstört2) nur außerhalb ist I2 erfüllt

3) Inkonsistenz bei [i % N] ≤ [j % N]4) Inkonsistenz bei mehreren Prozessen(-instanzen) vom Typ 'erzeuger'5) Inkonsistenz bei mehreren Prozessen(-instanzen) vom Typ 'verbraucher'

Parallelität

• Bsp.: Puffer

• Erzeuger• Verbraucher

• Invarianten

• Gedankenstütze• Spezifikation• Verifikation

• I1 ≡ 0 ≤ b ≤ N• I2 ≡ i = j + b• kritische Gebiete: b++, b--

Synchronisierung• Zielsetzung: Einhaltung der Invarianten

• Operative Eingriffe durch die Synchronisierung • ausstoßen von anderen Prozessen• verzögern von Prozessen (von sich selbst)

6.3 Entwurf und Verifikation paralleler Prozesse Zielsetzung:

Auf der Grundlage handhabbarer und wohlverstandener Synchronisierungsoperationen sollenkorrekte (z.B. Invariante) parallele Programme entwickelt werden.

Abstraktion:

Atomare Anweisungen

Zielsetzung: Realisierung von Zustandsübergängen nur durch atomare Anweisungen

Ideal:

Terminierende Anweisung A

32

• wird zum selben Zeitpunkt begonnen und beendet • zum selben Zeitpunkt findet keine weitere Anweisung statt

Real: Eine Anweisung A heißt atomar, wenn ihre Wirkung vom Ideal nicht zu unterscheiden ist.

• unteilbare Operationen auf Variablen: <A>

z.B. <b-->; Anweisung wird nicht unterbrochen, bis nicht alle Zustände abgearbeitet sind• Zwischenzustände sind nicht mehr sichtbar• andere atomare Anweisungen finden entweder vor oder nach A statt

6.3.1 Parallelausführung von Anweisungen (und Abbildung in atomareAnweisungen)Bsp.: P1 berechnet den Ausdruck e(y)

P2 ändert y

[Abb32: Zeitdiagramm für P1 und P2]

[Abb33: Abstraktion in atomare Anweisung]

6.3.2 Parallele Ausführung von Anweisungen, die sich nicht in atomareAusführungen übersetzen lassenBsp.: P1 berechnet den Ausdruck e(x,y)

P2 verändert erst x, dann y

[Abb34: Zeitdiagramm für P1 und P2]

33

Bsp.: P1 :: z = x+yP2 :: x:=1; y:=2

6.3.3 Formale Beschreibung der Bedeutung von Programmen (Semantik) angewandtauf parallele Anweisungen{P} A {Q} Hoare-Formeln

P: Vorbedingung pre(A)

A: AnweisungsfolgeQ: Nachbedingung post(A)

"Wenn die Variablenwerte vor Ausführung von A die Bedingung P erfüllen und P terminiert, dannerfüllen die Variablenwerte nach Ausführung von A die Bedingung Q."

Beispiel: {P xe} x := e {P} ("Ersetze jedes freie Vorkommnis von x durch e")

6.3.3.1 Spezifikation der ParallelanweisungBsp. Unabhängige Anweisungen

P xe = P =

{x=X} x := x + 2; {x=X+2} {x=X} → {x+2 = X+2} = {P xe}

{y=Y} y := y + 3; {y=Y+3}natürliche Erweiterung:=> {P} A {Q}

{x=X ∧ y=Y} [x:=x+2; || y:=y+3] {x=X+2 ∧ y=Y+3}

Bsp.: Abhängige Anweisungen

{x=0 ∧ y=0 ∧ z=Z} z = x + y; {x=0 ∧ y=0 ∧ z=0}

{x=0 ∧ y=0} x := 1; y := 2; {x=1 ∧ y=2}natürliche Erweiterung nicht möglich, führt zu Fehler:

{x=0 ∧ y=0 ∧ z=Z} [z:=x+y; || x:=1; y:=2] {x=0 ∧ y=0 ∧ x=1 ∧ y=1 ∧ z=0}

6.3.3.2 Unabhängigkeitsregel• dient zur Prüfung, ob eine ausführbare (atomare) Anweisung

{pre(A)} A {post(A)}

im Kontext eines Prädikates P unbeeinflusst ist.

UR(P,A) = {P ∧ pre(A)} A {P}

34

Definition: Zwei Anweisungen A1 und A2 heißen unabhängig voneinander (Voraussetzung: {P1}A1{Q1} und{P2}A2{Q2}), wenn gilt

UR(P2,A1) ∧ UR(Q2,A1) ∧ UR(P1,A2) ∧ UR(Q1,A2)

Bsp.: Nachweis von Abhängigkeiten mit Hilfe der Unabhängigkeitsregel

Gegeben:{z=Z} z := x+y; {z= x+y}

{x=0} x := 1; {x=y}Es ist zu prüfen, ob folgend eine Hoare-Aussage ist.

UR({z=x+y}, x:=1;) =

{z=y}= {z=x+y ∧ x=0} x := 1 {z=x+y}

R xe = {z=y+1} x := 1 {z=x+y} = R stehen im Widerspruch zueinander!

→ keine Hoare-Aussage

6.3.3.3 Handout "at-most-once", Parallelanweisung, URFormen von atomaren Anweisungen:

• Unmittelbare Atomarität beim lesenden und schreibenden Zugriff auf den Hauptspeicher

• Die "at-most-once"-Eigenschaft für Ausdrücke e und Zuweisungen x=e;. Diese Eigenschaftist erfüllt, wenn eine der folgenden Bedingungen zutrifft:

1. Auswertung eines Ausdrucks e, der höchstens eine Variable y enthält, die ein andererProzess während der Ausdrucksauswertung verändern kann. Bei dieser Auswertung darfy höchstens einmal gelesen werden.

2. Ausführung der Zuweisung x=e;, wobei x währenddessen von keinem anderen Prozessgelesen wird und für e die Bedingung (1) gilt.

3. Ausführung der Zuweisung x=e;, wobei e keine Variable enthält, die von anderenProzessen verändert wird.

• Die Anweisungsfolgen A, die so geklammert sind: <A>.

Regel für die parallele Programmierung:Spezifikation der Parallelanweisung:

{Pi}Ai {Qi},0≤ i≤ N ­1, seien unabhängige Aussagen

{P0∧...∧P N ­1}[ A0∥...∥AN ­1]{Q0∧...∧QN ­1}

Unabhängigkeitsregel:

UR(P,A) = {P ∧ pre(A)} <A> {P}

Spezifikation von Synchronisierung:

{P∧B}A{Q}

{P}⟨await B A⟩ {Q}

35

6.3.3.4 SchwächungFrage:

Wie kann die Regel zur Parallelanweisung dennoch auf abhängige parallele Anweisungenangewendet werden?Lösung:Schwächung der Aussage

Beispiel:[<z = x+y;> || <x:=1;><y:=2;>]

P1 ≡ {z = Z ∧ ((x=0 ∧ y=0) ∨ (x=1 ∧ y=0) ∨ (x=1 ∧ y=2))}

<z = x+y>

Q1 ≡ {(z=0 ∨ z=1 ∨ z=3) ∧ ((x=0 ∧ y=0) ∨ (x=1 ∧ y=0) ∨ (x=1 ∧ y=2))}

P2 ≡ {z = Z ∨ z=0) ∧ (x=0 ∧ y=0)}

<x:=1;><y:=2;>

Q2 ≡ {z = Z ∨ z=0 ∨ z=1 ∨ z=3) ∧ (x=1 ∧ y=2)}

Hierauf ist die Regel der Parallelanweisung anwendbar. Warum geht das?→ Prüfung aller Unabhängigkeitsregeln:

UR(P2,A1) ∧ UR(Q2,A1) ∧ UR(P1,A2) ∧ UR(Q1,A2)

z.B.: UR({P1}, <x:=1;><y:=2;>) ≡ {P1 ∧ pre(<x:=1><y:=2>)}<x:=1><y:=2> {P1}

muss gültige Hoare-Aussage sein

P1 ≡ {z=Z ∧ ((x=0 ∧ y=0) ∨ (x=1 ∧ y=0) ∨ (x=1 ∧ y=2)) ∧ (z=Z ∨ z=0) ∧ (x=0 ∧ y=0)}

<x:=1><y:=2>

P1 ≡ {z=Z ∧ ((x=0 ∧ y=0) ∨ (x=1 ∧ y=0) ∨ (x=1 ∧ y=2))}

fällt weg wegen Konsequenzregel

P' ≡ (x=0 ∧ y=0 ∧ z=Z)<x=1;><y=2;>

Q' ≡ (x=1 ∧ y=2 ∧ z=Z)

Konsequenzregel:

P ' ⇒ P ,{P}A{Q},Q ⇒Q '

{P ' }A{Q ' } P ≡ P' Q' ≡ Q

36

Resultat:

P1 ∧ P2 ≡ {z=Z ∧ (x=0 ∧ y=0)}

[<z:=x+y;> || <x:=1><y:=2>]

Q1 ∧ Q2 ≡ {(z=0 ∨ z=1 ∨ z=3) ∧ (x=1 ∧ y=2)}

6.3.4 Konstrukt für die Synchronisierung<await B → A;>A: terminierende Anweisung

B: boolscher AusdruckBedeutung:Die Ausführung der Anweisung A wird so lange verzögert, bis Bedingung B erfüllt ist. Aufgrundder Atomarität gilt immer, dass zu Beginn der Ausführung von A B erfüllt ist!

{P∧B}A{Q}

{P}⟨await B A⟩ {Q}

Bsp.: Synchronisierung des Erzeuger/Verbraucher-Problemse:: while(true){ v:: while(true){

/* Info x erzeugen */ <await b > 0 →

<await b < N → y = puffer[j];

puffer[i] = x; b--;

b++; j = (j+1)%N;>

i = (i+1)%N> /* Info y verbraucht */

} }

Wieviel Parallelität wollen wir erlauben?Grundsätzliches Problem:

• je feiner die Granularität

• um so komplexer werden die Programme• um so schwieriger die Korrektheitsbeweise

• je grober die Granularität

• mögliche Parallelität wird nicht genutzt

• "sicherere" parallele Programme

6.3.4.1 Spezifikation des gegenseitigen Ausschlusses• gegenseitiger Ausschluss erzeugt kritische Gebiete

[P0 || ... || Pn-1]# define drinnen 1 /* Prozess ist in krit. Gebiet */

# define draußen 0 /* Prozess ist nicht in krit. Gebiet */

37

common int p[n] /* Initialwert 0 also draußen */

Pi:: while(true) {

/* außerhalb des kritischen Gebietes */

p[i]=drinnen; /* Betreten des k.G. */

/* innerhalb des k. G.; endlicher Aufenthalt! */

p[i]=draußen; /* Verlassen des k.G. */

}

Was muss im kritischen Gebiet gelten?

MUTEX = ∑i=0

n­1

p[i ]≤1 (MUTEX = Mutual Exclusion)

Frage:Was muss gelten, um ein kritisches Gebiet zu betreten?

wp(p[i]=drinnen; , MUTEX) ≡ p[0] + .... p[i-1] + 1 + p[i+1].... p[n-1] ≤ 1 → ∑j=0, j !=i

n­1

p [ j ]=0

wp = weakest preconditionsomit (Hoare-Formel):

{MUTEX ∧ ∏0≤ j≤n­1

¬P [ j ]} p[i]=drinnen; {MUTEX}

Was muss beim Verlassen des krit. Gebietes gelten, damit MUTEX weiterhin gültig ist?

{MUTEX ∧ p[i]=1} p[i] = draußen {MUTEX} (1 = drinnen → keine Vorbedingung)

6.3.4.2 Programm für den gegenseitigen Ausschluss mit <await....>Pi ::

/* p[i]=0 ∧ MUTEX */

while(true){

/* außerhalb */

<await p[0] + .... + p[n-1] = 0 → p[i] = 1> ←Synchronisierung nur hier notwendig!

/*innerhalb ∧ MUTEX */

p[i]=0;

/*p[i] = 0 ∧ MUTEX */

38

Vereinfachung:Ersetzen des Arrays p[0,.., n-1] gegen eine einzige Variable mutex:

mutex = 1­∑i=1

n

p [i ]

Betreten: <await mutex == 1 → mutex = 0;>Verlassen: mutex = 1;

6.4 Eigenschaften von parallelen Programmen• Sicherheit (safety):

Für jede mögliche Ausführung eines parallelen Programms gilt, dass nur "günstige"(sichere) Zustände angenommen werden. "günstig" = Inhalt der Invarianten

• Lebendigkeit (liveness):

• Für mögliche Ausführungen eines parallelen Programmes gilt, dass schließlich(eventually != eventuell) ein beabsichtigter Zustand angenommen wird (z.B.: Der Zustandder Termination)

• Zum Teil auch als "starvation-free" bezeichnet

• Begrifflichkeit (temporale Logik)• □P P gilt in jedem Zustand des Systems ("always")

• ◊LP In jedem Fall wird es einen Zustand geben, zu dem P wiederum gilt ("eventually" → schließlich). L steht für "linear" → Zustand soll in linearer Zeit erreicht werden

• ◊BP Es gibt einen Zustand in der Zukunft, zu dem P erfüllt wird ("possibly")• Fairness:

Aussage darüber, wie schnell die Berechnung eines Prozesses gegenüber anderen fortschreitet.

Fallbetrachtung:Ist die Berechnung eines Prozesses an einer Synchronisierungsoperation angelangt, dann ergibt sichdie Frage, wann diese ausgeführt wird.

Bsp.: P1:: .... P2:: ....

stetiger Fortschritt, A1; <await B → A2> conditional Fairnessder garantiert sein .... .... Ziel: Aussage über densollte Fortschritt der Ber.

Fairness: Für <await B → A> heißt ein Scheduling-Verfahren

• schwach fair, wenn schließlich die Anweisung A ausgeführt wird unter der Voraussetzung, dassB ab einem Berechnungsschritt ununterbrochen erfüllt ist.

39

• stark fair, wenn schließlich die Anweisung A ausgeführt wird unter der Voraussetzung, dass B abeinem Berechnungsschritt unbegrenzt oft erfüllt ist.

6.4.1 Handout Beispiele zur FairnessBsp.: Fairnessbetrachtung beim gegenseitigen Ausschluss mit Hilfe der Variablen mutex.#define draussen 0

#define drinnen 1

common int mutex = 1;

P[i]:: while(TRUE){

/* außerhalb des krit.Gebietes */

<await mutex == 1 → mutex = 0;>

/* endlicher Aufenthalt im krit. Geb. */

<mutex = 1;>

}

Für einen Prozess, der das kritische Gebiet betreten will, ist die Bedingung mutex == 1 immerwieder kurzfristig erfüllt, und zwar sobald ein Prozess das krit. Gebiet verlässt. Das kannunbegrenzt oft der Fall sein, so dass ein stark faires Scheduling-Verfahren sicherstellt, dassschließlich jeder Prozess, der ins krit. Gebiet will, auch hineingelangt.

Bsp.: Unterschiede zwischen schwacher und starker Fairness anhand folgenderProgramme:x=0; ende=FALSE;

[P1 || P2]

Mit

P1:: <await x>0 → ende=TRUE;>

undP2:: while(!ende) <x=x+1>

Hier genügt schwache Fairness, um eine Termination des Programms und damit die Realisierungeines Zufallszahlengenerators zu erhalten.

Sei hingegen

P1:: <await prim(x) → ende=TRUE;>

wobei prim(x) genau für Primzahlen x den Wert TRUE liefert. Jetzt lässt sich mit der schwachenFairness die Termination des Programms nicht mehr sicherstellen; wohl aber mit der starkenFairness. Dann da es unendlich viele Primzahlen gibt, ist prim(x) unbegrenzt oft erfüllt, so dassschließlich die Anweisung ende=TRUE; ausgeführt wird.

Frage:

Realisierbarkeit von <await B → A>1. Grundsätzliche Realisierbarkeit der Bedingungs- und Anweisungsausführung im krit. Gebiet.

→ "geht" siehe Punkt 6.5

40

2. Notwendigkeit einer a) ständigen Überprüfung: "busy waiting", sehr aufwendig.

b) gezielten Überprüfung: Forschungsaufgabe

6.5 Elementare SynchronisierungsmethodenFrage:Auf welche Grundoperation(en) lassen sich die Synchronisierung bzw. kritische Gebiete aufbauen?

Konkret:

Gegenseitiger Ausschluss von zwei Prozessen.Anwendungsfelder:

• Einprozessorsysteme:Zwei Prozesse, die auf gemeinsame Daten zugreifen.

• Mehrprozessorsysteme

Zwei/mehrere Prozessoren, die gleichzeitig auf einem Speicher arbeiten

Gegenseitiger Ausschluss und wiedereintrittsfeste (reentrant) Programmabschnitte im Kern(Kontrollfluss im Kern)

[Abb35: Kernzugriffe mit Gefahr auf krit. Gebiete]

Ziel:Erzeugung von Atomarität mit minimalen Mitteln.

41

Möglicher Ansatz (für Ein- und Mehrprozessor):• Lesen aus dem Speicher in ein Register

• Schreiben eines Registers in den Speicher

Lösungsschema:

Common Datenbereiche

Pi:: private Daten

betreten/* krit. Gebiet */

verlassen

6.5.1 Gütekriterien für eine Lösung 1. Korrektheit: Nur ein Prozess darf zu einem Zeitpunkt im kritischen Gebiet sein. 2. Es gibt keine äußeren Einflüsse auf das Betreten und Verlassen eines krit. Gebietes.

3. Ein einzelner Prozess, der das krit. Gebiet betreten will, soll auch schließlich hinein gelangen.4. Wollen mehrere Prozesse ins krit. Gebiet, so soll schließlich einer (jeder?) hinein gelangen

(einer: Lebendigkeit; jeder: starvation-free)

5. Die Ausführungszeiten der parallelen Prozesse untereinander sollen keinen Einfluss auf 1-4haben

6.5.2 Dekker'sche Lösungen (1966) zum gegenseitigen Ausschluss Absichten:

• prinzipielle Realisierbarkeit des gegenseitigen Ausschlusses bei atomarem Lesen bzw.Schreiben.

• Mit welchen (immer wieder auftretenden) Problemen hat man zu tun?

• → Regeln für Lösungen

6.5.2.1 1. Dekker'sche Lösung common

marke = 1;

P1: P2:

while(marke!=1); while(marke!"2);

/* kritisches Gebiet */

marke=2; marke=1;

42

1. Gütekriterium: Erfüllt.2. Gütekriterium: Verletzt

3. Gütekriterium: Verletzt

6.5.2.2 Handout 2.-4. Dekker'sche Lösung 2. Dekker'sche Lösung#define auf 0

#define zu 1

common int eingang = auf; /* Initialisierung */

P1:: P2::

while(eingang == zu); while(eingang == zu);

eingang = zu; eingang = zu;

/* kritisches Gebiet */ /* kritisches Gebiet */

eingang = auf; eingang = auf;

Wertung:

Es kann mehr als ein Prozess im kritischen Gebiet sein. Damit ist die entscheidenste Forderung 1verletzt.

[Abb36: Zeitdiagramm 2. Dekker'sche Lösung]

Die Variable eingang ist nur über den gemeinsamen Bus zugreifbar, d.h. zu einem Zeitpunkt kannnur entweder P1 oder P2 lesend oder schreibend auf eingang zugreifen. (Für P1 und P2 gebendie Ziffern im Zeitdiagramm die Zeilen an, die gerade ausgeführt werden. Kommentarzeilenwerden nicht mitgezählt.)

3. Dekker'sche Lösungen#define drinnen 1

#define draussen 0

common int p1 = draussen; /* Initialisierung */

common int p2 = draussen;

P1:: p1 = drinnen; P2:: p2 = drinnen;

while(p2 == drinnen); while(p1 == drinnen);

/* kritisches Gebiet */ /* kritisches Gebiet */

p1 = draussen; p2 = draussen;

43

Wertung:

Es kann dazu kommen, dass P1 wegen p2 == drinnen und P2 wegen p1 == drinnen endlosaufeinander warten. Damit liegt ein Deadlock vor, womit insbesondere die Forderung 4 verletzt ist.

[Abb37: Zeitdiagramm 3. Dekker'sche Lösung]

4. Dekker'sche Lösung#define drinnen 1

#define draussen 0

common int p1 = draussen; /* Initialisierung */

common int p2 = draussen;

P1:: do P2:: do

{p1 = drinnen; {p2 = drinnen;

if (p2 == drinnen) if (p1 == drinnen)

p1 = draussen; p2 = draussen;

while(p2 == drinnen); while (p1 == drinnen);

} }

while(p1 == draussen); while(p2 == draussen);

/* kritisches Gebiet */ /* kritisches Gebiet */

p1 = draussen; p2 = draussen;

Wertung:

Aufgrund der absoluten Symmetrie zwischen P1 und P2 ist es prinzipiell möglich, dass sich beideProzesse immer wieder in der selben Zeile aufhalten, wobei immer dann, wenn ein Prozess auf p1zugreift, der andere in der selben Zeit auf p2 zugreift. In diesem Falle erkennt der Prozess, dassder andere auch gerade ins kritische Gebiet möchte und zieht sich zurück ("absolut defensivesVerhalten"). Diese Ausführungsfolge läßt sich beliebig lange fortsetzen und führt dazu, dieProzesse beliebig lange vom Betreten des kritischen Gebietes abzuhalten.

Diese Situation heißt Livelock und widerspricht der 4. Forderung. Dass die oben konstruierteAnweisungsfolge sich tatsächlich ergibt, ist unwahrscheinlich und es genügt bereits, dass einProzess ohne vom anderen ununterbrochen zu werden, die Zeilen 3 und 4 ausführt.

44

5. Dekker'sche Lösungen#define drinnen 1

#define draussen 0

common int marke = 1; /* Initialisierung */

common int p1 = draussen;

common int p2 = draussen;

P1:: p1 = drinnen; P2:: p2 = drinnen;

if (p2 == drinnen); if (p1 == drinnen)

{if (marke == 2); {if (marke == 1)

{p1 = draussen; {p2 = draussen;

while(marke == 2); while(marke == 1);

p1 = drinnen; } p2 = drinnen; }

while(p2 == drinnen);} while(p1 == drinnen);}

/* kritisches Gebiet */ /*kritisches Gebiet */

marke = 2; marke = 1;

p1 = draussen; p2 = draussen;

Wertung:

Im Gegensatz zur vorangegangenen Lösung ist nun der Livelock verbannt. Mittels der Variablemarke wird eine Asymmetrie im Verhalten der Prozesse P1 und P2 für den Fall erzwungen, dasssie gleichzeitig in das kritische Gebiet wollen. Ähnlich wie bei der ersten Lösung wird dann imWechsel einer der beiden Prozesse bevorzugt.

6.5.2.3 Lösungen nach Peterson#define drinnen = 1

#define draussen = 0

common int marke;

common int p1, p2;

P1:: P2::

(1a)

p1 := drinnen; p2 := drinnen;

(1b)

marke = 1; marke := 2;

(1c)

while(marke == 1 && while(marke == 2 && p1 == drinnen);

p2 == drinnen);

(1d)

p1 = draussen; p2 := draussen

45

Betrachtung möglicher Zustandsübergänge (p1, p2, marke) → 8 Zustände2a 2b 2c 2d 2e

1a(0,0,?) (0,1,?) (0,1,2) (0,1,2) (0,0,2)

1b (1,0,?) (1,1,?) (1,1,2) (1,1,2) (1,0,2)

1c (1,0,1) (1,1,1) (1,1,1)

(1,1,2) (1,1,1)

(1,0,1)

1d (1,0,1) (1,1,1) (1,1,2) krit. Gebiet (1,0,1)

1e(0,0,1) (0,1,1) (0,1,2) (0,1,2) (0,0,?)

6.5.3 Bedeutung der Lösungen nach Dekker u. Peterson• anwendbar auf Ein- und Mehrprozessorsysteme

• Aufwand: 3 Variablen bei 2 Prozessen

• Erweiterung auf mehrere Prozesse • → kaskadieren

• eher akademisch

• Symmetrie bei parallelen Programmen ist eine Aussage darüber, wie sehr sich dieBerechnungen einzelner Prozesse unterscheiden. → 5. Dekker'sche Lösung beruht aufBrechen der Symmetrie

• Peterson-Lösung:• kleines Programm, viele Möglichkeiten• Sperren von Interrupts

• test_and_set

Frage:

Wie können bessere (elementare) Lösungen aussehen?

→ Mit Hilfe erweiteter Hardware-Befehle

46

Erzwingung des gegenseitigen Ausschlusses bei Einprozessorsystemen durch Sperren vonInterrupts.

Pi:: ......DI /* disable interrupts */

krit. Gebiet EI /* enable interrupts */...

Lösung wird angewandt z.B. beim Implementieren von Semaphoroperationen (wie Systemaufruf)Nachteile:

• Nur im privilegierten Modus

• Beschränkt auf Einprozessorsysteme• kategorische Lösung

6.5.4 Synchronisierung mit Hilfe mächtiger MaschinenbefehleSpezieller Befehl: test_and_set

ts(x,y) = x,y vom Typ boolean< kopiere y auf x;

setze y auf den Wert FALSE;>

Frage:Wie lässt sich damit synchronisieren?Hinweis: 2. Dekker'sche Lösung

6.5.4.1 Betreten und Verlassen eines krit. Gebietes mit dem ts(x,y)-Befehlcommon int y = TRUE;

Pi:: int xi = 0; /* privat*/ i ∈ ℵ

Betreten do

ts(xi, y)

while (!xi); /* xi := TRUE */

typische busy-waiting-Struktur (spin lock)→ nur sinnvoll für kurze krit. Gebiete

→ geeignet für Mehrprozessorsysteme /* krit. Gebiet */

Verlassen y := TRUE;

47

6.5.4.2 test_and_set unter LinuxFunktion test_and_set(nr,addr)

*addr nr

• atomar:

• gibt Bitwert zurück• setze Bit auf 1

• Spin-Locks (auch bezogen auf Linux)

• Zur Synchronisierung der Kernel-Threads• Technik bei Mehrprozessor-Architekturen für den gegenseitigen Ausschluss

[Abb38: Gleichzeitiges Arbeiten mehrerer Prozesse]

Lösung unter Linux und Pentirum IVspin_lock:: 1: lock; decb slp

jns 3f

2: cmpb $0, slp pause

jle 2b

jmp 1bspin_unlock:: lock; movb $1, slp

atomar

jump not set → slp =0

jump less equal → slp ≤ 0

f, b heißt: Sprünge forward/backward spin_lock: "Betreten", spin_unlock: "Verlassen"

48

< >

6.6 Semaphore• Dijkstra 1968• Datenstruktur S, natürliche Zahl

• Operationen• P(s)• V(s)

• Init(s)

[Abb39: Laufzeitmodell: Prozessverwaltung]

6.6.1 Semantik der Semaphoroperationen• P(s) = <await s > 0 → s := s-1>

• Prädikatenkalkül:

{P∧s0}s=s­1{Q}{P}P s{Q}

{P∧s0∧Q ss­1

}

{P}P s{Q}

• V(s) = <s = s+ 1>

{P ⇒Q ss­1

}

{P}V s{Q}

{Q ss­1} <s = s+1> {Q} nur, wenn kein anderer Prozess aktiv ist.

Bsp.: Bewahrung der Invarianten

I ≡ i = j+bAnnahme:

S initialisiert mit 1e:: while(true) { v:: while(true) {

P(s) P(s)

i++; j++;

b++; b--;

V(s) V(s)

} }

49

6.6.2 Lösung des Erzeuger-Verbraucher-ProblemsIdee: Ausnutzung der Zähleigenschaft von Semaphoren

Verzögerungsbedingung:

b > N → N – b < 0 zuvor ist der Erzeuger zu verzögern b < 0 zuvor ist der Verbraucher zu verzögern

Wie kann man verzögern?

P(s) verzögert, wenn s ≤ 0

6.6.2.1 Handout E-V-Problem mit SemaphorenDie Prozesse e() und v() aufgrund der Entwicklung:

Erzeuger: Verbraucher:e() v()

{while(TRUE) {while(TRUE)

{/*erzeuge ein Datum x*/ {

P(frei); P(belegt);

/*frei≥0 && belegt<N*/ /*belegt≥0 && frei<N*/ puffer[i%N] = x; y = puffer[j%N];

i++; j++;

V(belegt); V(frei);

/* frei≥0 && belegt≤N */ /*belegt≥0 && frei≤N*/ /*verbrauche ein Datum y*/

} }

} }

6.6.3 Implementierung von Semaphoroperationen via Systemaufruf• Prozessverwaltung• warte_auf(s) → einreihen des Prozesses in eine Schlange "verzögert wegen s". Stattdessen

darf ein anderer rechenbereiter Prozess rechnen

• wecke(s) → Aus der Schlange "verzögert wegen s" kann ein! Prozess in den Zustandrechenbereit wechseln

[Abb40: Prozessverwaltung mit wecke(s) und warte_auf(s)]

50

Implementierung von SemaphoroperationenP(semaphor s) { V(semaphor s) {

< s--; < s++;

if (s<0) warte_auf(s) if (s≤0) wecke(s)

> >

} }

(bei s <0 entspricht -s der Anzahl der Prozesse in der Schlange)

6.7 Paradigmen der parallelen Programmierung• Musterbeispiel

• Art zu denken• Art, Probleme zu lösen• Erarbeiten von Lösungselementen

• Vertrautheit unter Fachleuten

Paradigmen

• bislang:• gegenseitiger Ausschluss • Erzeuger/Verbraucher

• weitere:• Leser-Schreiber-Problem• Fünf-Philosophen-Problem

• Rollercoaster-Problem

• Cache-Kohärenz-Problem• Barrier-Problem

6.7.1 Leser-Schreiber-ProblemEs geht um lesenden und schreibenden Zugriff auf einen Datenbestand.Konflikte:

P1\P2 l sl - +s + +

Abstrakte Operationen:

• lies(D, &y)• schreib(D,x)

51

1. LösungInit(sD,1)

schreib(D,x) { lies(D, &y) {

P(sD) P(sD)

D=x; y=D;

V(sD) V(sD)

} }

Verbietet mehr Parallelität wie möglich, ist aber korrekt → einfache Lösung dank groberVorgehensweise.

Vorbereitung einer verbesserten Lösung beschreibende Größen:

• anzleserDAnzahl der Prozesse (Leser), die gerade am Datenbestand lesend arbeiten

• anzschreiberD

Anzahl der Prozesse (Schreiber), die gerade am Datenbestand schreibend arbeitenZustände:

• F

D ist frei ≡ anzleserD = 0 ∧ anzschreiberD = 0• L

D wird lesend benutzt ≡ anzleserD > 0 ∧ anzschreiberD = 0

• S

D im schreibenden Zugriff ≡ anzleserD = 0 ∧ anzschreiberD = 1Beachte:

• Im Zustand L kann es mehrere wartende Schreiber geben (vielleicht nicht pragmatisch)

• Im Zustand S kann es mehrere wartende Leser und Schreiber geben

Abarbeitung von abstrakten Operationen (lies, schreib) in Form eines Protokollsschreib(D,x) { lies(D,y) {

anf_schreib(D) anf_lies(D)

/* S */ /* L */

D=x; y=D;

ende_schreib(D) ende_lies(D)

} }

Außerhalb von anf_schreib/lies und end_schreib/lies können alle Zustände gelten, also F, L oder S.

52

2. Lösung: Leserseite• Der erste Leser soll den Schreibern den Zugang zu D verwehren → Semaphor sD

• Leser untereinander sind mit Semaphor mutexD voreinander zu schützen (Init(mutexD,1)) →soll verhindern, dass mehrere Leser gleichzeitig anzleserD abfragen und somit alle als "erster"Leser Zugang zu D haben

anf_lies(D) { ende_lies(D) {

P(mutexD) P(mutexD)

if (anzleserD==0) anzleserD--;

/* F ∨ S */ if (anzleserD==0)

P(sD); /* F */

/* L */ V(sD)

anzleserD++; V(mutexD)

V(mutexD)

} }

Bedeutung der Semaphore sD• Init(sD,1)

erster Leser soll allen folgenden Schreibern den Zugang verwehren → • ein Schreiber soll folgenden Lesern und Schreibern den Zugang verwehren

I ≡ sD = 1 ⇒ F <=> L ∨ S ⇒ sD = 0

Folgerungen:• wenn P(sD) zu Ende ausgeführt wird, muss gelten:

{I ∧ sD = 1} P(sD) {I}(vorher muss F gelten)

• wenn V(sD) ausgeführt wird, muss F gelten

{I ∧ F} V(sD) {I}

2. Lösung: Schreiberseiteanf_schreib(D) { ende_schreib(D) {

P(sD); /*sD=1*/ /* S */

anzschreiberD++; anzschreiberD--; /*F*/

/* S */ V(sD)

} }

Eigentlich ist anzschreiberD nicht nötig

53

Diskussion der 2. Lösung • Deadlock

• Livelock• Fairness

Wo kann ein Deadlock überhaupt entstehen?

• bei P(mutexD), weil ein anderer Prozess bei P(sD) verzögert wurde.• P(sD) ist immer ein "Wartepunkt", wenn ein Deadlock existiert.

Angenommen:

Es gibt eine Prozessmenge D ⊆ P (nicht zu verwechseln mit Datenbestand D), die im Deadlocksteckt, davon ein Prozess bei P(sD) in anf_lies(D)

Wenn p im Deadlock ist, wird die zugehörige Operation V(sD) nie mehr ausgeführt

• gilt für die Leserseite

• Verursacher von sD=0 ist der Schreiber. Dieser wird schließlich V(sD) ausführen.

→ Es gibt die Möglichkeit auf V(sD) geweckt zu werden → Widerspruch zur Annahme, dasseine Deadlock-Menge existiert.

Livelock

• mikroskopisch: ein Prozess arbeitet

• makroskopisch: er kommt nicht (echt) vorwärts

Beispiel Livelock bei der 2. Lösung des Leser-Schreiber-Problems:Problem: V(sD) stößt zwar Leser und Schreiber an, wird jedoch im Zustand L nur aufgerufen, wenngilt: anzleserD == 0

[Abb41: Zeitdiagramm]

6.7.1.1 Fairness bei SemaphoroperationenProzess p wird in P(s) verzögert. Wann wird er wieder geweckt: Durch V(s) wird nicht festgelegt,welcher wartende Prozess geweckt wird.

54

• ein wartender Prozess ist uneingeschränkt weckbereit→ es genügt damit ein schwach fairer Scheduler

• z.B. FIFO• <await B → A> nur unter Gültigkeit von B weckbereit

6.7.2 Das Fünf-Philosophen-Problem• "akademisch"

• Ursprung: Dijkstra 1968• bildhaft (jeder Informatiker kennt es)• Andwendbarkeit:

• parallele Programmierung• verteilte Programmierung

[Abb42: Problemskizze]5 Philosophen sitzen um einen Tisch herum, auf dem ein Topf Spaghetti steht. Jeder hat eine Gabelvor sich.

Regel: Ein Philosoph kann nur essen, wenn er im Besitz der jeweils linken und rechten Gabel ist.Rahmen für die Lösung des 5-Ph.-Problems:#define N 5

common semaphor gabel[N]={1,..,1}

..

Phi:: while(TRUE){

/*ein Ph. denkt*/

will_essen(i);

/*Ph. isst*/

will_denken(i);

}

55

Symmetrische Lösung:will_essen(i) {

P (gabel[i]);

P (gabel[i+1] MOD N]); /*Besitzer von zwei Gabeln → Korrektheit*/

}

will_denken(i) {

V (gabel[(i+1) MOD N]);

V (gabel[i]);

}

Frage:Ist diese Lösung Deadlockfrei?

Nein; z.B. jeder Philosoph belegt seine eigene Gabel und versucht, die seines Nachbarn zubekommen.Alle Prozesse können voranschreiten bis P(gabel[i]).

Was ist zu tun? → Brechen der Symmetrie!

6.8 Monitore (Hoare, 1974)• Grundgedanke:

• Synchronisierungsoperationen mit syntaktischer Einbindung → Compiler soll in der Lagesein, Plausibilitäten zu prüfen.

• Monitor: Abtraktionsobjetk für

• gekapselte Datenstruktur

• Menge von Operationen darauf (Zustandsübergänge)• Zielsetzung:

• strukturierte Programmentwicklung

• Synchronisierung paralleler Prozesse • Arbeitsweise:

• 1. Schritt: Definition einer Schnittstelle zwischen den Benutzern und den Entwicklerneines Monitors. → tragfähig für Objektorientierung

• 2. Schritt: • Entwicklung des Monitors

• Benutzung der Operationen des Monitors

6.8.1 Monitore und parallele Prozesse • Monitore: passiv

• parallele Prozesse: aktiv

56

[Abb43: Darstellung Monitore/Prozesse]

• Objektorientierte Merkmale:• Kapselung• Vererbung angewendet auf diese Kapseln

• Initialisierung, Löschung

Regel der Konsistenzerhaltung

• "In einem Monitor kann zu einem Zeitpunkt höchstens ein Prozess aktiv (rechnend undrechenbereit) sein."

6.8.2 Synchronisierungseigenschaften des Monitors• Betreten: Voraussetzung: kein anderer Prozess ist aktiv im Monitor, d.h. der Monitor ist

"offen". Andernfalls reiht sich dieser Prozess in eine Warteschlange "wartend auf Monitor(objekt) x" ein.

• Verlassen: Der Monitor ist wieder offen.

Beispiel: Erzeuger/Verbraucher mit Monitoren1. Schritt: Festlegung von Schnittstellen (Operationen, Methoden)

• in_puffer (IN y: info)• out_puffer (OUT z: info)

2. Schritt Benutzerseits:

• Erzeugung paralleler Prozesse • Erzeugung Monitor(objekt) x• Zugriff auf den Monitor mit x.in_puffer(y) oder x.out_puffer(z)

57

2. Schritt Entwicklerseits:• Implementierung des Monitors, insbesondere der (public)-Operationen

• Synchronisierungsproblematik bzgl Erzeuger/Verbraucher• Angenommen, ein Prozess i will mit der Operation x.out_puffer(z) eine Info aus dem

Puffer (Monitor) x entnehmen, dieser ist jedoch leer. → Es muss eine Möglichkeit geben,einen Prozess im Monitor zu verzögern (durch WAIT).

• Prozess ist nicht mehr aktiv → Monitor ist wieder offen• Angenommen, ein Prozess j hat mit der Operation x.in_puffer(y) eine Information in den

Puffer (Monitor) x abgelegt, der Monitor ist also nicht mehr leer. → Es soll eineMöglichkeit geben, einen im Monitor verzögerten Prozess anzustoßen (durch SIGNAL)• Der angestoßene Prozess wird anstelle des anstoßenden im Monitor aktiv (wohin

kommt der anstoßende Prozess?)

[Abb44: Diagramm]

• leer.WAIT:

condition-Variable; Schlange, in die man mit WAIT sich selbst (als Prozess) einreihen kann.Mit SIGNAL wird man aus dieser Schlange geweckt und fortgesetzt (rechnend).

• leer.SIGNAL:

eine Möglichkeit: Einreihen in eine Schlange von Prozessen die darauf wartet, dass derMonitor wieder offen wird.

58

6.8.2.1 Handout Implementationsteil des Moduls pufferMODULE puffer[1]

EXPORT in_puffer, aus_puffer;

IMPORT SIGNAL, END, WAIT, Init, infotyp;

CONST N = 1000 (* Puffergröße *)

VAR op: INTEGER; (* Aufrufe in_puffer – aus_puffer *)

voll, leer: SIGNAL;

i, j: INTEGER; (* Indizees in den Puffer *)

speicher_puffer: ARRAY[0..N-1] OF infotyp;

PROCEDURE in_puffer(x: infotyp)

BEGIN

op := op + 1;

IF op > N THEN WAIT(voll) END;

speicher_puffer[i MOD N] := x; (* b++ *)

i := i+1;

IF op =< 0 THEN SEND(leer) END;

END;

PROCEDURE aus_puffer(VAR y: infotyp);

BEGIN

op := op – 1;

IF op < 0 THEN WAIT(leer) END;

y := speicher_puffer[j MOD N]; (* b-- *)

j := j+1;

IF op >= N THEN SEND(voll) END;

END

BEGIN (* Initialisierung *)

op := 0;

i := 0;

j := 0;

Init(voll);

Init(leer);

END.

[Stimmt nicht mit Hoare überein; SIGNAL ist hier condition-Var., SEND ist SIGNAL von Hoare)

59

6.8.3 Zustandsmodell für Monitore• Monitorobjekt (Zustände)

• offen kein Prozess ist im Monitor aktiv, Schlange "wartend auf Monitor" ist leer

• belegt ein Prozess ist im Monitor • Prozesse (Zustände bezogen auf einen Monitor)

• aktiv rechnend, rechenbereit

• außerhalb/innerhalb des Monitors• passiv

• außerhalb

• "wartend auf Monitor" (beim Betreten)• "wartend auf condition-Variable s" (mit s.WAIT)

• "wartend auf Monitor" (bei Operation s.SIGNAL)

[Abb45: Zustandsdiagramm für Prozesse (bei einem speziellen Monitor)]

6.8.4 Entwurf und Verifikation von Programmen mit MonitorenEine boole'sche Bedingung I verkörpert eine Invariante des Monitors und damit dessen Bedeutung→ Gültigkeit: an allen Ein- und Austrittspunkten des Monitors

60

[Abb46: Monitor puffer]Prädikate, die bezogen auf den Monitor relevant sind:

• I: Monitorinvariante

• L: lokales Prädikat eines Prozesses, der im Monitor ist• B: Bedingung, damit ein im WAIT wartender Prozess fortfahren kann

Regeln:

{I ∧ L} WAIT(s) {I ∧ L ∧ B}

{F ∧ L ∧ B ∧ notempty(s)} SIGNAL(s) {I ∧ L}z.B. der Erzeuger findet die Situation vor, die der Verbraucher erkannt hat.

Invariante zum Erz.-Verbr.-Problem

I1 ≡ i=j+b

I = I2 = 0 ≤ b ≤ N bei der Initialisierung zu erzeugen

Bedingungen auf die gewartet wird:auf b<N wartet der Erzeuger mit WAIT(voll)

auf b>0 wartet der Verbraucher mit WAIT(leer)

Anstoß, wenn gilt b<N durch SIGNAL(voll)Anstoß, wenn gilt b>0 durch SIGNAL(leer)

61

Bedeutung der Var. opop<0 → -op = #Prozesse im Zustand "wartend auf leer"

op>N → op-N = #Prozesse im Zustand "wartend auf voll"

0 ≤ op ≤ N kein Prozess wartet b = op

Was ist bei der Verifikation zu tun?

Es ist zu überprüfen, ob die sequentielle Programmausführung zwischen Gültigkeitspunkten derInvarianten deren Gültigkeit erhält.

Sei: i=I, j=J, b=B, op=OPFall 1. (bez. auf Abb46):

• OP ≥ N• Monitorinvariante gilt beim Betreten• WAIT(voll) wird ausgeführt

op:= OP+1

• Warten auf b<N ≡ B (B von Bedingung, siehe oben bei „Prädikaten“)• Monitorinvariante bleibt erhalten

Fall 8.: "daraufhin"• OP > N

• Monitorinvariante gilt beim Betreten

• op:= OP-1j:= J+1

b:= B-1• Invariante ist wieder erfüllt, außerdem gilt b<N

• SIGNAL(voll)

7 Modellbildung und Analyse

7.1 EinführungDienstleistende Systeme ("Investition")

• Aufträge (von Kunden)

• Bedieneinheiten (Betreiber von dienstleistenden Systemen), begrenzt vorhanden

• "verlorene Zeit"im Verhältnis zur Zeit der Diensterbringung• Betreiber vs. Kunde

62

Leistungsbewertung

Leistungsanalyse Erfahrung

Simulation Messmethoden Modellbildung/Analyse

Benchmarks

Grundmodell: Bedienstation

[Abb47: Bedienstation]

Regeln:• Aufträge werden ununterbrochen behandelt• Ist die Bedienstation leer, dann gelangt ein Auftrag sofort in die Bedieneinheit

• Sind Aufträge in der Bedienstation, dann kommt der nächste Auftrag in die Warteschlange(FIFO)

• Ist ein Auftrag vollständig in der Bedieneineit bearbeitet, dann rückt ein weiterer aus derWarteschlange nach (unmittelbar)

• λ = Ankunftsrate (Mittelwert) [1/Zeit]• µ = Bedienrate = Leistungsfähigkeit der Bedieneinheit [1/Zeit]

• 1/λ = mittlere Zeit zwischen zwei Ankünften im System (Zwischenankunftszeit) → Zeitzwischen zwei Abgängen aus dem System

• 1/µ = mittlere Bedienzeit

• Maßzahl: ρ= λµ Durchsatz, Auslastung ( ρ: rho)

Voraussetzung: λ ≤ µ (Ansprüche ≤ Leistungsfähigkeit)

→ 0 ≤ ρ ≤ 1

• W = E [W ] Verweildauer (mittlere) (W=Zeit in der Schlange + Zeit in Bedieneinheit)

E [W ] 1µ

• Zielsetzung: Kunde: W 1µ

Betreiber: ρ → 1Sind die Ziele gleichzeitig zu erreichen?

63

7.1.1 Allgemeine Zielsetzung• Erkennung von Eigenschaften z.B. Ursachen einer schlechten Auslastung• Vorhersagen für noch nicht existierende Systeme

• Vergleich von unterschiedlichen Systemen mit gleicher Zielsetzung• Bewertung von Maßnahmen z.B. Verbesserungen

[Abb48: Beispiel T-Kreuzung B9/Mainzer Str.]

7.2 Der Ankunftsprozess (Zufallsprozess)• Menge von Zufallsgrößen, denen eine Zeit zugeordnet ist {X(t), t e T}

• Ankunftsprozess {ANS(t), t e T}

[Abb49: Diagramm Ankunftsprozess]

ANS(t) = ANS2 ≤ t < ANS3

Gegeben: Ein Zeitintervall (s,t] ANS((s0,t0]) = 2

[Abb50: Zeitintervall]

64

7.2.1 Annahmen über den Ankunftsprozess (allgemeingültig)• ANS(0) = 0

• Unabhängigkeit: Ankünfte kommen unabhängig voneinander. Seien (s1, t1] und (s2, t2]disjunkte Zeitintervalle, dann muss gelten:

P[ANS((s1,t1]) = h1, ANS((s2, t2]) = h2] = P[ANS((s1, t1]) = h1] * P[ANS((s2, t2]) = h2]

• Singularität:

Die Ankünfte kommen einzeln.

lims t

P [ ANS s , t ]1]t­s

=0

• Stationarität:

Das Verhalten ist unabhängig vom Zeitpunkt. Sei h ∈ T:

P[ANS((s+h, t+h]) = n] = P[ANS((s, t]) = n]

Beispiel: Postschalter

• Beginn bei t=0• Kunden nicht verabredet!• Kunden kommen einzeln?!

• Zustrom dauerhaft gleichmäßig?

Beantwortung der Frage: Wie groß ist die Wahrscheinlichkeit, dass im Zeitintervall (0, t] mit genaun Ankünften zu rechnen ist?

Pn(t) = P[ANS((0,t]) = n] = Pn(t) = P[ANS(t) = n]

ANS(0) = 0 → Pn(0) : P0(0) = 1, P1(0) = 0,..., Pn(0) = 0

Wie groß ist die Wahrscheinlichkeit P[in ∆ t kommt ein Auftrag]?

Def.: Ankunftsrate λ (t) ← allgemein

λ(t) = lim∆ t 0

∑i=1

∞

P [ ANS t , t∆ t ]=i ]

∆ t

Mit Stationarität:

λ = lim∆ t 0

∑i=1

∞

P [ ANS ∆ t =i ]

∆ t

Mit Singularität:

λ = lim∆ t 0

P [ ANS ∆ t =1]∆ t

65

Antwort:P[in ∆t kommt ein Auftrag] = λ ∆ t

P[in ∆t kein Auftrag] = 1- λ ∆ t

Frage: Wie groß ist die Wahrscheinlichkeit, dass im Intervall (0, t+∆t] mit n Ankünften zu rechnenist (Ansatz)?

[Abb51: Zeitintervall]

Ausgansgleichung zur Herleitung Pn(t):

Pn(t+ ∆ t) = Pn-1(t) * λ * ∆ t + Pn(t) (1- λ * ∆ t)

Poisson-Verteilung:

Pnt =e­λt∗ λt n

n!

7.2.2 Mittlere Anzahl von Ankünften bis zum Zeitpunkt tE[ANS(t)] 1. Moment, entspricht Mittelwert

Def.: E[xk] = ∑i

xk∗pi xk = k-tes Moment

E[ANS(t)] = ∑n=0

∞

n∗Pn t = ∑n=1

∞

n∗e­λt∗λt n

n!= e­λt∗∑

n=1

∞

n∗ λt n

n!

= λt∗e­λt∗∑n=1

∞ λt n­1

n­1!

= λt∗e­λt∗∑n=0

∞ λt n

n!= λt

7.2.3 Zwischenankunftszeiten

[Abb52: Zwischenankunftszeiten]

{ZAZn, n>0} sind untereinander unabhängige Zufallsgrößen.

66

ANS1 = ZAZ1, ZAZi+1 = ANSi+1 – ANSi ← Erneuerungsprozess (renewal process)

Aufgrund der Stationarität genügt eine Zufallsvariable ZAZ.

7.2.3.1 Verteilung von Zwischenankunftszeiten• allg.: Paare (xi, pi)

• kontinuierlich (Integral)• diskret (Summe)

• FX(x) = P[X ≤ x] X = Zufallsgröße, Wert

= ∑xi≤x

Pi diskret

= ∫­∞

x

f X x ' dx ' kontinuierlich

FZAZ(t) = P[ZAZ ≤ t] = 1 – P[ZAZ > t] = 1 – P0[t]

= 1­e­λ∗t

[Abb53: Verlauf von FZAZ(t)]

fZAZ(t) = dF ZAZ t

dt=λ e­λt

[Abb54: Verlauf von fZAZ(t)]

67

7.2.4 Markov-Eigenschaft → Eigenschaft der GedächtnislosigkeitAusgangspunkt: Ankunftsprozess mit exponentialverteilten ZwischenankunftszeitenBeobachtung:

Im Intervall (0, T] fand keine Ankunft statt.Frage: Wie groß ist (dann, unter dieser Voraussetzung) die Wahrscheinlichkeit, dass im Intervall(T, T+ ∆ t] eine Ankunft stattfindet?

[Abb55: Zeitintervall]P[ZAZ ≤ T+ ∆t, ZAZ > T] → Markov= P[ZAZ ≤ ∆t]

7.3 Eigenschaften der Bedienung

[Abb56: Zeitachse; virtueller Bedienprozess]Ermittlung von µ = (mittlere) Bedienrate

µ= n

∑i=1

n

BEZi

Beispiel für einen Bedienvorgang:Bedienung durch einen Plattentreiber

1) Auftrag in Schlange2) a) z.B. Schreiben: Daten in den Controller

b) Anfahren des Zylinders

c) Abwarten der Plattenrotation (Daten auf Platte)d) Vorgang beendet

68

[Abb57: Graphen zu Bedienraten]

7.3.1 Charakteristische Daten für die Exponentialverteilung X (z.B. ANS(t))E[x] = 1/λE[x²] = 2/λ²Var[x] = E[x²] – (E[x])² = 1/λ²

cx = VAR [ x ]E [ x ]

= 1 Variationskoeffizient

7.4 Satz von Little• Voraussetzung:

• System mit Aufträgen

• Stationarität

[Abb58: Bedienstation]• Beziehung zwischen:

• Ankunftsrate λ

• Anzahl von Aufträgen N

• Verweildauer W

N=λ⋅W

Anwendungsbeispiel: Mensa

[Abb59: Mensa]

Essensausgabe (zwei Stationen): alle 10 s wird ein Essen ausgegeben → 2 * 6/Min = 720/h = λDauer eines Essens: 20 Min → 1/3 h720/h * 1/3 h = 240 [Stühle = Aufträge]

69

[Abb60: Essensausgabe]N = λ * W12 = 6/min * WW = 2 min(quer → Mittelwert)

7.5 Kendall-Notation (für dienstleistende Systeme)A/B/C/D/E/FA: Verteilung der Zwischenankunftszeit ZAZB: Verteilung der Bedienzeit BEZ

C: Anzahl der BedieneinheitenD: Kapazität im BediensystemE: Anzahl der Auftraggeber

F: Disziplin der Schlange

[Abb61: M/M/1-System]

[Abb62: M/M/3-System]

[Abb63: M/M/1//N-System; typisch: Dialogbetrieb]

M/G/1-System: G für „general“; z.B. Bedienung durch Plattentreiber, cBEZ muss nicht 1 sein.

M/D/1-System: D für „deterministisch“; cBEZ = 0 → kein Unterschied in BEZ, z.B. Kaffeemaschine

7.6 M/M/1-SystemeGeburts- und Sterbeprozess:N(t) = ANS(t) - ABS(t) N(t): Anzahl der Aufträge im System zur Zeit t

70

Ansatz: Markov-Kette

[Abb64: Markov-Kette]

Pi: Wahrscheinlichkeit, dass gerade i Aufträge im System sind (N(t) = i)

n > 0: pn(λ + µ) = pn-1 * λ + pn+1 * µ

n = 0: p0 * λ = p1 * µ Stationarität

pn * λ = pn+1 * µ

pn+1 = λµ *pn ; ∑

i=0

∞

pi=1 ; pn= λµn

∗p0 hieraus kann man p0 ableiten:

p0 = 1- ρ

pn = (1- ρ) * ρn

[Abb65: Aufgabe aus Klausur zu Markov-Ketten]

∑ pa , pb , pc=1

I pa * λ1 = λ2 * pb + λ4 * pc

II pb ( λ2 + λ3) = pa * λ1

III pc * λ4 = pb * λ3

Auflösen des Gleichungssystems ergibt die Wahrscheinlichkeiten.

E[N] = ∑i=0

∞

i ∗pi=ρ

1­ρ

ρ = Auslastung → Verhältnis von Zustrom auf Leistungsfähigkeit; bewegt sich zwischen 0 und 1

71

[Abb66: ρ im Verhältnis zu E[N]]

ρ 0 ¼ ½ ¾ 9/10 E[N] 0 1/3 1 3 9

Gesucht: E[W]E[N] = λ * E[W]

E[W] = 1λ∗ ρ

1­ ρ= 1

µ∗ 1

1­ ρ

Ziele:

Betreiber: rho → 1 → limrho∞

E [W ]=∞

Benutzer: E[W] = 1/µ → ρ → 0

Beide Ziele nicht gleichzeitig erfüllbar → Kompromiss

Folgerung: E[N] = E[NB] + E[NS] B: Bedieneinheit, S: Schlange

ρ1­ρ = ρ ρ

1­ρ­ρ

E[NS] = ρ⋅E [ N ]

E[WS] = 1λ⋅ρ⋅E [ N ]= 1

µ⋅ ρ

1­ρ

[Abb67:“verlorene Zeit“]

72

Versionshinweise• 1.00: Erste Fassung

• 1.01: Fehlende Grafiken eingefügt• 1.02: Skript um Vorlesungsstoff vom 03.05.05 erweitert• 1.03: Skript um Vorlesungsstoff vom 04.05.05 erweitert

• 1.03b: Es fehlen noch einige Grafiken.• 1.04: Skript um Vorlesungsstoff vom 06.05.05 erweitert, fehlende Grafiken eingefügt

• 1.05: Skript um Stoff bis zum 24.05.05 erweitert, einige Grafiken mit zugehörigen Textstellenfehlen noch.

• 1.06: Fehler behoben, einige Grafiken zugefügt• 1.07: Teilweise überarbeitet (wird fortgesetzt), Stoff vom 31.05.05 zugefügt.

• 2.00: Überarbeitung abgeschlossen, Skript komplett auf aktuellem Vorlesungsstand• 2.01: Skript um Vorlesungsstoff vom 02.06.05 erweitert• 2.02: Skript um Vorlesungsstoff vom 03.06.05 erweitert

• 2.03: Skript um Vorlesungsstoff vom 07.06.05 erweitert (Handout fehlt noch)• 2.04: Skript um Stoff bis zum 10.06.05 erweitert, einige Grafiken fehlen noch.

• 2.10: Skript vollständig

• 2.11: einige kleine Korrekturen vorgenommen• 2.12: weitere Korrekturen (14.07.05)

Special thanks to:• Zealot, fürs Anfertigen einiger Grafiken• Nosferatu, fürs Korrekturlesen

• Stefan Papp, fürs Online-Stellen seines Skripts – prima zum Vergleichen(mittlerweile wieder offline. Schade!)

• Daniel Bildhauer, ebenfalls fürs Online-Stellen seines Skripts

73