Inkonsistenter Zustand einer Sperre

Ich lese die Kunst der Multiprozessor-Programmierung und versuche, ihr Konzept inkonsistenter Sperren zu verstehen. Insbesondere auf Seite 37 ist mir die Definition 2.8.1 einer inkonsistenten Sperre sowie Lemma 2.8.1 nicht klar.

Definition 2.8.1. Der Status eines Sperrobjekts s ist in jedem globalen Status inkonsistent, in dem sich ein Thread im kritischen Bereich befindet. Der Sperrstatus ist jedoch mit einem globalen Status kompatibel, in dem sich kein Thread im kritischen Bereich befindet oder versucht einzutreten.

Lemma 2.8.1 Keine Deadlock-freie Lock-Implementierung kann in einen inkonsistenten Zustand eintreten.

Beweis:

Angenommen, das Lock-Objekt befindet sich in einem inkonsistenten Zustand, in dem sich kein Thread im kritischen Bereich befindet oder versucht, ihn einzugeben. Wenn Thread B versucht, in den kritischen Abschnitt einzutreten, muss er möglicherweise erfolgreich sein, da die Implementierung Deadlock-frei ist.

Angenommen, das Lock-Objekt befindet sich in einem inkonsistenten Zustand s, wobei sich A im kritischen Bereich befindet. Wenn Thread B versucht, in den kritischen Abschnitt einzutreten, muss er blockieren, bis A verlässt. Wir haben einen Widerspruch, weil B nicht feststellen kann, ob sich A im kritischen Bereich befindet.

Was ich nicht verstehe:

• Bedeutet Inkonsistenz nur, dass andere Threads nichts davon wissen können, wenn sich ein Thread in einem kritischen Abschnitt befindet?
• Was ist der Widerspruch in einem Lemma-Beweis? Angenommen, Thread A befindet sich in einem kritischen Abschnitt und die Sperre befindet sich in einem inkonsistenten Zustand. Was hindert einen anderen Thread daran, den Status der Sperre zu überschreiben und zu erfassen?

• "inkonsistent" bedeutet hier im Grunde, dass die interne Implementierung nicht die Realität der Thread-Aktivierung und der Verfügbarkeit von Sperren widerspiegelt. aka "defekt". dh es funktioniert nicht richtig als Thread-Sperre. Beispielsweise kann die Sperre "aktiv" anzeigen, aber kein Thread hat die Sperre erhalten, oder die Sperre zeigt "inaktiv" an, aber ein Thread hat eine Sperre erhalten.

• Der Widerspruch ist, dass laut "Deadlock Free" eine Sperre schließlich von mindestens einem Thread erworben wird, der sie anfordert. Wenn es sich jedoch in einem inkonsistenten Zustand befindet, wird ein Thread ausgeführt, aber die Sperre zeigt an, dass nichts gesperrt ist. Aber dann kann es keinem neuen Thread gelingen, die Sperre zu erhalten (ohne gleichzeitig mit A ausgeführt zu werden).

Beachten Sie eine Falte / Subtilität aus einer Online-Referenz [1], die eng mit der Buchausstellung übereinstimmt (dieselben Autoren):

Beachten Sie, dass ein Programm auch dann einen Deadlock ausführen kann, wenn jede der verwendeten Sperren die No-Deadlock-Eigenschaft erfüllt. Betrachten Sie beispielsweise die Threads A und B, die die Sperren 0 und 1 gemeinsam nutzen. Zuerst erwirbt A 0 und B 1. Als nächstes versucht A, 1 zu erfassen, und B versucht, 0 zu erfassen. Die Threads blockieren, weil jeder auf den anderen wartet um sein Schloss zu lösen

[1] Multiprozessorsynchronisation und gleichzeitige Datenstrukturen Maurice Herlihy / Nir Shavit