Post on 14-Jun-2020
Seite 1
DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Okt 2017
7) Task-Synchronisation
Inhalt
• Sperrsynchronisation (Mutex)
• Reihenfolgensynchronisation
• Semaphore
• Verklemmungen
• Deadlocks
• Livelocks
• Prioritäteninversion
• Prioritätenvererbung
Weitere Beispiele für die Semaphore-Operationen
REQ und REL:
Seite 2
DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Okt 2017
7) Task-Synchronisation
Kritischer Bereich
• Synchronisation ist notwendig, wenn Tasks abhängig voreinander sind, weil sie
gemeinsame Betriebsmittel benutzen, wie z.B. Daten, Geräte oder Programme.
• 2 grundlegende Varianten der Synchronisation:
• Sperrsynchronisation (wechselseitiger Ausschluss, Mutual Exclude (Mutex))
stellt sicher, dass zu einem Zeitpunkt immer nur eine Task auf ein gemeinsames
Betriebsmittel zugreift.
• Reihenfolgensynchronisation regelt die Reihenfolge auf gemeinsame
Betriebsmittel
• Bereiche, in denen Tasks synchronisiert werden müssen, heißen kritische Bereiche.
• Busy-Waiting ist das Hauptproblem der Software-Lösungen und der Hardware-
unterstützten Lösungen zur Durchsetzung des wechselseitigen Ausschlusses.
• Gesucht werden daher Synchronisationsmechanismen, die Busy-Waiting verhindern.
Dies ist nur auf Betriebssystemebene möglich, da dort Prozesse blockiert und wieder
auf bereit gesetzt werden können..
Seite 3
DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Okt 2017
7) Task-Synchronisation
Semaphore als Lösung
Einführung einer Semaphore, die aus:
– einer Zählvariablen (Warteschlange) und aus
– zwei nicht unterbrechbaren (atomaren)
Operationen P(S) und V(S) besteht.
s := s-1;
if (s < 0)
then „Ordne Prozess an
Position –s der
Assoziierten
Warteschlange ein“;
s := s+1;
if (s <= 0)
then „Wecke den ältesten
Wartenden Prozess und
sende ihn in den
kritischen Bereich“;
Notationen:
P(S) = passeeren = Verringern um den Wert 1:
Request, wait, down, aquire, …
V(S) = vrijgeven = Erhöhen um den Wert 1:
Release, up, signal, …
Seite 4
DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Okt 2017
7) Task-Synchronisation
Semaphore zur Synchronisation
• Bei Standardbetriebssystemen: Bereitmachen einer beliebigen wartenden Task bei V
• Bei Echtzeitbetriebssystemen: Bereitmachen der höchstprioren wartenden Task bei V
Task blockieren
Zähler := Zähler - 1
Zähler<0 ?
Request
eine blockierte Task
bereit machen
Zähler := Zähler + 1
Zähler<1 ?
Release
ja ja
Seite 5
DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Okt 2017
7) Task-Synchronisation
Semaphore zur Synchronisation
• Lösung des wechselseitigen
Ausschlusses mit einem
binären Semaphore
• Begriff binärer Semaphor
resultiert daraus, dass es
nur zwei Zustände gibt.
Da es nur darauf ankommt, ob
kritischer Bereich frei ist oder
nicht, sind andere Werte
(negative oder größer 1)
nicht nötig:
– S = 1, wenn kritischer
Bereich frei ist,
– S = 0, wenn kritischer
Bereich belegt ist.
Initialisiere
Semaphore S = 1
REQ S
REL S
Zugriff auf
geschützte
Betriebsmittel
REQ S
REL S
Task 1 Task 2
Task 2
blockiert
Task 2 freigegeben
Zugriff auf
geschützte
Betriebsmittel
Seite 6
DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Okt 2017
7) Task-Synchronisation
Semaphore zur Synchronisation
• Reihenfolge-Synchronisation
mit zwei binären Semaphoren
• Anfangswert = 1 garantiert,
dass dieser Prozess als
Erster beginnt
Initialisiere
Semaphore S1=0
Task 1 Task 2
Task 1
blockiert
Task 1 freigegeben
Aktivität Task 2
Aktivität Task 1
Aktivität Task 2
Task 2
blockiert
Task 1
blockiert
Task 2 freigegeben
Task 1 freigegeben
Initialisiere
Semaphore S2=1
REQ S1 REQ S2
REL S1
REL S2
REQ S2
REQ S1
REL S1
Seite 7
DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Okt 2017
7) Task-Synchronisation
Semaphore zur Synchronisation
• Erzeuger-/Verbraucher
Synchronisation mit zwei
Zählsemaphoren (Zähler > 1):
• Svoll: erzeugte Objekte
für Verbraucher und
• Sleer: Freie Plätze für
Objekte des Erzeugers
• Svoll = 0 bedeutet
Lager ist leer (Aus einem
leeren Lager kann nichts entnommen
werden)
• Sleer = 0 bedeutet
Lager ist voll (In ein
volles Lager kann nichts
deponiert werden)
• Sleer+Svoll ist invariant.
• Zusätzlich ist beim Erzeugen
und Verbrauchen noch ein MUTEX
zu implementieren
Initialisiere
Semaphore
Sleer = n
REQ Sleer
Task "Erzeuger" Task "Verbraucher"
Erzeuge Objekt
REL Svoll
Initialisiere
Semaphore
Svoll = 0
REQ Svoll
Verbrauche Objekt
REL Sleer
Seite 8
DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Okt 2017
7) Task-Synchronisation
Semaphore zur Synchronisation
Reader-Writer-Problem:
• Writer sind Prozesse, die schreiben dürfen, Reader Prozesse, die Anfragen stellen
• 1 Schreiber, n Leser
• Es dürfen mehrere Leser gleichzeitig auf den Daten lesen.
• Wenn der Schreiber auf den Daten schreibt, darf kein Leser lesen.
• Wenn ein Leser liest, darf der Schreiber nicht schreiben (in seinen kritischen Abschnitt eintreten).
• Schreiber hat Priorität, d.h. wenn der Schreiber in seinen kritischen Abschnitt eintreten will, darf
kein Leser vor ihm mehr in seinen kritischen Abschnitt eintreten.
1. Reader-Writer-Problem: Kein Reader muss auf eine Eintrittserlaubnis warten; es sei denn, ein Writer
befindet sich im kritischen Bereich. Problem: Reader können das System monopolisieren, und
Writer kommt nicht dazu, sein Update durchzuführen -> Verklemmung (starvation) bezüglich
Writer.
2. Reader-Writer-Problem: Sobald ein Writer wartet, wird neuen Readern der Zugang verwehrt. Die
Writer können das System monopolisieren.
3. Reader-Writer-Problem: Fairness durch alternierende Lese- und Schreibphasen: Ist gerade
Lesephase und meldet sich ein Writer an, werden keine neuen Reader mehr zugelassen. Sobald
alle Reader fertig sind, darf der Writer zugreifen. Ist gerade eine Schreibphase und meldet sich
ein Reader an, wird das Ende dieser Schreibphase abgewartet und dann eine Lesephase
gestartet.
Seite 9
DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Okt 2017
7) Task-Synchronisation
Semaphore zur Synchronisation
Lösung für das 1. Reader-Writer-Problem:
• Semaphore s für die Schreib- und w für die Lesephase
• Variable n zählt Anzahl der gleichzeitig aktiven Leser
• Funktionen:
– Semaphore s wird mit 1 initialisiert und
wird sowohl von Reader- als auch von
Writerprozessen verwendet, um Writern
einen exklusiven Zugriff zu ermöglichen.
– Semaphor w stellt sicher, dass ein Update
von n ungestört erfolgen kann.
Writerprozess
Readerprozess
wait() entspr. REQ
signal() entspr. REL
Seite 10
DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Okt 2017
7) Task-Synchronisation
Übung zum wechselseitigen Ausschluss: Zwei Task A und B (mit absteigender Priorität,
A hat die höchste) benutzen exklusiv zwei gemeinsame Speicherbereiche, die jeweils
durch eine Semaphore geschützt werden (gestr. Linie = Programmcode, nT =
Ausführungsdauer).
Tragen Sie den zeitlichen Verlauf
mit den entsprechenden
Taskzuständen (blockiert = wartet
auf Sema, ablaufwillig = durch
höhere Prio verdrängt) der zwei
Tasks im Bereich 0<=t<=20T ein,
wobei sie zwei Fälle unterscheiden:
• Fall 1: Task A wird bei T=5t und B
bei T=0t gestartet
• Fall 2: Task A wird bei T=2t und B
bei T=0t gestartet
Die zwei Semaphore S1 und S2
sind mit 1 initialisiert.
Task B (Prio 2)
T
REQ S1
REL S1
END
2T
T
REQ S2
3T
REL S2
2T
Task A (Prio 1)
T
REQ S2
REL S2
END
2T
T
REQ S1
3T
REL S1
2T
Seite 11
DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Okt 2017
7) Task-Synchronisation
Übung: Formular zum Zeichnen der Soll-Abläufe
105 15 20
ablaufwillig
blockiert
laufend
ablaufwillig
blockiert
laufend
Task A
Task B
Seite 12
DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Okt 2017
7) Task-Synchronisation
Verklemmungen
2 Arten
• Deadlocks (Blockierung, Deadly Embrace): mehrere auf die Freigabe von
Betriebsmittel wartende Tasks blockieren sich gegenseitig
– Deadlocks entstehen, wenn falsch programmiert wurde oder
– wenn die Reihenfolge der REQ/REL-Anweisungen falsch gewählt wurde
• Livelocks (Starvation, Aus-/Verhungern): eine Task wird durch andere Tasks ständig
an der Ausführung gehindert.
– Beispiel: eine hochpriore Task verhindert ständig die Ausführung einer
niederprioren Task
– Auch hochpriore Tasks können „Opfer“ von Livelocks werden, Problem der
Prioritäteninversion
Seite 13
DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Okt 2017
7) Task-Synchronisation
Verklemmungen
• Beispiel 1: Deadlock durch kreuzweise Betriebsmittelbelegung
• Ablauf: Task 1: REQ SD; Task 2: REQ ST; Task 2: REQ SD; Task 2: blockiert;
Task 1: REQ ST; Task 1: blockiert.
• Gegenmaßnahme: Vergabe der Betriebsmittel in gleicher Reihenfolge
REQ S(DruckTab)
REQ S(TempTab)
DruckTab schreiben
TempTab schreiben
REL S(DruckTab)
REL S(TempTab)
REQ S(TempTab)
REQ S(DruckTab)
TempTab lesen
DruckTab lesen
REL S(TempTab)
REL S(DruckTab)
Tabellen drucken
Task 1 Task 2
Seite 14
DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Okt 2017
7) Task-Synchronisation
Verklemmungen
• 2 Lösungen für die kreuzweise Betriebsmittelbelegung:
• Task 11 mit Task 2
• Task 12 mit Task 2
REQ S(DruckTab)
DruckTab schreiben
REL S(DruckTab)
REQ S(TempTab)
TempTab schreiben
REL S(TempTab)
REQ S(TempTab)
REQ S(DruckTab)
TempTab lesen
DruckTab lesen
REL S(TempTab)
REL S(DruckTab)
Tabellen drucken
Task 11
Task 2
REQ S(TempTab)
REQ S(DruckTab)
DruckTab schreiben
TempTab schreiben
REL S(DruckTab)
REL S(TempTab)
Task 12
Seite 15
DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Okt 2017
7) Task-Synchronisation
Verklemmungen
• Beispiel 2: Deadlock durch
Programmierfehler
• Gegenmaßnahme: höhere
Synchronisationskonstrukte
(z.B. Monitore)
Initialisiere
Semaphore S = 1
REQ S
REQ S
Zugriff auf
geschützte
Betriebsmittel
REQ S
REL S
Task 1 Task 2
Zugriff auf
geschützte
Betriebsmittel
Seite 16
DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Okt 2017
7) Task-Synchronisation
Verklemmungen
• Beispiel 3: Deadlock durch Programmierfehler (Erzeuger/Verbraucher-Problem)
• Wie ist der Programmierfehler zu beheben?
While (true) {
REQ SWait;
REQ SFree;
/*erzeuge Produkt*/
REL SWait;
REL SProd; }
Erzeuger
While (true) {
REQ SProd;
REQ SWait;
/*verbrauche Produkt*/
REL SWait;
REL SFree; }
Initialisierung:
SWait = 1
SFree = 2
SProd = 0
Verbraucher
Seite 17
DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Okt 2017
7) Task-Synchronisation
Verklemmungen
• Beispiel 3: Deadlock durch Programmierfehler (Erzeuger/Verbraucher-Problem)
• Ablauf:
Erzeuger: REQ SWait;
SWait=0 SProd=0 SFree=2
Erzeuger: REQ SFree;
SWait=0 SProd=0 SFree=1
Erzeuger: REL SWait;
SWait=1 SProd=0 SFree=1
SWait=1 SProd=1 SFree=1
Erzeuger: REL SProd;
Erzeuger: REQ SWait;
SWait=0 SProd=1 SFree=1
Erzeuger: REQ SFree;
SWait=0 SProd=1 SFree=0
Erzeuger: REL SWait;
SWait=1 SProd=1 SFree=0
Erzeuger: REL SProd;
SWait=1 SProd=2 SFree=0
SWait=0 SProd=2 SFree=0
Erzeuger: REQ SWait;
Erzeuger: REQ SFree;
SWait=0 SProd=2 SFree=-1
Erzeuger: ist blockiert
Verbraucher: REQ SProd;
SWait=0 SProd=1 SFree=-1
Verbraucher: REQ SWait;
SWait=-1 SProd=1 Free=-1
Verbraucher: ist blockiert
Seite 18
DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Okt 2017
7) Task-Synchronisation
Verklemmungen
• Beispiel 4: Deadlock durch ungünstigen Speicherzugriff
• Annahme: Speicherverfügbarkeit = 200 kB
• Verklemmung, wenn sich beide Tasks zwischen der ersten und zweiten
Speicheranforderung befinden, da nur noch 50 kB verfügbar sind.
• Gegenmaßnahme: Virtueller Speicher
…
80 kB
…
60 kB
…
Task 1 Task 2
…
70 kB
…
90 kB
…
Seite 19
DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Okt 2017
7) Task-Synchronisation
Verklemmungen (Prioritäteninversion)
Task 1
hohe
Priorität
Task 2
niedere
PrioritätMutex
Task 2
Task 1
Ereignis
für Task 1
Ruhe
Ereignis
für Task 2
Zeit
Task 2 belegt
Mutex
Task 1 versucht,
Mutex zu belegen,
wird blockiert
Task 2 gibt
Mutex frei
Prioritäteninversion
Seite 20
DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Okt 2017
7) Task-Synchronisation
Verklemmungen (Prioritäteninversion)
Livelock Task 1
hohe
Priorität
Task 3
niedere
PrioritätMutex
Task 2
Task 1
Ereignis
für Task 1
Ruhe
Ereignis
für Task 3
Zeit
Livelock, Task 1 ist
längerfristig blockiert Task 3
Ereignis
für Task 2
Task 3 belegt
Mutex
Task 1 versucht,
Mutex zu belegen,
wird blockiert
Task 2
mittlere
Priorität
Seite 21
DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Okt 2017
7) Task-Synchronisation
Vermeidung von Deadlocks
2 Klassen von Methoden zur Deadlockverhinderung (Deadlock Prevention)
• Indirekte Methoden (Erfüllung von 3 Bedingungen für den Eintritt eines Deadlocks):
• 1. Bedingung: Mutual Exclusion, d.h. mind. 2 Prozesse und 2 Betriebsmittel
• 2. Bedingung: Hold and Wait, d.h. ein Prozess muß ein Betriebsmittel behalten, während er
auf ein weiteres Betriebsmittel wartet
• 3. Bedingung: No Preemption, d.h. ein Betriebsmittel kann einem Prozess, der sie behält,
nicht wieder entzogen werden.
• Direkte Methoden (Betrachtung der genauen Deadlock-Situation):
• Circular Wait, d.h. es existiert eine geschlossene Kette von Prozessen, so dass jeder
Prozess mindestens ein Betriebsmittel behält, das von einem anderen Prozess der Kette
gebraucht wird.
Betriebsmittel A
Betriebsmittel B
Prozess 2Prozess 1
fordert an
fordert an
belegt von
belegt von
Seite 22
DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Okt 2017
7) Task-Synchronisation
Vermeidung von Verklemmungen durch Prioritätenvererbung
• Vermeidung des Livelocks
Task 2
Task 1
Ereignis
für Task 1
Ruhe
Ereignis
für Task 3
Zeit
Prioritätenvererbung,
Task 3 erhält die
Priorität von Task 1
(daher keine Unter-
brechung durch Task 2)
Task 3
Ereignis
für Task 2
Task 3 belegt
Mutex
Task 1 versucht,
Mutex zu belegen,
wird blockiert
Task 1 ist
fertig
Task 3 gibt
Mutex frei
Seite 23
DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Okt 2017
7) Task-Synchronisation
Beispiel für Deadlock-Prevention (die höchstpriore Task kommt am spätesten)
Im Programmablauf bedeutet:
• E = Anweisung
• Q = Zugriff auf Ressource Q
• V = Zugriff auf Ressource V
Übung: Stellen Sie den zeitlichen Ablauf der vier Tasks zwischen 0 und 18 T dar:
a) Ohne Präemption während MUTEX-Belegung
b) Mit Präemption (Prioritätsinversion)
c) Mit Prioritätsvererbung (priority inheritance)
Taskzustände: E = ablaufend
EQ = ablaufend mit Zugriff auf Q
EV = ablaufend mit Zugriff auf V
B = blockiert
Task Ankunftszeit Programmablauf 1/T Prio
a 4 T E E Q V E 1 (hoch)
b 2 T E V V E 2
c 2 T E E 3
d 0 T E Q Q Q Q E 4
Seite 24
DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Okt 2017
7) Task-Synchronisation
Zeitlicher Ablauf
ohne Präemption während
MUTX-Belegung:
Tasks in einem MUTEX
werden nicht unterbrochen
Task Ankunftszeit Programmablauf 1/T Prio
a 4 T E E Q V E 1 (hoch)
b 2 T E V V E 2
c 2 T E E 3
d 0 T E Q Q Q Q E 4
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
A E E EQ EV
B
C
D E EQ EQ EQ EQ
Taskzustände: E = ablaufend
EQ = ablaufend mit Zugriff auf Q
EV = ablaufend mit Zugriff auf V
Seite 25
DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Okt 2017
7) Task-Synchronisation
Zeitlicher Ablauf
Mit Präemption
(Prioritäteninversion)
Task Ankunftszeit Programmablauf 1/T Prio
a 4 T E E Q V E 1 (hoch)
b 2 T E V V E 2
c 2 T E E 3
d 0 T E Q Q Q Q E 4
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
A
B
C
D E EQ
Taskzustände: E = ablaufend
EQ = ablaufend mit Zugriff auf Q
EV = ablaufend mit Zugriff auf V
B = blockiert
Seite 26
DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Okt 2017
7) Task-Synchronisation
Zeitlicher Ablauf
Mit Prioritätenvererbung
Task Ankunftszeit Programmablauf 1/T Prio
a 4 T E E Q V E 1 (hoch)
b 2 T E V V E 2
c 2 T E E 3
d 0 T E Q Q Q Q E 4
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
A
B
C
D E EQ
Taskzustände: E = ablaufend
EQ = ablaufend mit Zugriff auf Q
EV = ablaufend mit Zugriff auf V
B = blockiert
Seite 27
DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Okt 2017
7) Task-Synchronisation
Task 1
hohe
Priorität
Mutex 1
Deadlocks entstehen auch dadurch, dass
sich Tasks gegenseitig blockieren, wenn sie
auf mehrere kritische Bereiche zugreifen
müssen (s. Übung Seite 10); jeder kritische
Bereich wird dabei durch eine Semaphore
geschützt.
Task 2
niedere
Priorität
Mutex 2
Regel:
Möchte ein Prozess eine Ressource nutzen, so wird zuerst geprüft, ob diese verfügbar ist: ist die
Ressource bereits vergeben, so wird die Anforderung verweigert und der Prozess blockiert an dieser
Ressource, ist die Ressource verfügbar, so wird die aktuelle Prioritätsschranke des Systems geprüft: hat
der Prozess eine höhere Priorität als die aktuelle Prioritätsschranke, so bekommt er die Ressource
zugeteilt, hat er keine höhere Priorität, so bekommt er die Ressource nur dann, wenn er schon die
Ressource, die die aktuelle Prioritätsschranke des Systems begründet, besitzt. Ansonsten wird ihm die
Ressource verweigert.
Blockiert ein Prozess an einer Ressource, so erbt der Prozess, der diese Ressource momentan besitzt,
die (höhere) Priorität des anfragenden Prozesses. Der Prozess, der die Ressource schon besitzt, wird
nun unter dieser Priorität weiterverarbeitet, bis er alle Ressourcen freigegeben hat, deren
Prioritätsschranke größer oder gleich der geerbten Priorität ist.
Vermeidung von Verklemmungen durch Prioritätenvererbung
• Vermeidung durch das priority ceiling protocol (Prioritätsobergrenze)
Seite 28
DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Okt 2017
7) Task-Synchronisation
Gegenseitiges Blockieren beim Zugriff auf kritische Bereiche
Soll-Ablauf ohne priority ceiling protocol (pcp)
105 15 20
ablaufwillig
blockiert
laufend
ablaufwillig
blockiert
laufend
Task A
Task B
REQ S1
REQ S2 REQ S1
REQ S2
Seite 29
DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Okt 2017
105 15 20
ablaufwillig
blockiert
laufend
ablaufwillig
blockiert
laufend
Task A
Task B
REQ S1
REQ S2
REL S2
REL S1REQ S2
REL S1 REL S2REQ S1
Hier blockiert Task A
und Task B
bekommt die Prio 1
Hier hat Task B alle
Ressourcen
freigegeben und gibt
damit die Prio zurück.
Kein gegenseitiges Blockieren beim Zugriff auf kritische Bereiche
Soll-Ablauf mit priority ceiling protocol (pcp)
7) Task-Synchronisation
Seite 30
DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Okt 2017
7) Task-Synchronisation
Übung für Task-Reihenfolge:
Vorgegeben sind die Anordnung von Semaphor-Anweisungen am Anfang und am Ende dreier
Tasks A, B und C.
In der folgenden Tabelle sind die Anfangswerte für die drei Semaphor-Variablen S1, S2 und S3
eingetragen. Ermitteln Sie für die 4 Fälle a), b), c) und d) der Tabelle, ob und in welcher
Reihenfolge diese Tasks bei der angegebenen Initialisierung der Semaphor-Variablen
ablaufen.
REQ S1
REQ S1
REQ S1
Task A
REL S2
REQ S2
Task B
REL S3
REL S1
REQ S3
REQ S3
REQ S3
Task C
REL S2
REL S2
Fall a) b) c) d)
S1 2 3 2 0
S2 0 0 1 0
S3 2 2 1 3
Seite 31
DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Okt 2017
7) Task-Synchronisation
S1 S2 S3 Ablauffähige
Task
Bemerkungen
a) 3
0
0
1
2
2
A
B
Reihenfolge:
b) 2 0 2 Reihenfolge:
c) 2 1 1 Reihenfolge:
d) 0 0 3 Reihenfolge:
Formular für die Lösung
Seite 32
DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Okt 2017
7) Task-Synchronisation
Kritischer Bereich (Betriebssystem-unterstützte Lösungen)
Semaphore sind eine „low-level“-Lösung, die erhebliche Disziplin vom Programmierer
verlangt. Eine komfortablere Lösung bieten Monitore.
• Ein Monitor ist eine Sammlung von Prozeduren, Variablen und Datenstrukturen (mit
einer assoziierten Warteschlange).
• Prozesse können die Prozeduren des Monitors aufrufen, aber keine internen Daten
ändern.
• Monitore besitzen die Eigenschaft,
dass immer nur genau ein Prozess
einen Monitor benutzen kann.
• Monitore sind Konstrukte einer
Programmiersprache und erfordern
daher spezielle Compiler,
die Maschinenbefehle generieren,
die z.B. den wechselseitigen Ausschluss
im Monitor garantieren
(nicht mehr der Programmierer).
Seite 33
DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Okt 2017
7) Task-Synchronisation
Kritischer Bereich (Monitore)
• Die Abarbeitung von Monitorprozeduren wird von Zustandsvariablen (condition
variables) abhängig gemacht, auf die zwei Operationen wirken
– wait(cond) veranlasst einen Prozess, sich schlafen zu legen, d.h. sich an das
Ende der assoziierten Warteschlange einzureihen. (ähnlich REQ)
– signal(cond) weckt den ältesten Prozess in der Warteschlange. (ähnlich REL)
• Unterschied zu Semaphor: signal hat keine Wirkung, wenn zum Zeitpunkt des
Absendens kein Prozess wartet, d.h. sie gehen verloren.
• Mit anderen Worten: signal(cond) signalisiert das Eintreffen der Bedingung cond und
wait(cond) realisiert das Warten von Prozessen aufgrund des Nichterfülltseins von
cond.
• Da sich immer nur ein Prozess im Monitor befindet, werden die wait und signal-
Operationen atomar ausgeführt.
Seite 34
DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Okt 2017
7) Task-Synchronisation
Kritischer Bereich (Monitore)
• Beispiel:
Seite 35
DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Okt 2017
7) Task-Synchronisation
Kritischer Bereich (Monitore)
• Problem: Was passiert, wenn Prozess A während Monitorbenutzung ein Signal setzt,
auf das ein anderer Prozess B wartet, d.h. nach der signal-Operation können sich
zwei Prozesse im Monitor befinden?
• 3 Lösungen sind möglich:
– 1. Lösung (Brinch Hansen): Die signal-Operation ist immer die letzte Operation
eines Prozesses im Monitor, d.h. die Operation wird abgeschlossen, bevor ein
anderer Prozess erweckt wird.
– 2. Lösung (Hoare): Der Signalgeber-Prozess wird gesperrt, bis der erweckte
Prozess den Monitor verlassen hat.
– 3. Lösung: Der Prozess wird erst erweckt, nachdem der Signalgeber-Prozess
den Monitor verlassen hat.
• Kein Königsweg: Die verwendete Semantik muss explizit festgelegt werden; Beste
Lösung: signal-Operation immer ans Ende einer Monitorprozedur setzen.
Seite 36
DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Okt 2017
7) Task-Synchronisation
Kritischer Bereich (Monitore)
• Erzeuger/Verbraucher-Problem:
Seite 37
DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Okt 2017
7) Task-Synchronisation
Kritischer Bereich (Monitore)
• 3. Reader-Writer-Problem:
ankommender Reader
erhält Priorität vor später
ankommenden Writern
und umgekehrt.
Seite 38
DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Okt 2017
7) Task-Synchronisation
Kritischer Bereich (Monitore)
• 3. Reader-Writer-Problem
Seite 39
DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Okt 2017
7) Task-Synchronisation
Kritischer Bereich (Monitore)
• 3. Reader-Writer-Problem
Seite 40
DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Okt 2017
7) Task-Synchronisation
Kritischer Bereich (Monitore)
• Ablaufbeispiel für das 3. Reader-Writer-Problem
Seite 41
DHBW Stuttgart, Studiengang Elektrotechnik, 5. HJ, Vorlesung: Realzeitsysteme Okt 2017
7) Task-Synchronisation
Kritischer Bereich (Monitore)
• Ablaufbeispiel für das 3. Reader-Writer-Problem