DE60317500T2

DE60317500T2 - Weniger aufwendige kontextumschaltung in mit statischen prioritäten gesteuerten betriebssystemen

Info

Publication number: DE60317500T2
Application number: DE60317500T
Authority: DE
Inventors: David Lake; John Tuffen
Original assignee: Livedevices Ltd
Current assignee: Livedevices Ltd
Priority date: 2002-04-25
Filing date: 2003-04-16
Publication date: 2008-10-02
Anticipated expiration: 2023-04-17
Also published as: DE60317500D1; EP1770517A2; GB2411751A; GB0511395D0; GB2387931A; US7082607B2; US20030204554A1; GB0209479D0; EP1770517A3

Description

Die vorliegende Erfindung bezieht sich auf Verfahren und Systeme zur Verringerung der Speicher- oder Prozessorbenutzung in Betriebssystemen, die von auf statischer Priorität basierender Ablaufsteuerung (Scheduling) Gebrauch machen, insbesondere bei der Verringerung der Notwendigkeit zur Ressourcenspeicherung bei Kontextwechseln bzw. -umschaltungen zwischen Tasks. Ausführungsformen der vorliegenden Erfindung sind von besonderer Relevanz für das technische Gebiet eingebetteter bzw. integrierter Vorrichtungen bzw. Bauelemente und ihrer Steuerung, da diese in Anbetracht des begrenzten Bereichs erforderlicher Funktionen im allgemeinen auf statischer Priorität basierende Ablaufsteuerung verwenden. Ausführungsformen der vorliegenden Erfindung können in Verbindung mit einer Erfindung verwendet werden, die in der gleichzeitig anhängigen U.K.-Patentanmeldung Nr. 0209800.2 des vorliegenden Anmelders vom 30. April 2002 offenbart ist, von der eine Kopie mit der vorliegenden Anmeldung eingereicht wird.
In einem Betriebssystem, das um auf statischer Priorität basierender Ablaufsteuerung herum basiert (Systeme, in denen die Prioritätsreihenfolge bzw. -ordnung von Tasks offline festgelegt wird und konstant bleibt) existiert irgend eine externe Beschreibung der Aufgaben- beziehungsweise Taskingstruktur des Systems, die verwendet wird, um Datenstrukturen zu erzeugen, die die Tasks und ihre Prioritäten beschreiben. Diese Datenstrukturen werden am vorteilhaftesten offline durch ein "Konfigurationswerkzeug" oder ein anderes Programm berechnet und verwendet, um das System zu initialisieren, wenn es hochfährt. Tasks in einem derartigen Betriebssystemen können zu jeder Zeit aktiviert werden, aber beginnen nicht abzulaufen, bis sie der ablauffähige Task mit der höchsten Priorität in dem System sind. Sie laufen weiter ab (auch wenn sie durch andere Tasks höherer Priorität unterbrochen werden können, wobei an diesem Punkt ein Kontextwechsel stattfindet), bis ihre Arbeit getan ist, und enden dann.
Anwendungen, die unter Verwendung derartiger Betriebssysteme aufgebaut sind, bestehen typischerweise aus einer Vielzahl simultaner Tasks, von denen jeder auf eine vorbestimmte Priorität eingestellt ist. Ausführungsformen der vorliegenden Erfindung beziehen sich darauf, die Menge an Kontext zu verringern, die gespeichert werden muss, wenn ein Kontextwechsel bzw. eine Kontextumschaltung zwischen zwei beliebigen Tasks durchgeführt wird.
Die vorliegende Erfindung wird in Hinblick auf ihre Anwendung auf ein Betriebssystem mit einer Tasksemantik mit einem einzelnen Stapel, Einmalausführung und Durchlauf bis zur Fertigstellung (single-stack, single-shot, run-to-completion task semantics) beschrieben, obwohl sie allgemein auf andere Formen von Taskingmodellen anwendbar ist.
Man betrachte ein System, das von irgendeiner Software- oder Hardwareressource Gebrauch macht, die für jeden Task so "erscheinen" muss, als wäre sie unter seiner exklusiven Kontrolle (zum Beispiel eine nicht ablaufinvariante Software-Fließkommaimplementierung, ein Satz von Hardware-Fließkommaregistern oder ein Satz von Akkumulatoren eines digitalen Signalprozessors). Wir bezeichnen die Sammlung von Daten, die geladen und gespeichert werden müssen, um jedem Task seine eigene Sicht derartiger Ressourcen zu geben, als einen "Ressourcenkontext", da dieser zusätzlich zu dem normalen Taskkontext ist.
In einem herkömmlichen System würden diese Ressourcen beim Eintritt in jeden Task gespeichert und wiederhergestellt, wenn der Task verlassen wird. Dies bedeutet, dass es für jedes System eine zusätzliche Speicherbenutzung von einem "Ressourcenkontext" pro Task in dem System geben würde.
Clement, B. J. et al., "Scheduling high-level tasks among cooperative agents", Multi-Agent Systems, 1998, Poc. Int. Conf. Paris, 3. bis 7. Juli 1998, IEEE Corp. Soc., 3. Juli 1998, Seiten 96 bis 103 offenbart ein Verfahren zur Gruppierung oder Zusammenlagerung von Tasks, um so Ressourcenkontexte beim Wechseln zu verringern.
Saksena, M. et al., "Scalable Real-Time System Design Using Preemption Thresholds", Bericht des 21. IEEE Echtzeitsystemymposiums, IEEE Piscataway, 2000, Seiten 25 bis 34 offenbart die Integration von Zeitfolgeanalyseergebnissen mit Ergebnissen von einem Betriebssystem-Konfigurationswerkzeug.
US 6,052,707 offenbart präemptives Multitasking mit kooperativen Gruppen von Tasks.
Gemäß einem ersten Aspekt der vorliegenden Erfindung wird ein Verfahren zur Verringerung von Speicher- oder Prozessorbenutzung in einem Betriebssystem bereitgestellt, das auf statischer Priorität basierende Ablaufsteuerung für Tasks verwendet, wie es in Anspruch 1 beansprucht ist.
Andere Aspekte von Ausführungsformen der Erfindung werden unten beschrieben und in den verbleibenden Ansprüchen beansprucht.
Das Softwareprodukt kann in jeder geeigneten Form oder Sprache vorliegen und kann auf einem Datenträger gespeichert sein, wie etwa einer Diskette, einer optischen Platte, einer Flashspeichervorrichtung oder irgendeiner anderen Art von Datenträger.
Wir werden zuerst die Bedeutung von "Hülle" (wrapper) und "Zuteiler" (dispatcher) diskutieren, wie sie nachfolgend in der vorliegenden Anmeldungen verwendet werden, bevor wir potenti elle Implementierungen von Ausführungsformen der Erfindung diskutieren.
Eine "Hülle" bzw. ein "Wrapper" ist in dieser Anmeldung als ein Fragment von Programmcode definiert, das einen Task einkapselt und an seiner Stelle durch das zu Grunde liegende Betriebssystem aufgerufen wird. Wenn wir zum Beispiel einen Task "Task 1" betrachten, dessen "Eintritt" (die Funktion, die nützliche Arbeit ausführt) wie folgt definiert ist:
können wir es unter manchen Umständen (zum Beispiel wenn Laden oder Speichern von Kontext erforderlich ist) wünschen, ihn durch eine Hülle zu ersetzen:
Ein "Zuteiler" bzw. "Dispatcher" führt im Wesentlichen dieselben Aktivitäten durch, aber anstatt dass die Taskeintrittfunktion ersetzt ist, ist das Betriebssystem selbst modifiziert, um die Vor- und Nach-Task-Aufrufe durchzuführen. Zum Beispiel könnten wir den folgenden Code innerhalb des Betriebssystems finden:
Die Beschreibung dieser Erfindung konzentriert sich auf die Verwendung von Hüllen, auch wenn ein Ansatz ähnlich zu diesem, der aber modifizierte Formen der Betriebssystem-Zuteilerfunktion verwendet, ebenfalls möglich ist.
Lassen Sie uns nun ein Beispiel einer unoptimierten Konfiguration eines Systems betrachten, das Taskhüllen verwendet. Lassen Sie uns annehmen, dass ein System wie folgt deklariert ist (wobei höhere Zahlen eine höhere Priorität implizieren):

Task a Priorität 1;
Task b Priorität 2;
Task c Priorität 3;
Task d Priorität 4;
Task e Priorität 5;

Trivialerweise würde dieses System fünf "Ressourcenkontexte" benötigen – einen für jeden der Tasks a, b, c, d und e, um ihre Ressourcen in diesen zu speichern, wenn sie durch Tasks höherer Priorität unterbrochen werden. Jeder Task würde durch eine "Hülle" geschützt sein, die sicherstellt, dass der "Ressourcenkontext" in den geeigneten Puffer gespeichert würde, und der Betriebssystemzuteiler bzw. -dispatcher würde diese anstatt der Taskeintrittfunktion aufrufen – zum Beispiel würde der Systemzuteiler, anstatt unmittelbar zu "Task d Eintritt" zu springen, eine Hülle aufrufen:
(In diesem Fall zeigen wir, dass die Hülle in einer C-artigen Sprache erzeugt ist und die Deklaration des "Ressourcenkontexts" selbst enthält – obwohl diese auch in Assemblersprache mit geeignetem Code und geeigneten Datendeklarationen erzeugt werden könnte oder durch Aufruf verschiedener Varianten oder Zweige der Betriebssystem-Zuteilerfunktion herbeigeführt werden könnte).
Der Systemzuteiler könnte in diesem Fall eine Tabelle von Funktionszeigern verwenden, um zu entscheiden, welche Funktion für jeden Task aufgerufen werden soll. In einer hypothetischen Assemblersprache könnte sich dies wie folgt darstellen:

Task Eintritt_Tab: ÖFFENTLICH
.Zeiger Task_a_Eintritt_Hülle
.Zeiger Task_b_Eintritt_Hülle
.Zeiger Task_c_Eintritt_Hülle
.Zeiger Task_d_Eintritt_Hülle
.Zeiger Task_e_Eintritt_Hülle

Aber lassen Sie uns annehmen, dass nur drei der Tasks von Ressourcen Gebrauch machen, die gespeichert und wiederhergestellt werden müssen – die Systembeschreibung wird modifiziert in:

Task a Priorität 1 verwendet FK;
Task b Priorität 2 verwendet FK;
Task c Priorität 3;
Task d Priorität 4 verwendet FK;
Task e Priorität 5;

In diesem System ist die Deklaration "verwendet FK" hinzugefügt, um anzugeben, dass ein Task den Fließkomma-Koprozessor verwendet. Wenn ein Task nicht explizit erwähnt, dass er irgendetwas verwendet, das einen "Ressourcenkontext" erfordert, dann wird keiner bereitgestellt (und es ist keine Hülle erforderlich – das Betriebssystem (BS) kann die Eintrittfunktion des Tasks unmittelbar aufrufen).
Eine logische Folgerung des obigen besteht darin, dass der Task niedrigster Priorität, der eine gemeinsam genutzte Ressourcen verwendet, keine Hülle bereitstellen muss, um diesen Kontext zu laden oder zu speichern – da der Unterbrecher (preemter) den Kontext speichert und nicht der Unterbrochene (preemptee. Die äußerste Ausweitung hiervon ist es, dass jedes System, in dem nur ein Task eine gemeinsam genutzte Ressource verwendet, keine Hülle oder Speicherung erfordert, da es nichts anderes gibt, was die Ressource verwendet, um ihn zu unterbrechen (pre-empt).
Dies bedeutet, dass nur zwei Ressourcenkontexte und Hüllen erzeugt werden müssen (für Task b und Task d). In diesem Fall könnte die Zuteilungstabelle wie folgt aussehen:

Task Eintritt Tab: ÖFFENTLICH
.Zeiger Task_a_Eintritt # keine Notwendigkeit für Hülle – Unterbrecher speichert
.Zeiger Task_b_Eintritt Hülle # erfordert Hülle, kann a unterbrechen
.Zeiger Task_c_Eintritt # keine Notwendigkeit für Hülle – kein FK
.Zeiger Task_d_Eintritt_Hülle # erfordert Hülle, kann b unterbrechen
.Zeiger Task_e_Eintritt # keine Notwendigkeit für eine Hülle

Hieran kann eine weitere Optimierung vorgenommen werden. Man nehme an, dass wir einen Mechanismus haben, um festzustellen, dass zwei Tasks in gegenseitigem Ausschluss (Mutual Exclusion) zueinander ablaufen (das heißt für ein Paar von Tasks x und y, dass auch dann, wenn x von höherer Priorität als y ist, x niemals y unterbrechen kann).
Man betrachte diese Systembeschreibung, die die Tasks a und b in gegenseitigen Ausschluss bringt:

Task a Priorität 1 verwendet FK;
Task b Priorität 2 verwendet FK;
Task c Priorität 3;
Task d Priorität 4 verwendet FK;
Task e Priorität 5;
Mutex a, b;

Unter der Voraussetzung, dass die Tasks a und b sich in gegenseitigem Ausschluss befinden, können wir daher einen weiteren Ressourcenkontext und eine weitere Hülle entfernen – nur Task d muss den "Ressourcenkontext" speichern und wiederherstellen, da er der einzige Task höherer Priorität ist, der den Status der gemeinsam genutzten Ressourcen beeinflussen kann, so dass in diesem Fall nur Task d mit einer Hülle und einem "Ressourcenkontext" erzeugt werden würde.
Es ist darauf hinzuweisen, dass Tasks oder dergleichen dann, wenn sie dieselbe Priorität teilen, in derselben Weise behandelt werden können, als wenn sie sich in gegenseitigem Ausschluss befinden.
Man betrachte auch diese Variante:

Task a Priorität 1 verwendet FK;
Task b Priorität 2;
Task c Priorität 3 verwendet FK;
Task d Priorität 4 verwendet FK;
Task e Priorität 5;
Mutex c, d;

In diesem System ist es klar, dass beide Tasks c und d eine Hülle benötigen, um den Kontext zu speichern, aber sie können denselben Ressourcenkontext gemeinsam nutzen, da sie sich in gegenseitigem Ausschluss befinden. Die Hüllen können von der Form sein:
Auch wenn wir in dieser Beschreibung nur Tasks diskutieren, ist dieses Schema einheitlich unter der Voraussetzung auf Unterbrechungsdienstroutinen (Interrupt Service Routines, ISR) erweiterbar, dass wir eine Unterbrechungsprioritätsreihenfolge feststellen können – so würde jede ISR, die eine bestimmte Ressource verwendet, diese Ressource speichern und wiederher stellen müssen, wenn sie durch eine andere Unterbrechung bzw. einen anderen Interrupt höherer Priorität unterbrochen werden könnte. (Unterbrechungen bzw. Interrupts mit derselben Priorität aber einer unterschiedlichen Entscheidungsreihenfolge werden als in einer Gruppe gegenseitigen Ausschlusses befindlich betrachtet).
Ein Algorithmus, der durch ein Offline-Konfigurationswerkzeug zur Festlegung von Ressourcenkontexten und Hüllen verwendet werden könnte, könnte wie folgt sein:
Es ist ersichtlich, dass dieser Algorithmus lediglich ein Beispiel einer Art und Weise ist, um Ressourcenkontexte festzulegen. Ausführungsformen der vorliegenden Erfindung können diesen Algorithmus oder jeden anderen geeigneten Algorithmus oder jedes andere geeignete Verfahren verwenden, das denselben oder einen ähnlichen Effekt erzielt.
Eine einfache Erweiterung dieses Ansatzes würde es jedem Gerät ermöglichen, mehrere gemeinsam genutzte Ressourcen zu verwenden, wobei optimale Hüllen für jeden Task auf Basis der Ressource(n) erzeugt werden, die er verwendet – man betrachte zum Beispiel das folgende System, das Fließkommaregister und eine digitale Signalprozessoreinheit (DSP-Einheit) hat:

Task a Priorität 1 verwendet FK;
Task b Priorität 2 verwendet DSP, FK;
Task c Priorität 3 verwendet FK;
Task d Priorität 4 verwendet DSP;
Task e Priorität 5 verwendet DSP, FK;
Task f Priorität 6 verwendet FK;

In diesem System:
Task a benötigt keine Hülle (da der Unterbrecher die Ressourcen speichert)
Task b benötigt eine Hülle, die nur den "FK"-Kontext speichert (er ist der Task niedrigster Priorität, der den "DSP"-Kontext verwendet, so dass er ihn nicht speichern muss)
Task c benötigt eine Hülle, die nur den "FK"-Kontext speichert
Task d benötigt eine Hülle, die nur den "DSP"-Kontext speichert (er ist der erste unterbrechende Task, der ihn verwendet)
Task e benötigt eine Hülle, die beide Kontexte speichert
Task f benötigt eine Hülle, die nur den "FK"-Kontext speichert.
Derartige Hüllen können automatisch aus Codeskeletten erzeugt werden, die durch den Benutzer des Konfigurationswerkzeugs bereitgestellt werden.
Das Verfahren des ersten Aspekts kann ferner umfassen, dass Ergebnisse von einem Zeitfolgeanalysewerkzeug (timing analysis tool) mit einem Betriebssystem-Konfigurationswerkzeug in einer solchen Weise integriert werden, dass dann, wenn es durch das Zeitfolgeanalysewerkzeug gezeigt wird, dass ein bestimmter Task niemals einen anderen Task oder andere Tasks unterbricht, mit dem bzw. mit denen er um eine Ressource streitet, nur ein einziger Ressourcenkontext erzeugt wird, wobei der einzige Ressourcenkontext durch die Tasks gemeinsam genutzt wird.
Die Rechenvorrichtung des zweiten Aspekts kann ferner ein Zeitfolgeanalysewerkzeug aufweisen, das angepasst ist, um Zeitfolgeanalyseergebnisse mit Ergebnissen von einem Betriebssystem-Konfigurationswerkzeug in einer solchen Weise zu integrieren, dass dann, wenn es durch das Zeitfolgeanalysewerkzeug gezeigt wird, dass ein bestimmter Task niemals einen anderen Task unterbricht, mit dem er um eine Ressource streitet, nur ein einziger Ressourcenkontext erzeugt wird, wobei der einzige Ressourcenkontext durch die Tasks gemeinsam genutzt wird.
Das Softwareprodukt des dritten Aspekt kann angepasst sein, um Ergebnisse von einem Zeitfolgeanalysewerkzeug mit einem Betriebssystem-Konfigurationswerkzeug in einer solchen Weise zu integrieren, dass dann, wenn es durch das Zeitfolgeanalysewerkzeug gezeigt wird, dass ein bestimmter Task niemals einen anderen Task unterbricht, mit dem er um eine Ressource streitet, nur ein einziger Ressourcenkontext erzeugt wird, wobei der einzige Ressourcenkontext durch die Tasks gemeinsam genutzt wird.
Mit anderen Worten können die Ergebnisse einer Zeitfolgeanalyse, die in ihrer Natur heuristisch sein kann, anstelle von oder zusätzlich zu Ergebnissen von einer formalen Ablaufsteuerbarkeitsanalyse verwendet werden, um Tasks als effektiv in gegenseitigem Ausschluss befindlich zu kennzeichnen. Auf diese Weise wird eine Vervielfältigung von Ressourcenkontexten und/oder Hüllen vermieden.
Es ist darauf hinzuweisen, dass eine Zeitfolgeanalyse mit Hilfe eines Zeitfolgeanalysewerkzeugs erhalten werden kann, das Verfahren, wie etwa ratenmonotone Analyse (Rate Monotonic Analysis) und Erweiterungen davon anwendet, um unter anderem festzustellen, wann ein gegebener Task ablaufen könnte, die letzte Zeit festzustellen, zu der der gegebene Task enden könnte, und festzustellen welche anderen Tasks den gegebenen Task möglicherweise unterbrechen können.
Man nehme zum Beispiel das folgende einfache periodische System:
Task t1 Priorität 1 alle 20 Ticks Dauer 5 Ticks Versatz 0 Ticks verwendet FK;
Task t2 Priorität 2 alle 20 Ticks Dauer 5 Ticks Versatz 2 Ticks verwendet FK;
Das Ausführungsprofil dieses Systems ist in 1 der beigefügten Zeichnungen gezeigt. In diesem System unterbricht Task t2 immer Task t1 zwei "Ticks" in seinen Ablauf, wobei das System zu Task t1 zurückkehrt, nachdem t2 nach fünf "Ticks" aufgehört hat, abzulaufen. Da beide Tasks eine Verwendung der Fließkommaregister teilen, muss Task t2 daher ihren Kontext laden und speichern.
Man betrachte jedoch das folgende System:
Task t1 Priorität 1 alle 20 Ticks Dauer 5 Ticks Versatz 0 Ticks verwendet FK;
Task t2 Priorität 2 alle 20 Ticks Dauer 5 Ticks Versatz 10 Ticks verwendet FK;
Das Ausführungsprofil dieses Systems ist in 2 der beigefügten Zeichnungen gezeigt. In diesem System unterbricht Task t2 niemals Task t1 – ein Zeitfolgeanalysewerkzeug kann daher berechtigterweise den Schluss ziehen, dass die Tasks in gegenseitigem Ausschluss ablaufen können, und durch automatische Hinzufügung der Deklaration
Mutex t1, t2;
zu der Systemdeklaration kann dies die Erzeugung von Hüllen und Kontextspeicherinformationen für diese zwei Tasks verhindern.
Der Ansatz ist auf jede Form von Analyse erweiterbar, die demonstrieren kann, dass für jedes Paar von Tasks x, y keine Bedingung existiert, unter der die Tasks einander unterbrechen können.
Zum Beispiel zeigt ein veröffentlichtes Dokument des Standes der Technik mit dem Titel: "How embedded applications using an RTOS can stay within an-chip memory limits" [Robert Davis, Nick Merriam und Nigel Tracey, Tagungsbericht der Sitzung in Arbeit und industrielle Erfahrung, Euromicro-Konferenz über Echtzeitsysteme, Juni 2000.] wie Ablaufsteuerbarkeitsanalyse verwendet werden kann, um Tasks in Mutexe zu sammeln, während sichergestellt wird, dass alle Tasktermine eingehalten werden. Es ist einfach, diese Verfahren so zu erweitern, dass Mutexerzeugung die Kombination von Stapelgröße und Kontextspeicherbereichen minimiert, indem diejenigen Tasks, die ansonsten separate Kontextspeicherbereiche erfordern würden, in Mutexe gruppiert werden.
Die bevorzugten Merkmale der Erfindung sind auf alle Aspekte der Erfindung anwendbar und können in jeder möglichen Kombination verwendet werden.
Überall in der Beschreibung und den Ansprüchen dieser Spezifikation bedeuten die Wörter "aufweisen" bzw. "umfassen" und "enthalten" und Variationen der Wörter, zum Beispiel "aufweisend" bzw. "umfassend" und "aufweist" bzw. "umfasst", "einschließlich, aber nicht darauf beschränkt" und sind nicht dazu beabsichtigt (und tun es nicht), andere Komponenten, ganze Zahlen, Teile, Hilfsmittel oder Schritte auszuschließen.

Claims

Verfahren zum Verringern der Speicher- oder Prozessorbenutzung in einem Betriebssystem, das präemptive Ablaufsteuerung mit statischer Priorität verwendet, wobei die Ablaufsteuerung eine Vielzahl von Prioritäten aufweist, die einer Vielzahl von Tasks zugeordnet sind, von den jeder einen jeweiligen Ressourcenkontext hat, und wobei die Prioritäten offline festgelegt worden sind, dadurch gekennzeichnet, dass für eine bestimmte Ressource Daten für entsprechende Ressourcenkontexte, die von dem Betriebssystem beim Ausführen der Tasks benötigt werden, bestimmt werden, indem bestimmt wird, welche der Tasks erfordern, dass Ressourcenkontexte zur Verwendung der bestimmten Ressource gespeichert und wiederhergestellt werden, wobei Hüllen oder Zuteiler nur für Tasks vorgesehen werden, die solche Ressourcenkontexte speichern und wiederherstellen müssen, und dadurch, dass der Schritt des Bestimmens von einem oder mehreren von dem Folgenden abhängt: a. Identifizieren von einem der Tasks mit einer niedrigsten Priorität für die bestimmte Ressource und Schließen, dass jeder derartige identifizierte Task nicht ein Task ist, der eine entsprechende Hülle oder einen entsprechenden Zuteiler benötigt, um einen Ressourcenkontext zu speichern und wiederherzustellen, und b. Identifizieren von einem der Tasks, dessen Verwendung der bestimmen Ressource sich mit Verwendungen der Ressource durch einen anderen Task gegenseitig ausschließt, wobei das Identifizieren das Identifizieren von zumindest einem Paar von Tasks der Vielzahl von Tasks umfasst, die einander gegenseitig ausschließend betrieben werden können, und Schließen, das zumindest das Paar von Tasks unter Verwendung gemeinsam genutz ten Codes betrieben werden kann, um einen Ressourcenkontext zu speichern und wiederherzustellen.
Verfahren nach Anspruch 1, bei dem die Schritte des Identifizierens von einem der Tasks der Vielzahl von Tasks mit einer niedrigsten Priorität und des Schließens, dass jeder derartige identifizierte Task nicht ein Task ist, der eine entsprechende Hülle oder einen entsprechenden Zuteiler benötigt, um einen Ressourcenkontext zu speichern und wiederherzustellen, die Schritte aufweisen, einen Task der Vielzahl von Tasks mit einer niedrigsten jeweiligen Priorität in Bezug auf zumindest eine erste gemeinsam genutzte Ressource zu identifizieren und zu schließen, dass der identifizierte Task nicht ein Task ist, der eine Hülle oder einen Zuteiler benötigt, um einen Ressourcenkontext in Bezug auf die zumindest erste gemeinsam genutzte Ressource zu speichern und wiederherzustellen.
Verfahren nach Anspruch 1, bei dem der Schritt des Identifizierens von zumindest einem Paar von Tasks der Vielzahl von Tasks, die sich gegenseitig ausschließend betrieben werden können, und des Schließens, dass zumindest das Paar von Tasks unter Verwendung des gemeinsam genutzten Codes betrieben werden kann, um einen Ressourcenkontext zu speichern und wiederherzustellen, die Schritte aufweist, zumindest ein Paar von Tasks der Vielzahl von Tasks zu identifizieren, die in Bezug auf eine gemeinsam genutzte Ressource einander gegenseitig ausschließend betrieben werden können, und zu schließen, dass zumindest das Paar von Tasks unter Verwendung des gemeinsam genutzten Codes betrieben werden kann, um einen Ressourcenkontext in Bezug auf die gemeinsam genutzte Ressource zu speichern und wiederherzustellen.
Verfahren nach einem der Ansprüche 1 und 3, bei dem der Schritt des Identifizierens von zumindest dem Paar von Tasks der Vielzahl von Tasks, die in Bezug auf eine gemeinsam genutzte Ressource oder anderweitig einander gegenseitig ausschließend betrieben werden können, den Schritt aufweist, diejenigen Tasks der Vielzahl von Tasks zu bestimmen, die niemals zusammen laufen werden, wobei das Bestimmen eine Zeitfolgeanalyse oder eine Ablaufsteuerbarkeitsanalyse des Betriebssystems verwendet.
Verfahren nach einem der Ansprüche 1 bis 4, das den Schritt aufweist, eine einzelne Ressourcenkontextdeklaration zur Verwendung durch das zumindest eine Paar einander gegenseitig ausschließend betreibbarer Tasks zu definieren.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Tasks Unterbrechungsdienstroutinen sind.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Schritte des Identifizierens die Schritte aufweisen, Hüllen oder Zuteiler zum Speichern und Wiederherstellen eines Ressourcenkontexts der jeweiligen Ressourcenkontexte für alle Tasks der Vielzahl von Tasks zuzuweisen, redundante Kontexte zusammenzuführen und redundante Hüllen oder Zuteiler zum Speichern und Wiederherstellen eines Ressourcenkontexts der jeweiligen Ressourcenkontexte zu entfernen.
System mit einem Mittel zum Implementieren eines Verfahrens nach einem der vorhergehenden Ansprüche.
Computerprogramm mit Code, der ausgestaltet ist, um bei der Ausführung ein Verfahren oder System nach einem der vorhergehenden Ansprüche zu implementieren.
Computerlesbarer Speicher, der ein Computerprogramm nach einem der vorhergehenden Ansprüche speichert.
Rechenvorrichtung, die einen Speicher, einen Prozessor und ein Betriebssystem aufweist, das präemptive Ablaufsteuerung mit statischer Priorität einer Vielzahl von Tasks verwendet, wobei jeder Task einen jeweiligen Ressourcenkontext und eine jeweilige Ausführungspriorität hat, wobei die Rechenvorrichtung gemäß einem Verfahren nach einem der Ansprüche 1 bis 7 erzeugte Hüllen oder Zuteiler speichert, die vorgesehen sind, um einen Ressourcenkontext der jeweiligen Ressourcenkontexte nur für diejenigen Tasks zu speichern und wiederherzustellen, die dazu in der Lage sind, einen anderen Task oder Code zu blockieren, und wobei die Rechenvorrichtung angepasst ist, um diese Hüllen oder Zuteiler auszuführen.