ZugriffaufmehrereRessourcen NebenläufigenProgrammierung

(1)

Prinzipien, Modelle und Algorithmen der

Nebenl¨ aufigen Programmierung

Wintersemester 2019/20

Zugriff auf mehrere Ressourcen

Prof. Dr. David Sabel

LFE Theoretische Informatik

Letzte ¨Anderung der Folien: 10. Dezember 2019

(2)

Ubersicht ¨

1 Deadlocks bei mehreren Ressourcen Einleitung

Deadlock-Verhinderung Deadlock-Vermeidung

2 Transactional Memory Einleitung

ACID-Eigenschaften Operationen

Merkmale

TCS | 08 Mehrere Ressourcen | WS 2019/20 2/96 Deadlocks bei mehreren Ressourcen Transactional Memory

(3)

Deadlocks bei mehreren Ressourcen

Deadlock beim Mutual-Exclusion Problem

Deadlock: Kein Prozess kommt in den kritischen Abschnitt, obwohl mindestens ein Prozess in den kritischen Abschnitt m¨ ochte

Kommt dem Belegen einer Ressource gleich

Wir betrachten nun Prozesse, die mehrere solcher Ressourcen belegen m¨ ochten, wobei die Ressourcen durch Sperren gesch¨ utzt sind.

Die genaue Implementierung der Sperren lassen wir dabei außer Acht (diese k¨ onnen z.B. durch Semaphore oder Monitore erfolgen).

(4)

Deadlocks bei mehreren Ressourcen (2)

Deadlocks allgemeiner (bei mehreren Ressourcen) Definition

Eine Menge von Prozessen ist deadlocked (verklemmt), wenn jeder (nicht beendete) Prozess aus der Menge auf ein Ereignis wartet, das nur ein anderer Prozess aus der Menge herbeif¨ uhren kann.

Das Ereignis entspricht meist dem Freigeben einer Ressource.

(5)

Beispiele

Mutual-Exclusion Problem: Deadlock, wenn es nicht mehr m¨ oglich ist, dass irgendein Prozess den kritischen Abschnitt betritt, obwohl alle Prozesse in den kritischen Abschnitt m¨ ochten

(6)

Beispiele (2)

Zwei Prozesse machen Umbuchungen zwischen Konto A und Konto B.

Vorgehensweise:

Sperren des ersten Kontos Sperren des zweiten Kontos

Uberweisung von erstem Konto auf zweites Konto durchf¨ ¨ uhren Entsperren der Konten.

Prozess P Prozess Q

wait(KontoA); wait(KontoB);

wait(KontoB); wait(KontoA);

buche von A nach B buche von B nach A signal(KontoA); signal(KontoB);

signal(KontoB); signal(KontoA);

Deadlock!

(7)

Beispiele (2)

Zwei Prozesse machen Umbuchungen zwischen Konto A und Konto B.

Vorgehensweise:

Sperren des ersten Kontos Sperren des zweiten Kontos

Uberweisung von erstem Konto auf zweites Konto durchf¨ ¨ uhren Entsperren der Konten.

Prozess P Prozess Q

wait(KontoA); wait(KontoB);

wait(KontoB); wait(KontoA);

buche von A nach B buche von B nach A signal(KontoA); signal(KontoB);

signal(KontoB); signal(KontoA);

Deadlock!

(8)

Beispiele (2)

Zwei Prozesse machen Umbuchungen zwischen Konto A und Konto B.

Vorgehensweise:

Sperren des ersten Kontos Sperren des zweiten Kontos

Uberweisung von erstem Konto auf zweites Konto durchf¨ ¨ uhren Entsperren der Konten.

Prozess P Prozess Q

wait(KontoA); wait(KontoB);

wait(KontoB); wait(KontoA);

buche von A nach B buche von B nach A signal(KontoA); signal(KontoB);

signal(KontoB); signal(KontoA);

Deadlock!

(9)

Beispiele (2)

Zwei Prozesse machen Umbuchungen zwischen Konto A und Konto B.

Vorgehensweise:

Sperren des ersten Kontos Sperren des zweiten Kontos

Uberweisung von erstem Konto auf zweites Konto durchf¨ ¨ uhren Entsperren der Konten.

Prozess P Prozess Q

wait(KontoA); wait(KontoB);

wait(KontoB); wait(KontoA);

buche von A nach B buche von B nach A signal(KontoA); signal(KontoB);

signal(KontoB); signal(KontoA);

Deadlock!

(10)

Beispiele (3)

Funktionierende L¨ osung (Deadlock-frei)

Prozess P Prozess Q

wait(KontoA); wait(KontoA);

wait(KontoB); wait(KontoB);

buche von A nach B buche von B nach A signal(KontoA); signal(KontoA);

signal(KontoB); signal(KontoB);

(11)

Beispiele (3)

Funktionierende L¨ osung (Deadlock-frei)

Prozess P Prozess Q

wait(KontoA); wait(KontoA);

wait(KontoB); wait(KontoB);

buche von A nach B buche von B nach A signal(KontoA); signal(KontoA);

signal(KontoB); signal(KontoB);

(12)

Beispiele (3)

Funktionierende L¨ osung (Deadlock-frei)

Prozess P Prozess Q

wait(KontoA); wait(KontoA);

wait(KontoB); wait(KontoB);

buche von A nach B buche von B nach A signal(KontoA); signal(KontoA);

signal(KontoB); signal(KontoB);

(13)

Beispiele (3)

Funktionierende L¨ osung (Deadlock-frei)

Prozess P Prozess Q

wait(KontoA); wait(KontoA);

wait(KontoB); wait(KontoB);

buche von A nach B buche von B nach A signal(KontoA); signal(KontoA);

signal(KontoB); signal(KontoB);

(14)

Beispiele (4)

Ahnliches Problem bei: Speisende Philosophen ¨

Deadlock m¨ oglich, wenn alle Philosophen unsychronisiert Alle haben die linke Gabel keiner die rechte.

(15)

Beispiele (5)

Engstelle

Nur ein Fahrzeug kann passieren

(16)

Beispiele (6)

Alle warten, dass “rechts frei” ist

(17)

Beispiele (7)

Gleiches Problem, aber etwas komplizierter

(18)

Deadlock-Behandlung

Vier Ans¨ atze

1

Ignorieren: Keine Vorkehrungen, Hoffnung, dass Deadlocks nur selten auftreten.

2

Deadlock-Erkennung und -Beseitigung: Laufzeitsystem erkennt Deadlocks und beseitigt sie. Problem: Finde Algorithmus der Deadlocks erkennt.

3

Deadlock-Vermeidung: Algorithmus verwaltet Ressourcen und l¨ asst Situation nicht zu, die zu einem Deadlock f¨ uhren k¨ onnen.

4

Deadlock-Verhinderung: Der Programmierer entwirft die Programme so, dass Deadlocks nicht auftreten k¨ onnen.

(19)

Deadlock-Behandlung

Vier Ans¨ atze

1

Ignorieren: Keine Vorkehrungen, Hoffnung, dass Deadlocks nur selten auftreten.

2

Deadlock-Erkennung und -Beseitigung: Laufzeitsystem erkennt Deadlocks und beseitigt sie. Problem: Finde Algorithmus der Deadlocks erkennt.

3

Deadlock-Vermeidung: Algorithmus verwaltet Ressourcen und l¨ asst Situation nicht zu, die zu einem Deadlock f¨ uhren k¨ onnen.

4

Deadlock-Verhinderung: Der Programmierer entwirft die Programme so, dass Deadlocks nicht auftreten k¨ onnen.

(20)

Deadlock-Behandlung

Vier Ans¨ atze

1

Ignorieren: Keine Vorkehrungen, Hoffnung, dass Deadlocks nur selten auftreten.

2

Deadlock-Erkennung und -Beseitigung: Laufzeitsystem erkennt Deadlocks und beseitigt sie. Problem: Finde Algorithmus der Deadlocks erkennt.

3

Deadlock-Vermeidung: Algorithmus verwaltet Ressourcen und l¨ asst Situation nicht zu, die zu einem Deadlock f¨ uhren k¨ onnen.

4

Deadlock-Verhinderung: Der Programmierer entwirft die Programme so, dass Deadlocks nicht auftreten k¨ onnen.

(21)

Deadlock-Behandlung

Vier Ans¨ atze

1

Ignorieren: Keine Vorkehrungen, Hoffnung, dass Deadlocks nur selten auftreten.

2

Deadlock-Erkennung und -Beseitigung: Laufzeitsystem erkennt Deadlocks und beseitigt sie. Problem: Finde Algorithmus der Deadlocks erkennt.

3

Deadlock-Vermeidung: Algorithmus verwaltet Ressourcen und l¨ asst Situation nicht zu, die zu einem Deadlock f¨ uhren k¨ onnen.

4

Deadlock-Verhinderung: Der Programmierer entwirft die Programme so, dass Deadlocks nicht auftreten k¨ onnen.

(22)

Deadlock-Behandlung (2)

Offensichtlich: Beste Methode: Deadlock-Verhinderung Daf¨ ur muss man wissen:

Unter welchen Umst¨ anden kann ein Deadlock auftreten?

Im folgenden: Bedingungen f¨ ur Deadlock und Deadlock-Verhinderung

(23)

Wann tritt Deadlock auf?

Vier notwendige Bedingungen (alle gleichzeitig erf¨ ullt):

1

Wechselseitiger Ausschluss (Mutual-Exclusion): Nur ein Prozess kann gleichzeitig auf eine Ressource zugreifen,

2

Halten und Warten (Hold and Wait): Ein Prozess kann eine Ressource anfordern (auf eine Ressource warten), w¨ ahrend er eine andere Ressource bereits belegt hat.

3

Keine Bevorzugung (No Preemption): Jede Ressource kann nur durch den Prozess freigegeben (entsperrt) werden, der sie belegt hat.

4

Zirkul¨ ares Warten: Es gibt zyklische Abh¨ angigkeit zwischen wartenden Prozessen: Jeder wartende Prozess m¨ ochte Zugriff auf die Ressource, die der n¨ achste Prozesse im Zyklus belegt hat.

(24)

Wann tritt Deadlock auf?

Vier notwendige Bedingungen (alle gleichzeitig erf¨ ullt):

1

Wechselseitiger Ausschluss (Mutual-Exclusion): Nur ein Prozess kann gleichzeitig auf eine Ressource zugreifen,

2

Halten und Warten (Hold and Wait): Ein Prozess kann eine Ressource anfordern (auf eine Ressource warten), w¨ ahrend er eine andere Ressource bereits belegt hat.

3

Keine Bevorzugung (No Preemption): Jede Ressource kann nur durch den Prozess freigegeben (entsperrt) werden, der sie belegt hat.

4

Zirkul¨ ares Warten: Es gibt zyklische Abh¨ angigkeit zwischen wartenden Prozessen: Jeder wartende Prozess m¨ ochte Zugriff auf die Ressource, die der n¨ achste Prozesse im Zyklus belegt hat.

(25)

Wann tritt Deadlock auf?

Vier notwendige Bedingungen (alle gleichzeitig erf¨ ullt):

1

Wechselseitiger Ausschluss (Mutual-Exclusion): Nur ein Prozess kann gleichzeitig auf eine Ressource zugreifen,

2

Halten und Warten (Hold and Wait): Ein Prozess kann eine Ressource anfordern (auf eine Ressource warten), w¨ ahrend er eine andere Ressource bereits belegt hat.

3

Keine Bevorzugung (No Preemption): Jede Ressource kann nur durch den Prozess freigegeben (entsperrt) werden, der sie belegt hat.

4

Zirkul¨ ares Warten: Es gibt zyklische Abh¨ angigkeit zwischen wartenden Prozessen: Jeder wartende Prozess m¨ ochte Zugriff auf die Ressource, die der n¨ achste Prozesse im Zyklus belegt hat.

(26)

Wann tritt Deadlock auf?

Vier notwendige Bedingungen (alle gleichzeitig erf¨ ullt):

1

Wechselseitiger Ausschluss (Mutual-Exclusion): Nur ein Prozess kann gleichzeitig auf eine Ressource zugreifen,

2

Halten und Warten (Hold and Wait): Ein Prozess kann eine Ressource anfordern (auf eine Ressource warten), w¨ ahrend er eine andere Ressource bereits belegt hat.

3

Keine Bevorzugung (No Preemption): Jede Ressource kann nur durch den Prozess freigegeben (entsperrt) werden, der sie belegt hat.

4

Zirkul¨ ares Warten: Es gibt zyklische Abh¨ angigkeit zwischen wartenden Prozessen: Jeder wartende Prozess m¨ ochte Zugriff auf die Ressource, die der n¨ achste Prozesse im Zyklus belegt hat.

(27)

Veranschaulichung

Prozess P 1 will Ressource R 1 belegen (hat sie aber nicht):

P ₁ R ₁

Prozess P ₁ hat Ressource R ₁ belegt:

P 1 R 1

(28)

Veranschaulichung der 4 Bedingungen

1

Wechselseitiger Ausschluss (Mutual-Exclusion): Nur ein ausgehender (gr¨ uner) Pfeil pro Ressource

2

Halten und Warten (Hold and Wait): Rote und gr¨ une Pfeile f¨ ur einen Prozess m¨ oglich

3

Keine Bevorzugung (No Preemption): Gr¨ une Pfeile k¨ onnen nicht ver¨ andert werden (außer vom Prozess, der den Pfeil hat)

4

Zirkul¨ ares Warten: Zyklus im Graphen

Verboten:

P ₂ R 1

P 1

(29)

Veranschaulichung der 4 Bedingungen

1

Wechselseitiger Ausschluss (Mutual-Exclusion): Nur ein ausgehender (gr¨ uner) Pfeil pro Ressource

2

Halten und Warten (Hold and Wait): Rote und gr¨ une Pfeile f¨ ur einen Prozess m¨ oglich

3

Keine Bevorzugung (No Preemption): Gr¨ une Pfeile k¨ onnen nicht ver¨ andert werden (außer vom Prozess, der den Pfeil hat)

4

Zirkul¨ ares Warten: Zyklus im Graphen

Erlaubt:

R 1

P 1

R ₃

(30)

Veranschaulichung der 4 Bedingungen

1

Wechselseitiger Ausschluss (Mutual-Exclusion): Nur ein ausgehender (gr¨ uner) Pfeil pro Ressource

2

Halten und Warten (Hold and Wait): Rote und gr¨ une Pfeile f¨ ur einen Prozess m¨ oglich

3

Keine Bevorzugung (No Preemption): Gr¨ une Pfeile k¨ onnen nicht ver¨ andert werden (außer vom Prozess, der den Pfeil hat)

4

Zirkul¨ ares Warten: Zyklus im Graphen

(31)

Veranschaulichung der 4 Bedingungen

1

Wechselseitiger Ausschluss (Mutual-Exclusion): Nur ein ausgehender (gr¨ uner) Pfeil pro Ressource

2

Halten und Warten (Hold and Wait): Rote und gr¨ une Pfeile f¨ ur einen Prozess m¨ oglich

3

Keine Bevorzugung (No Preemption): Gr¨ une Pfeile k¨ onnen nicht ver¨ andert werden (außer vom Prozess, der den Pfeil hat)

4

Zirkul¨ ares Warten: Zyklus im Graphen

P ₂ R 1

P 1

R ₃

P 3 R 2

(32)

Beispiel

Prozess 1: Prozess 2: Prozess 3:

Request R 1 Request R 2 Request R 3

Request R 2 Request R 3 Request R 1

Release R ₁ Release R ₂ Release R ₃ Release R ₂ Release R ₃ Release R ₁

P 1 P 2 P 3

R ₁ R ₂ R ₃

(33)

Beispiel

Prozess 1: Prozess 2: Prozess 3:

Request R 1 Request R 2 Request R 3

Request R 2 Request R 3 Request R 1

Release R ₁ Release R ₂ Release R ₃ Release R ₂ Release R ₃ Release R ₁

P 1 P 2 P 3

R ₁ R ₂ R ₃

(34)

Beispiel

Prozess 1: Prozess 2: Prozess 3:

Request R 1 Request R 2 Request R 3

Request R 2 Request R 3 Request R 1

Release R ₁ Release R ₂ Release R ₃ Release R ₂ Release R ₃ Release R ₁

P 1 P 2 P 3

R ₁ R ₂ R ₃

(35)

Beispiel

Prozess 1: Prozess 2: Prozess 3:

Request R 1 Request R 2 Request R 3

Request R 2 Request R 3 Request R 1

Release R ₁ Release R ₂ Release R ₃ Release R ₂ Release R ₃ Release R ₁

P 1 P 2 P 3

R ₁ R ₂ R ₃

(36)

Beispiel

Prozess 1: Prozess 2: Prozess 3:

Request R 1 Request R 2 Request R 3

Request R 2 Request R 3 Request R 1

Release R ₁ Release R ₂ Release R ₃ Release R ₂ Release R ₃ Release R ₁

P 1 P 2 P 3

R ₁ R ₂ R ₃

(37)

Beispiel

Prozess 1: Prozess 2: Prozess 3:

Request R 1 Request R 2 Request R 3

Request R 2 Request R 3 Request R 1

Release R ₁ Release R ₂ Release R ₃ Release R ₂ Release R ₃ Release R ₁

P 1 P 2 P 3

R ₁ R ₂ R ₃

(38)

Beispiel

Prozess 1: Prozess 2: Prozess 3:

Request R 1 Request R 2 Request R 3

Request R 2 Request R 3 Request R 1

Release R ₁ Release R ₂ Release R ₃ Release R ₂ Release R ₃ Release R ₁

P 1 P 2 P 3

R ₁ R ₂ R ₃

(39)

Beispiel

Prozess 1: Prozess 2: Prozess 3:

Request R 1 Request R 2 Request R 3

Request R 2 Request R 3 Request R 1

Release R ₁ Release R ₂ Release R ₃ Release R ₂ Release R ₃ Release R ₁

P 1 P 2 P 3

R ₁ R ₂ R ₃

(40)

Beispiel

Prozess 1: Prozess 2: Prozess 3:

Request R 1 Request R 2 Request R 3

Request R 2 Request R 3 Request R 1

Release R ₁ Release R ₂ Release R ₃ Release R ₂ Release R ₃ Release R ₁

P 1 P 2 P 3

R ₁ R ₂ R ₃

(41)

Beispiel: Anderes Scheduling

Prozess 1: Prozess 2: Prozess 3:

Request R 1 Request R 2 Request R 3

Request R 2 Request R 3 Request R 1

Release R ₁ Release R ₂ Release R ₃ Release R ₂ Release R ₃ Release R ₁

P 1 P 2 P 3

R ₁ R ₂ R ₃

(42)

Beispiel: Anderes Scheduling

Prozess 1: Prozess 2: Prozess 3:

Request R 1 Request R 2 Request R 3

Request R 2 Request R 3 Request R 1

Release R ₁ Release R ₂ Release R ₃ Release R ₂ Release R ₃ Release R ₁

P 1 P 2 P 3

R ₁ R ₂ R ₃

(43)

Beispiel: Anderes Scheduling

Prozess 1: Prozess 2: Prozess 3:

Request R 1 Request R 2 Request R 3

Request R 2 Request R 3 Request R 1

Release R ₁ Release R ₂ Release R ₃ Release R ₂ Release R ₃ Release R ₁

P 1 P 2 P 3

R ₁ R ₂ R ₃

(44)

Beispiel: Anderes Scheduling

Prozess 1: Prozess 2: Prozess 3:

Request R 1 Request R 2 Request R 3

Request R 2 Request R 3 Request R 1

Release R ₁ Release R ₂ Release R ₃ Release R ₂ Release R ₃ Release R ₁

P 1 P 2 P 3

R ₁ R ₂ R ₃

(45)

Beispiel: Anderes Scheduling

Prozess 1: Prozess 2: Prozess 3:

Request R 1 Request R 2 Request R 3

Request R 2 Request R 3 Request R 1

Release R ₁ Release R ₂ Release R ₃ Release R ₂ Release R ₃ Release R ₁

P 1 P 2 P 3

R ₁ R ₂ R ₃

(46)

Beispiel: Anderes Scheduling

Prozess 1: Prozess 2: Prozess 3:

Request R 1 Request R 2 Request R 3

Request R 2 Request R 3 Request R 1

Release R ₁ Release R ₂ Release R ₃ Release R ₂ Release R ₃ Release R ₁

P 1 P 2 P 3

R ₁ R ₂ R ₃

(47)

Beispiel: Anderes Scheduling

Prozess 1: Prozess 2: Prozess 3:

Request R 1 Request R 2 Request R 3

Request R 2 Request R 3 Request R 1

Release R ₁ Release R ₂ Release R ₃ Release R ₂ Release R ₃ Release R ₁

P 1 P 2 P 3

R ₁ R ₂ R ₃

(48)

Beispiel: Anderes Scheduling

Prozess 1: Prozess 2: Prozess 3:

Request R 1 Request R 2 Request R 3

Request R 2 Request R 3 Request R 1

Release R ₁ Release R ₂ Release R ₃ Release R ₂ Release R ₃ Release R ₁

P 1 P 2 P 3

R ₁ R ₂ R ₃

(49)

Beispiel: Anderes Scheduling

Prozess 1: Prozess 2: Prozess 3:

Request R 1 Request R 2 Request R 3

Request R 2 Request R 3 Request R 1

Release R ₁ Release R ₂ Release R ₃ Release R ₂ Release R ₃ Release R ₁

P 1 P 2 P 3

R ₁ R ₂ R ₃

(50)

Beispiel: Anderes Scheduling

Prozess 1: Prozess 2: Prozess 3:

Request R 1 Request R 2 Request R 3

Request R 2 Request R 3 Request R 1

Release R ₁ Release R ₂ Release R ₃ Release R ₂ Release R ₃ Release R ₁

P 1 P 2 P 3

R ₁ R ₂ R ₃

(51)

Beispiel: Anderes Scheduling

Prozess 1: Prozess 2: Prozess 3:

Request R 1 Request R 2 Request R 3

Request R 2 Request R 3 Request R 1

Release R ₁ Release R ₂ Release R ₃ Release R ₂ Release R ₃ Release R ₁

P 1 P 2 P 3

R ₁ R ₂ R ₃

(52)

Beispiel: Anderes Scheduling

Prozess 1: Prozess 2: Prozess 3:

Request R 1 Request R 2 Request R 3

Request R 2 Request R 3 Request R 1

Release R ₁ Release R ₂ Release R ₃ Release R ₂ Release R ₃ Release R ₁

P 1 P 2 P 3

R ₁ R ₂ R ₃

(53)

Beispiel: Anderes Scheduling

Prozess 1: Prozess 2: Prozess 3:

Request R 1 Request R 2 Request R 3

Request R 2 Request R 3 Request R 1

Release R ₁ Release R ₂ Release R ₃ Release R ₂ Release R ₃ Release R ₁

P 1 P 2 P 3

R ₁ R ₂ R ₃

(54)

Beispiel: Anderes Scheduling

Prozess 1: Prozess 2: Prozess 3:

Request R 1 Request R 2 Request R 3

Request R 2 Request R 3 Request R 1

Release R ₁ Release R ₂ Release R ₃ Release R ₂ Release R ₃ Release R ₁

P 1 P 2 P 3

R ₁ R ₂ R ₃

(55)

Beispiel: Anderes Scheduling

Prozess 1: Prozess 2: Prozess 3:

Request R 1 Request R 2 Request R 3

Request R 2 Request R 3 Request R 1

Release R ₁ Release R ₂ Release R ₃ Release R ₂ Release R ₃ Release R ₁

P 1 P 2 P 3

R ₁ R ₂ R ₃

(56)

Beispiel: Anderes Scheduling

Prozess 1: Prozess 2: Prozess 3:

Request R 1 Request R 2 Request R 3

Request R 2 Request R 3 Request R 1

Release R ₁ Release R ₂ Release R ₃ Release R ₂ Release R ₃ Release R ₁

P 1 P 2 P 3

R ₁ R ₂ R ₃

(57)

Beispiel: Anderes Scheduling

Prozess 1: Prozess 2: Prozess 3:

Request R ₁ Request R ₂ Request R ₃ Request R ₂ Request R ₃ Request R ₁ Release R 1 Release R 2 Release R 3

Release R ₂ Release R ₃ Release R ₁

Deadlock-Verhinderung: Programm so erstellt, dass unabh¨ angig vom Scheduling kein Deadlock auftritt

Deadlock-Vermeidung: Scheduler erkennt Deadlock-Gefahr und schließt diese Schedulings aus

(58)

Deadlock-Verhinderung

Ansatz: Greife eine der vier Bedingungen an, so dass sie nie wahr wird.

Wechselseitiger Ausschluss: Im allgemeinen schwer m¨ oglich, manchmal aber schon:

Z.B. Druckerzugriff wird durch Spooler geregelt.

No Preemption: Schwierig, man kann z.B. nicht den Zugriff auf den Drucker entziehen, wenn Prozess noch nicht fertig gedruckt hat usw.

(59)

Verhindern von Hold and Wait

M¨ oglichkeit: Prozess fordert zu Beginn alle Ressourcen an, die er ben¨ otigt.

Philosophen: Exklusiver Zugriff auf alle Gabeln 1. Problem: Evtl. zu sequentiell

2. Problem: Oft nicht klar, welche Ressourcen jeder Prozess braucht

Variation dieser L¨ osung: 2-Phasen Sperrprotokoll

(60)

2-Phasen Sperrprotokoll

Die Prozesse arbeiten in zwei Phasen Jeder Prozess f¨ uhrt dabei aus:

1. Phase: Der Prozess versucht alle ben¨ otigten Ressourcen zu belegen.

Ist eine ben¨ otigte Ressource nicht frei, so gibt der Prozess alle belegten Ressourcen zur¨ uck und der Prozess startet von neuem mit Phase 1.

2. Phase: Der Prozess hat alle ben¨ otigten Ressourcen Nachdem er fertig mit seiner Berechnung ist, gibt er alle Ressourcen wieder frei.

(61)

Beispiel: Speisende Philosophen

Initial alle Gabeln (Semaphore) mit 1 initialisiert

tryWait: Nicht-blockierende Implementierung von wait:

tryWait(S) =

True, wenn Semaphor belegt werden konnte False, sonst

Phase 1, Phase 2

Philosoph i loop forever

(1) l := tryWait(gabel[i]);

(2) if l then

(3) r:=tryWait(gabel[i+1]);

(4) if r then (5) Philosoph isst (6) signal(gabel[i + 1]);

(7) signal(gabel[i]);

(8) else signal(gabel[i]);

(9) Philosoph denkt;

end loop

P ₃ gabel[1]

P 1

gabel[2]

P 2 gabel[3]

Deadlock nicht m¨ oglich!

Aber Livelock!

(62)

Beispiel: Speisende Philosophen

Initial alle Gabeln (Semaphore) mit 1 initialisiert

tryWait: Nicht-blockierende Implementierung von wait:

tryWait(S) =

True, wenn Semaphor belegt werden konnte False, sonst

Phase 1, Phase 2

Philosoph i loop forever

(1) l := tryWait(gabel[i]);

(2) if l then

(3) r:=tryWait(gabel[i+1]);

(4) if r then (5) Philosoph isst (6) signal(gabel[i + 1]);

(7) signal(gabel[i]);

(8) else signal(gabel[i]);

(9) Philosoph denkt;

end loop

P ₃ gabel[1]

P 1

gabel[2]

P 2 gabel[3]

Deadlock nicht m¨ oglich!

Aber Livelock!

(63)

Beispiel: Speisende Philosophen

Initial alle Gabeln (Semaphore) mit 1 initialisiert

tryWait: Nicht-blockierende Implementierung von wait:

tryWait(S) =

True, wenn Semaphor belegt werden konnte False, sonst

Phase 1, Phase 2

Philosoph i loop forever

(1) l := tryWait(gabel[i]);

(2) if l then

(3) r:=tryWait(gabel[i+1]);

(4) if r then (5) Philosoph isst (6) signal(gabel[i + 1]);

(7) signal(gabel[i]);

(8) else signal(gabel[i]);

(9) Philosoph denkt;

end loop

P ₃ gabel[1]

P 1

gabel[2]

P 2 gabel[3]

Deadlock nicht m¨ oglich!

Aber Livelock!

(64)

Beispiel: Speisende Philosophen

Initial alle Gabeln (Semaphore) mit 1 initialisiert

tryWait: Nicht-blockierende Implementierung von wait:

tryWait(S) =

True, wenn Semaphor belegt werden konnte False, sonst

Phase 1, Phase 2

Philosoph i loop forever

(1) l := tryWait(gabel[i]);

(2) if l then

(3) r:=tryWait(gabel[i+1]);

(4) if r then (5) Philosoph isst (6) signal(gabel[i + 1]);

(7) signal(gabel[i]);

(8) else signal(gabel[i]);

(9) Philosoph denkt;

end loop

P ₃ gabel[1]

P 1

gabel[2]

P 2 gabel[3]

Deadlock nicht m¨ oglich!

Aber Livelock!

(65)

Beispiel: Speisende Philosophen

Initial alle Gabeln (Semaphore) mit 1 initialisiert

tryWait: Nicht-blockierende Implementierung von wait:

tryWait(S) =

True, wenn Semaphor belegt werden konnte False, sonst

Phase 1, Phase 2

Philosoph i loop forever

(1) l := tryWait(gabel[i]);

(2) if l then

(3) r:=tryWait(gabel[i+1]);

(4) if r then (5) Philosoph isst (6) signal(gabel[i + 1]);

(7) signal(gabel[i]);

(8) else signal(gabel[i]);

(9) Philosoph denkt;

end loop

P ₃ gabel[1]

P 1

gabel[2]

P 2 gabel[3]

Deadlock nicht m¨ oglich!

Aber Livelock!

(66)

Beispiel: Speisende Philosophen

Initial alle Gabeln (Semaphore) mit 1 initialisiert

tryWait: Nicht-blockierende Implementierung von wait:

tryWait(S) =

True, wenn Semaphor belegt werden konnte False, sonst

Phase 1, Phase 2

Philosoph i loop forever

(1) l := tryWait(gabel[i]);

(2) if l then

(3) r:=tryWait(gabel[i+1]);

(4) if r then (5) Philosoph isst (6) signal(gabel[i + 1]);

(7) signal(gabel[i]);

(8) else signal(gabel[i]);

(9) Philosoph denkt;

end loop

P ₃ gabel[1]

P 1

gabel[2]

P 2 gabel[3]

Deadlock nicht m¨ oglich!

Aber Livelock!

(67)

Beispiel: Speisende Philosophen

Initial alle Gabeln (Semaphore) mit 1 initialisiert

tryWait: Nicht-blockierende Implementierung von wait:

tryWait(S) =

True, wenn Semaphor belegt werden konnte False, sonst

Phase 1, Phase 2

Philosoph i loop forever

(1) l := tryWait(gabel[i]);

(2) if l then

(3) r:=tryWait(gabel[i+1]);

(4) if r then (5) Philosoph isst (6) signal(gabel[i + 1]);

(7) signal(gabel[i]);

(8) else signal(gabel[i]);

(9) Philosoph denkt;

end loop

P ₃ gabel[1]

P 1

gabel[2]

P 2 gabel[3]

Deadlock nicht m¨ oglich!

Aber Livelock!

(68)

Beispiel: Speisende Philosophen

Initial alle Gabeln (Semaphore) mit 1 initialisiert

tryWait: Nicht-blockierende Implementierung von wait:

tryWait(S) =

True, wenn Semaphor belegt werden konnte False, sonst

Phase 1, Phase 2

Philosoph i loop forever

(1) l := tryWait(gabel[i]);

(2) if l then

(3) r:=tryWait(gabel[i+1]);

(4) if r then (5) Philosoph isst (6) signal(gabel[i + 1]);

(7) signal(gabel[i]);

(8) else signal(gabel[i]);

(9) Philosoph denkt;

end loop

P ₃ gabel[1]

P 1

gabel[2]

P 2 gabel[3]

Deadlock nicht m¨ oglich!

Aber Livelock!

(69)

Beispiel: Speisende Philosophen

Initial alle Gabeln (Semaphore) mit 1 initialisiert

tryWait: Nicht-blockierende Implementierung von wait:

tryWait(S) =

True, wenn Semaphor belegt werden konnte False, sonst

Phase 1, Phase 2

Philosoph i loop forever

(1) l := tryWait(gabel[i]);

(2) if l then

(3) r:=tryWait(gabel[i+1]);

(4) if r then (5) Philosoph isst (6) signal(gabel[i + 1]);

(7) signal(gabel[i]);

(8) else signal(gabel[i]);

(9) Philosoph denkt;

end loop

P ₃ gabel[1]

P 1

gabel[2]

P 2 gabel[3]

Deadlock nicht m¨ oglich!

Aber Livelock!

(70)

Beispiel: Speisende Philosophen

Initial alle Gabeln (Semaphore) mit 1 initialisiert

tryWait: Nicht-blockierende Implementierung von wait:

tryWait(S) =

True, wenn Semaphor belegt werden konnte False, sonst

Phase 1, Phase 2

Philosoph i loop forever

(1) l := tryWait(gabel[i]);

(2) if l then

(3) r:=tryWait(gabel[i+1]);

(4) if r then (5) Philosoph isst (6) signal(gabel[i + 1]);

(7) signal(gabel[i]);

(8) else signal(gabel[i]);

(9) Philosoph denkt;

end loop

P ₃ gabel[1]

P 1

gabel[2]

P 2 gabel[3]

Deadlock nicht m¨ oglich!

Aber Livelock!

(71)

Beispiel: Speisende Philosophen

Initial alle Gabeln (Semaphore) mit 1 initialisiert

tryWait: Nicht-blockierende Implementierung von wait:

tryWait(S) =

True, wenn Semaphor belegt werden konnte False, sonst

Phase 1, Phase 2

Philosoph i loop forever

(1) l := tryWait(gabel[i]);

(2) if l then

(3) r:=tryWait(gabel[i+1]);

(4) if r then (5) Philosoph isst (6) signal(gabel[i + 1]);

(7) signal(gabel[i]);

(8) else signal(gabel[i]);

(9) Philosoph denkt;

end loop

P ₃ gabel[1]

P 1

gabel[2]

P 2 gabel[3]

Deadlock nicht m¨ oglich!

Aber Livelock!

(72)

Beispiel: Speisende Philosophen

Initial alle Gabeln (Semaphore) mit 1 initialisiert

tryWait: Nicht-blockierende Implementierung von wait:

tryWait(S) =

True, wenn Semaphor belegt werden konnte False, sonst

Phase 1, Phase 2

Philosoph i loop forever

(1) l := tryWait(gabel[i]);

(2) if l then

(3) r:=tryWait(gabel[i+1]);

(4) if r then (5) Philosoph isst (6) signal(gabel[i + 1]);

(7) signal(gabel[i]);

(8) else signal(gabel[i]);

(9) Philosoph denkt;

end loop

P ₃ gabel[1]

P 1

gabel[2]

P 2 gabel[3]

Deadlock nicht m¨ oglich!

Aber Livelock!

(73)

Beispiel: Speisende Philosophen

Initial alle Gabeln (Semaphore) mit 1 initialisiert

tryWait: Nicht-blockierende Implementierung von wait:

tryWait(S) =

True, wenn Semaphor belegt werden konnte False, sonst

Phase 1, Phase 2

Philosoph i loop forever

(1) l := tryWait(gabel[i]);

(2) if l then

(3) r:=tryWait(gabel[i+1]);

(4) if r then (5) Philosoph isst (6) signal(gabel[i + 1]);

(7) signal(gabel[i]);

(8) else signal(gabel[i]);

(9) Philosoph denkt;

end loop

P ₃ gabel[1]

P 1

gabel[2]

P 2 gabel[3]

Deadlock nicht m¨ oglich!

Aber Livelock!

(74)

Beispiel: Speisende Philosophen

Initial alle Gabeln (Semaphore) mit 1 initialisiert

tryWait: Nicht-blockierende Implementierung von wait:

tryWait(S) =

True, wenn Semaphor belegt werden konnte False, sonst

Phase 1, Phase 2

Philosoph i loop forever

(1) l := tryWait(gabel[i]);

(2) if l then

(3) r:=tryWait(gabel[i+1]);

(4) if r then (5) Philosoph isst (6) signal(gabel[i + 1]);

(7) signal(gabel[i]);

(8) else signal(gabel[i]);

(9) Philosoph denkt;

end loop

P ₃ gabel[1]

P 1

gabel[2]

P 2 gabel[3]

Deadlock nicht m¨ oglich!

Aber Livelock!

(75)

Timestamping-Ordering

Prozesse erhalten eindeutigen Zeitstempel, wenn sie beginnen.

Zwei-Phasen Sperrprotokoll mit Timestamping Jeder Prozess geht dabei so vor:

1. Phase: Der Prozess versucht alle ben¨ otigten Ressourcen auf einmal zu sperren.

Ist eine ben¨ otigte Ressource belegt mit kleinerem Zeitstempel, dann gibt Prozess alle Ressourcen frei und startet von neuem.

Ist eigener Zeitstempel kleiner, dann wartet der Prozess auf die restlichen Ressourcen.

2. Phase: Wenn der Prozess erfolgreich in diese Phase gekommen ist, hat er alle ben¨ otigten Ressourcen. Er benutzt sie und gibt sie anschließend wieder frei.

Beachte: Neue Zeitstempel werden nur vergeben, nach erfolgreichem Durchlauf durch beide Phasen.

(76)

Timestamping-Ordering (2)

Deadlock-frei

Livelock nicht m¨ oglich Starvation-frei.

Definition

Starvation ist eine Situation, in der ein Prozess niemals (nach beliebig vielen Berechnungsschritten) in der Lage ist, alle ben¨ otigten Ressourcen zu belegen.

(77)

Zirkul¨ ares Warten verhindern

Versuche das zirkul¨ are Warten zu verhindern.

Philosophen-Problem: N. Prozess hebt zuerst rechte Gabel Dann kann kein zirkul¨ ares Warten enstehen

Denn die Gabeln wurden total geordnet: 1 < 2 . . . N.

Und die Philosophen haben die Ressourcen entsprechend dieser Ordnung belegt.

(78)

Total-Order Theorem

Allgemein gilt:

Total-Order Theorem

Sind alle gemeinsamen Ressourcen durch eine totale Ordnung geordnet und jeder Prozess belegt seine ben¨ otigten Ressourcen in aufsteigender Reihenfolge bez¨ uglich der totalen Ordnung, dann ist ein Deadlock unm¨ oglich.

Beweis: durch Widerspruch. Annahme: Es gibt einen Deadlock.

D.h. es gibt Ressourcen R 1 , . . . , R n und Prozesse P 1 , . . . , P n mit Prozess P i hat Ressource R i−1 belegt

Prozess P _i wartet auf Ressource R _i

Sei R _j die kleinste Ressource aus {R ₁ , . . . , R _n } bez¨ uglich der totalen Ordnung. Dann wartet Prozess P j auf Ressource R j , wobei er Ressource R j−1 schon belegt hat. Widerspruch.

(79)

Total Order Theorem (2)

Man kann nachweisen:

Lemma

Ein Deadlock-freies System, indem die Belegung von (allen) einzelnen Ressourcen Starvation-frei ist, ist auch insgesamt Starvation-frei

Mit dem Total Order Theorem l¨ asst sich folgern:

Wenn es eine totale Ordnung der Ressourcen gibt, die Ressourcen entsprechend dieser Ordnung belegt werden und die Belegung einzelner Ressourcen Starvation-frei ist, dann ist das Gesamtsystem Starvation-frei.

(80)

Deadlock-Vermeidung

Erinnerung:

Deadlock-Vermeidung: Algorithmus verwaltet Ressourcen und l¨ asst Situation nicht zu, die zu einem Deadlock f¨ uhren k¨ onnen.

Im folgenden:

Beispiel von Dijkstra zur Deadlock-Vermeidung:

Problem des Deadly Embrace L¨ osung: Bankier-Algorithmus

(81)

Deadly Embrace

Annahme:

Es gibt m gleiche Ressourcen

Jeder Prozesse P i ben¨ otigt eine gewisse Zahl m i ≤ m dieser Ressource

Prozesse fordern Ressourcen nach und nach an

Die maximal ben¨ otigte Anzahl m i ist beim Start bekannt Hat ein Prozess seine maximale Anzahl, terminiert er und gibt die Ressourcen zur¨ uck.

Problem: Implementiere Ressourcenverwalter

(82)

Dijkstra’s Veranschaulichung

Ressource: Geld

Prozesse sind Bankkunden Ressourcenverwalter: Bankier

(83)

Deadlock-Vermeidung: Beispiel

Vorhandene Ressourcen am Anfang: 98 EUR 2 Kunden, beide ben¨ otigen 50 EUR

Beide Kunden haben bereits 48 EUR erhalten Beide Kunden fordern 1 EUR an.

Soll der Bankier beide Anforderungen zulassen?

Nein: Dann haben beide Kunden 49 EUR, die Bank 0 EUR Ein Deadlock ist eingetreten.

Ein Kunde fordert 1 EUR an Soll er das Geld bekommen?

Ja, denn danach ist der Zustand immer noch sicher sicher = Deadlock noch vermeidbar (muss nicht eintreten)

(84)

Deadlock-Vermeidung: Beispiel

Vorhandene Ressourcen am Anfang: 98 EUR 2 Kunden, beide ben¨ otigen 50 EUR

Beide Kunden haben bereits 48 EUR erhalten Beide Kunden fordern 1 EUR an.

Soll der Bankier beide Anforderungen zulassen?

Nein: Dann haben beide Kunden 49 EUR, die Bank 0 EUR Ein Deadlock ist eingetreten.

Ein Kunde fordert 1 EUR an Soll er das Geld bekommen?

Ja, denn danach ist der Zustand immer noch sicher sicher = Deadlock noch vermeidbar (muss nicht eintreten)

(85)

Deadlock-Vermeidung: Beispiel

Vorhandene Ressourcen am Anfang: 98 EUR 2 Kunden, beide ben¨ otigen 50 EUR

Beide Kunden haben bereits 48 EUR erhalten Beide Kunden fordern 1 EUR an.

Soll der Bankier beide Anforderungen zulassen?

Nein: Dann haben beide Kunden 49 EUR, die Bank 0 EUR Ein Deadlock ist eingetreten.

Ein Kunde fordert 1 EUR an Soll er das Geld bekommen?

Ja, denn danach ist der Zustand immer noch sicher sicher = Deadlock noch vermeidbar (muss nicht eintreten)

(86)

Deadlock-Vermeidung: Beispiel

Vorhandene Ressourcen am Anfang: 98 EUR 2 Kunden, beide ben¨ otigen 50 EUR

Beide Kunden haben bereits 48 EUR erhalten Beide Kunden fordern 1 EUR an.

Soll der Bankier beide Anforderungen zulassen?

Nein: Dann haben beide Kunden 49 EUR, die Bank 0 EUR Ein Deadlock ist eingetreten.

Ein Kunde fordert 1 EUR an Soll er das Geld bekommen?

Ja, denn danach ist der Zustand immer noch sicher sicher = Deadlock noch vermeidbar (muss nicht eintreten)

(87)

L¨ osungsversuch

Naive L¨ osung:

Kunden erhalten Reihenfolge

Bankier bedient immer einen Kunden, bis er seinen maximalen Betrag erhalten hat

Alle andere Kunden m¨ ussen warten

Schlecht, da sequentieller Algorithmus Deshalb:

Zus¨ atzliche Anforderung: Erlaube soviel Nebenl¨ aufigkeit wie m¨ oglich

Lehne nur dann Anfrage ab, wenn der Zustand dann unsicher w¨ urde,

d.h. ein Deadlock eintreten muss

(88)

L¨ osungsversuch

Naive L¨ osung:

Kunden erhalten Reihenfolge

Bankier bedient immer einen Kunden, bis er seinen maximalen Betrag erhalten hat

Alle andere Kunden m¨ ussen warten Schlecht, da sequentieller Algorithmus

Deshalb:

Zus¨ atzliche Anforderung: Erlaube soviel Nebenl¨ aufigkeit wie m¨ oglich

Lehne nur dann Anfrage ab, wenn der Zustand dann unsicher w¨ urde,

d.h. ein Deadlock eintreten muss

(89)

L¨ osungsversuch

Naive L¨ osung:

Kunden erhalten Reihenfolge

Bankier bedient immer einen Kunden, bis er seinen maximalen Betrag erhalten hat

Alle andere Kunden m¨ ussen warten Schlecht, da sequentieller Algorithmus Deshalb:

Zus¨ atzliche Anforderung: Erlaube soviel Nebenl¨ aufigkeit wie m¨ oglich

Lehne nur dann Anfrage ab, wenn der Zustand dann unsicher w¨ urde,

d.h. ein Deadlock eintreten muss

(90)

Bankier-Algorithmus: Datenstrukturen

Annahme: Verschiedene Ressourcen, z.B. mehrere W¨ ahrungen Vektor − →

A : Aktueller Vorrat in der Bank. Jede Komponente von − →

A ist nicht-negative Ganzzahl und stellt Vorrat einer W¨ ahrung dar

P Menge der Kunden (Prozesse). F¨ ur P ∈ P sei:

−−→ M P der Vektor der maximal durch Prozess P anzufordernden Ressourcen

−→ C _P der Vektor der bereits an Prozess P vergebenen Ressourcen

(91)

Bankier-Algorithmus: Sicherer Zustand

sicher = Deadlock in der Zukunft vermeidbar Ein Zustand (mit all seinen Vektoren) ist sicher,

wenn es eine Permutation π der Prozesse P 1 , . . . , P n ∈ P gibt, sodass es f¨ ur jeden Prozesse P i entsprechend der Reihenfolge der Permutation gen¨ ugend Ressourcen gibt, wenn er dran ist.

Gen¨ ugend Ressourcen bedeutet hierbei:

−

→ A +



 X

π(j)<π(i)

−−−→ C P

_π(j)



 − −−→

M P

i

+ −→

C P

i

≥ − → 0

Zu den aktuell verf¨ ugbaren Ressourcen − → A

d¨ urfen momentan vergebenen Ressourcen hinzuaddiert werden, deren zugeh¨ orige Prozesse entsprechend der Permutation vor P _i vollst¨ andig bedient werden.

(92)

Bankier-Algorithmus: Grundger¨ ust

Bankier erh¨ alt eine Ressourcenanfrage −→

L _P eines Prozesses P ∈ P.

Konsistenzbedingung: −→

L _P + −→

C _P ≤ −−→

M _P

Bankier berechnet den Folgezustand, alsob P die Ressourcen erh¨ alt, d.h.

−

→ A := − → A − −→

L _P

−→ C _P := −→

C _P + −→

L _P Anschließend: Teste ob Zustand noch sicher

Wenn unsicher, dann stelle Ursprungszustand her und lasse P warten

Wenn Kunde maximale Ressourcen erh¨ alt wird − →

A automatisch angepasst,

(93)

Bankier-Algorithmus: Test auf Sicherheit

function testeZustand(P , − → A ):

if P = ∅ then return “sicher”

else

if ∃P ∈ P mit −−→

M P − −→

C P ≤ − → A then

−

→ A := − → A + −→

C _P ; P := P \ {P };

testeZustand(P , − → A ) else

return “unsicher”

(94)

Eigenschaften

Algorithmus berechnet eine der gesuchten Permutationen Laufzeit O(|P| ² )!

Kriterium ist ausschließlich

” Kein Deadlock“ sonst keine

” Optimierung“

kleine Verbesserung:

Wenn − → A ≥ −−→

M P − −→

C P (gen¨ ugend Ressourcen vorhanden um P komplett zu bedienen) dann ist nach Anfrage −→

L P der Zustand immer sicher (Test muss nicht ausgef¨ uhrt werden)

(95)

Beispiel

4 Ressourcen (EUR, USD, JYN, SFR) 4 Prozesse A, B, C, D

Aktueller Zustand

Maximal-Werte Erhaltene Werte Verf¨ ugbare Ressourcen

− − →

M A = (4, 7, 1, 1) −→

C A = (1, 1, 0, 0) − →

A = (2, 2, 3, 3)

−−→ M _B = (0, 8, 1, 5) −→

C _B = (0, 5, 0, 3)

−−→ M _C = (2, 2, 4, 2) −→

C _C = (0, 2, 1, 0)

−−→ M D = (2, 0, 0, 2) −→

C D = (1, 0, 0, 1)

Ist der Zustand sicher?

(96)

Beispiel (2)

Wir betrachten nun die Anfrage L A = (2, 2, 0, 0), d.h. Prozess A m¨ ochte zwei weitere EUR und zwei weitere USD belegen.

Nach Aktualisierung ( − → A := − →

A − −→

L A und −→

C A := −→

C A + −→

L A ) erhalten wir den Zustand:

Maximal-Werte Erhaltene Werte Verf¨ ugbare Ressourcen

− − →

M A = (4, 7, 1, 1) −→

C A = (3, 3, 0, 0) − →

A = (0, 0, 3, 3)

−−→ M _B = (0, 8, 1, 5) −→

C _B = (0, 5, 0, 3)

−−→ M _C = (2, 2, 4, 2) −→

C _C = (0, 2, 1, 0)

−−→ M D = (2, 0, 0, 2) −→

C D = (1, 0, 0, 1)

Bleibt der Zustand sicher?

(97)

Transactional Memory

(98)

Transactional Memory

Neuer Programmieransatz

Ziel: Programmierer schreibt mehr oder weniger sequentiellen Code

System garantiert Deadlockfreiheit und evtl. noch mehr

(99)

Motivation: Beispiel

Uberweisungen zwischen Konto A und B ¨

L¨ osung: Sperre Konten entsprechend einer totalen Ordnung

Erweiterung: Buche nur dann ab, wenn Konto gedeckt L¨ osung 1: Abort und Restart: Wenn Konto nicht gedeckt, starte von neuem. Birgt die Gefahr, immer wieder neu zu starten.

L¨ osung 2: Warte bis Konto gedeckt (Sperren m¨ ussen aufgehoben werden!)

Fazit: Kleine Erweiterungen erfordern große ¨ Anderungen

(100)

Motivation: Beispiel

Uberweisungen zwischen Konto A und B ¨

L¨ osung: Sperre Konten entsprechend einer totalen Ordnung Erweiterung: Buche nur dann ab, wenn Konto gedeckt

L¨ osung 1: Abort und Restart: Wenn Konto nicht gedeckt, starte von neuem. Birgt die Gefahr, immer wieder neu zu starten.

L¨ osung 2: Warte bis Konto gedeckt (Sperren m¨ ussen aufgehoben werden!)

Fazit: Kleine Erweiterungen erfordern große ¨ Anderungen

(101)

Motivation: Beispiel

Uberweisungen zwischen Konto A und B ¨

L¨ osung: Sperre Konten entsprechend einer totalen Ordnung Erweiterung: Buche nur dann ab, wenn Konto gedeckt L¨ osung 1: Abort und Restart: Wenn Konto nicht gedeckt, starte von neuem. Birgt die Gefahr, immer wieder neu zu starten.

L¨ osung 2: Warte bis Konto gedeckt (Sperren m¨ ussen aufgehoben werden!)

Fazit: Kleine Erweiterungen erfordern große ¨ Anderungen

(102)

Motivation: Beispiel

Uberweisungen zwischen Konto A und B ¨

L¨ osung: Sperre Konten entsprechend einer totalen Ordnung Erweiterung: Buche nur dann ab, wenn Konto gedeckt L¨ osung 1: Abort und Restart: Wenn Konto nicht gedeckt, starte von neuem. Birgt die Gefahr, immer wieder neu zu starten.

L¨ osung 2: Warte bis Konto gedeckt (Sperren m¨ ussen aufgehoben werden!)

Fazit: Kleine Erweiterungen erfordern große ¨ Anderungen

(103)

Motivation: Beispiel

Uberweisungen zwischen Konto A und B ¨

L¨ osung: Sperre Konten entsprechend einer totalen Ordnung Erweiterung: Buche nur dann ab, wenn Konto gedeckt L¨ osung 1: Abort und Restart: Wenn Konto nicht gedeckt, starte von neuem. Birgt die Gefahr, immer wieder neu zu starten.

L¨ osung 2: Warte bis Konto gedeckt (Sperren m¨ ussen aufgehoben werden!)

Fazit: Kleine Erweiterungen erfordern große ¨ Anderungen

(104)

Lock-basierte Programmierung ist schlecht . . .

(Argumente von S. L. Peyton Jones)

Setzen zu weniger Locks: Programmierer vergisst eine Sperre zu setzen, Folge: Race Condition

Setzen zu vieler Locks: Programmierer ¨ ubervorsichtig:

Folgen:

Programm unn¨ otig sequentiell (Best-Case), Deadlock (Wort-Case)

Setzen der falschen Locks: Beziehung zwischen Sperren und Daten kennt nur der Programmierer. Compiler oder andere Programmierer kennen die Beziehung evtl. nicht.

(105)

Lock-basierte Programmierung ist schlecht . . . (2)

Setzen von Locks in der falschen Reihenfolge: Das Total-Order Theorem kann nur eingehalten werden, wenn jeder

Programmierer weiß, wie die Ordnung der Locks aussieht.

Fehlerbehandlung schwierig, da bei Fehlerbehandlung Locks entsperrt werden m¨ ussen.

Vergessene signal-Operationen oder vergessenes erneutes Pr¨ ufen von Bedingungen f¨ uhrt zu fehlerhaften Systemen.