-
Die vorliegende Erfindung betrifft ein Verfahren zum Steuern von Prozessen. Die vorliegende Erfindung betrifft darüber hinaus eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes Speichermedium.
-
Stand der Technik
-
In der Betriebssystemtheorie hinlänglich bekannt sind sogenannte präemptive Prozess-Scheduler für Echtzeit-Betriebssysteme und Hypervisor. Ein Prozess-Scheduler letzterer Art kann dazu dienen, auf einem einzelnen Prozessorkern zum Beispiel eines Steuergeräts mehrere Gastsysteme (virtuelle Maschinen, VMs) zu betreiben, wobei etwaige Echtzeitanforderungen jedes Gastsystems erfüllt werden.
-
Zur Ressourcenzuteilung an konkurrierende Prozesse kommt hierbei etwa ein einfaches Rundlaufverfahren (round robin) zum Einsatz, das einzelnen Prozessen zur Laufzeit aufeinanderfolgende sogenannte Zeitschlitze (timeslices, timeslots) nach einem zyklischen Ausführungsplan zur Nutzung des Prozessorkerns zuteilt.
-
EP 2084606 B1 offenbart ein System mit mehreren Ausführungseinheiten und ein Verfahren zu dessen Umschaltung. Das System mit mehreren Ausführungseinheiten weist mindestens zwei Ausführungseinheiten auf und ist zwischen einem Performanz-Betriebsmodus, bei dem die Ausführungseinheiten unterschiedliche Programme ausführen, und einem Vergleichs-Betriebsmodus, bei dem die Ausführungseinheiten das gleiche Programm ausführen, umschaltbar. Das System weist einen Scheduler auf, der durch eine Ausführungseinheit zur Ermittlung des nächsten auszuführenden Programms aufgerufen wird. Dabei werden die übrigen Ausführungseinheiten dazu veranlasst, ebenfalls den Scheduler aufzurufen, wenn das durch den zuerst aufgerufenen Scheduler ermittelte Programm in einem Vergleichs-Betriebsmodus auszuführen ist. Eine Umschalteinheit schaltet das System mit mehreren Ausführungseinheiten von dem Performanz-Betriebsmodus in den Vergleichs-Betriebsmodus um, wenn das von dem zuletzt aufgerufenen Scheduler ermittelte auszuführende Programm in dem Vergleichs-Betriebsmodus auszuführen ist, wobei dieses ermittelte auszuführende Programm als Programm mit der höchsten Priorität durch alle Ausführungseinheiten nach dem Umschalten des Systems im Vergleichs-Betriebsmodus ausgeführt wird.
-
Offenbarung der Erfindung
-
Die Erfindung stellt ein Verfahren zum Steuern (scheduling) von Prozessen, eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein maschinenlesbares Speichermedium gemäß den unabhängigen Ansprüchen bereit.
-
Demnach wird das Rundlaufverfahren zur Ressourcenzuteilung an konkurrierende Prozesse derart erweitert, dass einzelnen besonders zeitkritischen Prozessen zur Laufzeit zusätzliche Zeitschlitze zur Nutzung des Prozessorkerns zugeteilt werden, ohne die übrigen Prozesse zeitlich zu beeinflussen oder einzuschränken. Die Zuteilung kann somit dynamisch angepasst werden, wenn einzelne Prozesse zum Beispiel mehr Rechenzeit oder kürzere Wartezeiten anfordern.
-
Durch die in den abhängigen Ansprüchen aufgeführten Maßnahmen sind vorteilhafte Weiterbildungen und Verbesserungen des im unabhängigen Anspruch angegebenen Grundgedankens möglich. So kann vorgesehen sein, dass die beschriebene Zuteilung auf Anforderung einer externen Software (SW) erfolgt, sodass ein etwaiger folgender verfügbarer Zeitschlitz zeitlich vorgezogen wird. Eine entsprechende Ausführungsform fußt auf der Erkenntnis, dass eine statische Zuordnung von Rechenzeit zu einzelnen VMs dazu führt, dass Latenzzeiten bei der Reaktion auf (aus Sicht der SW in einer VM) externe Ereignisse entstehen. Asynchronen Ereignisse wird in einem eingebetteten System (embedded system) üblicherweise durch eine Unterbrechung (interrupt) Rechnung getragen, d. h., der aktuelle Programmfluss wird unterbrochen und eine sogenannte Unterbrechungsroutine (interrupt service routine, ISR) ausgeführt. Dieses Verfahren erlaubt sehr schnelle Reaktionen der SW. In einem herkömmlichen Hypervisor ist dieses Verfahren schwer umsetzbar, da der VM ein Interrupt signalisiert wird, dieser aber erst bearbeitet wird, wenn der Zeitschlitz der entsprechenden VM vom Hypervisor ausgeführt wird. Dadurch entstehen Latenzzeiten bei der Reaktion auf externe Ereignisse, die sehr stark von der Konfiguration der Zeitschlitze abhängen. Grundsätzlich wäre es denkbar, eine geringere Latenzzeit zu erreichen, indem eine VM einfach sehr häufig ausgeführt wird (z. B. in jedem zweiten Zeitschlitz, dann entspräche die Latenzzeit im Wesentlichen höchstens der Dauer eines Zeitschlitzes). Diese Lösung birgt aber die Gefahr einer Ressourcenverschwendung, da Rechenzeit reserviert werden muss, die ggf. nur in Sonderfällen wirklich benötigt wird. Mit Hilfe des vorgeschlagenen Verfahrens kann Rechenzeit trotz einer grundsätzlich statischen Konfiguration dynamisch einzelnen VMs zugewiesen werden, wodurch die Latenzzeit bei der Reaktion auf externe Ereignisse drastisch reduziert wird. Dieses Verfahren erlaubt es, die beschriebene Schwäche abzumildern bzw. vollständig zu eliminieren.
-
Gemäß einem weiteren Aspekt kann vorgesehen sein, dass die Anforderung durch einen prozessorintensiven Prozess selbst gestellt und dieser anfordernde Prozess in eine Warteschlange eingereiht wird. Ein Vorzug dieses Aspekts besteht darin, dass er es zum Beispiel einer VM erlaubt, mehr Laufzeit aus dem statisch deklarierten (d. h. zur Übersetzungszeit beschränkten) Vorrat an überschüssiger Laufzeit abzurufen. Diesem Ansatz liegt die Einsicht zugrunde, dass eine statische Verteilung der Rechenzeit auf einzelne VMs dazu führen kann, dass Lastspitzen bei der Festlegung der Verteilung berücksichtigt werden müssen, sodass die Länge und Anzahl der Zeitschlitze sich immer aus der im ungünstigsten Fall (worst case) erforderlichen Laufzeit einer einzelnen VM ergeben. Für die Auslegung des Gesamtsystems müssen dann all diese Laufzeiten der verschiedenen VMs addiert werden, selbst wenn es Fälle gibt, in denen ein Eintritt des jeweils ungünstigsten Falles bei mehreren unabhängigen VMs nicht möglich oder wahrscheinlich ist. Somit muss viel Rechenzeit als Reserve vorgehalten werden. Mit Hilfe des vorgeschlagenen Verfahrens können, indem wie oben beschrieben Rechenzeit trotz der statischen Konfiguration dynamisch einzelnen VMs zugewiesen wird, die Ausführungszeiten im ungünstigsten Fall (Lastspitzen) abgefangen werden, ohne - in günstigeren Fällen ungenutzte - Reserven einzuplanen.
-
Gemäß einem weiteren Aspekt kann vorgesehen sein, dass die betreffende Anfrage abgewiesen wird, wenn die Warteschlange den anfordernden Prozess bereits enthält. Andere VMs können so zwar ihrerseits Rechenzeit aus dem vorhandenen Vorrat anfordern, aber die Methode stellt eine definierte Zuteilung sicher, wodurch alle korrekt betriebenen VMs vor fehlerhaften VMs geschützt werden, die zu viel aus dem Vorrat anfordern.
-
Gemäß einem weiteren Aspekt kann vorgesehen sein, dass der für einen nicht ausführbaren Prozess reservierte Zeitschlitz im Ausführungsplan als verfügbar gekennzeichnet und erst bei Aufhebung der Blockade erneut für den Prozess reserviert wird. Da die andernfalls ungenutzte Prozessorkapazität auf diese Weise gleichsam „aufgefangen“ wird, ist es nicht notwendig, die Gastsoftware (d. h. die durch eine VM ausgeführte Software) zu modifizieren, um anzuzeigen, wenn es möglich ist, zu einer anderen VM zu wechseln.
-
Gemäß einem weiteren Aspekt kann vorgesehen sein, dass, solange die Warteschlange leer ist, die verfügbaren Zeitschlitze zum Beispiel im Leerlaufprozess (system idle process) des Betriebssystems oder Hypervisors abgewartet werden. Die Timing-Eigenschaften eines Gastsystems sind so einfacher zu modellieren.
-
Figurenliste
-
Ausführungsbeispiele der Erfindung sind in den Zeichnungen dargestellt und in der nachfolgenden Beschreibung näher erläutert. Es zeigt:
- 1 das Flussdiagramm eines Verfahrens gemäß einer ersten Ausführungsform.
- 2 eine reguläre Ausführung von VMs.
- 3 die Ausführung bei einer Anforderung verfügbarer Zeitschlitze durch die VMs.
- 4 die Ausführung bei einer Einfügung verfügbarer Zeitschlitze auf externe Anforderung.
- 5 schematisch ein Steuergerät gemäß einer zweiten Ausführungsform.
-
Ausführungsformen der Erfindung
-
1 illustriert ein Verfahren (10) zum Steuern von Prozessen gemäß einem Aspekt der Erfindung. Die Prozesse werden hierbei in einem insoweit herkömmlichen Zeit-Multiplex-Verfahren nach einem zyklischen Ausführungsplan (11) reihum abgearbeitet. Erfindungsgemäß sieht der Ausführungsplan (11) über die für bestimmte Prozesse reservierten Zeitschlitze hinaus jedoch weitere, zunächst frei verfügbare Zeitschlitze vor. Der in 2 beispielhaft dargestellte Ausführungsplan (11) etwa sieht neun Zeitschlitze (18) vor, die jeweils für eine von fünf abbildungsgemäß mit 0, 1, 2, 3 und 4 nummerierten VMs reserviert sind. Zwei weitere Zeitschlitze (19) sind hingegen vorerst etwaigen Belastungsspitzen oder Unterbrechungsanforderungen vorbehalten.
-
Scheduler und Dispatcher unterscheiden (12 - 1) zwischen diesen gleichsam „statischen“ und „dynamischen“ Zeitschlitzen folgendermaßen: Während der reservierten Zeitschlitze wird - wie im Fall eines konventionellen Schedulers - jeweils der vorgegebene Prozess (13) abgearbeitet. Während der verfügbaren Zeitschlitze (19) hingegen werden besonders laufzeit- oder prozessorintensive Prozesse (17) abgearbeitet, die sich zu diesem Zweck über eine hierzu vorgesehene Programmierschnittstelle (application programming interface, API) in eine Warteschlange (16) einreihen können. Eine diesbezügliche Anfrage wird jedoch abgewiesen, wenn die Warteschlange (16) den anfragenden Prozess bereits enthält, sodass jeder Prozess in der Warteschlange (16) höchstens einmal vertreten und deren Tiefe so auf die Gesamtzahl der zu steuernden Prozesse beschränkt ist.
-
Ausgehend vom Ausführungsplan (11) der Figur 2 könnte sich so beispielsweise der Ablauf gemäß 3 ergeben. Hier wird auf Anforderung (21) von VM 1 der erste verfügbare Zeitschlitz (19) in die Warteschlange (16) eingereiht. Auf eine zweite Anforderung (22) hin wird auch die nunmehr anfordernde VM 2 in die Warteschlange (16) eingereiht. Eine dritte Anforderung (23) schließlich zeigt keine Auswirkung, da VM 1 an diesem Punkt bereits in der Warteschlange (16) steht.
-
Beim Eintritt in die - hier exemplarisch am Ende des Ablaufplans (16) vorgesehenen - verfügbaren Zeitschlitze (19) prüft (Entscheidung 14 - 1) der Scheduler hierzu zunächst die Elementanzahl der Warteschlange (16). Wäre letztere leer, so würde der anstehende Zeitschlitz (19) untätig abgewartet (Prozess 15 - 1); im Szenario der 3 jedoch werden ihr der Reihe nach (first in - first out, FIFO) zunächst VM 1 und sodann VM 0 entnommen und vom Dispatcher in dieser Folge zur Ausführung gebracht.
-
Ein alternativer Ablauf ist 4 zu entnehmen. Eine SW, die außerhalb der virtuellen Maschine ausgeführt wird (z. B. von einem µC-Core aus, der nicht unter Kontrolle des Hypervisors steht) hat hier Bedarf, VM 0 über ein externes Ereignis zu informieren (z. B. den Empfang von zeitkritischen Daten). Diese externe Software nutzt daher die Möglichkeit, dynamisch einen der verfügbaren Zeitschlitze (19) für VM 0 anzufordern und so eine zeitnahe Ausführung zu erreichen. Diese Anforderung (21) wird in die - in 4 nicht abgebildete - Warteschlange (16) eingetragen, woraufhin der angeforderte Zeitschlitz (19) vom Hypervisor direkt nach dem Zeitschlitz der VM 1 ausgeführt wird, in welchen die Anforderung (21) zeitlich fällt. Der verfügbare Zeitschlitz (19) ist also nicht an seine ursprüngliche Position am Ende des Ausführungsplans (16) gebunden, sondern wird gleichsam vorgezogen und an der nächsten Position eingefügt.
-
Diese Einfügung (injection) wiederholt sich entsprechend bei einer zweiten Anforderung (22), die sich nun auf VM 1 bezieht. Um die Gesamtdauer des Ausführungsplans (16) unverändert zu halten, wird auch in diesem Fall für den sozusagen „eingeschobenen“ verfügbaren Zeitschlitz (19) der ursprünglich im Ausführungsplan (16) vorgesehene verfügbare Zeitschlitz (19) gestrichen. Eine dritte Anforderung (23), die etwa VM 2 zum Gegenstand hat, bleibt daher ohne Auswirkung, da kein vorkonfigurierter verfügbarer Zeitschlitz (19) mehr zur Verfügung steht, der noch nicht verwendet wurde.
-
Dieses Verfahren (10) kann beispielsweise in Software oder Hardware oder in einer Mischform aus Software und Hardware beispielsweise in einem Steuergerät (20) implementiert sein, wie die schematische Darstellung der 5 verdeutlicht.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
