Prioritätenkonzept und Warteschlangen

Die Ausführungsprioritäten lassen sich wie folgt einteilen:

Prioritäten 0 - 29	Prioritäten für Systemtasks
Prioritäten 30 - 127	Feste Task-Scheduling-Prioritäten
Prioritäten 128 - 255	Variable Task-Scheduling-Prioritäten

Mit Ausnahme der Systemprioritäten werden die Prioritäten bei der Job-Klassen-Definition und benutzerspezifisch im Benutzerkatalog festgelegt.

Gibt der Benutzer im SET-LOGON-PARAMETERS- bzw. ENTER-JOB-Kommando eine Priorität an, dann wird diese sowohl in der dem Benutzer zugewiesenen Job-Klasse als auch im Benutzerkatalog geprüft.

Die Priorität einer Task wird sowohl bei der Aktivierung als auch bei der Initiierung (Zuteilung des Betriebsmittels CPU) berücksichtigt.

Über den Systemparameter ETMFXLOW gibt es die Möglichkeit, auch einen unteren Bereich von festen Prioritäten einzurichten.

Variable Prioritäten

Charakteristisch für die variablen Prioritäten ist die dynamische Anpassung der Priorität mit dem HRN-Algorithmus (= Highest-Response ratio Next).

HRN basiert auf dem Verhältnis „Verweilzeit / verbrauchte CPU-Zeit“ unter Berücksichtigung der Start-Priorität beim SET-LOGON-PARAMETERS bzw. ENTER-JOB-Kommando oder einer extern zugewiesenen Priorität (Kommando CHANGE-TASK-PRIORITY).

Der HRN-Algorithmus bewirkt, dass Tasks, die wenig CPU-Leistung aufnehmen, und Ein-/Ausgabe-intensive Tasks bevorzugt behandelt werden, ohne dabei rechenintensive Tasks extrem stark zu benachteiligen.
Darüber hinaus wird eine angemessene Versorgung auch für Tasks mit niedriger Start-Priorität gewährleistet.

Die variable Priorität wird zu folgenden Zeitpunkten neu berechnet:

• bei jeder Aktivierung

• bei jedem PEND/UNPEND nach Q5

• bei Ablauf der Mikrozeitscheibe (einem von der CPU-Geschwindigkeit und vom unmittelbar zurückliegenden E/A-Verhalten der Task abhängigen Zeitquantum)

• periodisch (1/Sekunde)

• bei Absetzen des Kommandos MODIFY-TASK-CATEGORIES

• bei Absetzen des Kommandos CHANGE-TASK-PRIORITY 

Feste Prioritäten

Die festen Prioritäten ändern sich nicht.

Für die betroffene Task stellt die feste Priorität eine starke Bevorzugung dar.
Feste Prioritäten sind für Anwendungen mit extremen Realzeitanforderungen entwickelt worden. Durch die Vergabe einer festen Priorität kann eine Performance-Verbesserung erreicht werden, jedoch unter Berücksichtigung folgender Punkte:
Feste Prioritäten engen den Entscheidungsspielraum des Systems stark ein. Zur Erzielung eines positiven Effektes müssen daher die Betriebsmittelanforderungen sämtlicher Tasks bekannt sein. Zur Aktivierung anstehende Tasks mit fester Priorität führen bei hoch ausgelasteten Betriebsmitteln zu einer sofortigen Verdrängung anderer Tasks, wodurch sich eine Überlastsituation ergeben kann. Das wiederum hat letztendlich negative Auswirkungen auf die Performance.

Feste Prioritäten sollten nur nach genauer Analyse der Last, der Betriebsmittel-Auslastung und zusammen mit lastbegrenzenden Maßnahmen (wie z.B. Beschränkung des Multiprogrammierungs-Grades der Kategorien durch den Operanden MAXIMUM-ACTIVE-TASKS im Kommando MODIFY-TASK-CATEGORIES) vergeben werden.

Zusammenfassend lässt sich Folgendes feststellen:

• Prioritäten, egal welche, beeinflussen die Task-Reihenfolge in den Warteschlangen.

• Jede Priorität, die besser ist als die „normale Priorität“ 255, beeinflusst das System unabhängig von der Lastsituation.

• Auf Grund der gesteigerten Bedeutung der Priorität kann die Systembetreuung durch Prioritätsänderung die Performance einzelner Tasks sehr leicht beeinflussen. Vor allem für leistungsschwächere Systeme mit nur wenigen Benutzertasks bietet sich an, die Tasks mit variablen Prioritäten unterschiedlicher Größenordnung zu belegen. Damit kann erreicht werden, dass jede Task die Leistung erhält, die ihrer Wichtigkeit entspricht.

• Arbeiten fast alle Tasks mit Priorität 255, genügt ein kleiner Prioritätsunterschied (z.B. 5), um eine Task deutlich zu bevorzugen. Bei einem größeren Prioritätsspektrum muss der Prioritätenunterschied entsprechend größer gewählt werden.
  Die Variation der Priorität sollte nach Last z.B. in 5er- oder 10er-Schritten vorgenommen werden, bis das gewünschte Performanceziel erreicht ist. In der Regel ist es unnötig, feste Prioritäten zu vergeben, da mit mittleren variablen Prioritäten (etwa 200) bereits gute Performancewerte erreicht werden können.
  Größere Prioritätsschritte sind bei einem permanent hohen Task-Aufkommen bzw. bei überwiegend Ein-/Ausgabe-intensiven Tasks notwendig.

• Die Zuteilung der Betriebsmittel Hauptspeicher und CPU an Benutzer- und Systemtasks wird entsprechend dem vorgegebenen Kategorien- und Prioritätenkonzept gesteuert. 

Warteschlangen

Im System vorhandene Tasks können sich in fünf Zuständen befinden:

• die Task belegt eine CPU

• die Task ist aktiv und ablaufbereit

• die Task ist aktiv, aber nicht ablaufbereit

• die Task ist inaktiv und ablaufbereit

• die Task ist inaktiv und nicht ablaufbereit

Die notwendige Basis bietet das Warteschlangensystem der Task-Steuerung, das die Tasks in Abhängigkeit des jeweiligen Zustandes in eine der folgenden Warteschlangen einreiht.

Q0	Laufende Task	Task in Control
Q1	Warten auf Zuteilung einer CPU	a k t i v und ablaufbereit
Q2	Schreibtasks von openSM2	a k t i v und nicht ablaufbereit
Q3	Warten auf Seitenwechsel	a k t i v und nicht ablaufbereit
Q4	Warten bei schneller Ein-/Ausgabe, Explizite Synchronisationsfunktionen (VPASS, SOLSIG, REVNT, Locks und Auftragsbeziehungen im System), Warten auf neue Eingabe für TP-Tasks	a k t i v und nicht ablaufbereit
Q5	pro Kategorie: Warten auf Aktivierung	i n a k t i v und ablaufbereit
Q6	pro Kategorie: Warten auf Zulassung durch PCS (nur falls PCS eingeschaltet ist)	i n a k t i v und ablaufbereit
Q10	Warten im HOLD-Zustand	i n a k t i v und nicht ablaufbereit
Q11	Wartende Systemtasks	i n a k t i v und nicht ablaufbereit
Q12	Warten bei langdauernder Ein- und Ausgabe und langdauernden Synchronisationsfunktionen insbesondere Terminal-Ein-/Ausgabe im Dialog	i n a k t i v und nicht ablaufbereit
Q13	Warten n Sekunden (PASS/VPASS)	i n a k t i v und nicht ablaufbereit

Tabelle 31: Warteschlangen der Task-Steuerung

Wartet eine Task nicht auf eine Eingabe, so hat sie das primäre Ziel, die CPU zu belegen. Das setzt in der Regel mehrere Zustandswechsel voraus.

Eine Benutzertask (z.B. der Kategorie Batch) befindet sich z.B. nach einem HOLD-TASK-Kommando in der Q10.
Sobald die Systembetreuung die Task mit dem Kommando RESUME-TASK wieder freigibt, verändert sie ihren Zustand.
Die Q10 wird verlassen und die Task wird in die Q5 (Subqueue für die jeweilige Kategorie, z.B. Batch) eingereiht. Dort wartet sie darauf, dass PRIOR über die Aktivierungsentscheidung auf diese Task zugreift und sie in die Q1 bringt und danach in die Q0.

Diese Zustandswechsel werden durch die PEND-/UNPEND-Routinen realisiert:
Die UNPEND-Routinen bringen die Task in Richtung CPU, die PEND-Routinen bringen die Task von einer hochwertigen Warteschlange in eine niederwertige Warteschlange.