DE202004021684U1

DE202004021684U1 - Einrichtungen und Vorrichtungen zur Verwendung bei einem Scheduling

Info

Publication number: DE202004021684U1
Application number: DE202004021684U
Authority: DE
Original assignee: Infineon Technologies AG
Current assignee: Infineon Technologies AG
Priority date: 2004-12-20
Filing date: 2004-12-20
Publication date: 2010-04-29
Anticipated expiration: 2014-12-21
Also published as: US7793296B2; US20060161924A1; DE102004061339A1

Abstract

Einrichtung (3) zur Verwendung bei einem Scheduling, bei welchem ein Scheduling für von einem Multithreaded (MT)-Prozessor (11) abzuarbeitende Threads durchgeführt wird dadurch gekennzeichnet, dass die Einrichtung (3) eine Vorrichtung (1) aufweist zum Vergleichen von den Threads zugeordneten Index-Variablen.

Description

Die Erfindung betrifft Einrichtungen und Vorrichtungen zur Verwendung bei einem Scheduling.
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 Programmbefehlfolgen (Threads) unterteilt sein.
Dies hat z. B. den Vorteil, dass – insbesondere z. B. bei sog. Multithreaded (MT) Mikrocontroller- bzw. Mikroprozessor-Systemen – konkurrierend jeweils mehrere, verschiedene Programmbefehlfolgen 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 – ebenso 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 dem CPU Core gehalten; 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, und einem entsprechenden „Kontext” zugeordnet werden („Off-Core-Thread-Scheduling” bzw. „Thread-Scheduling”). Bei einer zweiten, nachgeordneten Stufe wird entschieden, wann welcher der in den CPU Core geladenen, einem Kontext zugeordneten Threads exekutiert werden soll („On-Core-Thread-Scheduling” bzw. „Context-Scheduling”).
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.
Für beide Scheduling-Stufen können jeweils unterschiedliche Scheduling-Strategien verwendet werden. Ziel des „Context-Schedulings” (und ggf. auch des „Thread-Schedulings”) ist – allgemein formuliert – die Optimierung einer entsprechenden Kostenfunktion, insbesondere z. B. das Erzielen eines möglichst hohen Durchsatzes, die sog. Toleranz entsprechender Latenzen, bzw. ein möglichst optimaler Einsatz der Prozessor-Resourcen, etc., etc., und Ziel des „Thread-Scheduling” z. B. die Bestimmung einer konfliktfreien Folge von Programmflüssen, oder die Priorisierung von Programmflüssen anhand von Echtzeit-Anforderungen, etc.
Herkömmliche Context-Scheduling-Strategien basieren auf (fest vergebenen, den einzelnen, jeweils abzuarbeitenden Threads zugeordneten, „quasi-statischen”) Prioritäten.
Dies hat zur Folge, dass i. d. R. – im Sinne der o. g., und/oder entsprechender weiterer Ziele des jeweiligen Schedulings (d. h. im Sinne der Optimierung einer entsprechenden Kostenfunktion) – kein optimales, bzw. relativ weit von einem optimalen Scheduling entferntes Context-Scheduling erreicht wird.
Die Erfindung hat zur Aufgabe, neuartige Einrichtungen und Vorrichtungen zur Verwendung bei einem Scheduling, insbesondere Kontext-Scheduling zur Verfügung zu stellen.
Sie erreicht dieses und weitere Ziele durch die Gegenstände der Ansprüche 1, 6, 7.
Vorteilhafte Weiterbildungen der Erfindung sind in den Unteransprüchen angegeben.
Bei einer besonders vorteilhaften Ausgestaltung der Erfindung wird derjenige Thread als durch den Prozessor abzuarbeitender Thread ausgewählt, dessen Index-Variable den höchsten (oder – bei einer weiteren, alternativen, vorteilhaften Ausgestaltung – den niedrigsten) Wert aufweist.
Bei einer bevorzugten Weiterbildung der Erfindung kann der Wert der Index-Variable eines im aktiven Zustand befindlichen Threads während des aktiven Thread-Zustands geändert werden; insbesondere kann der Wert der Index-Variable des jeweils abgearbeiteten Threads im Verlauf der Thread-Abarbeitung geändert werden.
Vorteilhaft kann zur Änderung des Werts der Index-Variable eine Hardware-Schaltung, insbesondere eine Hardware-Interpolator-Schaltung verwendet werden.
Gemäß einem weiteren Aspekt der Erfindung wird eine Einrichtung, insbesondere eine Kontext-Schedule-Einrichtung zur Verwendung bei einem Scheduling zur Verfügung gestellt, bei welchem ein Scheduling für von einem Multithreaded (MT)-Prozessor abzuarbeitende Threads durchgeführt wird dadurch gekennzeichnet, dass die Einrichtung eine Vorrichtung aufweist zum Vergleichen von den Threads zugeordneten Index-Variablen.
Bei einer vorteilhaften Ausgestaltung ist die Vergleichs-Vorrichtung so ausgestaltet und eingerichtet, dass mit der Vergleichs-Vorrichtung derjenige Thread ermittelt wird, dessen Index-Variable den höchsten (oder alternativ z. B. den niedrigsten) Wert aufweist.
Vorteilhaft weist die Einrichtung eine Vorrichtung auf zum Erzeugen eines Thread-Wechsel-Signals (bzw. eines Context-Switch-Indikations-Signals), wenn durch die Vergleichs-Vorrichtung ermittelt wird, dass ein Wechsel beim Thread mit höchstem (oder alternativ: mit niedrigstem) Index-Variablen-Wert stattgefunden hat. Die Abarbeitung des zuletzt abgearbeiteten Threads kann dann unterbrochen, und stattdessen mit der Abarbeitung des Threads mit (dann) höchstem Index-Variablen-Wert begonnen werden.
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 der bei dem in 1 gezeigten Mikrocontroller- bzw. Mikroprozessor-System bei einem Kontext-Scheduling verwendeten Kontext-Schedule-Vorrichtung, und der in 1 gezeigten CPU;
3 eine schematische Detail-Darstellung der in 2 gezeigten Kontext-Schedule-Vorrichtung;
4 eine schematische Detail-Darstellung einer der in der in 3 gezeigten Kontext-Schedule-Vorrichtung verwendeten Interpolator-Einrichtungen.
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, z. B. um ein auf einem „Fine Grain” Multithreaded Prozessor Mikro-Architektur-Protokoll der Fa. Infineon basierendes 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 zugeordnet. 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 (insbesondere so, dass beim Umschalten nur wenige Zyklen, oder – besonders vorteilhaft – kein Zyklus verloren geht).
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 (weiteren) Speichereinrichtung 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 in der o. g. weiteren Speichereinrichtung zwischengespeicherte) Threads in den CPU Core 11 geladen werden, und einem entsprechenden „Kontext” zugeordnet werden („Off-Core-Thread-Scheduling” bzw. „Thread-Scheduling”).
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 – hardwaremäßig verwirklichten, in 2 gezeigten – Kontext-Schedule-Vorrichtung 3).
Das Thread-Scheduling kann z. B. – entsprechend wie herkömmlich – software-mäßig (oder alternativ z. B. auch hardware-mäßig) gesteuert werden.
Die – für das „On-Core-Thread-Scheduling” bzw. „Context-Scheduling” verantwortliche – Kontext-Schedule-Vorrichtung 3 benötigt – für jeden in den CPU Core 11 geladenen On-Core-Thread – Informationen hinsichtlich des momentanen Kontext-Status, und Attribut-Informationen (z. B. hinsichtlich Thread-Index-Wert bzw. Default-Thread-Index-Wert (bzw. hinsichtlich entsprechender Interpolation-Type-Default-, und Expected-Reward-Default-Werte (s. u.))).
Diese Informationen können in einem entsprechenden Kontext-Status-Array-Speicher abgespeichert sein.
Im Kontext-Status-Array-Speicher können mehrere Kontext-Status-Elemente (CSE bzw. Context Status Element) enthalten sein, die jeweils – bezogenen auf jeweils einen Kontext – die o. g. Informationen hinsichtlich des momentanen Kontext-Status, und die o. g. Attribut-Informationen enthalten.
Jedes Kontext-Status-Element kann zwei Register aufweisen, und zwar ein erstes Register zum Speichern der Kontext-Status-Informationen, und ein zweites Register zum Speichern der Attribut-Informationen.
Das erste Register weist mindestens ein Bit auf, welches anzeigt, ob das jeweilige Kontext-Status-Element (bzw. der entsprechende Kontext) frei („free”), oder belegt („not free”) ist (d. h. von einem entsprechenden Thread belegt ist, oder nicht) („occupied”-Bit).
Falls beim o. g. Thread-Scheduling ermittelt wird, dass ein Kontext-Status-Element (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 einer von mehreren zur Bearbeitung anstehenden, in der o. g. weiteren Speichereinrichtung zwischengespeicherten Kandidaten-Threads (entsprechend der beim Thread-Scheduling verwendeten Scheduling-Strategie (z. B. entsprechend wie bei herkömmlichen Vorgehen jeweils der erste von mehreren in einer Kandidaten-Thread-Liste enthaltenen, in einem Bereit-Zustand befindlichen Threads)) in den CPU Core 11 geladen, der Thread mit dem entsprechenden Kontext verknüpft, und dann das „occupied”-Bit gesetzt werden (sowie z. B. ein weiteres Status-Bit, welches den Thread dann als im Zustand „idle” befindlich kennzeichnet).
Des weiteren können für den neu geladenen Thread die entsprechenden – z. B. im o. g. Programmspeicher 17 unter Zuordnung zum jeweiligen Thread abgespeicherten (und beim Laden des Threads in der o. g. weiteren Speichereinrichtung zwischengespeicherten) – Attribut-Informationen (Thread-Index- bzw. Default-Thread-Index-Wert (bzw. Interpolation-Type-Default-, und Expected-Reward-Default-Wert (s. u.))) in dem Kontext-Status-Array-Speicher, insbesondere in dem (zweiten) Register des entsprechenden Kontext-Status-Elements abgelegt werden, und kann die Start-Adresse des neu geladenen Threads in den entsprechenden Programm-Zähler (PC bzw. Program Counter) des CPU Core 11 geschrieben werden.
Ein von dem CPU Core 11 abzuarbeitender Thread kann sich – On-Core-mäßig betrachtet (d. h. für die Kontext-Schedule-Vorrichtung 3) – insbesondere z. B. in einem aktiven, oder einem nicht aktiven Zustand befinden:

– „nicht-aktiv” (z. B. „idle”: Thread bereit zum Starten bzw. zum Fortfahren mit der Ausführung, jedoch zum Zeitpunkt (momentan) nicht ausgeführt)
– „aktiv” bzw. „running”: Thread zum Zeitpunkt ausgeführt, indem entsprechende Befehle ggf. geholt und durch die Execution Pipeline bzw. Processing Pipeline ausgeführt werden.

Im CPU Core 11 kann sich jeweils nur ein einziger Thread im Zustand „running” befinden.
Der Zustand des o. g. – im Kontext-Status-Array-Speicher abgespeicherten – „idle”-Bits wird von der Kontext-Schedule-Vorrichtung 3 abgefragt; diese wählt – falls ein von dem CPU Core 11 in Abarbeitung befindlicher, d. h. im Zustand „running” befindlicher Kontext bzw. Thread durch einen neuen, abzuarbeitenden Thread ersetzt werden soll (bzw. neu ein Thread in einen Zustand „running” gebracht werden soll) – den nächsten, laufenden bzw. von dem CPU Core 11 abzuarbeitenden (d. h. in einen Zustand „running” zu bringenden) Kontext bzw. Thread unter solchen Kontexten bzw. Threads aus, die durch ein gesetztes „idle”-Bit als im Zustand „idle” befindlich gekennzeichnet sind.
Wie aus 2 ersichtlich ist, wird – z. B. mittels eines über eine Leitung 6 übertragenen Signals „Current Context” – von dem CPU Core 11 aus fortwährend der Kontext-Schedule-Vorrichtung 3 mitgeteilt, welcher Kontext bzw. Thread momentan in einem Zustand „running” ist, d. h. für welchen Thread durch die Execution Pipeline bzw. Processing Pipeline gerade entsprechende Befehle geholt, und ausgeführt werden (z. B. durch Übertragung einer den jeweils ausgeführten bzw. laufenden Thread kennzeichnenden Kontext-ID („Running context number”)).
Gemäß 3 weist die Kontext-Schedule-Vorrichtung 3 eine – z. B. der Anzahl an (maximal) zur Verfügung stehenden Kontexten entsprechende, und diesen jeweils zugeordnete – Vielzahl von Interpolator-Einrichtungen 5a, 5b, etc. auf.
Eine erste Interpolator-Einrichtung (z. B. die Interpolator-Einrichtung 5a) kann beim vorliegenden Ausführungsbeispiel (vorübergehend oder dauerhaft) z. B. einem ersten der Vielzahl von Kontexten zugeordnet sein, z. B. einem momentan laufenden (in einem Zustand „running” befindlichen) Thread bzw. Kontext, und eine oder mehrere weitere Interpolator-Einrichtungen (z. B. die Interpolator-Einrichtung 5b, etc.) (vorübergehend, oder dauerhaft) z. B. jeweils einem oder mehreren weiteren Threads bzw. Kontexten, z. B. momentan bereiten, aber nicht laufenden (insbesondere in einem Zustand „idle” befindlichen) Threads bzw. Kontexten, etc.
Wie im folgenden noch genauer erläutert wird, wird beim vorliegenden Ausführungsbeispiel jeweils die dem momentan laufenden (in einem Zustand „running” befindlichen) Thread bzw. Kontext zugeordnete Interpolator-Einrichtung (z. B. die Interpolator-Einrichtung 5a) (und ggf. zusätzlich auch jeweils beim o. g. Thread-Scheduling jeweils aktuell neu geladenen Threads zugeordnete Interpolator-Einrichtungen) in einen „aktivierten” Zustand (Zustand „interpolator running”) gebracht, und die Interpolator-Einrichtung(en) (z. B. die Interpolator-Einrichtung 5b) der übrigen – momentan bereiten, aber nicht laufenden – Threads bzw. Kontexts in einen „deaktivierten” Zustand (Zustand „interpolator idle”).
Im aktivierten Zustand wird – wie ebenfalls weiter unten noch genauer erläutert wird – durch die entsprechende Interpolator-Einrichtung 5a jeweils ein neuer, aktualisierter, abgeänderter Thread-Index-Wert berechnet, und der jeweils (neu) berechnete Index-Wert mittels eines entsprechenden, an einer Leitung 20 ausgegebenen Signals an eine Vergleichs-Einrichtung 1 übertragen.
Demgegenüber wird von den jeweils deaktivierten Interpolator-Einrichtungen 5b – ohne Änderung – (weiter) der jeweils zuletzt berechnete Thread-Index-Wert ausgegeben, und mittels entsprechender, über entsprechende Leitungen 21 übertragenen Signalen – ebenfalls – der Vergleichs-Einrichtung 1 zugeführt.
Die Vergleichs-Einrichtung 1 ermittelt, welche der Interpolator-Einrichtungen 5a, 5b den jeweils größten Thread-Index-Wert liefert (d. h. für welchen Thread bzw. Kontext jeweils der größte Thread-Index-Wert vorliegt).
Wie aus 3 hervorgeht, wird von der Vergleichs-Einrichtung 1 an einer Leitung 8 ein den Thread bzw. Kontext mit dem jeweils größten Thread-Index-Wert kennzeichnendes Signal „Destination Context” zur Verfügung gestellt (z. B. ein die Kontext-ID des Threads bzw. Kontextes mit dem jeweils größten Thread-Index-Wert enthaltendes Signal).
Gemäß 2 wird das von der Vergleichs-Einrichtung 1 an der Leitung 8 ausgegebene Signal „Destination Context” an den CPU Core 11 weitergeleitet, sowie – wie aus 3 ersichtlich ist – über eine Leitung 22 an einen ersten Eingang einer Komparator-Einrichtung 2, und über eine Leitung 23 an einen Zwischenspeicher bzw. ein Latch 4.
Der Zwischenspeicher bzw. Latch 4 leitet das an der Leitung 23 anliegende – die Kontext-ID des Threads mit dem jeweils grössten Thread-Index-Wert angebende – Signal „Destination Context” mit einer gewissen Verzögerung behaftet über eine Leitung 24 an einen zweiten Eingang der Komparator-Einrichtung 2 weiter.
Kommt es zu einem Wechsel beim Thread bzw. Kontext mit jeweils grösstem Thread-Index-Wert – und damit auch zu einer Änderung beim die Kontext-ID des Threads mit dem jeweils grössten Thread-Index-Wert angebenden Signal „Destination Context” –, liegt – kurzzeitig – an den Leitungen 8, 22, 23 schon ein die neue Kontext-ID kennzeichnendes Signal „Destination Context_neu” an, jedoch – aufgrund der o. g. Verzögerungswirkung des Zwischenspeichers bzw. Latches 4 – an der Leitung 24 noch ein die alte Kontext-ID kennzeichnendes Signal „Destination Context alt”.
Aufgrund des – kurzzeitigen – Unterschiedes der – über die Leitung 22, und die Leitung 24 – an den ersten und zweiten Eingang der Komparator-Einrichtung 2 angelegten Signale wird von der Komparator-Einrichtung 2 dann – kurzzeitig – an einer Leitung 7 ein einen stattgefundenen Wechsel beim Thread bzw. Kontext mit jeweils grösstem Thread-Index-Wert kennzeichnendes Signal „Context Switch Indication” ausgegeben, und – wie aus 2 hervorgeht – an den CPU Core 11 weitergeleitet.
Durch die CPU Core 11 kann dann ein entsprechender Kontext-Wechsel vollzogen werden, wobei der durch das an den Leitungen 8 ausgegebene Signal „Destination Context” angegebene Kontext dann in einen laufenden Zustand (Zustand „running”) gebracht wird, und der zuletzt laufende bzw. in einem Zustand „running” befindliche Kontext in einen nicht laufenden Zustand (insbesondere z. B. in einen Zustand „idle”).
Wie oben bereits kurz erläutert wurde, wird – insbesondere – jeweils die dem momentan laufenden (in einem Zustand „running” befindlichen) Thread bzw. Kontext zugeordnete Interpolator-Einrichtung (z. B. die Interpolator-Einrichtung 5a) in einen aktivierten Zustand gebracht.
Hierzu wird – wie aus 4 hervorgeht – in jeder Interpolator-Einrichtung 5a die an der Leitung 6 mittels des Signals „Current Context” von dem CPU Core 11 aus übertragene, den jeweils ausgeführten bzw. laufenden Thread kennzeichnende Kontext-ID in einer Vergleichseinrichtung 30 mit der – z. B. in der Vergleichseinrichtung 30 abgespeicherten – Kontext-ID des der jeweiligen Interpolator-Einrichtung 5a zugeordneten Kontextes verglichen.
Falls die den jeweils ausgeführten bzw. laufenden Thread kennzeichnende Kontext-ID gleich ist, wie die Kontext-ID des der jeweiligen Interpolator-Einrichtung 5a zugeordneten Kontextes, wird durch die Vergleichseinrichtung 30 an einer Leitung 31 ein Aktivier- bzw. Freigabe-Signal ausgegebenen, insbesondere ein Signal „Write Enable”.
Das Signal „Write Enable” wird an einen Freigabe-Eingang eines Register-Satzes 32 weitergeleitet, und an jeweils erste Eingänge entsprechender UND-Glieder 33, 34.
Hierdurch wird – wie im folgenden noch genauer erläutert wird – der Register-Satz 32 zum (Neu-)Beschreiben mit entsprechenden Werten freigegeben, und die UND-Glieder 33, 34 zur Weiterleitung entsprechender, an Leitungen 57, 58 anliegender Signale „Flush Indication” bzw. „Push Indication” an entsprechende Steuereingänge eines FIFO-Speichers 35 (FIFO = First-In-First-Out).
Wie aus 2 hervorgeht, und wie im folgenden noch genauer erläutert wird, werden von dem CPU Core 11 über entsprechende, mit der Kontext-Schedule-Vorrichtung 3 verbundene Leitungen 13, 14, 19 auf den jeweils laufenden Thread bzw. Context bezogene Signale „Interpolation Type”, „Expected Reward”, und „Stopping Time” zur Verfügung gestellt (bzw. – für den jeweils laufenden Thread bzw. Kontext – entsprechende Variablen-Werte für entsprechende – den jeweiligen Interpolations-Typ, den erwarteten Erfolg, und die Stopping Time kennzeichnende – Variablen (s. u.)).
Wie weiter unten noch genauer erläutert wird, werden die entsprechenden „Interpolation Type”-, „Expected Reward”-, und „Stopping Time”-Variablen-Werte in den dem jeweils laufenden Thread bzw. Kontext zugeordneten FIFO-Speicher 35 geladen.
Solange in dem FIFO-Speicher 35 noch keine entsprechenden Variablen-Werte gespeichert sind, solange der FIFO-Speicher 35 also in einem „leeren” Zustand ist, wird an einer Leitung 36 ein den „leeren” Zustand des FIFO-Speichers 35 kennzeichnendes Signal „Empty” ausgegeben.
Die Leitung 36 ist mit einem Steuer-Eingang eines ersten Multiplexers 37 verbunden.
Das an der Leitung 36 dem Steuer-Eingang des ersten Multiplexers 37 zugeführte Signal „Empty” führt dazu, dass entsprechende Ausgangs-Leitungen 39 des ersten Multiplexers 37 logisch mit entsprechenden – an einen Default-Register-Satz 38 angeschlossenen – Eingangs-Leitungen 40 verbunden werden, und dass die Ausgangs-Leitungen 39 des ersten Multiplexers 37 logisch von entsprechenden mit dem FIFO-Speicher 35 verbundenen Eingangs-Leitungen 41 getrennt werden.
Dies hat zur Folge, das in dem Default-Register-Satz 38 abgespeicherte Default-Werte für die o. g. Variablen „Interpolation Type”, „Expected Reward”, und „Stopping Time” (insbesondere in einem Interpolation-Typ-Default-Register 38a, einem Expected-Reward-Default-Register 38b, und einem Stopping-Time-Default-Register 38c abgespeicherte Variablen-Werte) über die Multiplexer-Eingangs-Leitungen 40, und den ersten Multiplexer 37 an die Multiplexer-Ausgangs-Leitungen 39 weitergeleitet werden.
Als Interpolation-Type-Default-, und Expected-Reward-Default-Werte können in den entsprechenden Registern 38a, 38b z. B. die dem jeweiligen Kontext bzw. Thread zugeordneten, im o. g. Kontext-Status-Array-Speicher abgespeicherten Werte abgespeichert sein; des weiteren kann als Stopping-Time-Default-Wert im entsprechenden Register 38c z. B. – fest – der Wert „1” abgespeichert sein.
Wie sich aus den Ausführungen oben, und der Darstellung gemäß 4 ergibt, liegt an einer mit einem Steuer-Eingang eines zweiten Multiplexers 42 verbundenen Leitung 43 zunächst ein Signal „Stopping Time = 0” an, das dazu führt dazu, dass entsprechende Ausgangs-Leitungen 44 des zweiten Multiplexers 42 logisch mit den o. g. Ausgangs-Leitungen 39 des ersten Multiplexers 37 verbunden werden, und dass die Ausgangs-Leitungen 44 des zweiten Multiplexers 42 logisch von weiteren im folgenden noch genauer erläuterten – Leitungen 45 getrennt werden.
Dies hat zur Folge, das die o. g. in dem Default-Register-Satz 38 abgespeicherten, an den Leitungen 39 anliegenden Default-Werte für die o. g. Variablen „Interpolation Type”, „Expected Reward”, und „Stopping Time” an den Ausgangs-Leitungen 44 des zweiten Multiplexers 42 ausgegeben werden, und in den Register-Satz 32 geschrieben werden (insbesondere der Wert der in dem Interpolation-Typ-Default-Register 38a abgespeicherten Variablen „Default Interpolation Type” in ein erstes Register 32a, der Wert der in dem Expected-Reward-Default-Register 38b abgespeicherten Variablen „Default Expected Reward” in ein zweites Register 32b, und der Wert der in dem Stopping-Time-Default-Register 38c abgespeicherten Variablen „Default Stopping Time” in ein drittes Register 32c).
Wie aus 4 weiter hervorgeht, wird ein den in das Register 32a geschriebenen (Interpolation-Type-)Wert repräsentierendes Signal über eine Leitung 46, und eine Leitung 47 einem Steuer-Eingang eines dritten Multiplexers 50 zugeführt, sowie – ebenfalls über die Leitung 46, und eine Leitung 48 – einem Steuer-Eingang eines vierten Multiplexers 51.
Des weiteren wird – wie ebenfalls aus 4 hervorgeht – das den in das Register 32a geschriebenen (Interpolation-Type-)Wert repräsentierende, an der Leitung 46 anliegende Signal über eine erste Leitung 45a der o. g. Leitungen 45 dem zweiten Multiplexer 42 zugeführt.
Ein den in das Register 32b geschriebenen (Expected-Reward-)Wert repräsentierendes Signal wird über eine Leitung 49 jeweils entsprechenden Eingängen entsprechender Expected-Reward-Variablen-Nachberechnungs-Einrichtungen 52a, 52b zugeführt, und jeweils entsprechenden ersten Eingängen entsprechender Thread-Index-Berechnungs-Einrichtungen 53a, 53b.
Des weiteren wird ein den in das Register 32c geschriebenen (Stopping-Time-)Wert repräsentierendes Signal über eine Leitung 54 jeweils entsprechenden zweiten Eingängen der entsprechenden Thread-Index-Berechnungs-Einrichtungen 53a, 53b zugeführt, und – über eine Leitung 54a – einem Eingang einer Stopping-Time-Dekrementier-Einrichtung 55.
Jede der Thread-Index-Berechnungs-Einrichtungen 53a, 53b berechnet mittels entsprechender Vorgehensweisen – insbesondere z. B. mittels entsprechender, herkömmlicher Gittin's-Index-Berechnungs-Strategien –, und basierend auf dem in dem Register 32b bzw. 32c abgespeicherten Expected-Reward- und Stopping-Time-Wert den jeweils aktuellen, dem jeweiligen Thread bzw. Kontext zuzuordnenden – an der Leitung 20 auszugebenden – Thread-Index-Wert.
Mit Hilfe des den (Interpolation-Type-)Wert repräsentierenden, an den Leitungen 46, 48 anliegenden, und dem Steuer-Eingang des vierten Multiplexers 51 zugeführten Signals kann ausgewählt werden, welcher der von den verschiedenen Thread-Index-Berechnungs-Einrichtungen 53a, 53b – jeweils basierend auf unterschiedlichen Vorgehensweisen berechnete, und an verschiedenen Leitungen 51a, 51b ausgegebene – Thread-Index-Wert an die Leitung 20 weitergeschaltet werden soll.
Wie aus 4 weiter zu entnehmen ist, berechnet jede der Expected-Reward-Variablen-Nachberechnungs-Einrichtungen 52a, 52b – passend zu den jeweiligen, durch die Thread-Index-Berechnungs-Einrichtungen 53a, 53b basierend auf entsprechenden Interpolationsvorgehensweisen berechneten Thread-Index-Werten – mittels entsprechender Vorgehensweisen (insbesondere z. B. mittels entsprechender, bei herkömmlichen Gittin's-Index-Berechnungs-Strategien angewandten Vorgehensweisen), und basierend auf dem in dem Register 32b abgespeicherten Expected-Reward-Wert jeweils entsprechende, angepasste Werte für die o. g. Expected-Reward-Variable.
Mit Hilfe des den (Interpolation-Type-)Wert repräsentierenden, an den Leitungen 46, 47 anliegenden, und dem Steuer-Eingang des dritten Multiplexers 50 zugeführten Signals kann ausgewählt werden, welcher der von den verschiedenen Expected-Reward-Variablen-Nachberechnungs-Einrichtungen 52a, 52b jeweils basierend auf unterschiedlichen Vorgehensweisen berechnete, und an verschiedenen Leitungen 50a, 50b ausgegebene, angepasste Expected-Reward-Variablen-Wert an eine zweite Leitung 45b der o. g. Leitungen 45, d. h. an den zweiten Multiplexer 42 weitergeschaltet werden soll.
Mit Hilfe der Stopping-Time-Dekrementier-Einrichtung 55 wird der dieser über die Leitung 54a jeweils zugeführte (Stopping-Time-)Wert dekrementiert (insbesondere, indem vom Stopping-Time-Wert der Wert „1” subtrahiert wird), und ein den dekrementierten Stopping-Time-Wert repräsentierendes Signal über eine Leitung 55a an eine Vergleichseinrichtung 56 weitergeleitet, und über eine dritte Leitung 45c der o. g. Leitungen 45 an den zweiten Multiplexer 42.
Sobald – wie oben erläutert – über die Leitungen 13, 14, 19 die entsprechenden „Interpolation Type”-, „Expected Reward”-, und „Stopping Time”-Variablen-Werte in den dem jeweils laufenden Thread bzw. Kontext zugeordneten FIFO-Speicher 35 geladen wurden, der FIFO-Speicher 35 also nicht mehr in einem „leeren” Zustand ist, wird an der Leitung 36 kein Signal „Empty” mehr ausgegeben.
Dies hat zur Folge, dass die o. g. Ausgangs-Leitungen 39 des ersten Multiplexers 37 dann logisch mit den entsprechenden mit dem FIFO-Speicher 35 verbundenen Eingangs-Leitungen 41 verbunden werden (und logisch von den – mit dem Default-Register-Satz 38 verbundenen – Eingangs-Leitungen 40 getrennt werden).
Aufgrund des bis dahin unveränderten Zustands des am Steuer-Eingang des zweiten Multiplexers 42 anliegenden Signals bleiben weiterhin die Ausgangs-Leitungen 44 des zweiten Multiplexers 42 logisch mit den o. g. Ausgangs-Leitungen 39 des ersten Multiplexers 37 verbunden, und bleiben weiterhin die Ausgangs-Leitungen 44 des zweiten Multiplexers 42 logisch von den o. g. weiteren Leitungen 45 getrennt.
Dies hat zur Folge, dass die o. g. in dem FIFO-Speicher abgespeicherten, von dem CPU Core 11 gelieferten Werte für die o. g. Variablen „Interpolation Type”, „Expected Reward”, und „Stopping Time” über die Multiplexer 37, 42 an die Ausgangs-Leitungen 44 des zweiten Multiplexers 42 weitergeschaltet werden, und – neu – in den Register-Satz 32 geschrieben werden (insbesondere der in dem FIFO-Speicher 35 abgespeicherte Interpolation-Typ-Wert in das erste Register 32a, der in dem FIFO-Speicher 35 abgespeicherte Expected-Reward-Wert in das zweite Register 32b, und der im FIFO-Speicher 35 abgespeicherte Stopping-Time-Wert in das dritte Register 32c).
Auf Grundlage der geänderten, in den Registern 32b bzw. 32c abgespeicherten Expected-Reward- und Stopping-Time-Werte werden durch die o. g. Thread-Index-Berechnungs-Einrichtungen 53a, 53b jeweils entsprechend geänderte, aktualisierte Thread-Index-Werte berechnet, und einer dieser Werte – entsprechend der über den vierten Multiplexer 51 getroffenen Auswahl – als geänderter, dem jeweiligen Thread bzw. Kontext zuzuordnender Thread-Index-Wert an der Leitung 20 ausgegeben.
Entsprechend ähnlich werden auch durch die Expected-Reward-Variablen-Nachberechnungs-Einrichtungen 52a, 52b basierend auf dem in dem Register 32b abgespeicherten, geänderten Expected-Reward-Wert jeweils entsprechend geänderte, angepasste Expected-Reward-Variablen-Werte berechnet, und einer dieser Werte – entsprechend der über den dritten Multiplexer 50 getroffenen Auswahl – über die Leitung 45b dem zweiten Multiplexer 42 zugeführt.
Aufgrund der o. g. Änderung des Werts der im Register 32c abgespeicherten Stopping-Time-Variablen (insbesondere, da diese nicht mehr entsprechend dem o. g. Stopping-Time-Default-Wert = 1, bzw. nach erfolgter Dekrementierung = 0 ist) liegt an der mit dem Steuer-Eingang des zweiten Multiplexers 42 verbundenen Leitung 43 dann – zunächst – kein Signal „Stopping Time = 0” mehr an. Dies hat zur Folge, dass entsprechende Ausgangs-Leitungen 44 des zweiten Multiplexers 42 nicht mehr logisch mit den o. g. Ausgangs-Leitungen 39 des ersten Multiplexers 37 verbunden sind, sondern mit den o. g. Leitungen 45.
Dies hat zur Folge, dass der an der o. g. Leitung 45c anliegende – gegenüber dem an der Leitung 54a anliegenden, in dem dritten Register 32c abgespeicherte Stopping-Time-Variablen-Wert durch die Stopping-Time-Dekrementier-Einrichtung 55 entsprechend dekrementierte – Variablen-Wert über den zweiten Multiplexer 42 dem dritten Register 32c zugeführt, und dort abgespeichert wird.
Entsprechend ähnlich wird auch der an der o. g. Leitung 45b anliegende, von der durch den dritten Multiplexer 50 ausgewählten Expected-Reward-Variablen-Nachberechnungs-Einrichtung 52a, 52b gelieferte, angepasste Expected-Reward-Variablen-Wert über den zweiten Multiplexer 42 dem zweiten Register 32b zugeführt, und dort abgespeichert, und der an der Leitung 45a anliegende Wert der „Interpolation Type”-Variable über den Multiplexer 42 an das erste Register 32a (zurück-)geleitet, und (erneut) dort abgespeichert.
Auf Grundlage der – erneut – geänderten, in den Registern 32b bzw. 32c abgespeicherten Expected-Reward- und Stopping-Time-Werte werden durch die o. g. Thread-Index-Berechnungs-Einrichtungen 53a, 53b erneut jeweils entsprechend geänderte, aktualisierte Thread-Index-Werte berechnet, und einer dieser Werte – entsprechend der über den vierten Multiplexer 51 getroffenen Auswahl – als geänderter, dem jeweiligen Thread bzw. Kontext zuzuordnender Thread-Index-Wert an der Leitung 20 ausgegeben.
Entsprechend ähnlich werden auch – erneut – durch die Expected-Reward-Variablen-Nachberechnungs-Einrichtungen 52a, 52b basierend auf dem in dem Register 32b abgespeicherten, erneut geänderten Expected-Reward-Wert jeweils entsprechend geänderte, angepasste Expected-Reward-Variablen-Werte berechnet, usw.
Dabei wird – wie aus 4 hervorgeht – durch die Stopping-Time-Dekrementier-Einrichtung 55 der dieser über die Leitung 54a jeweils zugeführte (Stopping-Time-)Wert immer weiter dekrementiert (insbesondere, indem vom zuletzt geltenden Stopping-Time-Wert der Wert „1” subtrahiert wird), bis durch die Vergleichseinrichtung 56 ermittelt wird, dass der Stopping-Time-Wert den Wert Null erreicht hat.
Daraufhin wird von der Vergleichseinrichtung 56 (wieder) an der mit dem Steuer-Eingang des zweiten Multiplexers 42 verbundenen Leitung 43 ein Signal „Stopping Time = 0” angelegt, das dazu führt, dass die Ausgangs-Leitungen 44 des zweiten Multiplexers 42 logisch (wieder) mit den o. g. Ausgangs-Leitungen 39 des ersten Multiplexers 37 verbunden werden, und dass die Ausgangs-Leitungen 44 des zweiten Multiplexers 42 logisch (wieder) von den Leitungen 45 getrennt werden.
Dies hat zur Folge, das die o. g. in dem FIFO-Speicher abgespeicherten (bzw. neu abgespeicherten), von dem CPU Core 11 (ggf. neu) gelieferten Werte für die o. g. Variablen „Interpolation Type”, „Expected Reward”, und „Stopping Time” über den ersten Multiplexer 37, und den zweiten Multiplexer 42 an den Register-Satz 32 weitergeleitet, und in den entsprechenden Registern 32a, 32b, 32c abgespeichert werden können.
Die o. g. Variable „Expected Reward” repräsentiert – entsprechend der (aus „Multi-Armed-Bandit-Problemen” bekannten) Theorie der Gittin'schen Indizes – die Güte des durch die Abarbeitung des jeweiligen Threads erreichten Erfolgs, z. B. die Grösse des nach der Abarbeitung des Threads freiwerdenden Speicherplatzes (also die jeweils zu optimierende Grösse), und die o. g. Variable „Stopping Time” einen sich aus der Theorie der Gittin'schen Indizes ergebenden (Wichtungs-)Parameter.
Zum Laden entsprechender Werte für die o. g. Variablen „Interpolation Type”, „Expected Reward”, und „Stopping Time” in den FIFO-Speicher 35 kann durch den CPU Core 11 – wie in 2 und 4 gezeigt ist – an der Leitung 57 das o. g. Signal „Push Indication” ausgegeben werden (woraufhin die entsprechenden, an den Leitungen 13, 14, 19 anliegenden Variablen-Werte im FIFO-Speicher 35 abgespeichert werden).
Beispielsweise bei – z. B. bei Auftreten eines Fehlers im CPU Core 11 durchzuführenden – „Sprüngen” können mittels eines durch den CPU Core 11 an der Leitung 58 ausgegebenen Signals „Flush Indication” die bisher im FIFO-Speicher 35 gespeicherten Werte für die o. g. Variablen „Interpolation Type”, „Expected Reward”, und „Stopping Time” (komplett) wieder gelöscht werden, woraufhin mittels eines an der Leitung 57 ausgegebenen Signals „Push Indication” erneut wieder – entsprechend den dann an den Leitungen 13, 14, 19 anliegenden Signalen – entsprechende Werte für die Variablen „Interpolation Type”, „Expected Reward”, und „Stopping Time” im FIFO-Speicher 35 abgespeichert werden können. Die o. g. Thread-Index-Werte entsprechen – zur Optimierung der jeweiligen Kostenfunktion verwendeten, entsprechend der „Multi-Armed-Bandit-Theorie” berechneten – Werten (wobei bei der Lösung des Optimierungs-Problems insbesondere – wie oben angedeutet – eine Thread-Umschaltung ohne Zyklenverlust vorausgesetzt wird). Bei – geringfügiger – Verletzung dieser Bedingung ergeben sich entsprechend – in den meisten Fällen gering – von einer optimalen Lösung abweichende Werte.

Claims

Einrichtung (3) zur Verwendung bei einem Scheduling, bei welchem ein Scheduling für von einem Multithreaded (MT)-Prozessor (11) abzuarbeitende Threads durchgeführt wird dadurch gekennzeichnet, dass die Einrichtung (3) eine Vorrichtung (1) aufweist zum Vergleichen von den Threads zugeordneten Index-Variablen.
Einrichtung (3) nach Anspruch 1, bei welcher die Vergleichs-Vorrichtung (1) so ausgestaltet und eingerichtet ist, dass mit der Vergleichs-Vorrichtung (1) derjenige Thread ermittelt wird, dessen Index-Variable den höchsten Wert aufweist.
Einrichtung (3) nach Anspruch 1, bei welcher die Vergleichs-Vorrichtung (1) so ausgestaltet und eingerichtet ist, dass mit der Vergleichs-Vorrichtung (1) derjenige Thread ermittelt wird, dessen Index-Variable den niedrigsten Wert aufweist.
Einrichtung (3) nach Anspruch 2 oder 3, welche eine Vorrichtung (2, 4) aufweist zum Erzeugen eines Thread-Wechsel-Signals (Context-Switch-Indication), wenn durch die Vergleichs-Vorrichtung (1) ermittelt wird, dass ein Wechsel beim Thread mit höchstem oder niedrigstem Index-Variablen-Wert stattfindet.
Einrichtung (3) nach einem der Ansprüche 2 bis 4, welche eine Hardware-Schaltung (5a, 52a, 53a), insbesondere eine Hardware-Interpolator-Schaltung (52a, 53a) aufweist zum Ändern des Werts der Index-Variable eines im aktiven Zustand befindlichen Threads.
Vorrichtung zum Durchführen eines Schedulings für mehrere von einem Multithreaded (MT)-Prozessor (11) abzuarbeitende Threads, mit einer Einrichtung zur Auswahl des jeweils abzuarbeitenden Threads in Abhängigkeit von den Threads zugeordneten Index-Variablen, und einer Interpolationsschaltung (5a) zur fortlaufenden Neuberechnung des Werts einer einem ausgewählten Thread zugeordneten Index-Variablen im Verlauf der Abarbeitung des ausgewählten Threads, und einer Einrichtung zum Unterbrechen der Abarbeitung des ausgewählten Threads, wenn die Index-Variable des ausgewählten Threads nicht mehr den höchsten Wert aufweist.
Vorrichtung zum Durchführen eines Schedulings für mehrere von einem Multithreaded (MT)-Prozessor (11) abzuarbeitende Threads, mit einer Einrichtung zur Auswahl des jeweils abzuarbeitenden Threads in Abhängigkeit von den Threads zugeordneten Index-Variablen, und einer Einrichtung (5a) zur fortlaufenden Neuberechnung des Werts einer Index-Variablen im Verlauf der Abarbeitung eines Threads.