Fortgeschrittene Systementwicklung

Mehrbenutzersnychronisation
Übungen

1. (max. 1Pkt.) Das Philisophenproblem

Beim Philosophenproblem handelt es sich um ein Fallbeispiel aus dem Bereich
der theoretischen Informatik. Es veranschaulicht das Problem Nebenläufigkeit und der
Verklemmung.
Fünf Philosophen sitzen an einem runden Tisch, und jeder hat
einen Teller mit Spaghetti vor sich. Zum Essen von Spaghetti
benötigt jeder Philosoph zwei Gabeln. Allerdings waren im
Haushalt nur fünf Gabeln vorhanden, die nun zwischen den
Tellern liegen. Die Philosophen können also nicht alle
gleichzeitig speisen. Jeder darf nur die beiden Gabeln
nehmen, die rechts und links von ihm liegen.

Versuchen Sie Fälle zu finden wo:

• Mehr als ein Philosoph (nebenläufig!) essen kann

• Es zu einer Verklemmung kommt

2. Nichtserialisierbare Historien (Banküberweisung)

(max. 2 Pkt.) Berechnen Sie die Ergebnisse der Historien und vergleichen diese jeweils mit
den Ergebnissen der seriellen Historien T1 I T2, T2 I T1, T1 I T3 und T3 I T1.













 Fortgeschrittene Systementwicklung
Mehrbenutzersnychronisation
3. (max. 2Pkt.) Deadlock-Vermeidung
Spielen Sie für die Strategie wound-wait und wait-die die Fälle durch und zeigen so, dass es
keine Deadlocks geben kann.

Aufgaben

1. (max. 9 Pkt.) Serialisierbarkeit

Gegeben seien die beiden Mengen T1 und T2 an Transaktionen sowie die dazugehörigen Historien
H1, H2, welche jeweils durch ihre Folge von Elementaroperationen gegeben sind:

Ƭ1 = {T1, T2, T3, T4}

H1 = r3[d] → w3[c] → r2[c] → r3[a] → r4[b] → w2[d] → w4[a] → w2[b] → r1[b] → w2[a] → w1[c] →
c1 → c2 → c3 → c4.

Ƭ2 = {T1, T2, T3, T4, T5, T6}

H2 = r4[b] → r6[b] → w1[b] → r1[b] → w5[b] → r3[b] → w3[d] → w3[e] → w6[b] → r1[b] → w4[a] →
w4[c] → w2[c] → r6[d] → r1[e] → w5[a] → r4[d] → c1 → c2 → c3 → c4 → c5 → c6.

Zeichnen Sie für beide Mengen T1 und T2 den jeweiligen Serialisierbarkeitsgraphen SG(Hi).

Benennen Sie für jede Kante im Serialisierbarkeitsgraphen alle Paare pi → pj von Operationen, die
als Begründung für diese Kante genannt werden könnten.

Falls die Historie serialisierbar ist, geben Sie eine mögliche Reihenfolge an. Andernfalls geben Sie
eine (möglichst kleine) Menge an Transaktionen an, welche man aus der Historie streichen müsste
damit diese serialisierbar wird. Geben Sie anschließend dafür eine mögliche serielle Reihenfolge
an.

Beispiel: Für drei Transaktionen T1, T2, T3 mit der Historie:

w1[a] → r2[a] → w3[a] → w1[b] → w2[b] → w1[a] ergibt sich folgender Serialisierbarkeitsgraph

T1 T3

T2

Die Kanten sind wie folgt begründbar:

T1 → T2: w1[a] → r2[a], w1[b] → w2[b]




















Fortgeschrittene Systementwicklung
Mehrbenutzersnychronisation
T2 → T3: r2[a] → w3[a]

T1 → T3: w1[a] → w3[a]

T2 → T1: r2[a] → w1[a]

T3 → T1: w3[a] → w1[a]

Diese Historie ist nicht serialisierbar. Nach Entfernen der Transaktion T1 wird sie jedoch
serialisierbar. Eine gültige serielle Reihenfolge wäre dann T2 vor T3.

 Fortgeschrittene Systementwicklung
Mehrbenutzersnychronisation

2. (max. 2Pkt.) Bestimmen Sie alle Eigenschaften an, die von der Historie erfüllt werden und begründen
Ihre Zuordnung jeweils.

H1 = w1(x) ➔ r2(y)➔w3(y)➔w2(x)➔w3(z)➔ c3➔w1(z)➔ c2; c1

Ja nein Aussage
serialisierbar
rücksetzbar
Vermeidet kaskadierendes Zurücksetzen
Strikt

3. (max. 5 Pkt.) Wenden Sie eine zeitstempelbasierte Synchronisation am folgenden Beispiel an:

T1 T2 T3

Zeit

1 bot

2 bot

3 bot

4 r(A)

5 r(C)

6 w(A)

7 r(C)

8 w(C)

9 commit

10 r(B)

11 w(C)

12 commit

13 w(C)

14 w(A)

15 commit

Bearbeiten Sie die Historie aus Sicht eines Schedulers, indem Sie die Zeitstempel setzen und
jede Operation überprüfen. Nach einem möglichen Abbruch einer Transaktion braucht der
Wiederanlauf der Transaktion nicht bearbeitet zu werden. Sie können die nachfolgende
Vorlage verwenden:







Fortgeschrittene Systementwicklung
Mehrbenutzersnychronisation

T1 T2 T3 A B C
Zeit
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

Fortgeschrittene Systementwicklung
Mehrbenutzersnychronisation