DE112004002296B4 - Anwenderprogrammierbares Multithreading mit geringem Overhead - Google Patents

Anwenderprogrammierbares Multithreading mit geringem Overhead Download PDF

Info

Publication number
DE112004002296B4
DE112004002296B4 DE112004002296T DE112004002296T DE112004002296B4 DE 112004002296 B4 DE112004002296 B4 DE 112004002296B4 DE 112004002296 T DE112004002296 T DE 112004002296T DE 112004002296 T DE112004002296 T DE 112004002296T DE 112004002296 B4 DE112004002296 B4 DE 112004002296B4
Authority
DE
Germany
Prior art keywords
thread
switch
trigger
helper
command
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
DE112004002296T
Other languages
English (en)
Other versions
DE112004002296T5 (de
Inventor
Perry San Jose Wang
Hong Santa Clara Wang
John San Jose Shen
Ashok Santa Clara Seshadri
Anthony Dublin Mah
William Fort Collings Greene
Ravi San Jose Chandra
Piyush Pleasanton Desai
Steve Shih-wei San Jose Liao
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tahoe Research Ltd
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Publication of DE112004002296T5 publication Critical patent/DE112004002296T5/de
Application granted granted Critical
Publication of DE112004002296B4 publication Critical patent/DE112004002296B4/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/30076—Arrangements for executing specific machine instructions to perform miscellaneous control operations, e.g. NOP
    • G06F9/3009—Thread control instructions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline, look ahead
    • G06F9/3836—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
    • G06F9/3851—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution from multiple instruction streams, e.g. multistreaming
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/542—Event management; Broadcasting; Multicasting; Notifications

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Advance Control (AREA)
  • Executing Machine-Instructions (AREA)
  • Memory System Of A Hierarchy Structure (AREA)
  • Image Processing (AREA)

Abstract

Prozessor mit einem Threadwechsel-Handler, einem Trigger-Antwortmechanismus und einem Datencachespeicher,
a) wobei der Trigger-Antwortmechanismus auf das Empfangen eines Markierungsbefehls während der Ausführung eines Hauptthreads in einen Erfassungszustand übergeht, in dem er eine asynchrone Threadwechsel-Antwort erzeugt, wenn beim nachfolgenden Ausführen eines Ladebefehls ein Cache-Miss im Datencachespeicher gemeldet wird;
b) wobei die Threadwechsel-Antwort vom Threadwechsel-Handler empfangen wird, der daraufhin die Ausführung des Hauptthreads aussetzt, die Befehlszeigeradresse für den aktuellen Thread speichert und einen Kontextwechsel initiiert, so dass ein Helferthread asynchron gespawnt wird;
c) wobei der Threadwechsel-Handler die Anfangs-Befehlszeigeradresse des Helferthreads von einem zuvor bezeichneten Speicherplatz oder aus einem Register bezieht;
d) wobei der Hauptthread weiterhin auf die durch den Ladebefehl angeforderten Daten wartet und nach Abschluss der Ausführung des Helferthreads die Steuerung wieder aufnimmt.

Description

  • ALLGEMEINER STAND DER TECHNIK
  • TECHNISCHES GEBIET
  • Die vorliegende Offenbarung betrifft allgemein Informationsverarbeitungssysteme und spezifischer das Spawnen (Hervorbringen) und Verwalten von gleichzeitig ablaufenden Threads (Teilprozessen) mit geringem Overhead.
  • ALLGEMEINER STAND DER TECHNIK
  • Ein Ansatz, der zum Verbessern der Prozessorleistung eingesetzt wurde, ist als „Multithreading” (Mehrfädigkeit) bekannt. Beim Software-Multithreading wird ein Befehlsstrom in mehrere Befehlsströme aufgeteilt, die parallel ausgeführt werden können. In einem Ansatz können mehrere Prozessoren in einem Mehrprozessorsystem jeweils gleichzeitig an einem der mehreren Threads arbeiten.
  • In einem anderen Ansatz, als „Time-Slice-Multithreading” (Zeitscheiben-Multithreading) bekannt, wechselt ein einziger Prozessor nach einer festgelegten Zeitspanne zwischen Threads. In noch einem anderen Ansatz wechselt ein einziger Prozessor beim Eintreten eines Triggerereignisses (Auslöseereignisses), wie einem „Cache-Miss” (Cache-Fehltreffer) mit langer Latenzzeit, zwischen Threads. Der letztere Ansatz ist als „Switch-On-Event-Multithreading” (Multithreading mit Wechseln bei Ereignis) bekannt.
  • Herkömmlicherweise ist das Triggerereignis für Switch-On-Event-Multithreading festverdrahtet. Es wäre jedoch für den Programmierer oder Anwender wünschenswert, ein beliebiges einer Vielfalt an auslösenden Ereignissen zum Auslösen eines Threadwechsels auf einem einzigen Prozessor zu spezifizieren. Ausführungsformen des Verfahrens und der Vorrichtung, die hierin offenbart sind, befassen sich mit diesem und anderen Anliegen, die mit Multithreading zusammenhängen.
  • Aus der Druckschrift US 6,272,520 B1 ist ein Verfahren zum Bestimmen eines Zustandes für einen Thread-Switch bekannt. Dazu sind erste und zweite Scoreboard-Bits für jedes Register in einem Registerfile vorgesehen. Das erste Scoreboard-Bit wird gesetzt, wenn ein Ladevorgang Daten an das Register übergibt. Das zweite Scoreboard-Bit wird gesetzt, wenn der Ladevorgang in einem ausgewählten Prozessor-Cache fehlschlägt. Wenn eine Leseanweisung von einem Register defektiert wird, dessen erstes und zweites Scoreboard-Bit gesetzt sind, wird ein Thread-Switch veranlasst.
  • Die Aufgabe der vorliegenden Erfindung besteht darin, die durch Cache-Misses hervorgerufenen Verzögerungen einzuschränken oder auszuschließen. Dazu sieht die Erfindung einen Prozessor gemäß Anspruch 1 bzw. ein Verfahren gemäß Anspruch 4 vor. Bevorzugte Ausführungsformen sind in den Unteransprüchen dargelegt.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Die vorliegende Erfindung kann mit Bezugnahme auf die folgenden Zeichnungen verstanden werden, in denen gleiche Elemente durch gleiche Ziffern angegeben sind. Diese Zeichnungen sollen nicht einschränkend sein, sondern werden bereitgestellt, um ausgewählte Ausführungsformen eines Verfahrens, einer Vorrichtung und eines Systems zum Bereitstellen von gleichzeitig ablaufenden Helferthreads mit geringem Overhead zu veranschaulichen.
  • 1 ist ein Blockdiagramm mindestens einer Ausführungsform eines Trigger-Antwortmechanismus.
  • 2 ist ein Zustandsdiagramm, das die Zustände mindestens einer Ausführungsform eines Trigger-Antwortmechanismus veranschaulicht.
  • 3 ist eine Zeitachse, die das asynchrone Spawnen eines Helferthreads zum Durchführen eines Vorauslesens (Prefetching) von Daten während einer Blockierung aufgrund eines Cache-Miss beim Hauptthread veranschaulicht.
  • 4 ist ein Datenflußdiagramm, das das Speichern und Wiederherstellen von Kon textinformationen während zwei Probekontextwechseln veranschaulicht.
  • 5 ist ein Ablaufdiagramm, das ein Verfahren zum Bereitstellen von anwenderprogrammierbarem Multithreading mit geringem Overhead veranschaulicht.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Hierin sind ausgewählte Ausführungsformen eines Systems, einer Vorrichtung und eines Verfahrens zum anwenderprogrammierbaren Spawnen eines oder mehrerer gleichzeitig ablaufender Helferthreads mit geringem Overhead beschrieben. In der folgenden Beschreibung wurden zahlreiche spezifische Einzelheiten, wie Prozessortypen, Arten von Prozessorereignissen, Methoden zum Erfassen von Prozessorereignissen und Steuerungsablaufabwicklung dargelegt,
    um ein vollständigeres Verständnis der vorliegenden Erfindung bereitzustellen. Ein Fachmann wird jedoch zu schätzen wissen, daß die Erfindung ohne derartige spezifische Einzelheiten ausgeübt werden kann. Darüber hinaus wurden einige wohl bekannte Strukturen, Schaltkreise und dergleichen nicht ausführlich dargestellt, um zu vermeiden, daß die vorliegende Erfindung unnötigerweise verschleiert wird.
  • In Prozessoren, die Unterstützung von Multithreading durch die Hardware bereitstellen, wie jenen, die einen Ansatz unterstützen, der als „simultanes Multithreading” („SMT”) bezeichnet wird, wird bewirkt, daß es für Betriebssysteme und Anwenderprogramme den Anschein hat, als würde es sich bei einem einzigen physikalischen Prozessor um mehrere logische Prozessoren handeln. Beim SMT können mehrere Threads aktiv sein und gleichzeitig auf einem einzigen Prozessor ohne Wechsel ablaufen. Das heißt, jeder logische Prozessor pflegt einen kompletten Satz des Architekturzustands, viele andere Betriebsmittel (Ressourcen) des physikalischen Prozessors, wie Cachespeicher, Ausführungseinheiten, „Branch Predictoren” (Einrichtungen zur Sprungvorhersage), Steuerlogik und Busse, werden jedoch gemeinsam genutzt. Befehle aus den mehreren Threads können gleichzeitig ablaufen, wobei mindestens ein Befehl aus jedem Thread innerhalb desselben Zeitrahmens ausgeführt wird.
  • Bei Prozessoren, die die Hardwarefunktionen, die SMT unterstützen, nicht bereitstellen, kann es dennoch wünschenswert sein, Multithreading zu implementieren, so daß ein zweiter Thread Ausführungsressourcen des Prozessors einsetzen kann, wenn ein Hauptthread ein Triggerereignis angetroffen hat, wie einen Befehl mit langer Latenzzeit. Wenn beispielsweise ein Prozessor einen Ladebefehl ausführt, der einen Cache-Miss verursacht, kann ein zweiter Thread gespawnt werden, um ein Vorauslesen (Prefetching) von Daten für einen künftigen, erwarteten Cache-Miss des ersten Threads während des Zeitraums durchzuführen, in dem der erste Thread latent ist, während er darauf wartet, daß Ladedaten abgerufen werden.
  • 1 ist ein Blockdiagramm, das einen Prozessor 101 darstellt, der virtuelle Multithreading-Hardware zum Bereitstellen von anwenderprogrammierbarem Multithreading mit geringem Overhead enthält. Das heißt, der Prozessor 101 stellt asymmetrisches Multithreading auf Anwenderebene mit verringerter Kontextgröße für den zusätzlichen Thread bereit. Im Gegensatz zu Prozessoren, die herkömmliches Switch-On-Event-Multithreading unterstützen, ermöglicht der in 1 dargestellte Prozessor 101, daß ein oder mehrere vom Anwender spezifizierte Triggerereignisse ein Spawnen eines Helferthreads bewirken.
  • 1 veranschaulicht, daß die virtuelle Multithreading-Hardware des Prozessors 101 einen Trigger-Antwortmechanismus 120 und einen Threadwechsel-Handler (ein Threadwechsel-Bearbeitungsprogramm) 130 enthält. Der Threadwechsel-Handler 130 speichert bestimmte minimale Informationen zum Architekturzustand nach einem Kontextwechsel zu oder von einem Thread mit geringem Overhead und stellt diese wieder her. Der Trigger-Antwortmechanismus 120 bestimmt, daß ein vom Anwender definiertes Threadwechselkriterium erfüllt worden ist und erzeugt eine entsprechende Antwort, um zu bewirken, daß der gewünschte Threadwechsel erfolgt.
  • Das vom Prozessor 101 unterstützte Multithreading-Schema ist zumindest in dem Sinne asymmetrisch, daß die für Helferthreads gespeicherten Kontextinformationen viel kleiner als die für den Hauptthread gepflegten Kontextinformationen sind. Der Umfang der für einen Threadwechsel gespeicherten Kontextinformationen wird als „Gewicht” eines Kontextwechsels bezeichnet. Bei mindestens einer Ausführungsform ist das Gewicht des Kontextwechsels direkt programmierbar. Das heißt, das Ausmaß des Architekturzustands, der in der Warteschlange 104 gespeichert werden soll, kann über die Befehlsregister 150 programmiert werden. Diese Programmierbarkeit des Kontextgewichts steht im Kontrast zu herkömmlichem Switch-On-Event-Multithreading.
  • Wie hierin verwendet, soll der Ausdruck „Helfer”-Thread einen Thread umfassen, der gleichzeitig mit dem Hauptthread abläuft. Wie hierin verwendet, zeigt „gleichzeitig” an, daß beide Threads zur selben Zeit aktiv sind, insofern daß Betriebsmittel eines Prozessorsystems gleichzeitig Arbeit für jeden Thread durchführen. In der Regel führt ein Helferthread Arbeit im Voraus durch, von der erwartet wird, daß der Hauptthread sie zu einem späteren Zeitpunkt im Befehlsstrom des Hauptthreads einsetzt. Ein Helferthread kann gespawnt werden, wenn der Hauptthread ein Triggerereignis erfährt, das bewirkt, daß der Hauptthread eine Blockierung durchmacht, wodurch Ausführungsressourcen des Prozessors freigegeben werden. Während ein Betriebsmittel, wie ein Speichersystem, die Verarbeitung für den Hauptthread (wie beispielsweise das Abrufen von Ladedaten vom Speicher in einen Cachespeicher) durchführt, können andere Ausführungsressourcen dazu genutzt werden, gleichzeitig Befehle für den Helferthread zu verarbeiten.
  • Die Ausführung eines Helferthreads kann beispielsweise darin resultieren, daß Daten in einen Datencachespeicher eingestellt werden, so daß ein künftiger Cache-Miss im Hauptthread vermieden werden kann. Bei mindestens einer anderen Ausführungsform kann der Helferthread dazu genutzt werden, Befehlsabrufvorgänge in einen Befehlscachespeicher durchzuführen, der vom Hauptthread genutzt wird.
  • Der Ausdruck „Helfer”-Thread wird folglich im gesamten Text dieser Offenbarung dazu verwendet, einen gleichzeitig ablaufenden Thread mit geringem Overhead zu bezeichnen, der als Antwort auf eine vom Anwender definierte Triggerbedingung gespawnt wurde. Es versteht sich, daß der gespawnte Thread bei zumindest einigen Ausführungsformen Arbeit durchführen kann, die keinen Bezug zu der Arbeit des Hauptthreads hat. Ein solcher Thread, der als Antwort auf eine vom Anwender definierte Triggerbedingung gespawnt wurde, umfaßt einen geringen Overhead in Bezug auf den Hauptthread und läuft ab, während auch der Hauptthread aktiv ist (obgleich der Hauptthread während der gesamten oder einem Teil der Ausführung des gespawnten Threads blockiert werden kann). Bei solchen Ausführungsformen führt der gespawnte Thread jedoch Arbeit aus, die keinen Bezug zu der Arbeit des Hauptthreads hat. Der Ausdruck „Helfer”-Thread, wie hierin verwendet, umfaßt auch solche Threads.
  • 1 veranschaulicht, daß der Trigger-Antwortmechanismus 120 als Eingabe Dateninformationen von Prozessorereigniszählern 110 empfangen kann. Auf Grundlage von vom Anwender eingegebenen Werten in einer aktiven Bank von Trigger-Antwortregistern 115 bestimmt der Trigger-Antwortmechanismus 120, ob eine Antwort auf Grundlage des Inhalts der Ereigniszählerregister 110 autorisiert ist. Wenn dies der Fall ist, kann der Trigger-Antwortmechanismus 120 eine synchrone Antwort oder eine nichtsynchrone Antwort erzeugen.
  • 1 veranschaulicht, daß der Trigger-Antwortmechanismus 102 mindestens eine Bank von anwenderprogrammierbaren Trigger-Antwortregistern 115 enthält. Bei der dargestellten Ausführungsform werden n Sätze (oder „Bänke”) von Trigger-Antwortregistern 115a–115n bereitgestellt, wobei nur ein Satz zu einer beliebigen gegebenen Zeit aktiv ist. Die Anzahl von Registern in der Bank 115 zeigt die Anzahl von Bedingungen an, die vom Anwender beim Spezifizieren der Triggerbedingung zum Spawnen eines Threads mit geringem Overhead genutzt werden können.
  • Zum Beispiel kann jedes Register ein Prozessorereignis wiedergeben, wie eine Zykluszahl, einen Cache-Miss, einen Befehlsoperationscode usw. Diese Trigger-Antwortregister 115 unterstützen zusammen mit den Ereigniszählerregistern 110 eine robuste Programmierbarkeit, indem sie Anwenderzugriff auf mehrere elementare Ereignisse bereitstellen, die ein Anwender dazu nutzen könnte, ein spezifisches asynchrones Triggerereignis zu formulieren. Die „Rohereignisse”, die in den Triggerregistern 110 verfolgt werden, können von einem Anwender für sich oder zusammen mit einem oder mehreren anderen „Rohereignissen” dazu genutzt werden, eine Triggerbedingung (in der Trigger-Antwortregisterbank 115 dargelegt) für das Spawnen eines Helferthreads zu spezifizieren. Die Triggerereignisse können synchrone oder asynchrone Ereignisse sein und können Architektur- oder Mikroarchitektur-Prozessorereignisse sein.
  • Die vom Trigger-Antwortmechanismus 120 erzeugte Antwort kann eine synchrone Antwort oder eine asynchrone Antwort sein. Hinsichtlich einer synchronen Antwort kann der Threadwechsel-Handler 130 einen Threadwechsel als Antwort auf einen bestimmten Befehl in der Befehlpipeline des Hauptthreads durchführen. Bei einem solchen Vorgang wird der Threadwechsel als synchron betrachtet, da er direkt einem spezifischen Befehl im Befehlsstrom des Hauptthreads entspricht. Bei einer solchen Ausführungsform wird der Threadwechsel voraussichtlich ausgelöst, wenn der Trigger-Antwortmechanismus 120 erkennt, daß ein Operationscodeereigniszähler 110 anzeigt, daß ein bestimmter Operationscode angetroffen wurde. Bei mindestens einer Ausführungsform kann der Operationscode einem Befehl entsprechen, der den Prozessorzustand nicht anderweitig ändert. Zum Beispiel kann eine Leeranweisung mit einem spezifischen Wert im konstanten Feld als ein Triggerbefehl behandelt werden. (Es sollte beachtet werden, daß der konstante Wert sich vom konstanten Wert, der zum Markieren von Befehlen genutzt wird – im Folgenden erörtert –, unterscheiden kann.)
  • Bei mindestens einer Ausführungsform stellt der in 1 dargestellte Prozessor 101 Unterstützung von „Trigger”-Befehlen durch die Architektur bereit, die dem Anwender mehrere Befähigungen zur Threadverwaltung liefern. Triggerbefehle werden zum Durchführen der folgenden Funktionen unterstützt: Erstellung eines Threads, Zerstörung eines Threads, Aussetzen eines Threads und Wiederaufnahme eines Threads. Jeder dieser Typen von „Trigger”-Befehlen weist die folgenden Charakteristika auf. Erstens hat der Befehl keinen Nebeneffekt auf den Prozessorzustand. Zweitens wird der Operationscode des Befehls von mindestens einem der Ereigniszählerregister 110 als ein Triggerbefehl erkannt, für den vom Trigger-Antwortmechanismus eine synchrone Antwort erzeugt werden sollte.
  • Wenn ein solcher Triggerbefehl die Ausführungsstufe einer Ausführungspipeline erreicht, kann der Operationscode für den Befehl erfaßt und von einem Operationscodeereigniszählerregister 110 gemeldet werden. Dies kann bewirken, daß der Trigger-Antwortmechanismus 120 eine synchrone Antwort an den Threadwechsel-Handler 130 sendet, die anzeigt, daß ein Threadwechsel autorisiert ist, ungeachtet des Zustands jeglicher anderer Prozessorereignisse. Bei einer solchen Ausführungsform markiert der Threadwechsel-Handler 130 die Rückkehrbefehlszähleradresse („IP”-Adresse) als die Befehlszähleradresse für den auslösenden Befehl. Der Wechsel-Handler erhöht den Wert der Rückkehrbefehlszähleradresse und speichert die Rückkehr-IP-Adresse in der Auftragsschlange 140. Ein Fachmann wird erkennen, daß der Wert der Rückkehr-IP-Adresse im Voraus vor der Speicherung in der Warteschlange 140 erhöht werden kann oder im Nachhinein erhöht werden kann, nachdem der Wert aus der Warteschlange 140 abgerufen wurde.
  • Die Auftragsschlange 140 kann eine beliebige Hardwarespeicherstruktur sein. Bei mindestens einer Ausführungsform ist die Auftragsschlange 140 im Speicher implementiert. Bei mindestens einer anderen Ausführungsform ist die Auftragsschlange 140 als ein oder mehrere Register implementiert. Demgemäß kann die Rückkehr-IP-Adresse in einem Speicherplatz oder in einem Register gespeichert werden.
  • Im Gegensatz zu der oben erörterten synchronen Antwort kann der Trigger-Antwortmechanismus 120 anstatt dessen eine asynchrone Antwort erzeugen. Das heißt, die asynchrone Antwort, die anzeigt, daß ein Threadwechsel autorisiert ist, kann auf Prozessorereignissen basieren und ist von dem Befehl unabhängig, der für den aktuellen Thread ausgeführt wird. Bei mindestens einer Ausführungsform bestimmt der Trigger-Antwortmechanismus 120 auf die folgende Art und Weise, ob eine asynchrone Antwort autorisiert ist.
  • Die Prozessorereigniszähler 110 verfolgen Bedingungen, die vom Benutzer beim Spezifizieren der Triggerbedingung zum Spawnen eines Threads mit geringem Overhead genutzt werden können. Zum Beispiel kann jedes Register ein „Roh”-Prozessorereignis wiedergeben, wie eine Zykluszahl, einen Cache-Miss, einen Befehlsoperationscode usw. Die Ereigniszähler 110 können als Zählerregister zum Zählen der verschiedenen „Roh”-Prozessorereignisse implementiert werden. Ein Ereigniszählerregister 110 kann auf eine Zahl im Bereich des Ereigniszählerregisters 110 initialisiert werden, in Anbetracht der Bitgröße des Registers 110.
  • Der Trigger-Antwortmechanismus 120 kann darauf programmiert werden, ein Überlaufsignal vom Triggerregister 110 zu erfassen und das Signal entsprechend zu verarbeiten. Wenn beispielsweise ein bestimmtes Ereigniszählerregister 110 einen L3-Cache-Miss erfaßt, kann das Zählerregister 110 auf einen Wert initialisiert werden, der um Eins niedriger als der Überlaufwert ist. In einem solchen Fall wird ein Überlaufwert für den Zähler 110 beim ersten Eintreten eines L3-Cache-Miss erzeugt. Ein solches Eintreten kann vom Trigger-Antwortmechanismus 120 erfaßt werden und dieser kann darauf reagieren.
  • Ein Anwender kann den bestimmten Zustand der Ereigniszählerregister 110 programmieren, der einen Threadwechsel auslösen wird. Das heißt, der Anwender kann einen speziellen Markierungsbefehl zum Programmieren der Werte der Trigger-Antwortregister 115 einsetzen. Bei mindestens einer Ausführungsform ist der Markierungsbefehl eine Leeranweisung mit einem bestimmten konstanten Wert. Der Anwender kann diesen Befehl in einem Anwenderprogramm einsetzen, das vom Prozessor 101 ausgeführt werden soll. Wenn der Markierungsbefehl des Anwenderprogramms die Ausführungsstufe einer Ausführungspipeline für den Prozessor 101 erreicht, werden die Trigger-Antwortregister 115 entsprechend modifiziert. Dieser Vorgang setzt den Trigger-Antwortmechanismus 120 effektiv auf „Beobachtung”, um auf das vom Anwender spezifizierte, gewünschte Threadwechsel-Triggerereignis zu überwachen.
  • Bei mindestens einer Ausführungsform stellt der Trigger-Antwortmechanismus 120 dem Threadwechsel-Handler 130 eine asynchrone Antwort bereit, wenn das Threadwechsel-Triggerereignis erfaßt wird. In der Situation, in der die auslösende Bedingung, wie von den Trigger-Antwortregistern angezeigt, erfüllt wird, kann der Threadwechsel dann zu einem beliebigen Punkt im Ausführungsstrom des Hauptthreads erfolgen. In diesem Sinne ist der Threadwechsel asynchron, da er nicht mit einem beliebigen bestimmten Befehl im Hauptthreadstrom korreliert ist, sondern asynchron zum Verlauf des Hauptthreads erfolgen kann.
  • Mindestens eine Ausführungsform des Trigger-Antwortmechanismus 120 überwacht auf nur jeweils ein Threadwechsel-Triggerereignis. Wenn beispielsweise zwei Markierungsbefehle ausgeführt werden, kann nur jeweils einer vom Trigger-Antwortmechanismus 120 verarbeitet werden. In einem solchen Fall können mehrere Threadwechsel-Triggerbedingungen vorliegen, die in jeder von mehreren Trigger-Antwortregisterbänken 150a–150n angezeigt werden, nur eine der Bänke ist jedoch zu einem beliebigen gegebenen Zeitpunkt aktiv. Es kann eine Zeitüberschreitungsfunktion implementiert werden, so daß der Trigger-Antwortmechanismus 120 nur einen spezifizierten Zeitraum lang (der beispielsweise über die Anzahl von verstrichenen Zyklen oder Anzahl von gelöschten Befehlen gemessen werden kann) auf ein erstes Threadwechsel-Triggerereignis überwacht. Wenn das Threadwechsel-Triggerereignis nicht innerhalb des zugewiesenen Zeitrahmens erfaßt wird, kann das nächste Threadwechsel-Triggerereignis verarbeitet werden.
  • Kurze Bezugnahme auf 2, zusammen mit 1, die ein Beispiel der Zeitüberschreitungsfunktion veranschaulicht. 2 ist ein Zustandsdiagramm, das den Übergang des Trigger-Antwortmechanismus 120 durch die Zustände 202, 204, 206 eines Einzelereignis-Erfassungsschemas veranschaulicht. Zu Zwecken der Erörterung von 2 wird zu Beispielzwecken angenommen, daß ein erster Markierungsbefehl anzeigt, daß ein Threadwechsel nach einem L3-Cache-Miss erfolgen sollte. 2 veranschaulicht, daß der Trigger-Antwortmechanismus 120 sich vor der Ausführung des Markierungsbefehls in einem Standardzustand 202 befindet.
  • Wenn der Markierungsbefehl empfangen wird, geht der Trigger-Antwortmechanismus 120 in einen Erfassungszustand 204 über. Beim Eintritt in den Erfassungszustand 204 werden die Werte in der aktiven Trigger-Antwortregisterbank 115 entsprechend modifiziert. Beim Beispiel eines Cache-Miss wird die Trigger-Antwortregisterbank 115 gemäß des Markierungsbefehls darauf programmiert, eine asynchrone Threadwechsel-Antwort zu erzeugen, wenn mittels der Ereigniszähler 110 ein L3-Cache-Miss gemeldet wird. Beim Eintritt in den Erfassungszustand 204 beginnt außerdem die Zeitüberschreitungsperiode.
  • Während des Erfassungszustands 204 überwacht der Trigger-Antwortmechanismus 120, ob die spezifizierte Threadwechsel-Triggerbedingung erfüllt wird. Wenn die Bedingung nicht vor Ablauf der spezifizierten Zeitüberschreitungsperiode erfaßt wird, hat eine Zeitüberschreitung stattgefunden. Die Zeitüberschreitung bewirkt einen Übergang zurück in den Standardzustand 202.
  • Eine Zeitüberschreitung kann in unserem Beispiel erfolgen, wenn vom zutreffenden Ereigniszähler 110 keine L3-Miss-Zählerüberlaufanzeige innerhalb einer spezifizierten Anzahl von Zyklen angezeigt wird. Analog dazu kann eine Zeitüberschreitung erfolgen, wenn eine bestimmte Anzahl von Befehlen gelöscht wurde, seit in den Erfassungszustand 204 eingetreten wurde. In einem solchen Fall ist es wahrscheinlich, daß sich die betreffenden Speicherzugriffe auf den Cachespeicher ausgewirkt haben. In einem solchen Fall wird der Trigger-Antwortmechanismus 120 auf den Standardzustand 202 zurückgesetzt und ist dann dazu bereit, den nächsten Markierungsbefehl zu empfangen.
  • Wenn bereits ein zweiter Markierungsbefehl ausgeführt wurde, so daß eine zweite Bank von Trigger-Antwortregistern 115 zur Aktivierung zur Verfügung steht, kann der Trigger-Antwortmechanismus zurück zum Erfassungszustand 204 übergehen, um auf das zweite spezifizierte Threadwechsel-Triggerereignis zu überwachen. Andernfalls bleibt der Trigger-Antwortmechanismus 120 im Standardzustand 202, bis ein weiterer Markierungsbefehl ausgeführt wird.
  • 2 veranschaulicht, daß, wenn der Trigger-Antwortmechanismus 120 während des Erfassungszustands 204 erfaßt, daß das spezifizierte Threadwechsel-Triggerereignis stattgefunden hat, der Trigger-Antwortmechanismus 120 in einen Zustand 206 übergeht. Im Zustand 206 zeigt der Trigger-Antwortmechanismus 120 dem Wechsel-Handler 130 an, daß ein Threadwechsel erfolgen sollte. Der Trigger-Antwortmechanismus geht dann zurück zum Standardzustand 202 über.
  • Zur 1 zurückkehrend, veranschaulicht 1, daß die Antwort (entweder synchron oder asynchron), die vom Trigger-Antwortmechanismus 120 erzeugt wird, vom Threadwechsel-Handler 130 empfangen werden kann. Der Threadwechsel-Handler 130 stellt eine minimale Speicherungs-/Wiederherstellungsverarbeitung für einen gespawnten Thread bereit. Wenn die Antwort vom Trigger-Antwortmechanismus 120 anzeigt, daß ein Threadwechsel angemessen ist, speichert der Threadwechsel-Handler 130 minimale Kontextinformationen für den aktuellen Thread, bevor er zu einem anderen Thread wechselt. Die minimalen Kontextinformationen können in einer Warteschlange 140 gespeichert werden. Je nach der Implementierung der Warteschlange 140, wie oben erörtert, können die minimalen Kontextinformationen in einem oder mehreren Registern gespeichert werden oder kann im Speicher gespeichert werden.
  • Bei mindestens einer Ausführungsform ist die IP-Adresse (IP = instruction Pointer, Befehlszähler) für den aktuellen Thread die einzige Kontextinformation, die in der Warteschlange 140 gespeichert wird, bevor zu einem anderen Thread gewechselt wird. Bei mindestens einer anderen Ausführungsform können jedoch weitere Kontextinformationen gespeichert werden. Die Befehlsregister 150 zeigen dem Wechsel-Handler 130 an, welche Infor mationen bei einem Kontextwechsel in der Warteschlange 140 zu speichern sind.
  • Der Helferthread bzw. die Helferthreads, der bzw. die aus einem Hauptthread gespawnt wurde bzw. wurden, ist bzw. sind in dem Sinne Threads mit „geringem Overhead”, daß die Hardware bei einem Threadwechsel verhältnismäßig wenig Kontextinformationen pflegt, in Bezug auf den Umfang der Kontextinformationen, die vom Prozessor für den Hauptthread unterhalten werden. Andere herkömmliche Kontextinformationen, wie Allgemeinregisterwerte, werden aus den minimalen Kontextinformationen, die für Wechsel zu Threads mit geringem Overhead gespeichert werden, ausgeschlossen. Ein Thread, für den nur minimale Informationen von der Hardware gespeichert werden, wie die in 1 dargestellte Ausführungsform (z. B. kann die Befehlszähleradresse (IP-Adresse) die einzige Kontextinformation sein, die in der Warteschlange 140 gespeichert wird), kann wahlweise als ein „Thread mit geringem Overhead”, „Fliegengewicht-Thread”, „dünner Thread” oder „Faser” bezeichnet werden.
  • Bei mindestens einer Ausführungsform wird angenommen, daß Software, in der der Anwender ein Thread spawnendes Triggerereignis spezifiziert hat, dafür verantwortlich zeichnet, andere Informationen zum Architekturzustand zu verwalten, die nicht in der Warteschlange 140 gepflegt werden. Es ist zu beobachten, daß, da der Threadwechsel von einem Anwender ausdrücklich programmiert wird, der Threadwechsel auf der Grundlage von Interaktion des Anwenderprogramms mit der Hardware erfolgt; die Erstellung eines Threads wird bei einer solchen Ausführungsform nicht vom Betriebssystem abgewickelt. Bei mindestens einer Ausführungsform wird beispielsweise angenommen, daß der Kompilierer die weiteren Kontextinformationen für einen Thread mit geringem Overhead mittels Registerpartition explizit verwaltet. Die Wechsel zu Threads mit geringem Overhead sind für das Betriebssystem transparent.
  • Ein Nebeneffekt des oben erörterten anwenderprogrammierbaren Multithreading-Schemas mit geringem Overhead ist, daß Threadwechsel effizient häufiger und mit geringerer Granularität als herkömmliche Multithreading-Kontextwechsel erfolgen können. Der mit einem solchen Kontextwechsel assoziierte geringe Overhead kann amortisiert und über ein verhältnismäßig kleines Quantum ausgeglichen werden. Die Granularität für einen Kontextwechsel mit geringem Overhead, wie hierin beschrieben, kann beispielsweise etwa 200 Maschinenzyklen ausmachen. Dagegen kann die Granularität für einen vom Betriebssystem unterstützten Kontextwechsel für herkömmliches Multithreading viele Millisekunden betragen. Im Hinblick auf die Berechnungseffizienz ist dieser Unterschied beträchtlich – eine Millisekunde kann Millionen von Maschinenzyklen darstellen.
  • 3 ist eine Zeitachse, die eine Beispielsequenz von Ereignissen gemäß einem asynchronen Gebrauchsmodell des oben erörterten Multithreading-Schemas mit geringem Overhead veranschaulicht. Beim in 3 dargestellten asynchronen Gebrauchsmodell enthält ein Hauptthread T1 einen Markierungsbefehl, um anzuzeigen, daß bei einem L3-Cache-Miss während der Ausführung des Hauptthreads T1 ein Threadwechsel erfolgen sollte. Der Markierungsbefehl, x, wird vor dem Zeitpunkt t0 ausgeführt, der den Trigger-Antwortmechanismus 120 (1) wart, auf das vom Anwender spezifizierte Threadwechsel-Triggerereignis zu überwachen (das heißt, auf einen L3-Cache-Miss zu überwachen).
  • 3 veranschaulicht, daß ein L3-Cache-Miss zum Zeitpunkt t0 stattfindet. Der Cache-Miss bewirkt, daß die Ausführung des Hauptthreads (T1) blockiert wird, bis die verfehlten Daten aus dem Speicher abgerufen werden. 3 veranschaulicht, daß diese Blockierung vom Zeitpunkt t0 bis zum Zeitpunkt t4 stattfindet.
  • 3 veranschaulicht, daß der Cache-Miss zum Zeitpunkt t0 außerdem den Trigger-Antwortmechanismus 120 (1) veranlaßt, einen Kontextwechsel mit geringem Overhead zu initiieren, so daß ein Helferthread, T2, asynchron gespawnt wird. Der Kontextwechsel beginnt zum Zeitpunkt t0 und wird zum Zeitpunkt t1 abgeschlossen, zu dem der Helferthread T2 mit der Ausführung beginnt. Demgemäß stellt die Zeitspanne A in 3 die Zeit dar, die dazu benötigt wird, die Steuerung vom Hauptthread T1 zum Helferthread T2 zu übertragen.
  • Bei der in 3 dargestellten Ausführungsform führt der Helferthread T2 eine Vorausberechnungsscheibe von Befehlen für einen künftigen Befehl des Hauptthreads (T1) aus, wobei vom künftigen Befehl des Hauptthreads erwartet wird, daß er einen Cache-Miss erfährt. Das heißt, durch Profilerstellung oder andere Mittel wurde beispielsweise bestimmt, daß vom Befehl bei t6 erwartet wird, daß er aufgrund eines Cache-Miss an einem Ladebefehl während der Ausführung des Hauptthreads T1 einen Leistungsabfall hervorruft. Folglich liest der Helferthread während der Blockierung aufgrund des vom Hauptthread zum Zeitpunkt t0 erfahrenden Cache-Miss Daten im Voraus in einen Datencachespeicher ein, in der Hoffnung, einen zu einem späteren Zeitpunkt erwarteten Cache-Miss (zum Zeitpunkt t6) im Hauptthread (T1) zu vermeiden.
  • Die vom Helferthread T2 vom Zeitpunkt t1 bis zum Zeitpunkt t2 ausgeführte Vorausberechnungsscheibe ist die kleinste Teilmenge von Hauptthreadbefehlen, die zum Vorausberechnen der Adresse des Zielladebefehls erforderlich ist, von dem erwartet wird, daß er zum Zeitpunkt t6 einen Cache-Miss im Hauptthread verursacht. Nach dem Ausführen der Vorausberechnungsscheibe führt der Helferthread den Zielladebefehl aus. 3 veranschaulicht, daß der Zielladebefehl zum Zeitpunkt t2 ausgeführt wird.
  • Bei mindestens einer Ausführungsform kann der Anwender einen Triggerbefehl hinter dem Zielladebefehl im Helferthreadcode setzen, um anzuzeigen, daß der Thread die Ausführung abgeschlossen hat und daß der Hauptthread T1 die Steuerung wiederaufnehmen kann. Der Triggerbefehl kann ein asynchroner oder synchroner Befehl sein. Bei mindestens einer Ausführungsform können sowohl ein synchroner als auch ein asynchroner Befehl am Ende des Helferthreads T2 gesetzt werden.
  • 3 veranschaulicht, daß nach Abschluß des Zielladebefehls zum Zeitpunkt t2 ein Kontextwechsel initiiert wird. (Wie oben angegeben ist, kam dieser Kontextwechsel mittels eines Triggerbefehls initiiert werden, der in dem Helferthreadbefehlsstrom hinter den Zielladebefehl gesetzt wurde.) 3 veranschaulicht, daß der Kontextwechsel zum Zeitpunkt t3 abgeschlossen ist. Demgemäß stellt die Zeitspanne B in 3 die Zeit dar, die dazu benötigt wird, die Steuerung vom Helferthread T2 zurück zum Hauptthread T1 zu übertragen.
  • Obgleich der Kontextwechsel zum Zeitpunkt t3 abgeschlossen wurde, wird der Hauptthread T1 noch immer blockiert, wartet auf die Ladedaten, Daten1, die zum Zeitpunkt t0 angefordert wurden. 3 veranschaulicht, daß die Ladedaten, Daten1, zum Zeitpunkt t4 zurückgesendet werden, zu dem der Hauptthread T1 nicht mehr blockiert wird und die Ausführung von Befehlen wiederaufnimmt.
  • Zwischenzeitlich wird der Helferthread T2 von dem Zeitpunkt an blockiert, zu dem sein Zielladebefehl zum Zeitpunkt t2 ausgegeben wird, bis derartige Ladedaten, Daten2, vom Speichersystem zum Zeitpunkt t5 zurückgesendet werden.
  • Nach Wiederaufnahme der Steuerung zum Zeitpunkt t3 fährt der Hauptthread T1 folglich mit der Ausführung seines Befehlsstroms fort, gelangt schließlich zum Zeitpunkt t6 beim Ladebefehl an.
  • Da die Daten für diesen Ladebefehl, die Daten2, vom Helferthread zum Zeitpunkt t5 vorausgelesen wurden und im Cachespeicher plaziert wurden, wird ein Cache-Miss im Hauptthread T1 zum Zeitpunkt t6 vermieden.
  • 4 stellt die Verarbeitung durch den Threadwechsel-Handler 130 während der bei A und B in 3 gezeigten Threadwechsel an. Zu dem Zeitpunkt, bevor der Kontextwechsel A zum Zeitpunkt t0 initiiert wird, ist der Hauptthread T1 der aktive Thread. 4 veranschaulicht, daß der Hauptthread T1 der aktive Thread ist, der in den Wechsel-Handler 130 geht. Der Wechsel-Handler 130 führt den Kontextwechsel mit geringem Overhead aus, indem er Kontextinformationen in der Auftragsschlange 140 speichert. Des Weiteren setzt der Wechsel-Handler 130 den Befehlszähler des Prozessors während des Kontextwechsels auf den ersten Befehl des Helferthreads T2. Zum Beispiel kann der Wechsel-Handler 130 den T2-Befehlszählerwert von einem zuvor bezeichneten Speicherplatz oder aus einem Register beziehen. Danach fährt der Prozessor mit der Ausführung der Befehle des Helferthreads T2 fort.
  • Für den in 3 dargestellten Kontextwechsel B veranschaulicht 4, daß der Helferthread T2 vor dem Zeitpunkt, zu dem der Kontextwechsel B zum Zeitpunkt t2 initiiert wird, der aktive Thread ist. Folglich ist der Helferthread T2 der aktive Thread, der zum Zeitpunkt t2 in den Wechsel-Handler 130 geht. Der Wechsel-Handler 130 speichert während des Kontextwechsels B die Kontextinformationen für den Thread T2 in der Auftragsschlange 140 und stellt den Befehlszähler des Prozessors aus den T1-Kontextinformationen wieder her, die während des vorherigen Kontextwechsels in der Warteschlange 140 gespeichert wurde. Danach fährt der Prozessor mit der Ausführung der Befehle des Hauptthreads T1 fort.
  • 5 ist ein Ablaufdiagramm, das mindestens eine Ausführungsform eines Verfahrens 500 zum Durchführen von anwenderprogrammierbarem Multithreading veranschaulicht. Bei mindestens einer Ausführungsform wird das Verfahren ohne Eingreifen des Betriebssystems durchgeführt und ist für das Betriebssystem transparent. Die Befähigung eines Anwenders, die in 5 dargestellte Verarbeitung direkt zu veranlassen, kann mittels eines Kompilierers bereitgestellt werden, der einen Treiber zur Thread-Erstellung als Teil einer Ausführungsbibliothek bereitstellen kann.
  • 5 veranschaulicht, daß die Verarbeitung für das Verfahren 5000 bei Block 502 beginnt und zu Block 504 voranschreitet. Bei Block 504 erfaßt Hardware, wie die in 1 dargestellten Trigger-Antwortregister 115, eine vom Anwender spezifizierte Threadwechsel-Triggerbedingung. Die Bedingung kann synchron (wie die Ausführung eines expliziten Triggerbefehls) oder asynchron (wie eine von einem Markierungsbefehl angezeigte Bedingung) sein. Wenn keine Triggerbedingung erfaßt wird, läuft die Verarbeitung in einer Schleife zum Block 502 zurück. Als Antwort auf das Erfassen eines Triggerereignisses bei Block 504 schreitet die Verarbeitung zu Block 506 voran.
  • Bei Block 506 setzt Hardware (wie beispielsweise der in 1 dargestellte Wechsel-Handler 130) die Ausführung des aktuellen Threads aus. Der aktuelle Thread ist bei mindestens einer Ausführungsform ein Hauptthread mit vollständigem Kontext. Das Aussetzen kann das Speichern von minimalen Kontextinformationen für den aktuellen Thread in einer Auftragsschlange, wie der in 1 dargestellten Auftragsschlange 140, einschließen. Der Anwender kann das Gewicht bzw. den Umfang der Kontextinformationen, die bei Block 506 gespeichert wird, programmieren. Ein Kompilierer oder ein ähnliches Hilfsprogramm kann weitere Kontextinformationen pflegen, die nicht von der Hardware gepflegt werden (manchmal hierin als „ausgeschlossene” Kontextinformationen bezeichnet).
  • Die Verarbeitung schreitet dann zu Block 508 voran, bei dem ein Helferthread mit geringem Thread aktiviert wird. Bei mindestens einer Ausführungsform wird der Helferthread von Hardware, wie dem Wechsel-Handler 130, aktiviert, die die Anfangs-Befehlszähleradresse für den Helferthreadbefehlsstrom in dem Befehlszählerregister des Prozessors plaziert. Von Block 508 schreitet die Verarbeitung dann zu Block 510 voran.
  • Bei Block 510 erfaßt Hardware, wie die in 1 dargestellten Trigger-Antwortregister 115, eine vom Anwender spezifizierte Threadwechsel-Triggerbedingung, um die Aufgabe des Helferthreads und folglich die Wiederaufnahme des Hauptthreads zu bewirken. Die Bedingung kann synchron (wie die Ausführung eines expliziten Triggerbefehls) oder asynchron (wie eine von einem Markierungsbefehl angezeigte Bedingung) sein. Wenn keine Triggerbedingung erfaßt wird, läuft die Verarbeitung in einer Schleife zum Block 510 zurück und der Helferthread setzt die Ausführung fort. Als Antwort auf das Erfassen eines Aufgabe-Triggerereignisses bei Block 510 schreitet die Verarbeitung zu Block 512 voran.
  • Bei Block 512 wird der Helferthread ausgesetzt. Wenn die bei Block 510 erfaßte Bedingung anzeigt, daß der Helferthread zerstört werden sollte, müssen keine Kontextinformationen für den Helferthread gespeichert werden. Wenn der Helferthread jedoch auszusetzen ist, werden während des Aussetzens bei Block 512 Kontextinformationen für den Helferthread gespeichert. Die Verarbeitung schreitet dann zu Block 514 voran.
  • Bei Block 514 wird der Kontext für den „aktuellen” Thread, der bei Block 506 gespeichert wurde, wiederhergestellt. Die Verarbeitung für den aktuellen Thread wird darin an der wiederhergestellten Befehlszähleradresse wiederaufgenommen. Die Verarbeitung endet dann bei Block 516.
  • Es sollte beachtet werden, daß bei mindestens einer Ausführungsform der bei den Blöcken 506 und 508 und 512 und 514 bewirkte Kontextwechsel ohne Eingreifen eines Betriebssystems durchgeführt wird.
  • Die vorstehende Erörterung offenbart ausgewählte Ausführungsformen einer Vorrichtung, eines Systems und eines Verfahrens zum anwenderprogrammierbaren Spawnen und Verwalten eines oder mehrerer gleichzeitig ablaufender Helferthreads mit geringem Overhead. Die hierin beschriebenen Verfahren können auf einem Verarbeitungssystem, wie dem in 1 dargestellten Verarbeitungssystem 100, durchgeführt werden.
  • 1 stellt eine Ausführungsform eines Verarbeitungssystems 100 dar, das offenbarte Techniken nutzen kann. Das System 100 kann beispielsweise dazu verwendet werden, ein oder mehrere Verfahren zum Bereitstellen von anwenderprogrammierbarem Multithreading, wie die hierin beschriebenen Ausführungsformen, auszuführen. Zu Zwecken dieser Offenbarung schließt ein Verarbeitungssystem ein beliebiges Verarbeitungssystem ein, das einen Prozessor aufweist, wie beispielsweise: einen digitalen Signalprozessor (DSP), einen Mikrocontroller, eine anwendungsspezifische integrierte Schaltung (application specific integrated circuit, ASIP) oder einen Mikroprozessor. Das System 100 ist für Verarbeitungssysteme repräsentativ, die auf den Itanium®- und Itanium® 2-Prozessoren sowie den Pentium®-, Pentium® Pro-, Pentium® II-, Pentium® III- und Pentium® 4-Mikroprozessoren basieren, die alle von der Intel Corporation erhältlich sind. Andere Systeme (einschließlich Personalcomputern (PCs) mit anderen Mikroprozessoren, Engineering-Workstations, Minicomputer (PDAs) und andere tragbare Geräte, Digitalempfänger und dergleichen) können ebenfalls verwendet werden. Mindestens eine Ausführungsform des Systems 100 kann eine Version des WindowsTM-Betriebssystems ausführen, das von der Microsoft Corporation erhältlich ist, obwohl auch andere Betriebssysteme und beispielsweise grafische Benutzeroberflächen verwendet werden können.
  • Das Verarbeitungssystem 100 enthält ein Speichersystem 150 und einen Prozessor 101. Das Speichersystem 150 kann Befehle 140 und Daten 141 zum Steuern des Betriebs des Prozessors 101 speichern. Das Speichersystem 150 ist als eine verallgemeinerte Repräsentation von Speicher gedacht und kann eine Vielfalt an Formen einschließen, wie ein Festplattenlaufwerk, eine CD-ROM, einen Direktzugriffsspeicher (random access memory, RAM), einen dynamischen Direktzugriffsspeicher (dynamic random access memory, DRAM), einen statischen Direktzugriffsspeicher (static random access memory, SRAM), einen Flash-Speicher und anverwandte Schaltkreise. Das Speichersystem 150 kann Befehle 140 und/oder Daten 141 speichern, die von Datensignalen dargestellt sind, die vom Prozessor 101 ausgeführt werden können.
  • In der vorhergehenden Beschreibung werden verschiedene Gesichtspunkte eines Verfahrens, einer Vorrichtung und eines Systems zum Implementieren von anwenderprogrammierbarem Multithreading offenbart. Zu Zwecken der Erläuterung wurden spezifische Zahlen, Beispiele, Systeme und Konfigurationen dargelegt, um ein vollständigeres Verständnis bereitzustellen. Einem Fachmann wird offensichtlich sein, daß das beschriebene Verfahren und die beschriebene Vorrichtung ohne die spezifischen Einzelheiten ausgeübt werden kann. Es wird Fachmännern ersichtlich sein, daß Änderungen und Abwandlungen vorgenommen werden können, ohne von der vorliegenden Erfindung in ihren weiteren Gesichtspunkten abzuweichen. Zum Beispiel können die in 3 gezeigte Zeitachse und das in 5 dargestellte Verfahren 500 modifiziert werden, um für mehrere Helferthreads zu sorgen – ein Helferthread kann selbst einen anderen Helferthread spawnen. Während bestimmte Ausführungsformen der vorliegenden Erfindung gezeigt und beschrieben wurden, sollten die angehängten Ansprüche in ihrem Schutzumfang alle derartigen Änderungen und Abwandlungen umfassen, die in den rechtmäßigen Schutzumfang der vorliegenden Erfindung fallen.

Claims (7)

  1. Prozessor mit einem Threadwechsel-Handler, einem Trigger-Antwortmechanismus und einem Datencachespeicher, a) wobei der Trigger-Antwortmechanismus auf das Empfangen eines Markierungsbefehls während der Ausführung eines Hauptthreads in einen Erfassungszustand übergeht, in dem er eine asynchrone Threadwechsel-Antwort erzeugt, wenn beim nachfolgenden Ausführen eines Ladebefehls ein Cache-Miss im Datencachespeicher gemeldet wird; b) wobei die Threadwechsel-Antwort vom Threadwechsel-Handler empfangen wird, der daraufhin die Ausführung des Hauptthreads aussetzt, die Befehlszeigeradresse für den aktuellen Thread speichert und einen Kontextwechsel initiiert, so dass ein Helferthread asynchron gespawnt wird; c) wobei der Threadwechsel-Handler die Anfangs-Befehlszeigeradresse des Helferthreads von einem zuvor bezeichneten Speicherplatz oder aus einem Register bezieht; d) wobei der Hauptthread weiterhin auf die durch den Ladebefehl angeforderten Daten wartet und nach Abschluss der Ausführung des Helferthreads die Steuerung wieder aufnimmt.
  2. Prozessor nach Anspruch 1, wobei: – der Markierungsbefehl zur Handhabung eines Hauptthreads ein Triggerbefehl zum Erzeugen, Beenden, Anhalten oder Wiederaufnehmen eines Hauptthreads ist und – eine Logik, welche den Cache-Miss detektiert, so ausgelegt ist, dass sie den Operationscode des Triggerbefehls detektiert, wenn der Triggerbefehl zur Ausführung kommt.
  3. Prozessor nach Anspruch 1, der ferner ein Anwender-adressierbares Steuerregister zum Spezifizieren, dass als Antwort auf das Aufrufen des Helferthreads ein Gewicht eines Kontextes gespeichert werden soll, aufweist.
  4. Verfahren, welches von einem Prozessor mit einem Threadwechsel-Handler, einem Trigger-Antwortmechanismus und einem Datencachespeicher auasgeführt wird, und Folgendes umfasst: a) der Trigger-Antwortmechanismus geht auf das Empfangen eines Markierungsbefehls während der Ausführung eines Hauptthreads in einen Erfassungszustand über, in dem er eine asynchrone Threadwechsel-Antwort erzeugt, wenn beim nachfolgenden Ausführen eines Ladebefehls ein Cache-Miss im Datencachespeicher gemeldet wird; b) die Threadwechsel-Antwort wird vom Threadwechsel-Handler empfangen, der daraufhin die Ausführung des Hauptthreads aussetzt, die Befehlszeigeradresse für den aktuellen Thread speichert und einen Kontextwechsel initiiert, so dass ein Helferthread asynchron gespawnt wird; c) der Threadwechsel-Handler bezieht die Anfangs-Befehlszeigeradresse des Helferthreads von einem zuvor bezeichneten Speicherplatz oder aus einem Register; d) der Hauptthread wartet weiterhin auf die durch den Ladebefehl angeforderten Daten und nimmt nach Abschluss der Ausführung des Helferthreads die Steuerung wieder auf.
  5. Verfahren nach Anspruch 4, wobei: das Detektieren eines Cache-Misses ferner das Bestimmen umfasst, dass ein in dem Markierungsbefehl spezifiziertes asynchrones Triggerereignis angetroffen wurde.
  6. Verfahren nach Anspruch 4, ferner umfassend: Wiederherstellen von Kontextinformationen für den Hauptthread vor dem Wiederaufnehmen der Ausführung des Hauptthreads.
  7. Prozessor nach einem der Ansprüche 1 bis 3, der ferner Folgendes umfasst: Benutzer-programmierbares Kontextsteuerbefehlsregister zum Spezifizieren eines Gewichts eines Kontexts, der gespeichert wird, wenn der Cache-Miss gemeldet wird, wobei der Threadwechsel-Handler den Helferthread mit lediglich eine Befehlszeigeradresse umfassende Kontextinformation aufruft, und wobei der Helferthread den an dieser Befehlszeigeradresse abgelegten Ladebefehl ausführt, um Daten zu laden, die später von dem Hauptthreads benötigt werden.
DE112004002296T 2003-12-05 2004-11-19 Anwenderprogrammierbares Multithreading mit geringem Overhead Active DE112004002296B4 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US10/728,649 US7631307B2 (en) 2003-12-05 2003-12-05 User-programmable low-overhead multithreading
US10/728,649 2003-12-05
PCT/US2004/038987 WO2005062168A2 (en) 2003-12-05 2004-11-19 User-programmable low-overhead multithreading

Publications (2)

Publication Number Publication Date
DE112004002296T5 DE112004002296T5 (de) 2006-09-28
DE112004002296B4 true DE112004002296B4 (de) 2010-07-08

Family

ID=34633761

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112004002296T Active DE112004002296B4 (de) 2003-12-05 2004-11-19 Anwenderprogrammierbares Multithreading mit geringem Overhead

Country Status (4)

Country Link
US (1) US7631307B2 (de)
CN (1) CN101218561B (de)
DE (1) DE112004002296B4 (de)
WO (1) WO2005062168A2 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10877910B2 (en) 2003-02-19 2020-12-29 Intel Corporation Programmable event driven yield mechanism which may activate other threads

Families Citing this family (74)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050166177A1 (en) * 2004-01-27 2005-07-28 Ylian Saint-Hilaire Thread module chaining
US7490325B2 (en) * 2004-03-13 2009-02-10 Cluster Resources, Inc. System and method for providing intelligent pre-staging of data in a compute environment
US20070266388A1 (en) 2004-06-18 2007-11-15 Cluster Resources, Inc. System and method for providing advanced reservations in a compute environment
EP1622009A1 (de) * 2004-07-27 2006-02-01 Texas Instruments Incorporated JSM-Architektur und Systeme
US8176490B1 (en) 2004-08-20 2012-05-08 Adaptive Computing Enterprises, Inc. System and method of interfacing a workload manager and scheduler with an identity manager
US8271980B2 (en) 2004-11-08 2012-09-18 Adaptive Computing Enterprises, Inc. System and method of providing system jobs within a compute environment
US7810083B2 (en) * 2004-12-30 2010-10-05 Intel Corporation Mechanism to emulate user-level multithreading on an OS-sequestered sequencer
WO2006069494A1 (en) * 2004-12-31 2006-07-06 Intel Corporation Parallelization of bayesian network structure learning
US9075657B2 (en) 2005-04-07 2015-07-07 Adaptive Computing Enterprises, Inc. On-demand access to compute resources
US8863143B2 (en) 2006-03-16 2014-10-14 Adaptive Computing Enterprises, Inc. System and method for managing a hybrid compute environment
US9231886B2 (en) 2005-03-16 2016-01-05 Adaptive Computing Enterprises, Inc. Simple integration of an on-demand compute environment
US7950012B2 (en) * 2005-03-16 2011-05-24 Oracle America, Inc. Facilitating communication and synchronization between main and scout threads
US7472256B1 (en) 2005-04-12 2008-12-30 Sun Microsystems, Inc. Software value prediction using pendency records of predicted prefetch values
US20070094213A1 (en) * 2005-07-14 2007-04-26 Chunrong Lai Data partitioning and critical section reduction for Bayesian network structure learning
US20070094214A1 (en) * 2005-07-15 2007-04-26 Li Eric Q Parallelization of bayesian network structure learning
US20070079294A1 (en) * 2005-09-30 2007-04-05 Robert Knight Profiling using a user-level control mechanism
US7774779B2 (en) * 2005-11-18 2010-08-10 At&T Intellectual Property I, L.P. Generating a timeout in a computer software application
US9003421B2 (en) * 2005-11-28 2015-04-07 Intel Corporation Acceleration threads on idle OS-visible thread execution units
US8065690B2 (en) * 2005-12-01 2011-11-22 Cisco Technology, Inc. Method and system for event-based remote procedure call implementation in a distributed computing system
US9754265B2 (en) * 2006-05-01 2017-09-05 At&T Intellectual Property I, L.P. Systems and methods to automatically activate distribution channels provided by business partners
US7502913B2 (en) * 2006-06-16 2009-03-10 Microsoft Corporation Switch prefetch in a multicore computer chip
GB2443507A (en) * 2006-10-24 2008-05-07 Advanced Risc Mach Ltd Debugging parallel programs
US20080141268A1 (en) * 2006-12-12 2008-06-12 Tirumalai Partha P Utility function execution using scout threads
KR20100014823A (ko) * 2007-01-23 2010-02-11 에이저 시스템즈 인크 디바이스들을 위한 단일 스레드 아키텍쳐에서 애플리케이션 스위칭
US8495627B2 (en) * 2007-06-27 2013-07-23 International Business Machines Corporation Resource allocation based on anticipated resource underutilization in a logically partitioned multi-processor environment
US8219989B2 (en) 2007-08-02 2012-07-10 International Business Machines Corporation Partition adjunct with non-native device driver for facilitating access to a physical input/output device
US8645974B2 (en) * 2007-08-02 2014-02-04 International Business Machines Corporation Multiple partition adjunct instances interfacing multiple logical partitions to a self-virtualizing input/output device
US8574393B2 (en) * 2007-12-21 2013-11-05 Tsinghua University Method for making touch panel
US7996663B2 (en) * 2007-12-27 2011-08-09 Intel Corporation Saving and restoring architectural state for processor cores
US8145849B2 (en) 2008-02-01 2012-03-27 International Business Machines Corporation Wake-and-go mechanism with system bus response
US8171476B2 (en) * 2008-02-01 2012-05-01 International Business Machines Corporation Wake-and-go mechanism with prioritization of threads
US8880853B2 (en) * 2008-02-01 2014-11-04 International Business Machines Corporation CAM-based wake-and-go snooping engine for waking a thread put to sleep for spinning on a target address lock
US8725992B2 (en) 2008-02-01 2014-05-13 International Business Machines Corporation Programming language exposing idiom calls to a programming idiom accelerator
US8640141B2 (en) * 2008-02-01 2014-01-28 International Business Machines Corporation Wake-and-go mechanism with hardware private array
US8386822B2 (en) * 2008-02-01 2013-02-26 International Business Machines Corporation Wake-and-go mechanism with data monitoring
US8612977B2 (en) * 2008-02-01 2013-12-17 International Business Machines Corporation Wake-and-go mechanism with software save of thread state
US8341635B2 (en) * 2008-02-01 2012-12-25 International Business Machines Corporation Hardware wake-and-go mechanism with look-ahead polling
US8732683B2 (en) * 2008-02-01 2014-05-20 International Business Machines Corporation Compiler providing idiom to idiom accelerator
US8788795B2 (en) * 2008-02-01 2014-07-22 International Business Machines Corporation Programming idiom accelerator to examine pre-fetched instruction streams for multiple processors
US8225120B2 (en) * 2008-02-01 2012-07-17 International Business Machines Corporation Wake-and-go mechanism with data exclusivity
US8250396B2 (en) * 2008-02-01 2012-08-21 International Business Machines Corporation Hardware wake-and-go mechanism for a data processing system
US8127080B2 (en) 2008-02-01 2012-02-28 International Business Machines Corporation Wake-and-go mechanism with system address bus transaction master
US8452947B2 (en) 2008-02-01 2013-05-28 International Business Machines Corporation Hardware wake-and-go mechanism and content addressable memory with instruction pre-fetch look-ahead to detect programming idioms
US8516484B2 (en) * 2008-02-01 2013-08-20 International Business Machines Corporation Wake-and-go mechanism for a data processing system
US8316218B2 (en) 2008-02-01 2012-11-20 International Business Machines Corporation Look-ahead wake-and-go engine with speculative execution
US8312458B2 (en) * 2008-02-01 2012-11-13 International Business Machines Corporation Central repository for wake-and-go mechanism
US8082315B2 (en) * 2009-04-16 2011-12-20 International Business Machines Corporation Programming idiom accelerator for remote update
US8145723B2 (en) * 2009-04-16 2012-03-27 International Business Machines Corporation Complex remote update programming idiom accelerator
US8230201B2 (en) * 2009-04-16 2012-07-24 International Business Machines Corporation Migrating sleeping and waking threads between wake-and-go mechanisms in a multiple processor data processing system
US8886919B2 (en) * 2009-04-16 2014-11-11 International Business Machines Corporation Remote update programming idiom accelerator with allocated processor resources
US8327059B2 (en) * 2009-09-30 2012-12-04 Vmware, Inc. System and method to enhance memory protection for programs in a virtual machine environment
US11720290B2 (en) 2009-10-30 2023-08-08 Iii Holdings 2, Llc Memcached server functionality in a cluster of data processing nodes
US8423750B2 (en) * 2010-05-12 2013-04-16 International Business Machines Corporation Hardware assist thread for increasing code parallelism
US8667253B2 (en) 2010-08-04 2014-03-04 International Business Machines Corporation Initiating assist thread upon asynchronous event for processing simultaneously with controlling thread and updating its running status in status register
US8793474B2 (en) 2010-09-20 2014-07-29 International Business Machines Corporation Obtaining and releasing hardware threads without hypervisor involvement
US8713290B2 (en) 2010-09-20 2014-04-29 International Business Machines Corporation Scaleable status tracking of multiple assist hardware threads
US8694832B2 (en) 2011-03-03 2014-04-08 International Business Machines Corporation Assist thread analysis and debug mechanism
US9201689B2 (en) * 2011-04-22 2015-12-01 Cray Inc. Software emulation of massive hardware threading for tolerating remote memory references
CN104011703B (zh) 2011-12-22 2017-04-12 英特尔公司 用于指定应用线程性能状态的指令的指令处理装置及相关方法
US9396020B2 (en) 2012-03-30 2016-07-19 Intel Corporation Context switching mechanism for a processing core having a general purpose CPU core and a tightly coupled accelerator
US9286081B2 (en) * 2012-06-12 2016-03-15 Apple Inc. Input device event processing
US9582320B2 (en) * 2013-03-14 2017-02-28 Nxp Usa, Inc. Computer systems and methods with resource transfer hint instruction
JP6477216B2 (ja) * 2015-05-08 2019-03-06 富士通株式会社 演算装置、スレッド切替方法、及びマルチスレッドプログラム
US10019283B2 (en) * 2015-06-22 2018-07-10 Advanced Micro Devices, Inc. Predicting a context portion to move between a context buffer and registers based on context portions previously used by at least one other thread
CN106980546B (zh) * 2016-01-18 2021-08-27 阿里巴巴集团控股有限公司 一种任务异步执行方法、装置及系统
US10558463B2 (en) 2016-06-03 2020-02-11 Synopsys, Inc. Communication between threads of multi-thread processor
US10628320B2 (en) * 2016-06-03 2020-04-21 Synopsys, Inc. Modulization of cache structure utilizing independent tag array and data array in microprocessor
US10318302B2 (en) 2016-06-03 2019-06-11 Synopsys, Inc. Thread switching in microprocessor without full save and restore of register file
US10552158B2 (en) 2016-08-18 2020-02-04 Synopsys, Inc. Reorder buffer scoreboard having multiple valid bits to indicate a location of data
US10613859B2 (en) 2016-08-18 2020-04-07 Synopsys, Inc. Triple-pass execution using a retire queue having a functional unit to independently execute long latency instructions and dependent instructions
US10210650B1 (en) * 2017-11-30 2019-02-19 Advanced Micro Devices, Inc. Primitive level preemption using discrete non-real-time and real time pipelines
WO2020186630A1 (en) * 2019-03-21 2020-09-24 Huawei Technologies Co., Ltd. Serializing divergent accesses using peeling
US11474861B1 (en) * 2019-11-27 2022-10-18 Meta Platforms Technologies, Llc Methods and systems for managing asynchronous function calls
US11194503B2 (en) * 2020-03-11 2021-12-07 Samsung Electronics Co., Ltd. Storage device having a configurable command response trigger

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6272520B1 (en) * 1997-12-31 2001-08-07 Intel Corporation Method for detecting thread switch events

Family Cites Families (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US2055964A (en) * 1934-09-26 1936-09-29 Granberg Meter Corp Flow shut-off mechanism
US3061445A (en) * 1959-04-30 1962-10-30 Abbott Lab Effervescent sweetening tablet
US3018686A (en) * 1961-01-10 1962-01-30 Sawyer S Inc Tachistoscope
US4539637A (en) * 1982-08-26 1985-09-03 At&T Bell Laboratories Method and apparatus for handling interprocessor calls in a multiprocessor system
JP3034873B2 (ja) * 1988-07-01 2000-04-17 株式会社日立製作所 情報処理装置
US5247676A (en) * 1989-06-29 1993-09-21 Digital Equipment Corporation RPC based computer system using transparent callback and associated method
US5179702A (en) * 1989-12-29 1993-01-12 Supercomputer Systems Limited Partnership System and method for controlling a highly parallel multiprocessor using an anarchy based scheduler for parallel execution thread scheduling
US5390329A (en) * 1990-06-11 1995-02-14 Cray Research, Inc. Responding to service requests using minimal system-side context in a multiprocessor environment
US6697935B1 (en) 1997-10-23 2004-02-24 International Business Machines Corporation Method and apparatus for selecting thread switch events in a multithreaded processor
US6098169A (en) * 1997-12-23 2000-08-01 Intel Corporation Thread performance analysis by monitoring processor performance event registers at thread switch
US6560626B1 (en) * 1998-04-02 2003-05-06 Microsoft Corporation Thread interruption with minimal resource usage using an asynchronous procedure call
US6401155B1 (en) * 1998-12-22 2002-06-04 Philips Electronics North America Corporation Interrupt/software-controlled thread processing
US6535905B1 (en) 1999-04-29 2003-03-18 Intel Corporation Method and apparatus for thread switching within a multithreaded processor
US7343602B2 (en) 2000-04-19 2008-03-11 Hewlett-Packard Development Company, L.P. Software controlled pre-execution in a multithreaded processor
US7222150B1 (en) * 2000-08-15 2007-05-22 Ikadega, Inc. Network server card and method for handling requests received via a network interface
US20020138706A1 (en) * 2001-03-21 2002-09-26 Littera, Inc. Reader-writer lock method and system
US6928645B2 (en) * 2001-03-30 2005-08-09 Intel Corporation Software-based speculative pre-computation and multithreading
AU2002331774A1 (en) 2001-08-29 2003-03-18 Analog Devices, Inc. Methods and apparatus utilizing flash burst mode to improve processor performance
US7047533B2 (en) * 2001-09-10 2006-05-16 Hewlett-Packard Development Company, L.P. Wait utility and method
US7117346B2 (en) * 2002-05-31 2006-10-03 Freescale Semiconductor, Inc. Data processing system having multiple register contexts and method therefor
US7228348B1 (en) * 2002-08-13 2007-06-05 Finisar Corporation System and method for triggering communications data capture
US8176298B2 (en) * 2002-10-08 2012-05-08 Netlogic Microsystems, Inc. Multi-core multi-threaded processing systems with instruction reordering in an in-order pipeline
US7010672B2 (en) * 2002-12-11 2006-03-07 Infineon Technologies Ag Digital processor with programmable breakpoint/watchpoint trigger generation circuit
US7376954B2 (en) * 2003-08-28 2008-05-20 Mips Technologies, Inc. Mechanisms for assuring quality of service for programs executing on a multithreaded processor
US6931354B2 (en) * 2003-11-13 2005-08-16 International Business Machines Corporation Method, apparatus and computer program product for efficient, large counts of per thread performance events

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6272520B1 (en) * 1997-12-31 2001-08-07 Intel Corporation Method for detecting thread switch events

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
Studer, A.: Helper Threads, 18.03.03, S. 1-71 (recherchiert am 05.11.08) *
Studer, A.: Helper Threads, 18.03.03, S. 1-71 <http://www.ece.rochester.edu/~mihuang/TEACHING/OLD/ECE404_SPRING03/ HelperThreads.pdf> (recherchiert am 05.11.08)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10877910B2 (en) 2003-02-19 2020-12-29 Intel Corporation Programmable event driven yield mechanism which may activate other threads

Also Published As

Publication number Publication date
US20050125802A1 (en) 2005-06-09
US7631307B2 (en) 2009-12-08
WO2005062168A2 (en) 2005-07-07
CN101218561B (zh) 2013-03-06
WO2005062168A3 (en) 2008-01-03
CN101218561A (zh) 2008-07-09
DE112004002296T5 (de) 2006-09-28

Similar Documents

Publication Publication Date Title
DE112004002296B4 (de) Anwenderprogrammierbares Multithreading mit geringem Overhead
DE60109748T2 (de) Verfahren und gerät zur ausführungsunterbrechung in einem prozessor
DE10297856B4 (de) Verfahren und Vorrichtung zum Suspendieren der Ausführung eines Threads, bis ein spezifizierter Speicherzugriff auftritt
DE112005002305B4 (de) Thread-Livelock-Einheit
DE10085375B4 (de) Verfahren und Einrichtung für einen pipeline-verschachtelten Multi-Thread-Befehlsdecodierer
DE60210633T2 (de) Verfahren und vorrichtungen zur verbesserung des durchsatzes von eingebetteten prozessoren auf cache-basis durch umschalten von tasks als reaktion auf eine cache-verfehlung
DE602004006858T2 (de) Abrechnungsverfahren und -schaltung zur bestimmung der pro-thread-nutzung von prozessorbetriebsmitteln in einem simultanen multithread-prozessor (smt)
DE60038693T2 (de) Verfahren und vorrichtung zur ausschaltung eines taktsignals in einem vielfadenprozessor
DE69819849T2 (de) Anordnung zum willkürlichen Abtasten von Instruktionen in einer Prozessorpipeline
DE10085363B4 (de) Verfahren und Einrichtung zum Verwalten von Ressourcen in einem Multithreaded-Prozessor
DE69829693T2 (de) Prozessor mit mehrfachprogrammzählern und ablaufverfolgungspuffern ausserhalb einer ausführungspipeline
DE69931288T2 (de) Ermittlung der Latenzzeit eines Rechnerspeichers
DE19781850B4 (de) Mikroprozessor zum spekulativen Ausführen von Befehlen aus mehreren von einem Verzweigungsbefehl angezeigten Befehlsströmen, Verfahren und Computersystem mit Mikroprozessor
DE602005005726T2 (de) Verbreitung eines Thread-IDs in einem Multithreadpipelineprozessor
DE19527031C2 (de) Verzweigungsprozessor für ein Datenverarbeitungssystem und Verfahren zum Betreiben eines Datenverarbeitungssystems
DE69824688T2 (de) System und Verfahren zur Leistungsoptimierung eines Rechnersystems
DE112006001698T5 (de) Grundfunktionen zum Verbessern von Thread-Level Spekulation
DE112004002267T5 (de) Ruhezustandsmechansimus für virtuelles Multithreading
DE602004007754T2 (de) Verfahren und Vorrichtung zur Feststellung einer Prozessorenbelastung
DE60115976T2 (de) Rechnersystem und Interruptvorgang
DE19506734A1 (de) Computersystem und Verfahren zum Aufrechterhalten der Speicherkonsistenz in einer Busanforderungswarteschlange
DE10050684A1 (de) Verfahren und System zur periodischen Ablaufverfolgung für die Echtzeitgenerierung von Segmenten von Aufrufstack-Bäumen
DE10297597T5 (de) Suspendieren der Ausführung eines Threads in einem Mehrfach-Thread-Prozessor
DE102010052680A1 (de) Ein Befehl, um einen Prozessor-Wartezustand zu ermöglichen
DE112011105042T5 (de) Indikatoren zur Aufzeichnung einer letzten Verzweigung für einen Transaktionsspeicher

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law

Ref document number: 112004002296

Country of ref document: DE

Date of ref document: 20060928

Kind code of ref document: P

8125 Change of the main classification

Ipc: G06F 9/46 AFI20051017BHDE

8364 No opposition during term of opposition
R081 Change of applicant/patentee

Owner name: TAHOE RESEARCH, LTD., IE

Free format text: FORMER OWNER: INTEL CORPORATION, SANTA CLARA, CALIF., US

R082 Change of representative

Representative=s name: DENNEMEYER & ASSOCIATES S.A., DE