Nun mit der Sperre wollen wir abschließend noch eine weitere Technik kennenlernen, die man verwenden kann, um

gleichzeitige Aktivitäten zu koordinieren, im Wesentlichen um sowas wie kritische Abschnitte zu

schützen. Wir werden sehen, dass es sich schon stark unterscheidet zum Mutex und insbesondere

noch zum Simafor, aber wir werden halt eben auch erkennen, dass es eine Technik ist, die uns gerade

hilft, Simafor korrekt zu implementieren. Also die Atomharen, die kritischen Abschnitte, die wir

vorher bei der Implementierung des Simafors gesehen haben, die können wir halt hier sicherstellen,

indem wir so eine Sperre verwenden, die wir gleich kennenlernen. Hier gibt es ein paar grundsätzliche

Sachen zu diesem Sperrkonzept sagen und denso typische Varianten, die in den Betriebssystemen

durchaus realisiert sind, mal kurz ansprechen, aber nur ganz kurz. So, mit dem Sperrmechanismus

wird man eine Prozessauslösung verhindern. Indem man das tut, werden eben auch gleichzeitige

Prozesse irgendwie zeitwählig unterbunden. Es ist ein Mechanismus, der die Auslösung einer solchen,

von solchen gleichzeitig Prozessen eben letztendlich zeitwählig außer Kraft setzt. Mehr macht man

da halt nicht. Nun gibt es verschiedene Gründe, weshalb dann so gleichzeitige Prozesse entstehen

können. Zum Beispiel durch Interrupts, also durch Unterbrechungen, durch Unterbrechungsanforderungen.

Jede Unterbrechung, die reinkommt, kann praktisch dazu führen, dass eben gleichzeitig Abläufe zu

einem unvorhersehbaren Zeitpunkt dann geschehen. Und wenn man diese Abläufe jetzt gerade nicht

zulassen darf, wenn man sich zum Beispiel in einem kritischen Abschnitt befindet, dann könnte man

die Unterbrechung sperren. Nun, Unterbrechungen, also Interrupt-Händler, laufen immer asynchron

zum aktuellen Prozess und asynchron zum Betriebssystem. Wir meinen hier eben auch den

sogenannten First-Level-Interrupt-Händler, den Flee, wie man ihn noch häufig abkürzt,

der praktisch gesperrt wird oder der Aufruf eines solchen Händlers, denn praktisch gesperrt wird im

Moment eines solchen Unterbrechungssignals, wenn man diesen Mechanismus aktiviert hat.

Eine andere Variante ist die Fortsetzung einer Unterbrechungsbehandlung auszusetzen.

Jeder Unterbrechungshändler, Interrupt-Händler, besteht für gewöhnlich aus zwei Teilen. Einmal

den Flee, den wir gerade kurz kennenlernt haben, und dann einen zweiten Teil, den man so als

Second-Level-Interrupt-Händler bezeichnen kann, der auch asynchron zum System läuft, aber synchron

zum Systemkern. Also man stellt durch den Mechanismus, durch den Aussperrmechanismus,

ist dann halt sicher, dass solche Fortsetzungen von Unterbrechungsbehandlungsroutinen

einsynchronisiert sind in die Aktionen, die innerhalb eines Betriebssystemkerns denn zum

Beispiel stattfinden. Und an den Stellen, wo man Fortsetzungen zulässt, genauso an den Stellen,

wo man normale Unterbrechungen zulässt, ist eben dieser Mechanismus dann halt nicht als

Sperrmechanismus aktiviert. Eine weitere Variante eigentlich wäre, Verdrängungen zu verhindern.

Also dieses Preemption eines präemptiven Schedulars zeitweilig auszusetzen. Typischerweise

Schedular, die praktisch präemptiv arbeiten, werden denn immer als Folge eines Second-Level-Interrupt-Händlers

aktiviert. Also zum Beispiel, wenn wir Zeitscheibensteuerung halt haben, dann ist das

durch einen Timerinterrupt letztendlich physisch geregelt. Das heißt, wir bekommen halt eine

Unterbrechungsanforderung, wenn sozusagen die Zeitscheibe eines Prozesses abgelaufen wird.

Dann haben wir erstmal den First-Level-Interrupt-Händer für den Timer, dann wird der den Second-Level-Interrupt-Händer

halt haben zu diesem Timer und dann wird im Rahmen dieser zweiten Ebene der Unterbrechungsbehandlung

letztendlich der Schedular aktiviert. Und diese Aktivierung, die könnte man außer Kraft setzen.

Das würde dann bedeuten, man sperrt Verdrängungssignale oder die Verdrängungsereignisse,

die dann letztendlich dazu führen würden, dass man präemptive Prozessumschaltung betreiben könnte

in so einem Schedular. Nun, damit werden aber auch immer Prozesse ausgesperrt, die überhaupt nichts

mit unserem kritischen Abschnitt möglicherweise zu tun haben. Also der Konflikt, der hier möglicherweise

gesehen wird in diesem nicht-sequenziellen Programm und vor dem man sich dann sozusagen

hüten möchte. Da werden also kausal unabhängige, gleichzeitig Abläufe, die werden unnötig unterbunden.

Das heißt also, man schränkt natürlich mit dieser Holzhammer-Methode Parallelität ein,

die einfach unkritisch ist. Und damit schränken wir natürlich eben auch die Leistungsfähigkeit

unseres Rechensystems ein Stück weit ein. Man sollte solche Techniken eben nur sehr, sehr selten

halt anwenden, eben aus diesem Grund. Deshalb sind sowas wie Simaphore erfunden worden oder auch