-
Die
Erfindung betrifft ein Thread-Scheduling-Verfahren, und eine Einrichtung
zur Verwendung bei einem Thread-Scheduling-Verfahren.
-
Herkömmliche
digitale Rechenschaltkreise (z.B. entsprechende, auf einem Mikrochip
angeordnete Mikrocontroller- bzw. Mikroprozessor-Systeme) weisen
eine oder mehrere (zentrale) Steuer- bzw. Recheneinheiten auf (Central
Processing Units (CPUs), bzw. CPU „Cores").
-
Die
CPU oder die CPUs sind – über einen System-Bus
(und ggf. ein oder mehrere weitere Bus-Systeme) – mit einer oder mehreren (externen oder
internen) Speicher-Einrichtungen verbunden, z.B. einer Programm-
und einer Datenspeichereinrichtung („Programmspeicher", und „Datenspeicher").
-
Der „Programmspeicher" enthält insbesondere
die Folge der von dem bzw. den CPU Cores abzuarbeitenden Befehle,
also das Programm (und ggf. zusätzlich
entsprechende – von
dem bzw. den CPU Cores zu verwendende – Daten-Konstanten).
-
Der
Programmspeicher kann z.B. von einem EPROM (Erasable PROM bzw. Löschbaren
Festwertspeicher) oder EEPROM (Electrically Erasable PROM bzw. Elektrisch
Löschbarer
Festwertspeicher) gebildet werden, insbesondere einem Flash-EEPROM-Bauelement.
-
Dadurch
kann erreicht werden, dass das Programm auch bei unterbrochener
Stromzufuhr auf der entsprechenden Speicher-Einrichtungen gespeichert bleibt.
-
Für häufig zu ändernde
Programme können – alternativ – z.B. auch
RAMs (RAM = Random Access Memory bzw. Schreib-Lese-Speicher), insbesondere
DRAMs als Programmspeicher verwendet werden, die von einem externen
Massenspeicher geladen werden können.
-
Im
o.g. „Datenspeicher" können z.B.
die – insbesondere
von dem bzw. den CPU Cores beim Abarbeiten des Programms ggf. abzuändernden – Variablen
gespeichert sein.
-
Der
Datenspeicher kann z.B. von einem oder mehreren RAM-Bauelementen, insbesondere
z.B. einem entsprechenden DRAM-Bauelement
(DRAM = Dynamic Random Access Memory), oder SRAM-Bauelement (SRAM = Static Random Access Memory)
gebildet werden.
-
Ein – durch
den CPU Core abzuarbeitendes – Software-Programm
(bzw. mehrere derartige Programme) kann in eine Vielzahl entsprechender
Software Tasks (Threads) unterteilt sein.
-
Dies
hat z.B. den Vorteil, dass – insbesondere
z.B. bei sog. Multithreaded (MT) Mikrocontroller- bzw. Mikroprozessor-Systemen – parallel
jeweils mehrere, verschiedenene Tasks gleichzeitig in ein- und denselben
CPU Core geladen, und dort abgearbeitet werden können.
-
Mit
Hilfe von Multithreaded (MT) Mikrocontroller- bzw. Mikroprozessor-Systemen
können
bestimmte Resourcen – insbesondere
z.B. die Execution Pipeline (Processing Pipeline) – effizienter
genutzt werden.
-
Beispielsweise
können
Takt-Zeiten, in denen es bei einem bestimmten, in den CPU Core geladenen
Thread aus bestimmten Gründen
zu einer Verzögerung
kommt, zur Bearbeitung eines weiteren – parallel in den CPU Core
geladenen – Threads
verwendet werden.
-
Zum
Speichern des Zustands bzw. „Kontexts" von – ggf. mehreren – in den
CPU Core geladenen Threads sind bei einem Multithreaded (MT) Mikrocontroller-
bzw. Mikroprozessor-System
Elemente wie z.B. Programm-Zähler
(PC bzw. Program Counter), Befehls-Zustands-Register (Execution
Status Register), Register File, etc., etc. ggf. mehrfach vorhanden.
-
Dadurch
können
mehrere, verschiedene Threads gleichzeitig in ein- und demselben
CPU Core gehalten, und kann zwischen den Threads entsprechend hin-
und hergeschaltet werden.
-
Üblicherweise
wird nur ein kleiner Teil der jeweils auszuführenden Threads simultan in
den CPU Core geladen; die übrigen,
auszuführenden
Threads werden – bis
sie in den CPU Core geladen werden – ausserhalb des CPU Cores
zwischengespeichert.
-
Das
Scheduling der Threads findet somit in zwei Stufen statt: Bei einer
ersten Scheduling-Stufe wird entschieden, wann welche zur Abarbeitung
anstehende (ausserhalb des CPU Cores zwischengespeicherte) Threads
in den CPU Core geladen werden („Off-Core-Thread-Scheduling" bzw. „Thread-Scheduling"). Bei einer zweiten,
nachgeordneten Stufe wird entschieden, wann welcher der in den CPU
Core geladenen Threads exekutiert werden soll („On-Core-Thread-Scheduling" bzw. „Context-Scheduling").
-
Für beide
Scheduling-Stufen können
jeweils unterschiedliche Scheduling-Strategien verwendet werden.
Beispielsweise kann Ziel des „Context-Schedulings" sein, die Prozessor-Resourcen möglichst
optimal einzusetzen, und Ziel des „Thread-Scheduling", eine möglichst hohe Gesamt-Performance
zu erzielen (insbesondere z.B. ein hoher Durchsatz, bzw. geringe
Latenzzeiten, etc.).
-
Bei
herkömmlichen
Multithreaded (MT) Mikrocontroller- bzw. Mikroprozessor-Systemen
wird das „Context-Scheduling" üblicherweise hardware-mäßig, und
das „Thread-Scheduling" software-mäßig gesteuert.
-
Software-mäßiges „Thread-Scheduling" hat eine Belegung
von Prozessor-Resourcen durch das entsprechende Thread-Scheduling-Programm
zur Folge, und dementsprechend Einbußen bei der Gesamt-Performance
des Mikrocontroller- bzw. Mikroprozessor-Systems.
-
Die
Erfindung hat zur Aufgabe, ein neuartiges Thread-Scheduling-Verfahren, und eine neuartige
Einrichtung zur Verwendung bei einem Thread-Scheduling-Verfahren
zur Verfügung
zu stellen.
-
Sie
erreicht dieses und weitere Ziele durch die Gegenstände der
Ansprüche
1 und 9.
-
Vorteilhafte
Weiterbildungen der Erfindung sind in den Unteransprüchen angegeben.
-
Gemäß einem
ersten Aspekt der Erfindung wird ein Thread-Scheduling-Verfahren zur Verfügung gestellt,
welches die Schritte aufweist:
- – Durchführen eines
Schedulings für
von einem Multithreaded (MT) – Prozessor
abzuarbeitende Threads
daurch gekennzeichnet, dass das
Scheduling
in Abhängigkeit
von einer die Prozessor-Idle-Time repräsentierenden Variablen (idle) durchgeführt wird.
-
Bei
einer besonders vorteilhaften Ausgestaltung der Erfindung kann ein
Thread vorzeitig einem Scheduling unterzogen werden, wenn die die
Prozessor-Idle-Time repräsentierende
Variable (idle) grösser
als ein dem Thread zugeordneter Idle-Time-Schwellwert (scheduled.threshold) ist,
und ein in einer Thread-Liste dem Thread vorgeordneter Thread noch
nicht in einem Bereit-Zustand ist.
-
Durch
entsprechende Wahl des Idle-Time-Schwellwerts kann verhindert werden,
dass der dem in der Thread-Liste vorgeordneten, noch nicht bereiten
Thread nachgeordnete Thread „zu
früh" einem Scheduling
unterzogen wird. Insbesondere hat es sich gezeigt, dass das Inkaufnehmen
einer kleinen Wartezeit – bis
der vorgeordnete Thread ggf. in einen Bereit-Zustand übergewechselt
ist, und dann ggf. vor dem nachgeordneten Thread einem Scheduling
unterzogen wird – i.d.R.
zu einer entsprechend besseren Gesamt-Performance führt, als
ein sofortiges Scheduling des nachgeordneten Threads bei nicht-bereitem,
vorgeordneten Thread.
-
Besonders
vorteilhaft wird der (nachgeordnete) Thread vorzeitig einem Scheduling
unterzogen, wenn er – anders
als der in der Thread-Liste dem Thread vorgeordnete Thread – in einem
Bereit-Zustand ist.
-
Bei
einer besonders bevorzugten Ausgestaltung der Erfindung wird die
die Prozessor-Idle-Time repräsentierende
Variable (idle) hochgesetzt, wenn der Prozessor in einem Stall-Zustand
ist, und/oder ein freier Kontext zur Verfügung steht.
-
Gemäß einem
weiteren Aspekt der Erfindung wird eine Einrichtung zur Verwendung
bei einem Thread-Scheduling-Verfahren
zur Verfügung gestellt,
bei welchem ein Scheduling für
von einem Multithreaded (MT) – Prozessor
abzuarbeitende Threads durchgeführt
wird
daurch gekennzeichnet, dass die
Einrichtung eine
Idle-Time-Messeinrichtung aufweist zum Durchführen des Thread-Schedulings
in Abhängigkeit
von einer durch die Idle-Time-Messeinrichtung gemessenen, die Prozessor-Idle-Time
repräsentierenden
Variablen (idle).
-
Vorteilhaft
ist die o.g. Einrichtung in Hardware ausgeführt.
-
Im
folgenden wird die Erfindung anhand von Ausführungsbeispielen und der beigefügten Zeichnung
näher erläutert. In
der Zeichnung zeigt:
-
1 eine
schematische, vereinfachte Darstellung eines Mikrocontroller- bzw.
Mikroprozessor-Systems gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung;
-
2 eine
schematische Darstellung von bei einem Thread-Scheduling bei dem in 1 gezeigten
Mikrocontroller- bzw. Mikroprozessor-System verwendeten Einrichtungen;
-
3 eine
schematische Darstellung von mehreren in dem in 2 gezeigten
Kontext-Status-Array-Speicher abgespeicherten Kontext-Status-Elementen;
-
4 eine
schematische Darstellung eines der in 3 gezeigten
Kontext-Status-Elemente;
-
5 eine
schematische Darstellung der in 2 gezeigten
Kontext-Schedule-Vorrichtung;
-
6 eine
schematische Darstellung der in 2 gezeigten
Thread-List-Schedule-Vorrichtung;
-
7 eine
schematische Darstellung von durch die in der in 6 gezeigten
List-Manager-Einrichtung durchgeführten Verfahrensschritten;
-
8 eine
schematische Darstellung von durch die in der in 6 gezeigten
Idle-Time-Überwach-Einrichtung
durchgeführten
Verfahrensschritten; und
-
9 eine
schematische Darstellung von durch den in der 6 gezeigten
Thread Scheduler ausgeführten
Prozessen.
-
In 1 ist
eine schematische Darstellung eines Mikrocontroller- bzw. Mikroprozessor-Systems 10 gemäß einem
Ausführungsbeispiel
der Erfindung gezeigt.
-
Bei
dem Mikrocontroller- bzw. Mikroprozessor-System 10 kann
es sich z.B. um ein 8 Bit Mikrocontroller- bzw. Mikroprozessor-System 10 handeln, oder
um ein beliebiges anderes Mikrocontroller- bzw. Mikroprozessor-System,
z.B. ein entsprechendes 16 Bit, 32 Bit oder 64 Bit Mikrocontroller- bzw. Mikroprozessor-System,
etc., insbesondere um ein Multithreaded (MT) Mikrocontroller- bzw.
Mikroprozessor-System.
-
Das
Mikrocontroller- bzw. Mikroprozessor-System 10 weist eine
oder mehrere, auf einem entsprechenden Mikrochip 15 angeordnete
(zentrale) Steuer- bzw. Recheneinheiten 11 auf (Central
Processing Units (CPUs), bzw. CPU „Cores").
-
Die
CPU 11 oder die CPUs sind – über einen System-Bus 16 (und
ggf. ein oder mehrere weitere Bus-Systeme) – mit einer oder mehreren internen (auf
demselben Mikrochip 15, wie die CPU 11 vorgesehenen)
Speicher-Einrichtungen 17 verbunden, sowie – z.B. über den
System-Bus 16, und eine oder mehrere entsprechende Speicher-Steuereinrichtungen
(„memory
controller") 12 – mit einer
oder mehreren externen (auf einem anderen Mikrochip, als die CPU 11 vorgesehenen)
Speicher-Einrichtungen 18.
-
Die
Speicher-Einrichtungen 17, 18 können z.B.
als Programmspeichereinrichtung, und/oder Datenspeichereinrichtung
(„Programmspeicher", und „Datenspeicher") fungieren.
-
Der „Programmspeicher" enthält insbesondere
die Folge der von der bzw. den CPUs 11 abzuarbeitenden
Befehle, also das Programm (und ggf. zusätzlich entsprechende – von der
bzw. den CPUs 11 zu verwendende – Daten-Konstanten).
-
Der – z.B. von
der Speicher-Einrichtung 17 gebildete – Programmspeicher kann z.B.
von einem EPROM (Erasable PROM bzw. Löschbaren Festwertspeicher)
oder EEPROM (Electrically Erasable PROM bzw. Elektrisch Löschbarer
Festwertspeicher) gebildet werden, insbesondere einem Flash-EEPROM-Bauelement.
-
Dadurch
kann erreicht werden, dass das Programm auch bei unterbrochener
Stromzufuhr auf der entsprechenden Speicher-Einrichtungen gespeichert bleibt.
-
Für häufig zu ändernde
Programme können – alternativ – z.B. auch
RAMs (RAM = Random Access Memory bzw. Schreib-Lese-Speicher), insbesondere
DRAMs als Programmspeicher verwendet werden, die von einem externen
Massenspeicher geladen werden können.
-
Im
o.g. – z.B.
von der Speicher-Einrichtung 18 gebildeten – „Datenspeicher" können z.B.
die – insbesondere
von der bzw. den CPUs 11 beim Abarbeiten des Programms
ggf. abzuändernden – Variablen
gespeichert sein.
-
Der
Datenspeicher kann z.B. von einem oder mehreren RAM-Bauelementen, insbesondere
z.B. einem entsprechenden DRAM-Bauelement
(DRAM = Dynamic Random Access Memory), oder SRAM-Bauelement (SRAM = Static Random Access Memory)
gebildet werden.
-
Ein – durch
die CPU bzw. den CPU Core 11 abzuarbeitendes – Software-Programm
(bzw. mehrere derartige Programme) kann in eine Vielzahl entsprechender
Software Tasks (Threads) unterteilt sein.
-
Dies
hat z.B. den Vorteil, dass – insbesondere
bei dem hier gezeigten Multithreaded (MT) Mikrocontroller- bzw.
-
Mikroprozessor-System 10 – parallel
jeweils mehrere, verschiedenene Tasks gleichzeitig in den CPU Core 11 geladen,
und dort abgearbeitet werden können.
-
Zum
Speichern des Zustands bzw. „Kontexts" von – ggf. mehreren – in den
CPU Core 11 geladenen Threads sind bei dem CPU Core 11 bestimmte
Elemente wie z.B. Programm-Zähler
(PC bzw. Program Counter), Befehls-Zustands-Register (Execution
Status Register), Stack Pointer, Register File, etc., etc. ggf.
mehrfach vorhanden (z.B. zwei-, drei-, vier- oder fünffach,
etc.).
-
Jedem
Thread ist ein als Thread-Kontext bezeichneter Satz von Zustandselementen
verbunden. Hierdurch, und durch das mehrfache Vorsehen der o.g.
Elemente können
mehrere, verschiedene Threads (z.B. zwei, drei, vier oder fünf Threads,
etc.) gleichzeitig in den CPU Core 11 geladen, und kann zwischen
den Threads entsprechend hin- und hergeschaltet werden.
-
Auf
diese Weise können
bestimmte Prozessor-Resourcen – insbesondere
z.B. die Execution Pipeline (Processing Pipeline) – effizienter
genutzt werden; die Execution Pipeline kann verschiedenen Threads
zugeordnete Befehle simultan bearbeiten.
-
Beispielsweise
können
Takt-Zeiten, in denen es bei einem bestimmten, in den CPU Core 11 geladenen
Thread aus bestimmten Gründen
zu einer Verzögerung
kommt, zur Bearbeitung eines weiteren – parallel in den CPU Core
geladenen – Threads
verwendet werden.
-
Wie
im folgenden noch genauer erläutert wird,
wird i.d.R. nur ein (kleiner) Teil der jeweils auszuführenden
Threads simultan in den CPU Core 11 geladen; die übrigen,
auszuführenden
Threads werden – bis
sie in den CPU Core 11 geladen werden – ausserhalb des CPU Cores 11 zwischengespeichert (und
hierzu z.B. aus der Speicher-Einrichtung 17 ausgelesen,
und – zur
Zwischenspeicherung – in
einer nahe beim CPU Core 11 vorgesehenen Speichereinrichtung 2e abgespeichert).
-
Das
Scheduling der Threads findet somit in zwei Stufen statt: Bei einer
ersten Scheduling-Stufe wird entschieden, wann welche zur Abarbeitung
anstehende (ausserhalb des CPU Cores 11 zwischengespeicherte)
Threads in den CPU Core 11 geladen werden („Off-Core-Thread-Scheduling" bzw. „Thread-Scheduling", z.B. mit Hilfe
einer – hardwaremäßig verwirklichten,
in 2 gezeigten – Thread-List-Schedule-Vorrichtung 2).
-
Bei
einer zweiten, nachgeordneten Stufe wird entschieden, wann welcher
der in den CPU Core 11 geladenen Threads exekutiert werden
soll („On-Core-Thread-Scheduling" bzw. „Context-Scheduling", z.B. mit Hilfe
einer – ebenfalls
hardwaremäßig verwirklichten,
in 2 gezeigten – Kontext-Schedule-Vorrichtung 3).
-
Ein
von dem CPU Core 11 abzuarbeitender Thread kann sich in
den folgenden Zuständen
befinden:
- 1. „unavailable": Thread nicht startfertig
- 2. „available": Thread startfertig
- 3. „running": Für den Thread
werden durch die Execution Pipeline Processing entsprechende Befehle
geholt und ausgeführt
- 4. „suspended": Ausführung des
Threads abgebrochen
- 5. „ready": Thread bereit zum
Starten bzw. zum Fortfahren mit der Ausführung
- 6. „terminated": Ausführung beendet
-
Die
ersten zwei Zustände
(„unavailable", und „available") sind Off-Core-Zustände; die
weiteren Zustände "running", „suspended", „ready" sind On-Core-Zustände, und
stellen Off- Core-mäßig betrachtet (d.h.
für die
Thread-List-Schedule-Vorrichtung 2)
ein- und denselben Zustand dar, nämlich „loaded": Der Thread ist in den CPU Core 11 geladen.
-
Im
CPU Core 11 kann sich jeweils nur ein einziger Thread im
Zustand „running" befinden.
-
Die – für das „On-Core-Thread-Scheduling" bzw. „Context-Scheduling" verantwortliche – Kontext-Schedule-Vorrichtung 3 benötigt – für jeden On-Core-Thread – Informationen
hinsichtlich des momentanen Kontext-Status, und Attribut-Informationen (z.B.
hinsichtlich Thread-Priorität,
Pre-Emption-, und Suspend/Recovery-Property,
etc.).
-
Diese
Informationen sind in einem – ebenfalls
in 2 gezeigten – Kontext-Status-Array-Speicher 4 abgespeichert.
-
Der
Kontext-Status-Array-Speicher 4 bildet die Schnittstelle
zwischen der Kontext-Schedule-Vorrichtung 3, und der Thread-List-Schedule-Vorrichtung 2.
-
Eine Änderung
der im Kontext-Status-Array-Speicher 4 abgespeicherten
Kontext-Status-Informations-Daten kann durch in dem CPU Core 11 intern
stattfindende, oder externe Ereignisse getriggert werden.
-
Beispielsweise
kann ein – durch
entsprechende Daten im Kontext-Status-Array-Speicher 4 – als sich
zunächst
im Zustand „running" befindlich gekennzeichneter
Kontext dann, wenn der Thread z.B. auf einen Coprozessor-Zugriff
warten muss – durch Änderung
der entsprechende Daten im Kontext-Status-Array-Speicher 4 – als sich
im Zustand „suspended" befindlich gekennzeichnet
werden.
-
Wenn
der Coprozessor geantwortet hat, kann der – durch entsprechende Daten
im Kontext-Status-Array-Speicher 4 – als sich im Zustand „suspended" befindlich gekennzeichnete Kontext dann – durch Änderung
der entsprechende Daten im Kontext-Status-Array-Speicher 4 – als sich
im Zustand „ready" befindlich gekennzeichnet
werden, etc., etc.
-
Entsprechend ähnlich kann
z.B. ein – durch entsprechende
Daten im Kontext-Status-Array-Speicher 4 – als sich
zunächst
im Zustand „running" befindlich gekennzeichneter
Kontext dann, wenn der Thread vollständig abgearbeitet wurde, – durch Änderung
der entsprechende Daten im Kontext-Status-Array-Speicher 4 – als sich im Zustand „terminated" befindlich gekennzeichnet
werden, etc., etc.
-
Die
Thread-List-Schedule-Vorrichtung 2 verwaltet – wie im
folgenden noch genauer erläutert
wird – eine
Liste mit Off-Core-Threads,
und stellt eine Verknüpfung
zwischen einem Thread mit einem Kontext her, falls ein entsprechender,
freier Kontext vorhanden ist (und ggf. weitere – z.B. Idle-Time-abhängige – Voraussetzungen erfüllt sind,
s.u.).
-
Lädt die Thread-List-Schedule-Vorrichtung 2 einen
entsprechenden Thread in den CPU Core 11, werden durch
die Thread-List-Schedule-Vorrichtung 2 für den neu
geladenen Thread die Attribut-Informationen in dem Kontext-Status-Array-Speicher 4 abgelegt,
und die entsprechenden Status-Daten
so aktualisiert, dass der Thread im Kontext-Status-Array-Speicher 4 dann
als im Zustand „ready" befindlich gekennzeichnet
ist; zwischenzeitlich schreibt die Thread-List-Schedule-Vorrichtung 2 die
Start-Adresse des neu geladenen Threads in den entsprechenden Programm-Zähler (PC
bzw. Program Counter).
-
Die
o.g. – von
der Thread-List-Schedule-Vorrichtung 2 verwaltete – Liste
mit Off-Core-Threads enthält
die o.g. (Thread-) Start-Adresse, die Start-Bedingungen, die Attribut-Informationen, und
den aktuellen – Off-Core-mäßig gesehenen – Status
(„unavailable", „available", oder „loaded").
-
Eine Änderung
des Thread-Status eines in der Liste mit Off-Core-Threads enthaltenen Threads kann – ähnlich wie
oben für
On-Core-Thread-Status-Daten erläutert – durch
in dem CPU Core 11 intern stattfindende, oder externe Ereignisse
getriggert werden (z.B. kann ein Zustands-Wechsel von „unavailable" zu „available" veranlasst werden,
wenn entsprechende Bedingungen erfüllt sind, z.B. alle vorangehenden,
auf einen entsprechenden Thread bezogenen Threads geladen bzw. vollständig abgearbeitet
wurden (interne Triggerung), oder z.B. dann, wenn eine entsprechende,
dem Thread zugeordnete externe Resource Start-fertig ist (externe
Triggerung)).
-
Um
ein Scheduling für
einen im Zustand „available" befindlichen Thread
durchzuführen
(wobei ein Laden des Threads in den CPU Core 11 stattfindet,
s.o.), wird von der Thread-List-Schedule-Vorrichtung 4 der
Zustand sämtlicher
verfügbarer,
im Kontext-Status-Array-Speicher 4 abgespeicherter Kontexte
abgefragt, und insbesondere ermittelt, ob ein freier – nicht
von einem entsprechenden Thread belegter – Kontext vorhanden ist; zusätzlich kann
ein Scheduling – wie
weiter unten noch genauer erläutert wird – von weiteren,
z.B. die Prozessor-Idle-Time, etc. berücksichtigenden Voraussetzungen
abhängig gemacht
werden.
-
Die
o.g. (und ggf. weitere) externe Ereignisse anzeigende, externe Signale
werden zentral einer Ereignis-Steuer-Einrichtung 5 zugeführt, und
in entsprechende, die Thread-List-Schedule-Vorrichtung 2, die
Kontext-Schedule-Vorrichtung 3, und den Kontext-Status-Array-Speicher 4 entsprechend
(z.B. wie oben erläutert)
steuernde interne Steuer-Signale umgesetzt, welche von der Ereignis-Steuer-Einrichtung 5 an
die Kontext-Schedule-Vorrichtung 3 bzw. den Kontext-Status-Array-Speicher 4,
oder die Thread-List-Schedule-Vorrichtung 2 weitergeleitet werden.
-
Wie
in 3 veranschaulicht, sind im Kontext-Status-Array-Speicher 4 mehrere
Kontext-Status-Elemente 4a, 4b, 4c, 4d (CSE
bzw. Context Status Element) abgespeichert, die jeweils – bezogenen auf
jeweils einen Kontext – Informationen
hinsichtlich des momentanen Kontext-Status, und Attribut-Informationen (z.B.
hinsichtlich Thread-Priorität, Pre-Emption-, und Suspend/Recovery-Property,
etc.) enthalten.
-
An
einer Leitung 6 anliegende, von der CPU Core 11 erzeugte
Signale, die eine Kontext-Status-Aktualisierung bewirken sollen,
werden mit Hilfe eines von der Kontext-Schedule-Vorrichtung 3 über eine
Leitung 7 gesteuerten Multiplexers 8 zu dem dem
momentan laufenden bzw. aktuellen Kontext zugeordneten Kontext-Status-Element 4a, 4b weitergeleitet
(insbesondere durch Anlegen eines die Kontext-ID („Running
Context Number")
des momentan laufenden Kontextes anzeigenden Steuer-Signals an die
mit einem Steuer-Eingang des Multiplexers 8 angeschlossene
Leitung 7).
-
In 4 ist
eine schematische Darstellung eines der in 3 gezeigten
Kontext-Status-Elemente 4a gezeigt.
-
Das
Kontext-Status-Element 4a weist zwei Register 9a, 9b auf,
und zwar ein Register 9a zum Speichern der Kontext-Status-Informationen, und
ein Register 9b zum Speichern der Attribut-Informationen.
-
Das
Register 9a weist mindestens ein Bit auf, welches anzeigt,
ob das jeweilige Kontext-Status-Element 4a (bzw. der entsprechende
Kontext) frei („free"), oder belegt („not free") ist (d.h. von einem entsprechenden
Thread belegt ist, oder nicht) („occupied"-Bit).
-
Falls
von der Thread-List-Schedule-Vorrichtung 2 ermittelt wird,
dass ein Kontext-Status-Element 4a (bzw. der entsprechende
Kontext) frei („free") ist (d.h., falls
das „occupied"-Bit in einem einen
solchen Zustand anzeigenden (z.B. nicht gesetzten) Zustand ist),
kann durch die Thread-List-Schedule-Vorrichtung 2 ein
Thread auf den Kontext geladen werden, und dann das „occupied"-Bit gesetzt werden
(sowie ein weiteres Status-Bit, welches den Thread dann als im o.g.
Zustand „ready" befindlich kennzeichnet).
-
Des
weiteren werden durch die Thread-List-Schedule-Vorrichtung 2 für den neu
geladenen Thread die entsprechenden Attribut-Informationen in dem
Kontext-Status-Array-Speicher 4, insbesondere in dem Register 9b des
entsprechenden Kontext-Status-Elements 4a abgelegt.
-
Der
Zustand des o.g. „ready"-Bits wird von der
Kontext-Schedule-Vorrichtung 3 abgefragt;
diese wählt
den nächsten,
laufenden bzw. von dem CPU Core 11 abzuarbeitenden Kontext
bzw. Thread unter solchen Kontexten bzw. Threads aus, die durch
ein gesetztes „ready"-Bit als im Zustand „ready" befindlich gekennzeichnet
sind.
-
Die
in 4 gezeigte Bedingungs-Überprüf-Einrichtung 20 dient
dazu, von entsprechenden externen Ereignissen (bzw. diese repräsentierende Signale)
solche herauszufiltern, die den Status des entsprechenden Kontext ändern. Dies
geschieht entsprechend den im Register 9b abgelegten Attribut-Informationen zum
entsprechenden Thread, und dem momentanen Kontext-Status.
-
In 5 ist
eine schematische Darstellung der in 2 gezeigten
Kontext-Schedule-Vorrichtung 3 gezeigt.
-
Diese
weist eine Kontext-Auswahl-Einrichtung 3a, und einen Switch-Trigger-Generator 3b auf.
-
Die
Kontext-Auswahl-Einrichtung 3a wählt unter den im Zustand „ready" befindlichen Kontexten den
als nächstes
durch den CPU Core 11 abzuarbeitenden bzw. als nächstes laufenden
Kontext aus, z.B. entsprechend einem „Round-Robin"-Auswahlverfahren.
-
Das
Round-Robin-Auswahlverfahren kann ohne Wichtung der Kandidaten-Kontexte
stattfinden; alternativ kann beim Round-Robin-Auswahlverfahren auch eine Wichtung
der Kontexte stattfinden, z.B. unter Verwendung der o.g. Attribut-Informationen, z.B. unter
Berücksichtigung
der Thread-Priorität, der Pre-Emption-Property,
etc.
-
Alternativ
kann auch ein beliebiges anderes Auswahlverfahren verwendet werden,
z.B. ein Auswahlverfahren, bei dem für jeden Kontext eine maximale
Laufzeit spezifiziert ist, die bei der Kontext-Auswahl berücksichtigt
wird.
-
Wird
ein neuer Kontext ausgewählt,
erzeugt der Switch-Trigger-Generator 3b ein
(z.B. über
eine Leitung 21) dem CPU Core 11, und einer Kontext-ID-Speichereinrichtung 3c zugeführtes Switch-Trigger-Signal;
der durch die Kontext-Auswahl-Einrichtung 3a ausgewählte Kontext
bzw. Thread wird dann zum dortigen, unmittelbaren Abarbeiten dem
CPU Core 11 zur Verfügung
gestellt, und die in der Kontext-ID-Speichereinrichtung 3c abgespeicherte
Kontext-ID („Running
Context Number") so
aktualisiert, dass sie der Nummer bzw. ID des jeweils laufenden
(neu ausgewählten)
Kontextes entspricht (und die Kontext-ID des neu ausgewählten bzw.
geladenen Kontextes über
eine Leitung 22 an den Kontext-Status-Array-Speicher 4 weitergeleitet).
-
In 6 ist
eine schematische Darstellung der in 2 gezeigten
Thread-List-Schedule-Vorrichtung 2 gezeigt.
-
Diese
weist eine List-Manager-Einrichtung 2a, einen Thread Scheduler 2b,
eine Idle-Time-Überwach-Einrichtung 2c,
und eine Idle-Time-Zähl-Einrichtung 2d auf.
-
Die
List-Manager-Einrichtung 2a, der Thread Scheduler 2b,
die Idle-Time-Überwach-Einrichtung 2c,
und die Idle-Time-Zähl-Einrichtung 2d sind
für das
Thread-Scheduling von in der – oben
bereits kurz erwähnten – Speichereinrichtung 2e der Thread-List-Schedule-Vorrichtung 2 zwischengespeicherten,
auszuführenden
Threads verantwortlich.
-
Die
in der Speichereinrichtung 2e – z.B. in einer entsprechenden
Liste – gespeicherten
Threads, bzw. deren Attribut-Informationen können in Reaktion auf bestimmte
Ereignisse, bzw. bestimmte Ereignisse anzeigende Signale geändert bzw.
bearbeitet werden. Betrifft ein Ereignis einen bereits im Zustand „running" befindlichen Thread,
wird das das entsprechende Ereignis anzeigende Signal durch einen Event
Controller 105 an die Kontext-Schedule-Vorrichtung 3 weitergeleitet;
ansonsten werden mit Hilfe der List-Manager-Einrichtung 2a die in der Speichereinrichtung 2e gespeicherten
Attribut-Informationen des jeweiligen Threads – dem jeweiligen Ereignis entsprechend – aktualisiert.
-
Zur
Steuerung der Thread-List-Schedule-Vorrichtung 2 können die
folgenden – in
Hardware-Registern implementierten – Variablen verwendet werden:
- - list_base.status:
im Zustand "true", falls der nächste in-order Thread
laufbereit ist, ansonsten im Zustand „false"
- - list_base.adr:
Adresse des Listen-Eintrags, der die Thread-Daten
des nächsten
in-order-Threads enthält
- - list_base.attributes:
Attribute des Thread-Eintrags des
nächsten
in-order-Threads; aus Effizienz-Gründen lokal zwischengespeichert
- - scheduled.status
im Zustand "true",
falls der nächste
out-of-order Thread lauf-bereit ist, ansonsten im Zustand „false"
- - scheduled.adr:
Adresse des Listen-Eintrags, der die entsprechenden
Thread-Daten des
entsprechenden (out-of-order) Threads enthält
- – scheduled.threshold:
Idle
Time Schwellwert
- - scheduled.prev
Adresse des letzten Eintrags in „scheduled.adr"
- – scheduled.attributes
Attribute
des entsprechenden Thread-Eintrags des entsprechenden out-of-order-Threads;
aus Effizienz-Gründen
lokal zwischengespeichert
-
Die
List-Manager-Einrichtung 2a wird durch ein entsprechendes
Ereignis getriggert (bzw. durch ein ein entsprechendes Ereignis
anzeigendes Signal).
-
In
Reaktion hierauf geht die List-Manager-Einrichtung 2a – in einer
bestimmten Reihenfolge – (d.h. „in-Order") durch die in der
Speichereinrichtung 2e abgespeicherte Thread-Liste, z.B.
vom untersten Thread-Eintrag („base") zum obersten Thread-Eintrag („top"). Alternativ kann
die List-Manager-Einrichtung 2a die in der Thread-Liste
abgespeicherten Threads auch in einer anderen – ebenfalls vorbestimmten – Reihenfolge
(d.h. auch dann „in-Order") inspizieren.
-
In 7 ist
weiter im Detail eine schematische Darstellung von durch die List-Manager-Einrichtung 2a durchgeführten Verfahrensschritten
gezeigt.
-
Wie
aus 7 hervorgeht, werden in Reaktion auf die durch
das o.g. Ereignis hervorgerufene Triggerung der List-Manager-Einrichtung 2a zunächst die
o.g. Variablen list_base.status, und scheduled.status, sowie eine
Variable thread_scheduled in einen Zustand „false" gebracht (Schritt A).
-
Daraufhin
wird – wie
oben beschrieben – „in-order" (z.B. von unten
nach oben) durch die in der Speichereinrichtung 2e abgespeicherte
Thread-Liste gegangen (d.h. nacheinander durch die in der Thread-Liste
enthaltenen Threads, wobei – sukzessive – ein Thread
nach dem anderen betrachtet wird) (Schritt B).
-
Als
nächstes
kann (optional) die Auswirkung des o.g. Ereignisses auf die jeweiligen
Threads, insbesondere deren Status (entry.status) berechnet werden,
wobei sich der neue Status aus einer den alten Thread-Status, das
Ereignis, und die jeweiligen Thread-Attribute berücksichtigenden
Funktion f(entry.status, entry.attributes, event) ergibt (Schritt
C).
-
Nach
dem im Schritt C erfolgten Aktualisieren der Thread-Status-Informationen
wird überpfüft, ob der
jeweilige Thread sich in einem Bereit-Zustand („ready") befindet (Schritt D).
-
Falls
ja (entry.status="ready"), wird überprüft, ob der
jeweilige Thread der erste der in der Thread-Liste enthaltenen Threads
ist (d.h. sich ganz unten in der o.g. Thread-Liste befindet) (Schritt
E).
-
Falls
ja (entry.adr=list_base.adr), wird der entsprechende Thread in einen
laufbereiten Zustand („pending
for running") gebracht,
und es wird – in
einem Schritt F – die
o.g. Variable list_base.status in einen Zustand „true" gebracht (sowie list_base.adr auf entry.addr
gesetzt, und list_base.attributes auf entry.attributes). Sobald
ein Kontext frei wird, wird durch den Thread Scheduler 2b dann
ein Scheduling für den
entsprechenden Thread vorgenommen.
-
Falls
beim o.g. Schritt E ermittelt wird, dass der jeweilige Thread nicht
der erste der in der Thread-Liste enthaltenen Threads ist (d.h.
falls gilt entry.adr≠list_base.adr),
wird überprüft, ob nicht schon
für andere,
nachfolgende Threads ein entsprechendes (out-of-order-)Scheduling
vorgenommen worden ist (Schritt G).
-
Falls
nicht, d.h. falls gilt thread_scheduled="false", wird der entsprechende Thread dann
(neu) als Kandidat für
ein out-of-order-Scheduling
angesehen.
-
Für einen
als Out-Of-Order-Schedule-Kandidaten angesehenen Thread wird durch
den Thread Scheduler 2b ein Scheduling für den entsprechenden Thread
vorgenommen, falls die Gesamt-Idle-Time des Prozessors grösser als
der dem jeweiligen Thread zugeordnete Idle Time Schwellwert ist.
-
Beim
hier beschriebenen Verfahren kommt nur der (von unten betrachtet)
erste, dem allerersten Thread nachgeordnete der in der Thread-Liste
enthaltenen, in einem Bereit-Zustand („ready") befindlichen Threads als Kandidat
für ein
out-of-order-scheduling
in Frage.
-
Alternativ
können
auch beliebige, andere Scheduling-Verfahren zur Anwendung kommen,
beispielsweise Verfahren, bei denen – falls der erste in der Thread-List
enthaltene, dem allerersten Thread nachgeordnete Thread sich nicht
einem Bereit-Zustand („ready") befindet – unter
allen übrigen Threads,
bei denen der jeweilige Idle Time Schwellwert kleiner als die Gesamt-Idle-Time
des Prozessors ist, derjenige Thread (oder diejenigen Threads) als
Out-Of-Order-Scheduling-Kandidat
ausgewählt wird
bzw. werden, bei dem/bei denen der Idle Time Schwellwert am kleinsten
ist.
-
Nach
der Auswahl eines entsprechenden Out-Of-Order-Scheduling-Kandidaten wird in einem Schritt
H die o.g. Variable entry_status in einen Zustand „scheduled" gebracht, die Variable
scheduled.status in einen Zustand „true", etc. (vgl. 7).
-
Am
Ende des hier dargestellten Scheduling-Verfahrens enthält die Variable „scheduled" den (ersten) einem
(out-of-order-)Scheduling
zu unterziehenden out-of-order- Thread, und die Variable „list_base" den einem (in-order-)Scheduling
zu unterziehenden, unten in der Liste befindlichen Thread.
-
Die
entsprechend dem o.g. Algorithmus ggf. geänderten Listen-Einträge werden
zurück
in die o.g. – in
der Speichereinrichtung 2e abgespeicherte – Thread-Liste
geschrieben (Schritt I).
-
Um
Threads zusätzlich
in die Liste mit aufzunehmen, oder um Threads aus der Liste zu streichen, wird
durch die CPU Core 11 ein ein entsprechendes „Update"-Ereignis anzeigendes
Signal erzeugt; die List-Manager-Einrichtung 2a geht dann – entsprechend
wie oben beschrieben „in-order" – durch die in der Speichereinrichtung 2e abgespeicherte Thread-Liste,
und sorgt für
die entsprechenden Änderungen
(Streichungen aus der Liste), und/oder Ergänzungen (zusätzliche
Aufnahme in die Liste).
-
In 8 ist
eine schematische Darstellung von durch die in der in 6 gezeigten
Idle-Time-Überwach-Einrichtung 2c durchgeführten Verfahrensschritten
gezeigt.
-
Mit
Hilfe der Idle-Time-Überwach-Einrichtung 2c wird
ermittelt, ob für
einen dem in der Thread-Liste unten stehenden, im nicht-bereiten
Zustand befindlichen in-order-Thread
nachfolgenden, im bereiten Zustand befindlichen Thread vor dem in-order-Thread
ein (Out-Of-Order-) Scheduling durchgeführt werden soll.
-
In
einem ersten Schritt L wird durch die Idle-Time-Überwach-Einrichtung 2c der Zustand
der o.g. Variablen list_base.status abgefragt. Falls diese im Zustand „true" ist, wird ermittelt,
dass der in der Thread-Liste unten stehende in-order-Thread als nächstes einem
Scheduling zu unterziehen ist. Demnach wird einer Variablen „next-to-go" ein – für den in der
Thread-Liste unten stehenden in-order-Thread stehender – Wert „in-order" zugewiesen (Schritt M).
-
Falls
beim o.g. Schritt L ermittelt wird, dass die o.g. Variable list_base.status
im Zustand „false" ist, wird in einem
Schritt N ermittelt, ob der dem in der Thread-Liste unten stehenden
in-order-Thread nachfolgende out-of-order Thread in einem laufbereiten Zustand
ist (d.h., ob die Variable scheduled.status in einem Zustand „true" ist), und ob die
Idle-Time des Prozessors bzw. der CPU Core 11 grösser als
der dem jeweiligen Thread zugeordnete Idle Time Schwellwert ist
(d.h., ob eine Variable „idle" grösser als
die Variable scheduled.threshold ist).
-
Falls
ja, wird ermittelt, dass der dem in der Thread-Liste unten stehenden
in-order-Thread nachfolgende Thread einem (Out-Of-Order-) Scheduling zu
unterziehen ist. Demnach wird der Variablen „next-to-go" ein – für den dem
in der Thread-Liste
unten stehenden in-order-Thread nachfolgenden out-of-order-Thread stehender – Wert „out-of-order" zugewiesen (Schritt
O).
-
Falls
nein (d.h. falls die Variable scheduled.status in einem Zustand „false" ist, oder die Variable
idle kleiner-gleich der Variablen scheduled.threshold), wird ermittelt,
dass (vorerst) kein Thread einem Scheduling zu unterziehen ist.
Demnach wird der Variablen „next-to-go" ein dies kennzeichnender
Wert „noone" zugewiesen (Schritt
P).
-
Mit
Hilfe der „next-to-go"-Variable wird also angezeigt,
ob der nächste,
abzuarbeitende, einem Scheduling zu unterziehende Thread wie durch
die Variable „list_base" angezeigt gewählt werden
soll (next-to-go = in-order), oder wie durch die Variable „scheduled" angezeigt (next-to-go
= out-of-order), oder ob (vorerst) kein Thread einem Scheduling
zu unterziehen ist (next-to-go = noone).
-
Mit
Hilfe der o.g. Variablen „idle" wird die Gesamt-Idle-Time
des Prozessors bzw. der CPU Core 11 angezeigt. Der Wert
der Variablen „idle" wird von der Idle-Time-Zähl-Einrichtung 2d ermittelt,
und der Idle-Time-Überwach-Einrichtung 2c zur
Verfügung gestellt.
-
Die
Idle-Time-Zähl-Einrichtung 2d weist
einen – die
Variable „idle" bereitstellenden – Zähler auf, der
immer dann auf „Null" zurückgesetzt
wird, wenn durch die Thread-List-Schedule-Vorrichtung 2,
bzw. den Thread Scheduler 2b ein neuer Thread einem Scheduling
unterzogen bzw. geladen wurde, insbesondere ein neuer Thread einem
entsprechenden, freien Kontext zugeordnet wurde.
-
Der
Zähler
wird dann (und so lange andauernd fortdauernd, z.B. bei jeder steigenden
(und/oder fallenden) Taktflanke) inkrementiert, wenn (bzw. solange)
zumindest ein freier Kontext zur Verfügung steht, und der Prozessor
bzw. der CPU Core 11 in einem „Stall"-Zustand ist (was der Idle-Time-Zähl-Einrichtung 2d von
der CPU Core 11 durch ein entsprechendes, an einer Leitung 22 ausgegebenes
Stall-Signal angezeigt wird).
-
Der
Thread Scheduler 2b ordnet den durch die o.g. Variable
next_to_go als nächstes
einem Scheduling zu unterziehenden Thread dem nächsten freien Kontext zu (d.h.
aktualisiert dessen Status und Attribute in dem Kontext-Status-Array-Speicher 4), sorgt
für ein
entsprechendes Initiieren des Programm-Zählers (PC bzw. Program Counter),
und löscht
den entsprechenden Thread von der o.g. Thread-Liste.
-
Des
weiteren veranlasst der Thread Scheduler 2b ein entsprechendes
(Cache-)Zwischenspeichern der Attribute des entsprechenden Threads, und
leitet dann, wenn ein entsprechendes Ereignis (bzw. ein solches
repräsentierende
Signale) das Ausführen
einer Aktion mit dem entsprechenden Thread erforderlich macht die
entsprechenden Signale an die Kontext-Schedule-Vorrichtung 3 weiter.
-
Eine
schematische, weitere Details zeigende Darstellung von entsprechenden
durch den in der 6 gezeigten Thread Scheduler 2b ausgeführten Prozessen
(„process
1", „process
2", und „process 3") ist in 9 gezeigt.
-
- 2
- Thread-List-Schedule-Vorrichtung
- 2a
- List-Manager-Einrichtung
- 2b
- Thread
Scheduler
- 2c
- Idle-Time-Überwach-Einrichtung
- 2d
- Idle-Time-Zähl-Einrichtung
- 2e
- Speichereinrichtung
- 3
- Kontext-Schedule-Vorrichtung
- 3a
- Kontext-Auswahl-Einrichtung
- 3b
- Switch-Trigger-Generator
- 3c
- Kontext-ID-Speichereinrichtung
- 4
- Kontext-Status-Array-Speicher
- 4a
- Kontext-Status-Element
- 4b
- Kontext-Status-Element
- 4c
- Kontext-Status-Element
- 4d
- Kontext-Status-Element
- 5
- Ereignis-Steuer-Einrichtung
- 6
- Leitung
- 7
- Leitung
- 8
- Multiplexer
- 9a
- Register
- 9b
- Register
- 10
- Mikroprozessor-System
- 11
- CPU
- 12
- Speicher-Steuereinrichtung
- 15
- Mikrochip
- 16
- System-Bus
- 17
- Speicher-Einrichtung
- 18
- Speicher-Einrichtung
- 20
- Bedingungs-Überprüf-Einrichtung
- 21
- Leitung
- 22
- Leitung
- 105
- Event
Controller