-
Die
vorliegende Erfindung betrifft allgemein die Ressourcenplanung in
einem System wie zum Beispiel einem Rechner.
-
Das
allgemeine Ziel der Ressourcenplanung besteht darin, die Verwendung
von oder den Zugriff auf die Ressource durch Tasks in eine Reihenfolge zu
bringen, um mehrere Ziele auf Systemebene und/oder auf Benutzerebene
zu erreichen. Zu diesen Zielen können
beispielsweise Ressourcenauslastungsziele zwischen verschiedenen
Arten (d.h. Klassen) von Tasks, das Erreichen von Warte-/Antwortzeitzielen
zwischen verschiedenen Task-Klassen, die Bereitstellung einer vorhersagbaren
Leistung (d.h. einer Leistung mit geringen Schwankungen) sowohl
innerhalb von Task-Klassen als auch über alle Task-Klassen hinweg,
die gerechte Zuteilung von Ressourcen und die Bevorzugung von Tasks
mit einer kurzen Ressourcennutzungs-/besitzdauer gegenüber Tasks
mit einer langen Ressourcennutzungs-/besitzdauer gehören.
-
Viele
dieser Planungsziele stehen miteinander in Konflikt, wodurch sich
die Ressourcenplanung schwierig gestaltet. Angesichts dieser Komplexität wurden
viele Algorithmen für
die Ressourcenplanung entwickelt, um nur einen Teil der vorstehenden
Ziele zu erreichen. Während
diese Verfahren in ihren vorgesehenen Bereichen gewöhnlich wirkungsvoll
sind, sind sie in Systemumgebungen mit unterschiedlichen Anforderungen
oftmals nur mäßig erfolgreich
oder funktionieren überhaupt
nicht gut. Tatsächlich
ist es nicht ungewöhnlich,
dass man Systeme vorfindet, bei denen die Planungs- und Zuteilungsparameter
als Reaktion auf große Änderungen
bei der Auslastung des Kunden von Hand eingestellt werden müssen. Diese
Notwendigkeit verursacht eine unerwünschte Komplexität und einen
unerwünschten
Aufwand. Neben der Unterstützung
von vielen unterschiedlichen Zielen bei der Ressourcenplanung besteht
eine wesentliche gestalterische Herausforderung darin, eine wirksame
Steuerung der Zuteilung von Ressourcen zu ermöglichen, um die gewünschten
Leistungsanforderungen für
diese gleichzeitigen Ziele zu erfüllen.
-
"Time-Function Scheduling:
A General Approach To Controllable Resource Management", IBM RESEARCH REPORT
RC 20155, März
1995, von Fong u.a., beschreibt eine Vorgehensweise zur zeitlichen
Abfolgeplanung auf der Grundlage von Job-Klassen, bei der alle ausführbaren
Jobs mit ähnlichen
Eigenschaften einer bestimmten Job-Klasse zugeordnet werden. Job-Klassen
werden in drei verschiedene Gruppen, H, T und L, unterteilt, wobei
den Jobs in der Gruppe H absolute Priorität eingeräumt wird, Jobs in der Gruppe
T ausgeführt
werden, wenn sich in der Gruppe H keine Jobs befinden, und Jobs in
der Gruppe L ausgeführt
werden, wenn sich in der Gruppe T keine Jobs befinden. Die Prioritäten bei
der zeitlichen Abfolgeplanung in jeder Gruppe werden von Zeitfunktionen
festgelegt, die zu Job-Klassen gehören, welche die jeweilige Gruppe
bilden.
-
Folglich
stellt die Erfindung ein Verfahren zur zeitlichen Abfolgeplanung
von Jobs bereit, die von einer Ressource ausgeführt werden sollen, wobei das verfahren
die folgenden Schritte umfasst:
Gliedern der Jobs in eine Hierarchie,
die Job-Klassen umfasst, wobei zu mindestens einer Job-Klasse ein Satz
von Unterklassen gehört;
Bereitstellen
eines Nutzungsziels, um die Ressource der Hierarchie zuzuteilen;
Bereitstellen
eines Antwortzeitziels, um die Ressource der Hierarchie zuzuteilen;
und
Terminierung von Job-Klassen zur Ausführung, um ein Ziel zu erfüllen, das
aus der Gruppe der Ziele ausgewählt
wird, die aus dem Nutzungsziel, dem Antwortzeitziel und einer Kombination
aus dem Nutzungsziel und dem Antwortzeitziel besteht.
-
In
einer bevorzugten Ausführungsform
teilt das Nutzungsziel die Ressource Job-Klassen anteilig zu, und
das Antwortzeitziel teilt die Ressource anteilig Unterklassen innerhalb
einer bestimmten Job-Klasse zu, während in einer anderen bevorzugten
Ausführungsform
das Gegenteil gilt (das Antwortzeitziel teilt die Ressource Job-Klassen
anteilig zu, und das Nutzungsziel teilt die Ressource Unterklassen
innerhalb einer bestimmten Job-Klasse anteilig zu).
-
Vorzugsweise
beinhaltet das Verfahren des Weiteren den Schritt der dynamischen
Anpassung des Nutzungs- und/oder des Antwortzeitziels, wobei diese
Anpassung vorgenommen werden kann, indem Werte von Zeitfunktionen,
die zu einer oder mehreren Job-Klassen gehören, angepasst werden.
-
Überdies
beinhaltet das Verfahren vorzugsweise den Schritt des Wechsels eines
Jobs zwischen Job-Klassen und üblicherweise
die Rückgabe
des Jobs an eine Ursprungs-Jobklasse, wenn der Job nicht innerhalb
von einem bestimmten Zeitraum auf die Ressource zugreift.
-
In
einer bevorzugten Ausführungsform
werden die Jobs in eine Hierarchie von Gruppen von Job-Klassen gegliedert,
wobei mindestens eine erste Gruppe von Job-Klassen eine höhere Priorität als eine
zweite Gruppe von Job-Klassen hat. Die erste Gruppe von Job-Klassen
umfasst Job-Klassen, die kurze System-Tasks, interaktive Tasks und
Jobs mit Echtzeiteinschränkungen
umfassen. Zu jeder der Job-Klassen in der ersten Gruppe gehört eine
konstante Zeitfunktion, und zu jeder der Job-Klassen in der zweiten
Gruppe der Job-Klassen gehört
eine dynamische Zeitfunktion. Es sei angemerkt, dass bei Verwendung
von Klassengruppen ein Nutzungs- oder Antwortzeitziel auf Job-Klassen
innerhalb einer bestimmten Gruppe angewendet werden kann.
-
Die
Erfindung stellt auch ein Rechnersystem bereit, das eine Prozessor-Ressource,
ein Betriebssystem und eine Ablaufzeitsteuerung (scheduler) enthält, die
von dem Betriebssystem ausgeführt
wird, um die zeitliche Abfolge von Jobs, die von dem Prozessor ausgeführt werden
sollen, zu planen, wobei die Ablaufzeitsteuerung Folgendes umfasst:
ein
Mittel, das dazu dient, die Jobs in eine Hierarchie zu gliedern,
welche Job-Klassen umfasst, wobei zu mindestens einer Job-Klasse
ein Satz von Unterklassen gehört;
ein
Mittel, das dazu dient, ein Nutzungsziel bereitzustellen, um die
Ressource der Hierarchie zuzuteilen;
ein Mittel, das dazu dient,
ein Antwortzeitziel bereitzustellen, um die Ressource der Hierarchie
zuzuteilen; und
ein Mittel, das dazu dient, Job-Klassen zur
Ausführung
zu terminieren, um ein Ziel zu erfüllen, das aus der Gruppe der
Ziele ausgewählt
wird, welche aus dem Nutzungsziel, dem Antwortzeitziel und aus einer Kombination
aus dem Nutzungs- und
dem Antwortzeitziel besteht.
-
Die
Erfindung stellt auch ein Rechnerprogrammprodukt bereit, das eine
Ablaufzeitsteuerung enthält,
um die zeitliche Abfolge von Jobs, die von einer Ressource ausgeführt werden
sollen, zu planen, wobei die Ablaufzeitsteuerung Folgendes umfasst:
ein
Mittel, das dazu dient, die Jobs in eine Hierarchie zu gliedern,
welche Job-Klassen umfasst, wobei zu mindestens einer Job-Klasse
ein Satz von Unterklassen gehört;
ein
Mittel, das dazu dient, ein Nutzungsziel bereitzustellen, um die
Ressource der Hierarchie zuzuteilen;
ein Mittel, das dazu dient,
ein Antwortzeitziel bereitzustellen, um die Ressource der Hierarchie
zuzuteilen; und
ein Mittel, das dazu dient, Job-Klassen zur
Ausführung
zu terminieren, um ein Ziel zu erfüllen, das aus der Gruppe der
Ziele ausgewählt
wird, die aus dem Nutzungsziel, dem Antwortzeitziel und einer Kombination
aus dem Nutzungsziel und dem Antwortzeitziel besteht.
-
Die
Erfindung stellt auch ein verfahren zur zeitlichen Abfolgeplanung
von Jobs, die von einer Ressource ausgeführt werden sollen, bereit,
das die folgenden Schritte umfasst:
anteilige Zuteilung der
Ressource zu einem Satz von Job-Klassen
entsprechend einem Antwortzeitziel oder einem Nutzungsmodusziel,
wobei zu jeder der Job-Klassen ein monoton nichtsteigender Zeitfunktionswert
gehört;
und
Terminierung von Job-Klassen zur Ausführung, um das Modusziel zu
erfüllen.
-
Entsprechend
einem Antwortzeitziel wird bevorzugt, dass der Zeitfunktionswert
für jede
Job-Klasse von einer Wartezeit eines ältesten Jobs in der Job-Klasse
bestimmt wird und dass die zeitliche Abfolge der Job-Klassen in
jedem Abfolgeplanungszeitraum geplant wird, indem eine bestimmte
Job-Klasse ausgewählt
wird, die den kleinsten Zeitfunktionswert hat; während der Zeitfunktionswert
für jede
Job-Klasse entsprechend einem Nutzungsmodusziel von einer Gesamtnutzung
durch alle Jobs in der Job-Klasse bestimmt wird und die zeitliche
Abfolge der Job-Klassen in jedem Abfolgeplanungszeitraum geplant
wird, indem eine bestimmte Job-Klasse ausgewählt wird, die den kleinsten
Zeitfunktionswert hat.
-
Vorzugsweise
umfasst das Verfahren des Weiteren die folgenden Schritte:
anteilige
Zuteilung der Ressource zu einem Satz von Job-Klassen entsprechend einem Antwortmodusziel, wobei
zu jeder der Job-Klassen ein monoton nichtsteigender Zeitfunktionswert
gehört;
und
anteilige Zuteilung der Ressource zu einem Satz von Job-Klassen entsprechend
einem Nutzungsmodusziel, wobei zu jeder der Job-Klassen ein monoton nichtabnehmender
Zeitfunktionswert gehört;
und
Terminierung von Job-Klassen zur Ausführung, um das Antwortmodusziel,
das Nutzungsmodusziel oder eine Kombination aus dem Antwortmodusziel
und dem Nutzungsmodusziel zu erfüllen.
-
Unter
einem anderen Aspekt betrachtet, stellt die Erfindung des Weiteren
ein Verfahren zur zeitlichen Abfolgeplanung von Jobs bereit, die
von einer Ressource in einem Rechnersystem ausgeführt werden
sollen, wobei das Verfahren die folgenden Schritte umfasst:
Gliedern
der Jobs in eine Hierarchie, die Gruppen von Job-Klassen umfasst, wobei mindestens eine Gruppe
von Job-Klassen mindestens eine Job-Klasse enthält, zu der ein Satz von Unterklassen
gehört;
anteilige
Zuteilung des Prozessors zu der Hierarchie entsprechend einem Nutzungsziel;
anteilige
Zuteilung des Prozessors zu der Hierarchie entsprechend einem Antwortziel;
und
Terminierung von Job-Klassen zur Ausführung, um ein Ziel zu erfüllen, das
aus der Gruppe von Zielen, welche aus dem Nutzungsziel, dem Antwortzeitziel und
einer Kombination aus dem Nutzungsziel und dem Antwortzeitziel besteht,
ausgewählt
wird.
-
Unter
einem anderen Aspekt betrachtet, stellt die Erfindung des Weiteren
ein Verfahren zur zeitlichen Abfolgeplanung von Jobs bereit, die
von einem Prozessor in einem Rechnersystem ausgeführt werden
sollen, wobei das Verfahren die folgenden Schritte umfasst:
Gliedern
der Jobs in eine Hierarchie, die Job-Klassen umfasst, wobei zu mindestens
einer Job-Klasse ein Satz von Unterklassen gehört;
anteilige Zuteilung
des Prozessors zu der Hierarchie entsprechend einem Nutzungsziel;
anteilige
Zuteilung des Prozessors zu der Hierarchie entsprechend einem Antwortziel;
und
Terminierung von Job-Klassen zur Ausführung, um ein Ziel zu erfüllen, das
aus der Gruppe von Zielen, welche aus dem Nutzungsziel, dem Antwortzeitziel und
einer Kombination aus dem Nutzungsziel und dem Antwortzeitziel besteht,
ausgewählt
wird.
-
Wie
hier beschrieben wird, können
folglich die anteiligen Nutzungs- und Antwortzeit-Leistungsziele
bei der Inanspruchnahme einer Ressource oder beim Zugriff auf eine
Ressource innerhalb eines einheitlichen und integrierten Mechanismus
zur zeitlichen Abfolgeplanung eines Systems festgelegt werden, welcher
die zeitliche Abfolgeplanung einer Ressource, zum Beispiel eines
Rechnerprozessors, sowohl im "Nutzungs"-Modus als auch im "Antwortzeit"-Modus gestattet,
wobei ein Modus innerhalb der Grenzen einer Job-Klasse ausgeführt wird,
die in dem anderen Modus Einschränkungen
unterlag. Angesichts der allgemeinen, flexiblen und adaptiven Steuerungshoheit über die
Ressourcen-Zuteilung kann sich daher ein System ohne manuelles Eingreifen
dynamisch an veränderte
Arbeitslastanforderungen der Ressource anpassen und dadurch verschiedene
Ziele der zeitlichen Abfolgeplanung und auch unterschiedliche Leistungsanforderungen
erfüllen. Solche
Mechanismen zur zeitlichen Abfolgeplanung werden üblicherweise
in einem Rechner oder einem Rechnersystem ausgeführt, können aber auch in anderen Formen
eines Systems Anwendung finden.
-
In
der bevorzugten Ausführungsform
kann die Inanspruchnahme einer Ressource in einem Rechner mit Hilfe
eines hierarchischen Schemas, das die Kombination aus "Nutzungs"- und "Antwort"-Moduszielen allgemein und flexibel
unterstützt, auf
beliebig vielen Stufen geplant werden. Allgemeine zeitbasierte Funktionen
werden verwendet, die von Ressourcennutzungs- und Antwortzeitzielen,
einem adaptiven Rückmeldemechanismus
und so genannten Ressourcenanforderer-Klassen gesteuert werden, wobei eine
Klasse aus einer Gruppe von Anforderern besteht, die im Verhältnis zu
anderen Klassen von Anforderern in dem System dasselbe Leistungsziel
haben. Die Ablaufzeitsteuerung für
die Job-Klassen enthält
einen zu jeder Klasse gehörenden
Migrationsmechanismus, so dass ein bestimmter Job, der die Ressource "taxiert", in eine Job-Klasse niedrigerer
Priorität
umgelagert wird, nachdem er einen Satz von Nutzungskriterien erfüllt hat.
-
Wie
hier beschrieben wird, wird die Ressourcenplanung folglich für Jobs in
Job-Klassen innerhalb einer einheitlichen Struktur gemäß "Zeitfunktionen" durchgeführt. Jede
Job-Klasse hat eine zu ihr gehörende "Zeitfunktion", deren Wert bei
Freiwerden der Ressource dynamisch steuert, wann die Job-Klasse zur
zeitlichen Abfolgeplanung ausgewählt
wird. Eine Zeitfunktion kann jede beliebige Funktion der "Zeit" im allgemeinsten
Sinne sein, wie zum Beispiel eine Formel, die die genauen Werte
bestimmt, die von der Funktion bei Eingabe von Werten eines Satzes
von Variablen (oder Eingabeparametern) zurückgeliefert werden. Der Parameter "Zeit" kann ein beliebiges Zeitmaß in Bezug
auf die Ressource und auf andere Ressourcen sein, die zur Berechnung
des Zeitfunktionswerts je Klasse verwendet werden. Bei der bevorzugten
Arbeitsweise kann als Grundlage für die Zeitfunktionen ein allgemeiner "Nutzungs"-Modus dienen, bei
dem der Zeitparameter ein beliebiges Maß für die Nutzung der Ressource
oder der Gruppe von Ressourcen durch die Klasse ist, ein allgemeiner "Antwort"-Modus, bei dem der
Zeitparameter ein beliebiges Maß für die Wartezeit
auf die Ressource oder die Gruppe von Ressourcen durch die Klasse
ist, oder eine beliebige Kombination dieser Modi. Jedes allgemeine
Größenordnungsverhältnis oder
jede allgemeine Auswahlfunktion kann dann zur Feststellung verwendet
werden, welche Klasse auf der Grundlage der Zeitfunktionswerte je
Klasse ausgewählt
werden soll. Beispielhafte Auswahlfunktionen sind unter anderem
der Maximum- und der Minimum-Operator, bei der bevorzugten Arbeitsweise
ist die Auswahlfunktion üblicherweise
jedoch der Operator, der den kleinsten Wert unter den berücksichtigten Zeitfunktionswerten
auswählt.
Sobald eine Job-Klasse zur zeitlichen Abfolgeplanung ausgewählt wurde, wird
der Ressource ein Job in dieser Klasse zur Ausführung bereitgestellt.
-
Die
Job-Klassen, die um die Aufmerksamkeit einer Ressource konkurrieren,
werden vorzugsweise in einer allgemeinen "Hierarchie" angeordnet. Die Zeitfunktionen, die
zu den Klassen einer jeden Stufe der Hierarchie gehören, haben
denselben "Modus". Jeder Modus ist
vorzugsweise jedoch gleich und gleich bleibend durchführbar. Darüber hinaus
können der
Systemadministrator und/oder der Benutzer die Job-Klassen und die
Zeitfunktionsmodi auf jeder Stufe in jeder gewünschten Weise und für die gewünschte Anzahl
von Stufen festlegen. Zum Beispiel kann die oberste Stufe der Hierarchie
aus mehreren Job-Klassen bestehen, unter denen die Ressource zugeteilt
wird, um einen Satz von anteiligen Nutzungszielen aufrechtzuerhalten.
Jede dieser Klassen hat eine zu ihr gehörende Nutzungsmodus-Zeitfunktion,
die dynamisch steuert, welche Klasse bei Freiwerden der Ressource
zur zeitlichen Abfolgeplanung ausgewählt wird. Auf der nächsten Stufe
der Hierarchie kann jede der Klassen der obersten Stufe mehrere
Unterklassen umfassen, unter denen die Ressource zugeteilt wird,
um einen Satz von Antwortzeitzielen aufrechtzuerhalten. Jede dieser
Unterklassen hat eine zu ihr gehörende
Antwortmodus-Zeitfunktion, die dynamisch steuert, welche Unterklasse
zur zeitlichen Abfolgeplanung ausgewählt wird, wenn ihre Elternklasse
auf der obersten Stufe der Hierarchie ausgewählt wird. Diese hierarchische
Struktur zur zeitlichen Abfolgeplanung ist vollkommen allgemein
gehalten und kann rekursiv mit der erforderlichen/gewünschten
Anzahl von Stufen festgelegt werden.
-
In
der bevorzugten Ausführungsform
kann die Gruppe der Job-Klassen
auf jeder Stufe der Hierarchie zur zeitlichen Abfolgeplanung in "Gruppen" von Job-Klassen
unterteilt werden, wobei die erste Gruppe absolute Priorität vor allen
anderen Gruppen in dem Sinn hat, dass Job-Klassen in anderen Gruppen
für einen
Zugriff auf die Ressource nur in Betracht kommen, wenn alle Klassen
in der ersten Gruppe leer sind. Die zweite Gruppe der Job-Klassen hat
absolute Priorität
vor allen anderen Gruppen mit Ausnahme der ersten Gruppe der Job-Klassen, und eine ähnliche
Festlegung der Rangfolge hinsichtlich der absoluten Priorität wird für die restlichen
Gruppen der Job-Klassen vorgenommen. Die Zeitfunktionen für die Klassen
in jeder Gruppe sind in dem Sinn ähnlich gestaltet, dass sie
entweder konstant sind (d.h., sie verändern sich nicht mit der "Zeit") oder sich entsprechend
dem "Nutzungs"-Modus oder aber
dem "Antwort"-Modus dynamisch
verändern.
Eine erste Gruppe von Job-Klassen kann zum Beispiel kurze System-Tasks
mit hoher Priorität,
interaktive Arbeit (bei der es zwischen größeren Ruheperioden nur zu einer
geringen Nutzung von Ressourcen kommt) und Jobs mit Echtzeiteinschränkungen
umfassen, die absolute Priorität
vor anderen Arbeitsklassen haben.
-
In
einer bevorzugten Ausführungsform
findet die Gruppierung von Job-Klassen in erster Linie auf der obersten
Stufe der Hierarchie statt, aber alternativ können Gruppen von Job-Klassen auf jeder
beliebigen Stufe der Hierarchie oder auf einer Kombination von Hierarchiestufen
allgemein verwendet werden.
-
Mehrere
adaptive Rückmeldemechanismen werden
vorzugsweise in die Struktur zur zeitlichen Abfolgeplanung aufgenommen.
Ein solches Verfahren beinhaltet die adaptive Einstellung der Zeitfunktionen
bei Änderungen
der Ressourcennutzung, bei einer Mischung von Jobs oder bei irgendeinem
anderen Auslöser
(Trigger) oder Ereignis. Ein weiteres Verfahren beinhaltet die Umlagerung
von Jobs aus einer Klasse in eine andere Klasse in der Hierarchie, wenn
die Nutzung der Ressource oder der Gruppe von Ressourcen von einem
Systemadministrator und/oder einem Benutzer festgelegte Grenzwerte überschreitet,
und die anschließende
Rückgabe
des Jobs an seine Ursprungsklasse, wenn er für einen ausreichend langen
Zeitraum, der vom Systemadministrator oder dem Benutzer vorab festgelegt
wird, inaktiv wird.
-
Verschiedene
bevorzugte Ausführungsform der
Erfindung werden nun lediglich anhand eines Beispiels und mit Bezug
auf die folgenden Zeichnungen ausführlich beschrieben:
-
1 ist
eine repräsentative
Hierarchie von Job-Klassen, die um den Zugriff auf eine bestimmte Ressource
in einem Rechner oder in einem Rechnersystem konkurrieren;
-
2 ist
eine beispielhafte Hierarchie, bei der einem Paar von Untergruppen
Nutzungs- und Antwortzeiten anteilig zugeteilt werden, wobei diese Zuteilungen
zeitbasierte Funktionen enthalten, die sich dynamisch verändern;
-
3A veranschaulicht
die grundlegende Arbeitsweise des Ablaufzeitsteuerungsmechanismus,
der in dem Betriebssystem eines Rechners unterstützt wird;
-
3B veranschaulicht
die grundlegende Arbeitsweise des Ablaufzeitsteuerungsmechanismus,
wenn der Mechanismus als Zusatz zum Betriebssystem unterstützt wird;
-
4 ist
ein Flussdiagramm, das eine Gruppenauswahl-Routine (Group Selection
routine) des Ablaufzeitsteuerungsmechanismus veranschaulicht;
-
5 ist
ein Flussdiagramm, das eine Klassenauswahl-Routine (Class Selection
routine) zeigt;
-
6 ist
ein Flussdiagramm, das eine Klassenaktualisierungs-Routine (C1ass
Update routine) zeigt;
-
7 ist
ein Flussdiagramm, das eine Jobeintritts-/rückgabe-Routine (Job Enter/Return routine)
zeigt;
-
8 ist
ein Flussdiagramm, das eine Verlaufsaktualisierungs-Routine (History
Update routine) zeigt; und
-
9A bis 9B sind
Graphen von der Veranschaulichung dienenden Nutzungsmodus- und Antwortmodus-Abfolgesteuerungszielen,
die zeigen, wie die zeitliche Abfolge von Job-Klassen geplant wird.
-
In
der hier verwendeten Weise besteht eine "Klasse" im Allgemeinen aus einer Gruppe von
Anforderern, die im Verhältnis
zu anderen Klassen von Anforderern in dem System dieselben Leistungsziele haben.
In manchen Fällen
hat eine Klasse nur einen einzigen Anforderer. Auch wird ein Anforderer
hier oftmals als ein "Job" bezeichnet, bei
dem es sich um eine Arbeitsanforderung handelt, die um den Zugriff auf
eine Ressource in einem bestimmten Abfolgesteuerungsintervall konkurriert.
Anders ausgedrückt, im
Zusammenhang mit einem Rechnersystem ist ein Job gleichbedeutend
mit einem Anforderer. Folglich hat jede "Job-Klasse" üblicherweise
eine zugehörige Anzahl
von Jobs, die auf die Ressource zugreifen oder die Ressource "besitzen" möchten. Jobs
können
vom System, vom Benutzer oder einer Kombination von beiden einer
bestimmten Klasse zugewiesen werden. Ebenso können Job-Klassen vom System oder
vom Benutzer zugewiesen werden. In der hier verwendeten Weise kann
eine "Job-Klasse" einen oder mehrere "Jobs" enthalten.
-
In
einer repräsentativen
Ausführungsform
ist die Ressource ein Prozessor eines Rechners oder eines Rechnersystems.
Wie bekannt ist, hat der Prozessor eine begrenzte Anzahl von Rechenzyklen
je Zeiteinheit. Viele verschiedene "Klassen" von Jobs möchten Zugriff auf einen Prozessor
haben. Das hier angegangene Problem betrifft die Einsatzplanung des
Prozessors für
verschiedene Klassen von Anforderungen in einer Weise, die seine
wirksame Nutzung auf ein Höchstmaß steigert,
gleichzeitig jedoch eine Reihe von Ressourcennutzungszielen auf
Systemebene und/oder auf Benutzerebene erreicht.
-
Es
gibt generell zwei Arten von Zielen bei der Inanspruchnahme von
Ressourcen: die Nutzung und die Antwort. Weder der Nutzungs- noch
der Antwortmodus wird bei dem einheitlichen und integrierten Verfahren,
das nachstehend beschrieben wird, bevorzugt, und wie zu sehen sein
wird, wurde diese methodische Vorgehensweise entwickelt, um sich
die funktionalen Vorteile eines jeden Modus und einer jeden gewünschten
Kombination dieser Modi uneingeschränkt zunutze zu machen. Das
Ergebnis ist ein sehr robuster Ablaufzeitsteuerungsmechanismus, der
eine "feine" Steuerung der Ressourcenplanung stark
vereinfacht. Im "Nutzungs"-Modus wird die Ressource
Job-Klassen oder
einem Satz von Job-Klassen (bei einer Ausführung mit mehreren Hierarchiestufen)
auf der Grundlage eines für
diese Klassen (oder Unterklassen) festgelegten proportionalen Nutzungsziels
anteilig zugeteilt. Wie zu sehen sein wird, beruht die anteilige
Zuteilung in der bevorzugten Ausführungsform der Erfindung auch
auf einer Gesamtnutzung (im Sinne des auf dem bisherigen Verlauf beruhenden
Durchschnitts) der Ressource durch jede Job-Klasse (oder Untergruppe
von Job-Klassen).
Im Falle einer Ausführung
mit nur einer Stufe, bei der eine Gruppe von Job-Klassen beteiligt
ist, kann die Klasse 1 (zum Beispiel) 60 % der Ressource erhalten,
wohingegen die Klasse 2 40 % der Ressource erhält. Im "Antwort"-Modus wird die Ressource Job-Klassen
oder einem Satz von Job-Unterklassen (bei einer Ausführung mit
mehreren Stufen) zugeteilt, um ein für diese Klassen festgelegtes
anteiliges Antwortzeitziel zu erfüllen oder um eine gewichtete
Summe einer Funktion der Antwortzeiten für diese Klassen auf einen kleinstmöglichen
Betrag zu verringern. Diese Zielsetzung kann zum Beispiel vorgeben,
dass die mittleren Antwortzeiten der Klassen 1, 2 und 3 im Verhältnis 3:2:1
(oder so nah an diesen Werten wie möglich) aufrechtzuerhalten sind.
Das jeweilige anteilige Nutzungsziel beziehungsweise das oder die
anteilige(n) (oder das oder die auf einer gewichteten Summe beruhende(n))
Antwortzeitziel(e) können
von einem Benutzer, einem Bediener des Systems oder durch ein anderes
Mittel (manuell oder automatisch) gesetzt werden. Das Folgende ist
ein repräsentatives
Beispiel für
die Art und Weise, in der der Nutzungsmodus und der Antwortmodus
verwendet werden können.
-
Beim
Nutzungsmodus hat ein Rechnersystem oftmals einen primären Arbeitskern
mit einem bestimmten Anteil an Arbeiten im Stapelbetrieb, die um
den Primärkern
herum durchgeführt
werden müssen.
Ein häufig
angetroffenes Problem besteht darin, dass die Arbeit im Stapelbetrieb
von der Kernarbeit stark benachteiligt wird, was nicht erwünscht ist.
Daher möchte
man gegebenenfalls sicherstellen, dass die Arbeit im Stapelbetrieb
mindestens 20 % der Ressource zugeteilt bekommt. Ein weiteres Beispiel
sind zwei Abteilungen, die denselben Rechner gemeinsam benutzen
und die Ressource zwischen den beiden Abteilungen zu ungleichen
Teilen zuteilen und diese Zuteilung steuern möchten. Beim Antwortmodus ist
es bei verschiedenen Rechnersystemen (zum Beispiel Transaktionsverarbeitungssystemen)
oftmals wichtig, den Mittelwert und die Abweichung bei den Antwortzeiten
zwischen einem Satz von Job-Klassen zu steuern. In diesem Fall kann
es wichtig sein, dass die "Priorität" eines Jobs in der
Klasse "i" linear mit der Wartezeit
des Jobs auf die Ressource steigt. Die Steigung dieser linearen
Funktion hängt von
der Klasse ab, und mit ihr werden die Antwortzeiten, die jede Klasse
erhält
(entweder absolut oder im Verhältnis
zu den anderen Klassen), gesteuert.
-
Die
Verwendung von Zeitfunktionen vereinheitlicht die Unterstützung von
verschiedenen Abfolgesteuerungszielen im Rahmen eines einzelnen
Abfolgesteuerungsverfahrens. Welche Job-Klasse bei Freiwerden der
Ressource für
die zeitliche Abfolgeplanung ausgewählt wird, wird von der Zeitfunktion, die
in diesem Zeitraum zu jeder Klasse gehört, dynamisch festgelegt. Zeitfunktionen
können
eine beliebige Funktion der "Zeit" ganz allgemein sein,
wobei jedes beliebige Zeitmaß in
Bezug auf die Ressource und auf andere Ressourcen verwendet werden
kann, um die Zeitfunktionswerte (die manchmal auch als "TF-Wert" bezeichnet werden)
zu berechnen. "Zeit" in der in der bevorzugten
Ausführungsform
verwendeten Weise, jedoch nicht auf diese Verwendungsweise beschränkt, wird
auf zweierlei allgemeine Arten gemessen. Zum Beispiel ist Zeit ein
beliebiges Maß für die Nutzung
der Ressource oder einer Gruppe von Ressourcen durch die Klasse
der Anforderer (d.h. der Jobs), wobei die Zeitfunktion in diesem
Fall als im "Nutzungs"-Modus befindlich
gilt, und/oder Zeit ist ein beliebiges Maß für die Wartedauer auf die Ressource
oder auf eine Gruppe von Ressourcen durch die Klasse der Anforderer,
wobei die Zeitfunktion in diesem Fall als im "Antwort"-Modus befindlich gilt. Ohne allgemeine
Gültigkeit
zu verlieren, wird vorzugsweise davon ausgegangen, dass die Job-Klasse "i" unter gleichen Bedingungen gegenüber der Job-Klasse "j" bevorzugt wird, da i < j ist; d.h., die Zeitfunktion
für die
Klasse "i" ergibt einen Wert,
der größer als
die oder gleich der Zeitfunktion für die Klasse "j" ist, wenn beide den gleichen Satz von
Eingabeparametern erhalten. Die Klasse "i" wird
als eine "höhere Klasse" als die Klasse "j" bezeichnet, und umgekehrt ist die Klasse "j" eine "niedrigere Klasse" als die Klasse "i".
-
In
der bevorzugten Ausführungsform
werden Job-Klassen in einer Hierarchie angeordnet. 1 zeigt
einen allgemeinen Fall des hierarchischen Schemas 10. In diesem
Beispiel wird eine ganze Gruppe von Job-Klassen 1 bis K in "N" verschiedene Gruppen (die mit 1 bis
N bezeichnet sind) unterteilt, wobei jede Gruppe absolute Priorität vor den Job-Klassen
in der nächsten
Gruppe in der Hierarchie hat. Folglich kann ein Job, der zu einer
Klasse in der Gruppe 2 gehört,
nur ausgeführt
werden, wenn in dem System keine ausführbaren Jobs von der Gruppe
1 vorhanden sind. Ebenso haben Jobs in der Gruppe 2 absolute Priorität vor Jobs
in der Gruppe 3 und so weiter. In einem repräsentativen System werden Job-Klassen
in der Gruppe mit der höchsten
Priorität,
nämlich
der Gruppe 1, verwendet, um niedrige Systemtätigkeiten, die eine hohe Priorität haben,
wie zum Beispiel Betriebssystemaufgaben, auszuführen. Tasks auf Benutzerebene
(wie zum Beispiel Transaktionsverarbeitungsaufgaben) haben eine
vergleichsweise niedrigere Priorität und könnten daher in die Gruppe 2
(oder eventuell auch in eine Gruppe mit einer noch niedrigeren Priorität) gestellt
werden. Die Tasks mit der niedrigsten Priorität wie zum Beispiel Tasks, die überschüssige Zykluszeit
in Anspruch nehmen (zum Beispiel Systemsicherungsaufgaben oder eine
andere Hintergrundverarbeitung), könnten in die Gruppe mit der
niedrigsten Priorität,
die Gruppe N, verwiesen werden.
-
In
der bevorzugten Ausführungsform
gehören
zu jeder Gruppe eine oder mehrere Job-Klassen. Wie gezeigt ist,
gehören
folglich zur Gruppe 1 die Job-Klassen 1 bis L1,
zur Gruppe 2 gehören
die Job-Klassen (L1 +1) bis (L1 +
L2) und so weiter bis zur Gruppe N, zu der
die Job-Klassen (L1 + L2 +
... LN–1 + 1)
bis (L1 + ... LN)
gehören.
Wie in 1 weiter gezeigt ist, kann eine bestimmte Job-Klasse überdies rekursiv
in Unterklassen mit der gewünschten
Anzahl von Stufen unterteilt werden. Folglich können zur Job-Klasse i (ungeachtet
dessen, oder der Antwort- oder der Nutzungsmodus ausgewählt wird)
die Unterklassen i1 bis 1M1 gehören,
und zu einer bestimmten Unterklasse ij kann
ebenfalls noch eine weitere Gruppe von Unterklassen, 1j1 bis 1jMJ gehören und
so weiter. Auf diese Weise kann jeder Klasseneintrag rekursiv festgelegt
werden. Dies stellt einen wesentlichen Vorteil dar, da eine "feiner" abgestufte Abfolgesteuerung
ermöglicht
wird und so eine größere Vielzahl
an vom Benutzer oder vom System festgelegten Leistungszielen erreicht
werden kann.
-
1 zeigt
auch ein weiteres vorteilhaftes Merkmal, nämlich dass die Zeitfunktionen,
die zu den Job-Klassen in jeder Gruppe in der Hierarchie gehören, entweder "konstant" oder "dynamisch" sein können. Innerhalb
einer jeden Gruppe wird folglich die Reihenfolge, in der Job-Klassen
Zugriff auf die Ressource erhalten, von den zeitbasierten Funktionen festgelegt,
wobei jede zeitbasierte Funktion konstant sein oder sich entsprechend
einem bestimmten Zeitmaß dynamisch
verändern
kann. Wenn konstante zeitbasierte Funktionen verwendet werden, hat
jede Job-Klasse einen Zeitfunktionswert, der sich im Laufe der Zeit
nicht verändert.
Wenn dynamisch veränderliche
zeitbasierte Funktionen verwendet werden, verändert sich der Zeitfunktionswert
einer Job-Klasse im Allgemeinen in Bezug auf ein bestimmtes Zeitmaß. Die Vorteile
dieses Lösungsansatzes
werden nachstehend ausführlich
beschrieben.
-
Außerdem gehört zu jedem
Satz von Klassen oder Unterklassen oder Unter-Unterklassen usw. (je
nach Gegebenheit) eine Bitmaske 12. Jede Maske enthält ein Bit
(dem ein Wert von Q oder 1 zugewiesen wird), das zu einer bestimmten
Klasse, Unterklasse oder Unter-Unterklasse usw. (je nach Gegebenheit)
gehört.
Das Bit gibt einen Hinweis darauf, ob die jeweilige Klasse, Unterklasse
oder Unter-Unterklasse usw. leer ist und während der Verarbeitung folglich übergangen
werden kann. Dadurch werden mehrere der Abfolgesteuerungsroutinen
optimiert, wie nachstehend zu sehen sein wird. Alternativ zu einer
Bitmaske kann eine Gruppe von Zeigern verwendet werden.
-
Obgleich
dies in 1 nicht ausführlich gezeigt ist, wird jedem
Job in einer bestimmten Job-Klasse auch eine Job-Warteschlange zugewiesen, die eine Reihe
von Jobs aus der entsprechenden Klasse verwaltet, welche darauf
warten, die Ressource zugesprochen zu bekommen. Die Warteschlange
kann irgendein geeignetes Datenbankkonstrukt wie zum Beispiel eine
verkettete Liste sein.
-
Die
hier beschriebene Hierarchie von Gruppen, Klassen und Unterklassen
stellt eine sehr leistungsfähige
Struktur dar, um Jobs so zu organisieren, dass sie nach einem Zeitplan
Zugriff auf Ressourcen erhalten, um ihre Leistungsziele zu erfüllen. Klassifizierungen
von Jobs, ihre Leistungsziele und folglich die entsprechende Hierarchie
der Job-Klassen werden von Benutzern oder Systemadministratoren
festgelegt, die die entsprechende Befugnis und Zuständigkeit
hierfür
besitzen. Bei der Abfolgeplanung nach dem Zeitfunktionsverlauf können die
Leistungsziele hierarchisch gegliedert werden, und/oder eine beliebige
Kombination von anteiliger Nutzung und Antwortzeit kann zusätzlich zu
den konstanten Zeitgruppen verwendet werden. Ein ganz bestimmter
Fall der Hierarchie ist in 2 gezeigt.
Es sollte klar sein, dass die Hierarchie von 2 lediglich
Beispielcharakter hat und die Erfindung nicht auf das beziehungsweise
die einzelnen gezeigte(n) Abfolgesteuerungsziel(e) beschränkt ist.
-
In 2 gibt
es drei (3) Gruppen von Job-Klassen, A, B und C. Zumindest zu einem
Teil der Job-Klassen in der Gruppe B (aus Gründen, die offenkundig werden)
gehören
Unterklassen, wie gezeigt ist. Zu Job-Klassen in der Gruppe A gehören "konstante" zeitbasierte Funktionen,
was ein Schema mit festen Prioritäten zur Folge hat, um zwischen
den darin enthaltenen Job-Klassen eine Unterscheidung zu treffen.
Bei konstanten Zeitfunktionen wird die zeitliche Abfolge von Jobs
in der zweiten Klasse innerhalb der Gruppe nur geplant, wenn sich
in der ersten Klasse der Gruppe keine Jobs befinden, die zeitliche
Abfolge von Jobs in der dritten Klasse innerhalb der Gruppe wird
nur geplant, wenn sich sowohl in der ersten als auch in der zweiten
Klasse der Gruppe keine Jobs befinden, und so weiter. In der Gruppe
A der Job-Klassen kann es verschiedene Arten von Tasks geben. Somit
gibt es beispielsweise kurze "System"-Tasks, denen vor
allen anderen Tasks Priorität eingeräumt werden
muss (gegebenenfalls mit unterschiedlichen Prioritäten zwischen
verschiedenen Job-Klassen).
Diese Tasks werden von denjenigen erzeugt, die das System zunächst einmal
erstellen, und folglich sind dies der Definition und dem Aufbau entsprechend "kurze System-Tasks". Darüber hinaus gibt
es Echtzeitbenutzer-Tasks (im Gegensatz zu System-Tasks), die beim
Zugriff auf die Ressource häufig
an nächster
Stelle stehen. Die zeitliche Abfolge dieser Tasks wird oft entsprechend
einem Schema mit festen Prioritäten
geplant, d.h. im Anschluss an die Ausführung von System-Tasks, jedoch
häufig
vor der Ausführung
von anderen Benutzer-Tasks. Die Gruppe A der Job-Klassen kann darüber hinaus
interaktive Benutzer-Tasks enthalten, die als eine geringfügige Nutzung
von Ressourcen zwischen verhältnismäßig langen
Perioden der Inaktivität
definiert sind. Es kann von Vorteil sein, diesen interaktiven Tasks absolute
Priorität
vor anderen Benutzer-Tasks
einzuräumen
(die somit in die Gruppe B der Job-Klassen fallen können, wie
erörtert
werden wird). Das von konstanten Zeitfunktionen vorgesehene Schema
mit festen Prioritäten
kann diese (und andere) Erfordernisse hinsichtlich der Abfolgesteuerung
von verschiedenen Arten von Tasks in Bezug auf Ressourcen eines
Rechners oder eines Rechnersystems unterstützen.
-
Im
Rahmen der Gruppe A der Job-Klassen in 2 gibt es
somit System-Tasks, die eine höhere Priorität als Echtzeit-Tasks haben, welche
wiederum eine höhere
Priorität
als interaktive Tasks haben, wobei sich all diese Tasks in derselben
Gruppe befinden. Das Schema mit festen Prioritäten (mittels der konstanten
Zeitfunktionen) innerhalb der Gruppe dient zur Festlegung der Reihenfolge,
in der die verschiedenen Arten von Tasks innerhalb der Gruppe Zugriff
auf die Ressource erlangen.
-
Eine
sich dynamisch verändernde
zeitbasierte Funktion gehört
vorzugsweise zu jeder Job-Klasse in der zweiten Gruppe B. In diesem
der Veranschaulichung dienenden Beispiel unterliegen die Klassen B.1
bis B.L2 einem Nutzungsmodusziel (40%, 20%,... 5%),
und die einzelnen Klassen B.1, B.2,... unterliegen einem Antwortmodusziel.
Folglich haben die Unterklassen von B.1 ein Antwortmodusziel (10:3:
... 1), und die Unterklassen von B.2 haben ein Antwortmodusziel
(8:4: ... 1). Die einzelnen Parameter eines jeden Ziels (ungeachtet
des Nutzungs- oder Antwortmodus) können natürlich einzeln gewählt und
auf Wunsch dynamisch angepasst werden. Alternativ dazu können diese
Parameter mit einem Standardwert vorab zugewiesen werden. Die Anpassung
der Parameterwerte, die das jeweilige Ziel bilden, kann nach einem
bestimmten Ereignis, nach dem Ablauf einer bestimmten Zeitspanne,
durch die Verwendung einer adaptiven Rückmeldung, die die Gewichtungen dynamisch
anpasst, durch ein wissensbasiertes Expertensystem oder mittels
eines anderen bekannten Verfahrens stattfinden. So kann ein "Ereignis" zum Beispiel zeitbasiert
sein, wie beispielsweise die Ankunft zu einer bestimmten Tageszeit;
alternativ kann das Ereignis lastbasiert sein, wie zum Beispiel
ein Trigger, der ein neues Ziel setzt, wenn ein bestimmter Schwellenwert
der Systemnutzung erreicht wird.
-
Natürlich dient
die Tatsache, dass der Nutzungsmodus auf der Klassenebene und der
Antwortmodus auf der Unterklassenebene realisiert werden, lediglich
der Veranschaulichung. Wie vorstehend erwähnt wurde, wird weder der Nutzungsmodus
noch der Antwortmodus in der gegebenen Art der Ausführung bevorzugt.
Beide sind gleichermaßen
brauchbar und stehen für
eine oder mehrere bestimmte dynamische Zeitfunktionen zur Verfügung. Im
Allgemeinen können
die Zeitfunktionen je Klasse jede beliebige Form haben, die zweckmäßig erscheint.
In der bevorzugten Ausführungsform
ist der absolute Wert einer jeden klassenweisen Zeitfunktion monoton
nichtabnehmend (was bedeutet, dass der Zeitfunktionswert zum Zeitpunkt "t" immer größer als der oder gleich dem
Zeitfunktionswert zum Zeitpunkt t' bei allen Zeitpunkten t' weniger t ist).
Dies bedeutet, dass (unter anderem) die Job-Zuweisung von einer
bestimmten Job-Klasse, die den Zugriff auf die Ressource erhielt, vorzugsweise
auf der Grundlage "wer
zuerst kommt, mahlt zuerst" stattfindet,
da dies wünschenswert
ist, um innerhalb von Job-Klassen und auch jobklassenübergreifend
eine vorhersagbare Leistung zu ermöglichen. Mit Hilfe einer beliebigen
allgemeinen Auswahlfunktion kann dann festgelegt werden, welche Job-Klasse
innerhalb der Gruppe B auf der Grundlage der Zeitfunktionswerte
je Klasse ausgewählt
werden soll. Sobald eine bestimmte Klasse ausgewählt wurde, wird diese Prozedur
der Berechnung von klassenweisen Zeitfunktionswerten und der Auswahl einer
Klasse auf der Grundlage dieser Werte durch die entsprechenden Teile
der Abfolgesteuerungs-Hierarchie rekursiv angewandt.
-
Wie
in 2 ebenfalls gezeigt ist, wird in dem repräsentativen
Beispiel ein anderes Schema mit festen Prioritäten für die Job-Klassen in der dritten
Gruppe C verwendet, indem jeder Klasse eine konstante zeitbasierte
Funktion zugewiesen wird. Der Satz von Klassen C ist (in erster
Linie) für
Hintergrundarbeiten auf Systemebene vorgesehen. Ein nichtleerer
Satz C kann zu starken Benachteiligungen (starvations) und anderen
Systemproblemen führen,
wenn er nicht vorsichtig und korrekt verwendet wird, und folglich
wird die Gruppe C im Allgemeinen entweder deaktiviert (indem ihre
Größe auf 0
gesetzt wird), oder sie wird nur von Tasks verwendet, die von anderen
Tasks in der Gruppe A oder der Gruppe B unterstützt werden. Die Gruppe A und/oder die
Gruppe C können
leere Gruppen sein.
-
2 zeigt
folglich, wie der Ablaufzeitsteuerungsmechanismus die Kombination
aus Nutzungs- und
Antwortmodus innerhalb von verschiedenen Hierarchiestufen oder über verschiedene
Hierarchiestufen hinweg sehr allgemein und flexibel unterstützt. Zum
Beispiel kann ein Benutzer oder das System den Nutzungsmodus oder
den Antwortmodus auswählen.
Bei einer Ausführung
mit nur einer Stufe kann ein Systemwert so gesetzt werden, dass
zwischen dem Nutzungsmodus und dem Antwortmodus hin und her geschaltet
werden kann. Bei einer Ausführung
mit zwei Stufen kann ein System die Nutzung der Ressource unter
Verwendung des Nutzungsmodus (oder des Antwortmodus) planen. Sobald
eine bestimmte Klasse als der nächste
Empfänger
der Ressource ausgewählt
wurde, kann die Auswahl einer bestimmten Unterklasse innerhalb dieser
Klasse auf der Grundlage des Antwortmodus (oder des Nutzungsmodus)
erfolgen. 2 zeigt die mehrstufige Ausführung, bei
der Job-Klassen in der Gruppe B mit Hilfe des Nutzungsmodus zugeordnet
werden und einzelne Unterklassen innerhalb einer Job-Klasse mit Hilfe
des Antwortmodus zugeordnet werden.
-
Ein
Migrationsmechanismus kann jeder Job-Klasse zugeordnet werden. Im
Einzelnen kann ein Job von einer Klasse in eine andere niedrigere Klasse
umgelagert werden, nachdem er einen Satz von Kriterien überschritten
hat, die auf der Nutzung von Ressourcen dieses Jobs beruhen. Wie
weit die Task entfernungsmäßig umgelagert
wird, wird von einer Migrationsrate in Verbindung mit der Job-Klasse angegeben.
Eine Klasse, der ein Job anfangs zugewiesen wird, ist die "Basisklasse" für den Job.
Unter bestimmten Umständen
kann eine Job-Klasse (und/oder ein Job) in der Hierarchie in eine
höhere Klasse
hinaufgerückt
werden. Ein Beispiel hierfür wird
nachstehend dargelegt, wenn das Problem der "Prioritätsumkehr" angegangen wird.
-
Vorzugsweise
werden die Job-Klassen in der Gruppe B nur berücksichtigt, wenn es in der
Gruppe A keine ablaufbereite Arbeit gibt, und die Gruppe C wird
nur berücksichtigt,
wenn es in der Gruppe A und in der Gruppe B keine ablaufbereite
Arbeit gibt. Dieses hierarchische Schema wird zusammen mit dem Migrationsmechanismus
verwendet, der zu jeder Klasse gehört und einen Job nach dem Überschreiten
der mit der Klasse verbundenen Ressourcen-Kriterien in eine niedrigere
Klasse (innerhalb oder außerhalb
ihrer aktuellen Gruppe) herabstuft. In einer der Veranschaulichung
dienenden Ausführungsform tritt
ein Job folglich in die Gruppe B ein, weil seine Basisklasse in
der Gruppe B enthalten ist oder aber weil der Job (schließlich) in
eine der Job-Klassen der Gruppe B umgelagert wurde, nachdem er die
mit den Klassen seiner Gruppe A verbundenen Migrationskriterien überschritten
hatte. In dieser Ausführungsform treten
Jobs in Klassen in der Gruppe A und der Gruppe C ein, weil sich
ihre Basisklassen in der Gruppe A beziehungsweise der Gruppe C befinden. Überdies wird
ein Job vorzugsweise an seine Basisklasse zurückgegeben, nachdem er für einen
längeren
Zeitraum inaktiv geworden ist.
-
Die 3A und 3B sind
vereinfachte Blockschaubilder, die zeigen, wie der Ablaufzeitsteuerungsmechanismus
in einem Rechner oder einem Rechnersystem arbeitet, um eine Ressource
mit Jobs von den Job-Klassen zu versorgen. In diesem Beispiel ist
die Ressource 14 der Prozessor oder ein oder mehrere andere
Verarbeitungselemente des Systems 40. Das Rechnersystem 40 enthält ein Betriebssystem 42,
das im Speicher 44 unterstützt wird. In der Ausführungsform
von 3A ist der Ablaufzeitsteuerungsmechanismus 46 (der
manchmal auch als Zuteiler (dispatcher)) bezeichnet wird, als ein Dienstprogramm
des Betriebssystems realisiert. In der Ausführungsform von 3B ist
die Ablaufzeitsteuerung eine Software-Anwendung, die vom Betriebssystem 42 ausgeführt wird.
In beiden Fällen enthält die Ablaufzeitsteuerung
eine Job-Warteschlange 48, die zu jeder Job-Klasse gehört. Die Grundfunktion
des Ablaufzeitsteuerungsmechanismus besteht darin, Jobs aus den
Job-Warteschlangen abzurufen und sie der Ressource zur Ausführung bereitzustellen.
Wie in der Ausführungsform
in 3B gezeigt ist, kann die Ressource eine Warteschlange 45 enthalten,
die Jobs hält,
die zur Ausführung
durch die Ressource terminiert sind. Der Ablaufzeitsteuerungsmechanismus
ruft Jobs aus den Job-Warteschlangen ab und stellt sie zur Ausführung durch
die Ressource in die Warteschlange. Die Warteschlange ist optional,
in der Ausführungsform
von 3A ist sie zum Beispiel nicht erforderlich.
-
Die
verschiedenen Betriebslogikelemente des Ablaufzeitsteuerungsmechanismus
werden nun in der folgenden bevorzugten Ausführungsform beschrieben. Mit
der Gruppenauswahl-Routine (Group Selection routine) und der Klassenauswahl-Routine (Class
Selection routine) (4 bis 5) wird
die verfügbare
Ressource einem Job von einer entsprechenden Job-Klasse oder Job-Unterklasse
in einer ausgewählten
Gruppe zugeteilt. Nachdem ein Job aus einer bestimmten Klasse auf
diese Weise ausgewählt
worden ist, berechnet die Aktualisierungsroutine (Update routine)
(6) den dynamischen Zeitfunktionswert für die Job-Klasse
in Vorbereitung auf den nächsten
Auswahlzyklus neu. Die Verlaufsaktualisierungs-Routine (History
Update routine) (8) berechnet die Zeitfunktionswerte
und verwaltet die notwendigen Daten, um sicherzustellen, dass alle Job-Klassen
ihr jeweiliges Leistungsziel erreichen (im Gegensatz zu nur einer
Maßnahme
bei einer einzigen Job-Klasse bei der Aktualisierungsroutine). Die Jobeintritts-/-rückgabe-Routine
(Job Enter/Return routine) (7) stellt
einen möglichen
Migrationsmechanismus bereit, um Jobs mit einer Strafe zu belegen,
die Ressourcen über
die vorgesehenen Grenzwerte hinaus in Anspruch nehmen.
-
4 ist
ein Flussdiagramm, das die Gruppenauswahl-Routine zeigt. Dieser
Prozess dient dazu, eine bestimmte Gruppe zur Verarbeitung auszuwählen. Er
beginnt im Schritt 50, indem er die erste nichtleere Klasse
in der Hierarchie findet. Zu diesem Zweck wird die Bitmaske für die Hierarchie
durchsucht, und Job-Klassen, denen "0" Einträge in der Maske
zugeordnet sind, werden im Interesse einer leistungsfähigen Verarbeitung
nicht beachtet. Im Schritt 52 wird ein Test durchgeführt, um
festzustellen, ob eine erste nichtleere Klasse gefunden wurde. Wenn
nicht, wird die Routine im Schritt 54 automatisch beendet.
Wenn das Ergebnis des Tests im Schritt 52 positiv ist,
wird die Routine im Schritt 56 fortgesetzt, um zu prüfen, ob
die Job-Klasse zu einer Gruppe mit dynamischen Zeitfunktionen gehört. Wenn
nicht, gehört
die Job-Klasse zu einer Gruppe mit konstanten Zeitfunktionen. Im
letzteren Fall wird die Routine mit dem Schritt 58 fortgesetzt,
um einen Job aus der Klasse auszuwählen. Dabei handelt es sich
vorzugsweise um den Job in der Klasse, der am längsten auf die Nutzung der
Ressource gewartet hat. Anschließend wird die Routine beendet.
Wenn das Ergebnis des Tests im Schritt 56 positiv ist,
wird die Routine im Schritt 60 fortgesetzt, um eine Klassenauswahl-Routine aufzurufen.
-
Die
Klassenauswahl-Routine ist in dem Flussdiagramm von 5 gezeigt.
Diese Routine wird rekursiv auf die Hierarchie angewendet, wie es für die dynamischen
Zeitfunktionsgruppen erforderlich ist. Da sich die Zeitfunktionswerte
für jede Job-Klasse oder Job-Unterklasse
im Laufe der Zeit und bei unterschiedlichen anteiligen Verhältnissen ändern, vergleicht
die Klassenauswahl-Routine alle Zeitfunktionswerte von allen nichtleeren
Klassen in einer Gruppe, bevor sie die Auswahl trifft. Sie beginnt im
Schritt 62, indem sie temporäre Variablen auf einen Anfangswert
setzt: "save_TF_value" (auf den Wert TF(I)), "save_class_index" (auf den Wert I)
und "current_class_index" (auf den Wert I).
Im Schritt 64 wird current_class_index erhöht. Die
Routine wird dann im Schritt 66 fortgesetzt, um festzustellen,
ob alle Klassen geprüft
worden sind. Wenn nicht, wird im Schritt 68 ein Test durchgeführt, um
festzustellen, ob die Klasse für
current_class_index leer ist (was, wie vorstehend erwähnt wurde,
mit Hilfe der Bitmaske vorgenommen werden kann). Wenn das Ergebnis des
im Schritt 68 durchgeführten
Tests positiv ist, kehrt die Routine zum Schritt 64 zurück und erhöht current_class_index.
Wenn das Ergebnis des im Schritt 68 durchgeführten Tests
jedoch negativ ist, wird im Schritt 70 ein Test durchgeführt, um
festzustellen, ob der Wert von TF[current_class_index] geringer
als der Wert von save_TF_value ist. Wenn das Ergebnis des im Schritt 70 durchgeführten Tests
negativ ist, kehrt die Routine zum Schritt 64 zurück, und current_class_index
wird erhöht.
Wenn das Ergebnis des im Schritt 70 durchgeführten Tests
jedoch positiv ist, wird die Routine im Schritt 72 fortgesetzt,
in dem sie save_TF_value = TF[current_class_index] und save_class_index
= current_class_index setzt und anschließend zum Schritt 64 zurückkehrt.
-
Wenn
das Ergebnis des im Schritt 66 durchgeführten Tests alternativ dazu
positiv ist, was anzeigt, dass alle Klassen geprüft worden sind, verzweigt die
Routine zum Schritt 74, um einen Job aus der Job-Klasse
von save_class_index auszuwählen. Im
Schritt 76 wird dann ein Test durchgeführt, um festzustellen, ob die
ausgewählte
Job-Klasse Antwortmoduszielen zugeordnet ist. Wenn nicht, wird die Routine
im Schritt 78 automatisch beendet. Wenn die Job-Klasse
jedoch dem Antwortmodus zugeordnet ist, wird im Schritt 80 eine
Klassenaktualisierungsroutine aufgerufen.
-
Die
Klassenaktualisierungsroutine ist in 6 gezeigt.
Diese Routine bereitet einen nächsten Job
in der Klasse vor, der während
eines nächsten Wiederholungslaufs
ausgewählt werden
soll. In Verbindung mit dem Nutzungsmodus wird der Schritt 80 erreicht,
nachdem die Ressourcennutzung (von dem Job, dessen Ausführung gerade
beendet wurde) zu einer Gesamtnutzung für den Job hinzugefügt worden
ist. Wenden wir uns nun dem Flussdiagramm zu, in dem die Routine
im Schritt 82 beginnt, indem sie prüft, ob sich die betreffende
Klasse im Nutzungsmodus befindet. Wenn ja, wird die Routine im Schritt 84 fortgesetzt,
um die Gesamtnutzung um die Ressourcennutzung durch die letzte Klasse
i zu aktualisieren und um TF[i] mittels der folgenden Gleichung
(1) auf einen neuen Wert zu setzen:
Zeitfunktionswert = Funktion
(Gesamtnutzung, Gewichtungsfaktor),
wobei der Gewichtungsfaktor
für die
Job-Klasse ein Parameterwert bei dem jeweiligen Nutzungszeitziel ist.
Die vorstehende Funktion stellt sicher, dass jede Job-Klasse ihren
entsprechenden Anteil an der Ressourcennutzung erhält, während die
kumulierten Nutzungsanteile mit jeweils unterschiedlicher Geschwindigkeit
zunehmen. Nach dem Schritt 84 endet die Routine. Wenn das
Ergebnis des Tests im Schritt 82 jedoch negativ ist, wird
die Routine im Schritt 88 fortgesetzt, um TF[I] mittels
der folgenden Gleichung (2) für
den nächsten
Job in der Ausführungswarteschlange
für die
Klasse i zu setzen:
Zeitfunktionswert = Funktion (Wartezeit,
Gewichtungsfaktor),
wobei die Wartezeit angibt, wie lange die
Job-Klasse auf die Ressource gewartet hat, und der Gewichtungsfaktor
für die
Job-Klasse ein Parameter
ist, der vom Antwortzeitziel bestimmt wird. Nach dem Schritt 88 wird
die Routine automatisch beendet.
-
7 zeigt
eine Jobeintritts-/-rückgaberoutine,
mit der ein bestimmter Job anfangs oder im Anschluss an seine Ausführung durch
die Ressource in eine Job-Warteschlange gestellt wird. Die Routine beginnt
im Schritt 90, um festzustellen, ob der Job von class_index über einen
längeren
als den von einem vorher festgelegten Inaktivitätsgrenzwert (idle_limit) vorgegebenen
Zeitraum inaktiv war. Wenn ja, wird class_index im Schritt 92 gleich
base_class gesetzt. Anschließend
wird der Job im Schritt 94 in die Job-Warteschlange von
class_index gestellt, und die Routine wird automatisch beendet.
Wenn das Ergebnis des Tests im Schritt 90 negativ ist,
wird die Routine fortgesetzt, indem sie im Schritt 96 eine
Prüfung
durchführt,
um festzustellen, ob die Gesamtressourcennutzung des Jobs einen
für Jobs
in der Klasse gesetzten Grenzwert überschreitet. Wenn nicht, verzweigt
die Routine zum Schritt 94. Wenn das Ergebnis des Tests
im Schritt 96 jedoch positiv ist, wird die Routine im Schritt 98 fortgesetzt
und setzt class_index gleich der Zielmigrationsklasse. Anschließend wird
die Routine mit dem Schritt 94 fortgesetzt, wie zuvor beschrieben
wurde. Die Schritte 92 und 98 führen den
Job-Wechsel folglich
hierarchieübergreifend
durch.
-
8 zeigt
eine Verlaufsaktualisierungs-Routine, die die Zeitfunktionswerte
für jede Job-Klasse,
die eine dynamische Zeitfunktion hat, neu berechnet. Diese Routine
beginnt im Schritt 100. Im Schritt 102 wird ein
Test durchgeführt,
um festzustellen, ob die Klasse i dem Nutzungsmodus zugeordnet ist.
Wenn ja, wird die Routine im Schritt 104 fortgesetzt, um
(bei Bedarf) eine Alterungsfunktion auf die Gesamtnutzung für die Klasse
i anzuwenden. Anschließend
wird die Routine automatisch beendet. Ein Beispiel für das Alterungsschema
ist die Multiplikation von TF[i] mit einer Konstanten (kleiner als
1). Die Alterungsfunktion bietet mehrere Vorteile. Wenn eine Klasse
von Jobs die Ressource eine Zeit lang (zum Beispiel die letzten
24 Stunden) nicht verwendet hat, könnte sie die Ressource völlig allein
für sich in
Anspruch nehmen, um die "verlorene" Zeit wettzumachen.
Die Alterungsfunktion verhindert eine solche bevorzugte Nutzung.
-
Wenn
das Ergebnis des Tests im Schritt 102 negativ ist, tritt
als zweite Möglichkeit
der Antwortmodus in Kraft. Dann wird die Routine im Schritt 106 fortgesetzt,
in dem sie TF[i] mittels der Gleichung (2), die vorstehend beschrieben
wurde, aktualisiert, und anschließend wird die Routine automatisch
beendet. Am Ende dieser Routine lassen alle Job-Klassen im Antwortmodus
ihre Zeitfunktionswerte in Bezug auf einen neuen Abfolgeplanungszeitraum
neu berechnen (d.h. mit einer neuen Wartezeit). Die Verlaufsaktualisierungs-Routine
kann in jedem Auswahlzyklus verwendet werden. Diese Routine wird
jedoch in einem festen Zeitintervall verwendet, das vom Benutzer/System
festgelegt werden kann. Aus Gründen der
Leistungsfähigkeit
wird der letztere Ansatz bevorzugt.
-
Es
sollte klar sein, dass die Gleichung (1) somit ausgeführt wird,
wenn die Ablaufzeitsteuerung im Nutzungsmodus arbeitet (um die Zuteilung
entsprechend einem Nutzungszeitziel vorzunehmen), und dass die Gleichung
(2) ausgeführt
wird, wenn die Ablaufzeitsteuerung im Antwortmodus arbeitet (um
die Zuteilung entsprechend Antwortziel vorzunehmen). Auf einer bestimmten
Ebene (ungeachtet dessen, ob Klassen-, Unterklassen-, Unter-Unterklassenebene usw.)
wird vorzugsweise nur eine Betriebsart (entweder der Antwortmodus
oder der Nutzungsmodus) ausgeführt.
Im Nutzungsmodus wird der Zeitfunktionswert für jede Klasse vorzugsweise
von der Gesamtnutzung durch alle Jobs in der Klasse bestimmt. Im
Antwortmodus wird der Zeitfunktionswert vorzugsweise von der Wartezeit
des ältesten
Jobs in der Klasse bestimmt. Es sei angemerkt, dass sich die Verwendung
des "ältesten" Jobs direkt aus
der Verwendung von monoton nichtabnehmenden Zeitfunktionen im Antwortmodus
ergibt. Es ist jedoch auch möglich,
keine nichtabnehmenden Zeitfunktionen zu verwenden, wobei der Wert
der Zeitfunktion für
jede Klasse in diesem Fall auf dem höchsten Zeitfunktionswert beruhen
könnte,
nachdem alle Jobs in der Klasse geprüft worden sind.
-
Es
dürfte
klar sein, dass alle Zeitfunktionswerte im Nutzungsmodus positiv
sind und sich zeitlich "vorwärts" bewegen. Der Ablaufzeitsteuerungsmechanismus
hält folglich
nach den "kleinsten" Werten Ausschau,
um das vorgegebene Nutzungsziel zu erfüllen. Jedes Mal, wenn die Ressource
verwendet wird, wird die Job-Klasse damit "belastet", und die Jobs bewegen sich auf der
vorgegebenen Kurve mit den Zeitfunktionswerten weiter nach vorn.
Im Antwortmodus nehmen die Zeitfunktionswerte mit der Zeit zu, und
die Ablaufzeitsteuerung beruht üblicherweise
auf der Auswahl von den "höchsten" werten (d.h. den
Jobs mit dem jeweils höchsten
Zeitfunktionswert). Im Interesse einer einheitlichen methodischen
Vorgehensweise verarbeitet die vorliegende Erfindung die Kurve mit
den Zeitfunktionswerten im Antwortmodus mit einer "negativen" Gewichtung (wie nachstehend
zu sehen sein wird) in der Weise, dass praktisch die "kleinsten" Werte ausgewählt werden, wie
es auch im Nutzungsmodus der Fall ist. Dies stellt ungeachtet dessen,
ob der Antwortmodus oder der Nutzungsmodus verwendet wird, ein "einheitliches" Verfahren und Verarbeitungsschema
dar.
-
Im
Nutzungsmodus hält
die Ablaufzeitsteuerung folglich nach dem kleinsten Wert Ausschau,
der die Klasse kennzeichnet, die im Verhältnis zu den anderen Klassen
zur Zeit am weitesten von ihrem anteiligen Nutzungsziel entfernt
ist. Im Antwortmodus hält die
Ablaufzeitsteuerung nach dem größten Zeitfunktionswert
unter allen Jobs in der Gruppe Ausschau; bei nichtsteigenden Funktionen
vereinfacht sich diese Vorgehensweise allerdings auf die Feststellung des
größten Zeitfunktionswerts
unter den ältesten Jobs
in der Klasse.
-
Das
Folgende beschreibt repräsentative
Beispiele für
die Ablaufzeitsteuerung gemäß Zeitfunktionen
im Nutzungsmodus und Zeitfunktionen im Antwortmodus, um diese Konzepte
zu veranschaulichen. Betrachten wir den Fall, in dem die zeitliche
Abfolge von einem Paar von Job-Klassen A:B (oder Unterklassen oder
Unter-Unterklassen usw.) entsprechend einem Nutzungsmodusziel von
(80:20) geplant wird, d.h., die Klasse A soll 80 % der Ressource und
die Klasse B soll 20 % der Ressource für die Dauer eines bestimmtes
Intervalls erhalten, wenn beide Jobs vorhanden sind. Bei diesem
Ziel ist eine repräsentative "Gewichtung" für die Zeitfunktion
der Klasse A im Nutzungsmodus (die vorstehend mit Bezug auf die
Gleichung (1) beschrieben wurde) (1/8) oder (1/4), was einer repräsentativen "Gewichtung" der Zeitfunktion
der Klasse B im Nutzungsmodus von (1/2) beziehungsweise (1) entspricht.
Zum Zweck dieses einfachen Beispiels sei angenommen, dass die Gesamtnutzung
bei beiden Klassen anfangs 0 beträgt, die Job-Warteschlange für beide Klassen viele Jobs
enthält
und die Verarbeitungsanforderung aller Jobs 1 Einheit beträgt. Der
bevorzugten Funktionsweise der Erfindung entsprechend wird die Job-Klasse
mit dem "kleinsten" Zeitfunktionswert
immer ausgewählt,
wenn eine Entscheidung bezüglich der
Ablaufzeitsteuerung getroffen wird. Wenn die Ressource verfügbar wird,
wählt die
Ablaufzeitsteuerung folglich den ersten Job aus der Klasse A zur
Verarbeitung aus, da höhere
Klassen vorzugsweise gewählt
werden, um zwischen Verbindungen (ties) eine Prioritätsentscheidung
zu treffen. Nach der Abarbeitung dieses Jobs wird der Zeitfunktionswert
für die Klasse
A auf 1/4 (d.h. 0 plus 1 Einheit multipliziert mit 1/4) aktualisiert.
Die nächste
Entscheidung hinsichtlich der Abfolgesteuerung wählt den ersten Job aus der
Klasse B zur Verarbeitung aus, da der Zeitfunktionswert der Klasse
B "0" beträgt. Nach
der Abarbeitung dieses Jobs wird der Zeitfunktionswert für die Klasse
B auf 1 (d.h. 0 plus 1 Einheit multipliziert mit 1) aktualisiert.
In dieser Weise fortfahrend wählen
die nächsten
vier Abfolgesteuerungs-Entscheidungen
einen Job aus der Klasse A aus (da Verbindungen von der Klasse A
gewonnen werden), was einen Zeitfunktionswert von 1,25 (0,25 plus
4 Einheiten multipliziert mit 1/4) für die Klasse A ergibt. Die
nächste
Abfolgesteuerungs-Entscheidung wählt
einen Job aus der Klasse B aus, was einen Zeitfunktionswert von
2 (1 plus 1 Einheit multipliziert mit 1) ergibt. Dies wird fortgesetzt,
solange es in der Job-Warteschlange
von beiden Klassen Jobs gibt, was von Aktualisierungen des Verlaufs
abhängt.
Diese Betriebsweise ist in 9B grafisch
dargestellt.
-
Für ein repräsentatives
Beispiel der Ablaufzeitsteuerung gemäß Zeitfunktionen im Antwortmodus
betrachten wir den Fall, in dem die zeitliche Abfolge von drei Job-Klassen
A:B:C (oder Unterklassen oder Unter-Unterklassen usw.) entsprechend
klassenweisen Zeitfunktionen geplant wird, die linear mit der Zeitspanne
schwanken, die ein Job in der Klasse mit dem Warten auf die Ressource
auf Grund eines Antwortmodusziels von (4:2:1) verbringt, d.h., die Zeitfunktion
je Klasse für
einen Job ist einfach die "Gewichtung" für seine
Klasse, multipliziert mit der Zeitspanne, die er wartend in der
Job-Warteschlange verbracht
hat. Zum Zweck dieses einfachen Beispiels sei angenommen, dass jede
Job-Klasse einen einzigen Job hat, der unmittelbar nach dem Empfang
von 1 Verarbeitungseinheit in seine Job-Warteschlange zurückkehrt,
und dass die Wartezeit aller Jobs anfangs "0" beträgt. Um dem
Minimum-Operator als Auswahlfunktion zu entsprechen, betrachten
wir die Gewichtungen (–4:–2:–1) für die Klassen
A:B:C zum Zweck dieses einfachen Beispiels. Da die Zeitfunktionswerte
anfangs alle "0" betragen (aufgrund
von 0 Wartezeiten), wählt
die Ablaufzeitsteuerung zuerst den Job aus der Klasse A zur Verarbeitung
aus, da höhere
Klassen in der bevorzugten Ausführungsform vorzugsweise
im Falle von Verbindungen gewählt werden.
Nach der Abarbeitung zum Zeitpunkt 1 betragen die Zeitfunktionswerte
für die
Klasse A, die Klasse B und die Klasse C "0", "–2" beziehungsweise "–1". Da der Zeitfunktionswert
der Klasse 2 nun der kleinste Wert ist, hat dies die Auswahl des
Jobs der Klasse B zur Folge, und nach dessen Abarbeitung zum Zeitpunkt
2 betragen die Zeitfunktionswerte für die Klasse A, die Klasse
B und die Klasse C "–4", "0" beziehungsweise "–2". Der Job in der
Klasse A wird dann ausgewählt,
und nach seiner Abarbeitung zum Zeitpunkt 3 betragen die Zeitfunktionswerte
je Klasse "0", "–2", "–3". Dies hat zur Folge,
dass der Job in der Klasse 3 als Nächstes ausgewählt wird,
was bei seiner Abarbeitung zum Zeitpunkt 4 Zeitfunktionswerte von "–4", "–4" und "0" ergibt. Bei diesem einfachen Beispiel
wird der Betrieb der Ablaufzeitsteuerung in dieser Weise fortgesetzt.
In 9A ist diese Betriebsweise grafisch dargestellt.
-
In
der bevorzugten Ausführungsform
können die
anteiligen Zeitfunktionswerte (nämlich
die Parameter des Nutzungs- oder des Antwortmodusziels) für die Job-Klassen
angepasst werden. So wird zum Beispiel der Vektor von Werten mit
Hilfe eines adaptiven Rückmeldemechanismus
angepasst, der die Werte an sich verändernde Bedingungen "anpasst". Ein "Standard"-Satz von Werten
würde dann
ausgeführt
werden, wenn die gesamte Systemauslastung einen bestimmten Wert
(z.B. 100 %) erreicht hätte; wenn
die gesamte Systemauslastung auf einen zweiten Wert (z.B. 75 %)
verringert würde,
würde ein
neuer Satz von Werten ausgeführt
werden und so weiter. Alternativ dazu können die Werte für die Job-Klassen geändert werden,
nachdem ein bestimmtes Ereignis stattgefunden hat oder eine bestimmte
Uhrzeit erreicht worden ist, oder diese Werte können optimiert oder in anderer
Weise entsprechend einer Wissensbasis unter Verwendung eines Expertensystems
angepasst werden. Noch eine weitere Alternative besteht in der Änderung
der Werte bei einer bestimmten Job-Mischung.
-
Wie
zuvor erwähnt
wurde, führt
die bevorzugte Ausführungsform
neben der Anpassung der Zeitfunktionen (oder der Zeitfunktionsparameter) noch
andere adaptive Rückmeldemechanismen
aus, wenn sich die Auslastung, die Job-Mischung usw. ändert. Somit stellt die Umlagerung
von Jobs aus einer Klasse in eine andere Klasse in der Hierarchie,
die stattfindet, wenn die Ressourcennutzung vom Systemadministrator
und/oder vom Benutzer festgelegte Grenzwerte überschreitet, einen solchen
Mechanismus dar. Bei einem anderen solchen Rückmeldemechanismus erfolgt
die Rückkehr
in die Basisklasse des Jobs, nachdem die Ressource eine bestimmte vorher
festgelegte Zeitspanne nicht in Anspruch genommen worden ist. Ein
weiterer adaptiver Rückmeldemechanismus
geht das Problem der "Prioritätsumkehr" an.
-
Unter
Prioritätsumkehr
versteht man im Einzelnen die Situation, in der ein Anforderer mit
einem hohen Zeitfunktionswert daran gehindert wird, die aktuelle
Ressource zu verwenden, da er auch eine andere Ressource angefordert
hat, um die heftig konkurriert wird und die sich im Besitz eines
Anforderers mit einem niedrigen Zeitfunktionswert befindet. Dies kann
ein ernstes Problem darstellen, da der Anforderer mit dem niedrigen
Wert den Anforderer mit dem hohen Zeitfunktionswert daran hindert,
sein Leistungsziel zu erreichen. Dieses Problem wird dadurch gelöst, dass
der Anforderer mit dem niedrigen Zeitfunktionswert so lange in die
Klasse des hohen Zeitfunktionswerts gestellt werden darf, wie er
die andere Ressource, um die heftig konkurriert wird, besitzt, und
anschließend
wird der Anforderer mit dem niedrigen Zeitfunktionswert an seine
Ursprungs-Jobklasse zurückgegeben.
Dies ist ein adaptiver Rückmeldemechanismus.
-
Als
ein konkretes Beispiel für
diesen Mechanismus sei angenommen, dass es zwei Ressourcen, eine
CPU und eine logische Sperre, gibt. Die Verwendung der CPU wird
mit Hilfe des Zeitfunktionsschemas geplant. Der Job A befindet sich
in einer Job-Klasse, deren anteilige Verwendung höher als die
der Klasse des Jobs B ist. Es sei angenommen, dass der Job B im
Besitz der Sperre ist, sein Zeitfunktionswert im Vergleich zu vielen
anderen Jobs in dem System aber niedrig ist. Der Job A hat eine
Zeitfunktion, die ihn dazu berechtigt, die CPU viel früher in Anspruch
zu nehmen als der Job B, jedoch wird der Job A aufgrund der Sperre,
die sich im Besitz des Jobs B befindet, an der Nutzung der CPU gehindert. In
der bevorzugten Ausführungsform
erbt der Job B die Zeitfunktion der Klasse des Jobs A, damit er
auf die CPU zugreifen kann, bis der Job B die Sperre freigibt und
sie für
den Job A zur Verfügung
stellt. Der Job B wird dann an die Job-Klasse zurückgegeben, in
der er sich befand, bevor er in die höhere Klasse gestellt wurde.
Bekannte Abfolgesteuerungsmechanismen sind nicht in der Lage, das
Problem der Prioritätsumkehr
in dieser einzigartigen Weise zu lösen.
-
Die
hier beschriebene Ablaufzeitsteuerung wird vorzugsweise auf einem
Rechner wie zum Beispiel einem Rechner vom Typ IBM RISC System/6000,
auf dem das Betriebssystem AIX läuft, oder
auf einem Intel-basierten Prozessorsystem, auf dem das Betriebssystem
Windows NT oder OS/2 läuft,
ausgeführt,
jedoch könnte
sie auch auf vielen anderen Formen von Einheiten (z.B. einer Datenübertragungsverbindung,
einer Prozesssteuereinheit usw.) ausgeführt werden.
-
Eine
der bevorzugten Ausführungsmöglichkeiten
der Erfindung ist ein Betriebssystem-Dienstprogramm. In diesem Fall
umfasst das Dienstprogramm einen Satz von Befehlen (Programmcode)
in einem Code-Modul, der sich während
des Betriebs üblicherweise
im Direktzugriffspeicher des Rechners befindet, jedoch in einem
anderen Speicher abgelegt wird, bis er von dem Rechner benötigt wird,
zum Beispiel in einem Festplattenlaufwerk oder in einem auswechselbaren
Speicher wie zum Beispiel einer optischen Platte (zur letztendlichen
Verwendung in einem CD-ROM)
oder einer Diskette (zur letztendlichen Verwendung in einem Diskettenlaufwerk),
oder über
das Internet oder ein anderes Rechnernetzwerk heruntergeladen wird.
-
Zwar
wurde der Begriff "Ressource" hier in Bezug auf
einen Prozessor verwendet, doch sollte klar sein, dass dieser Begriff
allgemein zu verstehen ist, so dass er jede physische oder logische
Einheit oder Komponente (ungeachtet dessen, ob es sich dabei um
Hardware oder Software oder um eine Kombination aus beidem handelt)
eines Rechners oder eines anderen Systems abdeckt, das über eine begrenzte
Kapazität
verfügt,
die in einem bestimmten Maß in
Anspruch genommen werden kann. Folglich kann sich eine "Ressource" in der hier verwendeten Weise
zum Beispiel auf einen Prozessor (der mit n Zyklen pro Sekunde arbeitet),
einen Speicher (dessen Speicherkapazität mit n Bits pro Sekunde in
Anspruch genommen werden kann), eine Datenübertragungsverbindung (deren
Kapazität
in Abhängigkeit von
der Größe und der
Zeit zugewiesen werden kann), eine Datenbank, eine Sperre usw. beziehen. Darüber hinaus
sollte auch der Begriff "Job" allgemein verstanden
werden, so dass er eine Aufgabe (Task), einen Prozess, eine Ausführungseinheit
innerhalb eines Prozesses (Thread), einen Anforderer oder ganz allgemein
jede "Einheit" oder jede Arbeit abdeckt,
die eine Ressource in Anspruch nimmt.
-
Der
hier beschriebene Lösungsansatz
bietet wesentliche Vorteile gegenüber dem Stand der Technik.
So stellen bekannte Ressourcen-Planungsmechanismen keine ganzheitliche
Struktur bereit, bei der eine Abfolgeplanung im Nutzungsmodus und auch
im Antwortmodus realisiert werden kann. Selbst in Bezug auf die
jeweiligen Modi sehen diese bekannten Schemata nicht den Steuerungsgrad
vor, den der vorstehend beschriebene dynamische zeitbasierte funktionale
Lösungsansatz
bietet. Außerdem
nutzt der hier beschriebene Lösungsansatz
vorteilhaft das Konzept einer "Hierarchie" aus Job-Klassen,
bei der Job-Klassen auf einer Stufe physisch in Gruppen mit absoluter
Priorität
gegenüber
der jeweils anderen Gruppe unterteilt werden und einzelne Klassen
auf einer anderen Stufe logisch in eine rekursive Gruppe von Unterklassen
unterteilt werden. Ebenso können
Unterklassen logisch noch feiner unterteilt werden. Wie vorstehend
erwähnt
wurde, können
adaptive Rückmeldemechanismen
verwendet werden, um Zeitfunktionswerte auf- und absteigend in der
Hierarchie dynamisch zu ändern.
Aufgrund dieser Funktionen kann die hier beschriebene Abfolgesteuerungsmethodik
bekannte Probleme bei der Ablaufzeitsteuerung im Rahmen einer neuen
Struktur angehen und lösen.
Ein solches Problem ist zum Beispiel als "Prioritätsumkehr" bekannt.
-
Zusammenfassend
kann gesagt werden, dass sowohl die anteilige Ressourcennutzung
(Nutzungsmodus) als auch die anteilige Antwortzeit der Ressourcen
(Antwortmodus) innerhalb einer einzigen Struktur unterstützt werden
können.
Der Ablaufzeitsteuerungsmechanismus ermöglicht auf vorteilhafte Weise
eine anteilige Ressourcen-Antwortzeit innerhalb von Kategorien einer
anteiligen Ressourcennutzung oder eine anteilige Ressourcennutzung innerhalb
von Kategorien einer anteiligen Ressourcen-Antwortzeit. Im Fall
des Nutzungsmodus beispielsweise wird somit mehreren Arbeitskategorien eine
Ressourcennutzungsdauer zugebilligt, deren Anteil vom Benutzer oder
vom System bestimmt wird, wie zum Beispiel verschiedene Prozentsätze, die
in der Summe 100 % betragen. Zyklen, auf die eine Kategorie ein
Recht hat, die aber nicht genutzt werden, werden im Verhältnis zu
dem jeweiligen vom Benutzer angegebenen Anteil zugewiesen. Im Fall
des Antwortmodus sind für
mehrere Arbeitskategorien Ressourcen-Antwortverzögerungen vorgesehen, um eine
allgemeine Zielfunktion zu erreichen, die vom Benutzer oder vom
System festgelegt wird, wie zum Beispiel die Minimierung einer gewichteten
Summe einer Funktion der Antwortzeiten je Klasse oder das Erreichen
von mittleren Antwortverzögerungen
in einem vorher festgelegten Verhältnis. Zyklen, auf die eine
Kategorie ein Recht hat, die aber nicht genutzt werden, werden im
Verhältnis
zu dem jeweiligen vom Benutzer angegebenen Anteil zugewiesen. Ein
solcher Ablaufzeitsteuerungsmechanismus macht es möglich, die
Zuteilung von Ressourcen in einer allgemeinen, flexiblen und adaptiven
Weise wirksam zu steuern.
-
Überdies
kommen in der bevorzugten Ausführungsform
verschiedene Mechanismen zur Anwendung, um die Zeitfunktionen je
Klasse als Reaktion auf Änderungen
bei der Systemauslastung dynamisch anzupassen, so dass die gewünschten
vom Benutzer oder vom System festgelegten Ziele ständig erreicht
werden können.
Ebenso werden während
verschiedenen Zeiträumen
des Systembetriebs verschiedene Reihen von Zeitfunktionen verwendet, um
im Laufe der entsprechenden Zeitintervalle die gewünschten
Ziele bei der Ablaufzeitsteuerung zu erreichen.