Abbildung: Echtzeit-Scheduler mit Prioritätsanpassung,
Der Grund für zu lange Totzeiten bei mehreren lauffähigen Prozessen ist, daß andere Prozesse bevorzugt werden können, wenn sie gleichzeitig mit dem Steuerprozeß lauffähig sind. Um dies zu verhindern, wird in der Interruptfunktion die Priorität des Steuerprozesses geändert.
Der Prozeß wird zum einen als Echtzeitprozeß eingestuft. Zum anderen wird bei jedem Interrupt von der Hardware die aktuelle Laufpriorität auf den maximalen Wert gesetzt. Dies bewirkt, daß beim nächsten Prozeßwechsel im Scheduler auf jeden Fall der Steuerungsprozeß ausgeführt wird. Die Funktionsweise wird in Kap. in der Interruptfunktion erläutert. Auf einem System darf aber immer nur ein Echtzeitprozeß laufen. Andernfalls geht die Echtzeitfähigkeit durch die konkurrierenden Echtzeitprozesse verloren.
Der Vorteil dieser Prioritätsanpassung ist nun, daß der Steuerprozeß wirklich nach jedem Prozeßwechsel als nächstes rechnen kann. Damit sinkt die maximale Zeit ohne Steuerung von auf , da x nur den Wert 1 annehmen kann. Mit einem Echtzeitscheduler, wobei kleiner als ist, geht normalerweise kein Takt verloren.
Leider trifft dies nur solange zu, wie keine intensiven I/O-Zugriffe stattfinden. Denn bei Zugriffen auf bestimmten Geräten, z.B. IDE-Platten, wird für längere Zeit durch busy-waiting der Prozeßwechsel unterbrochen bzw. die Interrupts abgeschaltet, siehe dazu auch Kap. . Bei intensiven Zugriffen auf solche Geräte kann sich die Totzeit auf einige Millisekunden erhöhen.
Ein Problem besteht jetzt noch, wenn der Rechner zu langsam ist, d.h. die Zeit zum Berechnen des Steuerimpulses höher ist, als die Taktrate . In diesem Fall wird der Steuerprozeß fortwährend ausgeführt. Dies bedeutet, daß dann kein anderer Prozeß laufen kann und das ganze System scheinbar steht. Um dies zu verhindern, wird durch die Interruptfunktion der Steuerprozeß abgebrochen, falls dieser Fall eintreten sollte.