DE69622832T2

DE69622832T2 - Vorrichtung und verfahren für kooperative unterbrechungen in einer preemptiven prozessablauffolgeplanungsumgebung

Info

Publication number: DE69622832T2
Application number: DE69622832T
Authority: DE
Inventors: B Jacklin; J Larocci; L Robbin; T Williams
Original assignee: Apple Computer Inc
Current assignee: Apple Inc
Priority date: 1995-05-05
Filing date: 1996-05-03
Publication date: 2003-04-10
Anticipated expiration: 2016-05-04
Also published as: DE69622832D1; WO1996035167A1; US5911065A; EP0783734A1; AU5726596A; EP0783734B1

Description

Diese Erfindung betrifft im allgemeinen Computerbetriebssysteme.
Entwickler von Betriebssystemen bauen eine große Vielfalt von Funktionen in deren Entwicklungen ein. Die Prozeßablaufsteuerung (process scheduling) ist eine solche Betriebssystemfunktion. Betriebssysteme definieren eine Prozeßablaufumgebung. Beispiele von Prozeßablaufumgebungen umfassen eine kooperative Ablaufsteuerungsumgebung und eine preemptive bzw. unterbrechende Taskablaufsteuerungsumgebung.
In einer kooperativen Ablaufsteuerungsumgebung werden Softwareapplikationen kooperativ verwaltet. Das heißt, wenn eine erste kooperative Applikation mit der Ausführung beginnt, kann keine kooperative Applikation ausgeführt werden, bis entweder: (1) die erste kooperative Applikation explizit die Steuerung der zentralen Recheneinheit (CPU) abgibt; oder (2) eine kooperative Unterbrechung auftritt. Eine Applikation ist eine Prozedur, zum Beispiel ein Programm, welches entwickelt ist, um in einer kooperativen Ablaufsteuerungsumgebung abzulaufen, während eine Task eine Prozedur ist, die ausgelegt ist, um in jeder anderen Betriebssystemumgebung, zum Beispiel der unterbrechenden Taskablaufsteuerungsumgebung, betrieben zu werden.
Während der Ausführung können Applikationen asynchrone Operationen auslösen, d. h. Operationen, welche zu einem späteren Zeitpunkt beendet werden. Beispiele von asynchronen Operationen umfassen eine Eingabe/Ausgabe (I/O) Operation oder das Setzen von einem Timer. Wenn die asynchrone Operation beendet ist, beispielsweise ist die I/O-Übertragung beendet oder die spezifizierte Zeit abgelaufen, wird eine kooperative Unterbrechung erzeugt. Eine Komplettierungsinformation wird an die Unterbrechungssteuerungsroutine übersandt, welche der Quellenapplikation zugeordnet ist, d. h. der Applikation, welche die asynchrone Operation auslöst. Die Komplettierungsinformation identifiziert die zugehörige asynchrone Anfrage. Der geeignete Unterbrechungs-Handler in der Quellenapplikation unterbricht die laufende kooperative Applikation (current cooperative application (CCA)), d. h. die Applikation, welche gegenwärtig ausgeführt wird. Die laufende kooperative Applikation wird unterbrochen, selbst wenn sie nicht die Quellenapplikation ist. In Reaktion auf die Unterbrechung führt die CPU die Unterbrechungskomplettierungsroutine aus.
Nachdem die Ausführung der Komplettierungsroutine beendet ist, bestimmt das Betriebssystem, ob irgendwelche andere kooperative Unterbrechungen anstehen. Falls zusätzliche kooperative Unterbrechungen anstehen, werden diese Unterbrechungen durchgeführt, d. h. die geeignete Komplettierungsroutine wird ausgeführt. Wenn keine kooperative Unterbrechungen mehr anstehen, wird die Ausführung der laufenden kooperativen Applikation fortgeführt.
Bei der kooperativen Ablaufsteuerungsumgebung kann eine Applikation sicherstellen daß sie nicht unterbrochen wird, indem alle kooperativen Unterbrechungen gesperrt werden. Eine Applikation kann die kooperativen Unterbrechungen sperren, falls sie eine Funktion ausführt, welche beispielsweise beendet werden muß, bevor sie in geeigneter Weise die asynchrone Operation bedienen kann. Um dies auszuführen, haben alle Applikationen in der kooperativen Ablaufsteuerungsumgebung die Fähigkeit, alle kooperativen Unterbrechungen zu sperren.
Ein Beispiel einer kooperativen Ablaufsteuerungsumgebung ist ein Apple System 7 Betriebssystem für den Macintosh Computer, erhältlich von Apple Computer, Inc., Cupertino, CA.
Eine zweite Art von Ablaufsteuerungsumgebung ist eine unterbrechende Taskablaufsteuerungsumgebung. Beispiele einer unterbrechenden Taskablaufsteuerungsumgebung sind das UNIX System V, entwickelt durch AT&T Beil Laboratories, und Windows NT, entwickelt durch Microsoft Corporation. Bei einer unterbrechenden Taskablaufsteuerungsumgebung steuert die Betriebssystemkerneinheit (operating system kernel), welche Task einen Zugriff zu der CPU hat. Das heißt, eine Task, welche in einer unterbrechenden Taskablaufsteuerungsumgebung betrieben wird, kann durch die Betriebssystemkerneinheit ihres CPU- Zugriffes entledigt worden sein. Dies ist ein Unterschied zu der kooperativen Ablaufsteuerungsumgebung, bei welcher der CPU-Zugriff durch die Applikationen gesteuert wird.
Ein Merkmal einer unterbrechenden Ablaufsteuerungsumgebung besteht darin, daß, wenn eine erste Task aus irgendeinem Grund nicht durchgeführt werden kann, beispielsweise wenn ein Seitenfehler auftritt, die Kerneinheit die Ausführung der ersten Task unterbricht, und eine zweite Task kann mit der Ausführung beginnen. Im Gegensatz dazu, wenn eine Applikation welche in einer kooperativen Ablaufsteuerungsumgebung ausgeführt wird, in ähnlicher Weise nicht ablaufen kann, kann keine andere Applikation ausgeführt werden, weil die laufende kooperative Applikation nicht gezwungen werden kann, die Steuerung der CPU abzugeben.
Ein weiteres Merkmal von unterbrechenden Taskablaufsteuerungsumgebungen besteht: darin, daß Nicht-Betriebssystemtasks und -applikationen im allgemeinen nicht in einem bevorzugten Modus oder auf einer Hardwareunterbrechungsebene ausgeführt werden. Im Gegensatz dazu sind kooperative Applikationen häufig so ausgebildet, daß sie in einem bevorzugten Modus oder auf einer Hardwareunterbrechungsebene ausgeführt werden. Zusätzlich sind kooperative Applikationen häufig basierend auf der Unterbrechungssemantik von der kooperativen Ablaufsteuerungsumgebung ausgebildet und ihr geeigneter Betrieb beruht darauf. Eine solche Unterbrechungssemantik umfaßt eine Beschränkung derart, daß keine Applikation ausgeführt werden kann, während die Unterbrechungskomplettierungsroutine ausgeführt wird, und eine einzelne Operation Unterbrechungen für alle anderen sperren kann. Diese kooperative Unterbrechungssemantik findet sich nicht in konventionellem unterbrechenden Taskablaufsteuerungsumgebungen.
Die vorstehende Diskussion zeigt einige der Schwierigkeiten im Zusammenhang mit dem Versuch der Ausführung von kooperativen Applikationen in einer unterbrechenden Taskablaufsteuerungsumgebung. Das Apple A/UX Unix Betriebssystem, entwickelt und kommerziell vertrieben durch Apple Computer, Inc., Cupertino, CA, zielte darauf ab, eine Ausführung von kooperativen Applikationen in einer unterbrechenden Taskablaufsteuerungsumgebung zur ermöglichen. Jedoch behandelt A/UX nicht die oben erwähnten Kompatibilitätsprobleme. Insbesondere behält das A/UX System nicht die Zeitfolge, d. h. die Abfolge, bei, in welcher die kooperativen Unterbrechungen an die unterschiedlichen Applikationen gesandt werden.
Das A/UX System führt jeden Unterbrechungs-Handler über eine Unix "Signal" Operation aus, welche an die Quellenapplikation gerichtet ist. Danach führt die Quellenapplikation die Unterbrechungskomplettierungsroutine aus. Dieses Design benötigt einen komplexen Applikations/Task-Planer, welcher einen häufigen Zugriff an die Betriebssystemkerneinheit erforderlich macht, wodurch die Leistungsfähigkeit des Betriebssystems verringert wird.
Wenn ein Unterbrechungssignal an eine Applikation in einem A/UX System gesendet wird, muß die Kerneinheit die Ausführung von Unterbrechungen in allen anderen Applikationen verhindern. Daher beeinflußt die Ausführung einer einzigen Unterbrechung die Ablaufsteuerung von allen anderen Applikationen. Eine erneute Planung der Ablaufsteuerung von all den Applikationen vermindert weiter die Leistungsfähigkeit des A/UX Betriebssystems.
Ein weiteres Kompatibilitätsproblem tritt auf, wenn eine Applikation in einer Maschinensprache einer Befehlssatzarchitektur geschrieben ist, welche sich von der Maschinensprache einer Befehlssatzstruktur der unterbrechenden Taskablaufsteuerungsumgebung unterscheidet. Das A/UX System behandelt dieses Problem ist.
Es besteht Bedarf nach einem System und einem Verfahren zum: (1) Ausführen von Applikationen, welche für eine kooperativen Ablaufsteuerungsumgebung geschrieben sind, in einer unterbrechenden Taskablaufsteuerungsumgebung; (2) Sicherstellen, daß die zeitliche Abfolge für die Ausgabe von Unterbrechungen in der unterbrechenden Taskablaufsteuerungsumgebung nicht veränder wird; (3) effizienten Sperren von allen kooperativen Unterbrechungen in Reaktion auf eine Anfrage von einer Applikation; (4) effizienten Ablaufsteuern aller kooperativen Unterbrechungen; und (5) effizienten Ausführen von emulierten Befehlen, während die Integrität, d. h. die Unteilbarkeit (Atomizität), der emulierten Befehle beibehalten wird.
Die vorstehenden Ziele (1) und (2) werden durch das Verfahren des unabhängigen Anspruches 1 und das System des unabhängigen Anspruches 11 erreicht. Die anderen Ziele sowie weitere vorteilhafte Merkmale, Aspekte und Details der Erfindung ergeben sich ersichtlich aus den abhängigen Ansprüchen, der Beschreibung und der Zeichnung.
Das System und Verfahren der vorliegenden Erfindung ist ein Betriebssystem, welche: Applikationen, welche für eine Ausführung in einer kooperativen Ablaufsteuerungsumgebung geschrieben sind, in einer unterbrechenden Taskablaufsteuerungsumgebung ausführt; sicherstellt, daß die zeitliche Abfolge für die Ausgabe von Unterbrechungen in der unterbrechenden Taskablaufsteuerungsumgebung nicht verändert wird; alle kooperativen Unterbrechungen in Reaktion auf eine Anfrage von einer Applikation effizient sperrt; den Ablauf aller kooperativen Unterbrechungen effizient steuert; und emulierte Befehle effizient ausführt, wobei die Integrität der emulierten Befehle beibehalten wird.

KURZBESCHREIBUNG DER ZEICHNUNG

Fig. 1 ist eine Darstellung einer Computerumgebung, welche ein bevorzugtes Ausführungsbeispiel der vorliegenden Erfindung aufweist;
Fig. 2 ist eine detailliertere Darstellung des Speichermoduls eines bevorzugten Ausführungsbeispiels der vorliegenden Erfindung;
Fig. 3 ist ein Flußdiagramm, welches das Verfahren zum Ausgeben einer kooperativen Unterbrechung an eine Applikation und Ausführen einer kooperativen Unterbrechung entsprechend einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung beschreibt;
Fig. 4 ist ein Flußdiagramm, welches das Verfahren zum Sperren aller kooperativen Unterbrechungen nach einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung beschreibt;
Fig. 5 ist ein Flußdiagramm, welches das Verfahren zum Freigeben von kooperativen Unterbrechungen nach einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung beschreibt;
Fig. 6 ist ein Flußdiagramm, welches das Verfahren zum Setzen eines Spezialkontextmodus nach einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung beschreibt; und
Fig. 7 ist ein Flußdiagramm, welches ein Verfahren zum Verlassen eines Spezialkontextmodus nach einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung beschreibt.

DETAILLIERTE BESCHREIBUNG BEVORZUGTER AUSFÜHRUNGSBEISPIELE

Ein bevorzugtes Ausführungsbeispiel der vorliegenden Erfindung wird nunmehr mit Bezugnahme auf die Figuren beschrieben, bei welchen gleiche Bezugsziffern gleiche oder funktionell ähnliche Elemente bezeichnen. Auch entspricht in den Figuren die äußerste linke Ziffer von jedem Bezugszeichen derjenigen Figur, in welcher das Bezugszeichen erstmalig verwendet wurde.
Fig. 1 veranschaulicht eine Computerumgebung, welche ein bevorzugtes Ausführungsbeispiel der vorliegenden Erfindung umfaßt. Das Betriebssystem befindet sich in einer Computerplattform 100, zum Beispiel ein Apple Power Macintosh vom Model 6100/60, welcher kommerziell erhältlich ist bei Apple Computer, Inc., Cupertino, CA. Die Computerplattform 100 besteht aus Hardwareelementen 102 und ausgewählten Programmen in einem Speicher 104 zum Betreiben des dargestellten Systems. Vorzugsweise umfassen die Hardwareelemente 102 konventionelle Komponenten wie etwa ein Speicherelement 106, zum Beispiel einen Festplattenspeicher, eine zentrale Recheneinheit (CPU) 108, zum Beispiel einen Motorola PowerPC 601, welcher kommerziell von Motorola, Inc., erhältlich ist, und eine Eingabe/Ausgabe (I/O) Schnittstelle 110. Die Programme im Speicher 104 umfassen ein Betriebssystem 112 sowie Applikationen und Tasks 114. Wie vorstehend beschrieben wurde, ist eine Applikation eine Prozedur, welche ausgelegt ist, um in einer kooperativen Ablaufsteuerungsumgebung betrieben zu werden, während eine Task eine Prozedur ist, welche ausgelegt ist, um in jeder anderen Betriebssystemumgebung abzulaufen.
Fig. 2 zeigt das Speichermodul 104 eines bevorzugten Ausführungsbeispiels der vorliegenden Erfindung. Das Betriebssystem 102 des bevorzugten Ausführungsbeispiels stellt eine unterbrechende Taskablaufsteuerungsumgebung bereit, wie sie vorstehend beschrieben wurde, und es umfaßt zwei Abschnitte. Der privilegierte Betriebsmodusabschnittsmodus 4 ist der Abschnitt des Betriebssystems, welcher in einem privilegierten Modus arbeitet. Daten, welche im privilegierten Modus gespeichert werden, können nur durch einen Code 216 in die Kerneinheit (kernel) oder andere Elemente geschrieben werden, welche sich auch in einem privilegiertem Modus befinden. Jedoch können Daten, welche im privilegierten Modus gespeichert sind, durch jedes Programm oder jedes Element gelesen werden. Die Operationen, welche durch die Betriebssystemkerneinheit 218 ausgeführt werden, und damit der Kerncode 216, werden nachfolgend dargelegt mit Bezugnahme auf die Fig. 3-7. Daten, welche im privilegiertem Modus gespeichert sind, umfassen Kerndaten 208, die Halteschlange (holds queue) 210, die Anzeigeschlangen (indicates queues) 212, 214 und das Flag 222 für eine anstehende kooperative Unterbrechung (cooperative interrupt pending flag (CIPF)). In Fig. 2 sind alle Elemente oberhalb der gestrichelten Linie 202 in einem privilegierten Modus, während alle Elemente unterhalb der gestrichelten Linie 202 sich in einem Benutzermodus befinden. Benutzermodusdaten können durch einen Prozeß geschrieben werden, welche sich entweder in einem Benutzermodus oder in einem privilegierten Modus befindet.
Die Betriebssystemkerneinheit 218 definiert und steuert die Ablaufsteuerungsumgebung des Computerssystems 100. Wie in näherem Detail unten diskutiert wird, stellt die Kerneinheit 218 der vorliegenden Erfindung eine unterbrechende Ablaufsteuerungsumgebung bereit und ermöglicht eine Ausführung von Applikationen, welche ausgebildet sind, um in einer kooperativen Ablaufsteuerungsumgebung abzulaufen. Eine detaillierte Diskussion der Kerneinheit 218 wird nunmehr durchgeführt.
Die Kerneinheit 218 der vorliegenden Erfindung steuert vorzugsweise einen Ablauf, in dem ein Warteschlangenmechanismus implementiert wird, welcher einen Basisabschnitt zur Verwendung durch Tasks und eine Gruppe von Erweiterungen umfaßt, welche die Kerneinheit für den Ablauf von kooperativen Applikationen verwendet. Der Warteschlangengrundmechanismus umfaßt drei Operationen, nämlich Bilde-eine-Kernwarteschlange (create-a-kernel-queue), Melde-eine-Kernwarteschlange (notify-a-kernel-queue) und Warte-auf-eine-Kernwarteschlange (wait-on-a-kernel-queue). Die Bilde-eine-Kernwarteschlange Operation schickt eine Kennung zurück, welche verwendet wird, um die Kernwarteschlange zur Verwendung in der Melde-eine- Kernwarteschlange Operation und in der Warte-auf-eine- Kernwarteschlange Operation identifiziert. Die Melde-eine- Kernwarteschlange Operation speichert Daten in die Kernwarteschlange. Diese Daten werden Warteschlangeneintrag genannt. Die Warte-auf-eine-Kernwarteschlange Operation liest einen Warteschlangeneintrag von der Kernwarteschlange aus, vorzugsweise unter Verwendung einer "first-in-first-out" (FIFO) Auslesetechnik. Die Task, welche die Warte-auf-eine- Kernwarteschlange Operation ausführt, empfängt den Warteschlangeneintrag, welcher während einer vorausgehenden Melde- eine-Warteschlange Operation gespeichert wird. Falls keine Warteschlangeneinträge in der Warteschlange vorliegen, setzt die Kerneinheit die Ausführung der Task aus, welche die Warte-auf-eine-Kernwarteschlänge Operation ausführt, bis ein Warteschlangeneintrag in der Kernwarteschlange gespeichert ist, die gezeigt ist.
Die Kerneinheit 218 der vorliegenden Erfindung addiert vorzugsweise zwei zusätzliche Arten von Kernwarteschlangen. Die erste ist eine Anzeigeschlange 212, 214. Jede Anzeigeschlange 212, 214 ist einer Applikation 236, 238 zugeordnet, welche im Speicher 104 gespeichert ist. Beispielsweise ist die Anzeigeschlange A 212 einer Applikation A 236 und die Anzeigeschlange B 214 einer Applikation B 238 zugeordnet. Jede Anzeigeschlange 212, 214 speichert Daten für ihre zugeordnete Applikation und wird durch die Kerneinheit 218 und den Prozessserver 224 verwendet, wie nachstehend diskutiert wird, um die kooperativen Applikationen auszuführen. Die Kerneinheit 218 verfolgt bzw. ermittelt die Identität der letzten Applikation, welche erfolgreich einen Warteschlangeneintrag von ihrer zugeordneten Anzeigeschlange 212, 214 ausgelesen hat. Diese Applikation wird als laufende kooperative Applikation (current cooperative application (CCA)) bezeichnet.
Der zweite zusätzliche Typ von Kernwarteschlange ist die Halteschlange 210. Die Halteschlange 210 speichert Daten, welche die Speicheradresse der Komplettierungsroutine für eine kooperative Unterbrechung darstellen. Die Adresse von jeder Komplettierungsroutine wird in der Halteschlange gespeichert, bevor die Komplettierungsroutine durch den kooperativen Unterbrechungsserver (cooperative interrupt server (CIS)) 230, der nachfolgend diskutiert wird, ausgeführt wird. Die Funktionen, welche durch die Anzeigeschlangen 212, 214 und die Halteschlange 210 ausgeführt werden, werden nachfolgend mit Bezugnahme auf die Fig. 3-7 in näherem Detail diskutiert.
Das kooperative Unterbrechungs(warte)flag (CIPF) 222 ist ein Wort von einem Speicher, welches durch die Kerneinheit 218 gesetzt wurde, wenn wenigstens eine kooperative Unterbrechung ansteht bzw. in Warteposition ist. Die Kerneinheit 218 setzt das CIPF 222 zurück, wenn keine kooperative Unterbrechung ansteht. Das CIPF 222 befindet sich in dem privilegierten Betriebsmodusabschnitt 204 des Betriebssystems. Daher kann der Wert des CIPF durch alle Applikationen und Tasks gelesen werden, jedoch kann er nur durch die Kerneinheit 218 geschrieben werden. Das CIPF 222 wird nachfolgend mit Bezugnahme auf die Fig. 3-7 genauer diskutiert.
Der Abschnitt 206 des Betriebssystems, welcher in einem Benutzermodus arbeitet, enthält einen Systemcode. Einige Systemcodes werden als ein Ergebnis von einem ausdrücklichen Applikationsaufruf durchgeführt, zum Beispiel einem WaitNextEvent-Aufruf. Andere Systemcodes werden unabhängig von irgendeiner Applikation ausgeführt. Dieser Systemcode wird eine "Systemtask" genannt. Vorzugsweise enthält das Betriebssystem wenigstens zwei Systemtasks, den Prozeßserver (PS) 224 und den kooperativen Unterbrechungsserver (CIS) 230.
Ein anderes Beispiel einer Systemtask 232 ist ein Systemregister.
Der PS 224 ist vorzugsweise ein Softwaremodul, welches die nachfolgende Prozedur ausführt. Der PS 224 wählt zusammen mit der Kerneinheit 218 die laufende kooperative Applikation (CCA) aus und unterbricht den Betrieb von allen anderen kooperativen Applikationen. Der PS 224 wählt die CCA durch anfängliches Speichern einer Applikationsinformation in der Anzeigeschlange 212, 214, welche der einen der Applikationen 236, 238 zugeordnet ist. Um beispielsweise eine Applikation B 238 als die CCA für den PS 224 auszuwählen, speichert der PS 224 eine Information in der Anzeigeschlange B 214. Die Information, welche in der Anzeigeschlange B 214 gespeichert ist, bezieht sich auf den Prozeß, welchen die Applikation B 238 ausführen soll. Der PS 224 stellt sicher, daß nur eine Applikation, die CCA, Zugriff auf die CPU 108 hat, indem die Information in nur einer Anzeigeschlange gespeichert wird. Nachdem der PS 224 die Information in der Anzeigeschlange B 214 gespeichert hat, wird die zugehörige Applikation, d. h. die Applikation B 238, zu der CCA.
Der CIS 230 wird in Verbindung mit der Halteschlange 210 betrieben, um die Komplettierungsroutine (CR) von einer asynchronen Operation auszuführen, wie es nachfolgend diskutiert wird. Der CIS 230 wird unterbrochen, falls die Halteschlange 210 leer ist oder falls der kooperative Unterbrechungssperrzähler (cooperative interrupt disable count (CIDC)) 228 nicht gleich Null ist und eine CR wird nicht ausgeführt. Zusätzliche Operationen, welche durch den CIS 230 ausgeführt werden, werden nachfolgend mit Bezugnahme auf die Fig. 3-7 diskutiert.
Der CIDC 228 ist allgemein für die Kerneinheit 218, alle Applikationen 236, 238 und alle Tasks zugänglich. Vorzugsweise ist der CIDC 228 ein Teil des kooperativen Unterbrechungssperrwortes (cooperative interrupt disable word (CIDW)) 226.
Das CIDW 226 umfaßt den CIDC 228 und ein Spezialkontextflag (special context flag (SCF)) 227, welches vorzugsweise ein 1- Bit Flag ist. Das SCF 227 ist ein Bit, welches repräsentiert, ob die CCA in einem speziellen Kontextmodus betrieben wird. Das SCF 227 und der spezielle Kontextmodus werden in näherem Detail nachstehend diskutiert. Die Kerneinheit 218 setzt anfänglich den Wert des CIDC auf Null. Während die Tasks und Applikationen ausgeführt werden, und falls der Wert des CIDC 228 Null ist, erzeugt das Betriebssystem kooperative Unterbrechungen. Das heißt, kooperative Unterbrechungen werden aktiviert, d. h. CIS 230 kann die CR abarbeiten, deren Adresse sich in der Halteschlange 210 befindet. Falls der Wert des CIDC 228 positiv ist, wird sodann die kooperative Unterbrechungserzeugung gesperrt, d. h. Warteschlangeneinträge können in der Halteschlange 210 platziert werden, aber die Warteschlangeneinträge können nicht durch den CIS 230 ausgelesen werden. Der CIDC 228 stellt einen Zählmechanismus bereit, welcher ermöglicht, daß jede Applikation 236, 238 alle kooperativen Unterbrechungen sperrt. Der CIDC 228 zählt die Anzahl von Sperrbefehlen und die Anzahl von Freigabebefehlen, welche durch die Applikationen 236, 238 erzeugt werden. Kooperative Unterbrechungen werden nur aktiviert, wenn die Anzahl von Freigabebefehlen gleich der Anzahl von Sperrbefehlen ist, d. h. wenn der CIDC gleich Null ist.
Die Spezialkontextmaske (special context mask (SCM)) 220 sind Daten, welche in dem Speicherabschnitt 104 gespeichert sind, beispielsweise in dem Betriebssystem 112. Die SCM 220 befindet in dem Benutzerbetriebsmodusabschnitt 206 des Betriebssystem 112. Die SCM 220 wird nachfolgend im näheren Detail beschrieben.
Der Applikationen/Tasks-Abschnitt 114 des Speichers 104 umfaßt vorzugsweise eine Kombination von kooperativen Applikationen 236, 238 und von Tasks 234. Beispiele von Tasks 234 umfassen einen File-Server und einen Datenbank-Server. Die Applikationen 236, 238 und die Tasks 234 arbeiten in dem Benutzermodus, wie vorstehend beschrieben.
Die Fig. 1 und 2 veranschaulichen das bevorzugte Ausführungsbeispiel des Systems nach der vorliegenden Erfindung. Die Fig. 3-7 veranschaulichen das bevorzugte Ausführungsbeispiel des Verfahrens nach der vorliegenden Erfindung. Wie vorstehend erläutert wurde, betrifft die vorliegende Erfindung ein Betriebssystem mit einer unterbrechenden Tasksablaufsteuerungsumgebung, welches ein System und ein Verfahren zum Ausführen von Applikationen umfaßt, welche für den Betrieb in einer kooperativen Ablaufsteuerungsumgebung ausgelegt sind. Um die kooperativen Applikationen 236, 238 in einer unterbrechenden Taskablaufsteuerungsumgebung in geeigneter Weise auszuführen, stellt das Betriebssystem 112 sicher, daß alle Applikationen kooperativ betrieben werden, indem gewährt wird, daß: (1) nur eine Applikation zu einem Zeitpunkt ausgeführt werden kann, wobei diese Applikation als die laufende kooperative Applikation (CCA) bezeichnet wird; (2) alle anderen Applikationen ausgesetzt werden, bis die CCA explizit die Steuerung der CPU abgegeben hat; (3) die Komplettierungsroutinen (CR), welche einem durch eine Applikation ausgelöstem asynchronen Ereignis zugeordnet sind, die Ausführung der CCA unterbrechen können; (4) keine Applikation ausgeführt werden kann, während die CR ausgeführt wird; (5) eine einzige Operation alle kooperativen Unterbrechungen sperren kann; und (6) die Abfolge der kooperativen Unterbrechungen unverändert bleibt, im Vergleich zu der Abfolge der kooperativen Unterbrechungen, wenn die. Applikationen in einer kooperativen Ablaufsteuerungsumgebung ausgeführt werden.
Fig. 3 ist ein Flußdiagramm, welches das Verfahren zum Ausgeben und Ausführen von einer kooperativen Unterbrechung an einer Applikation gemäß einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung beschreibt. Wenn eine Applikation A 236 die CCA ist, löst sie eine asynchrone Operation aus. Eine Applikation A gibt die Steuerung der CPU 108 ab und eine neue Applikation hat einen "exklusiven" Zugriff auf die CPU. Diese Applikation wird daher die neue CCA. Diese CCA hat einen "exklusiven" Zugriff zu der CPU nur in Bezug auf die anderen kooperativen Applikationen. Das heißt, nichtkooperative Prozeduren, zum Beispiel die Tasks 234, werden unterbrechend betrieben und können die CCA unterbrechen, selbst wenn die kooperativen Unterbrechungen gesperrt sind. Beispielsweise kann eine Task 234 die CCA unterbrechen, immer wenn die Kerneinheit 218 bestimmt, daß die Task nicht ausgesetzt wird und die Taskausführungspriorität die CCA Ausführungspriorität übertrifft.
Die Kerneinheit 218 empfängt 302 eine kooperative Unterbrechung für eine Applikation A 236. Die Kerneinheit 304 speichert die Adresse der Komplettierungsroutine (CR) in der Halteschlange 210. Die Komplettierungsroutine ist der asynchronen Operation zugeordnet, welche durch die Applikation A implementiert ist, während der Applikation A eine CCA war. Die Kerneinheit 218 prüft im Schritt 306 den Wert von CIDW 226. Wenn das CIDW 226 gleich Null ist, werden die kooperativen Unterbrechungen aktiviert und das SCF 227 zeigt an, daß die CCA nicht in einem Spezialkontextmodus betrieben wird, wie nachfolgend beschrieben wird. In diesem gegenwärtigen Beispiel wird die CCA nicht in einem Spezialkontextmodus betrieben, daher ist das SCF 227 beispielsweise Null.
Wenn das CIDW 226 nicht gleich Null ist, d. h. alle kooperativen Unterbrechungen gesperrt sind, führt die Kerneinheit 218 die Schritte aus, die in einer Subroutine "A" im Schritt 308 angegeben sind. In der Subroutine A im Schritt 308, setzt die Kerneinheit 218 das CIPF 222. Wenn CIPF 222 gesetzt ist, zum Beispiel auf einen Wert ungleich Null, zeigt das CIPF 222 an, daß eine kooperative Unterbrechung ansteht. Da das SCF 227 gleich Null ist, d. h. es ist nicht gesetzt im Schritt 322, kehrt die Subroutine A zurück im Schritt 326 und das Betriebssystem setzt die Ausführung derjenigen CCA, der Task oder der CR fort (Schritt 310), welche sie ausgeführt hatte, als die Kerneinheit die kooperative Unterbrechung im Schritt 302 erhielt.
Falls bestimmt im Schritt 306 wird, daß das CIDW 226 gleich Null ist, bestimmt die Kerneinheit 218 im Schritt 312, ob der CIS 230 gegenwärtig unterbrochen ist. Der CS 130 kann unterbrochen sein, wenn keine CR ausgeführt wird und: (1) die kooperativen Unterbrechungen gesperrt sind, d. h. CIDW 226 nicht gleich Null ist; oder (2) die Halteschlange 210 leer ist. Im Schritt 306 prüft die Kerneinheit 218, um festzustellen, ob die kooperativen Unterbrechungen gesperrt wurden. Daher findet der Schritt 312 nur statt, wenn die kooperativen Unterbrechungen aktiviert sind. Falls die Kerneinheit im Schritt 312 feststellt, daß der CIS 230 unterbrochen ist, dann waren vor der Ausführung von Schritt 304 alle anstehenden bzw. wartenden CRs ausgeführt, und die Halteschlange 210 war leer. Wenn der CIS 230 nicht unterbrochen ist, dann führt der CIS eine CR aus oder eine Task höherer Priorität wird ausgeführt. Daher ermöglicht die Kerneinheit 218, daß der Betrieb des Betriebssystem 112 fortgesetzt wird, wie es vorstehend unter Bezugnahme auf Schritt 310 beschrieben wurde. Wenn der CIS 230 unterbrochen wurde, nimmt die Kerneinheit 218 den Betrieb des CIS 230 wieder auf, d. h. er "weckt ihn auf", in Schritt 316. Die Kerneinheit 218 entfernt im Schritt 320 den Warteschlangeneintrag, d. h. die Adresse der CR, von der Halteschlange 210 und sendet sie zu dem CIS 230 und unterbricht sodann im Schritt 332 die CCA. Da lediglich eine Applikation zu einem Zeitpunkt ununterbrochen sein kann, d. h. die CCA, unterbricht ein Aussetzen der CCA effektiv alle Applikationen.
Danach führt der CIS 230 im Schritt 334 die CR aus. Es wichtig anzumerken, daß der CIS 230 die Ausführung der CR im Gegensatz zur Applikation steuert, welche die asynchrone Operation ausgelöst hat. Dies ist wichtig, weil es die globale Ordnung bzw. Abfolge der CR bewahrt. Da alle CRs durch eine einzige Task, d. h. den CIS 239 abgearbeitet werden, ordnet der CIS 230 die CR in der Halteschlange 210 in Reihe an, wodurch sichergestellt wird, daß die CR in der Reihenfolge abgearbeitet werden, in welcher die asynchronen Operationen vollendet werden, unabhängig von der Applikation, welche die asynchrone Operation ausgelöst hat. Im Gegensatz dazu wird in konventionellen Systemen, zum Beispiel dem A/UX System, welches vorstehend beschrieben wurde, die Abfolge der CR nur in bezug auf die jeweilige individuelle Applikation beibehalten. Das heißt, die CR Abfolge für all die Applikationen wird nicht beibehalten. Im Ergebnis kann in konventionellen Systemen eine zweite CR vor einer ersten CR ausgeführt werden, selbst wenn die asynchrone Operation, welche der ersten CR zugeordnet ist, zuerst beendet wird.
Danach fragt der CIS 230 die Kerneinheit 218 an, um zu bestimmen im Schritt 336, ob noch mehr kooperative Unterbrechungsinformationen (CII) in der Halteschlange 210 gespeichert ist. CII kann in der Halteschlange 210 gespeichert sein, wenn mehrere kooperative Unterbrechungen in der Halteschlange 210 während des Schrittes 230 noch anstehen oder wenn eine neue kooperative Unterbrechung im Schritt 304 in der Warteschlange 210 platziert wurde, während der CIS 230 eine vorherige CR ausgeführt hatte. Falls mehr CII in der Halteschlange 304 gespeichert ist, bestimmt die Kerneinheit im Schritt 344, ob die kooperativen Unterbrechungen gesperrt sind, d. h. ob CIDW nicht gleich Null ist. Die kooperativen Unterbrechungen könnten durch die vorausgehende CR gesperrt sein. Wenn die kooperativen Unterbrechungen gesperrt sind, führt die Kerneinheit 218 die Schritte 320 bis 326 in einer Subroutine A (Schritt 308) aus, wie es vorstehend beschrieben wurde. Sodann nimmt die Kerneinheit 218 im Schritt 338 die CCA wieder auf, unterbricht im Schritt 340 den CTS 230 und setzt die Ausführung in der Art und Weise fort, wie es oben in Bezug mit Schritt 310 beschrieben wurde. Falls die Kerneinheit 218 im Schritt 344 feststellt, daß die kooperativen Unterbrechungen freigegeben sind, wird die Prozedur beginnend vom Schritt 330 aus wiederholt. Nachdem alle kooperativen Unterbrechungen bedient wurden, ist die Halteschlange 210 leer. Sodann nimmt die Kerneinheit 318 im Schritt 338 die CCA auf, unterbricht im Schritt 340 den CIS 230 und setzt mit der Ausführung in der Art und Weise fort, wie es oben in Verbindung mit Schritt 310 beschrieben wurde.
Wie vorstehend angemerkt wurde, kann jede Applikation, Task oder CR alle kooperativen Unterbrechungen sperren. In konventionellen Systemen erfordert der Sperr- (und Freigabe-) Befehl für kooperative Unterbrechungen einen Zugriff auf die Kerneinheit 218. Leider ist ein Zugriff auf die Kerneinheit 218 aufwendig im Hinblick auf die Systemperformance. Die vorliegende Erfindung mildert dieses Problem. Fig. 4 ist ein Flußdiagramm, welches das Verfahren zum Sperren aller kooperativen Unterbrechungen beschreibt. Eine CCA, Task oder CR, d. h. die laufende Prozedur, bestimmt im Schritt 402, daß es notwendig ist, alle kooperativen Unterbrechungen zu sperren. Die laufende Prozedur inkrementiert im Schritt 404 den CIDC unmittelbar, d. h. ohne Zugriff auf die Kerneinheit 218, unter Verwendung einer elementaren Operation. Elementare Operationen, zum Beispiel eine Vergleichs- und eine Swap-Operation, werden bevorzugt durch die CPU 108 bereitgestellt. Elementare Operationen werden im allgemeinen verwendet, um einen Zugriff auf ein einziges Wort von Daten zu synchronisieren, welche von mehreren Tasks geteilt werden. Im Gegensatz dazu verwendet die vorliegende Erfindung die elementare Operation, um Operationen zwischen der Kerneinheit 218 und einer Task oder einer Applikation zu synchronisieren. Nach der Inkrementierung im Schritt 404 des CIDC 228, setzt die Kerneinheit den Betrieb fort, wie es vorstehend im Zusammenhang mit Schritt 310 beschrieben wurde.
Jede Applikation, Task oder CR kann den CIDC 228 dekrementieren. Fig. 5 ist ein Flußdiagramm, welches das Verfahren zum Freigeben von kooperativen Unterbrechungen beschreibt. In konventionellen Systemen, wie sie vorstehend mit Bezugnahme auf Fig. 4 beschrieben wurden, erfordert ein Freigabebefehl für eine kooperative Unterbrechung einen Zugriff zu der Kerneinheit 218. Bei der vorliegenden Erfindung dekrementiert in Schritt 502 die CCA, Task oder CR, d. h. die laufende Prozedur, den CIDC ohne Zugriff auf die Kerneinheit 118. Die laufende Prozedur bestimmt im Schritt 504, ob die kooperativen Unterbrechungen aktiviert sind, d. h. ob die CIDC 228 gleich Null ist. Wenn die kooperativen Unterbrechungen gesperrt sind, setzt das Betriebssystem 112 im Schritt 520 den Betrieb fort, wie es vorstehend im Zusammenhang mit Schritt 310 beschrieben wurde. Falls die kooperativen Unterbrechungen freigegeben sind, prüft die laufende Prozedur im Schritt 506 das CIPF 222, um zu bestimmen, ob eine kooperative Unterbrechung ansteht. Falls keine kooperativen Unterbrechungen anstehen, setzt das Betriebssystem 112 die Ausführung im Schritt 520 fort, wie es vorstehend mit Bezug auf Schritt 310 beschrieben wurde. Falls eine kooperative Unterbrechung ansteht, fragt die laufende Prozedur die Kerneinheit 218 an, um alle anstehenden kooperativen Unterbrechungen auszugeben. Die Kerneinheit 218 bestimmt im Schritt 508, ob die CCA in einem Spezialkontextmodus betrieben wird, in dem das SCF 227 geprüft wird. Wie es vorstehend diskutiert wurde, ist in diesem Beispiel das SCF 227 nicht gesetzt.
Die Kerneinheit 218 bestimmt sodann im Schritt 512, ob der CIS 230 ausgesetzt ist (Schritt 512). Wenn der CIS 230 nicht ausgesetzt ist, setzt das Betriebssystem 520 die Ausführung fort, wie es vorstehend mit Bezug auf Schritt 310 beschrieben wurde. Wenn der CIS 230 ausgesetzt ist, bestimmt die Kerneinheit 218 im Schritt 516, ob eine CII in der Halteschlange 210 gespeichert ist. Wenn die Halteschlange 210 leer ist, setzt das Betriebssystem 520 die Ausführung fort, wie es vorstehend mit Bezug auf Schritt 310 beschrieben wurde. Wenn die Halteschlange 210 eine CII Information enthält, nimmt die Kerneinheit 218 den Betrieb des CIS 230 auf und die Schritte 320 bis 348, wie sie in Fig. 3B gezeigt sind, werden in der vorstehend beschriebenen Art und Weise ausgeführt.
Das Verfahren zum Ausführen von kooperativen Applikationen, welche für den Betrieb in einer kooperativen Ablaufsteuerungsumgebung ausgelegt sind, wenn die kooperativen Applikationen nicht in einem Spezialkontextmodus betrieben werden, wird nachfolgend beschrieben. Das Verfahren zum Ausführen von kooperativen Applikationen, welche in einem Spezialkontextmodus betrieben werden, wird weiter unten erläutert.
Das vorstehend beschriebene Verfahren umfaßt die Situation, bei welcher sowohl die Applikationen 236, 233 als auch die Tasks 234 unter Verwendung derselben Befehlssatzsarchitektur entwickelt sind. Häufig verwenden jedoch eine oder mehrere Applikationen eine verschiedene Befehlssatzarchitektur, d. h. einen alten Befehlssatz, als der Befehlssatz, welcher durch das Betriebssystem 112 und die anderen Applikationen oder Tasks verwendet wird. Applikationen, welche den alten Befehlssatz verwenden, werden unter Verwendung eines Altbefehlssatzemulators ausgeführt, der nachfolgend als "Emulator" bezeichnet wird. Der Emulator führt CPU Befehle von der Altbefehlssatzarchitekturumgebung (die alte Umgebung) aus, unter Verwendung der ursprünglichen CPU-Befehle (CPU-Urbefehle) von der Neubefehlssatzarchitekturumgebung (die neue Umgebung). Wenn das Betriebssystem eine Applikation emuliert, welche unter Verwendung des alten Befehlssatzes entwickelt ist, arbeitet das Betriebssystem in einem Spezialkontextmodus.
Um einen Befehl von der alten Umgebung zu emulieren, benötigt die neue Umgebung mehrere ursprüngliche CPU-Befehle. Um die Integrität, d. h. die Unteilbarkeit, der kooperativen Applikationen in der neuen Umgebung zu bewahren, können kooperative Unterbrechungen lediglich an einer Altbefehlsgrenze der ursprünglichen CPU-Befehle auftreten. Das heißt, wenn die neue Umgebung drei ursprüngliche CPU-Befehle benötigt, um einen einzigen Befehl von der alten Umgebung zu emulieren, muß das Betriebssystem 112 sicherstellen, daß keine kooperativen Unterbrechungen auftreten, bis alle drei ursprünglichen CPU- Befehle ausgeführt wurden.
Wenn die CPU 108 Applikationen ausführt, die in der alten Umgebung (alte Applikationen) entwickelt wurden, werden sowohl emulierte als auch ursprüngliche CPU-Befehle ausgeführt. Die vorliegende Erfindung definiert einen Spezialkontextmechanismus, welcher die notwendige Geschwindigkeit bereitstellt, wenn Befehle emuliert werden und wenn zwischen der Ausführung von emulierten und ursprünglichen CPU-Befehlen geschaltet wird. Die Geschwindigkeit wird bereitgestellt, indem die Anfragen an die Kerneinheit 218 begrenzt sind. Insbesondere benötigt man keine zusätzliche Speicherbezugnahme zwischen der Ausführung von emulierten Befehlen. Zusätzlich wird auf die Kerneinheit 218 nicht zugegriffen: (1) zwischen der Ausführung von emulierten Befehlen, (2) wenn von der Ausführung von ursprünglichen CPU-Befehlen zu emulierten Befehlen geschaltet wird, und (3) wenn von der Ausführung von emulierten Befehlen zu ursprünglichen CPU-Befehlen geschaltet wird, außer kooperative Unterbrechungen sind anstehend und freigegeben.
Wie vorstehend diskutiert wurde, befindet sich das Betriebssystem 112 in einem Spezialkontextmodus, wenn eine alte Applikation emuliert wird. Das Betriebssystem 112 erfüllt die Notwendigkeit eines Spezialkontextmodus, wie er vorstehend angegeben wurde, unter Verwendung einer Spezialkontextmaske (SCM) 220 und eines Spezialkontextflags (SCF) 227. Die SCM 220 ist vorzugsweise ein Datenwort, welches in dem Benutzerabschnitt des Speichers 104 angeordnet ist. Vorzugsweise ist die SCM 220 durch den Emulator (CCA) als ein Teil einer Enter-Spezialkontext Operation gesetzt. Das SCF 227 ist vorzugsweise ein einzelnes Bit, welches in einem oberen Bit von dem selben Wort, CIDW 226, wie der CIDC 228 gespeichert ist. Das Speichern des SCF 227 im selben Wort wie der CIDC 228 ermöglicht, daß die zwei Stellen gleichzeitig unter Verwendung einer elementaren Operation, wie sie vorstehend diskutiert wurde, manipuliert werden. Das Speichern des SCF 227 in dem oberen Bit des CIDW 226 ermöglicht, daß der CIDC 228 mit normalen arithmetischen Operationen inkrementiert und dekrementiert wird.
Wenn der Emulator mit der Ausführung der emulierten Befehle beginnt, führt der Emulator, welcher die CCA ist, eine Enter- Spezialkontext Operation durch. Die Enter-Spezialkontext Operation ist in Fig. 6 dargestellt. Der Emulator führt die Enter-Spezialkontext Operation durch Setzen der SCM 222 im Schritt 602 und durch Setzen des SCF 227 im Schritt 604 aus. Wenn das SCF 227 gesetzt ist, sind die kooperativen Unterbrechungen gesperrt. Dies ist ersichtlich aus dem Schritt 306 und dem Schritt 344 in Fig. 3. In beiden dieser Schritte bestimmt die Kerneinheit 218, ob das gesamte Wort CIDW 226 gleich null ist. Falls das SCF 227 nicht null ist, dann ist das CIDW 226 nicht gleich null. Wenn die Subroutine A im Schritt 308 ausgeführt wird, bestimmt die Kerneinheit 218 im Schritt 322, ob das SCF 227 gesetzt ist. Wenn das SCF gesetzt ist, dann modifiziert die Kerneinheit 218 ein Datenregister innerhalb des Simulators (CCA) durch Ausführen einer logischen OR Operation zwischen der SCM 220 und dem internen Register des Emulators, anstelle des Erzeugens der kooperativen Unterbrechung;
Der Emulator prüft das betroffene Bit in dem internen Register nur bei emulierten Befehlsgrenzen, wobei der Emulator das Register nicht bei jeder Befehlsgrenze prüft. Da das betroffene Bit sich in einem internen Register befindet, ist es für den Emulator äußerst effizient, den Zustand des Bits zu prüfen.
Wenn der Emulator der vorliegenden Erfindung ermittelt, daß das Bit gesetzt ist, führt der Emulator eine Exit- Spezialkontext Operation durch. Die Exit-Spezialkontext Operation ist in Fig. 7 dargestellt. Der Emulator löscht im Schritt 702 das SCF 227 und das interne Registerbit in dem Emulator. Der Emulator geht sodann zu Punkt "G" im Schritt 503 in Fig. 5. Nachdem alle kooperativen Unterbrechungen bedient wurden, wie es vorstehend mit Bezug auf die Fig. 3-5 beschrieben wurde, setzt der Emulator fort, indem er eine Enter-Spezialkontext Operation ausführt und die Ausführung von emulierten Befehlen wiederaufnimmt.
In dieser Situation, d. h. wenn das SCF 227 gesetzt ist und eine Applikation den CIDC dekrementiert, ist der durch die vorliegende Erfindung durchgeführte Prozeß in Fig. 5 angegeben. Wenn die Kerneinheit 218 im Schritt 508 bestimmt, daß das SCF 227 gesetzt ist, bedient die Kerneinheit 218 nicht unmittelbar die kooperative Unterbrechung. Anstelle modifiziert die Kerneinheit 218 das interne Register des Emulators, CCA, indem eine logische OR Operation mit der SCM 220 und dem internen Register durchgeführt wird, und speichert das Ergebnis in das interne Register, wie es vorstehend mit Bezug auf Schritt 324 beschrieben wurde.
Während die Erfindung insbesondere mit Bezug auf ein bevorzugtes Ausführungsbeispiel und mehrere abgeänderte Ausführungsbeispiele gezeigt und beschrieben wurde, versteht es sich für den Fachmann, daß verschiedene Änderungen in der Form und den Details durchgeführt werden können, ohne den Schutzbereich der Erfindung, wie er beansprucht ist, zu verlassen.

Claims

1. Verfahren zur Verarbeitung einer ersten Applikation (236) in einem computergestützten System mit einem Prozessor, einem Controller, einem Speichermodul und einem preemptiven Betriebssystem, welches eine kooperative Ablaufsteuerung nicht unterstützt, wobei die erste Applikation ausgelegt ist, um auf einem zweiten Betriebssystem, welches eine kooperative Ablaufsteuerung und kooperative Unterbrechungen unterstützt, zu laufen, dadurch gekennzeichnet, daß es die Schritte umfaßt:

Empfangen (302) einer kooperativen Unterbrechung, welche der ersten Applikation zugeordnet ist;

Speichern (304) einer Adresse einer ersten Routine, welche der ersten Applikation zugeordnet ist, in einem ersten Speicherort (210) des Speichermoduls, wobei die erste Routine eine erste Prozedur zum Antworten auf die kooperative Unterbrechung aufweist;

Bestimmen (206, 312), ob die Ausführung der ersten Routine erlaubt ist; und

Ausführen (334) der ersten Routine unter Verwendung eines kooperativen Unterbrechungsservers (230), wenn die Ausführung der ersten Routine erlaubt ist.

2. Verfahren nach Anspruch 1, welches ferner den Schritt aufweist:

Aussetzen (332) der Ausführung einer zweiten Applikation, welche ausgelegt ist, um auf dem zweiten Betriebssystem zu laufen, wenn die Ausführung der ersten Routine erlaubt wird.

3. Verfahren nach Anspruch 1, welches ferner den Schritt aufweist:

Sperren (404) der ersten Routine durch Setzen von einem oder mehreren Sperrbits in dem Speichermodul unter Verwendung einer elementaren Operation, welche nicht auf den Controller zugreift.

4. Verfahren nach Anspruch 3, bei welchem der Schritt des Bestimmens, ob eine Ausführung der ersten Routine erlaubt ist, die Schritte umfaßt:

Bestimmen, ob ein Emulator einen emulierten Befehl ausführt; und

Bestimmen, ob der Emulator einen Befehl an einer Grenze des emulierten Befehls ausführt, wenn der Emulator den emulierten Befehl ausführt.

5. Verfahren nach Anspruch 4, bei welchem der Schritt des Bestimmens, ob die Ausführung der ersten Routine erlaubt ist, den Schritt umfaßt:

Setzen (324) von einem oder mehreren Spezialkontext-Bits (227) im Emulator.

6. Verfahren nach Anspruch 5, bei welchem der Schritt des Setzens von einem oder mehreren Spezialkontext-Bits die Schritte umfaßt:

Speichern eines Wertes in einer Spezialkontextmaske (220), wenn der Emulator einen emulierten Befehl ausführt;

Durchführen einer logischen OR Operation zwischen der Spezialkontextmaske und den Spezialkontext-Bits; und

Speichern des Ergebnisses der logischen OR Operation in den Spezialkontext-Bits.

7. Verfahren nach Anspruch 1, welches ferner den Schritt aufweist:

Unterbrechen der Ausführung der ersten Applikation (236), um eine zweite Applikation (234) auszuführen, welche ausgelegt ist, um auf einem Operationssystem zu laufen, welches eine unterbrechende Taskablaufsteuerung unterstützt.

8. Verfahren nach Anspruch 1, welches ferner die Schritte aufweist:

Empfangen einer zweiten kooperativen Unterbrechung, welche der zweiten Applikation zugeordnet ist;

Speichern der Adresse einer zweiten Routine, welche einer dritten Applikation zugeordnet ist, die ausgelegt ist, um in einer kooperativen Ablaufsteuerungsumgebung zu laufen, in einem zweiten Speicherort des Speichermoduls, wobei die zweite Routine eine Prozedur zum Antworten auf die zweite kooperative Unterbrechung umfaßt;

Bestimmen, ob die erste Routine ausgeführt wird;

Setzen eines Indikators für eine anstehende kooperative Unterbrechung, falls die erste Routine ausgeführt wird;

Bestimmen, ob die zweite Routine ausgeführt werden darf, falls die erste Routine nicht ausgeführt wird; und

Ausführen der zweiten Routine unter Verwendung des kooperativen Unterbrechungsservers, wenn die zweite Routine ausgeführt werden darf, wobei der kooperative Unterbrechungsserver sicherstellt, daß alle kooperativen Unterbrechungen in derselben Abfolge des zweiten Betriebssystems, welches kooperative Unterbrechungen unterstützt, bearbeitet werden,

9. Verfahren nach Anspruch 8, welches ferner den Schritt aufweist:

Aussetzen der Ausführung der zweiten Applikation, wenn die Ausführung der zweiten Routine erlaubt ist.

10. Verfahren nach Anspruch 1, welches ferner den Schritt aufweist:

Aussetzen aller kooperativen Applikationen, mit Ausnahme einer laufenden kooperativen Applikation, um sicherzustellen, daß die einzige kooperative Applikation, welche ausgeführt werden kann, die laufende kooperative Applikation ist.

11. Computergestütztes preemptives Betriebssystem, mit einem Prozessor zum Verarbeiten einer ersten Applikation (236) und einer zweiten Applikation (238), welche ausgelegt sind, um auf einem kooperativen Ablaufsteuerungsbetriebssystem unter Verwendung von kooperativen Unterbrechungen zu laufen, und zum Verarbeiten einer dritten Applikation (234), welche ausgelegt ist, um auf dem preemptiven Betriebssystem zu laufen, wobei das System dadurch gekennzeichnet ist, daß es aufweist:

eine erste Anzeigeschlange (212) zum Speichern von Information betreffend den Betrieb der ersten Applikation;

einen Prozessserver (224), welcher angeordnet, um mit der ersten Anzeigeschlange zu kommunizieren, um sicherzustellen, daß eine der ersten Applikation und der zweiten Applikation Zugriff auf den Prozessor entsprechend einer kooperativen Ablaufsteuerungsumgebung hat;

eine erste Routine, welche der ersten Applikation zugeordnet ist, zum Reagieren auf eine erste kooperative Unterbrechung, welche der ersten Applikation zugeordnet ist;

eine Halteschlange (210) zum Speichern von Information, welche der ersten Routine zugehört;

einen kooperativen Unterbrechungsserver (230), welcher angeordnet ist, um mit der Halteschlange zu kommunizieren, um die kooperativen Unterbrechungen zu bedienen, und um sicherzustellen, daß die kooperativen Unterbrechungen in der selben Folge bedient werden wie die kooperativen Unterbrechungen in dem kooperativen Ablaufsteuerungsbetriebssystem bereitgestellt werden; und

einen Controller (216), welcher mit der ersten Anzeigeschlange, dem Prozessserver und dem kooperativen Unterbrechungsserver gekoppelt ist, zum Steuern des Zugriffes auf die erste Anzeigeschlange und die erste Halteschlange und zum Bereitstellen einer preemptiven Ablaufsteuerungsumgebung.

12. System nach Anspruch 11, welches ferner aufweist:

einen Sperrmechanismus (226), welcher angeordnet ist, um Signale von einer der ersten Applikation, der zweiten Applikation und der ersten Routine zu empfangen, um das Bereitstellen der kooperativen Unterbrechungen durch den kooperativen Unterbrechungsserver zu verhindern, ohne auf den Controller zuzugreifen.

13. System nach Anspruch 12, bei welchem der Sperrmechanismus ferner aufweist:

einen emulierten Befehlsindikator (227), der angeordnet ist, um Signale vom Controller zu empfangen, zum Speichern von Information, welche anzeigt, daß ein emulierter Befehl ausgeführt wird, wobei der Sperrmechanismus das Bereitstellen der kooperativen Unterbrechungen durch den kooperativen Unterbrechungsserver verhindert, wenn der emulierte Befehlsindikator gesetzt ist.

14. System nach Anspruch 13, welches ferner aufweist:

einen Speicherort, welcher in der ersten Applikation angeordnet ist, um der zweiten Applikation mitzuteilen, daß eine kooperative Unterbrechung ansteht;

wobei der Controller den Speicherort modifiziert, wenn eine kooperative. Unterbrechung ansteht und der emulierte Befehlsindikator gesetzt ist.