Reihen oberflächlich betrachtet ist bei der Musterlösung zur Aufgabe 3 kein Unterschied zur vorherigen Aufgabe erkennbar.

Unterbrechungen werden wie gewohnt im Round-Robin-Verfahren von den Kernen abgearbeitet.

Aber unter der Haube steckt eine Änderung, die es in sich hat.

Zum einen haben wir nur Interrupt-Sperren verwendet, um kritische Abschnitte in Stubs zu schützen.

Stattdessen kommt nun das Prolog-Epilog-Modell zum Einsatz.

Das bedeutet nun nicht, dass wir gänzlich ohne Client-Sti auskommen.

Vereinzelt werden diese weiterhin noch gebraucht, um sehr kurze Abschnitte zu sichern.

Aber in Anwendungen nutzen wir nun stattdessen den Epilog,

wessen Funktionen Enter, Leave und Relay in Guard implementiert werden.

Die Treiberschnittstelle Gate bietet statt Trigger nun Prolog und Epilog an.

Entsprechend müssen auch die Treiber sowie die Unterbrechungsbehandlung angepasst werden.

Da Epilog auch verzögert werden können, stellt Gate-Q eine Epilog-Warteschlange

mit den elementaren Funktionen Enqueue und Dequeue zur Verfügung.

Während in OO-Stubs insgesamt eine verkettete Liste ausreicht,

braucht in MP-Stubs jeder Kern eine eigene Warteschlange.

Dadurch stellen wir sicher, dass der Epilog auch auf derselben CPU wieder Prolog ausgeführt wird.

Dabei darf in einer Warteschlange derselbe Epilog nicht mehrfach vorkommen.

Also beispielsweise wenn wir auf einer CPU-Lange in Ebene 1,5 sind

und dort bereits zwei Tastaturunterbrechungen und Prologe hatten,

dann ist dennoch nur ein Tastaturepilog in dieser Warteschlange.

Diese Designentscheidung macht uns das Leben einfacher,

da wir dem Verkettungszeiger, den Nextpointer,

die Warteschlange einfach als Klassenattribut in Gate anlegen können.

Wie der Epilog im Beispiel der beiden Tastaturprologe das behandeln soll, bleibt euch überlassen.

Eine Möglichkeit ist hierfür ein Ringpuffer, um mehrere Tasten speichern zu können.

Oder aber nur eine Taste wird gespeichert und die andere verworfen,

was konzeptionell kein großer Unterschied ist, nur ein Puffer der Länge 1.

Bei MP-Stubs kann es nun aber durchaus vorkommen,

dass derselbe Epilog in unterschiedlichen Epilog-Warteschlangen,

also beispielsweise auf CPU 1 und 3, gleichzeitig eingereiht ist.

Für die Tastatur ist das nun noch nicht wichtig,

jedoch brauchen wir dieses Verhalten in späteren Aufgaben noch für Timer- und Interprozessorinterrupts.

Und im Mehrkernbetrieb ist außerdem darauf zu achten,

dass zu keinem Zeitpunkt mehr als ein Kern auf der Epilog-Ebene arbeitet.

Dies lässt sich mit einem sogenannten Bekörnlock bewerkstelligen,

einer Umlaufsperre, welche dafür sorgt,

dass andere Kerne, welche in die Epilog-Ebene wollen, aktiv warten,

wenn diese Ebene gerade belegt ist.

Für die Implementierung muss hier der Ticketlock verwendet werden.

Er ist nicht nur fairer, sondern aufgrund von Cacheffekten bei unserer Test-Hardware,

Stichwort Hyperthreading, kann es bei einem Spinlock vorkommen,

dass zwei Kerne komplett verhungern.

Und obwohl es nur um wenige Code-Zeilen geht,

sollte man auch die Reihenfolge von Sperraufrufe genau durchdenken.

Das gewünschte Verhalten von MPStubs vertiefen wir an ein Beispiel mit zwei Kernen.

Zuerst wechselt CPU0 mit Enter auf die Epilog-Ebene.

Danach führt CPU1 ebenfalls ein Enter aus,

jedoch ist die Ebene belegt und sie muss warten.

Sobald CPU0 dann fertig ist und wieder auf die Anwendungsebene wechselt,

kann CPU1 den kritischen Abschnitt betreten.