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.