1 / 62

Prozess-synchronisation

Prozess-synchronisation. Prozesskommunikation. Race Conditions, Semaphore. Anwendungen. Verklemmungen. Race conditions. Eine Fehlbuchung tritt nur auf, wenn Prozess den Prozess überholt („ race condition “). Beispiel: Kontoführung Paralleler Zugriff auf globale Variable.

tieve
Download Presentation

Prozess-synchronisation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Prozess-synchronisation

  2. Prozesskommunikation Race Conditions, Semaphore Anwendungen Verklemmungen R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  3. Race conditions Eine Fehlbuchung tritt nur auf, wenn Prozess den Prozess überholt („race condition“) Beispiel: Kontoführung Paralleler Zugriff auf globale Variable 15:00 Uhr Parallele Prozesse von vielen Benutzern arbeiten gleichzeitig auf den Daten. Falls gleichzeitig zwei Benutzer auf das gleiche Konto einzahlen möchten, so kann es sein, dass der Kontostand hinterher nicht stimmt. Ein solcher Fehler wird von keinem Kunden toleriert! Konto A= 300 € 500 € einzahlen 100 € abheben 15:01 C := read(A) B := read(A) 15:02 B := B + 500 C := C -100 15:03 B write(A) C write(A) 15:04 Konto A = 200 € Zeit R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  4. Race conditions Situation: Warteschlangeneintrag eines PCB Einhängen A Aushängen B (1) Lesen des Ankers: PointToB (1) Lesen des Ankers: PointToB (2) Setzen des NextZeigers:=PointToB (2) Lesen des NextZeigers:PointToC (3) Setzen des Ankers:=PointToA (3) Setzen des Ankers:=PointToC Problem: („Race conditions“: kontextbedingt, nicht-wiederholbare Effekte durch „überholende“ Prozesse) a) Unterbrechung beim Aushängen von B durch Einhängen von A  Prozeß A ist weg! b) Unterbrechung beim Einhängen von A durch Aushängen von B  Prozeß B bleibt erhalten! R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  5. Synchronisation: Forderungen (Dijkstra 1965) • Zwei Prozesse dürfen nicht gleichzeitig in ihren kritischen Abschnitten sein (mutual exclusion). • Jeder Prozeß, der am Eingang eines kritischen Abschnitts wartet, muß irgendwann den Abschnitt auch betreten dürfen: kein ewiges Warten darf möglich sein (fairness condition). • Ein Prozeß darf außerhalb eines kritischen Abschnitts einen anderen Prozeßnicht blockieren. • Es dürfen keine Annahmenüber die Abarbeitungsge-schwindigkeit oder Anzahl der Prozesse bzw. Prozessoren gemacht werden. R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  6. Synchronisierung: erster Versuch Prozeß 1 Prozeß 2 . . . . . . WHILE dran1 DO NoOp END; WHILE dran2 DO NoOp END; Kritischer Abschnitt Kritischer Abschnitt dran := 2; dran := 1; . . . . . . Naiver Ansatz: mutual exclusion mit globaler Variabler Wartesperre errichten, bis kritischer Abschnitt freiInitialdran=1 Problem: nur wechselseitige Benutzung des kritischen Abschnitts möglich, Prozeß blockiert sich nach Ausführung selbst. (nicht-notw. Blockade und fairness sind verletzt bei ewigem Warten) R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  7. Synchronisierung: zweiter Versuch Prozeß 1 Prozeß 2 . . . . . . WHILE drin2=TRUE WHILE drin1= TRUE DO NoOp END ; DO NoOp END; drin1 := TRUE; drin2 := TRUE; Kritischer Abschnitt Kritischer Abschnitt drin1 := FALSE; drin2 := FALSE; . . . . . . Verbesserung: Zugang nur blockiert beim Aufenthalt in krit. Abschnitt Problem: Initialisierung drin1=drin2=False keine mutual exclusion! drin1=True, drin2=False P2 ist blockiert ohne Sinn R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  8. Synchronisierung: Lösung Prozeß 1 Prozeß 2 . . . . . . Interesse1 := TRUE; Interesse2 := TRUE; dran := 1; dran := 2; WHILE dran=1 WHILE dran=2 AND Intere s se2=TRUE AND Intere s se1=TRUE DO NoOp END; DO NoOp END; Kritischer Abschnitt Kritischer Abschnitt Interesse1 := FALSE; Interesse2 := FALSE; . . . . . . Peterson 1981 Verbesserung: eine globale Variable, 2 Prozeß-Zustandsvariable. Initial Interesse1 = Interesse2 = FALSE R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  9. Lösung: Signale und Semaphoren Beispiel: paralleles Hochzählen z = 1, 2, 3, ... z global Prozeß 1 Prozeß 2 . . . . . . P(s) P(s) z :=z+1; WriteInteger(z) z :=z+1; WriteInteger(z) V(s) V(s) . . . . . . Peterson: Synchronisierung durch Signale (Interesse) Allgemein: Das Semaphor(Signalbarken, Dijkstra 1965) • Passieren P(s) waitFor (signal) Aufruf vor krit. Abschnitt, Warten falls besetzt • Verlassen V(s)send (signal) Aufruf nach krit. Abschnitt, Aktivieren eines wart. Prozesses warten freigeben R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  10. Implementierung Semaphoren: busy wait Software Pseudo-Code Semaphore=Zähler, initial s=1 PROCEDURE P(VAR s:INTEGER) BEGIN WHILE s<=0 DO NoOp END; Ununterbrechbar! s:=s-1; END P; PROCEDURE V(VAR s:INTEGER) BEGIN s:=s+1; Ununterbrechbar! END V; Problem: spin locks können fairness verletzten, wenn die Zeitscheibe eines niedrig-prio Prozeß im krit. Abschnitt zu Ende geht R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  11. Implementierung Semaphoren: Schlafen Software Pseudo-CodeDatenstruktur PROCEDURE P(VAR s:Semaphor) BEGIN s.value:=s.value-1; IF s.value < 0 THEN einhängen(MyID,s.list); sleep; END; END P; PROCEDURE V(VAR s:Semaphor) VAR PID: ProcessId; BEGIN IF s.value < 0 THEN PID:=aushängen(s.list); wakeup(PID); END; s.value:=s.value +1; END V; TYPE Semaphor = RECORD value: INTEGER; list : ProcessList; END; Initial: s.value:=1 R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  12. Atomare Aktionen Computerabsturz ! Beispiel: Geldtransaktion Sie überweisen 2000 €. Abbuchung 2000 € Empfänger-Gutbuchung 2000 € Wo ist das Geld? Keine oder neue Überweisung = Verlust! Forderung: „Atomare Aktion“ Entweder vollständige Transaktion oder gar keine ! („roll back“ bei Abbruch) R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  13. HW-Implementierung: Atomare Aktionen • Interrupts ausschalten(Probleme: timer, power failure, I/O) • Atomare Instruktionsfolgen • Test And Set(test and set lock) PROCEDURE TestAndSet(VAR target:BOOLEAN): BOOLEAN VAR tmp:BOOLEAN; tmp:=target; target:= TRUE; RETURN tmp; END TestAndSet; • Swap PROCEDURE swap(VAR source,target: BOOLEAN) VAR tmp:BOOLEAN; tmp:=target; target:=source; source:=tmp; END swap; • Fetch And Add PROCEDURE fetchAndAdd(VAR a, value:INTEGER):INTEGER VAR tmp:INTEGER; tmp:=a; a:=tmp+value; RETURN tmp; END fetchAndAdd; R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  14. Implementierung Semaphoren: busy wait Software Pseudo-Code Semaphore=Zähler, initials=1 PROCEDURE P(VAR s:INTEGER) BEGIN WHILE FetchAndAdd(s,-1)<= 0 Ununterbrechbar! DO FetchAndAdd(s,+1) END END P PROCEDURE V(VAR s:INTEGER) BEGIN FetchAndAdd(s,+1)Ununterbrechbarlem! END V Probleme? R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  15. Anwendung Multiprozessoren Implementierung der Semaphor-Operationen, AnwendungMultiprozessorsynchronisation VAR s: INTEGER; (* Semaphore, initial = 1*) PROCEDURE P(s); PROCEDURE V(s); BEGIN BEGIN LOOPFetchAndAdd(s,1) END V; IF (FetchAndAdd(s,-1) >= 1) THEN RETURN END; FetchAndAdd(s,1); ENDLOOP; ENDP; S= 1, 0, -1, 0, -1 WHILE s<1 DO NoOp END; .... P3P3 P1 P3 P2 P2 P2 P1 R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  16. Semaphoren: Unix • lockf Sperren Dateizugriff P(s) lock file memory msem_init Semaphorinit. zumSpeicherzugriff msem_lock Sperren eines Semaphors P(s) msem_unlockEntsperren eines Semaphors V(s) msem_removeEntfernen eines Semaphors semctl Semaphorkontrolloperationen semget hole Semaphorwert semop Semaphoroperation Prozesse R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  17. Frage • Angenommen, Sie haben 3 Prozesse und 2 kritische Abschnitte pro Prozess. WievieleSemaphore benötigen Sie? • 2 • 3 • 6 • 12 Code A Code B Code C Krit. Abschn. Krit. Abschn. Krit. Abschn. Code A Code B Code C Krit. Abschn. Krit. Abschn. Krit. Abschn. Code A Code B Code C R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  18. Semaphore: Windows NT Prozesse • CreateSemaphore()Erzeugen • OpenSemaphore()Initialisieren • WaitForSingleObject(Sema,TimeOutVal) P(s) • ReleaseSemaphore()V(s) Threads Semaphore = Type CRITICAL_SECTION InitializeCriticalSection(S) EnterCriticalSection(S) P(s) LeaveCriticalSection(S) V(s) Kernprozesse Spin locks: keine Referenzen zu Disk-Speicher, keine traps & syscalls R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  19. Synchronisierung: Threads und Objekte Zwei Threads innerhalb eines Prozesses erzeugen das gleiche Objekt. DieMethoden beider Objekt-Instanzen greifen auf die gleichen globalen Daten (Attribute) zu. Chaos, wenn beide Threads auf die globalen Daten zugreifen. Problem: Object (Instanz 1) Thread 1 Globale Daten (static) Object (Instanz 2) Thread 2 R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  20. Lösung: Prozeßgruppen t1 t4 t5 t2 t6 Objekt 1 Objekt 1 Objekt 1 t3 t7 Objekt2 Objekt2 Objekt2 Apartment A Apartment C Apartment B Prozess X Prozess Y Mögliche Lösung: Sperrung der Objekte, Serialisierung des Zugriffs (marshalling) Nachteil: keine Parallelaktivitäten möglich! Windows NT:explizite Zuordnung der Threads zu Objektmengen (Apartments) R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  21. Lösung: Threadgruppen in NT Marshalling Marshalling Für jedes Objekt Speicherung des Threading-Modells (STA, MTA,both) in der Registrierung. MTA nur bei lokalen Daten ! main STA Thread 1 Objekt 1 Objekt 2 Single-Threaded Apartment STA Thread 2 Prozess Objekt 3 Multi-Threaded Apartment MTA Thread 3 Thread 4 Objekt 4 R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  22. Prozesskommunikation Race Conditions, Semaphore Anwendungen Verklemmungen R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  23. Anwendung: Synchr. von Prozessen • Präzedenzgraph Implementierung mit Semaphoren PROCESS A: TaskBodyA; V(b); V(c); END A; PROCESS B: P(b); TaskBodyB; V(d1);V(e); END B; PROCESS C: P(c); TaskBodyC; V(d2); END C; PROCESS D: P(d1); P(d2); TaskBodyD; END D; PROCESS E: P(e); TaskBodyE; END E; Globale Variableb,c,d1,d2,e mit 0 initialisieren. R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  24. Synch. Erzeuger-Verbraucher Umschaltung Problem: race condition innerhalb der Flusskontrolle bei Umschaltung nach „used=0“ Pufferfüllung, dann ewiges Schlafen beider Prozesse. Naiver Ansatz Initial: used = 0 Erzeuger Verbraucher LOOP LOOP produce(item) IF used=0 THEN sleep(); IF used=N THEN sleep(); getFromBuffer(item); putInBuffer(item); used := used-1 used := used+1; IF used = N-1 IF used=1 THEN wakeup(Erzeuger ); ); THENwakeup(Verbraucher consume(item); END LOOP END LOOP R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  25. Synch. Erzeuger-Verbraucher Lösung • Signal speichern. Aber: unbekannte Prozesszahl...? • Semaphor einführen: belegtePlätze := 0, freiePlätze := N, mutex := 1 Erzeuger Verbraucher LOOP LOOP produce( item) P(belegtePlätze); P(freiePlätze); P( mutex); P( mutex); getFromBuffer( item); putInBuffer( item); V( mutex); V( mutex); V(freiePlätze); V(belegtePlätze); consume( item); END LOOP END LOOP krit. Abschnittskontrolle + Flusskontrolle durch Semaphor R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  26. readers/writers - Problem Aufgabe: Koordination Lesen-Schreiben von Dateien • Erstesreaders/writers-Problem (Vorrang für Leser) Ein Leser soll nur warten, falls ein Schreiber bereits Zugriffsrecht zum Schreiben bekommen hat. Dies bedeutet, daß kein Leser auf einen anderen Leser warten muß, nur weil ein Schreiber wartet. Problem: Schreiber wartet ewig (verhungert!) • Zweitesreaders/writers-Problem (Vorrang für Schreiber) Wenn ein Schreiber bereit ist, führt er das Schreiben so schnell wie möglich durch. Wenn also ein Schreiber bereit ist, die Zugriffsrechte zu bekommen, dürfen keine neuen Leser mit Lesen beginnen. Problem: Leser wartet ewig (verhungert!) R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  27. Synchronisation readers/writers Semaphor ReadSem : Semaphor für Lese-Strategie WSem: Mutex f. Schreibvorgang LesenSchreiben P(ReadSem); readcount:=readcount+1; IF readcount=1 THEN P(WSem) END; V(ReadSem); . . . Reading_Data(); . . . P(ReadSem); readcount:=readcount-1; IF readcount=0 THEN V(WSem) END; V(ReadSem); P(WSem); . . . Writing_Data(); . . . V(WSem); R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  28. Multiprozessor-Synchronisation Warteschlangenmanagement beim NYU-Ultracomputer (1983) • FIFO-Ringpuffer im shared memory • Schutz der InSlot/OutSlot-Zeiger mittels FetchAndAdd • Puffermanagement full/empty RingBuf[0] RingBuf[N-1] RingBuf[1] InSlot OutSlot Init: 0 Init: 0 Fix InUse R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  29. Multiprozessor-Synchronisation Ein/Aushängen bei der ready-queue Einhängen Aushängen IF IF InUse >= N Fix <= 0 THEN THEN Full:=TRUE; RETURN Empty:=TRUE; RETURN END END ; ; IF IF FetchAndAdd(InUse,1)>=N FetchAndAdd(Fix,-1)<=0 THEN THEN FetchAndAdd(InUse,-1); FetchAndAdd(Fix,1); Full:=TRUE; RETURN Empty:=TRUE; RETURN END END ; ; MyInSlot:=FetchAndAdd MyOut Sl ot:=FetchAndAdd (InSlot,1)MOD N; (OutSlot,1)MOD N ; P P ( InSem[ MyInSlot]); ( OutSem[ MyOutSlot]); RingBuf[ MyInSlot]:= data; data:= RingBuf[ MyOutSlot]; V V ( OutSem[ MyInSlot]); ( InSem[ MyOutSlot]); FetchAndAdd(Fix,1); FetchAndAdd(InUse,-1); R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  30. Frage • Warum benötigt man bei jedem einzelnen Slot einen P/V-Mechanismus? • Warum reicht der FetchAndAdd-Mechanismus nicht aus? • Antwort FetchAndAdd ist für die Flußsteuerung nötig, aber reicht nicht für den Slot-Schut etwa bei halb gefülltem Puffer. R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  31. Fehler bei Semaphoranwendung Erzeuger P(freiePlätze); P(mutex); putInBuffer(item); V(mutex); V(belegtePlätze); Erzeuger P(mutex); P(freiePlätze); putInBuffer(item); V(mutex); V(belegtePlätze); Mögliche Fehler bei P/V-Anwendung • Vertauschung : alle sind nur gleichzeitig im krit. Abschnitt V(mutex); ... krit. Abschnitt ...; P(mutex); • Replikation oder Weglassen:ewiges Warten P(mutex); ...krit. Abschnitt ...; P(mutex); • Falsche ReihenfolgeErzeuger-Verbraucher-Problem R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  32. Monitore Lösung: Syntaktische Kapselung des kritischen Bereichs • critical region Shared s (Semaphor) regionsdo <statement> mutual exclusion  P(s); <statement>; V(s) • conditionalcritical region region s when B do <statement> • Abstrakter Datentyp Monitor interner, automatischer Schutz von Daten und Methoden durch Compiler MONITOR <name> (* lokale Daten und Prozeduren *) PUBLIC (* Methoden der Schnittstelle nach außen *) BEGIN(*Initialisierung *) ... ENDMONITOR R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  33. Monitore: Java Konstrukt synchronized (<expression>) <statement> • Thread wartet, bis <expression> frei ist (automat. Semaphor). • Innerhalb eines synchronized-Bereichs kann man zusätzlich mit den Methoden wait() auf ein Signal warten, das mit notify() gesendet wird, etwa zur Flusskontrolle. R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  34. Monitore: Erzeuger/Verbraucher Erzeuger Verbraucher LOOP LOOP produce( item) Buffer.getFromBuffer( item) Buffer.putInBuffer( item) consume( item); END END MONITOR Buffer; Schnittstelle TYPE Item = ARRAY[1..M] of BYTE; VAR RingBuf: ARRAY[1..N] of Item; InSlot, (* 1. freier Platz *) OutSlot, (* 1. belegter Platz *) used: INTEGER; PUBLICPROCEDURE putInBuffer(item:Item); BEGIN ... END; PROCEDURE getFromBuffer(VAR item:Item); BEGIN ... END; BEGIN used:=0; InSlot:=1; OutSlot:=1; END MONITOR; R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  35. Monitore: Flußkontrolle Erzeuger/Verbraucher: Zusätzliche Flußkontrolle nötig CONDITION s • Signal(s) sendet Signal s an alle, die im Monitor warten • Wait(s) wartet auf ein Signal Beispiel CONDITION frei, belegt PROCEDURE getFromBuffer(VAR item:Item); IF used=0 THEN wait(belegt)END item := RingBuf[OutSlot]; used := used-1; OutSlot := (OutSlot+1) MOD N; signal(frei); END getFromBuffer; PROCEDURE putInBuffer(item:Item) IF used=N THEN wait(frei)END; RingBuf[InSlot]:=item; used := used+1; InSlot := (InSlot+1) MOD N; signal(belegt); END putInBuffer; R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  36. Prozesskommunikation Race Conditions, Semaphore Anwendungen Verklemmungen R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  37. Verklemmungen • Beispiel R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  38. Verklemmungen (deadlocks) Beispiel: Datei bearbeiten und ausdrucken durch zwei Prozesse P1 P2 P2 hat den Drucker, will die Datei P1 hat die Datei, will den Drucker Drucker R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  39. Verklemmungen Notwendige und hinreichendeBedingungen (Coffman 1971) 1.Beschränkte Belegung(mutual exclusion) semaphorgeregelter Zugang 2.Zusätzliche Belegung(hold-and-wait) hat Drucker, will Datei 3.Keine vorzeitige Rückgabe (nopreemption) behält Datei bzw. Drucker 4.Gegenseitiges Warten(circularwait) P1 wartet auf P2, P2 wartet auf P1 R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  40. Verklemmungen Strategien: • das Problem ignorieren, • die Verklemmungen erkennen und beseitigen, • die Verklemmungen vermeiden, • die Verklemmungen unmöglich machen. eine der Bedingungen (1)–(4) verhindern R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  41. Verklemmungen • Erkennen und beseitigen Anzeichen: viele Prozesse warten, aber CPU ist idle Prozesse müssen zu lange warten Betriebsmittelgraph (resource allocation graph) P P B 1 3 3 B B P P 1 2 4 5 P B 2 4 Verklemmungsbedingungen erfüllt bei Zyklen im Graphen R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  42. Verklemmungen ES = Zahl der Betriebsmittel BM vom Typ S BKS = Zahl der von Prozeß K belegten BM vom Typ S CKS = Zahl der von Prozeß K geforderten BM vom Typ S verfügbare Zahl der BM vom Typ S Erkennungsalgorithmus für Verklemmung (0) Alle Prozesse sind unmarkiert. (1) Suche einen unmarkiertenProzeß K, bei dem für alle Betriebsmittel S gilt ASCKS . (2) Falls ein solcher Prozeß existiert, markiere ihn und bilde AS:=AS+BKS . (3) Gibt es einen solchen Prozeß ? DANN erneut (1) und (2). • SONST STOP. Wenn ein unmarkierterProzeß ex. : Verklemmung ex ! R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  43. Verklemmungen • Erkennen: Beispielrechnung • Beseitigen • Prozesse abbrechen z.B. verklemmten Prozess oder Prozess mit notw. BM • Prozesse zurücksetzen auf check point und verklemmenden Prozess warten lassen • Betriebsmittel entziehen von verklemmtem Prozess und warten, bis BM frei werden. R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  44. Verklemmungen • Verklemmungsbedrohte Zustände vermeiden Test: Banker-Algorithmus (Dijkstra 1965) konservative Kreditausleihe eines Bankers:„Gib nur Kredit, wenn auch die Wünsche von anderen, vorgemerkten Kunden berücksichtigt werden können bei sichergestellter Rückzahlung“. „Verklemmung-JA“ = Verklemmungsbedrohung; sie muß nicht eintreten, wenn rechtzeitig BM zurückgegeben werden. Vermeidung: lehne eine neue BM-Anforderung ab, wenn der Test sagt, daß dies zu einer Verklemmung führen kann. Aber: Realität • unbekannte BM-Forderungen der Zukunft • Prozesszahl + BM-Zahl wechselt • Laufzeit- + Speicherintensiver Algorithmus R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  45. Verklemmungen • Unmöglich machen Verhindere eine der vier Bedingungen 1. Beschränkte Belegung (mutual exclusion) BM fest nur einem Service-Prozess zuordnen 2. Zusätzliche Belegung (hold-and-wait) • Nur ein BM pro Prozess (aber: lesen und drucken nicht gleichzeitig) • Alle nötigen BM auf einmal anfordern (nicht bekannt und Vergeudung!) • Alle BM zurückgeben vor Neuanforderung (Verwaltungsaufwand!) 3.Keine vorzeitige Rückgabe (nopreemption) Vorzeitiger Prozess-Abbruch kann Inkonsistenzen verursachen 4. Gegenseitiges Warten (circularwait) Ordnungsrelation für BM einführen (Linearisierung) R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  46. Verklemmungen BeispieleOrdnungsrelation • Durchnummerieren der BM derart, dass nur höhere Nummern angefordert werden (nicht immer möglich). • Anordnung in einer Hierarchie Prozeß E Prozeß A Prozeß A Prozeß C Supervision der record-Belegung R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  47. Frage • Angenommen, man kann bei der BM-Belegung einen Timer (Zeituhr) aufsetzen. Welche der vier notwendigen Bedingungen für Verklemmungen sind damit nicht erfüllt? • Anwort: Bedingung 3: nopremption, kein vorzeitiger Abbruch R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  48. Prozesskommunikation Race Conditions, Semaphore Anwendungen Verklemmungen R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  49. Prozeßkommunikation · · · broadcast multicast • Verbindungsanzahl unicast R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

  50. Prozeßkommunikation: Adressierung Eindeutige Adressierung: Qualifizierter ID mit IP Adresse = Prozeß-ID.RechnerName.Firma.Land z.B. 5024.hera.rbi.uni-frankfurt.de Problem: Prozeß wechselt ID bei Neustart, Aufgabe bleibt Lösung: logische ID, nicht physische. Beispiel: „Drucker“ Prädikatsadresse: Spezifikationen als Adresse (IF 386-CPU AND Java_installiert AND Drucker) =True: fühle dich angesprochen, sonst nicht. Arbeitsverteilung! R.Brause - SS 2011 - Betriebssysteme: ProzeßSynchronisation

More Related