Wenn mehrere Threads dieselben Betriebsmittel verwenden, welche nur exklusiv benutzt werden

können, müssen sie sich synchronisieren. Mittels gegenseitigem Ausschluss wird dabei

verhindert, dass mehrere Fäden denselben kritischen Abschnitt betreten.

Wie sieht das in Stubs aus? Wir haben doch mit der Umlaufsperre ein kreislendes Warten

implementiert. Sowohl Ticket als auch Spinlock bieten dazu

die Methoden Lock zum Sperren und Unlock zum Endsperren des kritischen Abschnitts an.

Als Beispiel lassen wir mal im Eincam-Betrieb drei Anwendungen einen wechselseitigen Ausschluss

verwenden. Zu Beginn befinden sich auch alle noch in der Bereitschaftsliste.

Die erste Anwendung wird entnommen und die Bearbeitung angefangen. Sie ruft die Sperroperation

auf dem Utex auf und betritt damit den kritischen Abschnitt.

Bei der Abarbeitung kann es nun jedoch vorkommen, dass unsere Zeitscheibe abläuft, während

wir noch in diesem Abschnitt sind. Der Timer Interrupt also veranlasst, dass wir rausgeschedult

werden.

Dann wird mit App 2 die nächste Anwendung aus der Bereitschaftsliste entnommen und ausgeführt.

Diese versucht ebenfalls den kritischen Abschnitt zu betreten, da aber Anwendung einzig noch

darin befindet und entsprechend den Lock hält, wird sie aktiv warten. Und zwar so lange,

bis die Zeitscheibe abgelaufen ist. Sobald auch hier die Timer Unterbrechen kommt, wird

sie unverrichteter Dinge wieder in die Bereitschaftsliste gelegt, die nächste Anwendung entnommen und

ihr die Kontrolle übergeben. Und das Spiel wiederholt sich. Ein Betreten des kritischen

Abschnitts ist zurzeit nicht möglich, es wird aktiv gewartet.

Und zwar wieder die ganze Zeitscheibe, bis sie wieder rausgeschedult wird und endlich

App 1 wieder zum Zuge kommt, den kritischen Abschnitt fertig stellen kann und im Utex

3 gibt. Wir haben also einen Großteil unserer Zeit mit aktiven Warten verbracht, ohne dass

wir währenddessen irgendeinen Fortschritt haben hätten können, haben somit im Endeffekt

nur das Zimmer geheizt. Wie geht das besser?

Nun, wir könnten eine harte Synchronisation verwenden, eine Art deaktivierende Unterbrechungen,

aber weniger umfassend, nur auf den Scheduler beschränkt, dass dieser uns nicht innerhalb

eines kritischen Abschnitts zurück in die Bereitschaftsliste schickt.

Wie könnten wir das implementieren? Eine Möglichkeit wäre das temporäre Aussetzen

des präemptiven Schedulings, beispielsweise indem wir die Timerunterbrechungen blockieren.

Oder wir erweitern den Scheduler, so dass wir ihn über die Abarbeitung kritischer Abschnitte

informieren können und er währenddessen auf einem Fadenwechsel verzichtet.

Zudem haben wir natürlich noch unsere Epilog-Ebene. Könnten den kritischen Abschnitt einfach

dort abarbeiten, Timer-Epilogie werden dadurch erst beim Verlassen ausgeführt, wir werden

also davor nicht verdrängt. Diese Varianten funktionieren und sind zudem

auch vergleichsweise einfach umzusetzen. Leider haben sie auch systemweite Auswirkungen,

wir verzögern unter Umständen höher prior Kontrollflüsse und führen das außerdem

immer vorbeugend aus. Gibt es da nicht was besseres ohne diese

Probleme? Wie wäre es mit einem passiven Waden, dass

wir also die blockierten Threads aus dem Scheduler nehmen, während der betreffende Abschnitt

belegt ist? Bis jetzt kennt unser Scheduler zwei Zustände,

für den aktuell laufenden Thread und Ready für die Threads in der Bereitschaftsliste.

Außerdem können sich Threads mittels Exit selbst beenden oder mittels Kill beendet werden,

sie sind dann tot. Wir wollen nun also einen neuen Zustand wartend

einführen, in den ein aktiver Thread bei einer Blockierung wechseln kann. Sobald die

Ressource wieder frei ist, kann er aufgeweckt werden und wird dann wieder in die Bereitschaftsliste

eingereiht. Und natürlich soll auch ein wartender Thread beendet werden können.

Dazu führen wir für die blockierten Threads ein Wartezimmer ein, dies ist wie die Bereitschaftsliste

nichts weiter als eine Queue von Threads. Testen wir den neuen Ansatz am vorherigen

Beispiel mit den drei Anwendungen. Zuerst wird App 1 aus der Ready-Liste genommen