Race Condition — Änderungen 7768 → 7787

Zeile 104:

Das Problem ist klar: Prozess A hat die Überprüfung nicht korrekt durchgesetzt und printer_reserved auf eins gesetzt, obwohl es das schon war. Dadurch druckt zuerst Prozess B, dann Prozess A und dann Prozess B. Die Folge ist logischerweise Chaos auf dem fertigen Blatt Papier. Und genau das ist eine Race Condition: Sie hängt davon ab, ob Prozess A mit der Überprüfung von printer_reserved und dem Setzen schnell genug fertig wird, bevor ihn der Scheduler unterbricht – quasi ein Wettlauf, ein „Race“, zwischen Scheduler und Prozess.

== Ja toll, und was jetzt? ==

Um mit Race Conditions umzugehen gibt es im Grunde genommen zwei Lösungen:

Im Fall des Druckers ist die Einrichtung eines Spooler-Prozesses am häufigsten verbreitet. Nur der Spooler allein darf überhaupt auf den Drucker zugreifen. Alle Druckaufträge werden an den Spooler geschickt und dann von diesem speziellen Prozess nacheinander an den Drucker geschickt. So kommt es natürlich nicht zu Race Conditions. Jedoch wird es nicht bei jeder Ressource möglich sein, einem Prozess den exklusiven Zugriff zu verleihen.

In anderen Fällen wird man versuchen, das Sperren der Ressource "atomar" zu gestalten, das heißt, nach einer Anweisung, die nicht unterbrochen werden kann, ist die Ressource gesperrt. Wenn die Ressource blockiert ist, wird der Prozess ebenfalls blockiert, und bei Freigabe der Ressource wieder aufgeweckt. Dies wird zum Beispiel durch Semaphoren umgesetzt, die eine atomare Funktion zum Sperren und Freigeben bereitstellen. Diese sind vom Betriebssystem privilegiert (z.B. indem sie als Syscall implementiert werden) und werden daher garantiert nicht vom Scheduler unterbrochen.

[[Kategorie:Glossar]]

@@ Zeile 104: / Zeile 104: @@
 Das Problem ist klar: Prozess A hat die Überprüfung nicht korrekt durchgesetzt und printer_reserved auf eins gesetzt, obwohl es das schon war. Dadurch druckt zuerst Prozess B, dann Prozess A und dann Prozess B. Die Folge ist logischerweise Chaos auf dem fertigen Blatt Papier. Und genau das ist eine Race Condition: Sie hängt davon ab, ob Prozess A mit der Überprüfung von printer_reserved und dem Setzen schnell genug fertig wird, bevor ihn der Scheduler unterbricht – quasi ein Wettlauf, ein „Race“, zwischen Scheduler und Prozess.
+== Ja toll, und was jetzt? ==
+Um mit Race Conditions umzugehen gibt es im Grunde genommen zwei Lösungen:
+Im Fall des Druckers ist die Einrichtung eines Spooler-Prozesses am häufigsten verbreitet. Nur der Spooler allein darf überhaupt auf den Drucker zugreifen. Alle Druckaufträge werden an den Spooler geschickt und dann von diesem speziellen Prozess nacheinander an den Drucker geschickt. So kommt es natürlich nicht zu Race Conditions. Jedoch wird es nicht bei jeder Ressource möglich sein, einem Prozess den exklusiven Zugriff zu verleihen.
+In anderen Fällen wird man versuchen, das Sperren der Ressource "atomar" zu gestalten, das heißt, nach einer Anweisung, die nicht unterbrochen werden kann, ist die Ressource gesperrt. Wenn die Ressource blockiert ist, wird der Prozess ebenfalls blockiert, und bei Freigabe der Ressource wieder aufgeweckt. Dies wird zum Beispiel durch Semaphoren umgesetzt, die eine atomare Funktion zum Sperren und Freigeben bereitstellen. Diese sind vom Betriebssystem privilegiert (z.B. indem sie als Syscall implementiert werden) und werden daher garantiert nicht vom Scheduler unterbrochen.
 [[Kategorie:Glossar]]