Willkommen zum letzten Teil dieses Kapitels. Kapitel Fadensynchronisation zur Vorlesung

Betriebssysteme. Gucken wir uns einfach mal an. Am Beispiel was macht Windows? Was bietet

Windows an Synchronisier-Koordinier-Methoden? Also in der Windows Welt wer Windows ein bisschen

genauer kennt, der weiß, dass in Windows alles irgendwie Objekte sind und alle Objekte sind auch

irgendwie Synchronisierungsobjekte. Entweder explizit, also irgendwie es gibt Objekte mit dem

Namen Utex, beziehungsweise immer vorher, haben wir uns ja im letzten Video angeguckt, das sind so die

die schlechthin Objekte zum Synchronisieren. Es gibt aber auch noch so ähnliche im Sinne von

Timer. Also ich kann mich blockieren bis ein Timer tickt oder Events. Events kann man vielleicht

so als abgespeckte Simmerforen sehen, also ein Simmerfonds ohne Zähler. Heißt ich kann auf ein

Event warten und ich kann ein Event signalisieren und deblockiere dann damit den Wartenden. Das sind

so die ja ich sag mal expliziten Synchronisierungsobjekte, aber praktisch auch alle anderen Objekte,

denen man das erstmal vielleicht gar nicht so ansieht, an denen kann man sich auch synchronisieren.

Beispielsweise ein Prozess, kann man sich erstmal fragen, was hat jetzt ein Prozess mit

synchronisieren zu tun? Ja ich kann beispielsweise darauf warten, dass ein Prozess terminiert und

der sich selbst terminierende Prozess weckt dann den drauf wartenden wieder auf. Ja zum einen kann

man sich jeweils blockieren bis da irgendwie ein Zustand eintritt und aber das Warten ändert dann

typischerweise auch irgendwie den Zustand. Also beispielsweise bei der Simmerfora, ich warte drauf,

dass der Wert größer als Null wird, aber wenn ich erfolgreich warte dann dekrementiere ich den Wert

automatisch dann um auch um eins. In der Menuswelt kann ich entweder auf ein Objekt warten, dass sich

da irgendwas tut. Ich kann aber auch auf Multiple Objects warten, dass sich was tut. Entweder im Sinne

von, dass sich bei allen was getan hat. Also ich will, dass die Uhr getickt hat und der Prozess

fertig ist oder ich kann sagen, ich möchte darauf warten, dass die Uhr getickt hat oder der Prozess

fertig ist und beides kann ich jeweils hier, ihr seht so ein Millisekundenparameter kann ich mit

so einem Timeout versehen. Also ich warte irgendwie auf ein Event, aber nur eine bestimmte Zeit lang.

Jo, welche Objekte gibt es? Ihr seht hier eine lange Liste, will ich jetzt im Einzelnen nicht

durchgehen, könnt ihr euch durchlesen, wenn es euch interessiert. Ihr seht hier nur Mutex. Ich warte

bis der Mutex verfügbar ist und was passiert dann? Ja ich nehme den Mutex, also den kritischen Abschnitt

in Beschlag. Sehen wir mal vorher, ich warte darauf, dass der Wert in der Semaphore größer 0 ist. Wenn

der Wert größer 0 geworden ist, dann vermindere ich den Wert um 1. Könnt euch den Rest hier angucken,

was da so um Einzelnen passieren kann, worauf ich warten kann. Das Ganze wird logischerweise

alles im Betriebssystem Kern von Windows verwaltet. Insofern schön, als dass das alles geschützt ist.

Ihr könnt jetzt nicht irgendwelche Objekte kaputt machen. Wenn das alles intern verwaltet wird,

dann passt Windows hoffentlich auch darauf auf, dass das alles in sich konsistenz ist. Wenn ich

jetzt einen kritischen Abschnitt belegen darf, dann ist hoffentlich auch sichergestellt, dass ich

dann der einzige im kritischen Abschnitt bin. Das Dumme daran, dass das im Kern verwaltet wird, ist,

dass die Verwendung natürlich vergleichsweise teuer ist. Das mag in einem oder anderen Fall

relativ egal sein. Wenn ich jetzt, was weiß ich, die Shell warte drauf, bis mein eingetippter Befehl

ausgeführt und fertig ist, das dauert, was weiß ich, mein Programm läuft dann vielleicht 5 Stunden,

dann ist dieser eine Warteeaufruf völlig zu vernachlässigen. Ein bisschen anders sieht es

natürlich unter Umständen aus bei den Mutexen, die vielleicht im Milli- oder Mikrosekundentakt

aufgerufen werden. Da muss man dann sagen, für jeden Mutex nehmen, Mutex wieder freigeben, muss

ich in den Kern wechseln. Die Betriebssystemaufrufe sind generell teuer. Also in der Intel Welt zum

Beispiel kommen da schnell einige tausend Takte zusammen. Das Dumme ist natürlich, das kostet

mich jetzt tausend Takte, so einen kritischen Abschnitt zu synchronisieren. Möglicherweise ist

der kritische Abschnitt aber nur ein paar handvoll Instruktionen lang. Das heißt, den Mutex sich zu

nehmen und wieder freizugeben, ist ein Vielfaches der Zeit, die das kritische Gebiet selber eigentlich

braucht. Und das haben wir auch im anderen Zusammenhang schon gesagt, sehr häufig ist es so,

dass man kritische Abschnitte belegt und wieder freigibt, ohne dass man eigentlich überhaupt im

Wettstreit ist. Es gibt eigentlich im Moment vielleicht gar keinen zweiten Faden, der dieses

kritische Gebiet überhaupt betreten will. Das heißt, wir konkurrieren eigentlich gar nicht oder nur