Mein Lieber Leute, willkommen zum nächsten Video zur Vorlesung Betriebssysteme. Worum

soll es diesmal gehen? Es geht jetzt mal weiter darum Unterbrechungen zu synchronisieren,

nämlich mit dem normalen Kontrollfluss des Hauptprogramms. Das Kapitel an sich beschäftigt

sich letztendlich mit dieser gesamten Synchronisation. Wir feiern Anfang mit einer kleinen Einleitung

nochmal gucken wo das eigentliche Problem liegt. Das Ganze werden wir noch ein bisschen

formal beschreiben. Keine Angst, wird nicht viel Formalitäten sein. Hilft da mal ein

bisschen drüber zu reden. Einfach tauchen ein paar Namen auf, die man kennen sollte.

Dann kann man leichter über das Problem reden. Wenn wir dann das synchronisieren müssen,

dann gibt es zwei Verfahren. Die haben wir uns ganz grob schon mal angeguckt. Die gucken

wir uns nochmal genauer an, nämlich die harte bzw. weiche Synchronisation. Beide haben ihre

Vor- und Beide haben ihre Nachteile. Die arbeiten wir da noch ein bisschen genauer raus. Dann

gehen wir dazu über zum sogenannten Prolog-Epilog-Modell. Ihr erinnert euch an das letzte Kapitel mit

den Soft-Ir-Qs. Die zwei sind sehr miteinander verwandt. Das ist heutzutage in vielen Bereichen

Mittel der Wahl, wie man denn wirklich synchronisiert. Fangen wir an mit der Einleitung. Kleine Motivation,

dass ihr nochmal reinkommt in das Thema. Ihr erinnert euch an diesen Bound-it-Buffer. Wir

haben hier die Daten. Das Problem, das Hauptprogramm konsumiert Zeichen aus einem Buffer. Während

es vielleicht dabei ist, kommt ein Interrupt. Das Hauptprogramm wird unterbrochen und der

Interrupt-Händler produziert jetzt Daten. Das heißt, er legt Daten in diesen Bound-it-Buffer

ab. Wenn das beides mehr oder weniger gleichzeitig passiert, dann kommt dieser Bound-it-Buffer

in irgendeinen inkonsistenten Zustand. Das darf irgendwie nicht sein. Das müssen wir

jetzt irgendwie regeln. Woran liegt das Problem? Das liegt daran, dass sowohl die Produce-Methode

als auch die Consume-Methode auf einen gemeinsamen Zustand zugreifen. Die zwei Zugriffe, wie

man immer sagt, aus zwei verschiedenen Ebenen erfolgen. Nämlich einer unteren Ebene. Die

unteren Ebene wird traditionell immer die bezeichnet, die im Interrupt-Kontext abläuft.

Und wir haben eine obere Ebene. Das ist der Anwendungsbereich. Das ist der Kontrollfluss

vom Anwenderprogramm. Das ist der Kontrollfluss vom Interrupt-Händler. Wir haben zwei Kontrollflüsse.

Die greifen in der Mitte, sozusagen im Betriebssystem Kern, auf Daten zu. Die Daten gehen dann

gegebenenfalls kaputt. Wie stellen wir jetzt die Konsistenz sicher? Das ist jetzt die große Frage.

Der ein oder andere, der zum Beispiel in der SP-Vorlesung von Wosch war, wird sich vielleicht

daran erinnern, da war doch was, wenn dann zwei Prozesse gleichzeitig oder quasi gleichzeitig

auf einen Buffer zugreifen wollen. Dann haben wir das doch bei den zwei Prozessen gelöst mit

Mutexen, also Mutual Exclusion Geschichten. Wir locken den Buffer, lesen ihn aus, unlocken ihn.

Der Producer lockt den Buffer, tut was rein, macht einen Unlock drauf. Das sah, oder damals hat man das

so gemacht in der SP-Vorlesung Übung, wenn es darum ging zwei Prozesse zu koordinieren. Aber,

großes großes Aber, das funktioniert hinten und vorne nicht. Jeder mal drüber nachdenken,

warum geht das in die Hose? Ja, Problem kann nämlich sein, es kann sein, dass das Anwendungsprogramm

gerade den Buffer gelockt hat, weil es ein Zeichen aus dem Buffer rausholen möchte und in dem Moment,

also wenn wir hier in diesem eigentlich geschützten Bereich drin sind, in dem Moment ein Interrupt

kommt. Der Interrupt-Händler das Producer aufruft, dann will der Interrupt-Händler den Buffer locken,

kann er aber nicht, weil der ist ja schon gelockt. Das heißt, hier der Interrupt-Händler wartet

jetzt darauf, dass der Buffer wieder freigegeben wird. Problem, der wird es wieder natürlich

freigegeben, wenn das Produce terminiert, sprich der Interrupt-Händler terminiert und das Hauptprogramm

weiter läuft. Wenn aber das Produce nicht terminiert, weil er hier im Lock hängt, wird auch das

Konsum nicht weiter laufen können und nicht das Unlock aufrufen können. Also klassischer Fall von

gar nichts geht mehr. Es geht auch wirklich überhaupt nichts mehr, warum nicht? Die Interrupts sind

ausgeschaltet, weil es läuft ja gerade ein Interrupt-Händler. Ihr erinnert euch, bevor ein

Interrupt-Händler läuft, bevor die CPU den Interrupt-Händler beginnt abzuarbeiten, schaltet

sie die Interrupts aus und die CPU macht nicht mehr weiter, weil sie hier in dem Lock hängt.

Ja, es hilft jetzt auch kein Ctrl-C oder irgendwas in der Art mehr, weil der Interrupt, der Abbruch

Interrupt, der kommt ja nicht mehr durch. Also großes großes Problem, so bitte nicht und schon