9. Vorlesung Betriebssysteme

Transkript

1 Dr. Christian Baun 9. Vorlesung Betriebssysteme Hochschule Mannheim WS1213 1/39 9. Vorlesung Betriebssysteme Dr. Christian Baun Hochschule Mannheim Fakultät für Informatik

2 Dr. Christian Baun 9. Vorlesung Betriebssysteme Hochschule Mannheim WS1213 2/39 Heute Interprozesskommunikation Kritische Abschnitte Wettlaufsituationen (Race Conditions) Kommunikation vs. Kooperation Synchronisation von Prozessen Aktives Warten Blockieren und Deblockieren Gruppensignalisierung (Barrieren) Sperren Verhungern und Deadlocks Betriebsmittel-Graphen Deadlock-Erkennung mit Matrizen

3 Dr. Christian Baun 9. Vorlesung Betriebssysteme Hochschule Mannheim WS1213 3/39 Interprozesskommunikation (IPC) Prozesse, die an einer gemeinsamen Aufgabe arbeiten, müssen nicht nur Operationen auf Daten ausführen, sondern auch: sich gegenseitig aufrufen aufeinander warten sich abstimmen kurz gesagt: Sie müssen miteinander interagieren Bei der Interprozesskommunikation (IPC) ist zu klären: Wie kann ein Prozess Informationen an andere weiterreichen? Wie kann sichergestellt werden, dass zwei oder mehr Prozesse, die auf die gleiche Ressource zugreifen wollen, sich nicht in die Quere kommen? Frage: Wie verhält es sich hier mit Threads? Bei Threads gelten die gleichen Herausforderungen und Lösungen wie bei Interprozesskommunikation mit Prozessen Nur die Kommunikation zwischen den Threads eines Prozesses ist problemlos möglich, weil sie im gleichen Adressraum agieren

4 Dr. Christian Baun 9. Vorlesung Betriebssysteme Hochschule Mannheim WS1213 4/39 Kritische Abschnitte Auf Systemen, auf denen mehrere Prozesse laufen, müssen die Prozesse Daten austauschen und Ressourcen gemeinsam nutzen Laufen mehrere parallel ausgeführte Prozesse, unterscheidet man: Unkritische Abschnitte: Die Prozesse greifen gar nicht oder nur lesend auf gemeinsame Daten zu Kritische Abschnitte: Die Prozesse greifen lesend und schreibend auf gemeinsame Daten zu Damit Prozesse auf gemeinsam genutzten Speicher zugreifen können, ist wechselseitiger Ausschluss (Mutual Exclusion) notwendig Kritische Abschnitte dürfen nicht von mehreren Prozessen gleichzeitig durchlaufen werden

5 Dr. Christian Baun 9. Vorlesung Betriebssysteme Hochschule Mannheim WS1213 5/39 Kritische Abschnitte Beispiel: Drucker-Spooler (1/2)

6 Dr. Christian Baun 9. Vorlesung Betriebssysteme Hochschule Mannheim WS1213 6/39 Kritische Abschnitte Beispiel: Drucker-Spooler (2/2) Prozess X next_free_slot = in; (16) Speichere Eintrag in next_free_slot; (16) in = next_free_slot + 1; (17) Prozesswechsel Prozesswechsel Prozess Y next_free_slot = in; (16) Speichere Eintrag in next_free_slot; (16) in = next_free_slot + 1; (17) Das Spooler-Verzeichnis ist konsistent, aber der Eintrag von Prozess Y wurde von Prozess X überschrieben und ging verloren Eine solche Situation heißt Race Condition

7 Dr. Christian Baun 9. Vorlesung Betriebssysteme Hochschule Mannheim WS1213 7/39 Race Condition (Wettlaufsituation) Unbeabsichtigte Wettlaufsituation zweier Prozesse, die auf die gleiche Speicherstelle schreibend zugreifen wollen Das Ergebnis eines Prozesses hängt von der Reihenfolge oder dem zeitlichen Ablauf anderer Ereignisse ab Häufiger Grund für schwer auffindbare Programmfehler Problem: Das Auftreten und die Symptome hängen von unterschiedlichen Ereignissen ab Bei jedem Testdurchlauf können die Symptome komplett verschieden sein oder verschwinden Vermeidung ist u.a durch das Konzept der Semaphore möglich

8 Dr. Christian Baun 9. Vorlesung Betriebssysteme Hochschule Mannheim WS1213 8/39 Beispiel einer Race Condition (1/2) Der Wert einer Speicherstelle ist 5 Zwei voneinander unabhängige Prozesse wollen auf die Speicherstelle zugreifen und jeweils den gespeicherten Wert um 2 erhöhen Eine Ausführungsreihenfolge mit korrektem Ergebnis wäre z.b: 1. Prozess X liest Wert in internen Speicher = X=5 2. Prozess X erhöht intern den Wert um 2 = X=7 3. Prozess X schreibt neuen Wert in den Speicher = Speicher=7 4. Prozess Y liest Wert in internen Speicher = Y=7 5. Prozess Y erhöht intern den Wert um 2 = Y=9 6. Prozess Y schreibt neuen Wert in den Speicher = Speicher=9

9 Dr. Christian Baun 9. Vorlesung Betriebssysteme Hochschule Mannheim WS1213 9/39 Beispiel einer Race Condition (2/2) Wollen beide Prozesse gleichzeitig auf die Speicherstelle zugreifen, kommt es zu einer Race Condition und einem fehlerhaften Ergebnis 1. Prozess X liest Wert in internen Speicher = X=5 2. Prozess Y liest Wert in internen Speicher = Y=5 3. Prozess X erhöht intern den Wert um 2 = X=7 4. Prozess Y erhöht intern den Wert um 2 = Y=7 5. Prozess X schreibt neuen Wert in den Speicher = Speicher=7 6. Prozess Y schreibt neuen Wert in den Speicher = Speicher=7 Wie kann man eine Race Condition verhindern? Beim Zugriff auf den Wert der Speicherstelle muss diese bis zum Abschluss des Zugriffs gesperrt werden In diesem Fall muss Prozess Y warten, bis Prozess X den neuen Wert in die Speicherstelle geschrieben hat

10 Dr. Christian Baun 9. Vorlesung Betriebssysteme Hochschule Mannheim WS /39 Therac-25: Race Condition mit tragischem Ausgang Bekanntes Lehrbeispiel für (fehlende) Software-Qualität Therac-25, ein Elektronen-Linearbeschleuniger zur Strahlentherapie von Krebstumoren, verursachte Mitte der 80er Jahre in den USA sechs Unfälle durch mangelhafte Programmierung und Qualitätssicherung Die Patienten erhielten eine massiv erhöhte Strahlendosis Dabei wurde eine bis zu hundertfach erhöhte Bestrahlung verabreicht Drei Patienten starben direkt an den Folgen der Programmierfehler Zwei Patienten starben durch eine Race Condition, die zu inkonsistenten Einstellungen des Gerätes und damit zu erhöhter Strahlendosis führte Der Kontroll-Prozess synchronisierte nicht korrekt mit dem Prozess der Eingabeaufforderung Der Fehler trat nur dann auf, wenn die Bedienung zu schnell erfolgte Bei Tests trat der Fehler nicht auf, weil es eine gewisse Erfahrung (Routine) in der Bedienung des Geräts erforderte, bis es so schnell bedient werden konnte

11 Dr. Christian Baun 9. Vorlesung Betriebssysteme Hochschule Mannheim WS /39 Kommunikation vs. Kooperation Die Prozessinteraktion besitzt zwei Aspekte: Funktionaler Aspekt: Kommunikation und Kooperation. Zeitlicher Aspekt: Synchronisation Kommunikation (= expliziter Datentransport) Prozess 1 Prozess 2 Kooperation (= Zugriff auf gemeinsame Daten) Prozess 1 Prozess 2 Daten 1 Daten 2 Kopieren Daten 1 gemeinsamer Teil Daten 2 (gerichtete Beziehung) (symmetrische Beziehung)

12 Dr. Christian Baun 9. Vorlesung Betriebssysteme Hochschule Mannheim WS /39 Interaktionsformen Kommunikation und Kooperation basieren auf der Synchronisation Synchronisation ist die elementarste Form der Interaktion Begründung: Kommunikation und Kooperation benötigen eine zeitliche Abstimmung zwischen den Intaraktionspartnern, um korrekte Ergebnisse zu erhalten Darum müssen wir zuerst die Synchronisation behandeln Kommunikation Kooperation Synchronisation

13 Dr. Christian Baun 9. Vorlesung Betriebssysteme Hochschule Mannheim WS /39 Synchronisation Synchronisation Signalisierung (aktives Warten) Signalisierung (blockieren, deblockieren) Wechselseitige Synchronisierung Gruppensignalisierung Barrieren Kritische Abschnitte Sperren

14 Dr. Christian Baun 9. Vorlesung Betriebssysteme Hochschule Mannheim WS /39 Signalisierung Signalisierung ist eine spezielle Art der Synchronisation Bei der Signalisierung wird eine Reihenfolgebeziehung hergestellt Beispiel: Abschnitt X von Prozess 1 soll vor Abschnitt Y von Prozess 2 ausgeführt werden Mit den Operationen signal und wait kann signalisiert werden, wenn Prozess 1 den Abschnitt X abgearbeitet hat Prozess 2 muss zur Laufzeit eventuell auf das Signal von Prozess 1 warten Prozess 1 Prozess 2 X signal(s) wait(s) Y

15 Dr. Christian Baun 9. Vorlesung Betriebssysteme Hochschule Mannheim WS /39 Grundform der Signalisierung (aktives Warten) In der einfachsten Form sehen die Operationen zur Signalisierung so aus: signal(s) wait(s) set s is s set? no reset s Diese Vorgehensweise ist aktives Warten an der Signalisierungsvariablen s und das bedeutet, dass Rechenzeit der CPU verschwendet wird, da diese immer wieder von dem Prozess belegt wird Diese Technik heißt auch Spinlock oder Warteschleife

16 Dr. Christian Baun 9. Vorlesung Betriebssysteme Hochschule Mannheim WS /39 Signalisierung (blockieren, deblockieren) Besser ist, den wartenden Prozess zu blockieren, bis Prozess 1 Abschnitt X abgearbeitet hat Das würde die CPU deutlich entlasten Nachteil: Beim Signalisieren mit Wartezustand kann immer nur ein Prozess warten signal(s) wait(s) set s is s set? no yes process waiting? block process yes no deblock process reset s

17 Dr. Christian Baun 9. Vorlesung Betriebssysteme Hochschule Mannheim WS /39 blockieren, deblockieren unter JAVA Unter JAVA heißt die signal()-operation notify() class Signal { private boolean set = false ; // Signalvariable public synchronized void signal () { set = true ; notify (); // deblockiert den wartenden Prozess } } public synchronized void wait () { if (! set ) wait (); // wartet auf das Signal set = false ; } Das Schlüsselwort synchronized sorgt unter JAVA für gegenseitigen Ausschluss aller damit gekennzeichneten Methoden eines Objekts Mit wait() wird ein Prozess in seiner Ausführung blockiert Mit notify() wird ein wartender Prozess deblockiert

18 Dr. Christian Baun 9. Vorlesung Betriebssysteme Hochschule Mannheim WS /39 Wechselseitige Synchronisierung Werden wait() und signal() symmetrisch ausgeführt, werden die Abschnitte X1 und Y1 vor den Abschnitten X2 und Y2 ausgeführt Prozess 1 Prozess 2 X1 signal(s) wait(s) X2 Y1 signal(s) wait(s) Y2 In einem solchen Fall synchronisieren die Prozesse 1 und 2 Es kommt zu einem Rendezvous bzw. Handshake

19 Dr. Christian Baun 9. Vorlesung Betriebssysteme Hochschule Mannheim WS /39 Wechselseitige Synchronisierung sync() sync() fasst die Operationen wait() und signal() zusammen Implementierung einer Synchronisierung unter JAVA class Synchronisierung { private boolean set = false ; // Signalvariable } public synchronized void sync () { if ( set == false ) { // ich bin der erste Prozess set = true ; // die Bereitschaft signalisieren wait (); // auf den anderen Prozess warten } else { // ich bin der zweite Prozess set = false ; // Signalvariable zurücksetzen notify (); // deblockiert den wartenden Prozess } }

20 Dr. Christian Baun 9. Vorlesung Betriebssysteme Hochschule Mannheim WS /39 Gruppensignalisierung An einer Signalisierung können mehr als zwei Prozesse beteiligt sein In einem solchen Fall spricht man von Gruppensignalisierung Zwei Beispiele für Gruppensignalisierung: UND-Signalisierung: Ein Prozess darf in seiner Abarbeitung erst weiterlaufen, wenn mehrere Prozesse ein Signal gesetzt haben Es liegt eine UND-Verknüpfung auf der Signalisierungsseite vor ODER-Signalisierung: Mehrere Prozesse warten auf ein Signal Erfolgt das Signal, wird einer der wartenden Prozesse deblockiert Auf der Seite der wartenden Prozesse liegt eine ODER-Verknüpfung vor Alle möglichen Kombinationen der beiden Arten von Gruppensignalisierungen sind denkbar Bei Gruppensignalisierung sind in der Signalimplementierung entsprechende Kapazitäten bzgl. der Signalvariablen notwendig

21 Dr. Christian Baun 9. Vorlesung Betriebssysteme Hochschule Mannheim WS /39 UND-Signalisierung / ODER-Signalisierung

22 Gruppensynchronisierung mit Barriere Eine Barriere synchronisiert die beteiligten Prozesse an einer Stelle Prozess 1 Prozess 2 Prozess 3 Prozess 4 X1 sync(s) X1 sync(s) X2 X1 sync(s) X1 sync(s) X2 X2 X2 Erst wenn alle Prozesse die Synchronisationsstelle erreicht haben, dürfen sie weiterlaufen Gruppenrendezvous class BarrierenSynchronisation { private int summe = p; // Anzahl Prozesse private int zaehler = 0; // Anzahl wartende Prozesse public synchronized void sync () { zaehler = zaehler + 1; if ( zaehler < summe ) { // es fehlen noch Prozesse wait (); // auf die fehlenden Prozesse warten } else { // es sind alle Prozesse eingetroffen notifyall (); // alle wartenden Prozesse deblockieren zaehler = 0; } } } Dr. Christian Baun 9. Vorlesung Betriebssysteme Hochschule Mannheim WS /39

23 Dr. Christian Baun 9. Vorlesung Betriebssysteme Hochschule Mannheim WS /39 Sperren Mit Sperren sichert man kritische Abschnitte Prozess 1 Prozess 2 X lock(s) unlock(s) lock(s) Y unlock(s) Sperren garantieren, dass es bei der Abarbeitung zweier kritischer Abschnitte wie X von Prozess 1 und Y von Prozess 2 keine Überlappung gibt Die Ausführungen der Prozesse 1 und 2 schließen sich gegenseitig aus

24 Dr. Christian Baun 9. Vorlesung Betriebssysteme Hochschule Mannheim WS /39 Sperren und Freigeben Die Signalvariable s wird bei lock() anders als bei signal() in einer Schleife abgefragt, da zwischen dem Deblockieren des wartenden Prozesses und dem Setzen der Sperre ein anderer Prozess die Sperre setzen könnte unlock(s) lock(s) reset s is s set? yes no prozess waiting? block process yes no deblock prozess set s

25 Dr. Christian Baun 9. Vorlesung Betriebssysteme Hochschule Mannheim WS /39 Unterschied zwischen Signalisierung und Sperren Signalisierung legt eine Reihenfolgebeziehung zwischen Prozessen fest Beispiel: Abschnitt A von Prozess P 1 vor Abschnitt B von P 2 ausführen Sperren sichern kritische Abschnitte Die Reihenfolge, in der die Prozesse ihre kritische Abschnitte abarbeiten, ist nicht festgelegt! Es wird nur sichergestellt, dass es keine Überlappung in der Ausführung der kritischen Abschnitte gibt class Sperre { private boolean gesperrt = false ; // Signalvariable public synchronized void sperre () { while ( gesperrt ) wait (); // auf die fehlenden Prozesse warten gesperrt = true ; // den Prozess sprerren } } public synchronized void entsperren () { gesperrt = false ; // die Sperre für den Prozess aufheben notify (); // alle wartenden Prozesse benachrichtigen }

26 Dr. Christian Baun 9. Vorlesung Betriebssysteme Hochschule Mannheim WS /39 Probleme, die durch Sperren entstehen Verhungern (Starving) Hebt ein Prozess eine Sperre nicht wieder auf, müssen die anderen Prozesse unendlich lange auf die Freigabe warten Verklemmung (Deadlock) Warten zwei Prozesse gegenseitig auf die von ihnen gesperrten Ressourcen, sperren sie sich gegenseitig Da alle am Deadlock beteiligten Prozesse (ewig) warten, kann keiner ein Ereignis auslösen, so dass ein anderer geweckt wird

27 Dr. Christian Baun 9. Vorlesung Betriebssysteme Hochschule Mannheim WS /39 Ein Deadlock-Beispiel aus der realen Welt (São Paulo)

28 Dr. Christian Baun 9. Vorlesung Betriebssysteme Hochschule Mannheim WS /39 Weitere Deadlock-Beispiele aus Tel Aviv und Moskau

29 Dr. Christian Baun 9. Vorlesung Betriebssysteme Hochschule Mannheim WS /39 Bedingungen für Deadlocks Damit ein Deadlock entstehen kann, müssen laut Coffman et al. (1971) die folgenden vier Bedingungen alle gleichzeitig erfüllt sein: Wechselseitiger Ausschluss Jede Ressource wird von genau einem Prozess belegt oder ist verfügbar Anforderung weiterer Betriebsmittel Ein Prozess, der bereits Ressourcen besitzt, kann weitere anfordern Ununterbrechbarkeit Die Ressourcen, die ein Prozess besitzt, können nicht von außen entzogen, sondern nur durch ihn selbst freigegeben werden Zyklische Wartebedingung Es gibt eine zyklische Kette von Prozessen Jeder Prozess fordert eine Ressource an, die der nächste Prozess in der Kette besitzt Fehlt eine der Bedingungen, ist ein Deadlock unmöglich

30 Dr. Christian Baun 9. Vorlesung Betriebssysteme Hochschule Mannheim WS /39 Betriebsmittel-Graphen Mit gerichteten Graphen können die Beziehungen von Prozessen und Ressourcen dargestellt werden Mit Betriebsmittel-Graphen kann man Deadlocks modellieren Bei den Knoten eines Betriebsmittel-Graphen handelt es sich um: Prozesse: Sind als Kreise dargestellt Ressourcen: Sind als Rechtecke dargestellt Eine Kante von einem Prozess zu einer Ressource bedeutet: Der Prozess ist blockiert, weil er auf die Ressource wartet Eine Kante von einer Ressource zu einem Prozess bedeutet: Der Prozess belegt die Ressource

31 Dr. Christian Baun 9. Vorlesung Betriebssysteme Hochschule Mannheim WS /39 Prinzip von Betriebsmittel-Graphen

32 Dr. Christian Baun 9. Vorlesung Betriebssysteme Hochschule Mannheim WS /39 Beispiel zu Betriebsmittel-Graphen Es existieren drei Prozesse: P1, P2 und P3 Jeder Prozess fordert zwei Ressourcen an und gibt diese dann wieder frei Prozess P1 Prozess P2 Prozess P3 Anforderung R1 Anforderung R2 Anforderung R3 Anforderung R2 Anforderung R3 Anforderung R1 Freigabe R1 Freigabe R2 Freigabe R3 Freigabe R2 Freigabe R3 Freigabe R1 Beispiel aus Tanenbaum. Moderne Betriebssysteme. Pearson Studium. 2003

33 Dr. Christian Baun 9. Vorlesung Betriebssysteme Hochschule Mannheim WS /39 Keine Nebenläufigkeit: P1 P2 P3 P1 R1 R2 R3 P2 R1 R2 R3 P3 R1 R2 R3 P1 fordert R1 an P1 fordert R2 an P1 gibt R1 frei P1 gibt R2 frei P2 fordert R2 an P2 fordert R3 an P2 gibt R2 frei P2 gibt R3 frei P3 fordert R3 an P3 fordert R1 an P3 gibt R3 frei P3 gibt R1 frei Kein Deadlock

34 Dr. Christian Baun 9. Vorlesung Betriebssysteme Hochschule Mannheim WS /39 Nebenläufigkeit mit schlechter Reihenfolge P1 fordert R1 an P2 fordert R2 an P3 fordert R3 an P1 fordert R2 an P2 fordert R3 an P3 fordert R1 an Deadlock wegen Zyklus

35 Dr. Christian Baun 9. Vorlesung Betriebssysteme Hochschule Mannheim WS /39 Nebenläufigkeit mit besserer Reihenfolge P1 fordert R1 an P3 fordert R3 an P1 fordert R2 an P3 fordert R1 an P1 gibt R1 frei P1 gibt R2 frei P3 gibt R1 frei P3 gibt R3 frei P2 fordert R2 an P2 fordert R3 an P2 gibt R2 frei P2 gibt R3 frei

36 Dr. Christian Baun 9. Vorlesung Betriebssysteme Hochschule Mannheim WS /39 Deadlock-Erkennung mit Matrizen Gibt es nur eine Ressource pro Ressourcenklasse (Scanner, CD-Brenner, Drucker, usw.), kann man Deadlocks mit Graphen darstellen/erkennen Existieren von einer Ressource mehrere Kopien, kann ein matrizenbasierter Algorithmus verwendet werden Wir definieren zwei Vektoren Ressourcenvektor (Existing Resource Vektor) Zeigt an, wie viele Ressourcen von jeder Klasse existieren Ressourcenrestvektor (Available Resource Vektor) Zeigt an, wie viele Ressourcen von jeder Klasse frei sind Zusätzlich sind zwei Matrizen nötig Belegungsmatrix (Current Allocation Matrix) Zeigt an, welche Ressourcen die Prozesse aktuell belegen Anforderungsmatrix (Request Matrix) Zeigt an, welche Ressourcen die Prozesse gerne hätten

37 Beispiel der Deadlock-Erkennung mit Matrizen (1/2) Beispiel aus Tannenbaum. Moderne Betriebssysteme. Pearson Ressourcenvektor = ( ) Ressourcenrestvektor = ( ) Es existieren 4 Ressourcen vom Typ 1 Es existieren 2 Ressourcen vom Typ 2 Es existieren 3 Ressourcen vom Typ 3 Es existiert 1 Ressource vom Typ 4 Belegungsmatrix = [ ] Es sind noch 2 Ressourcen vom Typ 1 frei Es ist noch 1 Ressource vom Typ 2 frei Es sind keine Ressourcen vom Typ 3 frei Es sind keine Ressourcen vom Typ 4 frei Anforderungsmatrix = [ ] Prozess 1 belegt 1 Ressource vom Typ 3 Prozess 2 belegt 2 Ressourcen vom Typ 1 und 1 Ressource vom Typ 4 Prozess 3 belegt 1 Ressource vom Typ 2 und 2 Ressourcen vom Typ 3 Prozess 1 kann nicht laufen, weil keine Ressource vom Typ 4 frei ist Prozess 2 kann nicht laufen, weil keine Ressource vom Typ 3 frei ist Prozess 3 kann weiterlaufen Dr. Christian Baun 9. Vorlesung Betriebssysteme Hochschule Mannheim WS /39

38 Dr. Christian Baun 9. Vorlesung Betriebssysteme Hochschule Mannheim WS /39 Beispiel der Deadlock-Erkennung mit Matrizen (2/2) Wurde Prozess 3 fertig ausgeführt, gibt er alle seine Ressourcen frei Ressourcenvektor = ( ) Ressourcenrestvektor = ( ) Es existieren 4 Ressourcen vom Typ 1 Es sind noch 2 Ressourcen vom Typ 1 frei Es existieren 2 Ressourcen vom Typ 2 Es sind noch 2 Ressourcen vom Typ 2 frei Es existieren 3 Ressourcen vom Typ 3 Es sind noch 2 Ressourcen vom Typ 3 frei Es existiert 1 Ressource vom Typ 4 Es sind keine Ressourcen vom Typ 4 frei Jetzt kann Prozess 2 weiterlaufen Wurde Prozess 2 fertig ausgeführt, gibt er alle seine Ressourcen frei ( ) ( ) Ressourcenvektor = Ressourcenrestvektor = Jetzt kann Prozess 1 weiterlaufen Somit gibt es in diesem Beispiel keinen Deadlock

39 Dr. Christian Baun 9. Vorlesung Betriebssysteme Hochschule Mannheim WS /39 Deadlocks sind immer möglich und werden akzeptiert Deadlocks sind in der Informatik immer möglich Bekannte, mögliche Deadlocks werden nicht immer entfernt Entscheidend ist, wie wichtig ein System ist Ein Deadlock, der statistisch alle 5 Jahre auftritt, ist kein Problem, wenn das System wegen Hardwareausfällen oder sonstigen Softwareproblemen jede Woche ein mal abstürzt Deadlock-Erkennung ist aufwendig und verursacht Overhead In allen Betriebssystemen sind Deadlocks möglich: Prozesstabelle voll Es können keine neuen Prozesse erzeugt werden Maximale Anzahl von Inodes vergeben Es können keine neuen Dateien und Verzeichnisse angelegt werden Die Wahrscheinlichkeit, dass so etwas passiert, ist gering, aber 0 Solche potentiellen Deadlocks werden akzeptiert, weil ein gelegentlicher Deadlock nicht so lästig ist, wie die ansonsten notwendigen Einschränkungen (z.b. nur ein Prozess, nur eine offene Datei)