Dieser Audiobeitrag wird von der Universität Erlangen-Nürnberg präsentiert.

Ja, schönen guten Morgen zum letzten Teil über Synchronisation. Wir haben uns ja jetzt die letzten

Wochen so vorgearbeitet von der Sprachebene mit den Monitoren, wo das alles ja irgendwo konzeptionell

ganz einfach aussah. Enter Monitor, Leaf Monitor und dazwischen kann man vielleicht einen Weight machen.

Hat uns dann angeschaut, welche Probleme gerade bei diesem Weight im Monitor existieren, also

diese Automatik-Probleme, die man da hat zwischen dem Abprüfen einer Bedingung und dem Schlafenlegen,

dass man da eben nicht so ein Lost Wakeup sich einfängt, wenn die Signalisierung der Freigabe

der Bedingung noch ins Leere geht, weil der Prozess noch nicht schläft. Gut, das Schlafenlegen selbst,

das hat man uns dann ja auch angeschaut, dass man also im Endeffekt das aufteilen muss, dieses Weight,

dass man also sich erstmal in die Queue einträgt, in die Queue der Schlafenprozesse, damit man quasi

für das Signal schon mal empfangsbereit ist, dass man dann erst den Monitor freigibt und dann den

Prozess abgibt. Gut, und bei all diesen Geschichten hatte man im Endeffekt immer noch das Betriebssystem

unter und drunter, das im Zweifelsfall einen Lockmechanismen bereitstellt, die so ein bisschen

abstrakt betrachtet wurden. Man macht halt ein System Call und das Betriebssystem wird schon dafür

sorgen, dass das irgendwie atomar ist. Letztes Mal haben wir uns dann auch angeschaut, so die

Problematik, die man eben auch auf der unteren Ebene hat, also speziell auch beim Monoprozessor,

bei der Synchronisation mit Interrupts. Wenn ein Interrupt reinkommt, solange der Programm,

das gerade auf User-Level ist, unterbricht, ist das alles nicht besonders tragisch, weil die

Interrupt-Bearbeitung und die Daten, die der Prozess, der da unterbrochen wurde, bearbeitet. Das

sind völlig unterschiedliche Datenbereiche. Die Interrupt-Daten liegen im Systemkern, die

Daten auf User-Level liegen im Benutzeradressraum. Das heißt, da hat man letztendlich keine

Zugriffskonflikte drauf. Also alles relativ harmlos. Ein bisschen schlimmer ist das Ganze natürlich,

wenn der Interrupt den Systemkern selbst unterbricht, weil natürlich im Rahmen des Interrupts

beispielsweise ein Prozess aufgeweckt werden kann und wenn ein Prozess aufgeweckt wird, dann muss

er ja irgendwie aus einer Queue von blockierten Prozessen rausgenommen werden, in die Queue der

bereiten Prozesse eingetragen werden. Warteschlangenoperationen kennen Sie jetzt aus

vielerlei Übungsaufgaben. Warteschlangenoperationen sind ja alles andere als atomare Operationen. Das

heißt, wenn so ein Interrupt so mitten rein in so eine Warteschlangenoperation in das Ein- oder

Ausketten trifft und die Interrupt-Routine greift dann auch auf diese Warteschlange zu, dann hat

man natürlich einfach Ärger. Gut, das hatten wir das letzte Mal angeschaut. Das kriegt man ein Stück weit

dadurch in Griff, dass man den Interrupt so in First-Level und Second-Level-Händler aufteilt,

dass der First-Level-Händler im Endeffekt eigentlich nur die Daten vom Gerät entgegennimmt,

in irgendwelchen Datenstrukturen ablegt und dann einen Second-Level-Händler quasi scheduled,

den auch wieder in die Queue einträgt und dieser Second-Level-Händler, der wird erst dann abgearbeitet,

wenn das Systemkern im Endeffekt seine Datenstrukturen im konsistenten Zustand hat.

Und dann werden diese ganzen Second-Level-Händler, falls mehrere aufgelaufen sind, einfach der Reihe

nach abgearbeitet und dann kann man einfach sicher sein, dass die Daten in einem sinnvollen Zustand sind.

Solange Sie einen Prozessor haben, ist das alles wunderbar. Im Endeffekt benutzen Sie an der Stelle

eher einen Scheduling-Mechanismus, um Wettstreitigkeiten zu vermeiden zwischen verschiedenen

Prozessen oder zwischen verschiedenen Svets oder Abläufen.

Und ja, gut, also gerade mit Einplanungsmechanismen kann man das halt auch ganz gut tun.

Es gibt eine Stelle, an der Sie natürlich dann völlig chancenlos sind und diese Stelle war früher

ein extrem seltener Fall oder es gab ihn gar nicht, heutzutage ist es der Normalfall.

Sie haben einfach mehrere Prozessorkerne, auf denen parallele Abläufe passieren.

Die ersten Multiprozessorsysteme haben relativ einfach darauf noch reagiert.

Die haben gesagt, okay, das System Kern darf eben nur auf einem Prozessor ausgeführt werden

und die anderen machen bloß User-Level-Prozesse.

Das funktioniert ein Stück weit, solange Sie nicht zu viele Kerne haben, können Sie damit vielleicht

auch noch einigermaßen die Sachen ausnutzen, aber wenn Sie sich anschauen, wie viele Systemcalls

gemacht werden und heutzutage haben wir, was weiß ich, 60, 80 Kerne auf einem Prozessorchip,