Der OS/2-Scheduler

Der Scheduler -- auf deutsch vielleicht: "Fahrplaner" ;-) -- ist ein Teil des OS/2-Kernel, arbeitet also auf der untersten Ebene des Systems (vgl. hierzu auch die Erläuterungen zum WPS-Neustart).

Der Scheduler ist verantwortlich für das Multitasking und Multithreading in OS/2. Weil Sie idR. nur einen Prozessor haben, aber mehrere Programme wenigstens scheinbar gleichzeitig laufen sollen, schaltet der Scheduler viele Dutzend Mal in der Sekunde zwischen den verschiedenen Programmen um, so daß es so aussieht, als liefen die Programme gleichzeitig.

Für das Verständnis der einzelnen Einstellungen auf der Seite "Scheduler" im Objekt "OS/2 Kernel" ist ein grundsätzliches Verständnis der Art und Weise hilfreich, wie OS/2 Prozesse und Threads verwaltet. Ausführliche Hilfe zu den einzelnen Einstellungen erhalten Sie, wenn Sie den "Hilfe"-Knopf auf dieser Seite drücken.

Ein Thread ist die kleinste Verwaltungseinheit für die Umschaltung, die OS/2 zur Verfügung stellt. Ein Programm kann mehrere Threads, muß aber mindestens einen Thread enthalten. Die Bezeichnung "Thread" (auf deutsch etwa "Faden") wurde gewählt, weil innerhalb eines Threads Programminstruktionen sequentiell ausgeführt werden. Zwischen den Threads hingegen ist eine sequentielle Ausführung nicht gesichert, weil zu keinem Zeitpunkt bestimmt ist, welche Instruktion des einen Threads vor einer Instruktion eines anderen Threads ausgeführt wird.

Gut programmierte OS/2-Software benutzt mehrere Threads, um dem Benutzer eine schnellere Antwort auf seine Eingaben und Mausaktionen zu sichern. Wenn Sie zB. einen Befehl ausführen, der idR. länger dauern wird, so wird ein hochwertiges OS/2-Programm für diese Aufgabe einen neuen Thread starten, der diese Aufgabe ausführt. Während dieser Ausführung ist der Haupt-Thread des Programmes, der die Benutzereingaben entgegennimmt, bereits wieder zur Eingabe neuer Befehle bereit.

Schlecht programmierte OS/2-Software benutzt nur einen Thread, so daß während der Bearbeitung einer Aufgabe keine weiteren Benutzereingaben möglich sind. Ein Beispiel für solch schlechte Programmierung stammt ausgerechnet von IBM selbst: wenn Sie in VIEW.EXE "In allen Bibliotheken" nach einem bestimmten Begriff suchen, ist der Rechner komplett blockiert, bis alle Bibliotheken durchsucht sind. Hier wäre Multithreading sehr angebracht gewesen.

Threads können nun verschiedene Prioritäten besitzen. Allgemein gilt, daß ein Thread mit höherer Priorität mehr Prozessorzeit erhält als ein Thread mit geringerer Priotität. Dies gilt jedenfalls dann, wenn mehrere Threads zugleich etwas zu tun haben; wenn Threads gerade "leerlaufen", dh. auf weitere Aufgaben warten, verbrauchen sie keine Prozessorzeit, und die Prioritäten spielen keine Rolle.

OS/2 ermöglicht eine sehr differenzierte Prioritätszuweisung. Es unterscheidet zwischen vier Prioritätsklassen:

"Idle time priority" ist die geringste Prioritätsklasse. Solch ein Thread bekommt nur dann Prozessorzeit zugewiesen, wenn keine Threads mit höheren Prioritätsklassen Prozessorzeit benötigen, dh. nur dann, wenn diese "leerlaufen". Ein Beispiel hierfür ist der XFolder-"Worker"-Thread, der zB. Buch führt über die aktiven WPS-Objekte. Dies ist ziemlich zeitintensiv, aber nicht zeitkritisch: also wird es ausgeführt, wenn der Computer nichts anderes zu tun hat.
"Regular priority" ist die normale Prioritätsklasse. Die meisten Threads laufen mit dieser Klasse. OS/2 vergibt diese Klasse für neue Threads als Standard, wenn nichts anderes eingestellt wird. Zwischen Threads dieser Klasse ändert OS/2 dynamisch die Prioritätsebenen (dazu sogleich), um keinen dieser Threads auf Dauer "verhungern" zu lassen.
"Fixed-high priority" ist die zweithöchste Prioritätsklasse für Threads, die Daten für "reguläre" Threads vorbereiten müssen. Diese sollen vorrangig zur Ausführung kommen und nicht durch die dynamischen Prioritätsänderungen für "reguläre" Threads beeinflußt werden, was zB. häufig für Nachrichtenverteiler angewandt wird.
"Time-critical priority" ist die höchste Prioritätsklasse für Threads, die unmittelbar zur Ausführung kommen müssen, wenn sie etwas zu tun haben. Ein solcher Thread erhält sofort Prozessorzeit, wenn nötig, und wird nicht unterbrochen, bis er mit seiner Aufgabe fertig ist. Solche Threads sind idR. mit der Beantwortung von zeitkritischen Nachrichten beschäftigt, wie zB. Netzwerk- und andere Kommunikationssoftware.

Innerhalb jeder Prioritätsklasse kann schließlich noch die Prioritätsebene festgelegt werden. Dies ist ein Wert von -31 bis +31, der den Vorrang eines Threads innerhalb einer Prioritätsklasse festlegt.

Einige Beispiele:

Ein "regular thread" mit Priorität +31 verdrängt einen "regular thread" mit Prioriät 0.
Innerhalb der Klasse "Regular priority" sorgt OS/2 allerdings dafür, daß kein Thread "verhungert", also niemals zur Ausführung gelangt, indem nach einer bestimmten Zeit die Priorität eines niedrigeren Threads automatisch erhöht wird. Diese Zeit wird mit der CONFIG.SYS-Einstellung MAXWAIT festgelegt. OS/2 erhöht außerdem die Priorität eines Threads, wenn Tastatureingaben vorliegen, der Prozeß des Threads im Vordergrund läuft oder auf Geräte zugegriffen wird.
Diese dynamischen Änderungen werden jedenfalls dann vorgenommen, wenn in der CONFIG.SYS nicht der Befehl PRIORITY=ABSOLUTE steht, was nicht empfehlenswert ist. (Deswegen finden Sie diese Einstellung auch nicht auf der Einstellungsseite im Objekt "OS/2 Kernel").
Ein "time-critical thread" mit der Priorität -31 verdrängt immer noch einen "regular thread" mit der Priorität +31, weil er einer höheren Klasse angehört. Hierauf haben die beschriebenen dynamischen Anpassungen keine Auswirkungen, weil diese nur die "reguläre" Prioritätsklasse betreffen.
Gleiches gilt zB. für einen "regular thread" mit der Priorität 0 gegenüber einem "idle-time thread" mit der Priorität 0.
Zwei Threads mit gleicher Priorität hingegen laufen gleichmäßig "gegeneinander", dh. sie wechseln sich mit der Benutzung der Prozessorzeit ab.

Ein Prozeß ist demgegenüber eine OS/2-Anwendung, die in den Speicher geladen wurde. Jeder Prozeß muß mindestens aus einem Thread bestehen. Jeder Prozeß enthält gemeinsame Daten sowie Zugriff auf Systemressourcen. Prozesse werden gegeneinander vor ungültigen Speicherzugriffen geschützt, indem OS/2 ihnen den Zugriff auf Speicherbereiche verweigert, die ihnen nicht gehören ("Speicherschutz"). Mehrere Threads innerhalb eines Prozesses können jedoch auf den Speicher des Prozesses zugreifen, weil der Speicher pro Prozeß verwaltet wird. Gleiches gilt für andere Systemressourcen wie zB. geöffnete Dateien.