Hol' Dir diese Lernkarten, lerne & bestehe Prüfungen. Kostenlos! Auch auf iPhone/Android!

Die Komponente im Prozessmanager, die für die Planung der Betriebsmittelzuteilung zuständig ist, heißt Scheduler. Die Komponente, die dann einen tatsächlichen Prozesswechsel ausführt, wird als Dispatcher bezeichnet.

Batchsysteme:
– First Come First Served (FCFS): FCFS bearbeitet die im System ankommenden Aufträge in der Reihenfolge ihres Eintreffens.
– Shortest Job First (SJF): SJF sucht sich dagegen immer den Job bzw. Prozess aus, von dem es die kürzeste Bedienzeit erwartet.

Dialogsysteme:
– Round Robin (RR): RR ist im Prinzip FCFS (siehe Batch-Strategien) in Verbindung mit einer Zeitscheibe (Quantum genannt). RR geht davon aus, dass alle Prozesse gleich wichtig sind. Ein Prozess erhält ein bestimmtes Quantum, und wenn es abgelaufen ist, wird der Prozess unterbrochen und ein anderer Prozess erhält die CPU. Der unterbrochene Prozess wird hinten in die Warteschlange eingetragen und kommt erst dann wieder an die Reihe, wenn die anderen Prozesse ihr Quantum  verbraucht haben oder aus einem anderen Grund unterbrochen wurden. Die Frage nach der Länge der Zeitscheibe ist von großer Bedeutung für die Leistung des Systems.
– Priority Scheduling (PS): PS wählt immer den Prozess mit der höchsten Priorität aus. Dies setzt natürlich die Verwaltung von Prioritäten voraus.

Im non-preemptive, auch „run-to-completion“-Verfahren genannt, darf ein Prozess nicht unterbrochen werden, bis er seine Aufgaben vollständig erledigt hat. Beispiele: First Come First Served (FCFS) und Shortest Job First (SJF).

Im Gegensatz dazu darf im preemptive Scheduling eine Unterbrechung stattfinden. Rechenbereite Prozesse können somit suspendiert werden. Dies setzt natürlich eine Strategie zur Vergabe der CPU voraus, die vom Betriebssystem unterstützt werden muss und in der Regel auf der Zeitscheibentechnik basiert. Dieses Verfahren ist für die Unterstützung konkurrierender Benutzer geeignet. Beispiele: Round Robin (RR) und Priority Scheduling (PS).

– Wartezeit: Zeit, die ein Prozess auf die Ausführung warten muss, also die Summe aller Zeiträume, in denen ein Prozess warten muss.
– Bedienzeit (Servicezeit): Zeit, in der ein Prozess die CPU hält und arbeiten kann.
– Antwortzeit: Zeit, in der ein Anwender auf die Bearbeitung seines Auftrags warten muss.
– Durchsatz: Anzahl an Prozessen, die ein System in einer bestimmten Zeit bearbeiten kann.
– CPU-Auslastung: Auslastung der CPU während der Berbeitung von Prozessen in % der Gesamtkapazität.
– Durchlaufzeit = Verweilzeit: Gesamte Zeit, in der sich ein Prozess im System befindet (Servicezeiten + Wartezeiten).

-> Priority Boost
Unter Windows könnten Threads mit niedrigerer Priorität verhungern, da rechenintensive Threads höherer Priorität immer bevorzugt werden. Daher ist unter Windows noch ein Mechanismus implementiert, der einmal pro Sekunde prüft, ob
ein Thread schon 300 ms oder länger nicht mehr die CPU hatte, obwohl er im Zustand „bereit“ ist. Ist dies der Fall, wird seine Priorität auf 15 angehoben und sein Quantum wird verdoppelt. Nachdem er die CPU erhalten hat, wird er wieder auf den alten Zustand gesetzt. Ein Verhungern von Prozessen wird damit also vermieden.

RR (Round Robin) ist im Prinzip FCFS (First Come First Served) in Verbindung mit einer Zeitscheibe. RR geht davon aus, dass alle Prozesse gleich wichtig sind. Ein Prozess erhält ein bestimmtes Quantum (auch sog. Zeitscheibe oder engl. „timeslice“ genannt) und wenn es abgelaufen ist, wird der Prozess unterbrochen und ein anderer Prozess erhält die CPU. Der unterbrochene Prozess wird hinten in die Warteschlange eingetragen und kommt erst dann wieder an die Reihe, wenn die anderen Prozesse ihr Quantum verbraucht oder aus einem anderen Grund unterbrochen wurden. Die Frage nach der Länge der Zeitscheibe ist von großer Bedeutung für die Leistung des Systems. Heutzutage ist die Länge des Quantums dynamisch zwischen 10 und 200 ms lang.

SRTF wählt den Prozess mit der kürzesten noch verbleibenden Zeit als nächstes aus und wäre theoretisch für Dialogprozesse optimal. Er ist kaum zu realisieren, da in Betriebssystemen keine Informationen über die verbleibende Prozesszeit vorliegen.

-> gleiches Problem wie bei Belady - man kann nicht in die Zukunft sehen!

–Jeder Prozess / Thread hat einen wait_runtime Wert (Nanosekunden-Basis) der die aufgelaufende Wartezeit summiert
–Prozess mit höchster wait_runtime wird als nächstes gewählt und bleibt so lange aktiv, bis wait_runtime wieder auf einen fairen Wert reduziert worden ist
–Ziel: Wert von wait_runtime für alle Prozesse gleich halten
–Keine Statistiken, keine run queue, kein Switching von active nach expired queue
–Keine Quanten (Zeitscheiben)