1.1. Definition: Echtzeitverarbeitung

Echtzeitverarbeitung
Inhaltverzeichnis
1. EINLEITUNG
4
1.1.
Definition: Echtzeitverarbeitung
4
1.2.
Programmieransätze
4
1.3.
Annahmen der klassischen Programmierung
4
1.4.
Literatur
5
1.5.
Trend
5
2. EIGENSCHAFTEN VON ALGORITHMEN
6
2.1.
Ausführung nebenläufiger Anweisungen
7
2.2.
Abhängigkeiten von Prozessen
9
2.2.1. Konkurrenz
2.2.2. Kooperation
9
9
2.3.
Prozessverwaltung
10
2.4.
Zustände von Prozessen
10
2.5.
Planung (Scheduling)
11
2.5.1. Planung auf niedriger Ebene
2.5.2. Zeitgerechte Einplanung
11
13
2.6.
Unterbrechungen (Interrupts)
15
2.7.
Interrupts versus Sampling
15
3. SYNCHRONISATION
16
3.1.
Synchronisationsbedarf bei:
16
3.2.
Synchronisationsarten
17
3.3.
Kritische Abschnitte (critical sections/ regions)
17
3.4.
Synchronisationsprobleme
18
3.5.
Petri Netze
18
3.5.1.
3.5.2.
3.5.3.
3.5.4.
3.5.5.
Petri-Netze ohne Marken
Interpretation als „Kanal-Instanz Netz“ (channel agency nets)
Petri-Netze mit Marken
Synchronisation in Petri-Netzen
Petri-Netze mit unterscheidbaren Marken
18
19
20
22
25
2
3.6.
Verklemmungen (Deadlocks)
3.6.1. Verklemmungsvermeidung durch Bedarfsangabe
3.7.
Schlossvariablen
3.7.1. Einseitige Synchronisation
3.7.2. Mehrseitige Synchronisation
4. WHAT REALLY HAPPENED ON MARS?
26
28
29
29
29
38
3
1.
Einleitung
1.1. Definition: Echtzeitverarbeitung
Zeitkritische Anwendungen innerhalb ihres Zeitrahmens ausführen, maximal bis zur
Deadline. Prozess gibt Echtzeitanforderungen vor.
1.2. Programmieransätze
time-triggered
zeitgesteuert
synchrone Programmierung
-
SPS (speicherprogrammierbare
Steuerung)
event-triggered
ereignisgesteuert
asynchrone Programmierung
-
-
E
Sensoreingaben
P
Programm
A
Ausgabe
Aktorik
-
-
Tasks (Threads), Interrupts können
auftreten, Programm kann dadurch sehr
lange dauern
nicht deterministisch aber flexibel
Fokus der Vorlesung, obwohl weniger
geeignet als linke Variante
es gibt Abhängigkeiten zwischen Tasks,
die synchronisiert werden müssen
bei geteilten Betriebsmitteln Möglichkeit
zum Deadlock
am Eingang werden alle Signale
(Alarm, Daten) erfasst
das
Programm
läuft
ohne
Unterbrechung durch, selbst bei Alarm
erst beim nächsten Durchlauf wird
darauf eingegangen
zeitsicher
unflexibel, determiniert, sicher für
Echtzeit
1.3. Annahmen der klassischen Programmierung
-
1 Rechner führt genau ein Programm aus
1 Programm wird genau auf einem Rechner ausgeführt
1 Programm erfüllt seine Funktion unabhängig vom Startzeitpunkt und benötigt
Bearbeitungszeit
4
Fallen diese Annahmen weg, sind Programme
- nebenläufig (concurrent)
- verteilt (distributed)
- echtzeitabhängig (real-time dependet)
1.4. Literatur
Nebenläufige Programme (Springer Verlag)
Real Time Systems (Flugzeug auf Cover)
Real Time Systems (Satellit auf Cover)
1.5. Trend
Dezentralisierung durch verteilte Systeme
Multiprozessorsysteme
konzentriertes System
verteiltes System
Kommunikation über gemeinsame Speicher
ohne gemeinsamen Systembus:
Prozessor 1
Kommunikation über Bussysteme (Netz)
Prozessor 1
Feldbus, Ethernet
Prozessor 2
Prozessor 2
Speicher 1
Systembus 1
Speicher 2
Systembus 2
Synchronisierung über Nachrichten
Speicher 1
gemeinsamer
Speicher
Speicher 2
mit gemeinsamen Systembus:
Prozessor 1
Prozessor 2
Systembus
Speicher 1
gemeinsamer
Speicher
Speicher 2
Synchronisierung über globale Variablen
5
2.
Eigenschaften von Algorithmen
sequentieller Ablauf
Bsp.
v = x;
w = x;
x = y;
Programme, deren Ablauf eindeutig vorherbestimmt ist, heißen deterministisch.
Deterministische Programme liefern bei jeder Ausführung mit gleichen Eingabedaten
identische Ergebnisse
Bsp.
x = i; y = j; //Eingabe
v = x;
w = x;
x = y;
v = w = i; x = y = j; //Ausgabe
Ein Programm, das bei gleichen Eingaben gleiche Ausgaben produziert, heißt determiniert.
Deterministische Programme liefern determinierte Ergebnisse. „Deterministisch“ bezieht sich
auf Ablauf (Reihenfolge des Ablaufs vorhersehbar), „determiniert“ bezieht sich auf Ergebnis.
=> Können determinierte Ergebnisse auch ohne deterministische Programme erzeugt werden?
Verzicht auf Sequentialität kann bedeuten:
- die Anweisungen können parallel von mehreren Prozessoren ausgeführt werden
oder
- die Anweisungen können in einer beliebigen Folge sequentiell von einen Prozessor
ausgeführt werden
→ das ist die Definition von Nebenläufigkeit
Bsp.
v = x; //mit zweiter Anweisung austauschbar
w = x; //erste und zweite Anweisung sind folglich nebenläufig
x = y;
Definition:
Eine unteilbare Anweisung wird von einem Prozessor ohne Unterbrechung ausgeführt. Falls
die Anweisung nicht unteilbar ist, kann die Ausführung in mehreren Schritten erfolgen.
Ist eine Anweisung nebenläufig, ist auch jeder Schritt nebenläufig.
6
Bsp.
Parallele Ausführung auf zwei Prozessoren, → t
A1
Prozessor 1
Prozessor 2
A2
B1
A3
B2
nebenläufig auf einem Prozessor, wenn Anweisungen unteilbar, → t
Variante 1
Variante 2
A1
B1
A2
A3
B1
B2
A1
B2
A2
A3
nebenläufig auf einem Prozessor, wenn Anweisungen teilbar, verzahnte Ausführung möglich
(interleafing), Reihenfolge von A und B muss gewahrt werden (z.B. A2 nicht vor A1), → t
eine mögliche
Variante
B1
A1
A2
B2
A3
Begriffe: nebenläufig ≠ parallel
Parallelität ist eine spezielle Form der Nebenläufigkeit: nebenläufige Anweisungen sind
parallel, wenn sie auf verschiedenen Prozessoren ausgeführt werden.
2.1. Ausführung nebenläufiger Anweisungen
Bei der Ausführung können nebenläufige Anweisungen per Definition beliebig (= nicht
deterministisch) sequentialisiert werden.
Wird trotz Nichtdeterminismus ein deterministisches Ergebnis erwartet, müssen alle
möglichen Sequentialisierungen das gleiche Ergebnis liefern.
Bsp.
conc x = x+1 || x = x+1 end conc
Schritt Anweisung 1 Anweisung 2 x
0
i
1
x = x+1
i+1
2
x = x+1
i+2
Annahme: Anweisung x = x+1 ist unteilbar, gleiches Ergebnis bei umgekehrter Reihenfolge
Annahme: Anweisung erfolgt nicht unteilbar, sondern in folgender Sequenz:
load x, r //Inhalt von x ins Register r Laden
inc r
//r inkrementieren
store r, x //r nach x schreiben
Verzahnte Ausführung (eine Möglichkeit):
7
Schritt
0
1
2
3
4
5
6
Anweisung 1 Anweisung 2
load x, r
inc r
load x, r
inc r
store r, x
store r, x
x
r
i
i
i
i
i
i+1
i+1
?
i
i+1
i
i+1
i+1
i+1
Falsches Ergebnis, weil Anweisung unteilbar.
Annahme: verschiedene Register für jede Anweisung:
Schritt
0
1
2
3
4
5
6
Anweisung 1 Anweisung 2
load x, r1
load x, r2
inc r1
inc r2
store r1, x
store r2, x
x
r1
i
?
i
i
i
i
i
i+1
i
i+1
i+1 i+1
i+1 i+1
r2
?
?
i
i
i+1
i+1
i+1
Falsches Ergebnis (ein Beispiel reicht aus, um Nebenläufigkeit zu widerlegen)
Bei Nebenläufigkeit determiniertes Ergebnis nur wenn alle Sequentialisierungen auf der
Ebene der unteilbaren Anweisungen das gleiche Ergebnis liefern.
Selbst wenn die Anweisung x = x+1 unteilbar ist, kann die parallele Ausführung Probleme
bereiten:
Schritt Prozessor 1 Prozessor 2 x
0
i
1
x = x+1
x = x+1
i+1
Die Determiniertheit ist bei Mehrprozessorsystemen selbst bei Unteilbarkeit der Anweisungen
nicht gewährleistet.
Problem der Nichtreproduzierbarkeit bei nebenläufigen Anweisungen (Fehler können z.B. nur
bei einer bestimmten Ausführungsreihenfolge auftreten und sind kaum zu finden).
Definition: Prozess (Rechnerprozess, Task)
Ein Prozess ist eine sequentielle Folge von Aktivitäten, durch die eine in sich geschlossene
Aufgabe bearbeitet wird. Prozesse sind virtuelle Objekte zur Strukturierung von
Programmsystemen. In der Regel sind Prozesse von einander abhängig.
8
2.2. Abhängigkeiten von Prozessen
2.2.1. Konkurrenz
Gleichzeitige Benutzung eines gemeinsamen Betriebsmittels.
2.2.2. Kooperation
Produzenten-Konsumenten Systeme
Produzent
Produzent
Konsument
Konsument
Kommunikation nur in eine Richtung
Bsp. Buchungssystem im Supermarkt
3 Tasks
Lesen
Lesen
Buchung
Buchung
Strichcode
Drucken
Drucken
Zettel
Prozesse sind Nebenläufig, d.h. „Drucken“ kann nebenläufig von „Lesen“ und „Buchen“
passieren. Es ist aber nicht unabhängig, es kann erst gedruckt werden, wenn Daten vom
Buchungssystem eintreffen.
Auftraggeber-Auftragnehmer Systeme (Client-Server)
Auftraggeber
Auftraggeber
Auftragnehmer
Auftragnehmer
Bsp.
Bordcomputer
Bordcomputer
Verkehrsrechner
Verkehrsrechner
Kooperation und Konkurrenz schließen sich nicht aus. Teilaufgaben kooperierender Prozesse
können in Konkurrenz zueinander stehen. (Mischform)
Synchronisation koordiniert die Kooperation und Konkurrenz zwischen Prozessen (= bringt
die Aktivitäten verschiedener nebenläufiger Prozesse in eine bestimmte Reihenfolge).
Synchronisation erfordert Kommunikation (und umgekehrt):
- zum Abstimmen zweier Aktivitäten können Prozesse Informationen austauschen
- ein Informationsaustausch erfordert die Abstimmung der Aktivitäten von
Informationsabgabe und –aufnahme
9
2.3. Prozessverwaltung
Hat die Aufgabe, Prozesse in geordneter Weise einen Prozessor zur Verfügung zu stellen.
Prozesse benötigen neben dem Prozessor noch weitere Betriebsmittel (BM, ressources).
Definition: Betriebsmittel
Das sind alle Elemente einer Rechenanlage, die von einem Prozess benutzt werden können
(Ausgabegeräte, Speicherbereiche, …)
Eigenschaften vom Betriebsmittel:
- exklusiv, Zugriff nur durch einen Prozess zu jedem Zeitpunkt
- entziehbar (preemtive), Prozess gibt das BM ab und kann nach Wiederzuweisung so
arbeiten, als hätte er es nie abgegeben (nicht entziehbar z.B. Drucker)
- wiederverwendbar (reusable), z.B. RAM, aber nicht ROM
2.4. Zustände von Prozessen
Anmelden (wird erschaffen,
läuft aber noch nicht)
existent
Start
unbekannt
Neustart
Zuteilung
des Prozessors
bereit
wartet auf
Prozessor in
Warteschlange
Abmeldung
beendet
durch vollständige
Abarbeitung
laufend
Entzug des
Prozessor
Fremdblockade (BM
außer Prozessor fehlt)
Eigenblockade
(BM nicht zur Verfügung
außer Prozessor)
blockiert
Betriebssystem (OS) ist auch ein Task (Prozess) mit höchster Priorität.
Operationen, die zu Zustandsübergängen führen, können immer nur vom laufenden Prozess
durchgeführt werden. Prozesse können sich nicht selbst starten oder „de blockieren“.
Verwaltungsprozess (Scheduler) läuft in regelmäßigen Abständen und bei allen Aktionen, die
Zustandswechsel erfordern.
Bsp. Anweisung in PEARL (Programmiersprache für Echtzeit, heute kaum noch genutzt,
ADA beliebter)
Terminate Druckmessung;
AFTER 24HRS ACTIVATE Druckmessung;
…
Suspend Druckmessung;
…
Continue Druckmessung;
10
Bereitliste der Prozessverwaltung
Zuteilung zu Prozessor
1. Prozess G
2. Prozess J
3. Prozess B
4. Prozess M
Stellung in Liste
gibt augenblickliche
Priorität an
Warteschlange
Verschiedene Zuteilungsstrategien:
FIFO, LIFO
2.5. Planung (Scheduling)
Ist die Methode, nach der Priorität von Prozessen bestimmt wird.
Planung ist auf verschiedenen Ebenen möglich:
- niedrige Ebene: Vergabe eines BM (Prozessor)
- mittlere Ebene: mehrere BM-Anforderungen im Zusammenhang
- höchste Ebene: alle Prozesse im Zusammenhang betrachten
Planung ist Teil der Prozessverwaltung und kostet Rechenzeit (Overhead). Ziel: möglichst
sinnvolle Systemauslastung.
Planungskriterien verschieden je nach Anwendung:
- Interaktive Systeme: alle Benutzer sollen möglichst gleichmäßig schnell
vorankommen, „Faire“ Planung vermeidet „Aushungern“ von Prozessen (Starvation,
Prozess erhält auf Dauer mindestens ein BM nicht)
- Echtzeitsysteme: Deadlines entscheidend, nicht unbedingt Fairness
2.5.1. Planung auf niedriger Ebene
Berücksichtigung eines BM → Prozessorbeschränktes System (processor bound system)
Zuteilung
des Prozessors
Start
bereit
Beendigung
laufend
Entzug des
Prozessor
Warten auf BM wird nicht betrachtet → kein „blockiert“ Zustand
11
a) Einplanung nach Wartezeit (FIFO)
Strategie geht davon aus, dass ein gestarteter Prozess ohne Unterbrechung bis zum Ende
abgearbeitet wird. Ungeeignet für Echtzeitanforderungen.
Positiv: minimaler Aufwand, objektives Kriterium
Negativ: alle Prozesse werden gleich behandelt (kurzer dringender Prozess muss auf langen,
bereits gestarteten warten)
b) Einplanung nach Laufzeit, Prozess mit kürzester Laufzeit wird zuerst bearbeitet
(shortet job first)
Welcher Prozess ist der kürzeste? Schätzungen der Benutzer (Extra-Kosten oder Abbruch bei
überschreiten des angegebenen Schätzwerts). Ununterbrochene Abarbeitung eines Prozesses
oder Unterbrechung beim Eintreffen eines kürzeren Prozesses? Bei zweiten Fall Gefahr des
Aushungerns.
c) Zyklische Einplanung (round-robin Scheduling)
Jeder Prozess erhält feste Zeitscheiben (time slots). Anpassung an verschiedene Prozesse
durch verschieden große Zeitscheiben. Optimale Festlegung der Dauer schwierig. Slots zu
lang: Leerlauf bei kurzen Prozessen. Slots zu kurz: Overhead bei Prozesswechsel steigt, wenn
Prozesse im Slot nicht beendet werden können.
d) Mehrstufige Warteschlangen (multi-level queues)
Annahme: Prozess behält seinen „Charakter“ während seiner Existenz (kurzer bzw. langer
Prozess)
Prozessor
Priorität der
Warteschlange
1
2
3
2
4
Warteschlangen der
jeweiligen Priorität
5
1
2
3
4
5
3
1
neu gestarteter Prozess kommt an das Ende der Warteschlange mit höchster Priorität
Abarbeiten des Prozesses für bestimmte Zeitscheibe
noch nicht fertig → Warteschlange mit niedrigerer Priorität
Abarbeitung nur, falls keine Prozesse auf höherer Ebene warten
nicht fertig → unterste Ebene mit zyklischer Einplanung
Kurze Prozesse werden begünstigt, lange Prozesse sinken schnell in Warteschlange mit
niedrigster Priorität. Länge der Zeitscheiben unterschiedlich für verschiedene
Warteschlangen.
Planung wird wesentlich komplexer, wenn mehrere BM betrachtet werden.
12
2.5.2. Zeitgerechte Einplanung
Zeiten und Zeitschranken bei der Ausführung eines Prozesses:
Restlaufzeit L(t0)
Spielraum S = tZ - tE
Restantwortzeit a(t0)
Laufzeit L = tE – tS
Zeit
tA
tS
frühester tatsächlicher
Startzeitpunkt
t0
tE
tatsächlicher
Endzeitpunkt
tZ
spätester Endzeitpunkt
(Deadline)
Definition: Zeitgerechte (timely) Einplanung
Alle Prozesse können vor ihrem spätesten Endzeitpunkt tZ beendet werden.
Einplanung nach Antwortzeiten (Earliest Deadline First)
Jeder Prozess hat eine vorgegebene Deadline tZ. Prozess mit kürzester Antwortzeit wird dem
Prozessor zugeteilt.
a1
s1
P1
Antwortzeit ai
a2
s2
P2
Spielraum si
a3
s3
P3
Deadline
1
4
t
Antwortzeit von Betrachtungszeitpunkt (hier t = 0) bis Deadline.
Antwortzeiten nehmen linear ab mit der Zeit, unabhängig
davon, ob sie bearbeitet werden oder nicht.
ai
6
5
4
a1
3
a2
2
a3
Vorab-Planung wird nur einmal durchgeführt.
1
1
Prozessorbelegung
P3
1
2
3
4
P2
2
3
5
6
t
P1
4
5
6
t
Zuerst P3, da es kürzestes ai besitzt. Dann P2 wegen
zweitkürzester ai. Nach jedem Zeitschritt schaut OS, ob es
neuen Prozess mit kürzerer ai gibt. Dann wäre Entzug des
Prozessors und Prozesswechsel nötig.
13
Einplanung nach Spielraum (least laxity)
Man benötigt Laufzeit, viel schwieriger zu Ermitteln. Voraussetzung: für jeden Prozess ist
Laufzeit und Antwortzeit bekannt → Prozess mit kleinsten Spielraum erhält den Prozessor.
Planungszeitpunkte: Prozess mit kleinstem Spielraum
erhält den Prozessor.
si
4
3
2
1
a3
Solange Pi bearbeitet wird, ist si konstant. Für alle
wartenden Prozesse nimmt si linear ab.
a2
1
Prozessorbelegung
a1
2
3
4
5
6
t
P2 P3 P2 P1 P1
1
2
3
4
5
6
t
In Einprozessorsystemen sind beide Varianten optimal. In Mehrprozessorsystemen ist die
Strategie nach Antwortzeiten nicht mehr zeitgerecht (siehe folgendes Beispiel). Einplanung
nach Spielraum ist in Mehrprozessorsystemen zeitgerecht, falls die frühesten Startzeitpunkte
aller Prozesse gleich sind. Falls nicht siehe Beispiel 2.
Beispiel 1
Prozessorvergabe bei gleichen frühesten
Prozessstartzeiten
Einzuplanende Prozesse:
Beispiel 2
Prozessvergabe
bei
unterschiedlichen
frühesten Prozessstartzeiten
Einzuplanende Prozesse:
Laufzeit
Laufzeit
P1
P1
spätester
Endzeitpunkt
P2
spätester
Endzeitpunkt
P2
Zeit
P3
Prozessorvergabe nach Antwortzeit:
P3
frühester
Startzeitpunkt
P4
P5
Verletzung der
Antwortzeit
Prozessor 1
P2
P6
P1
P7
Prozessor 2
Zeit
P3
Prozessorvergabe nach Spielraum:
Prozessvergabe nach Spielraum:
Verletzung der
Antwortzeit
Prozessor 1
Prozessor 1
P1
P1
P2
P3
P3
P4
P3
P7
Prozessor 2
Prozessor 2
P2
Zeit
P5
P6
Zeit
Zeit
14
Zeitgerechte Prozessorvergabe:
Prozessor 1
P2
P1
P4
P6
P5
P7
Prozessor 2
P2
P3
Zeit
2.6. Unterbrechungen (Interrupts)
Sie veranlassen den Prozessor, seine laufenden Aktivitäten zu unterbrechen, um andere
Aktivitäten auszuführen.
Zwei Arten:
a) Externes Ereignis (external event) löst Unterbrechung zu einem unvorhersehbaren
Zeitpunkt asynchron zur Programmausführung aus. („echte“ Unterbrechung, „real“
interrupt)
b) Internes Ereignis (internal event) wird durch die gerade vom Prozessor ausgeführte
Operation ausgelöst, tritt also synchron zur Programmausführung auf.
(Ausnahmebedingung, exception).
Asynchrone Unterbrechungen werden durch Unterbrechungswerk (interrupt unit)
hardwaremäßig realisiert → Unterbrechungsbehandlungsroutine (interrupt handler).
Synchrone Unterbrechungen = Ausnahmebedingungen → Ausnahmebehandlungsroutine
(exception handler).
2.7. Interrupts versus Sampling
1 = Sensor unter Wasser
0 = sonst
Sensor
Wasser
Interrupt ungünstig bei Wellengang (ähnlich dem Prellen beim Schalter)
Wand
Nur bei geordneten Reaktionszeiten, die nicht durch Sampling zu erreichen sind, sind
Interrupts nötig. Im Grenzbereich wird eine Folge von Interrupts ausgelöst. Besser Sampling
(per Software alle paar Momente den Eingangsport abfragen), mitteln des Signals über einen
bestimmten Zeitraum.
15
3.
Synchronisation
Kooperierende oder konkurrierende Prozesse erfordern Synchronisation. Durch
Synchronisation wird die Unabhängigkeit der Abfolge von Aktivitäten verschiedener Prozesse
eingeschränkt.
3.1. Synchronisationsbedarf bei:
a) Schreib-Schreib-Konflikt
2 Prozesse verändern eine Variable nebenläufig (conc zur Deklaration nebenläufiger
Prozesse)
conc x = x+1 || x = x+1 end conc
Problem: nichtdeterministisch
Lösung: Unteilbarkeit der Aktivitäten
b) Schreib-Lese-Konflikt
Mögliche Inkonsistenzen, wenn ein Prozess Daten schreibt, während sie ein anderer
nebenläufig liest.
Bsp. Kontoführungssystem, 2 nebenläufige Prozesse: Registrieren einer Einnahme und
Abfrage des Kontostandes
Input
Zahlungsart
Input
Betrag
nein
Prozess 1: „Registrieren“
t = 0: Ein_Gesamt = 100, Ein_Schecks = 0
Betrag = 200
Zahlungsart
= Scheck?
als Scheck
ja
Ein_Schecks = Ein_Schecks + Betrag
Ein_Gesamt = Ein_Gesamt + Betrag
Stop
Ein_Gesamt
nein
Output
nach Berechnung Unterbrechung, zweiter Prozess
dann Fortsetzung
Ein_Gesamt = 300
Ende
Prozess 2: „Kontostand“
Output = 100
Ein_Gesamt > 0
ja
200
 200%
100
Ein _ Schecks
 100%
Ein _ Gesamt
Stop
Output
nach Ende zurück zu Prozess 1
16
t
Registrieren
Kontostand Ein_Gesamt Ein_Schecks
0
100
0
1 Ein_Schecks + 200
100
200
2
Output
100
200
3 Ein_Gesamt + 200
300
200
Bei ungünstiger Abfolge können Inkonsistenzen entstehen.
3.2. Synchronisationsarten
Unterscheidung je nachdem ob die Reihenfolge durch die Synchronisation von vornherein
feststeht oder nicht.
a) Einseitige Synchronisation
Zwei Aktivitäten A1 und A2
A1 → A2
(„→“ = geschieht vor)
A2 wird so lange verzögert bis A1 beendet ist. Synchronisation hat keine Auswirkungen auf
A1.
Anweisung AWAIT „Wartebedingung“ blockiert einen Prozess bis Bedingung erfüllt ist.
Registrierung von AWAIT noch offen: wie erfährt der Prozess das Eintreffen der Bedingung?
b) Mehrseitige Synchronisation (multilateral)
Zwei Aktivitäten A1 und A2 verschiedener Prozesse
A1 ↔ A2
(„↔“ = nicht zusammen mit (transitiv))
Anweisungen schließen sich gegenseitig aus. Reihenfolge liegt nicht fest: läuft A2 muss A1
warten bis A2 endet und umgekehrt. Keine Aktivität unterbricht die andere.
Bsp. Produzenten-Konsumenten-System
A1 (schreibt x) ↔ A2 (liest x, schreibt y) ↔ A3 (liest y)
——————————————————————> Datenfluss
Zwischen A1 und A3 keine Abhängigkeiten, konfliktfrei, nicht transitiv.
3.3. Kritische Abschnitte (critical sections/ regions)
Sind Anweisungen, deren Ausführung einen gegenseitigen Anschluss erfordert. Jede Klasse
kritischer Abschnitte besitzt eine Ordnung, die angibt, wie viel kritische Abschnitte dieser
Klasse zu einer Zeit ausgeführt werden dürfen.
Bsp. ftp_zugriff: critical (100)
100 bedeutet maximale Zahl nebenläufiger Prozesse im kritischen Abschnitt
Syntax:
crit ftp_zugriff do
… kritischer Abschnitt
end_crit
17
Prozess muss vor dem Betreten eines kritischen Abschnitts Erlaubnis einholen vom OS. Wenn
besetzt, dann warten.
3.4. Synchronisationsprobleme
a) Betriebsmittelnutzung
Alle Prozesse, die ein bestimmtes BM exklusiv nutzen wollen (z.B. Prozessor), bilden eine
kritische Klasse der Ordnung 1. Stehen n BM einer Sorte zur Verfügung (z.B. Drucker), dann
kritischer Abschnitt der Ordnung n.
b) Leser und Schreiber
Alle Lese- und Schreibzugriffe auf eine Variable bilden eine Klasse kritischer Abschnitte.
Nebenläufiger Zugriff beliebig vieler Leser möglich, Schreiber (-prozesse) benötigen
exklusiven Zugriff.
Unterscheidung nach Reihenfolge des Zugangs:
Erstes Leser-Schreiber Problem
Schreiber muss warten bis alle Leser fertig sind. Neu hinzukommender Leser kann Schreiber
überholen.
Zweites Leser-Schreiber Problem
Schreiber wartet auf begonnene Leser. Neue Leser müssen warten, bis Schreiber fertig ist.
Alle komplexen Synchronisationsvorgänge lassen sich in elementare einseitige und
mehrseitige Synchronisationen zerlegen.
3.5. Petri Netze
Dienen zur Modellierung nebenläufiger Systeme. 1962 von Petri in seiner Dissertation
entwickelt. Seither zahlreiche Varianten und Erweiterungen.
Wozu modellieren? Nachweis von Eigenschaften (z.B. Verklemmungsfreiheit) am Modell.
3.5.1. Petri-Netze ohne Marken
Gerichteter Graph mit 2 Arten von Knoten (Stellen, Transitionen) verbunden durch Menge
von Kanten (= Flussrelation).
18
Stellen
(places)
Transition
Eingansstellen mit
gerichteter Kante
zu einer Transition
Ausgangsstellen, eine
gerichteter Kante führt
von einer Transition weg
Isolierte Teilnetze = unabhängige nebenläufige Systeme
Zwei Stellen nicht direkt verbinden, immer Transitionen dazwischen.
3.5.2. Interpretation als „Kanal-Instanz Netz“ (channel agency nets)
Stelle = Kanal (passive Systemkomponente, z.B. Speicher Layer)
Transition = Instanz (aktive Systemkomponente, Verarbeiten von Informationen oder
Material)
Bsp. Materialverwaltung
Bestellannahme
Lieferauftrag Auslieferung
Lieferfertige
Waren
Kanal
Bestellung
Instanz
Produktionsauftrag Produktion
Lager
Teilnetze müssen gleiche Eingänge und Ausgänge haben, eingehende Kanten enden immer an
Transitionen und abgehende Kanten auf Stellen. Für jeden Verfeinerungsschritt muss die
Netzstruktur erhalten bleiben.
19
Verfeinerung von Auslieferung:
Lieferauftrag
Lieferschein
Versenden
Verpacken
verpackte
Produkte
Lieferfertige
Waren
Lieferscheinerstellung
Lager
Petri-Konzept um Dynamik erweitern → Marken.
3.5.3. Petri-Netze mit Marken
Modellierung der dynamischen Eigenschaften eines Systems durch Markierung der Stellen
und Definition von Schaltregeln. Geläufigste Form eines Petri-Netzes mit Marken sind:
Stellen-Transitions-Netze (state transition nets)
Zustand eines Systems wird durch Marken (token) in den Stellen beschrieben.
Zustandänderung erfolgt durch Schalten (firing) von Transitionen.
Bsp. Schalten einer Transition
= Marken
a) vorher
b) nachher
Schaltregeln bei Stellen-Transitions-Netzen
a) Transition kann erst dann Schalten, wenn alle Stellen ihres Vorbereiches „markiert“ sind
(= mindestens je eine Marke enthalten).
b) Durch das Schalten wird je eine Marke aus jeder Stelle des Vorbereichs genommen
(verarbeitet, vernichtet).
c) Durch das Schalten wird in jeder Stelle des Nachbereiches eine Marke erzeugt.
→ Anzahl der Marken im Netz muss nicht konstant bleiben
20
Die Kapazität einer Stelle ist die maximale Anzahl an Marken, die sie aufnehmen kann.
Kapazität = 5
ohne Angabe: Kapazität = ∞
Die Gewichtung einer Kante gibt an, wie viele Marken beim Schalten transportiert werden.
Gewichtung = 4
Bsp. Schalten mit gewichteten Kanten
3
3
2
2
a) vorher
b) nachher
Transition kann nur Schalten, wenn die Schaltregeln bezüglich Kantengewichtung und
Stellenkapazität nicht verletzt werden.
Bsp. nichtschaltende Transitionen
1
2
Markenmangel
Markenüberfluss
Petri-Netze heißen todesgefährdet, wenn ein Zustand eintreten kann, in dem keine Transition
mehr schalten kann (aufgrund leerer Stellen im Vorbereich oder voller Stellen im
Nachbereich).
Bsp.
lebendig
todesgefährdet
21
Systeme, die im Endlosbetrieb laufen sollen, müssen durch ein lebendiges Petri-Netz
beschrieben werden können. Bei lebendigen Petri-Netzen kommt es weder zu Markenmangel,
noch Markenüberfluss.
3.5.4. Synchronisation in Petri-Netzen
Stellen-Transitions-Netze erlauben die Modellierung nebenläufiger Systeme: Transitionen
sind Aktivitäten, Markierungen von Stellen beschreiben den Zustand des Systems.
Bsp. t1; conc t2 || t3 end conc; t4
erst t1, dann t2 und t3 nebenläufig (Reihenfolge egal), am Ende t4
t2
t1
t4
t3
Sieht parallel aus, soll aber nebenläufig sein.
Die Dauer der Transitionen (=Aktivitäten) wird meist nicht explizit modelliert (könnte aber).
Trotzdem sieht man:
- t2 und t3 können erst starten, wenn t1 beendet ist
- t4 kann erst starten, wenn t2 und t3 beendet sind
Bsp.
t2
t1
t4
t3
Nichtdeterminiertheit im Petri-Netz (wird t2 oder t3 ausgeführt?) → Konflikt
!!Völlig anderes Netz als im ersten Beispiel.
Einseitige Synchronisation
Vor dem Ausführen von t2 muss die Bedingung b von einem anderen Prozess erfüllt werden:
22
t1
t2
t3
Gegenseitiger Ausschluss für kritische Abschnitte einer Klasse k (K = kritischer Abschnitt):
P1: t1; crit K do t2 end krit; t3
P2: t2; crit K do t5 end krit; t6
t2
crit
end crit
t1
t3
t4
t6
crit
end crit
t5
Semaphor/
Schlüssel zu crit
kritischer Abschnitt
Bsp. Buchungssystem, 3 Prozesse: Lesen, Buchung, Drucker
Produzenten und Konsumenten:
Lesen
Buchen
Pufferspeicher
Drucken
Datenfluss
leer
Lesen
n
Marken
Abnehmen
Ausgabepuffer
mit m freie
Plätze
voll
Ablegen
leer
Buchen
Eingabepuffer
mit n freie Plätze
m
Marken
Abnehmen
voll
Ablegen
Drucken
23
Lesen: liest erst, wenn was zu lesen da ist (nicht eingezeichnet)
Buchen: ist Produzent und Konsument
Drucken: reiner Konsument
Ablegen im Puffer setzt freien Pufferplatz voraus. Abnehmen aus Puffer setzt einen
beschriebenen Pufferplatz voraus. Bei unterschiedlich schnellen Prozessen wird über die
Kapazität des Puffers synchronisiert.
Leser und Schreiber:
Je 4 Aktivitäten sind zu modellieren:
- Arbeiten im unkritischen Bereich
- Betreten des kritischen Abschnitts (k.A.)
- Arbeiten im kritischen Abschnitts
- Verlassen des kritischen Abschnitts
Leser
Eintritt
Eintritt
Schreiber
3
S
unkritischer
Abschnitt
k.A.
k.A.
unkritischer
Abschnitt
3
Schlüssel,
Semaphor
3 Leser
Austritt
Austritt
3 Schreiber
Problem: Schreiber könnten ausgehungert werden
Lösung: Funktion implementieren, damit neue Leser warten, wenn es einen Schreiber gibt,
der in den kritischen Abschnitt will
In jedem Zyklus können sich mehrere Marken befinden (z.B. 3). Jede Marke repräsentiert den
Zustand eines Prozesses der jeweiligen Klasse. Initiale Markenbelegung der Stelle S = Anzahl
der Leser, die gleichzeitig im kritischen Abschnitt arbeiten können. Schreiber kann nur in den
kritischen Abschnitt, wenn keine Leser mehr im kritischen Abschnitt → alle 3 Marken in
Stelle S. Schreiber entfernt bei Eintritt in kritischen Abschnitt alle 3 Marken aus S → Zugriff
für Leser gesperrt.
Speisende Philosophen:
P1
Pi = Philosophen
Si = Stäbchen
P2
S2
S1
P0
S3
S0
S4
P4
P3
2 Stäbchen zum Essen benötigt
3 Zustände: Denken, Warten aus 2 S, Essen
Deadlock, wenn alle Philosophen gleichzeitig essen wollen, je ein
Stäbchen in die Hand nehmen und aufs zweite warten
24
Jeder Philosoph wird durch einen Zyklus mit je einem Prozess modelliert. Zustand der
Stäbchen wird durch Belegung der entsprechenden Stelle modelliert.
P0
Denken
Speisen
P4
S0
S4
P1
S1
S3
S2
P3
P2
Ist vereinfachtes Modell durch „Faltung“ möglich?
Philosophen
Netz ist nicht falsch, entspricht als Modell aber nicht mehr der
ursprünglichen Aufgabenstellung: Philosophen und Stäbchen
haben ihre „Identität“ verloren (Platz nicht mehr berücksichtigt),
jeder kann zu beliebigen Stäbchen greifen.
→ Abhilfe: individuelle Marken
2
2
freie Stäbchen
3.5.5. Petri-Netze mit unterscheidbaren Marken
Individuelle Marken werden z.B. durch eine Zahl gekennzeichnet. Transitionen schalten erst
bei Vorliegen bestimmter Marken → Schaltbedingung.
Bsp.
8
5 3
17
1
42 4
10
Schaltbedingung
x (firing condition)
z
x = 2y
y z = 2x + y
Schaltwirkung
(firing result)
a) vorher
5 3
17
x
x = 2y
y
z = 2x + y
z
20
1
42 10
b) nachher
25
x = 8, y = 4, Marken durch Schalten verbraucht, z = 20, neue Marke erzeugt
Wenn keine Schaltbedingung angegeben: Schalten wie sonst, d.h. unabhängig von
bestimmten Marken. wenn keine Schaltwirkung angegeben: Marken werden unverändert in
den Nachbereich übernommen.
Bsp. Speisende Philosophen
Philosophen
0
123
4
i
st1 = i
st2 = (i+1) mod 5
i
st1 = i
st2 = (i+1) mod 5
0
st1, st2
123
4
freie Stäbchen
st1, st2
Diese Netze werden auch als Prädikats-Transitions-Netze (predicate transition nets)
bezeichnet.
Vorteile:
- übersichtlicher als Stellen-Transitions-Netze
- mächtiger Formalismus, z.B. auch mit Schaltbedingung „Temperatur > 42“
Nachteil:
- schwierige Handhabung
- bei komplizierten Problemen nicht mehr anschaulich
3.6. Verklemmungen (Deadlocks)
Verklemmungen treten dann auf, wenn Prozesse auf Ereignisse warten, die nicht mehr
auftreten können.
Bsp.
2 Studenten brauchen beide ein zweibändiges Lehrbuch. Student 1 leiht Band 1 aus, will Band
2 später holen. Student 2 leiht Band 2 aus. Student 1 will Band 1 nicht zurückgeben, bevor er
Band 2 hat. Ebenso gedenkt Student 2 mit seinem Buch umzugehen.
band1, band2: critical(1);
exklusives Betriebsmittel = kritische Abschnitte der Ordnung 1
26
2 nebenläufige Prozesse
Student 1: process
crit band1 do
band1 lesen
crit band2 do
band2 lesen
end crit
end crit
end process
Student 2: process
crit band2 do
band2 lesen
crit band1 do
band1 lesen
end crit
end crit
end process
Verklemmung bei Ausführungsreihenfolge:
Student 1
Student 2
crit band1 do
crit band2 do
Deadlock
crit band2 do
crit band1 do
Modellierung mit Petri-Netz:
band1 ausleihen
band2 ausleihen
band1 band2
band2
ausleihen
process
Student 1
band1
ausleihen
beide Bände
zurückgeben
process
Student 2
Netz ist todesgefährdet. Verklemmung muss nicht sofort oder immer auftreten, sondern nur
wenn beide Transitionen in der Ausgangslage gleichzeitig (direkt nacheinander) schalten.
Verklemmungen beim Streit um BM können nur auftreten, wenn die 4 notwendigen und
hinreichenden Bedingungen erfüllt sind:
1. die BM sind nur exklusiv nutzbar
2. die BM können nicht entzogen werden
3. die Prozesse geben die erhaltenen BM nicht frei, wenn sie auf die Zuteilung weiterer
BM warten
4. es gibt eine zyklische Kette von Prozessen, von denen jeder mindestens ein BM
besitzt, das der nächste Prozess in der Kette benötigt
27
Bsp. zu 4., zyklischer BM-Graph
BM
Student 2
band1
band2
Student 1
hat band1
und will ihn behalten
will band2
Kein zeitlicher Ablauf, sondern „Schnappschuss“ zu bestimmen Zeitpunkt.
3.6.1. Verklemmungsvermeidung durch Bedarfsangabe
Wunsch: bei der Anforderung vom BM feststellen, ob eine Zuteilung gefahrlos möglich ist
Prozess P2
P2 läuft
P1 bereit
band1
P2 fordert
band2 an
bei Knick
Prozesswechsel
band2
gleichzeitiger Ablauf
Prozess P1
P1 fordert band1 an
P1 läuft, P2 bereit
hier beginnt kritischer Bereich,
da darf man nicht rein, sonst tot
Auch wenn sich die Prozesse schon in einem Zustand befinden, der unweigerlich zu einer
Verklemmung führt, können sie noch ungestört arbeiten. Vorausschauende Prüfung nötig mit
Kenntnissen über die zukünftigen Anforderungen von Prozessen. Schwierig, daher in der
Praxis oft nur Verklemmungserkennung (match dog timer) oder Verklemmungsbeseitigung
durch Prozessabbruch (Rücksetzpunkt sinnvoll).
Verklemmungsvermeidung durch Regeln
Regeln aufstellen, so dass mindestens eine Bedingung 1 … 4 (s.o.) nicht erfüllt ist.
Bsp. Buchausleihe
1. gemeinsame Nutzung erlauben
2. Bücher müssen zurückgegeben werden
3. bei Anforderung eines neuen Buches müssen alle bisherigen geliehenen Bücher
zurückgegeben werden
4. band1 muss immer vor band2 ausgeliehen werden
Regeln sind Problemspezifisch und nicht unproblematisch.
28
3.7. Schlossvariablen
Bisher: Synchronisation durch AWAIT und CRIT Anweisung
Jetzt: Implementation mit Standard-Sprachschnittstellen
3.7.1. Einseitige Synchronisation
AWAIT Bedingung kann ersetzt werden durch:
while not Bedingung repeat
… nichts tun
end repeat
3.7.2. Mehrseitige Synchronisation
Prozesse müssen Zwecks Synchronisation miteinander kommunizieren, z.B. über
gemeinsamen Variablen.
Problem: Schutz vor gemeinsamen Variablen durch gemeinsame Variablen!?
Abstrakt: Schlossvariable S regelt Zugang zu kritischen Abschnitt:
S: lockvar
P: process
S∙lock
… kritischer Abschnitt
S∙unlock
end process
Bsp.
Priester laufen auf schmalen Weg eine Vulkanwand lang, um in den Vulkan Opfergaben
hinein zu werfen. Da es auf dem Weg keine Beleuchtung gibt, können sich zwei aufeinander
zu bewegende Priester umrennen und herunterstürzen. Deshalb muss am Weganfang
sichergestellt werden, dass sich nur ein Priester auf dem Weg befindet.
Implementation (2 Prozesse)
Ausschluss über boolesche Variable. Vor Eintritt gesetzt, nach verlassen gelöscht.
P1
disable
Interrupt
P2
besetzt = true
nein
besetzt = true
P1 im k.A.
ja
besetzt = true
ja
nein
besetzt = true
P2 im k.A.
enable
Interrupt
Problem: Prozesswechsel zwischen Abfragen und Verschließen
● mögliche Abhilfe: spezielle unteilbare Operation (kein Standard-Sprachmittel) oder
Unterbrechung verhindern
→ alternative Ansätze mit Standardoperationen
29
Ansatz 1: zwei boolesche Variablen
Priester schaut vor dem Betreten des Weges, ob ein anderer Priester einen Stein in seine
Schüssel gelegt hat, wenn nicht legt er einen Stein in seine Schüssel. Wenn ja, wartet er.
P1
k.A.
P2
P2
ja
krit2 = true
krit1
krit2
P1
krit1 = true
nein
nein
krit1 = true
krit2 = true
P1 im k.A.
ja
P2 im k.A.
P1 guckt, ob krit2 besetzt. Falls nicht, dann krit1 = true und P1 im kritischen Abschnitt. Falls
ja, dann wartet P1 vor krit2.
Gleiches Problem wie bei der booleschen Variablen: Unterbrechbarkeit zwischen Abfrage
und Verschließen.
Ansatz 2: erst Abschließen, dann Abfragen
Priester legen zuerst Stein in eigene Schüssel und schauen dann in andere Schüssel.
P1
P2
krit1 = true
krit2 = true
krit2 = true
ja
ja
krit1 = true
nein
P1 im k.A.
nein
P2 im k.A.
Problem: Deadlock, falls die jeweils ersten Anweisungen gleichzeitig ausgeführt werden →
beide warten
Ansatz 3: „Besetztzeichen“ beim Warten zurücknehmen
P2
P1
krit2 = true
krit1 = true
krit2 = true
P1 im k.A.
nein
ja
krit1 = true
krit1 = false
warten
krit1 = true
P2 im k.A.
nein
ja
krit2 = false
warten
krit2 = true
30
Bsp. Prozesswechsel (true = 1, false = 0)
P1
P2
krit1 = true
krit2 = true
krit1 krit2
false false
true false
true true
krit2 = true?
krit1 = true?
krit1 = false
false true
krit2 = false false false
warten
warten
krit1 = true
krit2 = true
…
…
true
true
false
true
„Aushungern“ durch „Nach Ihnen“ Problem, z.B.:
- Ausweichen einer Person (rechts – links – rechts …)
- Vortritt bei Tür
- …
Unterschied zwischen Aushungern und Verklemmung:
Aushungern kann sich lösen, Verklemmen nicht
Ansatz 4: Abwechselnder Zutritt
k.A.
ändert nach
Rückkehr
P2 favorit auf 1
favorit
P1
P1
P2
favorit = 2
ja
favorit = 1
nein
nein
P1 im k.A.
P2 im k.A.
favorit = 2
favorit = 1
ja
wartet bis
favorit = 1
Streng abwechselnder Zugriff. Problem wenn Prozesse unterschiedlich häufig. Terminiert
(beenden, nicht mehr ablaufen) ein Prozess, dann wartet der andere ewig.
Ansatz 5: Kombination aus Ansatz 3 und 4
P2 ähnlich wie im folgenden Bild P1, nur mit anderen Variablennamen oder -werten
● 2 Warteschleifen
31
P1
krit1 = true
k.A.
1
krit2 = true
ja
nein
favorit = 1
nein
krit1
favorit krit2
P1 im k.A.
krit1 = false
2
favorit = 2
favorit ≠ 1
krit1 = false
nein
krit1 = true
ja
Bsp. 1
P1
P2
aktiv
aktiv
krit1 krit2 favorit
0
0
1
1
0
1
1
1
1
warten in Schleife 1
aktiv
warten in Schleife 2
in k.A.
fertig
aktiv
k.A.
1
0
1
0
0
2
0
1
2
Bsp. 2
P1
fertig
P2
aktiv
k.A.
fertig
aktiv
(favorit wird nur im Konfliktfall abgefragt)
k.A.
fertig
krit1 krit2 favorit
0
0
2
0
1
2
0
0
1
0
1
1
0
0
1
Kein strenges Abwechseln der Prozesse, häufigere Prozesse können beliebig oft ungehindert
zugreifen, bis anderer Prozess Zugriff verlangt. Aushungern von Ansatz 3 wird durch
Favorisierung vermieden. Favorisierung wechselt gerecht, Prozesse werden gleich behandelt.
Favorisierung nur im Konfliktfall, kein Problem mit unterschiedlichen Häufigkeiten.
Problem: Algorithmus funktioniert nicht mit mehr als 2 Prozessen, enormer Aufwand das zu
ändern
Problem mit Schlossvariablen: aktives Warten (Prozess in Warteschleife muss aktiv den Wert
einer Variablen abfragen)
Abhilfe: OS holt Prozess aus der Warteschleife
32
Semaphore
Sind abstrakte Datentypen, enthalten Zähler und Warteschlange. 2 Operationen auf
Semaphoren:
a) P Operation (passieren) erniedrigt den Wert des Semaphorzählers um 1. Ist der Wert
negativ, wird der die Operation ausführende Prozess in die Warteschlange des
Semaphors eingeordnet und blockiert.
b) V Operation (freigeben) erhöht den Zähler um 1. Falls Warteschlange nicht leer
(Zähler ≤ 0), wird Prozess an erster Stelle der Warteschlange bereit gestellt.
Beide Operationen werden vom OS ausgeführt.
Aktion Prozess
P(S)
P Operation auf Semaphor S als
Eintrittsprotokoll
Aktion OS
S=S–1
ist S < 0?
nein: Prozess darf in k.A.
ja: Prozess in Warteschlange von S
nein: S ≥ 0
Prozess im k.A.
t
↓
fertig
V(S)
V Operation auf Semaphor S als
Austrittprotokoll
S=S+1
ist S ≤ 0?
nein: Warteschlange leer, nichts zu tun
ja: Prozess an erster Stelle der
Warteschlange bereit stellen
Bsp. Flugzeug, 3 (Initialwert) Toiletten (k.A.), 5 Reisende (Prozesse R1 bis R5)
R1 R2 R3 R4 R 5
P
P
P
t
V
↓
P
P
P
V
V
S
k.A.
3
2
1
0
1
0
-1
-2
-1
0
R1
R1, R2
R1, R2, R4
R1, R4
R1, R3, R4
R1, R3, R4
R1, R3, R4
R3, R4, R5
R3, R5, R2
Warteschleife
(Reihenfolge wichtig)
R5
R5, R2
R2
33
bereit
laufend
blockiert an
Semaphor S1
blockiert an
Semaphor Sn
Bsp.: erstes Leser und Schreiber Problem (Leser haben Priorität)
Synchronisation soll mit Semaphoren gelöst werden:
- Leser soll Priorität haben
- Zahl der Leser im k.A. durch Variable l_zähler dargestellt
- Blockieren eines Schreibers durch Semaphor ls_ausschluss (Initialwert = 1) sobald
mindestens ein Leser oder Schreiber im k.A., Blockieren der Leser sobald ein
Schreiber im k.A.
- gleichzeitiger Zugriff zweier Leser auf l_zähler kritisch, daher Schutz durch Semaphor
lz_schutz (Initialwert = 1)
ls_ausschluss, lz_schutz : Semaphor(1); //in Klammern der Initialwert
l_zähler : integer = 0;
lz_schutz • P
Leser
l_zähler = l_zähler + 1
ja
l_zähler = 1?
ls_ausschluss • P
nein
lz_schutz • V
Leser im k.A.
lz_schutz • P
l_zähler = l_zähler - 1
ja
l_zähler = 0?
ls_ausschluss • V
nein
lz_schutz • V
34
Schreiber
ls_ausschluss • P
Leser im k.A.
ls_ausschluss • V
Bsp. 2 Leser, 1 Schreiber
L1
L2
S
lz_schutz
l_zähler
ls_ausschluss
1
0
1
aktiv
0
0
1
aktiv
-1 (blockiert L2)
0
1
aktiv
-1
1
0
k.A.
0 (Freigabe von L2)
1
0
aktiv
0
2
0
k.A.
1
2
0
aktiv
1
2
-1 (blockiert S)
aktiv
0
2
-1
Austritt
0
1
-1
1
1
-1
aktiv
0
1
-1
Austritt
0
0
0 (Freigabe von S)
1
0
0
aktiv
1
0
0
Schreiben
1
0
0
Blockiert Schreiber, kann jederzeit von neuen Lesern überholt werden. Gefahr des
Aushungerns der Schreiber.
Bsp.: zweites Leser-Schreiber Problem
Schreiber haben Priorität, sollen so schnell wie möglich in kritischen Abschnitt. Leser im k.A.
dürfen Arbeit noch beenden. Neue Leser müssen nach Anmeldung des Schreibers warten bis
Schreiber fertig ist.
Idee: neuer Semaphor, der die Leser aufhält: l_halt
Leser
Schreiber (grob)
l_halt • P
1. Schreiber → l_halt • P
erster Teil des
bisherigen Algorithmus
ls_ausschluss • P
k.A.
l_halt • V
ls_ausschluss • V
k.A.
letzter Schreiber → l_halt • V
restlicher Teil des
bisherigen Algorithmus
nötig: Schreibzähler und Semaphor,
der Schreibzähler schützt
35
Schreiber:
sz_schutz • P
s_zähler = s_zähler + 1
ja
l_zähler = 1?
l_halt • P
nein
sz_schutz • V
ls_ausschluss • P
k.A.
Austrittsprotokoll entsprechend (wie bei Leseprozess, letzter Schreiber → l_halt • V)
L1
L2
L3
S
l_halt
Warteschlange
von l_halt
1
aktiv (dekrementiert
ls_ausschluss)
k.A.
0
1
0
1
aktiv
k.A.
aktiv (wartet an
ls_ausschluss)
aktiv
(wartet an
l_halt)
fertig
aktiv
(wartet an
l_halt)
0
-1
L3
-1
L3
-2
L3, L2
-1
0
-1
-1
L3, L2
L2
L2, S
fertig (letzter Leser
gibt ls_ausschluss
frei)
k.A.
fertig
k.A.
aktiv
fertig
Schreiber muss sich wie die Leser in die Warteschlange von l_halt einreihen, wenn l_halt ≤ 0.
noch ein Semaphor: l_vorhalt inklusive Warteschlange
(Schreiber kümmert sich nicht um l_vorhalt)
36
Weiterer Semaphor nötig, weil höchstens ein Leser am Semaphor
l_halt wartet. Erster Schreiber, der l_halt blockieren will, kann
weitere Leser, die bei l_vorhalt warten überholen.
Leser
l_vorhalt • P
l_halt • P
Durch l_vorhalt höchstens ein Leser in Warteschlange von l_halt
vor wartenden Schreiber.
bisheriger Algorithmus
l_halt • V
l_vorhalt • V
k.A.
l_vorhalt
l_halt
ls_ausschluss
k.A.
Schutzhüllen/
Warteschlangen
37
4.
What really happened on Mars?
Mars Pathfinder Mission, Landung am 4.7.1997, Sojourner Rouver. Nach einigen Tagen
Probleme mit Systemresets, die zu Datenverlusten führten. Single CPU, VxWorks als realtime embedded System Kernel der Fa. Wind River Systems. Versuche an der 1:1 Kopie im
Labor (JPL) den Fehler zu reproduzieren → Erfolg nach 18h.
Was war der Fehler?
Verschiedene Tasks:
frequent,
high priority
infrequent,
low priority
very infrequent,
medium priority
Bus management
task
Meteorological
data gathering task
Communication
task
Task A
Task C
Task B
Information Bus
Zugriffssteuerung durch „Mutex“ (Mutal Exclusion Locks) = Semaphore (1 = erste Ordnung)
Soll-Verlauf
A und C Zugriff per Mutex auf gemeinsame Ressource
(kritischer Abschnitt).
priority
A
B greift nicht auf Ressource über Mutex zu, hat aber höhere
Priorität als C.
B
C
t
Ist-Verlauf ohne B
C
A
t
Normaler Fall, ist zu erwarten.
A wartet auf Ressource, C kann nicht unterbrochen werden,
weil es gemeinsame Ressourcen nutzt wie A.
Ist-Verlauf mit B
priority inversion
C
B
C
an der Stelle meldete Watchdogtimer
immer: A nicht beendet
A
t
B kann unterbrechen, weil es höhere Priorität hat und nicht Information Bus nutzt. Weil Task
A so lange für Abarbeitung braucht, denkt OS, er wäre hängen geblieben → Reset.
38
Lösungsmöglichkeiten
a) Priority Inheritance
Task mit niedriger Priorität „erbt“ die Priorität eines Tasks, der Zugriff verlangt.
A
C mit Priorität von A
C
t
b) Priority Ceiling
Jede Ressource bekommt die Priorität des höchsten Tasks + 1, der auf die Ressource
zugreifen will. Jeder Task, der auf die Ressource zugreift, bekommt für diese Zeit die Priorität
der Ressource.
39