Also was passiert, wenn man bei Synchronisationen etwas falsch macht?

Im Endeffekt geht es heute um den Stillstand von Prozessen,

die sich untereinander synchronisieren und am Ende keiner mehr vorankommt.

Das ist das wesentliche Problem.

Ursachen dafür gibt es im Wesentlichen zwei.

Der eine ist die überkreuzte Anforderung von Betriebsmitteln.

Der eine Prozess fordert einen Lock an, der andere Prozess fordert einen anderen Lock an.

Der erste Prozess will dann den anderen Lock anfordern, den der zweite schon hat.

Und der zweite will dann den ersten Lock anfordern, den der erste schon hat.

Der zweite wartet auf den ersten, dass die Lock wieder freigeben.

Aber nachdem sie beide blockiert sind, kommen sie nicht voran und geben nichts wieder frei.

Das ist das eine Problem.

Das andere Problem hat man auch schon das letzte Mal angesprochen.

Das man ein grundsätzliches Problem hat, wenn ein Prozess Betriebsmittel anfordert,

das er mit Loks setzt und dann abstürzt und die Loks nicht wieder freigebt.

Wie geht das gesamte System damit um?

Das bedeutet, er wird den Lock nie wieder freigeben und ein anderer, der den Lock beantragt, wird ihn nicht bekommen.

Damit steht der andere Prozess, der eigentlich laufen könnte, weil der erste Prozess den Lock nicht wieder freigebt.

Da hat man ein bisschen das Problem, wenn ein Prozess abstürzt, während der Lock hält.

Den Lock belegt man üblicherweise deswegen, weil man an kritischen Datenstrukturen etwas machen möchte.

Letztendlich also atomare Aktionen ausführen möchte.

Wenn man mitten aus einer atomaren Aktion rausgerissen wird, ist immer die Frage, in welchem Zustand ist das ganze System dann?

Macht es überhaupt einen Sinn, dass ein anderer dann noch weiter arbeitet?

Oder ist das Ganze nicht überhaupt im Zustand, dass alle, die diesen kritischen Abschnitt betreten möchten,

im Endeffekt auch zum Scheitern verurteilt sind und das ganze Prozesssystem, das an diesem kritischen Abschnitt etwas tut,

letztendlich abgeschossen werden muss und neu gestartet werden muss oder neu initialisiert werden muss.

Das sind so ein bisschen die Probleme daran.

Dykstra nennt diese gegenseitige Abhängigkeit der Le Embroise

und letztendlich eine Abhängigkeit, die im Wesentlichen eigentlich durch Entwurfsfehler in der Software produziert wird.

Man muss sich natürlich grundsätzlich erst mal überlegen, wenn man Software baut, designt,

wie sind die Abhängigkeiten gerade eben auch bei Synchronisationsmechanismen?

Und wenn man die von vornherein so konzipiert, dass da eben diese Verschränkungen gar nicht erst auftreten können,

dann vermeidet man eben auch solche Situationen wie dieses Deadly Embrace.

Dann wollen wir uns anschauen auf verschiedene Facetten der Verklemmung.

Das Problem ist nicht nur, dass der eine Prozess auf den anderen und der andere auf den einen wartet.

Das Problem kann auch sein, dass die beiden noch weiter rechnen können,

letztendlich aktiv sind, also nicht im Zustand blockiert, sondern im Zustand bereit oder laufend sind,

aber letztendlich trotzdem nicht vorankommen, weil sie halt irgendwas abfragen und dann an irgendeine Stelle springen,

um irgendwas erneut zu versuchen und der andere macht das genauso.

Sowas nennt man dann LiveLogs und das große Problem ist, bei einem DeadLog kann ich im Endeffekt eigentlich die beteiligten Prozesse analysieren.

Ich kann also zum Beispiel nach einem Timeout, wenn Prozesse also eine bestimmte Zeit lang blockiert waren,

mir angucken, warum sind sie blockiert und wenn ich sehe, der ist in einem Log blockiert,

dann kann ich mal eine Analyse von dieser Logsituation machen und bekomme dann letztendlich, wenn es ein DeadLog ist,

kann ich das auch analysieren und rausbekommen, wie die Prozesse eben da miteinander sich verkeilt haben.

Im Fall vom LiveLog ist es nicht so einfach, weil ich erkenne diese Prozesse ja nicht, dass die nicht vorankommen.

Sie laufen ja, sie machen halt bloß am Ende keinen größeren Fortschritt mehr,

sodass also solche LiveLogs eigentlich eine sehr unangenehme Situation sind, weil man sie eben nicht automatisch erkennt und damit nicht auflösen kann.

Und dann wollen wir uns natürlich auf jeden Fall mal anschauen, was sind denn die Gegenmaßnahmen und im Endeffekt gibt es drei Stufen an der Stelle.

Das erste ist Vorbeugen, also von der Konstruktion her, Software System so baut, dass da gar nichts passieren kann.

Das zweite ist die Vermeidung, dass man also zur Laufzeit schaut, wenn jemand einen Log anfordert,