DE4236820C2 - Verfahren zum sicheren Betrieb eines Prozeßrechners - Google Patents

Description

Die Erfindung bezieht sich auf ein Verfahren zum sicheren Betrieb eines Prozeßrechners, bei dem ein Betriebssystem mit Multitaskingfähigkeit verwendet wird, mit einer vorgegebenen, begrenzten Zahl von Tasks, mit einem Betriebssystemkern zum Starten, Beenden, Anhalten und Fortsetzen einer Task und einer Schnitt stelle zwischen Betriebssystemdiensten und Betriebssystemkern, die eine freie Programmierung der Betriebssystemdienste zuläßt.

Betriebssysteme sind in den verschiedensten Ausführungsformen bekannt, z. B. MS-DOS.

Bei Betriebssystemen wird häufig eine Echtzeit-Multitasking­ fähigkeit gefordert, d. h. ein beliebiger Prozeß (Verarbeitung von Daten) darf zu jeder Zeit von einem anderen Prozeß unterbrochen werden, ohne daß die geplante Funktionalität der Systemsoftware dabei beeinträchtigt wird.

Die Unterbrechung wird dabei von außen, d. h. der Peripherie, verursacht und ist daher in bezug auf innere Vorgänge der Systemsoftware vollkommen asynchron.

Bekannte Betriebssysteme mit Multitaskingfähigkeit, wie z. B. UNIX, sind verhältnismäßig komplizierte und mächtige Pro­ gramme, bei denen die Strukturen vor allem in sicherheits­ relevanter Hinsicht nicht ganz einfach zu überprüfen sind.

Ein mächtiges System der eingangs genannten Art ist beispielsweise unter der Bezeichnung R MOS 2 näher in der Zeitschrift "Design und Elektronik", Ausgabe 2, vom 20. 01. 1987, auf den Seiten 83 bis 93 beschrieben.

Die Aufgabe der vorliegenden Erfindung besteht darin, ein einfaches Verfahren der eingangs genannten Art zum sicheren Betrieb eines Prozeßrechners anzugeben.

Diese Aufgabe wird erfindungsgemäß gelöst durch eine Ko­ ordinierung der Tasks über mit Bitmasken abgefragte Flags, bei der jeweils jeder Bitposition eine Task zugeordnet ist.

Nachfolgend ist die Lösung im Detail beschrieben.

Inhaltverzeichnis zur Lösung

Kapitel 1: Allgemeines
Kapitel 2: Grundarchitektur/Arbeitsweise
Kapitel 3: Nahtstellenbeschreibung
Anhang A: Glossar
Anhang B: Übersichtsschaltbild und Flußdiagramme

Kapitel 1: Allgemeines

Die Lösung besteht in der ARCHITEKTUR eines kleinen Be­ triebssystemes (zukünftig benannt mit dem Namen MICROS = MICRO Realtime Operating System) für Echtzeit-Multi­ tasking-Betrieb. Der BETRIEBSSYSTEMKERN ist der Schwer­ punkt der Architektur. Die Lösung zeichnet sich aus durch.

• a) Ein Taskverwaltungsverfahren für eine begrenzte Anzahl von Tasks (z. B. 16). Das Starten, Beenden, Anhalten, Fortsetzen einer Task ist Aufgabe des Betriebssystem­ kernes.
  Durch geeignete Algorithmen und entsprechende Defini­ tion der internen Variablen kann auf die (bei anderen Betriebssysteme übliche) mehrzweck dynamische Spei­ cherverwaltung verzichtet werden. Der vom Betriebs­ systemkern verwendete Speicher ist statisch; für be­ stimmte Funktionen (z. B. Mailboxes) vom Anwender als Puffer definierbar und (intern) über Zeiger verwaltet. Ein (oder mehrere) zentraler Speicher-Pool(s) aus deren Blöcke sich unterschiedliche Dienste bedienen, existieren hier nicht. Daher
  • - Einfachem Analyse im Fehlerfall. Folgefehler aufgrund von Blöcken, die vorzeitig zurückgege­ ben wurden und bereits für einen anderen Zweck vergeben sind, können nicht auftreten.
  • - Deadlocks wegen Erschöpfung der Memory-Resour­ cen sind ausgeschlossen.
• Die Koordinierung wird bei MICROS ausschließlich über Boolsche Variablen (Flags) realisiert. Die umfangrei­ che (und lauf zeitraubende) Blockverkettung in ver­ schiedenen Warteschlangen bei herkömmlichen Betriebs­ systemen trifft hier nicht zu. Warteschlangen werden bei MICROS als Bitmasken dargestellt, wobei jede Bitposition einen Task entspricht.
  Da die Variablen-Manipulation bei der Verwaltung ziem­ lich eingeschränkt ist, liegen die entsprechende Lauf­ zeiten sehr gut im Vergleich zu anderen Betriebssyste­ men. Ein guten Beispiel davon ist das Taskstarten per Interrupt.
• b) Die zu Taskverwaltung dazugehörige Nahtstelle zwischen den Kern die Betriebssystemdienste.
  Durch die gut ausgewählte Nahtstelle zum Betriebssys­ temkern können die Betriebssystemdienste (auch SVCs genannt; siehe Glossar: Anhang A) in einer beliebigen Hochsprache mit wenig Aufwand programmiert werden. Die SVCs sind voneinander unabhängige Softwarebausteine deren Menge und Oberfläche nach Bedarf (und mit weni­ gen Einschränkungen) an den Kern einzubinden sind, um eine Betriebssystem "nach Maß" herzustellen (einfache Skalierbarkeit).
  Hinweis: SVCs die in diesem Text als Beispiel aufge­ führt sind, sind bekannte Algorithmen. Nur die SVC- Nahtstelle zum MICROS-Kern soll geschützt werden.

Durch die einfache (und übersichtliche) Betriebssystem­ architektur können Verhaltensabweichungen des Prozeßrech­ ners während des Betriebes (Störungen) schnell untersucht werden. Eine bessere Garantie der Nachvollziehbarkeit im Störungsfall ist somit angeboten.

Kapitel 2: Grundarchitektur/Arbeitsweise 2.1 Allgemeines

Die (gesamte) Software einer Verarbeitungseinheit für Prozeßautomatisierung (siehe Übersichtschaltbild Fig. 1 lädt sich grundsätzlich in 3 Teile gliedern:

• - Anwenderprogramme (Tasks, siehe Glossar/Anhang A),
• - Betriebssystem,
• - Softwaretreiber (für Peripheriegeräte)

wobei das Betriebssystem (für Echtzeit-Multitasking-Be­ trieb) in dieser Betrachtung wiederum in

• - Betriebssystemkern (Taskverwalter),
• - Betriebssystemdienste (SVCS: siehe Glossar: Anhang A)

unterteilt wird. Andere Softwarekomponenten wie BIOS, Excep­ tionshändler u. a. bleiben hier, aufgrund der Übersicht­ lichkeit, außer Betrachtung.

Die Kommunikation zwischen den verschiedenen Teilen wurde in dem Bild durch die Anstöße (Signale) S1, S2,. . .S11 dargestellt.

S1

Ein Betriebssystemdienst (SVC) läuft bei MICROS als Unter­ programm der aufrufenden Task.
Beispiel: Semaphor testen und setzen.
call tsf(sem$id, sts$d)
wobei
sem$id: Identität des Semaphors (0, 1, . . .)
sts$ad: Adresse einer Status-Variable, wo die Ergebnisse der Operation zu hinterlegen sind (OK bzw. Fehler).

S2

Bei der SVC-Bearbeitung kann es notwendig sein, den Task anzuhalten (blockieren). Beispiele dafür sind:

• - Ein Task versucht einen Semaphor zu erobern, welcher bereits belegt ist (beim SVC "Semaphor testen und set­ zen").
• - Ein Task soll eine bestimmte Zeit warten ("PAUSE- SVC").

Das Anhalten (blockieren) der Task ist Aufgabe des Be­ triebssystemkernes und erfolgt innerhalb des SVCs (d. h. bei der Ausführung vom SVC-Code). Ab dieser Stelle (Adres­ se) im SVC-Unterprogramm soll die Task nachher ihre Be­ arbeitung fortsetzen. Dazu müssen Fortsetzungsadresse und Inhalt sämtlichen Register (Task-Kontext) gespeichert (gerettet) werden.

Der Kern sucht anschließend eine andere (niederpriore) Task zu starten oder fortzusetzen. Findet er keine, so gerät er in die sogenannte Untätigkeitsschleife.

S3

Der SVC in Bearbeitung stellt eine Anforderung an den Betriebssystemkern eine bestimmte Task zu starten oder fortzusetzen. Der Kern setzt die Task in "READY-Zustand (siehe Glossar: Task-Zustände). Hat die Task (im Vergleich zu anderen READY-Tasks) die höchste Priorität, so wird sie unmittelbar gestartet bzw. fortgesetzt (S4 bzw. S5).

S4

Angeregt durch einen Interrupt (S6) oder einen Task-Start- SVC (S3) startet der Scheduler (Bestandteil des Betriebs­ systemkernes) eine Task.

S5

Auf Anforderung von einem SVC (S3) oder von Softwaretrei­ bern (S8) setzt der Scheduler (Bestandteil des Betriebs­ systemkernes) eine Task fort. Die Taskfortsetzung erfolgt bei der Adresse (im SVC-Unterprogramm), an der sie ange­ halten wurde.

S6

Interruptanstoß aus der Peripherie um eine Task zu star­ ten.

S7, S8

Ein Peripheriegerät, für den ein Softwaretreiber vom Be­ triebssystem verwaltet wird, meldet den Abschluß einer Eingabe-/Ausgabe-Operation. Aus S7 folgt S8. Die E-/A- Operation wurde vorher durch S9 eingeleitet.

S9

Ein Peripheriegerät, für den ein Softwaretreiber vom Be­ triebssystem verwaltet wird, wird von einer Task (über einen SVC) angesprochen (Engl. Request Input Output, ab­ gekürzt RIO). Das RIO-SVC ruft die entsprechende SVC- Treiberserverroutine; die Task wird dabei angehalten. Die Aufgabe der SVC-Treiberserverroutine besteht darin, die E- /A-Operation einzuleiten. Nach einen oder mehreren Inter­ rupts (siehe S7 bzw. S8) ist die E-/A-Operation abge­ schlossen und die Task darf ihre Bearbeitung fortsetzen.

S10

Siehe Glossar (Anhang A): "Task-Start per unerwarteten Interrupt".

S11

Siehe Glossar (Anhang A): "Zeitgeber".

2.2 MICROS-Arbeitsweise

Anhand zweier Beispiele (siehe 2.2.1 und 2.2.2) wird die MICROS-Arbeitsweise erläutert. Auf dem MICROS-Kern-Fluß­ diagramm und Glossar (siehe jew. Anhang A und B) wird dauernd verwiesen.

2.2.1 Ablauf einer "Taskstart per Interrupt"

Ein externer (Hardware-)Interrupt (Anstoß aus der Peri­ pherie) soll eine Task starten. Die Task wird in Zukunft als "Task A" bezeichnet.

Bei Tasks, die über einen (Hardware-)Interrupt zu starten sind, muß bei dem Taskdefinitionsparameter (in MICROS- Konfigurationsdatei) eine Vektornummer angegeben werden. Das MICROS-Initialisierungsprogramm ordnet diesem Vektor einen Prolog zu (siehe Prolog in Glossar und MICROS- Kern-Flußdiagramm Fig. 7).

• 1. Nach dem Interruptanstoß werden im Prolog sämtliche Prozessorregister gerettet (siehe MICROS-Kern-Flußdia­ gramm Fig. 7).
• 2. Wird gerade eine SVC bearbeitet (Flag "svc_active"), so wird es abgefragt ob die Task A eine höhere Priorität hat als die Task, die die SVC aufgerufen hat (active Task). Wenn ja, wird das Flag "special-event" gesetzt. In dem Fall wird die Task A erst beim SVC-Abschluß gestartet (Unterprogramm "x_svc_done"; siehe Flußdiagr. Fig. 5b).
  Es wird danach abgefragt ob die Task A bereits ruht (Zustand: "dormant"). Wenn Ja, wird die Task A "READY" markiert. Nach Zurücksetzen vom Interruptcontroller (siehe Flußdiagramm Fig. 8), geht die Bearbeitung zu Ende. Andernfalls wird ein Zähler inkrementiert, damit die Interruptanstoß nicht verlorengeht (qstart- counter).
• 3. Wird in dem Augenblick, wo der Interrupt schlägt, kein SVC bearbeitet, so wird, nach Bestätigung daß die Task A "dormant" ist, die Task A "READY" gesetzt. Der Inter­ ruptcontroller wird zurückgesetzt (siehe MICROS-Kern- Flußdiagr. Fig. 8) und der Scheduler sucht nach dem Task mit der höchsten Priorität in der Menge der "READY-Tasks" (Sprung nach Label "mic_sch:" siehe Fluß­ diagr. Fig. 2). Erfüllt die Task A diese Bedingung, so wird sie unmittelbar gestartet. Andernfalls ist das Starten bis dahin verzögert. In dem Fall, daß die Task A nicht "dormant" ist, wurde (wie im Punkt 2) der qstart-counter inkrementiert.

Der Fall "Task-Fortsetzen nach einer Interruptanforderung" trifft bei folgenden Situationen zu:

• - Ein Treiber beendet einen "E/A-Operation" (siehe Glos­ sar: Anhang A),
• - Eine Task (z. B. der Debugger) wird per unerwarteten Interrupt gestartet (siehe Glossar "Task Starten per unerwarteten Interrupt"),
• - Eine Task soll nach Ablauf einer PAUSE fortgesetzt werden.

Die Bearbeitung ist sehr ähnlich wie das "Taskstart per Interrupt" (siehe MICROS-Kern-Flußdiagramm Fig. 6) und benötigt daher keine extra Erklärung.

2.2.2 Ablauf einer SVC-Bearbeitung

Als Beispiel wird das SETZEN und RÜCKSETZEN eines Sema­ phors nachvollzogen.

Semaphor testen und setzen

• 1. Eine Task (in Zukunft als "Task A" bezeichnet) ruft die SVC "SEMAPHOR TESTEN UND SETZEN" auf.
• 2. Als Erstes wird das Flag "sve-active" gesetzt (Schutz gegen Unterbrechung von Tasks einer höheren Priorität: siehe Flußdiagramm, Fig. 9).
• 3. Hat die Semaphorvariable die Grenze noch nicht errei­ cht, so inkrementiert das SVC-Unterprogramm die Variable und beendet sich mit den Aufruf "x_svc_done" (in MICROS-Kern-Routine, siehe MICROS-Kern-Flußdiagramm Fig. 5b). In dieser Routine wird abgefragt, ob seit dem das "svc-active-Flag" gesetzt ist, eine Interruptstart­ anforderung an einer Hochprioretask vorgekommen ist (Flag "special-event"). Ist es der Fall, wird ein Softwareinterrupt ausgelöst (x_tsk_switch: siehe Flug­ diagramm, Fig. 5a). Das Programm springt anschließend in den Scheduler hinein (Label "mic_ch") und startet die Task (Flußdiagramm, Fig. 5a und Fig. 2). Ansonsten geht die x_svc_done-Routine (über einen kurzen Weg) zur SVC-Aufrufstelle zurück (Ende). Das SVC-Unterprogramm beendet sich dabei und die Task A darf jetzt ihre Bear­ beitung fortsetzen.
• 4. Hat die Semaphorvariable ihre Grenze erreicht, so wird die Task A mittels eines Flags als "wartend" markiert. Der folgender Aufruf "tsk-switch" bewirkt einen Sprung in den Scheduler. Der Scheduler sucht Arbeit (d. h. eine Task zum Starten/Fortsetzen) aus der Menge der READY- Tasks (siehe MICROS-Kern-Flußdiagramm Fig. 2). Da die Task A (wie jede andere Task) das READY-Zustand seit ihrem letzten Start/Fortsetzungsvorgang verlassen hat, wird sie vom Scheduler nicht gefunden. Der Scheduler setzt daher die Task A nicht fort. Die Task A bleibt somit blockiert.
• 5. Eine andere Task (im Zukunft als "Task B bezeichnet") ruft die SVC "SEMAPHOR ZURÜCKSETZEN" auf.
• 6. Als erstes wird das Flag "svc-active" gesetzt (Schutz gegen Unterbrechung von Tasks einer höhere Priorität: siehe Flußdiagramm, Fig. 10).
• 7. Die Semaphorvariable ist nicht 0 (NULL), denn sie wurde bereits inkrementiert. Der Aufruf von Task B bewirkt daher eine Dekrementierung der Semaphorvariable. An­ genommen, die Variable erreicht jetzt den Wert 0, so erfolgt bei der weitere SVC-Bearbeitung ein "task-swit­ ch" (Eintritt in Scheduler über Softwareinterrupt). Als Versorgung der Nahtstelle (vor dem Interrupt) wer­ den alle (auf diesem Semaphor) wartende Tasks ein­ schließlich die SVC-aufrufende-Task eingegeben. Die Tasks A und B sind somit dabei; beide werden daher im "READY-Zustand" gesetzt (siehe Flußdiagramm Fig. 5a).
• 8. Der Scheduler sucht Arbeit (d. h. eine Task zum -Star­ ten/Fortsetzen) in der Menge der READY-Tasks (siehe MICROS-Kern-Flußdiagramm Fig. 2). Die Tasks A und B sind jetzt "READY" und werden, entsprechend ihre Priorität, vom Scheduler wieder "ACTIVE" gesetzt (Task-Fort­ setzung).

Kapitel 3: Schnittstellenbeschreibung

1. Schnittstelle zw. SVCs und Kern

1.1 Datenschnittstelle

1.2 Aufrufe 1.2.1 Task-Umschaltung (tsk-switch)

Aufruf: erfolgt vom SVC aus, über Software-Interrupt.
Beisp.-Aufruf (PL/M): cause$nterrupt (TSK_SWITCH_VEC);
Funktion: Anhalten/Starten/Fortsetzen von Tasks.

Über SW-Interrupt (Vektor TSK_SWITCH_VEC) kann der SVC-Programmierer, je nach Versorgung der Variable "rdy-req-mask", einen Task (über den Scheduler) an­ halten, starten oder fortsetzen (siehe Flußdiagramm, Fig. 5a).

Versorgung

rdy-req-mask = 0: Active Task anhalten (der Wert 0 braucht nicht extra zugewiesen werden).
rdy-req-mask: (bit x) gesetzt ⇒ Task × Start oder fortsetzen. Hier können auch mehrere Bits auf einmal gesetzt werden.

Bei dem Aufruf wird die Variable "svc-active" vom Kern auf "FALSE" gesetzt (d. h. der SVC-Programmierer braucht die Variable nicht zurücksetzen).

1.2.2 SVC-Abschluß (x_svc_done)

Um die Bearbeitung einer SVC abzuschließen, wird der Aufruf x_svc_done verwendet (siehe Flußdiagramm, Fig. 5b).
Aufruf: erfolgt vom SVC aus, über "far call".
Beispiel-Aufruf (PL/M) : call x_svc_done;
Funktion: Eintritt in Scheduler falls erforderlich.

Nachdem der Flag "svc-active" gesetzt ist, wird die Ausführung einer Anforderung "Task-Start per Inter­ rupt" (siehe Glossar) bis auf Beendigung der SVC- Bearbeitung verschoben.

Bei dem Aufruf der Procedure "x_svc_done" wird eine interne Kern-Variable abgefragt, ob während der SVC- Bearbeitung eine Start-Anforderung an einer Task mit höherer Priorität vorgekommen ist. Ist es der Fall, erfolgt ein Task-switch im Kern: die SVC-Aufrufende- Task wird "ready" gesetzt und die hochpriore Task wird dabei gestartet.

Das Flag "svc-active" wird dabei zurückgesetzt (Wert = "FALSE"). Das Zurücksetzen des Flages bleibt daher dem SVC-Programmierer erspart.

Der Aufruf ist nicht nötig, wenn:

• - Der SVC über Aufruf "tsk-switch" (siehe oben) sich beendet, denn in der Bearbeitung des SW-Interruptes ist die Funktionalität von x_svc_done bereits be­ inhaltet.
• - Der Variable "svc-active" noch nicht den Wert "TRUE" zugewiesen wurde.
  Die "TRUE-Zueisung" kann z. B. erst nach Gültig­ keit-Prüfung der SVC-Parameter erfolgen, gerade vor dem Zugriff auf MICROS-Daten. Somit kann SVC-Lauf­ zeit gespart werden.

Versorgung keine.

1.2.3 Systemtaktverarbeitung (x_pit_plm)

Die Systemtaktverarbeitung beinhaltet:

• - Interne-Zeit-Verarbeitung (Uhr/Kalender).
• - Task nach Ablauf einer Zeit (PAUSE) fortsetzen.

Aufruf: erfolgt vom MICROS-Kern aus, über "far call"

Aufrufumgebung

Aus programmtechnischen Gründen ist der Zeitgeberprolog (für den Systemtakt) im Kern codemäßig plaziert. Nach dem Retten der Prozessorregister, ruft der Prolog die PL/M-Funktions­ procedure x_pit_plm auf. Ist der Procedure-Rückgabewert ungleich 0, so springt das Programm zum Label x_deblock (siehe unten und Kern-Flußdiagramm, Anhang A Fig. 6).

Funktion

Der MICROS-Millisekundenzähler für die Zeitdienste wird hochgetaktet. Ferner wird die Liste der pausie­ renden Tasks bearbeitet. Wird festgestellt, daß eine (oder mehrere) Tasks ihre PAUSE beenden sollen (d. h. Task-Fortsetzen), so erfolgt über den Procedure-Rückga­ bewert die Identitätsangabe der betroffene(n) Task(s). Rückgabewert = 0 bedeutet keine.
Versorgung: keine.
Rückgabewert: WORD-Variable (Bit-Maske) wobei:
(Bit x = 1) ⇒ (Task-ID = x soll fortgesetzt werden).

2. Schnittstelle zw. Treiber und Kern 2.1 Datenschnittstelle

keine.

2.2 Aufrufe 2.1 Ende einer I/O-Operation (x_iodone):

Aufruf: erfolgt vom Treiber-Interrupt-Teil über "far jmp" (I oder DI-Zustand).

Aufrufumgebung

Die Bearbeitung des Treiberinterruptes erfolgt grundsätzlich in der Treiber-Interrupt-Serverroutine. Die Serverroutine ist in einer höherer Programmierspra­ che implementiert und wird im Rahmen des Treiber­ prologes aufgerufen. Nach Rückkehr aus der Server­ routine wird über die UCB-Schnittstelle abgefragt, ob die E-/A-Operation beendet ist oder nicht. Wenn ja, springt der Prolog zum Label x_iodone (siehe Flußdiagramm, Fig. 6).
Beispiel-Aufruf (ASM86): jmp x_iodone.
Funktion: Eingabe-/Ausgabe-Operation beenden.
Versorgung: Prozessorregister AX (16-Bit-Maske)
(Bit x = 1) ⇒ (Task-ID = x soll fortgesetzt werden).

2.2.2 Task-Start per unerwarteten Interrupt (x_unsol)

Aufruf: erfolgt vom Treiber-Interrupt-Teil über "far jmp" (I oder DI-Zustand).

Aufrufumgebung

Die Aufrufumgebung ist dieselbe wie bei x_iodone siehe 2.2.1). Nach Rückkehr aus der Serverroutine (Zeichenempfangsroutine in dem Fall) wird es über die UCB-Schnittstelle abgefragt, ob eine Task zu starten ist (Task-Start per unerwarteten Interrupt, siehe Glossar). Wenn ja, springt der Treiber-Prolog zum Label x_unsol (siehe Flußdiagramm, Fig. 6).
Beispiel-Aufruf (ASM86): jmp x_unsol.
Funktion: Task starten (falls sie "dormant" ist).
Versorgung: Prozessorregister AX (16-Bit-Maske)
(Bit x = 1) ⇒ (Task-ID = x soll gestartet werden).

3. Schnittstelle zw. Tasks und Kern 3.1 Datenschnittstelle

keine.

3.2 Aufrufe 3.2.1 Task beenden (ENDT)

Der Betriebssystemdienst "Task beenden" (ENDT) ist die einzige SVC, die im MICROS-Kern Codiert ist.
Aufruf: erfolgt aus Taskebene über "f ar call".
Beispiel-Aufruf (PL/M): call endt;
Funktion: Task beenden.

Die Task/-Codesegment/-Befehlszähler/-Flags werden im Stack wieder initialisiert (d. h. für den nächsten Task-Start vorbereitet). Ferner wird untersucht, ob Startanforderungen für die Task anstehen. Wenn ja, wird die Task in "READY-Zustand" versetzt. Task­ startparameter (wenn vorhanden) werden vom Parame­ terpuffer in dem Task-Stack transferiert (siehe Flußdiagramm, Fig. 4).
Versorgung: keine.

Anhang A: GLOSSAR A-Zustand

Siehe Betriebssystemzustände.

Betriebssystemzustände

MICROS unterscheidet 6 mögliche Betriebszustände. Die Zustände schließen sich gegenseitig aus und sind mit den Prozessoraktivitäten verbunden:

• - A-Zustand (A = Applikation): Der Prozessor bearbeitet Task-Code. Sämtlichen Interrupts sind (vor­ aussichtlich) freigegeben. Nur in diesem Zustand sind Betriebssystemaufrufe (SVCs) zulässig.
• - DI-Zustand (DI = Direkter-Interrupt): Diese Bedingung entspricht der Prozessor-Zustand unmittelbar nach Einschlagen eines Interrupts. Sämtliche Interrupts sind blockiert.
• - I-Zustand (I = Interrupt): In diesem Zustand sind nur die Interrupts blockiert, die die gleiche oder niedrigere Priorität besitzen, als der gerade bearbeitete Interrupt.
• - S-Zustand: (S = System): Der Prozessor bearbeitet ent­ weder MICROS-Kern-Code oder Code innerhalb eines SVCs unter der Bedingung: "Flag svc- active = TRUE". Bei der SVC-Bearbeitung sind (mit seltenen Ausnahmen) alle Interrupts freigegeben. Bei der Bearbeitung im Kern, sind sie meistens gesperrt.
• - Initialisierungszustand: Dieser Zustand findet nur bei der Initialisierung von MICROS statt. Um die Konsistenz der Daten zu bewahren, werden dabei sämtlichen Interrupts gesperrt.
• - IDLE-Zustand: Wenn keine der vorherigen Zustände zu­ trifft, bearbeitet der Prozessor die so­ genannte Untätigkeitsschleife (im Kern). Die Interrupts sind alle freigegeben.

BIOS

Das BIOS (Basic Input Output System) ist der hardwareab­ hängige Teil eines Betriebssystems. Um den Rest der Be­ triebssystemsoftware vollkommen hardwareunabhängig zu gestalten, müssen sämtlichen Unterprogramme für direkte Hardware-Zugriffe in einer Extra-Datei (BIOS) verlagert werden. Beispiel davon sind die Routine- für die Parame­ trierung und Reset der Interruptcontroller, Zeitgeber- Initialisierung usw.).

DI-Zustand

Siehe Betriebssystemzustände.

E/A-Operation

Unter E/A-Operation (E: Eingabe/A: Ausgabe) ist der Verkehr mit einem Peripheriegerät über Softwaretreiber gemeint (siehe Softwaretreiber).

Epilog

Siehe "Prolog".

Exception-Händler

Der Exceptionshändler dient zu einer sinnvollen Reaktion der Software, wobei Programmlaufbesonderheiten (exceptions). Beispiele davon sind:

• - Nicht interpretierbarer Befehl.
• - Quittungsverzug beim Zugriff auf einer Speicherzelle oder IO-Port der physikalisch nicht adressierbar ist (z. B. weil der entsprechende RAM- oder EPROM-Bereich nicht bestückt ist).
• - Fehler bei dem Arithmetik-Prozessor, wenn die Operanden unzulässig sind (z. B. Division durch Null).

Die Fehlerbehandlung erfolgt jeweils über Interruptrou­ tinen (Exceptionshändler).

I-Zustand, Idle-Zustand, Initialisierungszustand

Siehe Betriebssystemzustände.

Prolog

Unter dem Name Prolog ist eine Befehlssequenz gemeint, die nach einem Interrupt, sämtliche Prozessor-Register ret­ tet. Das Retten der Register ist notwendig, damit daß un­ terbrochene Programm nachher (ohne Datenverluste) die Bearbeitung fortsetzen kann. Auf der Ebene der Sprache Assembler-86 lautet die Syntax der Befehlssequenz "push ax, push bx, usw.". Das Gegenstück am Ende der Interruptbe­ arbeitung wird in diesem Text als "Epilog" bezeichnet (. . .pop bx, Pop ax, iret).

Scheduler

Der Scheduler teilt den Prozessor der Task zu, die die höchste Priorität aus der Menge der ready-Tasks besitzt (siehe Task-Zustände).

Softwaretreiber

Ein Softwaretreiber ist ein Programm, mit dem eine Task über eine komfortable Aufrufoberfläche koordinierte Peri­ pheriegerät-Zugriffe durchführen kann. Zum Beispiel
Treiber: Consoltreiber
Peripheriegerät: Monitor-Bildschirm
Zugriff: Ausgabe von einem ASCII-String.
Aufrufeingabeparameter (Oberfläche ): String-Adresse + Anzahl der Zeichen.

Die Koordinierung besteht darin, daß mehrere Tasks "gleichzeitig" ihre Ausgabeanforderung stellen können, ohne die Funktionalität dabei zu beeinträchtigen. Jede Task wird in Warte-Zustand versetzt, bis die Ausgabe abgeschlossen ist.

SVC

Bei der Anforderung von Systemdiensten bedienen sich die Tasks der sog. Systemaufrufe (in englisch "supervisor call"; abgekürzt: SVC). SVCs sind bei MICROS als Unterpro­ gramm der aufrufenden Task konzipiert.

S-Zustand

Siehe Betriebssystemzustände.

Task

Eine Task ist eine Programmbefehlssequenz, die einen Teil einer Applikation implementiert, und von MICROS verwaltet wird. MICROS kann maximal 16 Tasks verwalten.

Unter Verwaltung ist die Koordinierung, Synchronisation und Intertaskkommunikation zu verstehen.

Die Aufteilung einer Applikation in Tasks kann sich nach verschiedenen Kriterien richten. Folgende Gesichtspunkte sind (allgemein) zu berücksichtigen:

Als einzelne Tasks müssen implementiert werden

• - Prozesse die parallel ablaufen müssen oder können.
• - Prozesse mit wechselnde Zeitverhalten.
• - Prozesse, die während der Ausführung von unterschied­ licher Wichtigkeit (Priorität) sind.

Andere Faktoren, die die Aufteilung einer Applikation in Tasks beeinflussen, sind Programm-Modularität, Wartungs-/ Änderungsfreundlichkeit und Arbeitsaufteilung bei der Programmerstellung.

Task-Start-SVC

Der Task-Start-SVC ermöglicht das Starten einer Task per Programm (d. h. durch Aufruf aus einen anderen Task) unter der Annahme, daß die Zieltask "dormant" ist (siehe Task- Zustände).

Task-Start per Interrupt

Sehr wichtig in der Prozeßautomatisierung ist die Möglich­ keit durch einen Impuls aus der Peripherie (Interrupt) eine Task zu starten. Das Betriebssystem startet die Task unmittelbar nach dem Interrupt, wenn die Priorität der Zieltask höher ist als die Priorität des unterbrochenen Prozesses.

Task-Start per unerwarteten Interrupt

Falls eine Eingabe-Peripheriegerät, z. B. ein Datensichtge­ rät, einen Interrupt auslöst und momentan für dieses Gerät keine Eingabeanforderung einer Task ansteht, spricht man von einem unerwarteten Interrupt. Diese Situation findet statt, wenn z. B. der Operator die "ESCAPE-Taste" am Daten­ sichtgerät betätigt.

Task-Zustände

MICROS erkennt 4 Taskzustände nämlich: Dormant, Ready, active, blocked. Die Zustände werden wie folgt definiert:

Dormant ⇒ Die Task ruht und darf jederzeit ge­ startet werden.
Ready ⇒ Eine Task-Start/Fortsetzungsanforde­ rung steht an. Die Task wartet nur auf die Prozessorzuteilung durch den Schedu­ ler.
Active ⇒ Der Task wurde dem Prozessor bereits zugeteilt.
Blocked ⇒ Die Task wartet auf ein internes Koordi­ nierungsereignis (z. B. Abschluß einer IO-Operation), um "ready" zu werden.

Die obengenannten Zustände schliefen sich gegenseitig aus.

Der Übergang von einem Zustand zu dem anderen erfolgt nach den Regeln:

dormant → ready
ready → active
active → blocked
active → dormant
blocked → ready.

Zeitgeber

Auf die meisten Rechner befindet sich ein Systemtaktgene­ rator (Zeitgeber) deren Taktperiode einstellbar ist. Der Zeitgeber liefert nach Ablauf einer Periode einen Inter­ rupt. Der Interrupt dient dazu sämtliche zeitbezogene Betriebssystemfunktionen zu bearbeiten (Pausen, Datum/Uhr­ zeit usw.).

Claims (1)

1. Verfahren zum sicheren Betrieb eines Prozeßrechners, bei dem ein Betriebssystem mit Multitaskingfähigkeit verwendet wird, mit einer vorgegebenen, begrenzten Zahl von Tasks, mit einem Betriebssystemkern zum Starten, Beenden, Anhalten und Fortsetzen einer Task und einer Schnittstelle zwischen Betriebssystemdiensten und Betriebssystemkern, die eine freie Programmierung der Betriebssystemdienste zuläßt, gekennzeichnet durch eine Koordinierung der Tasks über mit Bitmasken abgefragte Flags, bei der jeweils jeder Bitposition eine Task zugeordnet ist.