DE102013214756A1

DE102013214756A1 - Verfahren und vorrichtung zum verbessern des verarbeitungsleistungsvermögens eines mehrkernprozessors

Info

Publication number: DE102013214756A1
Application number: DE102013214756.2A
Authority: DE
Inventors: Paolo Giusto; Karthik Lakshmanan; Ragunathan Rajkumar
Original assignee: Carnegie Mellon University; GM Global Technology Operations LLC
Current assignee: Carnegie Mellon University; GM Global Technology Operations LLC
Priority date: 2012-08-02
Filing date: 2013-07-29
Publication date: 2014-02-06
Anticipated expiration: 2033-07-30
Also published as: US20140040904A1; US9063796B2; CN103577376B; CN103577376A; DE102013214756B4

Abstract

Ein Verfahren zum Verwalten einer Task-Ausführung in einem Mehrkernprozessor umfasst, dass ein Spinlock eingesetzt wird, um eine dynamisch erzwingbare Beschränkung eines gegenseitigen Ausschlusses zu bewirken, und ein Multiprozessorprioritätsobergrenzenprotokoll eingesetzt wird, um zu bewirken, dass die dynamisch erzwingbare Beschränkung eines gegenseitigen Ausschlusses mehrere Tasks synchronisiert, die in dem ersten und zweiten Verarbeitungskern des Mehrkernprozessors ausgeführt werden.

Description

TECHNISCHES GEBIET
Diese Offenbarung bezieht sich auf Mehrkernprozessoren.
HINTERGRUND
Die Aussagen in diesem Abschnitt stellen lediglich Hintergrundinformationen bereit, die sich auf die vorliegende Offenbarung beziehen. Dementsprechend sollen solche Aussagen nicht Stand der Technik bilden.
Prozessoren sind elektronische Einrichtungen, die mit einer zentralen Verarbeitungseinheit/zentralen Verarbeitungseinheiten (CPU/CPUs) ausgestaltet sind und denen ein Speicher und Speichereinrichtungen zugehörig sind, die Routinen ausführen, um Tasks durchzuführen. Das Leistungsvermögen eines Prozessors kann verbessert werden, indem die Taktgeschwindigkeit der CPU erhöht wird, was zu einer schnelleren Ausführung von Routinen führt. Es besteht eine obere Grenze hinsichtlich Taktgeschwindigkeit und zugehörigem Prozessorleistungsvermögen aufgrund von mechanischen, elektrischen und thermischen Einschränkungen der Prozessorhardware und der Schnittstelleneinrichtungen.
Mehrkernprozessoren wurden eingeführt, um das Leistungsvermögen beim Ausführen von Routinen zum Durchführen von Tasks zu verbessern. Bei solchen Architekturen ermöglicht das Vorhandensein mehrerer Verarbeitungskerne das Vermögen einer wahren parallelen Task-Ausführung. Tasks, die gleichzeitig an verschiedenen Kernen ausgeführt werden, müssen jedoch möglicherweise wegen Anwendungsebenenanforderungen miteinander synchronisiert und/oder koordiniert werden.
ZUSAMMENFASSUNG
Ein Verfahren zum Verwalten einer Task-Ausführung in einem Mehrkernprozessor umfasst, dass ein Spinlock eingesetzt wird, um eine dynamisch erzwingbare Beschränkung eines gegenseitigen Ausschlusses zu bewirken, und ein Multiprozessorprioritätsobergrenzenprotokoll eingesetzt wird, um zu bewirken, dass die dynamisch erzwingbare Beschränkung eines gegenseitigen Ausschlusses mehrere Tasks synchronisiert, die in dem ersten und zweiten Verarbeitungskern des Mehrkernprozessors ausgeführt werden.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Nachstehend werden eine oder mehrere Ausführungsformen beispielhaft und mit Bezugnahme auf die begleitenden Zeichnungen beschrieben, in denen:
1-1 und 1-2 schematisch Ausführungsformen beispielhafter Mehrkernverarbeitungssysteme, die einen ersten und einen zweiten Verarbeitungskern umfassen, gemäß der Offenbarung zeigen;
2-1 schematisch ein Task-Ausführungsdiagramm zum Ausführen mehrerer Tasks in einem Mehrkernverarbeitungssystem gemäß der Offenbarung zeigt;
2-2 graphisch ein erstes Zeitdiagramm, das einer Task-Ausführung zugehörig ist, in Beziehung zu verstrichenen Zeitschritten, gemäß der Offenbarung zeigt;
2-3 graphisch ein zweites Zeitdiagramm, das einer Task-Ausführung, die einen statischen Offset einsetzt, zugehörig ist, gezeigt in Beziehung zu verstrichenen Zeitschritten, gemäß der Offenbarung zeigt;
3 graphisch eine Empfindlichkeitsbewertung von Setzen/Warten-Ereignissen für eine Basisnutzung und eine maximale Nutzung, dargestellt in Relation zu einer Brennkraftmaschinendrehzahl, gemäß der Offenbarung zeigt;
4 schematisch einen Prozess zum Analysieren des Timing von Spinlocks einschließlich eines ersten und eines zweiten Verarbeitungskerns und einer gemeinsam genutzten Softwareressource, die entweder für eine Ausführung oder Zirkulation erlangt wird, gemäß der Offenbarung zeigt;
5 graphisch ein Zeitdiagramm, das einer Task-Ausführung zugehörig ist, die Spinlocks einsetzt, gezeigt in Beziehung zu verstrichenen Zeitschritten, gemäß der Offenbarung zeigt;
6 graphisch eine Empfindlichkeitsbewertung von Spinlocks für eine Basisnutzung und eine maximale Nutzung, dargestellt in Relation zu einer Brennkraftmaschinendrehzahl, gemäß der Offenbarung zeigt;
7 schematisch eine Realisierung eines Multiprozessorprioritätsobergrenzenprotokolls, die einen ersten und einen zweiten Verarbeitungskern und eine entsprechende erste und zweite Prioritätswarteschlange, die zu einer gemeinsam genutzten Prioritätswarteschlange führen, die durch eine gemeinsam genutzte Softwareressource ausgeführt wird, gemäß der Offenbarung zeigt; und
8 graphisch ein Zeitdiagramm, das einer Ausführung des Multiprozessorprioritätsobergrenzenprotokolls zugehörig ist, gemäß der Offenbarung zeigt.
DETAILLIERTE BESCHREIBUNG
Nun auf die Zeichnungen Bezug nehmend, in denen die Darstellungen lediglich zum Zweck des Erläuterns bestimmter beispielhafter Ausführungsformen und nicht zum Zweck des Einschränkens dieser vorgesehen sind, zeigen 1-1 und 1-2 schematisch Ausführungsformen von Mehrkernverarbeitungssystemen, die einen ersten und einen zweiten Verarbeitungskern umfassen. Die hierin beschriebenen Mehrkernverarbeitungssysteme, die einen ersten und einen zweiten Verarbeitungskern umfassen, sind erläuternd und nicht einschränkend. Ferner werden die Begriffe ”erster” und ”zweiter” eingesetzt, um spezifische Verarbeitungskerne zu identifizieren und zu unterscheiden, sie werden jedoch nicht eingesetzt, um eine Reihenfolge des Vorrangs oder der Vorliebe anzugeben. Das Mehrkernverarbeitungssystem ist vorzugsweise ein homogener Mehrkernprozessor, obwohl die Offenbarung nicht darauf beschränkt ist. Die hierin beschriebenen Konzepte treffen auf jedes beliebige Mehrkernverarbeitungssystem zu, das zwei oder mehr Verarbeitungskerne einsetzt.
1-1 zeigt eine erste Ausführungsform eines homogenen Mehrkernprozessors 10, der vorzugsweise ein Einzelchipelement ist, das einen ersten und zweiten Verarbeitungskern 12 bzw. 22, einen ersten und zweiten Architekturzustand 13 bzw. 23 und einen individuellen ersten und zweiten On-Chip-L1-Speicher-Cache 14 bzw. 24 umfasst. Andere Merkmale umfassen thermische Controller 30, programmierbare Interrupt-Controller (APIC) 32 und eine Leistungsverwaltungslogik 34. Ein zweiter gemeinsam genutzter Speicher-Cache 36 und eine Busschnittstelle 38 werden eingesetzt, um mit einem externen Bus 40 zu kommunizieren.
1-2 zeigt eine zweite Ausführungsform eines homogenen Mehrkernprozessors 50, der vorzugsweise ein Einzelchipelement ist und einen ersten und einen zweiten Verarbeitungskern 52 bzw. 62 und einen individuellen ersten und zweiten On-Chip-L1-Speicher-Cache 54 bzw. 64 umfasst. Andere Merkmale umfassen bei einer Ausführungsform eine Systemanforderungsschnittstelle 66, einen Crossbar-Schalter 67 und einen ersten und zweiten Speichercontroller 58 bzw. 68, die verwendet werden, um Kommunikationen mit externen Einrichtungen zu verwalten, die Kommunikationen über einen externen Bus 40 umfassen. Die erste und zweite Ausführungsform des homogenen Mehrkernprozessors 10 und 50 sind erläuternd.
Jeder der mehreren Tasks Ti umfasst eine Sequenz von Runnables, wobei m(i) die Anzahl von Runnables, die zu Task Ti gehören, bezeichnet. Die einzelnen Runnables sind mit R_i,1 bis R_i,m(i) bezeichnet. Die ungünstigste Ausführungszeit jedes Runnable R_i,j wird als bekannt angenommen und mit C_i,j bezeichnet. Die kumulative ungünstigste Ausführungszeit von Task Ti ist die Summe aller Bestandteil-Runnable-Ausführungszeiten, welche als C_i (d. h. C_i = C_i,1 + C_i,2 + ... + C_i,m(i)) bezeichnet ist. Der Begriff P(Ti) bezeichnet den Verarbeitungskern, dem Task Ti zugeordnet ist. Es wird angenommen, dass das erste Runnable R_i,1 jedes Tasks Ti entweder periodisch zu jedem Ti oder durch ein Ereignis E_i,1 das durch einen anderen Task mit Periode Ti gesetzt wird, ausgelöst wird. Es wird angenommen, dass alle nachfolgenden Runnables R_i,j (j > 1) durch entweder den Abschluss des vorherigen Runnable R_i,j-1 oder ein externes Ereignis E_i,j ausgelöst werden. Jedem Runnable R_i,j wird auch ein Offset O_i,j ≥ 0 zugeordnet, so dass das Runnable nur für eine Ausführung berechtigt ist, nachdem O_i,j Zeiteinheiten seit der entsprechenden Freigabe von R_i,1 verstrichen sind.
Das Runnable, das ein Ereignis E_i,j auslöst oder setzt, wird durch π_i,j bezeichnet. Bei dem Szenario, bei dem ein Runnable R_i,j (j > 1) durch das vorherige Runnable R_i,j-1 ausgelöst wird, wird E_i,j durch π_i,j = R_i,j-1 gesetzt. Der Einfachheit halber ist π_i,j = O für jedes Runnable R_i,1, von dem angenommen wird, dass es periodisch zu jedem Ti ausgelöst wird. Jeder Task weist eine Deadline auf, die gleich seiner Periode Ti ist. Diese Annahme folgt der Tatsache, dass eine weitere Iteration von Task Ti startet, wenn Ti nicht in Ti Zeiteinheiten abgeschlossen ist. Es wird angenommen, dass die Prioritätszuordnung einem Rate Monotonic Scheduling folgt. Tasks mit kürzeren Perioden werden höhere Planungsprioritäten zugeordnet. Ohne Verlust der Allgemeingültigkeit wird der Task-Satz mit steigender Ordnung der Perioden und zunehmender Ordnung der Prioritäten bereitgestellt. Der Begriff hp(Ti) wird eingesetzt, um den Satz von Tasks, die eine höhere Priorität als Ti aufweisen, zu bezeichnen, und Ip(Ti) wird eingesetzt, um den Satz von Tasks zu bezeichnen, die eine niedrigere Priorität als Ti aufweisen. Der Begriff p(Ti) wird eingesetzt, um die Priorität von Task Ti zu bezeichnen. Für jede Sperre M, die eine sich gegenseitig ausschließende gemeinsam genutzte Ressource schützt, wird der Begriff I(M) eingesetzt, um die Anzahl an Tasks zu bezeichnen, die auf Sperre M zugreifen, und wird C_M eingesetzt, um die maximale Dauer darzustellen, für die M gehalten werden kann.
Synchronisationsstrukturen, wie beispielsweise Vorrangbeschränkungen, können unter Verwendung von Ereignissen für Mehrkernvorrangbeschränkungen realisiert werden. Beispielhaft werden zwei Tasks in Betracht gezogen, die Task T1, der an Verarbeitungskern P1 ausgeführt wird, und Task T2, der an Verarbeitungskern P2 ausgeführt wird, umfassen. Die Anwendung erfordert, dass ein Runnable R_2,d von Task T2 die Ausführung nach dem Abschluss eines Runnable R_1,s von Task T1 startet. Bei diesem Szenario kann Runnable R_2,d an P2 hinsichtlich eines Ereignisses E_2,d Bevorstehen/Warten, welches wiederum durch den Abschluss von Runnable R_1,s an P1 gesetzt werden kann. Setzen/Warten-Ereignisse werden eingesetzt, um Beschränkungen eines gegenseitigen Ausschlusses statisch zu erzwingen, indem Vorrangbeziehungen zwischen Runnables bei unterschiedlichen Tasks, die an dem gleichen Kern laufen, erzwungen werden, und werden hinsichtlich des Kontexts von Mehrkernprozessoren verallgemeinert.
Eine Analyse von Tasks mit Setzen/Warten-Ereignissen umfasst das Entwickeln einer Reaktionszeitanalyse für solche Tasks. Lediglich beispielhaft wird ein Task T1 an Verarbeitungskern P mit den Runnables R_i,1 bis R_i,m(i), der Setzen/Warten-Ereignisse verwendet, bewertet. Bei einem Szenario verwendet keiner der Tasks Th einer höheren Priorität (d. h. höhere Priorität als Ti) an P Setzen/Warten-Ereignisse, um sich mit anderen Tasks zu synchronisieren, d. h. ∀Th ∊ hp(Ti) und ∀k > 1, π_h,k = R_h,k-1. Bei diesem Szenario kann eine Grenze hinsichtlich der ungünstigsten Reaktionszeit von Task Ti abgeleitet werden wie folgt. Es bezeichne F(R_i,j) eine obere Grenze hinsichtlich der Beendigungszeit von Runnable R_i,j. Um F(R_i,j) zu berechnen, wird das letzte Runnable R_i,e von Ti vor R_i,j eingesetzt, das durch ein externes Ereignis ausgelöst wurde, d. h. e < j ist der größte Wert, so dass e = 1 oder π_i,e ≠ R_i,e. Der Zeitpunkt, zu dem dieses externe Ereignis gesetzt wird, kann mit S_i,e bezeichnet werden. Wenn W_i,{e...j} die ungünstigste Reaktionszeit des Ti-Segments, das die Runnables R_i,e bis R_i,j umfasst, bezeichnet, wird F(R_i,j) wie folgt ermittelt. F(R_i,j) = S_i,e + W_i,{e...j} [1]
Die Beendigungszeit von Runnable R_i,j ist somit nicht größer als W_i,{e...j} seit dem Setzen von Ereignis E_i,e bei S_i,e.
Eine obere Grenze der ungünstigsten Reaktionszeit W_i,{e...j} kann unter der Annahme erhalten werden, dass keiner der Tasks einer höheren Priorität an Verarbeitungskern P externe Setzen/Warten-Ereignisse verwendet. Die ungünstigste Reaktionszeit W_i,{e...j} wird durch Verwenden des Standardreaktionszeittests berechnet, der die Konvergenz des Folgenden ist:
wobei
Unter der Annahme, dass Runnables ihre entsprechenden Ereignisse durch das Ende deren Ausführung setzen, umfasst das Ergebnis das Folgende. S_i,e = F(π_i,e) [3]
Dieser Betrieb wird mit Bezug auf 2-1, 2-2 und 2-3 gezeigt.
2-1 zeigt schematisch ein Task-Ausführungsdiagramm zum Ausführen mehrerer Tasks in einem Mehrkernverarbeitungssystem wie es z. B. in Bezug auf 1-1 und 1-2 beschrieben ist. Die ausgeführten Tasks umfassen T1 210, T2 220, T3 230 und T4 240. T1 210 umfasst sequentiell ausgeführte Runnables R_1,1 211, R_1,2 212, R_1,3 213 und wird durch den ersten Verarbeitungskern ausgeführt. Wie gezeigt ist T1 210 für eine Ausführung einmal alle vier Zeitschritte geplant und wird jedes Runnable in einem einzelnen Zeitschritt ausgeführt. T2 220 umfasst sequentiell ausgeführte Runnables R_2,1 221 und R_2,2 222 und wird durch den ersten Verarbeitungskern ausgeführt. Wie gezeigt ist T2 220 für eine Ausführung einmal alle sieben Zeitschritte geplant und wird jedes Runnable in einem einzelnen Zeitschritt ausgeführt. T1 210 hat eine höhere Priorität als T2 220 und hat somit bei einer Ausführung in dem ersten Verarbeitungskern Vorrang. T3 230 umfasst ein einzelnes Runnable R_3,1 231 und wird durch den zweiten Verarbeitungskern ausgeführt. Wie gezeigt ist T3 230 für eine Ausführung einmal alle drei Zeitschritte geplant und wird jedes Runnable in einem einzelnen Zeitschritt ausgeführt. T4 240 umfasst ein einzelnes Runnable R_4,1 241 und wird durch den zweiten Verarbeitungskern ausgeführt. Wie gezeigt ist T4 240 für eine Ausführung einmal alle vier Zeitschritte geplant und wird jedes Runnable in einem einzelnen Zeitschritt ausgeführt. T3 230 hat eine höhere Priorität als T4 240 und hat somit bei der Ausführung in dem zweiten Verarbeitungskern Vorrang. Der erste und zweite Verarbeitungskern 20 und 30 sind jeweils ausgestaltet, um zu einem Zeitpunkt ein Task-Runnable auszuführen. T2 220 und T3 230 können ohne Setzen/Warten-Ereignisbeschränkungen ausgeführt werden. T1 210 und T4 240 weisen jeweils eine Setzen/Warten-Ereignisbeschränkung auf, die eine Vorrangbeziehung ist, wobei die Ausführung von Runnable R_1,2 212 nicht vor einer abgeschlossenen Ausführung von Runnable _R1,1 211 von T1 210 in dem ersten Verarbeitungskern wie durch Verbinder 215 gezeigt und Runnable R_4,1 241 von T4 240 in dem zweiten Verarbeitungskern wie durch Verbinder 245 gezeigt initiiert werden kann. Runnable R_4,1 wird durch ein Ereignis E_4,1 ausgelöst, das durch Runnable R_2,3 gesetzt wird, d. h. R_4,1 = R_2,3. Ähnlich wird Runnable R_2,4 durch ein Ereignis E_2,4 ausgelöst, das durch Runnable R_4,1 gesetzt wird, d. h. R_2,4 = R_4,1. Wie gezeigt wird die ungünstigste Reaktionszeit jedes intern ausgelösten benachbarten Segments berechnet, um die Gesamt-Task-Reaktionszeit zu begrenzen. Die Beendigungszeit F(R_2,3) von Runnable R_2,3 wird als ungünstigste Reaktionszeit von Segment R_2,1 bis R_2,3 unter Verwendung der in Bezug auf Gl. 2 beschriebenen Konvergenz berechnet. Diese wird dann als Setzzeit von Ereignis E_4,1 unter Verwendung von Gl. 3 verwendet. Die ungünstigste Reaktionszeit des Segment-Runnable R_4,1 wird unter Verwendung der Konvergenz von Gl. 2 berechnet. Wieder unter Verwendung der Gl. 1 und 3 wird die Beendigungszeit von Runnable R_4,1 als F(R_4,1) berechnet. Unter Verwendung dieses Beendigungszeitwerts in Gl. 1 und der ungünstigsten Reaktionszeit von Segment R_2,4 bis R_2,5, die unter Verwendung der Konvergenz von Gl. 2 erhalten wird, wird die Beendigungszeit von Runnable R_2,5 erhalten. Dies ist auch eine obere Grenze hinsichtlich der ungünstigsten Reaktionszeit von T2 220. Obwohl die Analyse eine obere Grenze hinsichtlich der ungünstigsten Reaktionszeit von Tasks unter Verwendung von Setzen/Warten-Ereignissen bereitstellt, können die Grenzen aufgrund der Annahme von unabhängigen ungünstigsten Reaktionszeiten für jedes benachbarte Segment von intern ausgelösten Runnables pessimistisch sein. Die Strukturen der Setzen/Warten-Ereignisse führen auch oftmals zu größeren ungünstigsten Reaktionszeiten, die auf die Möglichkeit langer Verzögerungen beim Setzen von Ereignissen zurückzuführen sind. Beispielsweise bei dem in 2-1 gezeigten Beispiel, bei dem T2 220 die Bevorrechtigung bei T4 durch T2 230 berücksichtigen muss, da dies zu einer Verzögerung beim Setzen von E_2,4 führt. Es kann somit sowohl aus einer Analyse- als auch einer Durchführungsperspektive vorteilhaft sein, wenn möglich Setzen/Warten-Ereignisstrukturen zu vermeiden, um sicherzustellen, dass der Task-Satz mit höheren Nutzungsschwellenwerten planbar ist, oder alternativ, um langsamere (und daher) billigere Prozessoren zu verwenden. Eine Konsequenz des Verwendens von Setzen/Warten-Ereignissen ist, dass es nicht mehr garantiert ist, dass die Freigabe von Runnables periodisch ist. In Abhängigkeit von der Setzzeit S_i,e externer Ereignisse ändert sich die Freigabezeit von Runnable R_i,e. Dies führt zu Schwankungen und Planungsstrafen für Tasks einer niedrigeren Priorität. Dies kann vermieden werden, indem den Runnables, die durch externe Ereignisse ausgelöst werden, statisch geeignete Offsets zugeordnet werden.
2-2 zeigt graphisch das erste Zeitdiagramm, das der Ausführung der Tasks T1 210, T2 220, T3 230 und T4 240 zugehörig ist, die in Bezug auf 2-1 beschrieben sind, in Beziehung zu verstrichenen Zeitschritten, die an der x-Achse 250 gezeigt sind. Es werden keine statischen Offsets eingesetzt. Es ist gezeigt, dass die Ausführungen von Task-Runnables bei Zeitschritt 0 starten. Mit voranschreitenden Zeitschritten werden die Runnables von T1 210, T2 220, T3 230 und T4 240 ausgeführt. Die Tasks T1 210 und T2 220 sind einem ersten Verarbeitungskern zugeordnet, während die Tasks T3 230 und T4 240 einem zweiten Verarbeitungskern zugeordnet sind. T1 210 und T4 240 sind miteinander unter Verwendung von Setzen/Warten-Ereignissen synchronisiert. T1 210 besteht aus den Runnables R_1,1, R_1,2 und R_1,3. T4 240 besteht aus einem einzelnen Runnable R_4,1. T1 210 und T4 240 werden periodisch alle 4 Zeiteinheiten ausgelöst. Runnable R_1,2 ist für eine Ausführung nach dem Abschluss von R_1,1 berechtigt und wird durch ein durch R_4,1 gesetztes externes Ereignis E_1,2 ausgelöst, d. h. T_1,2 = R_4,1. Wie bei den anderen Tasks weist T2 220 zwei Runnables R_2,1 und R_2,2 mit einer Periode von 7 Zeiteinheiten auf und weist T2 230 ein einzelnes Runnable R_3,1 mit einer Periode von 3 Zeiteinheiten auf. Zur Vereinfachung der Darstellung wird angenommen, dass alle Runnables eine ungünstigste Ausführungszeit von 1 Zeiteinheit haben.
Bei dem in 2-2 gezeigten Szenario bewirkt die Freigabeschwankung von Runnable R_1,2, dass T2 220 seine Deadline von 7 Zeiteinheiten verpasst. Es ist zu sehen, dass R_1,2 hinsichtlich Ereignis E_1,2 während der ersten Freigabe von T1 210 verzögert wurde, während es während der zweiten Freigabe nicht verzögert wurde. Dies bewirkt eine verstärkte Bevorrechtigung bei T2 220, was dazu führt, dass T2 220 seine Deadline verpasst.
Ein Mechanismus umfasst das Zuordnen von Freigabe-Offsets zusätzlich zu den Ereignisauslösern, um eine Freigabeschwankung zu berücksichtigen. Lediglich beispielhaft wird ein durch ein externes Ereignis E_i,e ausgelöstes Runnable π_i,e bewertet. Es ist garantiert, dass das Ereignis E_i,e durch die ungünstigste Beendigungszeit F(π_i,e) von Runnable Π_i,e, das Ei, e setzt, gesetzt wird. Daher garantiert das Zuordnen eines statischen Offsets von Φ_i,e = F(π_i,e), dass das Ereignis E_i,e gesetzt wird, bevor die Ausführung von Runnable R_i,e beginnt. Statische Offsets fungieren somit als einfacher Periodendurchsetzer, was eine periodische Freigabe von Runnable R_i,e ermöglicht und Tasks mit einer niedrigeren Priorität als Task Ti davon befreit, die Freigabeschwankung von Runnable R_i,e zu bewältigen. Wenn Runnables keine derartigen statischen Offsets zugeordnet werden, kann dies zu längeren ungünstigsten Reaktionszeiten und unvorhersagbaren Runnable-Freigabezeiten während des Systembetriebs führen.
Die Details des in 2-2 gezeigten Betriebs umfassen das Folgende. Bei Zeitschritt 0 wird Runnable R_1,1 211 von T1 210 in dem ersten Verarbeitungskern ausgeführt und wird Runnable R_3,1 231 von T2 230 gleichzeitig in dem zweiten Verarbeitungskern ausgeführt. Bei Zeitschritt 1 wird Runnable R_2,1 221 von T2 220 in dem ersten Verarbeitungskern ausgeführt und wird Runnable R_4,1 241 von T4 240 in dem zweiten Verarbeitungskern ausgeführt. Die Ausführung von T1 210 wird verzögert, da Runnable R_1,2 212 von T1 210 auf die Ausführung von Runnable R_4,1 241 von T4 240 in dem zweiten Verarbeitungskern wartet, was eine erforderliche Vorbedingung einer Ausführung von Runnable R_1,2 212 von T1 210 ist, das eine niedrigere Priorität als Runnable R_3,1 231 von T2 230 hat. Bei Zeitschritt 2 wird Runnable R_1,2 212 von T1 210 in dem ersten Verarbeitungskern nach den abgeschlossenen Ausführungen der Vorbedingungen von Runnable R_1,1 211 von T1 210 und Runnable R_4,1 241 von T4 240 ausgeführt. Bei Zeitschritt 3 wird Runnable R_3,1 231 von T2 230 wieder in dem zweiten Verarbeitungskern in Ansprechen auf seine geplante Ausführung, die alle drei Zeitschritte stattfindet, ausgeführt. Element R_1,3 213 von T1 210 wird in dem ersten Verarbeitungskern ausgeführt, wodurch eine Iteration von T1 210 abgeschlossen wird. Bei Zeitschritt 4 wird eine andere Iteration von T1 210 in dem ersten Verarbeitungskern in Ansprechen auf seine geplante Ausführung, die alle vier Zeitschritte stattfindet, ausgeführt. Somit wird bei Zeitschritt 4 Runnable R_1,1 211 von T1 210 ausgeführt. Gleichzeitig wird Runnable R_4,1 241 von T4 240 in dem zweiten Verarbeitungskern ausgeführt, da Runnable R_3,1 231 von T2 230 zuvor ausgeführt wurde und der zweite Verarbeitungskern für eine Ausführung verfügbar ist.
Die gleichzeitige Ausführung von Runnable R_1,1 211 von T1 210 und Runnable R_4,1 241 von T4 240 ermöglicht eine Ausführung von Runnable R_1,2 212 von T1 210 bei Zeitschritt 5, gefolgt von einer Ausführung von Runnable R_1,3 213 von T1 210 bei Zeitschritt 6. Diese Aktion schließt die Ausführung von Runnable R_2,2 222 von T2 220 aufgrund dessen niedrigerer Priorität in dem ersten Verarbeitungskern aus. Somit gelingt die Ausführung von T2 220 in seiner zugeteilten Zeitperiode nicht, und es entsteht ein Fehler, wie es durch Element 235 angegeben ist.
2-3 zeigt graphisch das zweite Zeitdiagramm, das der Ausführung der Tasks T1 210, T2 220, T3 230 und T4 240 zugehörig ist, die in Bezug auf 2-1 beschrieben sind, in Beziehung zu verstrichenen Zeitschritten, die an der x-Achse 250 gezeigt sind, und wobei bei T1 210 ein statischer Offset eingesetzt wird. T1 210 kann einen statischen Offset einsetzen, da es drei Task-Runnables und vier Zeitschritte, um die Tasks abzuschließen, gibt. Die Ausführungen der Task-Runnables sind startend bei Zeitschritt 0 gezeigt. Mit voranschreitenden Zeitschritten werden die Runnables T1 210, T2 220, T3 230 und T4 240 wie folgt ausgeführt. Bei Zeitschritt 0 wird Runnable R_1,1 211 von T1 210 in dem ersten Verarbeitungskern ausgeführt und wird Runnable R_3,1 231 von T2 230 gleichzeitig in dem zweiten Verarbeitungskern ausgeführt. Während jeder Iteration von T1 210 wird nach der Ausführung von Runnable R_1,1 211 ein statischer Offset 214 in T1 210 eingeführt. Das Einführen des statischen Offsets 214 nach der Ausführung von Runnable R_1,1 211 ist zulässig, da T1 210 drei Task-Runnables und vier Zeitschritte, in denen der Task abzuschließen ist, aufweist, wodurch das Einführen des statischen Offsets 214 die vollständige Ausführung von T1 210 nicht stört. Somit wird bei Zeitschritt 1 die Ausführung von T1 210 in Ansprechen auf eine Einführung des statischen Offsets 214 verzögert. Element R_4,1 241 von T4 240 wird in dem zweiten Verarbeitungskern ausgeführt, das eine niedrigere Priorität als Runnable R_3,1 231 von T2 230 hat. Das Einführen des statischen Offsets 214 nach der Ausführung von Runnable R_1,1 211 wird bevorzugt, da die Ausführung von Runnable R_4,1 241 von T4 240 eine erforderliche Vorbedingung hierfür ist und Runnable R_4,1 241 von T4 240 in dem zweiten Verarbeitungskern mit einer niedrigeren Priorität als Runnable R_3,1 231 von T2 230 ausgeführt wird. Bei Zeitschritt 2 wird Runnable R_1,2 212 von T1 210 in dem ersten Verarbeitungskern nach den abgeschlossenen Ausführungen der Vorbedingungen von Runnable R_1,1 211 von T1 210 und Runnable R_4,1 241 von T4 240 ausgeführt. Bei Zeitschritt 3 wird Runnable R_3,1 231 von T2 230 in Ansprechen auf seine geplante Ausführung, die alle drei Zeitschritte stattfindet, wieder in dem zweiten Verarbeitungskern ausgeführt. Element R_1,3 213 von T1 210 wird in dem ersten Verarbeitungskern ausgeführt, wodurch eine Iteration von T1 210 abgeschlossen wird. Bei Zeitschritt 4 wird eine andere Iteration von T1 210 in dem ersten Verarbeitungskern in Ansprechen auf seine geplante Ausführung, die alle vier Zeitschritte stattfindet, ausgeführt. Somit wird bei Zeitschritt 4 Runnable R_1,1 211 von T1 210 ausgeführt. Gleichzeitig wird Runnable R_4,1 241 von T4 240 in dem zweiten Verarbeitungskern ausgeführt, da Runnable R_3,1 231 von T2 230 zuvor ausgeführt wurde und der zweite Verarbeitungskern für eine Ausführung zur Verfügung steht. Bei Zeitschritt 5 wird die Ausführung von T1 210 in Ansprechen auf die Einführung des statischen Offsets 214 verzögert. Dies ermöglicht, dass Runnable R_2,2 222 von T2 220 in dem ersten Verarbeitungskern bei Zeitschritt 5 ausgeführt wird, wodurch die Ausführung von T2 220 in der geplanten Ausführung, die alle sieben Zeitschritte befohlen wird, abgeschlossen wird. Somit gibt es keine Verzögerung bei der Ausführung von T2 220 und keine zugehörige Verzögerung hinsichtlich Reaktionszeiten von Systemen, die auf das Ergebnis von T2 220 warten. Bei Zeitschritt 6 wird Runnable R_1,2 212 von T1 210 in dem ersten Verarbeitungskern ausgeführt und wird Runnable R_3,1 231 von T2 230 wieder in dem zweiten Verarbeitungskern ausgeführt, und zwar in Ansprechen auf seine geplante Ausführung, die alle drei Zeitschritte stattfindet. Bei Zeitschritt 7 wird Runnable R_1,3 213 von T1 210 in dem ersten Verarbeitungskern ausgeführt, wodurch eine andere Iteration von T1 210 abgeschlossen wird.
Das Einführen des statischen Offsets 214 nach der Ausführung von Runnable R_1,1 211 macht einen Zeitschritt in dem ersten Verarbeitungskern frei, während dem T2 220 einer niedrigeren Priorität dessen Runnable ausführen kann. Somit erhöht das Einführen des statischen Offsets 214 nach der Ausführung von Runnable R_1,1 211 die Wahrscheinlichkeit, dass T2 220 einer niedrigeren Priorität seine Runnables rechtzeitig ausführen kann, ohne die Reaktionszeit der Ausführung von T1 210 zu beeinflussen. Ferner verbessert das Einführen des statischen Offsets 214 die Timing-Vorhersagbarkeit von Tasks einer niedrigeren Priorität, z. B. T2 220.
3 zeigt graphisch eine Empfindlichkeitsbewertung von Setzen/Warten-Ereignissen für eine Basisnutzung 315 und eine maximale Nutzung 325, dargestellt in Relation zu einer Brennkraftmaschinendrehzahl, die an der x-Achse 310 gezeigt ist. Die Nutzung ist an der y-Achse 320 gezeigt. Um die Timing-Analyse unter Verwendung von Setzen/Warten-Ereignissen zu bewerten, wurde ein beispielhaftes System mit zehn zeitlich ausgelösten Tasks und zwei synchronen Maschinen-Tasks in Betracht gezogen und bewertet. Für den Setzen/Warten-Ereignismechanismus sind zwei Paare von Tasks relevant: (i) primäre und sekundäre Tasks mit Perioden von 6,25 ms und (ii) primäre und sekundäre Tasks mit Perioden von 12,5 ms. Task-Paar (i) weist 5 Runnables auf, während Task-Paar (ii) 68 Runnables aufweist. Task-Paar (i) weist 1 Setzen/Warten-Ereignisstruktur auf, während Task-Paar (ii) 30 Setzen/Warten-Ereignisstrukturen aufweist. Es wurde eine Timing-Analyse dieses Aufbaus an einem Dualkernsystem unter Verwendung der Analyse ausgeführt. Bei der Empfindlichkeitsbewertung erhöhen sich die Ausführungszeiten von Tasks, bis die Analyse berechnet, dass ein Task in dem System gerade seine Deadline verpasst. Die Systemnutzung wurde bei dieser Last als maximale erreichbare Nutzung für den gegebenen Arbeitspunkt verzeichnet. Unter der Annahme, dass es zwei synchrone Maschinen-Tasks gibt, wurde die Maschinendrehzahl von 3500 U/min auf 5750 U/min geändert, während die maximale erreichbare Nutzung gemessen wurde. Die Ergebnisse gaben an, dass Setzen/Warten-Ereignisstrukturen die Nutzung beeinflussen und das System nicht dazu in der Lage ist, eine Nutzung von 52% zu übersteigen, auch wenn das Basissystem eine hohe Nutzung aufweist. Im Gegensatz dazu kann, wenn das System keine derartigen Setzen/Warten-Ereignisstrukturen, jedoch die gleichen ungünstigsten Ausführungszeiten, aufwies, die Systemnutzung bei 3500 U/min um 127% erhöht werden und bei 5750 U/min um 124% erhöht werden. Dies bedeutet, dass das System mit höheren Nutzungsschwellenwerten planbar ist. Dies hat drei Auswirkungen: zusätzliche Tasks können die CPU-Verarbeitungsleistung verwenden, oder alternativ kann eine langsamere CPU eingesetzt werden, oder alternativ können Prozessoren mit weniger Verarbeitungskernen eingesetzt werden. Es sei angemerkt, dass die Nutzung einer Ressource niemals höher als 100% sein kann. Gemeint ist, dass die aktuelle Nutzung, mit der das System planbar ist, um beispielsweise einen Faktor von 1,27 erhöht werden kann. Wenn die aktuelle Nutzung 60% beträgt, können zusätzliche 7% (60%·1,27) der Prozessornutzung durch Integrieren zusätzlicher Tasks eingesetzt werden. Mit anderen Worten wird das System immer noch mit einer Nutzung von 67% geplant. Es können andere Faktoren die Nutzung beeinflussen, die inhärente Verzögerungen umfassen, die durch Setzen/Warten-Ereignisstrukturen eingeführt werden.
Es kann ein Spinlock-Grundelement als Mechanismus für eine Laufzeit-Task-Synchronisation zwischen Kernen in einem Mehrkernbetriebssystem eingesetzt werden. Ein Spinlock ist ein Synchronisationsmechanismus, bei dem ein Verarbeitungs-Thread zur Synchronisation in einer Schleife wartet oder während des Wartens zirkuliert. Der Thread bleibt aktiv, führt jedoch keinen nützlichen Task durch. Sobald es erlangt wurde, wird das Spinlock bis zur Freigabe gehalten, wenn nicht eine Synchronisation oder eine andere Aktion die Sperre freigibt.
Wie hierin beschrieben sind Runnables erforderlich, um ein Spinlock zu erlangen, bevor auf irgendeine gemeinsam genutzte Ressource zugegriffen wird. Wenn aktuell eine Ressource verwendet wird und das Spinlock gehalten wird, zirkuliert (läuft) das Runnable, das diese Ressource anfordert, weiterhin an der Sperre, bis es freigegeben wird oder bis ihm ein anderes Runnable einer höheren Priorität an dem gleichen Kern zuvorkommt. Einem zirkulierenden Runnable kann jedoch zuvorgekommen werden. Dies fungiert als dynamischer Laufzeitmechanismus für einen gegenseitigen Ausschluss. Ein Spinlock kann eingesetzt werden, um eine Systemnutzung zu verbessern, indem der durch Setzen/Warten-Ereignisse eingeführte Overhead vermieden wird. Unter Verwendung des Spinlock-Grundelements können gemeinsam genutzte Logikressourcen über mehrere Verarbeitungskerne geschützt werden. Tasks, die auf jegliche sich gegenseitig ausschließende gemeinsam genutzte Ressourcen zugreifen, können das Spinlock halten, bevor dies geschieht. Wenn ein Task versucht, ein Spinlock zu erlangen, das aktuell von einem anderen Task gehalten wird, zirkuliert der Task oder wartet er aktiv an der Sperre, bis sie durch den Task freigegeben wird. Dieser Mechanismus stellt somit eine Unterstützung bereit, um einen gegenseitigen Ausschluss einer gemeinsam genutzten Ressource in einem Mehrkernprozessor zu realisieren.
Bei Mehrkernprozessorarchitekturen können sowohl Spinlocks als auch Setzen/Warten-Ereignisse eingesetzt werden. Bei Tasks, bei denen die Beschränkungen eines gegenseitigen Ausschlusses statisch erzwungen werden müssen, werden Setzen/Warten-Ereignisse eingesetzt. Bei Tasks, bei denen die Beschränkungen eines gegenseitigen Ausschlusses dynamisch erzwungen werden können, können Spinlocks und/oder ein Multiprozessorprioritätsobergrenzenprotokoll (MPCP) eingesetzt werden. Beispielsweise wird ein System mit mehreren Sensoren und Aktoren bewertet, bei dem die Verarbeitung an einem Dualkernprozessor gehandhabt wird. Die Verarbeitungs-Tasks können selbst Setzen/Warten-Ereignisbeschränkungen für einen statisch definierten gegenseitigen Ausschluss verwenden. Die Sensor- und Aktordatenhandhabungs-Tasks könnten Laufzeitgrundelemente eines gegenseitigen Ausschlusses verwenden, um konsistente Datenauslesungen sicherzustellen. Obwohl Spinlocks einen gegenseitigen Ausschluss aus einer funktionalen Perspektive erfolgreich sicherstellen, können sie aus einer Timing-Perspektive mehrere Probleme darstellen. Spinlocks zugehörige Timing-Herausforderungen umfassen Deadlocks, eine Prioritätsumkehr und ein Aushungern. Ein Deadlock tritt auf, wenn einem Task, der eine Sperre hält, ein Task einer höheren Priorität zuvorkommt, der die gleiche Sperre erfordert. In diesem Fall zirkuliert der Task einer höheren Priorität, der die Ressource erfordert, endlos oder wartet er endlos aktiv. Eine Lösung, um dieses Problem anzugehen, ist, Konstruktionsbeschränkungen vorzugeben, die verhindern, dass Tasks an dem gleichen Verarbeitungskern Spinlocks verwenden.
Eine Prioritätsumkehr tritt auf, wenn ein Task einer höheren Priorität darauf wartet, dass ein Task einer niedrigen Priorität eine Ressource freigibt. Die Verwendung von Spinlocks kann zu einer unbegrenzten Dauer einer Prioritätsumkehr führen, was eine signifikante Herausforderung für Tasks mit strengen Deadlines darstellt. In Situationen, in denen es viele Tasks mit mittlerer Priorität und mehrere Bevorrechtigungen bei einem Task gibt, kann ein Task einer hohen Priorität schließlich einem unbegrenzten Umfang an Prioritätsumkehr gegenüberstehen. Eine Prioritätsumkehr ist ein ernsteres Problem bei Spinlocks, da die Tasks einer hohen Priorität grundlegend aktiv wartende/Verschwendungszyklen an deren Verarbeitungskernen darstellen. Lange Dauern einer Prioritätsumkehr führen somit zu einem erheblichen Verlust an nützlicher Systemnutzung. Das Begrenzen solch einer Prioritätsumkehr ist wichtig, um sowohl eine Timing-Vorhersagbarkeit als auch eine bessere Nutzung zu erreichen.
Ein Aushungern tritt auf, wenn ein Task aushungert, bevor er Zugriff zu einer gemeinsam genutzten Ressource erhält. Bei einem Beispiel wird ein Spinlock zwischen Tasks einer niedrigeren Priorität hin und her erlangt und freigegeben, obwohl ein Task einer höheren Priorität darauf wartet. Diese Sequenz ist möglich, wenn eine Hardwaretestrealisierung nicht garantiert, Task-Prioritäten zu respektieren. Beim Verwenden von Spinlocks kann ein Aushungern entstehen, da die Hardwareplanung von Testoperationen für bestimmte Verarbeitungskerne günstiger sein kann oder dem Task, der an der Sperre zirkuliert, an seinem Verarbeitungskern zuvorgekommen werden könnte, wann immer die Sperre durch andere Tasks freigegeben wird. Wie bei Spinlocks führt das aktive Warten während solch eines Aushungerns auch zu einem Nutzungsverlust durch verschwendete Prozessorzyklen.
Es können Task-Reaktionszeiten bei Spinlocks ermittelt werden, um ein Verhalten eines begrenzten Timings zu erreichen, das Konstruktionsbeschränkungen und Annahmen berücksichtigt. Dies umfasst das Verwenden der in Gl. 1, 2 und 3 bereitgestellten Analyse, indem eine Zirkulationszeit, um die Sperrenwarteverzögerungen zu berücksichtigen, und eine Blockierzeit für die nicht präemptive Dauer von Tasks einer niedrigeren Priorität hinzugefügt werden. Die Blockierterme werden wie folgt berechnet. Unter Verwendung des zuvor beschriebenen Satzes von Konstruktionsbeschränkungen wird eine Sperrenwarteverzögerung ermittelt. Jedes Mal, wenn ein sich gegenseitig ausschließender Task, d. h. ein sich gegenseitig ausschließendes Ereignis (Mutex) M durch ein Runnable R_i,j von Task Ti angefordert wird, wird die Sperrenwartezeit unter Verwendung von Spinlocks auf eine Sperrenwarteverzögerung (I(M) – 1)CM beschränkt, wobei CM die maximale Sperrenhaltezeit ist. Für jeden Task Ti kann eine kumulative Zirkulationszeit CI(i, j) berechnet werden. Ein Mutex ist ein Prozess, der sicherstellt, dass keine zwei Prozesse oder Verarbeitungs-Threads auf eine gemeinsam genutzte Logikressource, z. B. einen gemeinsam genutzten Speicher-Cache oder -ort, während der gleichen Zeitperiode zugreifen, wodurch eine Korrumpierung der gemeinsam genutzten Ressource verhindert wird. Für jedes Ereignis wird eine nicht präemptive Dauer ermittelt, die jedes periodisch ausgelöste Runnable R_i,j jedes Tasks Ti umfasst. Eine nicht präemptive Dauer Bn(i, j) von Tasks einer niedrigeren Priorität ist durch Verwenden der maximalen nicht präemptitiven Dauer begrenzt, die als Maximum I(M)CM über allen Mutexes M bestimmt ist, die durch jeden Task mit einer niedrigeren Priorität als Ti gehalten werden können. Es wird angenommen, dass der Task einer niedrigeren Priorität über dieser gesamten Dauer nicht präemptiv ist. Für Runnables R_i,j (j > 1), die durch den Abschluss eines vorherigen Runnable R_i,j (j > 1) ausgelöst werden, wird die nicht präemptive Blockierdauer Bn(i, j) auf 0 gesetzt.
Der Zirkulationsterm CI(i, j) wird zu der ungünstigsten Ausführungszeit jedes Runnable R_i,j für alle Tasks (einschließlich der Tasks einer höheren Priorität) hinzugefügt. Der Blockierterm Bn(i, j) muss nur für den Task Ti angewandt werden, dessen Reaktionszeit unter Verwendung von Gl. 2 berechnet wird. Die zuvor erwähnte beschriebene Analyse wird somit erweitert, um die Verwendung von Spinlocks zu umfassen.
4 zeigt schematisch einen Prozess zum Analysieren des Timing von Spinlocks einschließlich eines ersten und eines zweiten Verarbeitungskerns 410 bzw. 420 und einer gemeinsam genutzten Softwareressource 430, die entweder für eine Ausführung 415 oder eine Zirkulation 425 erlangt wird. Dies ermöglicht eine Einführung von Konstruktionsbeschränkungen, um eine Timing-Analyse zu ermöglichen, und ermöglicht eine Entwicklung einer Timing-Analyse mit den vorhandenen Konstruktionsbeschränkungen.
5 zeigt graphisch ein Zeitdiagramm, das einer Task-Ausführung zugehörig ist, die Spinlocks einsetzt, gezeigt in Beziehung zu verstrichenen Zeitschritten. Die Tasks sind gleichzeitig in Relation zur verstrichenen Zeit an der x-Achse 505 gezeigt und umfassen Task T1 510, der eine Ausführung an einem zweiten Verarbeitungskern anstrebt, Task T2 520, der eine Ausführung an einem ersten Verarbeitungskern anstrebt, und Task T3 530, der eine Ausführung an dem ersten Verarbeitungskern anstrebt. Zu Beginn befindet sich T3 530 in einem aktiven/Wartemodus 515, wobei ein Sperrenhaltezustand 525 eine Alle-Interrupts-Aussetzen-Funktion 545 einsetzt. Bei Zeitschritt 540 begibt sich T1 510 in einen aktiven/Wartemodus 515, der sich bei Zeitschritt 550 in den Sperrenhaltezustand ändert und eine Fernblockierung einsetzt. T2 520 beginnt den Betrieb bei Zeitschritt 550 in einem präemptiven Blockiermodus 535. Somit setzt das Steuersystem, um Perioden eines aktiven Wartens zu begrenzen, eine Alle-Interrupts-Aussetzen-Funktion ein, bevor ein Spinlock erlangt wird, wodurch Interrupts nur nach dem Freigeben des Spinlocks zugelassen werden. Nachfolgende Anforderungen hinsichtlich eines Spinlocks M werden zeitlich durch I(M)CM verteilt, wobei I(M) eine Menge von Tasks ist, die auf Spinlock M zugreifen, und CM die maximale Dauer, für die M gehalten wird, d. h. die Sperrenhaltezeit, ist.
6 zeigt graphisch eine Empfindlichkeitsbewertung von Spinlocks für eine Basisnutzung 615 und eine maximale Nutzung 625, dargestellt in Relation zur Maschinendrehzahl, die an der x-Achse 610 gezeigt ist. Die Nutzung ist an der y-Achse 620 gezeigt. In diesem Fall werden globale Logikressourcen zur gemeinsamen Nutzung an dem Dualkernprozessor eingeführt. Es wurden ein Minimum von 2 Tasks pro Ressource und ein Maximum von 3 Tasks pro Ressource mit nicht mehr als 2 Ressourcen pro Task eingesetzt. Der Prozentsatz an Zeit, die durch jeden Task aufgewandt wurde, wurde an jedem seiner globalen kritischen Abschnitte erhöht, bis analytisch ermittelt wurde, dass das System gerade seine Deadline verpasst hat. Die Setzen/Warten-Ereignisstrukturen wurden ignoriert. Wie es an diesen Ergebnissen zu sehen ist, arbeitet das System relativ gut, wobei jedem Task erlaubt wird, bis zu 50% seiner Ausführungszeit an global gemeinsam genutzten Ressourcen zu verbringen.
Das Einbringen eines einschränkenden Satzes von Konstruktionsbeschränkungen kann zu begrenzten Reaktionszeiten bei Spinlocks führen. Der Spinlock-Mechanismus stellt jedoch keine nach Priorität geordnete Bedienung von Ressourcenanforderungen sicher. Um die Annahmen zu lockern und um eine prioritätsgetriebene Bedienung sicherzustellen, kann ein Multiprozessorprioritätsobergrenzenprotokoll (MPCP) eingesetzt werden. Das MPCP wird für eine Task-Synchronisation in einem Mehrkernprozessor eingesetzt, um eine nach Priorität geordnete Bedienung von Ressourcenanforderungen durch Lockerungsannahmen zu erreichen. Interessant ist ein globales Mutex M_G, das ein Mutex ist, das von Tasks gemeinsam genutzt wird, die an verschiedenen Verarbeitungskernen eingesetzt werden. Die entsprechenden kritischen Abschnitte werden als globale kritische Abschnitte (GCS) bezeichnet. Umgekehrt wird ein lokales Mutex nur zwischen Tasks an dem gleichen Verarbeitungskern gemeinsam genutzt, und die entsprechenden kritischen Abschnitte sind lokale kritische Abschnitte. Wenn ein Task T M_G erlangt, führt er den GCS entsprechend dem globalen Mutex M_G mit einer Priorität aus, die wie folgt gesetzt wird: p(M_G) = p(G) + p(T0) wobei
p(M_G) eine Prioritätsobergrenze ist,
p(G) ein Basisprioritätsniveau ist, das größer als das eines beliebigen anderen normal ausgeführten Tasks in dem System ist, und
p(T0) die Priorität eines Tasks T0 einer höchsten Priorität ist, der das globale Mutex M_G sperren kann.
Jedes MPCP minimiert eine Fernblockierung und Prioritätsumkehrungen, wenn globale Ressourcen gemeinsam genutzt werden. Jedes MPCP umfasst die folgenden Eigenschaften, die umfassen, dass Tasks zugeordnete Prioritäten verwenden, wenn sie sich nicht in kritischen Abschnitten befinden, und ein Einzelprozessorprioritätsobergrenzenprotokoll für alle Anforderungen hinsichtlich lokaler Mutexes verwendet wird. Ein Task in einem globalen kritischen Abschnitt (GCS), der durch das globale Mutex M_G geschützt wird, weist die Priorität seines GCS auf, d. h. (p(G) + p(T0)). Ein Task in einem GCS kann einem anderen Task T* in einem GCS zuvorkommen, wenn die Priorität des GCS für T0 größer als die Priorität des GCS für T* ist. Wenn ein Task T ein globales Mutex M_G anfordert, kann das globale Mutex M_G für T mittels einer atomaren Transaktion an einem gemeinsam genutzten Speicher gewährt werden, wenn M_G nicht von einem anderen Task gehalten wird. Wenn eine Anforderung hinsichtlich eines globalen Mutex M_G nicht gewährt werden kann, wird Task T zu einer priorisierten Warteschlange hinsichtlich M_G hinzugefügt, bevor ihm zuvorgekommen wird. Die Priorität, die als der Schlüssel für das Einsetzen in die Warteschlange verwendet wird, ist die T zugeordnete normale Priorität. Wenn ein Task T anstrebt, ein globales Mutex M_G freizugeben, wird dies dem Task Th mit höchster Priorität, der auf M_G wartet, signalisiert, und er wird zur Ausführung an dem Host-Verarbeitungskern von Th mit seiner GCS-Priorität berechtigt. Wenn keine Tasks an dem globalen Mutex M_G ausgesetzt sind, wird es freigegeben.
7 zeigt schematisch eine Realisierung eines Multiprozessorprioritätsobergrenzenprotokolls, das einen ersten und einen zweiten Verarbeitungskern 710 bzw. 720 mit einer entsprechenden ersten und zweiten Prioritätswarteschlange 705 bzw. 715 umfasst, was zu einer gemeinsam genutzten Prioritätswarteschlange 725 führt, die durch eine gemeinsam genutzte Softwareressource 730 ausgeführt wird. Jedes globale Mutex hält eine Prioritätswarteschlange von Tasks aufrecht, die auf dessen Erlangung warten. Wenn ein Task das globale Mutex erlangt, ist er für die Ausführung an dessen entsprechendem Verarbeitungskern mit der Fernprioritätsobergrenze des globalen Mutex bereit. Die Priorität wird als Maximum aller normalen Task-Ausführungsprioritäten und als Maximum aller normalen Prioritäten von Tasks, die auf die gemeinsam genutzte Softwareressource zugreifen, festgelegt, was hierin beschrieben ist.
8 zeigt graphisch ein Zeitdiagramm, das einer Ausführung des Multiprozessorprioritätsobergrenzenprotokolls zugehörig ist. In diesem System gibt es vier Tasks, die T1 810, T2 820, T3 830 und T4 840 umfassen. Die Tasks T1 810 und T2 820 sind dem gleichen Verarbeitungskern P1 zugeordnet. Task T3 830 ist einem zweiten Verarbeitungskern P2 zugeordnet. Task T4 840 ist einem dritten Verarbeitungskern P3 zugeordnet. Die Tasks T1 810 und T4 840 nutzen eine Logikressource unter Verwendung eines ersten globalen Mutex M1 gemeinsam. Die Tasks T2 820 und T3 830 nutzen unter Verwendung eines zweiten globalen Mutex M2 eine andere Logikressource gemeinsam. Jeder der Tasks T1 810, T2 820, T3 830 und T4 840 umfasst eine normale Ausführung 825 und eine kritische Ausführung 815, wobei die kritische Ausführung 825 Tasks entspricht, die eine hohe Priorität aufweisen. Zu Beginn befinden sich die Tasks T1 810, T2 820 und T4 840 in einer normalen Ausführung 825. Bei Zeitschritt 850 beginnt T4 840 mit einer kritischen Ausführung 815. Bei Zeitschritt 852 beginnt T3 830 mit einer kritischen Ausführung 815 und beginnt T2 820 mit einer normalen Ausführung 825, die bei Zeitschritt 854 endet. T2 820 fordert das globale Mutex M2 an, das er erlangt, wenn das zweite globale Mutex M2 bei Zeitschritt 856 durch T3 830 freigegeben wird, wodurch ermöglicht wird, dass T2 mit einer kritischen Ausführung 815 ausgeführt wird. Wenn T2 820 die Ausführung mit der Fernprioritätsobergrenze des zweiten globalen Mutex M2 abschließt, wird das erste globale Mutex M1 mit höherer Fernprioritätsobergrenze bei Zeitschritt 858 durch T4 840 freigegeben und wird T1 810 die Priorität gegeben. Dies bewirkt eine Bevorrechtigung bei T2 820 durch T1 810, auch wenn T2 820 das zweite globale Mutex M2 hält, da das erste globale Mutex M1 eine höhere Fernprioritätsobergrenze aufweist als das zweite globale Mutex M2. Bei Zeitschritt 860 schließt T1 810 die kritische Ausführung 815 ab, was T2 820 ermöglicht, mit der kritischen Ausführung 815 zu arbeiten, endend bei Zeitschritt 862. Das Multiprozessorprioritätsobergrenzenprotokoll ermöglicht somit, dass Tasks, die globale Mutexes halten, durch globale Mutexes einer höheren Priorität zuvorgekommen wird, was beim Reduzieren der Sperrenwarteverzögerungen und der Sperrenhaltezeiten von globalen Mutexes, auf die durch Tasks einer hohen Priorität zugegriffen wird, von Vorteil ist.
Ein Vorteil des Verwendens des Multiprozessorprioritätsobergrenzenprotokolls umfasst das Zulassen eines prioritätsgetriebenen Zugriffs auf gemeinsam genutzte Ressourcen, wobei jedes globale Mutex eine Prioritätswarteschlange mit Tasks aufweist, die daran ausgesetzt sind. Wenn die Ressource freigegeben wird, wird sie dem Task mit höchster Priorität, der daran wartet, gegeben. Diese Eigenschaft wird nicht durch Spinlocks bereitgestellt, was ermöglicht, dass die Hardwaretestgrundelemente den Task ermitteln, der die Ressource erhält. Ein anderer Vorteil des Verwendens des Multiprozessorprioritätsobergrenzenprotokolls umfasst eine beschränkte Bevorrechtigung von Tasks, die Sperren halten. Mit dem MPCP wird eine globale Prioritätsobergrenze p(G) eingesetzt, die ermöglicht, dass Tasks, die Mutexes halten, durch Mutexes mit einer höheren Fernprioritätsobergrenze zuvorgekommen wird, wobei p(M_G) die Fernprioritätsobergrenze darstellt. Dies stellt die Ansprechbarkeit von Tasks mit höchster Priorität, die kürzere Deadlines haben können, sicher.
Ein weiterer Vorteil des Verwendens des Multiprozessorprioritätsobergrenzenprotokolls umfasst, dass keine Zyklen in einem Modus eines aktiven Wartens verschwendet werden, was eine aussetzungsbasierte Realisierung eines MPCP umfasst, bei der das Aussetzen von Tasks zugelassen ist, wenn die angeforderte Sperre nicht zur Verfügung steht. Der Task wird einer Prioritätswarteschlange an dem Mutex hinzugefügt und er wird benachrichtigt, wenn die Ressource gewährt wird. Dies vermeidet, dass irgendwelche Zyklen bei einem aktiven Warten verschwendet werden. Die Task-Aussetzung selbst führt jedoch die Möglichkeit einer Ausführung und eines Anforderns von globalen Mutexes von Tasks einer niedrigeren Priorität ein. Dies kann zu Bevorrechtigungen hinsichtlich solcher Tasks zu einem späteren Ausführungszeitpunkt führen. Um solch eine Strafe zu vermeiden, kann eine zirkulationsbasierte Realisierung eines MPCP eingesetzt werden, bei der Tasks an der angeforderten Sperre bis zu einer Verfügbarkeit zirkulieren.
Der zuvor erwähnte Reaktionszeittest für Tasks mit Setzen/Warten-Ereignissen kann leicht erweitert werden, um eine Synchronisation mit einem MPCP handzuhaben. Blockierferme werden für eine Warteverzögerung eines globalen Mutex und eine Haltedauer eines globalen Mutex einer niedrigeren Priorität definiert. Die Warteverzögerungen eines globalen Mutex sind wie nachstehend beschrieben. Die Tasks erlangen globale Mutexes in einer Prioritätsreihenfolge mit dem MPCP. Das Mutex kann somit als Ressource gesehen werden, die mit einer festen Prioritätsreihenfolge geplant wird. Die Blockierzeit BMi, j eines Runnable Ri, j von Task Ti, der auf ein globales Mutex M zugreift, ist wie folgt definiert.
wobei
Der erste Term entspricht der maximalen Dauer, für die das Mutex M von einem beliebigen Task Tl einer niedrigeren Priorität gehalten werden kann, wenn Ti M anfordert. Der zweite Term stellt die maximale Dauer dar, für die Tasks Th einer höheren Priorität das Mutex M halten können, bevor Task Ti M erlangen kann. Hier ist W 'M / l die maximale Haltezeit eines globalen Mutex von Task Tl in Bezug auf das globale Mutex M. Unter dem MPCP kann immer noch Tasks, die das globale Mutex M halten, durch Tasks, die Mutexes mit einer höheren Fernprioritätsobergrenze halten, zuvorgekommen werden. Die maximale Haltezeit eines globalen Mutex von Task Tl ist somit durch die Konvergenz wie folgt gegeben.
In Gl. 5 stellt der erste Term CM die ungünstigste Ausführungszeit dar, wenn das globale Mutex M gehalten wird. Der zweite Term stellt die maximale mögliche Bevorrechtigung, wenn Ti das globale Mutex M hält, durch Tasks Tk an dem gleichen Verarbeitungskern wie Ti, wenn sie Mutexes M' mit höheren Fernprioritätsobergrenzen wie das globale Mutex M erlangen, dar.
Die gesamte Warteverzögerung B_i,j eines globalen Mutex für Runnable R_i,j wird durch Summieren der Blockierzeiten BM_i,j für jeden Zugriff von T_i,j über alle Mutexes M ermittelt. Bi wird als die Summe der Warteverzögerungen über alle Runnables R_i,j die zu Task Ti gehören, dargestellt.
Eine Haltedauer eines globalen Mutex einer niedrigeren Priorität wird wie folgt ermittelt. Wann immer ein Task Tl mit einer niedrigeren Priorität als Ti ein globales Mutex M erlangt, wird seine Priorität hinsichtlich der Fernprioritätsobergrenze von M begünstigt. Diese Fernprioritätsobergrenze wird als über allen normalen Ausführungsprioritäten liegend definiert und bewirkt somit eine Bevorrechtigung bei Ti, auch wenn Ti keine Sperren hält. Dieser Bevorrechtigung hinsichtlich der Haltedauer eines globalen Mutex einer niedrigeren Priorität kann durch den Blockierterm H_i,j für jedes Runnable R_i,j Rechnung getragen werden. R_i,j wird extern ausgelöst und erlangt ρ_i,j globale Mutexes während der Ausführung wie folgt.
Wenn R_i,j (mit j > 1) durch den Abschluss von R_i,j-1 ausgelöst wird und während der Ausführung ρ_i,j globale Mutexes erlangt, dann
Die gesamte Haltedauer Hi eines globalen Mutex einer niedrigeren Priorität, die Task Ti erfährt, kann berechnet werden, indem H_i,j über alle Runnables R_i,j summiert wird, die zu Task Ti gehören.
Die Konvergenz einer ungünstigsten Reaktionszeit, die in Gl. 2 gegeben ist, kann wie folgt modifiziert werden.
Die Analyse umfasst somit einen gegenseitigen Ausschluss unter Verwendung des Multiprozessorprioritätsobergrenzenprotokolls (MPCP). Zusätzlich zu dem Bereitstellen einer prioritätsgetriebenen Bedienung und von Eigenschaften eines begrenzten Timings beseitigt die Verwendung von MPCP die Beschränkungen und Annahmen, die für Spinlocks erforderlich sind.
Die Offenbarung beschrieb bestimmte bevorzugte Ausführungsformen und Abwandlungen dieser. Weitere Abwandlungen und Änderungen können für Dritte beim Lesen und Verstehen der Beschreibung ersichtlich werden. Daher soll die Offenbarung nicht auf die bestimmte Ausführungsform/die bestimmten Ausführungsformen beschränkt sein, die als die Ausführungsform(en) offenbart ist/sind, die zum Ausführen dieser Offenbarung als am geeignetsten betrachtet wird/werden, sondern soll die Offenbarung alle Ausführungsformen umfassen, die innerhalb des Schutzumfangs der beigefügten Ansprüche liegen.

Claims

Verfahren zum Verwalten einer Task-Ausführung in einem Mehrkernprozessor, das umfasst, dass: ein Runnable eines Tasks in einem ersten Verarbeitungskern ausgeführt wird, was umfasst, dass ein statischer Offset für ein anderes Runnable eines Tasks eingeführt wird, das in einem zweiten Verarbeitungskern ausgeführt wird, um eine statisch definierte Beschränkung eines gegenseitigen Ausschlusses bei den Runnables zu bewirken; und selektiv Spinlocks, Setzen/Warten-Ereignisse und Multiprozessorprioritätsobergrenzenprotokolle eingesetzt werden, um Beschränkungen eines gegenseitigen Ausschlusses zu bewirken, um mehrere Tasks zu synchronisieren, die in dem ersten und zweiten Verarbeitungskern ausgeführt werden.
Verfahren nach Anspruch 1, wobei das Einsetzen von Setzen/Warten-Ereignissen die Beschränkungen eines gegenseitigen Ausschlusses statisch erzwingt.
Verfahren nach Anspruch 1, wobei das Einsetzen von Spinlocks und der Multiprozessorprioritätsobergrenzenprotokolle die Beschränkungen eines gegenseitigen Ausschlusses dynamisch erzwingt.
Verfahren nach Anspruch 1, wobei das Einsetzen von Multiprozessorprioritätsobergrenzenprotokollen umfasst, dass eine globale Prioritätsobergrenze eingesetzt wird, um Tasks mit ausgewählten Beschränkungen eines gegenseitigen Ausschlusses durch einen Task mit einer Beschränkung eines gegenseitigen Ausschlusses mit einer höheren Fernprioritätsobergrenze zuvorzukommen.
Verfahren nach Anspruch 4, wobei das Einsetzen der globalen Prioritätsobergrenze, um Tasks mit ausgewählten Beschränkungen eines gegenseitigen Ausschlusses zuvorzukommen, umfasst, dass globale kritische Abschnitte, die einem globalen Mutex M_G entsprechen, wenn ein Task T das globale Mutex M_G erlangt, mit einer Priorität ausgeführt werden, die gemäß der folgenden Beziehung gesetzt wird: p(M_G) = p(G) + p(T0) wobei p(M_G) eine Prioritätsobergrenze für das globale Mutex M_G ist, p(G) ein Basisprioritätsniveau ist, das größer als ein anderer ausgeführter Task in dem System ist, und p(T0) die Priorität eines Tasks T0 einer höchsten Priorität ist, der das globale Mutex M_G sperren kann.
Verfahren nach Anspruch 5, wobei das globale Mutex M_G ein Mutex ist, das von Tasks gemeinsam genutzt wird, die in dem ersten und dem zweiten Verarbeitungskern des Mehrkernprozessors eingesetzt werden.
Verfahren nach Anspruch 1, wobei das Einsetzen der Multiprozessorprioritätsobergrenzenprotokolle umfasst, dass einem Task in einem globalen kritischen Abschnitt, der durch ein globales Mutex mit einer Priorität des globalen kritischen Abschnitts geschützt ist, eine Priorität zugeordnet wird.
Verfahren nach Anspruch 7, wobei das Einsetzen der Multiprozessorprioritätsobergrenzenprotokolle ferner umfasst, dass einem ersten Task in dem globalen kritischen Abschnitt ermöglicht wird, einem zweiten Task in dem globalen kritischen Abschnitt zuvorzukommen, wenn eine Priorität des ersten Tasks größer als eine Priorität des zweiten Tasks ist.
Verfahren nach Anspruch 8, wobei das Einsetzen der Multiprozessorprioritätsobergrenzenprotokolle ferner umfasst, dass ein globales Mutex einem Task unter Verwendung einer atomaren Transaktion in einem gemeinsam genutzten Speicher des Mehrkernprozessors gewährt wird, wenn das globale Mutex nicht von einem anderen Task gehalten wird.
Verfahren nach Anspruch 9, wobei das Einsetzen der Multiprozessorprioritätsobergrenzenprotokolle ferner umfasst, dass ein Task zu einer priorisierten Warteschlange an dem globalen Mutex hinzugefügt wird, bevor dem Task zuvorgekommen wird, wenn eine Anforderung hinsichtlich eines globalen Mutex nicht gewährt werden kann, wobei eine Priorität für den der priorisierten Warteschlange hinzugefügten Task vorab zugeordnet wird.