Mein, mein liebe Leute willkommen zum nächsten Video zur Vollesum Betriebssysteme. Weiter soll es

gehen mit der Fadensynchronisation. Im letzten Video haben wir uns angeguckt, dass Fäden in der

Anwendungsebene irgendwie parallel laufen, verdrängbar sind und wir brauchen jetzt irgendwie

Mechanismen, um die zu koordinieren. Wichtiger Punkt, die Fäden, die in der Anwendung laufen,

können jederzeit und für sie unvorhersehbar verdrängt werden. Das muss so sein, werden wir

nachher noch sehen. Es muss eine Fortschrittsgarantie geben, heißt es muss auch immer zwischen allen

Fäden hin und her gewechselt werden. Auch die Fäden mit niedriger Priorität brauchen eine

minimale Fortschrittsgarantie, sonst werden wir sehen, kann sich das System letztendlich doch

verklemmen. Gut, wir haben uns in einem der letzten Videos angeguckt, niedrige Priorität heißt in der

Windows und Linux Welten nicht, dass man nie Rechenzeit kriegt, das heißt nur typischerweise,

dass man weniger kriegt an Rechenzeit als die anderen Fäden mit höherer Priorität. Also in der

typischen Linux Windows Welt gibt es diese Fortschrittsgarantie. Wichtig in dem Zusammenhang,

es muss ein präemptives System sein, sonst haben wir kein Problem, wenn unser Faden einfach durchläuft,

nicht verdrängt wird, haben wir kein Problem und wir haben typischerweise auch nur deshalb ein

Problem, weil wir online schedulen. Offline könnte man das Problem unter Umständen anders lösen,

da könnte man dem Scheduler von vornherein irgendwie sagen, wann er welchen Faden dran nehmen soll,

nämlich soll er die immer so auswählen, dass sie sich gegenseitig beispielsweise mit der Produce

und Consume Methode nicht in die Quere kommen. Dann rufe ich eben vom Scheduler aus schon die

Produce Methode, den Faden erstmal auf, der die Produce Methode aufruft und wenn der fertig ist

damit, dann schedule ich den, der das Consume aufruft. Jeder merkt, dann ist kein Problem. Also Problem

liegt hier in dem Online, dass wir so mehr oder weniger zufällig hin und her wechseln und dass

wir überhaupt wechseln. Gut, jetzt schauen wir uns mal an, was müssen wir jetzt eigentlich

koordinieren, synchronisieren. Das sind, sage ich mal, zwei grundlegend verschiedene Dinge. Das eine

sind diese exklusiven Zugriffe, die wir irgendwie sicherstellen müssen. Wenn der eine das Produce

aufruft, darf der andere nicht gleichzeitig das Consume aufrufen und umgekehrt. Dass es dieser

gegenseitige Ausschluss oder im englischen Mutual Exclusion, also abgekürzt, Motex, das ist eine,

was wir brauchen. Und das andere ist noch was davon eigentlich komplett getrennt zu betrachten,

nämlich Folgendes. Es kann ja auch sein, die Consume Methode wird zuerst aufgerufen und danach

erst die Produce Methode. Das macht eigentlich keinen Sinn, bzw. derjenige, der im Consume aufruft,

muss eigentlich so lange warten, bis der andere warten, was in diesen Waffereien gelegt hat. Das

ist jetzt ein anderes Warten, ein anderer Grund zu warten, als in dem gegenseitigen Ausschlussfall.

Und die Dinger werden typischerweise als Sommerformen bezeichnet. Ich warte so lange,

bis ein, wie das immer so schön heißt, konsumierbares Betriebsmittel da ist. Gut, jetzt habt ihr schon

an meiner Benahmung gemerkt, da muss immer irgendwie gewartet werden. Ich muss warten,

bis der andere den kritischen Abschnitt wieder verlassen hat. Ich muss warten, dass der andere

was in den Waffereien getan hat. Gut, und das ist jetzt ein generelles Betriebssystemkonzept. Das

ist was, das hatten wir bisher nicht. Wir brauchen jetzt für Fäden einen Wartezustand. Das heißt,

wir werden den Faden zeitweilig zumindest beim Schedule nicht betrachten. Wir gucken uns einfach

eine bestimmte Liste von Fäden an, die lauffähig sind und die, die gesagt haben, sie können eh

nicht, die warten gerade auf was, die nehmen wir bei einem Resum auch nicht als nächstes daran.

Also, erster Punkt, mutual exclusion. Letztendlich gibt es da zwei Methoden, ein Lock, ein Unlock.

So die Idee, bevor ich in einen kritischen Abschnitt reingehe, rufe ich das Lock auf. Das

blockiert mich gegebenenfalls, wenn jemand anderes in dem kritischen Abschnitt drin ist. Und wenn ich

aus dem kritischen Abschnitt wieder raus gehe, rufe ich das Unlock auf. Und dann deblockiere ich

gegebenenfalls alle, die auf mich gewartet haben. Das so die Semantik von diesen Lock- und Unlock-Methoden.

Die Idee ist immer, ja es darf maximal einen Lock-Aufruf mehr gegeben haben als Unlock-Aufrufe.

Das wäre so die Bedingung, dass es sicher ist, das kritische Gebiet wird nur von maximal einem

Faden gleichzeitig durchlaufen. Wenn wir diese Mutechecks haben, dann können wir einfach vor dem

Consume das Lock aufrufen, vor dem Produce das Lock aufrufen und umgekehrt hinterher das Unlock.

Im Sinne von, dann ist sichergestellt, dass Consume bzw. Produce einer von beiden, aber nicht beide