7) task-synchronisation - dhbw stuttgartrie/rzs/vorlesung/realzeitvorlesungk… · 7)...

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



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



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



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




• 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




• 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




• 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




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




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



Ü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



Übung: Formular zum Zeichnen der Soll-Abläufe

105 15 20

ablaufwillig

blockiert

laufend

ablaufwillig

blockiert

laufend

Task A

Task B

Seite 12



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



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



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



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



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



Verklemmungen

• Beispiel 3: Deadlock durch Programmierfehler (Erzeuger/Verbraucher-Problem)

• Ablauf:

Erzeuger: REQ SWait;

SWait=0 SProd=0 SFree=2

Erzeuger: REQ SFree;


Erzeuger: REL SWait;



Erzeuger: REL SProd;





Erzeuger: REL SWait;


Erzeuger: REL SProd;





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



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



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



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



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



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



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



Zeitlicher Ablauf

ohne Präemption während

MUTX-Belegung:

Tasks in einem MUTEX

werden nicht unterbrochen



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




Seite 25



Zeitlicher Ablauf

Mit Präemption

(Prioritäteninversion)



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




B = blockiert

Seite 26



Zeitlicher Ablauf

Mit Prioritätenvererbung



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




B = blockiert

Seite 27



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



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


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)


Seite 30



Ü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



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



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



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




• Beispiel:

Seite 35




• 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




• Erzeuger/Verbraucher-Problem:

Seite 37




• 3. Reader-Writer-Problem:

ankommender Reader

erhält Priorität vor später

ankommenden Writern

und umgekehrt.

Seite 38




• 3. Reader-Writer-Problem

Seite 39




• 3. Reader-Writer-Problem

Seite 40




• Ablaufbeispiel für das 3. Reader-Writer-Problem

Seite 41




• Ablaufbeispiel für das 3. Reader-Writer-Problem

7) task-synchronisation - dhbw stuttgartrie/rzs/vorlesung/realzeitvorlesungk… · 7)...

Documents