Mutex einfach erklärt: Gemeinsame Daten schützen

Eine Änderung kann aus mehreren Schritten bestehen: einen gemeinsamen Wert lesen, daraus einen neuen Wert bilden und diesen zurückschreiben. Ohne passenden Schutz können sich Schritte verschiedener Threads dazwischenschieben. Beide können dann mit demselben alten Stand arbeiten. Schreibt einer später sein Ergebnis zurück, kann er die Änderung des anderen überschreiben. Die Daten sind dann inkonsistent: Sie passen nicht mehr zu den Änderungen, die das Programm eigentlich ausführen sollte. Dieser Fehler ist eine Race Condition, also ein Fehler, dessen Auftreten von der zeitlichen Reihenfolge unzureichend abgestimmter Zugriffe abhängt.

Der kritische Abschnitt umfasst hier das zusammengehörige Lesen, Ändern und Zurückschreiben. Auch eine Prüfung mit anschließender Änderung muss gemeinsam geschützt werden, wenn ein anderer Thread den geprüften Zustand inzwischen verändern könnte. Ein Mutex ermöglicht gegenseitigen Ausschluss: Solange ein Thread die Sperre besitzt, kann kein anderer dieselbe Sperre erwerben. Die Entscheidung über den Erwerb muss unteilbar erfolgen, damit nicht zwei Threads gleichzeitig Besitzer werden.

Ein Thread erwirbt die Sperre vor dem kritischen Abschnitt und gibt sie danach frei. Alle beteiligten Zugriffe müssen dieselbe passende Sperre beachten. Das gilt auch für Leser, die mehrere zusammengehörige Angaben als stimmigen Stand benötigen. Verschiedene Sperren für dieselben Daten verhindern die störende Überlagerung nicht. Nur das Zurückschreiben zu schützen reicht ebenfalls nicht: Zwei Threads könnten vorher denselben alten Stand gelesen haben. Die Freigabe muss auch bei einem vorzeitigen Ende durch einen Fehler sichergestellt sein. Diese Abläufe beschreiben ein Modell, keinen ausführbaren Programmcode.

Im hier behandelten Mutex-Modell gehört eine erworbene Sperre einem bestimmten Thread. Dieser Besitzer gibt sie nach seinem geschützten Zugriff wieder frei. Ein anderer Thread kann ihm die belegte Sperre weder abnehmen noch sie stellvertretend freigeben. Ein wartender Thread darf den geschützten Zugriff erst nach seinem eigenen erfolgreichen Erwerb beginnen.

Ein konkretes Beispiel sind die eingebauten Monitorsperren der Programmiersprache Java. Eine Monitorsperre ist eine in Java eingebaute Sperre, die zu einem Objekt gehört. Ein Objekt bündelt Daten und zugehörige Programmaktionen. Beim Aufruf einer mit „synchronized“ gekennzeichneten Objektmethode, also einer entsprechend geschützten Programmaktion des Objekts, erwirbt der Thread dessen Monitorsperre. Beim Verlassen dieser Methode wird sie auch dann freigegeben, wenn ein unbehandelter Fehler den Aufruf beendet. Java-Monitorsperren sind reentrant: Ihr Besitzer kann dieselbe Sperre erneut erwerben. Das erlaubt etwa verschachtelte geschützte Aufrufe desselben Threads. Diese Eigenschaft darfst du nicht jedem Mutex zuschreiben.

Ein Semaphor verwaltet dagegen Erlaubnisse. Beim Erwerb wird eine verfügbare Erlaubnis entnommen; ohne verfügbare Erlaubnis muss der Thread warten. Laut Java-Dokumentation lässt sich ein Java-Semaphor binär nutzen: Anfangs gibt es eine Erlaubnis, und die Verwendung muss sicherstellen, dass höchstens eine verfügbar ist. Die Zustände sind dann „eine Erlaubnis verfügbar“ und „keine Erlaubnis verfügbar“. Der Semaphor kennt keinen Besitzer. Auch ein anderer Thread darf eine Erlaubnis zurückgeben. Gibt er sie zurück, während keine verfügbar ist, steigt die Anzahl auf eins. Zusätzliche Freigaben müssen so begrenzt werden, dass die binäre Nutzung erhalten bleibt. Aussagen über Besitz und Reentranz hängen von der konkreten Sperrart ab; die Java-Dokumentation behauptet diese Unterschiede nicht pauschal für jede mögliche Sperrimplementierung.

Ein Mutex kann Zugriffe ausschließen und trotzdem Teil einer Verklemmung sein. Eine Verklemmung, auch Deadlock genannt, liegt vor, wenn Threads dauerhaft aufeinander warten. Ein typisches Muster verwendet zwei Sperren: Der erste Thread hält eine Sperre und wartet auf die zweite. Der zweite hält die zweite und wartet auf die erste. Beide behalten während des Wartens ihre bereits erworbene Sperre. Deshalb kann keiner weiterarbeiten und seine Sperre freigeben.

Für dieses Zwei-Sperren-Muster hilft eine gemeinsame Erwerbsreihenfolge. Fordern beide Threads zuerst dieselbe erste Sperre und danach die zweite an, kann der beschriebene Wartekreis nicht entstehen. Der Verlierer beim ersten Erwerb hält dann noch keine der beiden Sperren. Das setzt voraus, dass beide diese Reihenfolge einhalten. Es ist kein allgemeiner Beweis gegen jede denkbare Verklemmung im restlichen Programm. Eine Pause vor der zweiten Anforderung oder eine geplante spätere Freigabe der zweiten Sperre beseitigt den beschriebenen Kreis nicht, solange beide ihre erste Sperre behalten.

Warten kann unterschiedlich umgesetzt sein. Beim blockierenden Warten ist der wartende Thread angehalten und prüft die Sperre nicht fortlaufend selbst. Beim aktiven Warten prüft er sie dagegen wiederholt in einer Schleife. Eine Sperre, die so wartet, heißt Spinlock. Solche Prüfungen verbrauchen Rechenzeit. Bekommt der Besitzer gerade keine Rechenzeit, können andere Threads weiter prüfen, ohne dass er die Sperre inzwischen freigeben kann. Bei einem Wartekreis können sie sogar dauerhaft prüfen. Nicht jeder Mutex wartet auf diese Weise.

Die Linux-Dokumentation empfiehlt Spinlocks in Benutzerprogrammen zusammen mit geeigneter Echtzeitplanung, also besonderen Regeln für die Zuteilung von Rechenzeit. Sie warnt vor ihrer Verwendung als allgemeine Sperrlösung. Die Wartezeit kann ohne feste obere Grenze wachsen. Außerdem droht Prioritätsumkehr: Ein wichtiger Thread wartet auf einen weniger wichtigen Besitzer, dessen Weiterarbeit durch andere Threads verzögert werden kann. Ein sorgfältiger Einsatz muss deshalb auch die Systemkonfiguration, die Zuordnung zu Prozessorkernen und die Prioritäten der Threads berücksichtigen.

Ein fehlerfreier Testlauf zeigt, dass in diesem Lauf kein Fehler gefunden wurde. Er beweist keine allgemeine Fehlerfreiheit. Bei nebenläufigem Code hängen mögliche Fehler unter anderem davon ab, wo zwischen Threads gewechselt wird. Ein Lauf kann einen günstigen Ablauf treffen, obwohl eine andere Verschachtelung fehlerhaft wäre. Auch viele Wiederholungen beweisen weder Fehlerfreiheit für weitere Eingaben noch, dass eine Sperre den ganzen nötigen Abschnitt schützt.

Eine Belastungsprobe lässt das Programm lange oder mit viel Arbeit laufen. Dadurch können Fehler sichtbar werden, doch die geprüften Abläufe bleiben unvorhersehbar und möglicherweise lückenhaft. Gezielte Tests steuern dagegen die Threadwechsel an ausgewählten Stellen. Sie können beispielsweise dafür sorgen, dass beide Threads einen alten gemeinsamen Zustand gelesen haben, bevor einer seine Änderung zurückschreibt. So lässt sich ein vermuteter Fehler gezielt auslösen. Ein festgehaltener Ablauf hilft außerdem, denselben Fehler erneut hervorzurufen und seine Ursache zu untersuchen.

Ein Testszenario legt eine untersuchte Situation fest, etwa Eingaben, Anfangszustand und beteiligte Aktionen. Die Forschungsarbeit „CHESS: A systematic testing tool for concurrent software“ beschreibt ein Werkzeug, das die Verschachtelungen eines gegebenen Szenarios systematisch untersucht und fehlerhafte Abläufe reproduzierbar macht. Selbst eine vollständige Untersuchung gilt für das festgelegte Szenario und das verwendete Modell. Sie ersetzt keinen allgemeinen Korrektheitsbeweis für andere Eingaben, ausgelassene Aktionen oder weitere Systembedingungen. Fehlt beispielsweise ein Fehlerabbruch im Modell, muss ein zusätzliches Szenario diesen Abbruch berücksichtigen. Mehr Wiederholungen oder mehr Last ergänzen die ausgelassene Aktion nicht.