Auf den ersten Blick hat sich in Stubs im Vergleich zur vorherigen Aufgabe nicht viel geändert.

Unsere Anwendungsfäden incrementieren weiterhin fröhlich vor sich hin, vielleicht ein wenig schneller als zuvor.

Die Ausgabe rechts oben ist neu, es wird die Zeit angezeigt, aber das ist optional.

Die eigentliche Änderung ist wieder nur unter der Haube zu sehen.

Unsere Anwendung sah in vorherigen Aufgaben in etwa so aus.

Nun verschwindet aber der kooperative Wechsel der Anwendungen mittels Scheduler Resume.

Dennoch werden alle Fäden bedient.

Dank einer regelmäßig auftretenden Unterbrechung, welche den Wechsel initiiert.

Während dieses präemptive Scheduling natürlich Anwendungsentwicklern das Leben vereinfacht,

muss Stubs selbst unter Umständen erst noch abgesichert werden, denn diese Unterbrechungen

können nun jederzeit, also an jeder Stelle des Codes geschehen.

Potenzial für viele interessante Fehler.

Was müssen wir dafür tun?

Für das präemptive Scheduling wollen wir den Lapig Timer verwenden, der dazu zuerst

konfiguriert und kalibriert werden muss.

Neben dem Umbau der Anwendung und den Schutz kritischer Abschnitte müssen nun in mp-stubs

Kerne unter Umständen bei bestimmten Ereignissen benachrichtigt werden.

Außerdem gibt es die Möglichkeit freiwillig weitere Timer einzubauen, wie die in der Musterlösung

gezeigte Real-Time Clock, welche die aktuelle Uhrzeit und Datum anzeigt.

Das wird dann über die Clock gesteuert.

Daneben gibt es noch die Watch, welche bei vom Lapig ausgelösten Unterbrechungen den

Threadwechsel auslöst.

Sie stellt dabei folgende Methoden zur Verfügung.

Windup stellt das gewünschte Unterbrechungsintervall ein, und zwar in Mikrosekunden.

Es ist für die Aufgabe außerordentlich hilfreich, Mikro- und Millisekunden nicht zu verwechseln

und im Zweifelsfall nochmals genau zu lesen.

Wenn die Uhr nun aufgezogen wurde, kann sie aktiviert werden, damit die Unterbrechungen

kommen.

Im Mehrkernbetrieb muss das nun auf jedem Kern gemacht werden, denn jeder hat einen

eigenen Lapig.

Beim Windup reicht jedoch ein Einzelnaufruf, da die Apig-Bus-Frequenz für alle Kerne gleich

ist.

Und da die Watch ein Gerät ist, muss sie auch einen Prolog und Epilog anbieten.

Dabei fordert der Prolog nur einen Epilog an und tätigt vielleicht zu Testzwecken mal

eine Ausgabe.

Sobald wir dann in der Epilog-Ebene sind, wird der Threadwechsel ausgeführt.

Der Lapig-Timer hat nun leider keine unsbekannte Basisfrequenz, sondern nimmt den Apig-Bus-Takt,

welcher wiederum je nach Hardware komplett unterschiedlich sein kann.

Er entspricht entweder dem Prozessor Core Clock, dem Core Chrysler Clock oder auch etwas

ganz anderem.

Und ein Auslesen solcher Werte mittels CPU-ID und MSR ist auch keineswegs schön, wie man

am Beispiel des Timestamp-Counters sehen kann.

Wie können wir nun einfach die Frequenz feststellen, möglichst generisch damit es auf jeder Hardware

läuft?

Nun, wir messen einfach die Zeit, wie lange ein Tick dauert und zwar mit Hilfe eines

anderen Timers, welcher auf jeder Hardware vorhanden ist und dessen Frequenz wir kennen,

dem Programmable Interval Timer.

Dieser ist bereits in Stubs fertig implementiert.

Wir setzen die Wartezeit auf einen möglichst großen Zeitraum und merken uns die Start-

und Endwerte des Lapig-Counters.