1 kapitel 13: mehrbenutzersynchronisation oliver vornberger fachbereich mathematik/informatik...

Download 1 Kapitel 13: Mehrbenutzersynchronisation Oliver Vornberger Fachbereich Mathematik/Informatik Universität Osnabrück 49069 Osnabrück oliver@uos.de

Post on 05-Apr-2015

104 views

Category:

Documents

1 download

Embed Size (px)

TRANSCRIPT

  • Folie 1
  • 1 Kapitel 13: Mehrbenutzersynchronisation Oliver Vornberger Fachbereich Mathematik/Informatik Universitt Osnabrck 49069 Osnabrck oliver@uos.de
  • Folie 2
  • 2 Multiprogramming Zeitachse T 2 T 3 T 1 Einbenutzer betrieb T 1 T 2 T 3 Mehrbenutzer betrieb
  • Folie 3
  • 3 Lost Update T 1 T 2 read(A, a 1 ) a 1 := a 1 - 300 read(A, a 2 ) a 2 := a 2 * 1.03 write(A, a 2 ) write(A, a 1 ) read(B, b 1 ) b 1 := b 1 + 300 write(B, b 1 )
  • Folie 4
  • 4 Dirty Read T 1 T 2 read(A, a 1 ) a 1 := a 1 300 write(A, a 1 ) read(A, a 2 ) a 2 := a 2 * 1.03 write(A, a 2 ) read(B, b 1 )... abort
  • Folie 5
  • 5 Phantomproblem T1T2 select sum(KontoStand) from Konten; insert into Konten values (C, 1000,...); select sum(KontoStand) from Konten;
  • Folie 6
  • 6 Historie, Schedule Wichtig: Lese/Schreiboperationen Unwichtig: lokale Variable Historie = Schedule = Festlegung fr die Reihenfolge smtlicher relevanter Datenbankoperationen. seriell =alle Schritte einer Transaktion unmittelbar hintereinander serialisierbar =es gibt ein serielles quivalentes Schedule
  • Folie 7
  • 7 Schedule T1T2T1T2 BOT read(A) write(A) read(B) write(B) commit BOT read(C) write(C) read(A) write(A) commit BOT read(A) BOT read(C) write(A) write(C) read(B) write(B) commit read(A) write(A) commit T1T2T1T2 nichtseriellseriell serialisierbar
  • Folie 8
  • 8 Nicht serialisierbares Schedule T 1 T 3 BOT read(A) write(A) BOT read(A) write(A) read(B) write(B) commit read(B) write(B) commit wegen A: T 1, dann T 3 wegen B: T 3, dann T 1
  • Folie 9
  • 9 Semantik Betrag berweisen T 1 T 3 BOT read(A, a 1 ) a 1 := a 1 - 50 write(A, a 1 ) BOT read(A, a 2 ) a 2 := a 2 - 100 write(A, a 2 ) read(B, b 2 ) b 2 := b 2 + 100 write(B, b 2 ) commit read(B, b 1 ) b 1 := b 1 + 50 write(B, b 1 ) commit Zufllig ist Reihenfolge unerheblich !
  • Folie 10
  • 10 Semantik Zinsen gutschreiben T 1 T 3 BOT read(A, a 1 ) a 1 := a 1 - 50 write(A, a 1 ) BOT read(A, a 2 ) a 2 := a 2 * 1.03 write(A, a 2 ) read(B, b 2 ) b 2 := b 2 * 1.03 write(B, b 2 ) commit read(B, b 1 ) b 1 := b 1 + 50 write(B, b 1 ) commit 3 % Zinsen fehlen !
  • Folie 11
  • 11 Elementare Operationen r i (A) zum Lesen von Datenobjekt A, w i (A) zum Schreiben von Datenobjekt A, a i zur Durchfhrung eines abort, c i zur Durchfhrung eines commit.
  • Folie 12
  • 12 Vier Flle r i (A) und r j (A) : kein Konflikt, da Reihenfolge unerheblich r i (A) und w j (A) : Konflikt, da Reihenfolge entscheidend w i (A) und r j (A) : Konflikt, da Reihenfolge entscheidend w i (A) und w j (A) : Konflikt, da Reihenfolge entscheidend
  • Folie 13
  • 13 quivalenz Zwei Historien H 1 und H 2 ber der gleichen Menge von Transaktionen sind quivalent (in Zeichen H 1 H 2 ), wenn sie die Konfliktoperationen der nicht abgebrochenen Transaktionen in derselben Reihenfolge ausfhren. D. h. fr die durch H 1 und H 2 induzierten Ordnungen auf den Elementaroperationen < H1 bzw. < H2 wird verlangt: Wenn p i und q j Konfliktoperationen sind mit p i < H1 q j, dann mu auch p i < H2 q j gelten. Die Anordnung der nicht in Konflikt stehenden Operationen ist irrelevant.
  • Folie 14
  • 14 Testen auf Serialisierbarkeit Input:Eine Historie H fr Transaktionen T 1,..., T k. Output:entweder: nein, ist nicht serialisierbar oder ja, ist serialisierbar + serielles Schedule Idee:Bilde gerichteten Graph G, dessen Knoten den Transaktionen entsprechen. Fr zwei Konfliktoperationen p i, q j aus der Historie H mit p i < H q j fgen wir die Kante T i T j in den Graph ein.
  • Folie 15
  • 15 Serialisierbarkeitstheorem Eine Historie H ist genau dann serialisierbar, wenn der zugehrige Serialisierbarkeitsgraph azyklisch ist. Im Falle der Kreisfreiheit lt sich die quivalente serielle Historie aus der topologischen Sortierung des Serialisierbarkeitsgraphen bestimmen.
  • Folie 16
  • 16 Beispiel r 1 (A) r 2 (B) r 2 (C) w 2 (B) r 1 (B) w 1 (A) r 2 (A) w 2 (C) w 2 (A) r 3 (A) r 3 (C) w 1 (B) w 3 (C) w 3 (A) T 1 T 2 T 3 Konflikte: w 2 (B) < r 1 (B) w 1 (A) < r 2 (A) w 2 (C) < r 3 (C) w 2 (A) < r 3 (A) Kanten: T 2 T 1 T 1 T 2 T 2 T 3
  • Folie 17
  • 17 Sperrbasierte Synchronisation Stelle durch Sperren die Serialisierbarkeit sicher: S (shared, read lock, Lesesperre): Wenn Transaktion T i eine S-Sperre fr Datum A besitzt, kann T i read(A) ausfhren. Mehrere Transaktionen knnen gleichzeitig eine S-Sperre auf demselben Objekt A besitzen X (exclusive, write lock, Schreibsperre): Ein write(A) darf nur die eine Transaktion ausfhren, die eine X-Sperre auf A besitzt.
  • Folie 18
  • 18 Kompatibilittsmatrix NLSX S - X --
  • Folie 19
  • 19 Zwei-Phasen-Sperrprotokoll Jedes Objekt mu vor der Benutzung gesperrt werden. Eine Transaktion fordert eine Sperre, die sie schon besitzt, nicht erneut an. Eine Transaktion respektiert vorhandene Sperren gem der Vertrglichkeitsmatrix und wird ggf. in eine Warteschlange eingereiht. Jede Transaktion durchluft eine Wachstumsphase (nur Sperren anfordern) und dann eine Schrumpfungsphase (nur Sperren freigeben). Bei Transaktionsende mu eine Transaktion alle ihre Sperren zurckgeben
  • Folie 20
  • 20 2-Phasen-Sperrprotokoll
  • Folie 21
  • 21 2-Phasen-Sperrprotokoll BOT lockX(A) read(A) write(A) BOT lockS(A)T 2 mu warten lockX(B) read(B) unlockX(A) T 2 wecken read(A) lockS(B)T 2 mu warten write(B) unlockX(B) T 2 wecken read(B) commit unlockS(A) unlockS(B) commit T 1 T 2
  • Folie 22
  • 22 Verklemmungen BOT lockX(A) BOT lockS(B) read(B) read(A) write(A) lockX(B)T 1 mu warten auf T 2 lockS(A)T 2 mu warten auf T 1...... Deadlock T 1 T 2
  • Folie 23
  • 23 Wartegraphen KnotenTransaktionen Kante von T i nach T j T i wartet auf T j Satz: Deadlock Zyklus im Wartegraph
  • Folie 24
  • 24 Zurcksetzen einer Transaktion Minimierung des Rcksetzaufwandes: Whle jngste beteiligte Transaktion. Maximierung der freigegebenen Resourcen: Whle Transaktion mit den meisten Sperren. Vermeidung von Verhungern (engl. Starvation): Whle nicht diejenige Transaktion, die schon oft zurckgesetzt wurde. Mehrfache Zyklen: Whle Transaktion, die an mehreren Zyklen beteiligt ist.
  • Folie 25
  • 25 Hierarchie der Sperrgranulate Datenbasis Segmente Seiten Stze
  • Folie 26
  • 26 Granularitt Bei zu kleiner Granularitt werden Transaktionen mit hohem Datenzugriff stark belastet. Bei zu groer Granularitt wird der Parallelittsgrad unntig eingeschrnkt.
  • Folie 27
  • 27 Multiple granularity locking (MGL) NLkeine Sperrung (no lock) SSperrung durch Leser XSperrung durch Schreiber ISLesesperre (S) weiter unten beabsichtigt IXSchreibsperre (X) weiter unten beabsichtigt NLSXISIX S - - X - - - - IS - IX - -
  • Folie 28
  • 28 Protokoll Idee: vor dem Sperren erst geeignete Sperren in allen bergeordneten Knoten von oben nach unten anfordern. Bevor ein Knoten mit S oder IS gesperrt wird, mssen alle Vorgnger vom Sperrer im IX- oder IS-Modus gehalten werden. Bevor ein Knoten mit X oder IX gesperrt wird, mssen alle Vorgnger vom Sperrer im IX-Modus gehalten werden. Sperren von unten nach oben freigeben.
  • Folie 29
  • 29 Datenbasis-Hierarchie mit Sperren D a 1 a 2 s 1 p 1 s 2 s 3 p 2 s 4 s 5 p 3 s 6 T 1 IX T 1 X T 1 IX T 2 IS T 2 S T 3 X T 3 IXT 4 IX T 5 IS T 1 will X p 1 T 2 will S p 2 T 3 will X a 2 T 4 will X s 3 T 5 will S s 5
  • Folie 30
  • 30 Zeitstempelverfahren quivalenz zu seriellem Schedule gem Eintrittszeit Jede Transaktion erhlt Zeitstempel bei Eintritt ins System drckt einem Item seinen Zeitstempel auf Jedes Item hat Lesestempel = hchster Zeitstempel durch Leseoperation Schreibstempel = hchster Zeitstempel durch Schreiboperation
  • Folie 31
  • 31 Regeln Transaktion mit Zeitstempel t darf kein Item lesen mit Schreibstempel t w > t (denn der alte Item-Wert ist weg). Zurcksetzen ! Transaktion mit Zeitstempel t darf kein Item schreiben mit Lesestempel t r > t (denn der neue Wert kommt zu spt). Zurcksetzen ! Zwei Transaktionen knnen dasselbe Item zu beliebigen Zeitpunkten lesen. OK ! Transaktion mit Zeitstempel t darf kein Item beschreiben mit Schreibstempel t w > t ignorieren !
  • Folie 32
  • 32 Regeln Transaktion X mit Zeitstempel t bei Zugriff auf Item mit Lesestempel t r und Schreibstempel t w : if (X = read) and (t t w ) fhre X aus und setze t r := max{t r, t} if (X = write) and (t t r ) and (t t w ) then fhre X aus und setze t w := t if (X = write) and ( t r t < t w ) tue nichts If (X = read and t < t w ) or (X = write and t < t r ) setze Transaktion zurck
  • Folie 33
  • 33 Beispiel fr Zeitstempelverfahren Stempel 150 160 Item a hat t r = t w = 0 read(a) t r := 150 read(a) t r := 160 a := a - 1 write(a) ok, da 160 t r = 160 und 160 t w = 0 t w := 160 write(a) T 1 wird zurckgesetzt, da 150 < t r = 160 T1 T2
  • Folie 34
  • 34 Beispiel fr Zeitstempelverfahren 200150175t r = 0t r = 0t r = 0 t w = 0t w = 0t w = 0 read(b)t r = 200 read(a)t r = 150 read(c)t r = 175 write(b)t w = 200 write(a)t w = 200 write(c) Abbruch write(a) ignoriert T1T2T3abc

Recommended

View more >