DE69729822T2

DE69729822T2 - Echtzeit-Taskzuweiser

Info

Publication number: DE69729822T2
Application number: DE69729822T
Authority: DE
Inventors: John E. Milpitas Zolnowsky
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1996-05-06
Filing date: 1997-05-01
Publication date: 2004-12-02
Anticipated expiration: 2017-05-02
Also published as: US6779182B1; DE69729822D1; EP0806730A3; EP0806730B1; JPH1055284A; EP0806730A2; US5826081A

Description

TECHNISCHES GEBIET
Diese Erfindung betrifft ein Verfahren und eine Vorrichtung für eine effiziente Prozesseinplanung für ein Multiprozessorsystem in einer Echtzeit-Umgebung.
Das Multiprozessorsystem (MP) ist gekennzeichnet durch die Gegenwart mehrerer CPU oder Prozessoren, welche an gemeinsamen oder gleichzeitig genutzten Rechner-Tasks zusammenarbeiten. Mit mehreren Prozessoren in einem einzigen Computersystem kann man eine Steigerung des Leistungsvermögens erhalten, indem zugelassen wird, dass sich viele Prozessoren die Rechnerlast teilen, oder indem zugelassen wird, dass viele kleinere Tasks parallel von separaten Prozessoren durchgeführt werden. Ein Multiprozessorsystem kann auch die Zuverlässigkeit des Systems verbessern, da der Ausfall eines Prozessors nicht notwendigerweise zu einem Absturz des gesamten Systems führen wird.
Die Einführung mehrerer Prozessoren verkompliziert jedoch die Betriebsmittelverwaltung und das Zuweisungsproblem, da zwei oder mehr Prozesse gleichzeitig im Kern auf separaten Prozessoren ausgeführt werden. Folglich muss ein Einplanermodul eines Betriebssystems entscheiden, welcher Prozessor einen Prozess ausführen soll, und in seiner allgemeinen Form einen Satz von Prozessen auf einem Satz von Prozessoren mit beliebigen Eigenschaften einplanen, um irgendeine Zielfunktion zu optimieren. Dies ist mit der Auswahl eines Prozesses zur Ausführung aus einem Satz von Prozessen verbunden.
Die grundlegenden Abstraktionen in einem Betriebssystem umfassen „Tasks" und „Threads". Ein Task ist eine Einheit der Betriebsmittelverwaltung und ein Thread ist ein einzelner Befehlsablauf. Jeder Thread besitzt einen Registerzustand und einen Stapelspeicher. Das System ordnet jedem Thread zusätzlich Zustandsinformationen zu, welche seine Einplanbarkeit betreffen. Diese umfassen die Taskzuweisungspriorität des Threads und die Prozessoraffinität, welche festlegt, auf welchen Prozessoren ein Thread ausgeführt werden kann.
1(A) zeigt einen Taskzuweiser mit einfacher Warteschlange nach dem Stand der Technik für ein Multiprozessorsystem, wobei ein Taskzuweiser eine Matrix 101 von Taskzuweisungswarteschlangen verwendet, welche nach Taskzuweisungspriorität indiziert sind. Wenn in 1(A) ein Thread lauffähig gemacht wird, wird er in einer Taskzuweisungswarteschlange, typischerweise am Ende, entsprechend seiner Taskzuweisungspriorität platziert. Wenn ein Prozessor auf einen neuen Thread umschaltet, wählt er immer den Thread am Anfang der nicht leeren Taskzuweisungswarteschlange höchster Priorität. Threads können eine Taskzuweisungspriorität nicht verändern während sie in einer Taskzuweisungswarteschlange sind; der Thread muss zuerst entfernt werden, seine Taskzuweisungspriorität eingestellt werden, und dann kann der Thread in einer unterschiedlichen Taskzuweisungswarteschlange platziert werden.
1(B) illustriert einen Taskzuweiser mit einfacher Warteschlange nach dem Stand der Technik, wo ein Thread, welcher in einem Synchronisationsobjekt warten muss, in einer Schlafwarteschlange 102 platziert wird, welche dem Synchronisationsobjekt zugeordnet ist. Die Schlafwarteschlange wird in der Reihenfolge der Taskzuweisungspriorität gehalten, so dass, wenn das Synchronisationsobjekt freigegeben wird, sich der Thread mit höchster Priorität, welcher auf das Objekt wartet, am Anfang der Schlafwarteschlange befindet.
Das in 1(A) und 1(B) gezeigte System nach dem Stand der Technik verwendet beim Einplanen eine einfache Schleifensperre (Spin-Lock), um alle Einplanungsoperationen zu schützen. Jeder Einplaner kann die Sperre erhalten oder aufheben. Wenn die Einplanungssperre gegenwärtig von einem Prozessor gehalten wird, „drehen" („spin") andere Prozessoren, welche die Einplanungssperre brauchen, beim Warten auf Zugang an der Sperre. Insbesondere wird, wann immer die Freigabe eines Synchronisationsobjekts irgendeinen Thread lauffähig macht, die Einplanungssperre gehalten, während der Thread in der Taskzuweisungswarteschlange platziert wird. Um eine Störung und Verzögerungen von Unterbrechungsroutinen zu vermeiden, läuft der Halter der Einplanungssperre auf einer erhöhten Unterbrechungsebene.
Folglich kann beim in 1(A) und 1(B) gezeigten System nach dem Stand der Technik der Konflikt um eine einzelne Einplanungssperre bewirken, dass Prozessoren hintereinander warten, um eine Einplanungsentscheidung zu treffen, was zu einigen ungenutzten Prozessoren führt. Im Ergebnis wird nicht nur der ganze Zweck der Verwendung mehrerer Prozessoren, eine schnelle Verarbeitung von Jobs zu erzielen, zunichte gemacht, sondern es bleiben wertvolle Computer-Betriebsmittel ungenutzt.
Diese Situation kann etwas verbessert werden, indem ein System mit mehreren Taskzuweisungswarteschlangen eingeführt wird, wobei zugelassen wird, dass jeder Prozessor seine eigene Taskzuweisungswarteschlange und seine eigene Einplanungssperre aufweist. Ein derartiges System mit mehreren Warteschlangen und mehreren Sperren, wie bei BLACK: „Scheduling Support for concurrency and Parallelism in the Mach Operating System", Computer, Bd. 23, Nr. 5, Mai 1990 offenbart, wird in 2(A) gezeigt, wobei jeder Prozessor seine eigene Taskzuweiserwarteschlange unterhält. Beispielsweise gibt es eine separate Taskzuweisungswarteschlange, welche jedem der Prozessoren 1, 2,..., N in 2(A) zugeordnet ist.
Beim System der 2(A) beginnt ein Prozessor, welcher bereit ist, einen neuen Thread zu übernehmen, nach einem lauffähigen Thread in seiner eigenen Taskzuweisungswarteschlange zu suchen. Wenn seine eigene Warteschlange nicht leer ist, übernimmt der Prozessor den verfügbaren lauffähigen Thread mit der höchsten Priorität aus seiner eigenen Warteschlange. Wenn seine eigene Warteschlange jedoch leer ist, beginnt der Prozessor, andere Taskzuweisungswarteschlangen nach verfügbaren Threads zu durchsuchen. Noch unter Bezugnahme auf 2(A) kann der Prozessor, falls es einen verfügbaren lauffähigen Thread in irgendeiner anderen Taskzuweisungswarteschlange gibt, außer der Thread ist markiert als nur auf einem bestimmten Prozessor lauffähig, den Thread aus der anderen Taskzuweisungswarteschlange übernehmen und den Thread ausführen. Taskzuweiser nach dem Stand der Technik, wie beispielsweise in 1 und 2 gezeigt, sind jedoch nicht für Echtzeit-Anwendungen geeignet.
Ein Echtzeit-Computersystem wird entworfen, um eine erforderliche Leistungsebene oder Verarbeitung innerhalb einer begrenzten Zeitdauer zu liefern. Echtzeit-Computersysteme finden in den Bereichen der virtuellen Realität, der Fabrikautomatisierung, der Robotik, der Telekonferenz und des Multimedia-Rundfunksystems Anwendungen. Diese Anwendungen sind typischerweise „gemischte Arbeitsweisen", d. h. sie sind in einplanbare Entitäten aufteilbar, von welchen einige Echtzeit-Reaktion erfordern. Um eine Reaktion in begrenzter Zeit zu erzielen, erfordern zeitkritische Anwendungen eine Kontrolle über ihr Einplanungsverhalten.
Wenn ein Multiprozessorsystem eingesetzt wird, um Echtzeit-Anwendungen zu unterstützen, wird die Einplanung von Prozessen sogar noch komplizierter, und folglich muss ein Echtzeit-Betriebssystem in der Lage sein, zeitkritischen Tasks irgendeine Echtzeit-Fähigkeit bereitzustellen. Folglich muss ein Echtzeit-System in der Lage sein, sofort eine Reaktion auf bestimmte externe Ereignisse und eine Einplanung bestimmter Prozesse bereitzustellen, um sie innerhalb einer bestimmten Zeitbegrenzung nach Auftreten eines Ereignisses auszuführen. Ein Echtzeit-System muss auch garantieren, dass das Betriebssystem einen bestimmten Prozess innerhalb einer festgelegten Zeitbegrenzung einplanen kann.
Um Echtzeit-Threads hoher Priorität so schnell wie möglich zu bedienen, kann das System in 2(A) so verbessert werden, dass es eine separate Echtzeit-Warteschlange aufweist, wie in 2(B) gezeigt. In 2(B) wird eine zusätzliche Superwarteschlange auf einer höheren Ebene den mehreren Taskzuweiserwarteschlangen hinzugefügt, um eine systemweite Sichtbarkeit lauffähiger Echtzeit-Threads bereitzustellen. Die Superwarteschlange ist eine Warteschlange von Taskzuweisungswarteschlangen, welche diejenigen Prozessorwarteschlangen enthält, die ungebundene Echtzeit-Threads mit einer Priorität halten, welche höher ist als irgendeine vorbestimmte Schwellprioritätsebene. Folglich listet die Superwarteschlange diejenigen Prozessoren auf, deren Thread mit der höchsten Priorität eine ausreichende Priorität aufweist, um als ein Echtzeit-Thread betrachtet zu werden.
Unter Bezugnahme auf 2(B) sucht ein Prozessor zuerst in der Superwarteschlange nach lauffähigen Threads. Falls es eine nicht leere Warteschlange hoher Priorität in der Superwarteschlange gibt, übernimmt der Prozessor den lauffähigen Thread mit der höchsten Priorität aus dieser Warteschlange. Falls die Superwarteschlange leer ist, prüft der Prozessor seine eigene Warteschlange. Falls seine eigene Warteschlange noch leer ist, geht der Prozessor zu anderen Taskzuweiserwarteschlangen für lauffähige Threads weiter. Falls es irgendeine nichtleere Taskzuweiserwarteschlange im System gibt, übernimmt der Prozessor den lauffähigen Thread mit der höchsten Priorität aus dieser Warteschlange und beginnt, den Thread auszuführen.
Echtzeit-Threads würden zugewiesen durch Untersuchung der Superwarteschlange. Wenn folglich ein Prozessor einen Thread zum Ausführen auswählt, untersucht er zuerst die Superwarteschlange und dann seine eigene Warteschlange.
Obwohl oben stehende Lösung, welche mit Bezug auf 2(B) behandelt wurde, eine Verbesserung gegenüber dem Stand der Technik darstellt und eine unkomplizierte Lösung für eine Echtzeit-Multiprozessoreinplanung bietet, stellt sie ein kritisches Wettlaufproblem beim Einplanen von Echtzeit-Threads dar. Beispielsweise kann eine Wettlaufsituation im folgenden Szenario erzeugt werden: es wird vorausgesetzt, dass die Prozessoren 1 und 2 benachrichtigt werden, dass es zwei lauffähige Echtzeit-Threads in der Superwarteschlange gibt. Die Prozessoren 1 und 2 fahren fort, die Superwarteschlange zu prüfen, um herauszufinden, welche Prozessor-Warteschlangen die beiden Threads aufweisen. Die beiden Echtzeit-Threads befinden sich beispielsweise in der Taskzuweisungswarteschlange des Prozessors 3 und des Prozessors 4, wobei der Echtzeit-Thread in der Warteschlange des Prozessors 3 eine höhere Priorität aufweist als der in der Warteschlange des Prozessors 4.
Nach dem Herausfinden aus der Superwarteschlange, dass sich der Echtzeit-Thread mit der höchsten Priorität in der Taskzuweisungswarteschlange des Prozessors 3 befindet, versuchen beide Prozessoren 1 und 2 zuzugreifen und den Echtzeit-Thread aus der Warteschlange des Prozessors 3 zu übernehmen. Prozessor 1 greift jedoch zuerst auf die Warteschlange des Prozessors 3 zu und übernimmt den Echtzeit-Thread. Dann versucht Prozessor 2, welcher noch nach einem Thread in der Warteschlange des Prozessors 3 sucht und nicht weiß, dass der Echtzeit-Thread mit der höchsten Priorität gerade von Prozessor 1 übernommen wurde, den nächsten Thread mit der höchsten Priorität aus der Warteschlange des Prozessors 3 zu übernehmen. Der nächste lauffähige Thread mit der höchsten Priorität in der Warteschlange des Prozessors 3 kann jedoch einer mit einer sehr geringen Priorität sein. Im Ergebnis wird der Echtzeit-Thread in der Warteschlange des Prozessors 4 in der Warteschlange zurückgelassen, wobei er darauf wartet, eingeplant zu werden, bis irgendein Prozessor verfügbar wird, ihn zu bedienen.
Beim oben stehenden Szenario, welches ein Beispiel vieler möglicher Nachteile wegen ungenauer Synchronisation ist, führt der Mangel an Kommunikation zwischen den Prozessoren 1 und 2 zu einer Wettlaufsituation, welche dazu führt, dass ein Echtzeit-Thread höherer Priorität in einer Warteschlange wartet, während ein Thread geringerer Priorität bedient wird. Eine ungenaue Systemsynchronisation kann folglich Terminüberschreitungen von Echtzeit-Threads sogar bei niedrigen Pegeln der Prozessorauslastung bewirken.
Folglich können Taskzuweiser nach dem Stand der Technik, welche voll von Wettlaufsituationen und Fehlern bei der Implementierung des Taskzuweisers sind, zu einem Nicht-Echtzeit-Verhalten von Echtzeit-(RT)-Threads führen und in manchen Fällen das System blockieren.
Folglich werden gegenwärtig verschiedene Vorrichtungen und Verfahren eingesetzt, um einen Taskzuweiser für ein Multiprozessorsystem bereitzustellen. Sie sind jedoch nicht für Echtzeit-Anwendungen geeignet, liefern für viele Anwendungen keinen Echtzeit-Dienst und sind voll von Wettlaufsituationen. Dementsprechend wäre es vorteilhaft, einen Taskzuweiser bereitzustellen, welcher effizient sowohl Timesharing-(TS)- und Echtzeit-(RT)-Einplanungs verfahrensweisen für ein Multiprozessorsystem unterstützen kann.
OFFENBARUNG DER ERFINDUNG
Die vorliegende Erfindung wird in den beiliegenden Ansprüchen definiert und stellt einen Prozesseinplaner oder Taskzuweiser für ein Multiprozessorsystem für Echtzeit-Anwendungen bereit. Bei den Ausführungsformen der vorliegenden Erfindung weist jeder Prozessor seine eigene Warteschlange und einen Taskzuweiser auf, so dass das System eine Taskzuweisungswarteschlange für jeden Prozessor und eine separate globale Taskzuweisungswarteschlange für ungebundene Echtzeit-Threads höherer Priorität unterhalten kann. Jede Warteschlange weist eine separate Einplanungssperre auf, welche ihr zugeordnet ist, um Einplanungsoperationen zu schützen. Es wird zugelassen, dass ein Prozessor einen neuen Thread in der globalen Echtzeit-Warteschlange hoher Priorität, in der eigenen Warteschlange des Prozessors oder in der Warteschlange jedes anderen Prozessors platziert.
Ein Taskzuweiser des Prozessors kann einen Thread zur Ausführung aus der globalen Echtzeit-Warteschlange, aus einer eigenen Warteschlange des Prozessors oder einer Warteschlange eines anderen Prozessors als ein auszuführender Kandidaten-Thread auf der Grundlage von Prioritätsvariablen auswählen, welche jeder Warteschlange zugeordnet sind. Die Untersuchung der Prioritäten in Warteschlangen zur Thread-Auswahl erfordert keine Einplanungssperren, und eine Fehlkommunikation wird durch Verwendung eines geeigneten Synchronisationsalgorithmus verhindert. Wenn ein Kandidaten-Thread zur Ausführung ausgewählt ist, benachrichtigt der Prozessor andere Prozessoren über seine Auswahl und fährt fort, sie gegenüber Threads in der globalen Echtzeit-Warteschlange und in der eigenen Taskzuweisungswarteschlange des Prozessors zu verifizieren, um den lauffähigen Thread höchster Priorität im System auszuwählen.
Folglich lässt die vorliegende Erfindung zu, dass der Taskzuweiser Wettlaufsituationen verhindert und Sperrkonflikte minimiert, während er sicherstellt, dass Threads hoher Priorität so schnell wie möglich zugewiesen werden. Die bevorzugte Ausführungsform der vorliegenden Erfindung wird durch eine Synchronisation zwischen den Operationen der Zuweisung eines Threads und des Lauffähigmachens eines Threads implementiert.
BESCHREIBUNG DER ZEICHNUNGEN
Die Erfindung wird nun beispielhaft unter Bezugnahme auf die folgenden Zeichnungen beschrieben:
1(A) zeigt ein Taskzuweisersystem mit einfacher Warteschlange nach dem Stand der Technik für eine Multiprozessorumgebung, wobei ein Taskzuweiser eine Matrix von Taskzuweisungswarteschlangen verwendet, welche durch die Taskzuweisungspriorität indiziert sind.
1(B) zeigt ein Taskzuweisersystem mit einfacher Warteschlange nach dem Stand der Technik, wobei blockierte Threads auf ein Synchronisationsobjekt warten.
2(A) zeigt ein System mit mehreren Warteschlangen und mehreren Sperren.
2(B) zeigt ein System mit mehreren Warteschlangen und mehreren Sperren mit einer zusätzlichen Superwarteschlange.
3 illustriert einen Universalcomputer, welcher für eine Implementierung einer Ausführungsform der Erfindung geeignet ist.
4(A) zeigt eine bevorzugte Ausführungsform eines Systems mit mehreren Taskzuweiserwarteschlangen gemäß der vorliegenden Erfindung.
4(B) zeigt eine Struktur einer Taskzuweisungswarteschlange ausführlicher, welche eine Taskzuweisungswarteschlange für einen Prozessor der 4(A) verwendet.
5 zeigt eine bevorzugte Konfiguration des Multiprozessorsystems gemäß der vorliegenden Erfindung.
6 zeigt ein Ablaufdiagramm, welches einen Taskzuweiser beschreibt, welcher einen Thread zum Ausführen auf einem Prozessor einplant.
7 zeigt ein Ablaufdiagramm, welches den Thread-Auswahlprozess des Schritts 601 der 6 ausführlicher beschreibt.
8 illustriert eine globale Strategie zur Prioritätsauflistung.
9 zeigt ein Ablaufdiagramm, welches einen Prozessor beschreibt, welcher einen Thread lauffähig macht.
10 illustriert ein Ablaufdiagramm, welches den Schritt 905 der Prozessorauswahl der 9 ausführlicher beschreibt.
AUSFÜHRUNGSFORMEN DER ERFINDUNG
Die vorliegende Erfindung ist ein Multiprozessoreinplanungssystem, welches mit Bezug auf Echtzeit-Anwendungen beschrieben wird. In der folgenden Beschreibung werden zahlreiche spezifische Einzelheiten dargelegt, um eine gründlichere Beschreibung der vorliegenden Erfindung bereitzustellen. Es wird jedoch Durchschnittsfachleuten offenkundig, dass die vorliegende Erfindung ohne diese spezifischen Einzelheiten betrieben werden kann. In anderen Fällen wurden wohlbekannte Merkmale nicht ausführlich beschrieben, um die vorliegende Erfindung nicht zu verschleiern.
Bei einem Multiprozessorsystem gibt es grundsätzlich zwei Entscheidungen zur Zuweisung von Betriebsmitteln, welche getroffen werden. Eine ist, wo Code und Daten im physikalischen Speicher lokalisiert werden sollen, und die andere ist, auf welchem Prozessor jeder Prozess ausgeführt werden soll – eine Zuweisungsentscheidung oder Prozessorverwaltung. Diese Entscheidungen sind in einem Multiprozessorsystem eine Herausforderung, und eine Optimierung der Prozessorverwaltung ist in einem Multiprozessorsystem wichtig.
Eine Zuweisungsentscheidung oder eine Job- und Prozessoreinplanung umfasst mehrstufige Einplanungsverfahrensweisen: Einplanung auf hoher Ebene oder Job-Einplanung, welche festlegt, welche Jobs für ein aktives Konkurrieren um Systembetriebsmittel zugelassen werden sollen; Einplanung auf mittlerer Ebene, welche festlegt, welche Prozesse für ein Konkurrieren um Systembetriebsmittel zugelassen werden sollen; und Einplanung auf unterer Ebene, welche von einem Taskzuweiser durchgeführt wird. Ein Taskzuweiser legt fest, welcher bereite Prozess welchem Prozessor zugeordnet wird, wenn er nächstes Mal lauffähig wird.
Es wird ein vollständig präemptives Einplanungsschema bei der bevorzugten Ausführungsform der vorliegenden Erfindung verwendet, bei welcher ein Prozessor von einem Prozess abgezogen werden kann, welchen er gegenwärtig ausführt, um einen anderen Prozess höherer Priorität zur Ausführung kommen zu lassen. Obwohl eine Unterbrechung zusätzlichen Aufwand wegen der Programmumschaltung einschließt, ist sie bei Systemen nützlich, bei welchen Prozesse hoher Priorität schnelle Aufmerksamkeit erfordern. Bei Echtzeit-Systemen kann beispielsweise das Überschreiten eines festen Termins fatale Folgen herbeiführen und folglich ist eine präemptive Einplanung zum Garantieren annehmbarer Dienstzeiten notwendig.
Bei der vorliegenden Erfindung führt ein Prozesseinplaner oder Taskzuweiser seine Funktion jedes Mal durch, wenn ein laufender Prozess blockiert oder unterbrochen wird. Sein Zweck ist es, den nächsten laufenden Prozess aus dem Satz bereiter Warteschlangen auszuwählen. Der Taskzuweiser befindet sich im Betriebssystemkern und überwacht die bereiten Warteschlangen und Bearbeitungsanforderungen zum Laden von Anwendungen. Dies schließt ein Erzeugen all der Tasks und Threads der Anwendung, das Reservieren von Speicher und das Laden des Codes und der Daten in den Speicher ein. Alle Betriebsmittel werden reserviert, bevor eine Anwendung als erfolgreich geladen und zum Ausführen bereit betrachtet wird. Folglich sollte ein Taskzuweiser ziemlich effizient sein, um zusätzlichen Betriebssystemaufwand zu minimieren.
Bei einem Multiprozessorsystem muss eine Echtzeit-Prioritätseinplanung eine Bedingung erfüllen: für jeden Prozessor gibt es in keiner Warteschlange einen Thread, welcher auf diesem Prozessor ausgeführt werden kann. Vom Standpunkt des Durchsatzes ist es am besten, dass jeder Prozessor seine eigene Taskzuweisungswarteschlange aufweist und folglich die Sperrkonkurrenz zwischen Prozessoren minimiert wird.
Diese Ausführungsform der vorliegenden Erfindung schlägt deshalb ein Taskzuweisermodell vor, welches eine separate globale Taskzuweisungswarteschlange für ungebundene Echtzeit-Threads höherer Priorität zusätzlich zu einer eigenen Taskzuweisungswarteschlange der Prozessoren unterhält. Statt zu garantieren, dass der Taskzuweiser immer korrekte Entscheidungen trifft, verwendet diese Ausführungsform der vorliegenden Erfindung weiterhin ein Auswahl- und Verifizierungsschema. Beide dieser Merkmale erlauben dieser Ausführungsform der vorliegendem Erfindung, die Sperrkonkurrenz zu minimieren, während sie sicher stellen, dass Threads hoher Priorität so schnell wie möglich zugewiesen werden. Dies wird durch eine Synchronisation zwischen den Operationen der Zuweisung eines Threads und des Lauffähigmachens eines Threads implementiert. Das Taskzuweisermodell dieser Ausführungsform der vorliegenden Erfindung wird unter SunOS Solaris 2.5 implementiert.
Die vorliegende Erfindung kann auf einem Universalcomputer, wie beispielsweise in 3 illustriert, implementiert werden. Eine Tastatur 310 und eine Maus 311 sind an einen bidirektionalen Systembus 318 angeschlossen. Die Tastatur und die Maus dienen zum Einbringen einer Benutzereingabe in das Computersystem und zum Kommunizieren dieser Benutzereingabe an eine CPU 313. Das Computersystem der 3 umfasst auch einen Videospeicher 314, einen Hauptspeicher 315 und einen Massenspeicher 312, welche alle zusammen mit einer Tastatur 310, einer Maus 311 und einer CPU 313 an einen bidirektionalen Systembus 318 angeschlossen sind. Der Massenspeicher 312 kann sowohl feste als auch austauschbare Medien, wie beispielsweise magnetische, optische oder magnetooptische Speichersysteme oder jede andere verfügbare Massenspeichertechnik, umfassen. Bus 318 kann beispielsweise 32 Adressleitungen zum Adressieren des Videospeichers 314 oder des Hauptspeichers 315 enthalten. Der System-Bus 318 umfasst auch beispielsweise einen 32-Bit-DATEN-Bus zum Übermitteln von DATEN zwischen und unter den Komponenten, wie beispielsweise der CPU 313, dem Hauptspeicher 315, dem Videospeicher 314 und dem Massenspeicher 312. Ersatzweise können Multiplex-DATEN-/Adressleitungen statt separater DATEN- und Adressleitungen verwendet werden.
Hauptspeicher 315 besteht aus dynamischem Schreib-/Lesespeicher (DRAM). Videospeicher 314 ist ein Video-Schreib-/Lesespeicher mit zwei Ports. Ein Port des Videospeichers 314 ist an einen Videoverstärker 316 angeschlossen. Der Videoverstärker 316 wird verwendet, um den Kathodenstrahlröhren-(CRT)-Rastermonitor 317 zu betreiben. Videoverstärker 316 ist in der Technik wohlbekannt und kann durch jedes geeignete Mittel implementiert werden. Dieser Schaltkomplex wandelt Pixel-DATEN, welche im Videospeicher 314 gespeichert sind, in ein Rastersignal um, welches zur Verwendung durch Monitor 317 geeignet ist. Monitor 317 ist ein Monitortyp, welcher zum Anzeigen von grafischen Bildern geeignet ist.
Das oben beschriebene Computersystem ist nur beispielhaft. Die vorliegende Erfindung kann in jedem Computersystem- oder Programmier- oder Verarbeitungsumgebungstyp implementiert werden.
4(A) zeigt ein Warteschlangensystem mit mehreren Taskzuweisern gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung. Unter Bezugnahme auf 4(A) umfasst das Warteschlangensystem mit mehreren Taskzuweisern separate Taskzuweiserwarteschlangen 401, 402,..., 403 für Prozessoren 1, 2,..., N und zusätzlich eine globale Echtzeit-Warteschlange hoher Priorität 404, welche verwendet wird, um Echtzeit-Threads hoher Priorität zu halten. Jede Taskzuweisungswarteschlange weist ihre eigene Einplanungssperre auf, welche ihr zugeordnet ist, um alle Einplanungsoperationen so zu schützen, dass jeder Prozessor, welcher versucht einen Thread aus einer Warteschlange zuzuweisen, eine Sperre für diese Warteschlange erhalten muss, bevor er den Thread aus der Warteschlange übernehmen kann. Folglich ist eine Sperrkonkurrenz bei der vorliegenden Erfindung mit mehreren Einplanungssperren für mehrere Taskzuweisungswarteschlangen reduziert, im Gegensatz zu Einplanern nach dem Stand der Technik, wobei eine einzelne Einplanungssperre für eine einzelne Taskzuweisungswarteschlange für alle Prozessoren verwendet wird.
Bei der bevorzugten Ausführungsform der 4(A) verwendet ein Taskzuweiser eine Matrix von Taskzuweisungswarteschlangen, welche durch eine Taskzuweisungspriorität indiziert sind. Wenn ein Thread lauffähig gemacht wird, wird er auch in einer Taskzuweisungswarteschlange entsprechend seiner Taskzuweisungspriorität typischerweise am Ende platziert. Es können jedoch andere Schemata für eine Warteschlangenbildung statt der FIFO-Thread-Warteschlangenbildung verwendet werden. Beispielsweise kann ein LIFO- (Last In First Out, Kellerprinzip), ein SJF- (Shortest Job First, Prinzip des kleinsten Jobs), ein SRT- (Shortest Remaining Time, Prinzip der kürzesten Frist) oder ein anderer fortschrittlicher Mechanismus zur Warteschlangenbildung in Abhängigkeit von den Einplanungsanforderungen der Echtzeit-Anwendung verwendet werden.
4(B) zeigt eine Struktur einer Taskzuweisungswarteschlange ausführlicher unter Verwendung einer Taskzuweisungswarteschlange für Prozessor 1 der 4(A). In 4(B) sind die Threads 1, 2 und 3 mit irgendeinem Prioritätswert in die Taskzuweisungswarteschlange eingereiht. Thread 1 befindet sich ganz oben in der Warteschlange, und falls ein FIFO-System angewendet wird, wäre er der erste Thread in dieser Prioritätskategorie, welcher aus der Warteschlange zur Ausführung zugewiesen wird. Die Threads in 4(B) weisen auch Merkmale der Prozessoraffinität auf, welche ihnen zugeordnet sind.
Eine Prozessoraffinität wird verwendet, um festzustellen, auf welchen Prozessoren ein Thread ausgeführt werden kann. Die meisten Threads sind auf allen Prozessoren ausführbar und werden dementsprechend so gekennzeichnet. Es gibt jedoch Threads, welche nur auf einem bestimmten Prozessor und auf keinem anderen Prozessor ausführbar sind. Diesem Thread wird dann eine Prozessoraffinität für diesen bestimmten bezeichneten Prozessor gegeben. Wenn ein Thread eine Affinität für einen bestimmten Prozessor aufweist, kann er nicht von anderen Prozessoren entwendet oder auf sie abgezogen werden. Der Thread 2 in 4(B) weist beispielsweise eine Prozessoraffinität für Prozessor 1 auf und ist nur auf Prozessor 1 ausführbar. Folglich kann ein Thread, welcher nur auf einem Prozessor lauffähig ist, d. h. ein gebundener Thread, nur in der Taskzuweisungswarteschlange seines gebundenen Prozessors erscheinen und wird nur durch diesen Prozessor zugewiesen.
Damit ein Prozessor in der Lage ist, einen Thread anderen Prozessoren zu entwenden, muss der Thread auf dem entwendenden Prozessor lauffähig sein. Unter Bezugnahme beispielsweise auf 4(B) kennen die Threads 1 und 3 entwendet, aus der Warteschlange übernommen und durch andere Prozessoren als Prozessor 1 ausgeführt werden.
5 zeigt eine Konfiguration des Mutiprozessorsystems gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung. Jeder Prozessor 1, 2,..., N weist seinen eigenen Einplaner und seine eigene Taskzuweisungswarteschlange auf, wie in 5 gezeigt. Beispielsweise sind der Einplaner 505 und die Taskzuweisungswarteschlange 509 über einen Bus an Prozessor 1 angeschlossen. Einplaner oder Taskzuweiser legen fest, wann und welche Threads zur Ausführung auf den Systemprozessoren zugewiesen werden sollen. Die Einplaner 1, 2,..., N und damit die Prozessoren 1, 2,...,, N sind über einen Bus an eine globale Echtzeit-Warteschlange hoher Priorität 501 und einen gemeinsam genutzten Speicher 503 angeschlossen. Threads können unter Verwendung von Synchronisationsobjekten interagieren, welche gemeinsam von allen Prozessoren genutzt werden.
Jedem Prozessor in 5 ist ein Satz von Einplanungsvariablen zugeordnet, welche für verschiedene Zwecke verwendet werden. Beispielsweise registrieren die Variablen cpu_runrun und cpu_kprunrun Anforderungen zur Unterbrechung des aktuellen Threads und werden verwendet, um Einplanungsentscheidungen zu treffen. Andere Variablen schließen cpu_dispthread und cpu_thread ein. Die Variable cpu_thread betrifft den Thread, welcher gegenwärtig auf einem Prozessor ausgeführt wird. Die Variable cpu_dispthread wird zur Kommunikation mit anderen Prozessoren verwendet und registriert die Identität des Threads, welcher zuletzt zur Zuweisung an den Prozessor ausgewählt wurde.
Die Variable cpu_runrun oder cpu_kprunrun wird durch andere Prozessoren für einen Prozessor eingestellt, wenn sie einen neuen Thread in die Warteschlange des Prozessors setzen und feststellen, dass der Prozessor gerade einen Thread mit niedrigerer Priorität als der neue Thread ausführt, welcher gerade in die Warteschlange des Prozessors gesetzt wurde. Die Variable cpu_kprunrun weist eine höhere Priorität als die Variable cpu_runrun auf. Wenn die Variable cpu_runrun oder cpu_kprunrun eingestellt ist, muss der Prozessor eine Einplanungsentscheidung treffen, den aktuellen Thread zu unterbrechen und einen neuen Thread höherer Priorität zu bedienen.
Jeder Prozessor in 5 ist in der Lage, einen Thread in jede der Warteschlangen im System. zur Ausführung zu setzen. Beispielsweise kann Prozessor 1 einen neuen Thread in seine eigene Warteschlange, in die globale Echtzeit-Warteschlange hoher Priorität oder in Warteschlangen anderer Prozessoren setzen, außer der neue Thread weist ein Merkmal einer bestimmten Prozessoraffinität auf.
Obwohl 5 Multiprozessoren zeigt, welche über einen einzelnen Bus verbunden sind, sind selbstverständlich andere alternative Architekturen für eine Ausführungsform der vorliegenden Erfindung möglich. Beispielsweise kann eine Multibus-Multiprozessororganisation oder ein Crossbar-Schaltsystem als Verbindungsnetzwerk verwendet werden, um das Leistungsvermögen des Multiprozessorsystems zu verbessern.
Um einen Thread einem Prozessor zuzuweisen oder einzuplanen, muss der Prozessor einen Thread zum Ausführen auffinden. 6 zeigt ein Ablaufdiagramm, welches einen Taskzuweiser, welcher einen Thread zum Ausführen auf einem Prozessor einplant, unter Verwendung eines Auswahl- und Verifizierungsschemas beschreibt.
Unter Bezugnahme auf 6 beginnt ein Prozessor, welcher für einen nächsten Thread bereit ist, im Schritt 601 einen Thread zum Ausführen auszuwählen, indem er die Echtzeit-Warteschlange hoher Priorität prüft, um zu sehen, ob sie irgendwelche Einträge aufweist. 7 zeigt ein Ablaufdiagramm, welches den Thread-Auswahlprozess des Schritts 601 ausführlicher beschreibt.
Die Untersuchung der Prioritäten in Warteschlangen schließt ein Prüfen einer lokalen Variable ein, welche jedem Prozessor zugeordnet ist, und erfordert keine Sperren. Beispielsweise kann eine Prioritätsvariable disp_maxrunpri verwendet werden, um eine maximale Prioritätsebene in einer Warteschlange zu bezeichnen. Dann kann Variable disp_maxrunpri sowohl in der Taskzuweisungswarteschlange des Prozessors als auch in der Echtzeit-Warteschlange unter Verwendung irgendeines geeigneten Synchronisationsalgorithmus, wie beispielsweise eines Dekker-Algorithmus, geprüft werden, um Fehlkommunikation zu vermeiden. Es kann jedoch jeder andere geeignete Synchronisationsalgorithmus in alternativen Ausführungsformen der vorliegenden Erfindung verwendet werden. Da die zu untersuchenden Prioritätsvariablen unteilbare Variablen sind, welche in jeder Taskzuweisungswarteschlange unterhalten werden, wird jeder Einplanungsfehler, welcher durch ein Auswählen einer falschen Warteschlange bewirkt wird, in einem Verifikationsschritt abgefangen. Es ist jedoch eine Einplanungssperre erforderlich, um einen Thread aus einer ausgewählten Warteschlange zu übernehmen.
Unter Bezugnahme nun auf 7 erlangt der Taskzuweiser des Prozessors, falls im Entscheidungsblock 701 die Echtzeit-Warteschlange einen Thread höherer Priorität als seine eigene Taskzuweisungswarteschlange aufweist, eine Sperre für die Echtzeit-Warteschlange und übernimmt im Schritt 702 einen Thread höchster Priorität aus der Echtzeit-Warteschlange, wie beispielsweise aus Warteschlange 404 der 4, und fährt fort, den Thread auszuführen.
Prozessoren, welche verfügbar werden, einen nächsten Thread zu übernehmen, sperren zuerst die Echtzeit-Warteschlange, bevor sie ihre eigenen Warteschlangen prüfen, wodurch sie Threads in der Echtzeit-Warteschlange höherer Priorität vor den Threads in ihren eigenen Warteschlangen bedienen, um Echtzeit-Threads den schnellstmöglichen Dienst bereitzustellen. Falls im Entscheidungsblock 701 festgestellt wird, dass die Echtzeit-Warteschlange keine verfügbaren Threads höherer Priorität aufweist, fährt der Prozessor mit Schritt 703 fort, um seine eigene Taskzuweisungswarteschlange auf einen lauffähigen Thread hin zu prüfen. Wenn seine eigene Warteschlange nicht leer ist, dann fährt der Prozessor mit Schritt 704 fort, um eine Sperre für seine eigene Warteschlange zu erlangen, und übernimmt einen Thread höchster Priorität aus seiner eigenen Warteschlange.
Wenn die eigene Taskzuweisungswarteschlange des Prozessors leer ist, dann fährt der Prozessor mit Schritt 705 fort, wo er Taskzuweiserwarteschlangen anderer Prozessoren prüft, um einen lauffähigen Thread aufzufinden. Falls es einen lauffähigen Thread mit keiner bestimmten Prozessoraffinität in irgendeiner anderen Taskzuweisungswarteschlange gibt, erlangt der Prozessor eine Einplanungssperre für diese Taskzuweisungswarteschlange und fährt in Schritt 706 fort, den Thread vom anderen Prozessor zu entwenden.
Falls der Prozessor im Entscheidungsblock 705 keine nichtleere Taskzuweisungswarteschlange oder keine lauffähigen Threads in ihnen auffinden kann, fährt der Prozessor mit Schritt 707 fort, um einen Leerlauf-Thread auszuwählen, wodurch der Thread-Auswahlprozess vervollständigt wird. Ein Leerlauf-Thread ist ein spezieller Thread, welcher eine niedrigere Priorität aufweist als jede Taskzuweisungspriorität und nie in der Taskzuweisungswarteschlange erscheint. Ein Leerlauf-Thread wird immer zur Ausführung ausgewählt, wenn kein anderer Thread lauffähig ist, und schaltet immer um, wenn ein anderer Thread lauffähig wird.
Folglich kann ein Thread von einem Prozessor aus der Warteschlange hoher Priorität, aus seiner eigenen Taskzuweisungswarteschlange und aus Taskzuweisungswarteschlangen anderer Prozessoren im System zur Ausführung ausgewählt werden. Durch ein Prüfen zuerst der Echtzeit-Warteschlange hoher Priorität, wie beispielsweise 404, vor einem Prüfen seiner eigenen Warteschlange oder anderen Taskzuweisungswarteschlangen, gibt ein Prozessor jedoch der Echtzeit-Warteschlange eine höhere Priorität als anderen Taskzuweisungswarteschlangen. Diese globale Prioritätsauflistung wird in 8 illustriert.
Wie in 8 gezeigt, wird den Timesharing-Threads die niedrigste Priorität bei einer Job-Einplanung oder -Zuweisung gegeben. Die Timesharing-Threads werden durch ein Zeitscheibenverfahren unterstützt und dynamisch mit ein paar hundert Millisekunden pro Zeitscheibe eingeplant. Der Timesharing-Einplaner schaltet das Programm in einer Round-Robin-Weise oft genug um, um jedem Thread eine gleiche Chance zum Ausführen zu geben. Die System-Threads mit höherer Priorität als die Timesharing-Threads umfassen spezielle System-Threads und Unterbrechungs-Threads. Unterbrechungs-Threads wird immer die höchste Priorität im System gegeben.
Echtzeit-Threads liegen zwischen den Unterbrechungs-Threads und den System-Threads in 8. Echtzeit-Threads werden strikt auf der Grundlage ihrer Priorität und der ihnen zugeordneten Zeitmenge eingeplant. Eine Zeitmenge oder Zeitscheibe wird einem Thread zugeordnet, um den Betrag der Prozessorzeit zu begrenzen, welche zum Ausführen des Threads zugelassen wird. Falls ein Thread nicht beendet wird, bevor seine Zeitmenge abläuft, wird der Thread unterbrochen, und der nächste wartende Thread höchster Priorität wird zum Ausführen zugewiesen. Beispielsweise wird ein Echtzeit-Thread mit unendlicher Zeitmenge ausgeführt, bis er beendet, blockiert oder unterbrochen wird.
Die Kriterien zum Festlegen, welche Prioritätsebenen als Trennlinien für verschiedene Prioritätsbereiche in 8 verwendet werden können, und damit welcher Prioritäts-Thread sich qualifiziert, beispielsweise in der globalen Echtzeit-Warteschlange zu sein, können durch Betrachten einer Anzahl von Faktoren eingestellt werden. Beispielsweise werden Threads in der Echtzeit-Warteschlange auf Ansprechbarkeit optimiert, während Threads, welche sich nicht in der Echtzeit-Warteschlange befinden, auf Durchsatz optimiert werden, wobei die Anzahl von pro Zeiteinheit ausgeführten Befehlen maximiert wird.
Unter Bezugnahme wieder auf 6 fährt der Prozessor nach Auswählen eines Kandidaten-Threads zum Ausführen in Schritt 601 mit Schritt 602 fort, wo er die Einplanungssperre, welche er im Schritt 601 erlangt hat, nach Rundsenden einer vorläufigen Benachrichtigung an andere Prozessoren freigibt, dass er den ausgewählten Kandidaten-Thread ausführen wird, durch Einstellen lokaler Prozessorvariablen, beispielsweise durch Einstellen einer Variable cpu_dispthread, um die aktuellste Thread-Priorität zu bezeichnen.
Im Schritt 603 löscht der Prozessor alle Benachrichtigungen, welche dieser Prozessor erneut einplanen soll, beispielsweise durch Löschen der Variablen cpu-runrun und cpu_kprunrun. Der Prozessor kann jedoch noch nicht bestätigen, dass der ausgewählte Kandidaten-Thread der lauffähige Thread höchster Priorität ist, welchen er übernehmen kann, da es eine Möglichkeit gibt, dass ein neuer Thread höherer Priorität in der globalen Echtzeit-Warteschlange oder in seiner eigenen Warteschlange durch irgendwelche anderen Prozessoren platziert worden sein könnte, während der Prozessor sich im Thread-Auswahlprozess befand. Dies kann die oben diskutierten Wettlaufsituationen im Hintergrund erzeugen, außer der Einplaner kann verifizieren, dass der ausgewählte Kandidaten-Thread die beste Wahl ist.
Folglich wird im Schritt 604 eine Verifizierung durchgeführt, ob der ausgewählte Thread eine beste mögliche Auswahl ist. Dies erfordert ein Zurückgehen zur Echtzeit-Warteschlange hoher Priorität und zu seiner eigenen Warteschlange und ein erneutes Prüfen von ihnen, um zu sehen, ob es einen neu platzierten Thread höherer Priorität in der Echtzeit-Warteschlange hoher Priorität oder in seiner eigenen Warteschlange gibt. Falls der ausgewählte Kandidaten-Thread eine höhere Priorität aufweist, als jeder andere Thread in den beiden Warteschlangen, fährt der Prozessor dann mit Schritt 605 fort, um den ausgewählten Kandidaten-Thread auszuführen.
Falls jedoch ein neuer Thread höherer Priorität in den beiden Warteschlangen aufgefunden wird, setzt der auswählende Prozessor den ausgewählten Kandidaten-Thread in irgendeine Warteschlange, wahrscheinlich in die Warteschlange, aus welcher der Thread übernommen wurde, in Abhängigkeit von einem Algorithmus zur Warteschlangenplatzierung zurück, und geht zum Schritt 601 zurück, um den Thread-Auswahlprozess erneut zu beginnen.
Das Auswahl- und Verifizierungsschema dieser Ausführungsform der vorliegenden Erfindung garantiert folglich, dass der schließlich ausgewählte Thread tatsächlich die höchste Priorität aufweisen wird, welche der Prozessor zum Ausführen auswählen kann. Auch die Wettlaufprobleme, wie beispielsweise beim Stand der Technik diskutiert, werden nun verhindert, und Threads höherer Priorität im System wird ein Echtzeit-Dienst mit minimaler Zuweisungslatenz garantiert.
9 zeigt ein Ablaufdiagramm, welches einen Prozessor beschreibt, welcher einen Thread lauffähig macht. Im Schritt 901 wird ein Prozessor für den Thread ausgewählt, und beim Entscheidungsblock 901 wird eine Festlegung getroffen, ob der Thread gebunden ist. Falls der Thread gebunden ist, wird der Thread im Schritt 902 in die Warteschlange des ausgewählten Prozessors gesetzt. Falls der Thread nicht gebunden ist, wird im Entscheidungsblock 903 eine Festlegung getroffen, ob der Thread eine Echtzeiteigenschaft aufweist. Echtzeit-Threads sind Threads, welche eine ausreichende Priorität aufweisen, dass eine Ansprechbarkeit des Systems beim Zuweisen des Threads wichtiger als der Durchsatz ist.
Es kann ein vorbestimmter Schwellenwert als ein Kriterium zum Unterscheiden von Echtzeit-Threads verwendet werden. Beispielsweise wird die Variable kppreemptpri bei der bevorzugten Ausführungsform als der Schwellenwert zum Feststellen von Echtzeit-Threads verwendet. Die Variable kppreemptpri kann in Abhängigkeit von Systemanwendungen auf jeden geeigneten Wert eingestellt werden. Falls folglich der Thread ungebunden ist und seine Priorität über kppreemptpri liegt, wird der Thread im Schritt 904 in die Echtzeit-Warteschlange hoher Priorität gesetzt. Im Schritt 905 wird ein Prozessor ausgewählt, um den Thread einzuplanen, bevor mit Schritt 907 fortgefahren wird. Falls im Schritt 903 festgestellt wird, dass der Thread eine Priorität unter kppreemptpri aufweist, fährt dann der Prozessor mit Schritt 906 fort, um den Thread auf den Prozessor zu setzen, auf welchem er zuletzt ausgeführt wurde, und fährt mit Schritt 907 fort.
10 illustriert den Prozessorauswahlschritt 905 der 9 ausführlicher. Im Schritt 1001 wird ein „bester Prozessor" als der Prozessor eingestellt, auf welchem der Thread zuletzt ausgeführt wurde. Dann stellt jeder Prozessor im System fest, ob sein aktueller Thread eine geringere Priorität besitzt als der Thread, welcher im Schritt 1002 eingefügt wird.
Falls sein aktueller Thread eine höhere Priorität besitzt, fährt er dann mit Schritt 1005 fort. Andernfalls wird eine Festlegung im Schritt 1003 getroffen, ob der aktuelle Thread des Prozessors eine geringere Priorität besitzt als der Thread auf dem „besten Prozessor". Falls der aktuelle Thread eine geringere Priorität besitzt, wird dann im Schritt 1004 der „beste Prozessor" gleich dem aktuellen Prozessor eingestellt. Im Schritt 1005 wird der „beste Prozessor" als der Zielprozessor ausgewählt, um den eingefügten Thread einzuplanen.
Unter Bezugnahme wieder auf 9 wird im Entscheidungsblock 907, nachdem ein Zielprozessor ausgewählt wurde, um den Thread auszuführen, eine Festlegung getroffen, ob der Thread eine höhere Priorität aufweist als der letzte Thread, welcher dem Prozessor anvertraut war. Falls der Thread eine höhere Priorität aufweist, wird der Prozessor im Schritt 908 durch Einstellen irgendwelcher lokaler Variablen, beispielsweise der Variablen cpu_runrun und cpu_kprunrun, benachrichtigt. Falls der Thread im Schritt 907 keine höhere Priorität aufweist, fährt der Einplanungsprozessor mit Schritt 909 fort.
Es versteht sich, dass bestimmte Ausführungsformen, welche hier beschrieben sind, die vorliegende Erfindung dadurch nicht einschränken sollen. Diese Erfindung kann in Verbindung mit jedem Multiprozessorsystem betrieben werden, welches ein präemptives Prioritätseinplanungssystem verwendet.
Folglich wurde ein Prozesseinplaner oder ein Taskzuweiser für ein Multiprozessorsystem, welches für Echtzeit-Anwendungen geeignet ist, beschrieben.

Claims

Verfahren zur Einplanung eines Threads in einem Multiprozessorsystem auf der Grundlage einer Prioritätsvoreinplanung, das Multiprozessorsystem mehrere Prozessoren umfassend; gekennzeichnet durch: Auswählen eines Threads als ein auszuführender Kandidaten-Thread aus einer von mehreren lokalen Warteschlangen und aus einer globalen Warteschlange, wobei die mehreren lokalen Taskzuweisungswarteschlangen zum Speichern von Threads einzuplanen sind, jede der mehreren lokalen Taskzuweisungswarteschlangen mit einem der mehreren Prozessoren verbunden ist, die globale Warteschlange zum Speichern von Threads einzuplanen ist, die globale Warteschlange durch jeden der mehreren Prozessoren zugänglich ist (601); Benachrichtigen von Prozessoren über den Kandidaten-Thread (602); Prüfen, ob ein Thread mit höherer Priorität in seiner lokalen Warteschlange und in der globalen Warteschlange verfügbar ist (701); Vorbelegen des ersten ausgewählten Threads und Auswählen des Threads mit höherer Priorität als der auszuführende Kandidaten-Thread, wenn es einen Thread mit höherer Priorität gibt (702, 704, 706, 707); Ausführen des Kandidaten-Threads.
Verfahren nach Anspruch 1, wobei der Schritt des Auswählens eines Threads als ein auszuführender Kandidaten-Thread ferner den Schritt des Auswählens des Threads mit höchster Priorität aus der globalen Warteschlange umfasst.
Verfahren nach Anspruch 2, wobei der Schritt des Auswählens eines Threads als ein auszuführender Kandidaten-Thread ferner den Schritt des Auswählens des Threads mit höchster Priorität aus einer der mehreren lokalen Taskzuweisungswarteschlangen umfasst, wenn es keinen lauffähigen Thread in der globalen Warteschlange gibt.
Verfahren nach Anspruch 3, wobei der Schritt des Auswählens eines Threads als ein auszuführender Kandidaten-Thread ferner den Schritt des Auswählens eines Threads aus einer lokalen Taskzuweisungswarteschlange eines anderen Prozessors umfasst, wenn es keinen lauffähigen Thread in der lokalen Taskzuweisungswarteschlange des Prozessors gibt.
Verfahren nach Anspruch 4, wobei der Schritt des Auswählens eines Threads als ein auszuführender Kandidaten-Thread ferner den Schritt des Auswählens eines ungenutzten Threads umfasst, wenn es keinen lauffähigen Thread in der lokalen Taskzuweisungswarteschlange eines anderen Prozessors gibt.
Verfahren nach Anspruch 1, ferner den folgenden Schritt umfassend: Platzieren eines Threads in einer lokalen Taskzuweisungswarteschlange eines Prozessors, wenn der Thread an den Prozessor gebunden ist (902).
Verfahren nach Anspruch 6, ferner den Schritt des Platzierens des Threads in der globalen Warteschlange umfassend, wenn der Thread eine Echtzeiteigenschaft aufweist.
Verfahren nach Anspruch 7, ferner die folgenden Schritte umfassend: Identifizieren eines letzten Prozessors, auf welchem der Thread gelaufen ist (901); Platzieren des Threads in der Taskzuweisungswarteschlange des letzten Prozessors, wenn der Thread keine Echtzeiteigenschaft aufweist (906).
Verfahren nach Anspruch 1, wobei der Schritt des Benachrichtigen von Prozessoren über den Kandidaten-Thread Folgendes umfasst: Verändern eines Speicherregisterwerts, wobei das Register durch die mehreren Prozessoren zugänglich ist.
Multiprozessoreinplanungssystem auf der Grundlage einer Prioritätsvoreinplanung, das Multiprozessoreinplanungssystem umfassend: mehrere Prozessoren (507, 513, 519); mehrere Einplaner, wobei jeder der mehreren Prozessoren mit einem der mehreren Einplaner verbunden ist (505, 511, 517); mehrere lokale Taskzuweisungswarteschlangen, wobei jeder der mehreren Prozessoren mit einer der mehreren lokalen Taskzuweisungswarteschlangen verbunden ist (509, 515, 521); gekennzeichnet durch: die mehreren Einplaner, welche mit einem Kommunikationsmedium verbunden sind (525); eine globale Taskzuweisungswarteschlange, welche mit dem Kommunikationsmedium verbunden ist (501); einen gemeinsam genutzten Speicher, welcher mit dem Kommunikationsmedium verbunden ist (503); Mittel zum Auswählen eines Threads als ein auszuführender Kandidaten-Thread aus einer von mehreren lokalen Warteschlangen und aus einer globalen Warteschlange, wobei die mehreren lokalen Taskzuweisungswarteschlangen zum Speichern von Threads einzuplanen sind, jede der mehreren lokalen Taskzuweisungswarteschlangen mit einem der mehreren Prozessoren verbunden ist, die globale Warteschlange zum Speichern von Threads einzuplanen ist, die globale Warteschlange durch jeden der mehreren Prozessoren zugänglich ist (601); Mittel zum Benachrichtigen von Prozessoren über den Kandidaten-Thread (602); Mittel zum Prüfen, ob ein Thread mit höherer Priorität in seiner lokalen Warteschlange und in der globalen Warteschlange verfügbar ist (701); Mittel zum Vorbelegen des ersten ausgewählten Threads und Auswählen des Threads mit höherer Priorität als der auszuführende Kandidaten-Thread, wenn es einen Thread mit höherer Priorität gibt (702, 704, 706, 707); Mittel zum Ausführen des Kandidaten-Threads.
Multiprozessoreinplanungssystem nach Anspruch 10, wobei die globale Taskzuweisungswarteschlange Echtzeit-Threads speichert.
Multiprozessoreinplanungssystem nach Anspruch 11, wobei der gemeinsam genutzte Speicher ein Register umfasst, welches durch die mehreren Einplaner zugänglich ist.
Fertigungsgegenstand umfassend: ein computertaugliches Medium, welches darin computerlesbaren Programmcode zum Einplanen eines Threads in einem Multiprozessorsystem auf der Grundlage einer Prioritätsvoreinplanung enthält, das Multiprozessorsystem mehrere Prozessoren umfassend; gekennzeichnet durch: computerlesbaren Code, welcher konfiguriert ist, um zu bewirken, dass einer der mehreren Prozessoren einen auszuführenden Kandidaten-Thread unter Verwendung eines Thread-Auswahl- und Verifizierungsverfahrens auswählt, die folgenden Schritte umfassend: Auswählen eines Threads als ein auszuführender Kandidaten-Thread aus einer von mehreren lokalen Taskzuweisungswarteschlangen und aus einer globalen Warteschlange, wobei die mehreren lokalen Taskzuweisungswarteschlangen zum Speichern von Threads einzuplanen sind, jede der mehreren lokalen Taskzuweisungswarteschlangen mit einem der mehreren Prozessoren verbunden ist, die globale Warteschlange zum Speichern von Threads einzuplanen ist, die globale Warteschlange durch jeden der mehreren Prozessoren zugänglich ist (601); Benachrichtigen von Prozessoren über den Kandidaten-Thread (602); Prüfen, ob ein Thread mit höherer Priorität in seiner lokalen Warteschlange und in der globalen Warteschlange verfügbar ist (701); Vorbelegen des ersten ausgewählten Threads und Auswählen des Threads mit höherer Priorität als der auszuführende Kandidaten-Thread, wenn es einen Thread mit höherer Priorität gibt (702, 704, 706, 707); computerlesbaren Code, welcher konfiguriert ist, um zu bewirken, dass der eine der mehreren Prozessoren den ausgewählten Kandidaten-Thread ausführt.
Fertigungsgegenstand nach Anspruch 13, wobei der computerlesbare Code, welcher konfiguriert ist, um zu bewirken, dass einer der mehreren Prozessoren einen Kandidaten-Thread auswählt, computerlesbaren Code umfasst, welcher konfiguriert ist, um zu bewirken, dass einer der mehreren Prozessoren den Thread mit höchster Priorität aus der globalen Warteschlange auswählt.
Fertigungsgegenstand nach Anspruch 14, wobei der computerlesbare Code, welcher konfiguriert ist, um zu bewirken, dass einer der mehreren Prozessoren einen Kandidaten-Thread auswählt, computerlesbaren Code umfasst, welcher konfiguriert ist, um zu bewirken, dass einer der mehreren Prozessoren den Thread mit höchster Priorität aus einer der mehreren lokalen Taskzuweisungswarteschlangen auswählt, wenn es keinen lauffähigen Thread in der globalen Warteschlange gibt.
Fertigungsgegenstand nach Anspruch 15, wobei der computerlesbare Code, welcher konfiguriert ist, um zu bewirken, dass einer der mehreren Prozessoren einen Kandidaten-Thread auswählt, computerlesbaren Code umfasst, welcher konfiguriert ist, um zu bewirken, dass einer der mehreren Prozessoren einen Thread aus einer lokalen Taskzuweisungswarteschlange eines anderen Prozessors auswählt, wenn es keinen lauffähigen Thread in der eigenen lokalen Taskzuweisungswarteschlange des Prozessors gibt.
Fertigungsgegenstand nach Anspruch 13, ferner umfassend: computerlesbaren Code, welcher konfiguriert ist, um zu bewirken, dass einer der mehreren Prozessoren eine der mehreren lokalen Taskzuweisungswarteschlangen auswählt, um einen Thread darin zu platzieren (901); computerlesbaren Code, welcher konfiguriert ist, um zu bewirken, dass einer der mehreren Prozessoren den Thread in der lokalen Taskzuweisungswarteschlange des Prozessors platziert, wenn der Thread gebunden ist (902).
Fertigungsgegenstand nach Anspruch 13, ferner computerlesbaren Code umfassend, welcher konfiguriert ist, um zu bewirken, dass einer der mehreren Prozessoren den Thread in der globalen Warteschlange platziert, wenn der Thread eine Echtzeiteigenschaft aufweist.
Fertigungsgegenstand nach Anspruch 18 ferner umfassend: computerlesbaren Code, welcher konfiguriert ist, um zu bewirken, dass einer der mehreren Prozessoren einen letzten Prozessor identifiziert, auf welchem der Thread gelaufen ist (901); computerlesbaren Code, welcher konfiguriert ist, um zu bewirken, dass einer der mehreren Prozessoren den Thread in der Taskzuweisungswarteschlange des letzten Prozessors platziert, wenn der Thread keine Echtzeiteigenschaft aufweist (906).
Fertigungsgegenstand nach Anspruch 13, der Schritt des Benachrichtigen von Prozessoren über den Kandidaten-Thread umfassend: computerlesbaren Code, welcher konfiguriert ist, um zu bewirken, dass einer der mehreren Prozessoren einen Speicherregisterwert verändert, wobei das Register durch die mehreren Prozessoren zugänglich ist.