AT513762B1 - Verfahren zum Schutz vor Unterbrechung einer festgelegten Befehlssequenz eines Prozesses durch einen anderen Prozess in einer Datenverarbeitungsanlage - Google Patents

Abstract

Die Erfindung betrifft ein Verfahren zum Schutz vor Unterbrechung einer festgelegten Befehlssequenz eines Prozesses durch einen anderen Prozess in einer Datenverarbeitungsanlage, wobei die Prozesse auf mindestens einem Prozessor ablaufen. Um eine atomare Abarbeitung von Prozessen unter Verhinderung einer Prioritätsumkehr zu ermöglichen, ist vorgesehen, -dass ein erster Prozess (EOS-Task1) am Beginn seiner Ausführung der festgelegten Befehlssequenz beim Betriebssystemkern (EOS-Kernel) wegen einer Sperre (EOS-Lock) des Prozessors für andere Prozesse anfragt, diese Sperre vom Betriebssystemkern gewährt wird, sofern kein anderer Prozess diese Sperre bereits eingeschaltet hat, und die Sperre zugunsten des ersten Prozesses (EOS-Task1) vom Betriebssystem so lange aufrecht erhalten wird, bis der erste Prozess am Ende seiner Ausführung der festgelegten Befehlssequenz die Sperre wieder aufhebt, und -dass ein zweiter Prozess (E0S-Task2), der während einer Sperre des Prozessors zugunsten eines ersten Prozesses {EOS-Task1) wegen der Benutzung des Prozessors anfragt, vom Betriebssystemkern keinen Zugriff auf den Prozessor erhält, der Betriebssystemkern jedoch diesen zweiten Prozess aufruft, nachdem der erste Prozess die Sperre aufgehoben hat.

Description

österreichisches Patentamt AT513 762B1 2014-10-15

Beschreibung

VERFAHREN ZUM SCHUTZ VOR UNTERBRECHUNG EINER FESTGELEGTEN BEFEHLSSEQUENZ EINES PROZESSES DURCH EINEN ANDEREN PROZESS IN EINER DATENVERARBEITUNGSANLAGE

TECHNISCHES GEBIET

[0001] Die Erfindung betrifft ein Verfahren zum Schutz vor Unterbrechung einer festgelegten Befehlssequenz eines Prozesses durch einen anderen Prozess in einer Datenverarbeitungsanlage, wobei die Prozesse auf mindestens einem Prozessor ablaufen, sowie ein entsprechendes Computerprogrammprodukt. Das Verfahren dient also zur Beeinflussung des zeitlichen Ablaufs von mehreren Prozessen in einer Datenverarbeitungsanlage.

[0002] Als Prozess wird in der Informatik ein Vorgang einer algorithmisch ablaufenden Informationsverarbeitung verstanden. Läuft ein Prozess auf der untersten Systemebene (dem Kernel oder Kern eines Betriebssystems), wird er als Task bezeichnet. Die vorliegende Erfindung kann besonders gut auf solche Tasks angewendet werden.

[0003] Ein Betriebssystemkern oder Systemkern (englisch kernel) ist der zentrale Bestandteil eines Betriebssystems. In ihm ist die Prozess- und Datenorganisation festgelegt, auf der alle weiteren Softwarebestandteile des Betriebssystems aufbauen.

[0004] Er bildet die unterste Softwareschicht des Systems und hat direkten Zugriff auf die Hardware. Gängige Anforderungen an einen Systemkern sind Parallelverarbeitung verschiedener Aufgaben (Multitasking), Einhaltung zeitkritischer Grenzen, Offenheit für unterschiedlichste Anwendungen und Erweiterungen.

[0005] Die Datenverarbeitungsanlage zur Ausführung des erfindungsgemäßen Verfahrens kann einen oder mehrere Prozessoren enthalten.

[0006] Ein Prozess umfasst mehrere einzelne Abschnitte, die jeweils durch einen oder mehrere Befehle in einer Programmiersprache bzw. Maschinensprache dargestellt und dann vom Prozessor ausgeführt werden. Oft ist es wichtig, dass eine zuvor festgelegte Abfolge von Befehlen, eine Befehlssequenz, nicht unterbrochen werden darf. Man spricht dann von einer atomaren Befehlssequenz.

[0007] Verfahren zum Schutz vor Unterbrechungen in einer Befehlssequenz eines Prozesses durch einen anderen Prozess sind beispielsweise bekannt aus US/2009/0177828 A1, US 7,698,708 B1 oder US 2008/0059677 A1.

STAND DER TECHNIK

[0008] In Datenverarbeitungsanlagen wird der zeitliche Ablauf von Prozessen, d. h. von in sich geschlossenen, auf Programmen basierenden Datenverarbeitungsvorgängen, durch die Ablaufsteuerung des Betriebssystems koordiniert, um Zugriffskonflikte zu vermeiden. Dadurch mögliche Zugriffskonflikte müssen durch einen Schutz vermieden werden.

[0009] Der Schutz kann beispielsweise über ein spezielles Zustandsbit, auch Semaphor genannt, erfolgen, das dem Betriebsmittel zugeordnet ist, auf das die Prozesse gemeinsam zugreifen, etwa der CPU (dem Zentralprozessor). Vor jedem Zugriff auf das gemeinsam genutzte Betriebsmittel muss durch den jeweiligen Prozess zunächst festgestellt werden, welchen seiner zwei möglichen Zustände "frei" und "belegt" das entsprechende Semaphor gerade einnimmt. Befindet sich das Semaphor in dem Zustand "frei", so kann der Zugriff auf das entsprechende Betriebsmittel erfolgen und das Semaphor wird für die Zugriffsdauer in den Zustand "belegt" überführt. Für andere Prozesse ist damit das Betriebsmittel gesperrt. Nach Beendigung des Zugriffs auf das Betriebsmittel wird das Semaphor auf "frei" gesetzt, so dass das Betriebsmittel wieder anderen Prozessen zur Verfügung steht. Die Verwendung von Semaphoren ist beispielsweise in der Einleitung der DE 19904085 A1 genannt. Semaphore bergen jedoch das 1 /8 österreichisches Patentamt AT513 762B1 2014-10-15

Risiko einer sogenannten priority Inversion (Prioritätsumkehr) der beteiligten Prozesse (Tasks). Ein Prozess mit niedriger Priorität läuft gerade am Prozessor und hat das Semaphor auf „belegt” gesetzt. Ein zweiter Prozess mit hoher Priorität ist bereit, um ausgeführt zu werden, muss aber warten, weil das Semaphor auf „belegt” geschaltet ist. Existiert nun ein Prozess mit mittlerer Priorität, der das Betriebsmittel bzw. das Semaphor nicht verwendet, kann dieser mittelpriore Prozess den niederprioren Prozess verdrängen, d.h. der mittelpriore Prozess wird an Stelle des niederprioren Prozesses ausgeführt. Der niederpriore Prozess kann das Betriebsmittel bzw. das Semaphor nun nicht mehr freigeben, so dass der hochpriore Prozess nicht zur Ausführung kommt. Damit hindert der mittelpriore Prozess indirekt auch den hochprioren Prozess an der Ausführung, was er nach dem Prinzip des Prioritätsschedulings nicht darf. Die Priorität des hochprioren Prozesses und des mittelprioren Prozesses sind somit vertauscht. Es wird also fälschlich ein Prozess mit hoher Priorität nicht abgearbeitet, was sich kritisch auf die Sicherheit des gesamten Software-Mulititasking-Systems auswirken kann.

[0010] DE 19904085 A1 selbst betrifft ein Verfahren zum Steuern des zeitlichen Ablaufs von Prozessen in einer Datenverarbeitungsanlage, wobei bei dem den auf mindestens einem Prozessor ablaufenden Prozessen durch ein Steuerprogramm jeweils mindestens ein Haltepunkt zugeordnet und für diesen Haltepunkt mindestens eine Steuerungsinformation bereitgestellt wird, die aus der Gesamtheit der ablaufenden Prozesse jeweils einen Prozess bezeichnet und dessen Zustandswechsel zwischen einem aktivierten Zustand und einem nicht aktivierten Zustand definiert, die Prozesse in ihrem Ablauf jeweils an dem ihnen zugeordneten Haltepunkt unterbrochen werden und bei diesen Unterbrechungen jeweils der Zustandswechsel des be-zeichneten Prozesses gemäß der dem Haltepunkt zugeordneten Steuerungsinformation veranlasst wird. Dies hat jedoch den Nachteil, dass die Prozesse unterbrochen werden, was nicht in jedem Anwendungsfall gewünscht bzw. möglich ist.

[0011] Eine andere Möglichkeit der Koordination besteht darin, dass auf Software-Ebene für die Dauer der Bearbeitung die Anwendungen (Prozesse) durch Interrupt-Sperren blockiert werden, wie dies etwa in der DE 10237350 A1 dargelegt ist. Dies birgt das Risiko, dass ein undurchschaubares Geflecht von Interrupt-Sperren und Freigaben entsteht, insbesondere dann, wenn die Sperren und Freigaben verschachtelt werden, also in verschachtelten Funktionen realisiert werden. So kann etwa die Interrupt-Sperre zu früh aufgehoben werden, wenn ein Hauptprogramm ein Unterprogramm aufruft, dieses selbst eine Interrupt-Sperre setzt und diese auch selbst wieder löscht: diese hätte jedoch erst durch das Hauptprogramm wieder gelöscht werden dürfen, welches das Unterprogramm aufgerufen hat. Folglich könnte nun das Hauptprogramm unterbrochen werden, was ja gerade nicht gewünscht war.

DARSTELLUNG DER ERFINDUNG

[0012] Es ist eine Aufgabe der vorliegenden Erfindung, ein Verfahren zum Schutz vor Unterbrechung einer festgelegten Befehlssequenz eines Prozesses (einem sogenannten atomaren Teil oder Bereich des Prozesses) durch einen anderen Prozess in einer Datenverarbeitungsanlage zur Verfügung zu stellen, welches einerseits die sogenannte atomare Abarbeitung von Prozessen (Tasks) ermöglicht, also das Abarbeiten eines Prozesses ohne Unterbrechung durch einen anderen Prozess, andererseits aber eine Prioritätsumkehr verhindert.

[0013] Diese Aufgabe wird durch ein Verfahren mit den Merkmalen des Patentanspruchs 1 gelöst. Vorteilhafte Ausgestaltungen der Erfindung sind in den jeweiligen abhängigen Ansprüchen definiert.

[0014] Gemäß Anspruch 1 ist bei einem Verfahren zum Schutz vor Unterbrechung einer festgelegten Befehlssequenz eines Prozesses durch einen anderen Prozess in einer Datenverarbeitungsanlage, wobei die Prozesse auf mindestens einem Prozessor ablaufen, vorgesehen, [0015] - dass ein erster Prozess am Beginn seiner Ausführung der festgelegten Befehlssequenz beim Betriebssystemkern wegen einer Sperre des Prozessors für andere Prozesse anfragt, diese Sperre vom Betriebssystemkern gewährt wird, sofern kein anderer Prozess diese Sperre bereits eingeschaltet hat, und die Sperre zugunsten des ersten Prozesses vom Be- 2/8 österreichisches Patentamt AT513 762B1 2014-10-15 triebssystem so lange aufrecht erhalten wird, bis der erste Prozess am Ende seiner Ausführung der festgelegten Befehlssequenz die Sperre wieder aufhebt, und [0016] - dass ein zweiter Prozess, der während einer Sperre des Prozessors zugunsten eines ersten Prozesses wegen der Benutzung des Prozessors anfragt, vom Betriebssystemkern keinen Zugriff auf den Prozessor erhält, der Betriebssystemkern jedoch diesen zweiten Prozess aufruft, nachdem der erste Prozess die Sperre aufgehoben hat.

[0017] Durch die einzige Sperre, die vom Betriebssystemkern verwaltet wird, ist sichergestellt, dass der atomare Teil (welche der festgelegten Befehlssequenz entspricht) des ersten Prozesses tatsächlich zu Ende geführt werden kann, ohne von einem weiteren Prozess unterbrochen zu werden. Die schützenswerten Teile einzelner Prozesse (Tasks) können somit atomar abgearbeitet werden.

[0018] Ein Kontextwechsel oder Taskswitching (engl, context switch) findet also nicht statt: dies bezeichnet den Vorgang in einem Betriebssystem, bei dem die Bearbeitung des aktuellen Prozesses (oder auch Threads, Tasks oder Programms) unterbrochen wird (z. B. nach einer festgelegten Zeitspanne durch einen Timer-Interrupt oder bei Systemaufrufen) und zu einem anderen Prozess gewechselt wird. Dabei wird der Kontext (im Wesentlichen die Prozessor-Register) des aktuellen Prozesses gesichert und der Kontext des neuen restauriert.

[0019] Dadurch, dass der Betriebssystemkern erfindungsgemäß Anfragen anderer Prozesse, die während der Abarbeitung des sperrenden Prozesses eingehen, speichert und diese Prozesse nach Beendigung der Sperre wieder aufruft, kann sichergestellt werden, dass der nächste anfragende Prozess auch tatsächlich als nächstes abgearbeitet wird.

[0020] Nun kann auch der Fall auftreten, dass mehrere Prozesse während der Abarbeitung des atomaren Teils des ersten Prozesses auf den Prozessor zugreifen wollen und einen Systemaufruf senden. Ein Systemaufruf, auch Systemcall (von engl. System call) oder kurz Syscall, ist eine von Anwendungsprogrammen benutzte Methode, um vom Betriebssystem bereitgestellte Funktionalitäten auszuführen, wie etwa das Lesen einer Datei oder die Benutzung des Prozessors. Dabei wird die Kontrolle vom Programm an das Betriebssystem übergeben.

[0021] Wenn aufgrund der Länge bzw. Laufzeit der Prozesse zu erwarten ist, dass mehrere Prozesse während des Abarbeitens eines Prozesses wegen einer Benutzung des Prozessors anfragen, so kann vorgesehen werden, dass ein dritter Prozess bzw. ein weiterer Prozess, der während der Sperre des Prozessors zugunsten des ersten Prozesses und nach dem zweiten Prozess wegen der Benutzung des Prozessors anfragt, vom Betriebssystemkern keinen Zugriff auf den Prozessor erhält, der Betriebssystemkern jedoch den zweiten, dritten bzw. weiteren Prozess entsprechend ihrer Priorität nacheinander aufruft, sobald der erste Prozess die Sperre aufgehoben hat.

[0022] Es kann somit zu keiner Prioritätsumkehr im eingangs beschriebenen Sinn kommen. Denn die Sperre aufheben kann nur der erste Prozess. Falls nun mehrere Tasks während des atomaren Teils des ersten Prozesses laufen wollen, so stellt das Betriebssystem sicher, dass sie in der richtigen Reihenfolge (Priorität) aufgerufen werden. Wenn also der zweite Prozess eine niedrigere Priorität hat als der dritte, dann wird nach dem atomaren Teil des ersten Prozesses zuerst der dritte Prozess aufgerufen und dann erst der zweite Prozess. Der Betriebssystemkern priorisiert die noch abzuarbeitenden Prozesse also nach ihrer Priorität für Zugriff auf den Prozessor.

[0023] Von Vorteil ist es, zu berücksichtigen, dass bei der Erstellung von Programmen für die einzelnen Prozesse Fehler unterlaufen können, indem etwa die Laufzeit der Prozesse zu lang ist, was bei Echtzeitverfahren kritisch ist, weil andere wichtige Prozesse erst später und möglicher Weise dann zu spät ausgeführt werden können. Insofern kann vorgesehen sein, dass der Betriebssystemkern in regelmäßigen, fix vorgegebenen Intervallen, welche der maximal zulässigen Laufzeit eines Prozesses entsprechen, einen Interrupt generiert, welcher den laufenden Prozess trotz Sperre unterbricht und einen Prozess zur Fehlerbehandlung aufruft.

[0024] Dieser Prozess zur Fehlerbehandlung kann nun bewirken, dass der unterbrochene 3/8 österreichisches Patentamt AT513 762 B1 2014-10-15

Prozess nicht weiter ausgeführt wird, die Sperre, welche der unterbrochene Prozess gesetzt hat, aufgehoben wird und etwa eine Fehlermeldung ausgegeben wird. Zusätzlich kann vorgesehen sein, dass dieser Prozess nicht mehr durchgeführt werden darf.

[0025] Insofern sollte bei der Programmierung der einzelnen Prozesse darauf geachtet werden, dass beim Ablauf der Prozesse auf dem Prozessor eine bestimmte maximale Zeitdauer des atomaren Abschnitts des Prozesses nicht überschritten wird, weil ja sonst eine Fehlerbehandlung eingeleitet werden muss. Je nach der Taktfrequenz des Prozessors entspricht die maximale Zeitdauer des atomaren Abschnitts des Prozesses einer maximalen Anzahl von Maschinenbefehlen.

[0026] Das erfindungsgemäße Verfahren kann auch Prozesse umfassen, die mehrere festgelegte Befehlssequenzen (atomare Bereiche) aufweisen, die nicht unterbrochen werden dürfen. In der Regel sind diese atomaren Bereiche durch andere Befehlssequenzen voneinander getrennt, die unterbrochen werden können.

[0027] Das erfindungsgemäße Computerprogrammprodukt bewirkt bei seinem Laden und Ausführen auf einer Datenverarbeitungsanlage einen erfindungsgemäßen Verfahrensablauf. Es umfasst also ein Programm, das direkt in einen Speicher einer Datenverarbeitungsanlage ladbar ist, mit Programm-Mitteln, um alle Schritte des Verfahrens nach einem der vorhergehenden Ansprüche auszuführen, wenn das Programm ausgeführt wird.

[0028] Die Erfindung ist insbesondere dazu geeignet, als Computerprogramm (Software) realisiert zu werden. Sie kann damit als Computerprogramm-Modul als Datei auf einem Datenträger wie einer Diskette, DVD- oder CD-ROM oder als Datei über ein Daten- bzw. Kommunikationsnetz verbreitet werden. Derartige und vergleichbare Computerprogramm-Produkte oder Computerprogramm-Elemente sind Ausgestaltungen der Erfindung. Dabei ist klar, dass entsprechende Computer, auf denen die Erfindung angewandt wird, weitere, an sich bekannte technische Einrichtungen wie Eingabemittel (Tastatur, Mouse, Touchscreen), einen Mikroprozessor, einen Daten- bzw. Steuerungsbus, eine Anzeigeeinrichtung (Monitor, Display) sowie einen Arbeitsspeicher, einen Festplattenspeicher und eine Netzwerkkarte enthalten können.

KURZBESCHREIBUNG DER FIGUREN

[0029] Zur weiteren Erläuterung der Erfindung wird im nachfolgenden Teil der Beschreibung auf die Figur Bezug genommen, aus der weitere vorteilhafte Ausgestaltungen, Einzelheiten und Weiterbildungen der Erfindung zu entnehmen sind.

AUSFÜHRUNG DER ERFINDUNG

[0030] In der Figur ist von oben nach unten der zeitliche Ablauf der Prozesse (erster Prozess EOS-Task1, zweiter Prozess EOS- Task2) sowie zugehöriger Hilfsprozesse (Programmable Interrupt Timer PIT, Prozess zur Fehlerbehandlung EOS- Errorhandler) im Betriebssystem des Prozessors gemäß der Erfindung dargestellt. Die einzelnen Prozesse bzw. Hilfsprozesse sind jeweils durch eine eigene senkrechte strichlierte Linie dargestellt. Wenn der einzelne Prozess bzw. Hilfsprozesse aktiv ist, ist dies durch einen senkrechten Balken dargestellt.

[0031] Ein erster Prozess, hier EOS-Task1 genannt, soll durch den Prozessor ausgeführt, jedoch dabei nicht unterbrochen werden. Der EOS-Task1 ist so programmiert, dass er zuerst eine Anfrage an das Betriebssystem, genauer, an den hier mit EOS-Kern bezeichneten Betriebssystemkern, des Prozessors sendet, um den Prozessor für andere Prozesse zu sperren. Dieser Vorgang ist in der Figur unter Bezugszeichen 1 „Setzen von EOS-Lock" dargestellt. Die Sperre des Prozessors für andere Prozesse wird als EOS-Lock bezeichnet.

[0032] Unter Bezugszeichen 1a „Prüfung EOS-Lock" prüft der Betriebssystemkern EOS-Kern, ob bereits von einem anderen Prozess eine Sperre des Prozessors bewirkt worden ist, ob also EOS-Lock bereits gesetzt ist. Das dient zur Erkennung eines Programmierfehlers im EOS-Taskl, falls nach dem ersten Setzen von EOS-Lock nochmals ein EOS-Lock gesetzt wird. Ein anderer Prozess, wie EOS-Task2, kann den EOS-Lock zu diesem Zeitpunkt also gar nicht 4/8 österreichisches Patentamt AT513 762B1 2014-10-15 setzen, weil er schon durch EOS- Taskl gesetzt ist.

[0033] Diese erfindungsgemäße Lösung, wonach die Sperre EOS-Lock als Kernel-Prozess ausgeführt ist (Kernel-Task, durch den Betriebssystemkern ausgeführter Prozess) ist ein wichtiger Unterschied zu den bekannten Interrupt-Sperren, die direkt von den einzelnen Prozessen exekutiert werden, wo also ein Prozess einen anderen sperren kann, ohne eine übergeordnete Kontrolle vom Betriebssystemkern.

[0034] Liegt noch kein EOS-Lock vor, so merkt sich der Betriebssystemkern EOS-Kern den EOS-Lock, der vom EOS-Task1 gesetzt worden ist, und ruft den ersten Prozess EOS-Task1 auf, siehe Bezugszeichen 2 „Aufruf EOS-Task1".

[0035] Der Prozessor verfügt über einen sogenannten Programmable Interval Timer (PIT), der auch als Systemuhr bezeichnet wird und als eigener Bauteil (Chip) ausgeführt sein kann. Dieser PIT sendet in gleichbleibenden Intervallen Interrupts an den Betriebssystemkern EOS-Kern. Dieser Interrupt löst bestimmte Prozesse des Betriebssystems aus, die regelmäßig durchgeführt werden müssen. Gängige Intervalle für den PIT liegen zwischen 1 und 10 ms.

[0036] Der Interrupt mit einem Intervall hier von einer 1 ms löst einen Kernel-Interrupt aus für die Prozesse, die am Prozessor laufen, und hat im gegenständlichen Fall den Zweck, dass kein Prozess den Prozessor so lange verwenden kann, dass andere zeitkritische Prozesse nicht an die Reihe kommen. Dies ist insbesondere für Echtzeit-Betriebssysteme notwendig, die technische Anwendungen in Echtzeit steuern.

[0037] Dauert nun der erste Prozess EOS-Task1 länger als das Intervall von 1 ms, so wird EOS-Task1 vom EOS-Kern mittels Kernel-Interrupt unterbrochen, was unter Bezugszeichen 3 „Kernel-Interrupt" dargestellt ist. EOS-Kern überprüft nun, ob der EOS-Lock länger als die Laufzeit von EOS-Task1 ist. Gegebenenfalls wird der EOS-Errorhandler aufgerufen, der eine Sicherheitsreaktion einleiten kann. Die Sicherheitsreaktion kann die Eigenschaft eines optischen Warnhinweises, die Eintragung eines Fehlercodes in eine Log-Datei, Abbruch von EOS-Task1 mit Aufheben der Sperre bis hin zur Einnahme eines sicheren Zustandes des Gesamtsystems haben. Dies ist unter Bezugszeichen 3a „EOS Errorhandler (Laufzeitüberschreitung von EOS-Taskl)" dargestellt.

[0038] Falls ein anderer Prozess, hier der zweite Prozess EOS-Task2, während der Schutzzeit (= Zeit, während das eigentliche Programm des EOS-Task1 abgearbeitet wird, in der Figur mit „CRITICAL SECTION" bezeichnet) auf den Prozessor zugreifen (= einen Context Switch durchführen) möchte, erkennt der EOS-Kern den EOS-Lock-Zustand und verhindert einen Zugriff auf den Prozessor. Dies geschieht auch, wenn der erste Prozess EOS-Task1 gerade aufgrund des Kernel-Interrupts unter 3 unterbrochen ist. Der EOS-Kern merkt sich aber, dass ein Context Switch zufolge eines EOS-Lock unterdrückt wurde und dass EOS-Task2 nach dem Ende des EOS-Locks gerufen werden muss. Dies ist unter Bezugszeichen 4 „Prüfung EOS-Lock EOS-Task2 würde ohne EOS-Lock aktiviert" dargestellt. Wäre also EOS-Lock nicht gesetzt, dann würde der EOS-Kern aus Prioritätsgründen nun den zweiten Prozess EOS-Task2 aktivieren.

[0039] Da aber EOS-Lock gesetzt ist, ruft der Betriebssystemkern EOS-Kern erneut den ersten Prozess EOS-Task1 auf, was unter 4a „Aufruf EOS-Task4" dargestellt ist. Der erste Prozess EOS- Taskl wird somit fortgesetzt und kann seine „CRITICAL SECTION" (= atomarer Bereich) weiter abarbeiten. Wenn der erste Prozess EOS-Task1 am Ende der „CRITICAL SECTION" angelangt ist, löscht er den EOS-Lock wieder, siehe Bezugszeichen 5 „Löschen des EOS-Locks".

[0040] Der EOS-Kern führt dann den zuvor unterdrückten Context- Switch zu EOS-Task2 aus, siehe Bezugszeichen 6 „Aufruf EOS- Task2": dieser zweite Prozess EOS-Task2 wird sodann vom Prozessor abgearbeitet und es erfolgen die gleichen Schritte wie zuvor beim ersten Prozess EOS-Task1: EOS-Task2 setzt einen EOS-Lock (wie unter Bezugszeichen 1 für EOS-Taskl), der vom EOS-Kern überprüft wird (wie unter Bezugszeichen 1a für EOS-Task1), und so weiter.

[0041] Wenn mehrere Tasks während der Schutzzeit von EOS-Task1 einen Context Switch 5/8 österreichisches Patentamt AT513 762B1 2014-10-15 verlangen, muss eine Prioritätsumkehr bei der Ausführung dieser Tasks verhindert werden. Der Betriebssystemkern EOS-Kern verwaltet die Anfragen der Tasks für einen Context Switch, welche zeit- und/oder ereignisgesteuert sind. Die zeitgesteuerten Tasks werden vom EOS-Kern nach einer konfigurierbaren Zeittabelle aufgerufen, daher darf die Schutzzeit von EOS-Task1 zu keiner Laufzeitüberschreitung der zeitgesteuerten Tasks führen. Die ereignisgesteuerten Tasks werden aufgrund von Nachrichten in einer „Message Queue" vom EOS-Kern aufgerufen.

[0042] Alle zeit- und/oder ereignisgesteuerten Context-Switch Anfragen vor dem Setzen von EOS-Lock durch EOS-Task1 werden eingefroren, während der Schutzzeit von EOS-Task1 können ereignisgesteuerte Context-Switch Anfragen anderer Tasks nicht gestellt werden, bzw. werden zeitgesteuerte Context- Switch Anfragen vom EOS-Kern nicht bearbeitet. Nachdem EOS- Taskl den EOS-Lock gelöscht hat, setzt der EOS-Kern mit der Abarbeitung der Context-Switch Anfragen fort und berücksichtigt dabei auch die Prioritäten der Prozesse, die den Context-Switch anfragen. BEZUGSZEICHENLISTE: CRITICAL SECTION Schutzzeit EOS-Lock EOS-Task1 EOS-Task2 EOS-Kern EOS-Error Händler PIT (1 ms)

Sperre des Prozessors erster Prozess, der vom Prozessor ausgeführt werden soll zweiter Prozess, der vom Prozessor ausgeführt werden soll Betriebssystemkern Prozess zur Fehlerbehandlung

Programmable Interval Timer für den Betriebssystemkern EOS-Kern mit Intervall von 1 ms 6/8

Claims (6)

1. österreichisches Patentamt AT 513 762 B1 2014-10-15 Patentansprüche 1. Verfahren zum Schutz vor Unterbrechung einer festgelegten Befehlssequenz eines Prozesses durch einen anderen Prozess in einer Datenverarbeitungsanlage, wobei die Prozesse auf mindestens einem Prozessor ablaufen, dadurch gekennzeichnet, - dass ein erster Prozess (EOS-Task1) am Beginn seiner Ausführung der festgelegten Befehlssequenz beim Betriebssystemkern (EOS-Kernel) wegen einer Sperre (EOS-Lock) des Prozessors für andere Prozesse anfragt, diese Sperre vom Betriebssystemkern gewährt wird, sofern kein anderer Prozess diese Sperre bereits eingeschaltet hat, und die Sperre zugunsten des ersten Prozesses (EOS- Taskl) vom Betriebssystem so lange aufrecht erhalten wird, bis der erste Prozess am Ende seiner Ausführung der festgelegten Befehlssequenz die Sperre wieder aufhebt, und - dass ein zweiter Prozess (EOS-Task2), der während einer Sperre des Prozessors zugunsten eines ersten Prozesses (EOS-Task1) wegen der Benutzung des Prozessors anfragt, vom Betriebssystemkern keinen Zugriff auf den Prozessor erhält, der Betriebssystemkern jedoch diesen zweiten Prozess aufruft, nachdem der erste Prozess die Sperre aufgehoben hat.
2. 2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass ein dritter Prozess bzw. ein weiterer Prozess, der während der Sperre des Prozessors zugunsten des ersten Prozesses und nach dem zweiten Prozess wegen der Benutzung des Prozessors anfragt, vom Betriebssystemkern keinen Zugriff auf den Prozessor erhält, der Betriebssystemkern jedoch den zweiten, dritten bzw. weiteren Prozess entsprechend ihrer Priorität nacheinander aufruft, sobald der erste Prozess die Sperre aufgehoben hat.
3. 3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass der Betriebssystemkern in regelmäßigen, fix vorgegebenen Intervallen, welche der maximal zulässigen Laufzeit eines Prozesses entsprechen, einen Interrupt generiert, welcher den laufenden Prozess trotz Sperre unterbricht und einen Prozess zur Fehlerbehandlung aufruft.
4. 4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass der Prozess zur Fehlerbehandlung die weitere Ausführung des unterbrochenen Prozesses unterbindet und die Sperre aufhebt.
5. 5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass ein Prozess mehrere festgelegte Befehlssequenzen aufweist, die nicht unterbrochen werden dürfen.
6. 6. Computerprogrammprodukt, welches ein Programm umfasst, das direkt in einen Speicher einer Datenverarbeitungsanlage ladbar ist, mit Programm-Mitteln, um alle Schritte des Verfahrens nach einem der Ansprüche 1 bis 5 auszuführen, wenn das Programm ausgeführt wird. Hierzu 1 Blatt Zeichnungen 7/8