Ich glaube man könnte das so ungefähr machen: Von den Prozessen, die nicht gerade auf ein Event (Software oder I/O) warten, (die "wichtigsten") werden die mit der höchsten Priorität mittels Round-Robin scheduled.
Das bedeutet: Erst wenn alle Prozesse der höchsten Priorität sich schlafen gelegt haben (= auf ein Event warten), dann werden die Prozesse mit der nächstniedrigeren Priorität ausgeführt.
Beispiel:
Prioritäten: 1 = hoch (wichtig) ... 3 = normal ... 5 = niedrig (unwichtig)
Videokodierer: Priorität 5 <- unwichtig
MP3-Programm: Priorität 3 <- wichtig
Browser: Priorität 3 <- wichtig
Browser und MP3-Programm sind hier die wichtigsten. Also laufen die beiden so lange abwechselnd und erwärmen die CPU, bis sie fertig sind. Irgendwann entscheidet das MP3-Programm, dass er neue Daten von der Festplatte braucht. Er setzt den Lese-Befehl ab, und legt sich schlafen, bis die Daten im Speicher angekommen sind.
Der Browser ist jetzt das einzige, was CPU-Zeit verbraucht. Irgendwann will der Browser eine Seite aufrufen. Er setzt das Netzwerkpaket ab, und legt sich auch schlafen.
Jetzt schlafen alle Priorität 3-Prozesse und der Videokodierer ist der nächste, der laufen darf. Der hat gerade Daten im Speicher und rechnet fleißig an denen rum. Das macht er so lange, bis ein IRQ auftritt, und der Kernel ein Event für den Browser, oder den MP3-Player ausliefern kann. Dann wacht einer von denen wieder auf.
Ich hoffe dieses kurze Beispiel erläuter die Idee von oben ein wenig.
Modifikation: Prozesse, die viel CPU fressen (= nutzen ihr gesamtes Timeslice), bekommen automatisch niedrigerere Prioritäten, bis sie sich wieder besser verhalten.
Ein SETI@Home-Programm hätte zum Beispiel Priorität 6 (noch unwichtiger), und der Idle-Thread Priorität 7 (noch viel mehr unwichtiger^^) bekommen können, aber beide wären nie aufgerufen worden, solange der Videokodierer noch was zu rechnen hat.
Ich vermute aber in der Praxis muss man noch viel mehr Feintuning machen
![Wink ;)](https://forum.lowlevel.eu/Smileys/classic/wink.gif)