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:

1. "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.
   
2. "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.
   
3. "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.
   
4. "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.

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.