DE69400206T2 - Mehrstufiges unterbrechungssystem - Google Patents

Mehrstufiges unterbrechungssystem

Info

Publication number
DE69400206T2
DE69400206T2 DE69400206T DE69400206T DE69400206T2 DE 69400206 T2 DE69400206 T2 DE 69400206T2 DE 69400206 T DE69400206 T DE 69400206T DE 69400206 T DE69400206 T DE 69400206T DE 69400206 T2 DE69400206 T2 DE 69400206T2
Authority
DE
Germany
Prior art keywords
interrupt
interrupts
executor
processing
hardware
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
DE69400206T
Other languages
English (en)
Other versions
DE69400206D1 (de
Inventor
George Norman
Patrick Ross
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Object Technology Licensing Corp
Original Assignee
Taligent Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Taligent Inc filed Critical Taligent Inc
Publication of DE69400206D1 publication Critical patent/DE69400206D1/de
Application granted granted Critical
Publication of DE69400206T2 publication Critical patent/DE69400206T2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/48Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806Task transfer initiation or dispatching
    • G06F9/4812Task transfer initiation or dispatching by interrupt, e.g. masked
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/52Program synchronisation; Mutual exclusion, e.g. by means of semaphores

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Bus Control (AREA)

Description

    Copyright-Hinweis
  • Dieses Patent enthält urheberrechtlich geschütztes Material, dessen Reproduktion nur als Teil der Patentanmeldung zu informativen Zwecken gestattet ist. Alle anderen Rechte, insbesondere das Recht der kommerziellen Verwertung derartigen Materials, sind vorbehalten.
  • Bereich der Erfindung
  • Die vorliegende Erfindung betrifft im allgemeinen eine hardware-unabhängige Schnittstelle für die externe, hardware-abhängige Ein-/Ausgabewelt (E/A).
  • Hintergrund der Erfindung
  • EP-A-0531108 offenbart ein Einzelebenen-Unterbrechungssystem, das den meisten Systemen gemein ist, die derzeit weltweit am Markt sind, und es wird als Stand der Technik in näheren Einzelheiten auf Seite 19, Zeilen 15-22, unter Bezugnahme auf Figur 9 beschrieben, welche als Stand der Technik bezeichnet wird. Eine Mehrzahl an Einrichtungen kann der Reihe nach von einem Satz an Unterbrechungsausführem ausgeführt werden, welche Unterbrechungen ausführen, wenn sie während Sendeaufrufvorgängen erkannt werden. Für Entwickler von Workstation-Software wird es zunehmend wichtiger, eine flexible Software-Umgebung zu schaffen und gleichzeitig die Konsistenz in der Anwenderschnittstelle zu gewährleisten. Die Unterbrechungsverarbeitung bei bestehenden Systemen bietet keine Mehrebenen-Unterbrechungsbefärderer. Mehrebenen-Unterbrechungsbeförderer beziehen sich auf Unterbrechungsausführer, die auch andere Unterbrechungsausführer auf rekursive Weise befördern.
  • So verfügt zum Beispiel der Apple Macintosh-Computer über einen Unterbrechungsausführer, der jeden einzelnen Unterbrechungsausführer wiederholt für die jeweilige Karte befördert, wenn er das System unterbricht. IBM-Prozessoren verteilen auf ähnliche Weise alle Einrichtungsunterbrechungen zu einer einzigen Ebene an Unterbrechungsbeförderern. Der Großteil der Computerindustrie folgt dem Beispiel des IBM-Modells bei der Verarbeitung von Unterbrechungen.
  • Zusammenfassung der Erfindung
  • Die bevorzugte Ausführungsform der Erfindung gemäß den Patentansprüchen beseitigt die Nachteile des Standes der Technik, indem sie eine hardware-unabhängige Schnittstelle zur externen hardware-abhängigen E/A-Welt schafft. Die von dieser Architektur zur Verfügung gestellten Dienstleistungen ermöglichen es einem Programmierer, sich auf Einrichtungen zu konzentrieren, anstatt auf die Kernunterbrechungsverarbeitung der unteren Ebene.
  • Die Unterbrechungsdienstleistungen sind Teile eines gesamten E/A-Modells, welches ein objektbasiertes E/A-System schafft, das eine dynamische Konfiguration des Systems unterstützt. Das Design dieser Unterbrechungen macht sich die Vorteile des Objektorientierten Designs (OOD) in einer andernfalls ungeordneten E/A-Welt zunutze. In der bevorzugten Ausführungsform der Erfindung wird die Objektverarbeitung selbst in die Routinen der untersten Ebene eingebaut. Dies umfaßt ein objektorientiertes Design bis hinunter zu den Unterbrechungsverarbeitungsabstraktionen. Diese Unterbrechungsabstraktionen bieten ein architektonisch solides Rahmenwerk für die dynamische Installation, Konfiguration und zeitliche Ausführung von Unterbrechungsausführern.
  • Kurze Beschreibung der Zeichnungen
  • Figur 1 ist ein Blockdiagramm eines Personal-Computer- Systems gemäß der bevorzugten Ausführungsform der Erfindung;
  • Figur 2 ist eine Darstellung einer bevorzugten Ausführungsform der Eingabeunterbrechungsdienstleistungen gemäß der vorliegenden Erfindung;
  • Figur 3 zeigt eine Hardware-Hierarchie einer bevorzugten Hardware-Umgebung gemäß der vorliegenden Erfindung;
  • Figur 4 zeigt eine Software-Hierarchie einer bevorzugten Software-Umgebung gemäß der vorliegenden Erfindung;
  • Figur 5 zeigt eine Mehrebenen-Hardware-Hierarchie für einen Standard-SCC-Chip gemäß der vorliegenden Erfindung;
  • Figur 6 zeigt eine alternative Hardware-Ausführungsform gemäß der vorliegenden Erfindung;
  • Figur 7 zeigt eine alternative Software-Ausführungsform gemäß der vorliegenden Erfindung;
  • Figur 8 zeigt einen Konfigurationszugriffsverwalter für einen Standardkontroll-Standardschnittstellenbus (SCSI-Bus).
  • Figur 9 zeigt eine Einzelebenen-Standardindustrie- Unterbrechungsbeförderung gemäß dem Stand der Technik.
  • Figur 10 zeigt ein Mehrebenen- Unterbrechungsbeförderungsflußdiagramm gemäß der vorliegenden Erfindung; und
  • Figur 11 zeigt eine bevorzugte Ausführungsform im C- Quellcode gemäß der vorliegenden Erfindung.
  • GENAUE BESCHREIBUNG DER ERFINDUNG
  • Die Erfindung wird vorzugsweise im Zusammenhang mit einem Betriebssystem angewandt, das sich auf einem Personalcomputer, wie zum Beispiel einem IBM PS/2 oder einem Apple Macintosh Computer, befindet. Eine repräsentative Hardwareumgebung wird in Figur 1 dargestellt, welche eine typische Hardware-Konfiguration einer Workstation gemäß der vorliegenden Erfindung darstellt und eine zentrale Recheneinheit 10, wie zum Beispiel einen herkömmlichen Mikroprozessor, und eine Anzahl anderer Einheiten umfaßt, die über einen Systembus 12 miteinander verbunden sind. Die in Figur 1 dargestellte Workstation umfaßt einen Direktzugriffsspeicher (RAM) 14, einen Nur-Lese-Speicher (ROM) 16, einen E/A- Adapter 18 zum Anschluß von Peripheriegeräten, wie zum Beispiel Disketteneinheiten 20, am Bus, einen Benutzerschnittstellenadapter 22 zum Anschluß einer Tastatur 24, einer Maus 26, eines Lautsprechers 28, eines Mikrophons 32 und/oder anderer Benutzerschnittstellengeräte, wie zum Beispiel eines Tast-Bildschirms (nicht dargestellt) am Bus, einen Kommunikationsadapter 34 zum Anschluß der Workstation an einem datenverarbeitenden Netzwerk und einen Anzeigenadapter 36 für den Anschluß eines Anzeigegerätes 38 am Bus. Typischerweise befindet sich auf der Workstation ein Betriebssystem, wie zum Beispiel das IBM OS/2 Betriebssystem oder das Apple System/7 -Betriebssystem.
  • Der Zweck von Unterbrechungsdienstleistungen besteht darin, eine hardware-unabhängige Schnittstelle zur externen, hardware-abhängigen E/A-Welt zu schaffen. Die von dieser Architektur zur Verfügung gestellten Dienstleistungen ermöglichen es dem Programmierer, sich mehr auf seine Einrichtung(en) zu konzentrieren, anstatt auf die Kernunterbrechungsverarbeitung der unteren Ebene.
  • Modellübersicht über die Architektur
  • Unterbrechungsdienstleistungen sind Teil eines E/A- Gesamtmodells, welches ein objektbasiertes E/A-System bietet, das die dynamische Konfiguration des Systems unterstützt. Das Design dieser Unterbrechungsdienstleistungen nutzt die Vorteile des Objektorientierten Designs (OOD) in einer ansonsten ungeordneten E/A-Welt.
  • Architekturziele
  • Unterbrechungsdienstleistungen sind Teil eines E/A- Gesamtmodells, welches ein objektbasiertes E/A-System bietet, das die dynamische Konfiguration des Systems unterstützt. Das Design dieser Unterbrechungen nutzt die Vorteile eines Objektorientierten Designs (OOD) in einer ansonsten ungeordneten E/A-Welt. Objektverarbeitung ist selbst in den Routinen der untersten Ebenen in der bevorzugten Ausführungsform der Erfindung enthalten. Dieses Design umfaßt Unterbrechungsverarbeitungsabstraktionen. Diese Unterbrechungsabstraktionen bieten ein architektonisch solides Rahmenwerk für die dynamische Installation, Konfiguration und zeitliche Ausführung von Unterbrechungsausführern.
  • Unterstützung der "Plug & Play"-Aufgabe
  • Die "Plug & Play"-Aufgabe ist ein Gesamtziel unseres E/A- Untersystems. Der Plug & Play-Betrieb befreit den Anwender davon, sich mit Konfigurationsdateien beschäftigen zu müssen, wenn er E/A-Hardware hinzufügen oder entfernen möchte.
  • Dynamische Installation von Unterbrechungsausführern
  • Eine erforderliche Erweiterung des Plug & Play-Betriebes ist die dynamische Installation von Unterbrechungsausführem, um eine Neukonfiguration von E/A-Einrichtungen zu ermöglichen, während das System läuft. Das beste Beispiel dafür ist das Umschalten der funktionellen Verwendung der seriellen Anschlüsse, nachdem das System gestartet wurde: eine solche Änderung würde im allgemeinen zu einer Entfernung des "alten" Unterbrechungsausführers und zur Installation des "neuen" führen.
  • Wiederherstellung von Hardware-Ausnahmen innerhalb von Unterbreahungsausführern
  • Die meisten Systeme sind sehr nachtragend bezüglich Ausnahmen, die erzeugt werden, während das System einen Unterbrechungscode ausführt. Der sich daraus ergebende Systemzusammenbruch hat wesentliche negative Auswirkungen auf die gesamte Systemzuverlässigkeit. Es gibt eine Anzahl verschiedener Gründe, warum Ausnahmen auftreten, zum Beispiel Programmierfehler, zeitweilige Busfehler, die erfolgreich wiederholt werden können, und Änderungen der Voraussetzungen, unter denen ein Unterbrechungsausführer arbeitet.
  • Ein Beispiel für das Ändern von Voraussetzungen umfaßt eine Situation, wo eine vormals gültige Speicher- oder Hardwareeinrichtung ohne vorherige Kenntnis des Unterbrechungsausführers entfernt wird. Die Wiederherstellung von der Ausnahme könnte nicht möglich sein, wenn der Unterbrechungsausführer für den Systembetrieb essentiell wichtig ist. Innovationen innerhalb der Personal-Computer-Industrie werden oft verlangsamt oder abgeblockt, weil die Betriebssystemsoftware (OS) zu viel über die darunterliegende Hardware-Plattform "wissen" muß. Diese unglückliche Wissensanforderung sperrt die Hardware an einem Ort ein, wo Änderungen sehr schwer durchzuführen sind. Die Verwendung von Objektabstraktionen in dieser tiefen Ebene des Systems ermutigt die Hardware- und Software-Innovation: sowohl die Hardware als auch die objektbasierte Software können sich ändern, ohne daß sich die Auswirkungen durch das ganze restliche System ausbreiten.
  • Laß Dich von Ressourcen finden
  • Ein grundlegendes Problem bei bestehenden, konfigurierbaren E/A-Systemen ist die Abhängigkeit von einer Art von Konfigurationsdatenbank. Diese Datenbank ist in manchen Fällen eine große, einzelne Datenbankdaten aber im allgemeinen handelt es sich dabei um kleine Textdateien, die im gesamten System verstreut sind. Ein viel besseres Beispiel ist eines, welches diese Kenntnis über die Konfigurationen "umkehrt", wodurch eine Gesamtkonfigurationsdatenbank nicht mehr notwendig ist. Bei Verwendung eines Designs, in welchem Ressourcen ihre auf einer höheren Ebene befindlichen "Eltern"-Objekte finden, ist eine Konfigurationsdatenbank nicht mehr notwendig.
  • Schlüsselabstraktionen Grundlegendes E/A-Modell
  • Das grundlegende E/A-Modell für die bevorzugte Ausführungsform der Erfindung besteht aus vier großen Baublöcken, wie sie in Figur 2 dargestellt und unten beschrieben sind.
  • 1) Die Zugriffsverwalter-Abstraktion 210: Zugriffsverwalter sind Anwenderbetriebsartabstraktionen, welche außerhalb des Kerns 260 ausgeführt werden;
  • 2) Der Unterbrechungsausführer 250: Unterbrechungsausführer sind einrichtungsspezifische Abstraktionen, welche Einrichtungsunterbrechungen verarbeiten;
  • 3) Die zu verwaltende Hardware-Einrichtung 220; und
  • 4) Unterbrechungsverwalter 230: Der Unterbrechungsverwalter verwaltet mehrere Unterbrechungsausführer und dekodiert die Unterbrechungen auf der ersten Ebene und verteilt sie zu den entsprechenden Unterbrechungsausführern. Die Zugriffsverwalterabstraktion und deren Unterbrechungsausführer stellen die klassischen Funktionen dar, die sich in einem Treiber finden.
  • Der Zugriffsverwalter 210 und der Unterbrechungsausführer 230 haben direkten Zugriff auf die Hardware-Einrichtung 220, die sie verwalten. Dies ermöglicht es dem Entwickler, die Funktion entweder innerhalb des Zugriffsverwalters 210 oder des Unterbrechungsausführers 230 zu betonen, um die Designziele zu erreichen. In einem Fall, in dem modernere E/A-Hardware verwendet würde, würde der Zugriffsverwalter 210 dominieren, und der Unterbrechungsausführer 250 würde minimal sein
  • Unterbrechungsausführer 230 werden auf Anforderung eines damit im Zusammenhang stehenden Zugriffsverwalters 210 installiert und/oder entfernt. Ein Zugriffsverwalter 210 darf einen Unterbrechungsausführer 230 nicht installieren, wenn die verwaltete Einrichtung keine Unterbrechungen erzeugt. Zugriffsverwalter können mehrere Einrichtungen unterstützen: in diesem Fall darf der Zugriffsverwalter einen Unterbrechungsausführer für jede Einrichtung installieren, die Dienstleistungen benötigt.
  • Zugriffsverwalter 210 und Unterbrechungsausführer 250 kommunizieren miteinander durch Verwendung zweier Standardschnittstellen. Der Zugriffsverwalter 210 kann eine Zweiweg-Kommunikationstransaktion durch Verwendung des Aktualisierungs- 280 Mechanismus in die Wege leiten. Der Unterbrechungsausführer 250 kann eine begrenzte Menge an Daten an einen beliebigen Task durch die OneWaySend- (EinWegSenden, OWSend) 294 Meldungsdienstleistung senden. Wenn ein Entwickler mit unzulänglicher E/A-Hardware zu tun hat, kann der Unterbrechungsausführer 250 eine große Menge der gesamten E/A-Funktionen und die Zugriffsverwaltungsabstraktion 210 eine geringere Menge davon übernehmen.
  • Der Apple SWIM-Diskettenkontroller zum Beispiel ist eine besonders schwierige Einrichtung: er kann keine Unterbrechungen erzeugen und ist während der Sektor-E/A 100% computergebunden. Ein SWIM-Zugriffsverwalter wäre klein und würde einfach die Anforderungen an seinen großen "Unterbrechungsausführer" mit dem Aktualisierungsvorgang weiterleiten. Der Unterbrechungsausführer würde notwendigerweise den gesamten E/A-Betrieb durchführen müssen und die Beendigung mit einem OWSend signalisieren. Wenngleich diese Art der E/A-Einrichtung aufgrund ihrer Kernspeicherverwendung und der Multitasking-Auswirkungen nicht bevorzugt ist, paßt sie in unser grundsätzliches E/A-Modell.
  • Ein E/A-Klient, wie zum Beispiel eine Anwendung, interagiert mit dem Zugriffsverwalter 210. Der Zugriffsverwalter 210 interagiert danach mit der Hardware-Einrichtung 220 direkt, und/oder dem Einrichtungsunterbrechungsausführer 250 durch die "Aktualisierungs"-Aufforderung 280. An einem Punkt erzeugt die Hardware-Einrichtung 220 eine Unterbrechung 270, die vom Unterbrechungsverwalter 230 in das erste Feld gesetzt wird und dann zum geeigneten Unterbrechungsausführer 250 befördert wird. Wenn der Unterbrechungsausführer 250 einen größeren Schritt im Umgang mit der Hardware-Einrichtung 220 abgeschlossen hat, antwortet der Unterbrechungsausführer 250 dem Zugriffsverwalter 210 mit einem OWSend 294. Der Zugriffsverwalter 210 informiert daraufhin den E/A-Klienten darüber, daß die angeforderte Maßnahme ausgeführt worden ist.
  • Der Zugriffsverwalter 210
  • Warum werden Zugriffsverwalter anstelle der klassischen Treiber verwendet? Die Antwort hängt mit der erweiterten Rolle zusammen, welche von die E/A-Software in der bevorzugten Ausführungsform der Erfindung verlangt wird. Es ist wahrscheinlich, daß auf jede Art der E/A-Einrichtung auf unterschiedliche Weise zuzugreifen ist.
  • Es ist zum Beispiel sehr unwahrscheinlich, daß Drucker oder Bandlaufwerke von mehreren Klienten gemeinsam genutzt werden. Diskettenlaufwerke sind von Natur aus gemeinsam nutzbar. Karten in Erweiterungsbussen können viele Einrichtungen mit unterschiedlichen Zugriffspolitiken aufweisen. Klarerweise läßt sich eine globale Einrichtungszugriffspolitikheutzutage nicht für alle Einrichtungen korrekt voraussagen. Daher kann das E/A-System keine globale E/A- Zugriffspolitik aufstellen, da jede Einrichtungszugriffpolitik, die heute erstellt wird, mit größter Wahrscheinlichkeit in der Zukunft falsch sein wird. Das E/A-System beschäftigt sich mit diesem Thema, indem es so viele Politikfragen wie möglich zu unseren neuen Treibern hinunterbewegt. Die funktionelle Rolle unserer neuen Treiber wurde von der einfachen Datenbewegung und Kontrolle einer Einrichtung dahingehend erweitert, daß sie nun auch die Definition der Zugriffspolitik der Einrichtung enthalten. Daher ist die Abstraktion, welche diese Zugriffspolitik definiert, als Zugriffverwalter bekannt.
  • Unterbrechungsausführer 230
  • Ein Unterbrechungsausführer ist eine unterbrechungsquellspezifische Abstraktion, welche Unterbrechungen verarbeitet und innerhalb des Adreßraumes des Kerns abläuft. Ein Unterbrechungsausführer ist einrichtungsspezifisch, weil dessen Code über detaillierte Kenntnisse von der Zieleinrichtung verfügt. Der Unterbrechungsausführer jedoch ist Kraft seiner Fähigkeit, mehrere Vorkommnisse einer Einrichtung an unterschiedlichen natürlichen Positionen handzuhaben, generisch.
  • Jeder Unterbrechungsausführer wird von der abstrakten TIn- terruptHandler-Basisklasse in Unterklassen unterteilt. Die TInterruptHandler-Klasse definiert den Protokollvertrag zwischen einrichtungsspezifischen Unterbrechungsausführern und dem Unterbrechungsverwalter innerhalb des Kerns. Die einrichtungsspezifische Unterklasse sowie alle anderen beliebigen Objekte, welche vom Unterbrechungsausführer verwendet werden, werden in einer normalen, gemeinsam verwendeten Bibliothek innerhalb des Systems verarbeitet.
  • Die Installation eines Unterbrechungsausführers von einer gemeinsam verwendeten Bibliothek erfordert einen damit im Zusammenhang stehenden Unterbrechungskontrolltask, so daß der Unterbrechungsausführer automatisch entfernt werden kann, wenn der Kontrolltask aus irgendeinem Grund beendet wird. Somit können die Unterbrechungsdienstleistungen garantieren, daß die vom Unterbrechungsausführer verwendeten Ressourcen nach Beendigung des Kontrolltasks wieder beansprucht werden. Figur 3 zeigt eine typische Hardware- Hierarchie gemäß der bevorzugten Ausführungsform der Erfindung.
  • E/A-Einrichtungen können an einem System über viele unterschiedliche Hardware-Pfade angeschlossen werden. Einige sind auf der Trägerleiterplatte eingebaut, andere sind an Bussen angeschlossen (z.B. Micro Channel, NuBus, SCSI, ISA), während andere eine Mischung aus beidem sind, wie zum Beispiel eine NuBus-Karte mit einem darauf befindlichen SCSI-Chip. Eine vereinfachende Abstraktion besteht darin, diese unterschiedlichen Hardware-Konfigurationen als eine Sammlung von Hardware-Hierarchien ähnlich wie in Figur 3 anzusehen.
  • Das Betrachten der Hardware als Hierarchie leitet sich von einer natürlichen Ansicht der Software für diese Einrichtungen als Hierarchie ab. Eine hierarchische Ansicht der Software paßt gut zur Einschränkung des Wissensumfangs bezüglich offensichtlicher Schichten der Hierarchie. Durch Einschränkung des Wissensumfangs können E/A-Politikthemen zu den niedrigsten Ebenen der Hierarchie gedrückt werden. Beim Auftreten einer Unterbrechung gibt die Wurzel der Software-Hierarchie die Kontrolle entlang der Software- Hierarchie nach unten weiter, bis der richtige Einrichtungsunterbrechungsaus führer die Unterbrechung verarbeitet.
  • Eltern-/Kind-Beziehung
  • Das E/A-System verwendet eine einfache Eltern-/Kind- Beziehung, um alle Schichten in den Software-Hierarchien zu verwalten. Jeder Unterbrechungsausführer und Zugriffsverwalter verfügt über eine Eltern-Beziehung und kann oder kann nicht eine Kind-Beziehung haben. Die Eltern-/Kind- Beziehung ist das einfachste Modell zur Verwaltung einer hierarchischen Abstraktion. Diese Beziehung muß zwei wichtige Rollen spielen: zum ersten definiert sie, wie die Software-Hierarchie konstruiert ist, und zum zweiten beschreibt sie den Kontrollfluß, wenn eine Unterbrechung auftritt.
  • Der Großteil der E/A-Hardware vereinfacht die Aufgabe, zu definieren, wo Funktionen in der Hierarchie geteilt werden sollten. In mancher Hardware ist die Aufgabe zur Definierung der Eltern-/Kind-Beziehung nicht so klar. Der Zilog- Chip Z8530 SCC ist genau ein solches Beispiel. Dieser Chip verfügt über zwei unterschiedliche Anschlüsse (A und B) und ein gemeinsames Unterbrechungsregister. Das offensichtlich erste Design besteht darin, zwei serielle Anschlüsse festzulegen und einen Unterbrechungsausführer für jeden Anschluß zur Verfügung zu haben. Wenn jedoch ein Unterbrechungsausführer für Anschluß A das Unterbrechungsregister lesen sollte, würde dieser den Unterbrechungszustand für beide Anschlüsse erhalten und diesen durch seine Maßnahmen löschen; dies würde sicherlich nicht funktionieren. Die Lösung besteht darin, zwei Ebenen der Abstraktion festzulegen: den Chip 500 und den Anschluß 510, wie dies in Figur 5 dargestellt ist.
  • Die Chipabstraktion stellt in diesem Beispiel den Elternteil dar, und sie exportiert zwei software-unabhängige serielle Anschlüsse. Wenn ein Klient (zum Beispiel eine MIDI- Anwendung) einen zugeordneten Anschluß verwenden muß, würde er zuerst das richtige Eltern-Unterbrechungsausführerobjekt erhalten und den mit dem Elternteil in Verbindung stehenden installierten MIDI-Unterbrechungsausführer anfordern. Dies zeigt, wie die Eltern-/Kind-Beziehung verwendet wird, um die Software-Hierarchie zu konstruieren. Als nächstes ist zu erklären, wie der Kontrollfluß im Unterbrechungsfall arbeitet. Nehmen wir für dieses Beispiel an, daß Anschluß B eine Unterbrechung erzeugt. Der Unterbrechungsverwalter dekodiert zuerst die Prozessorunterbrechung und befördert danach den SCC-Unterbrechungsausführer. Der SCC-Unterbrechungsausführer liest das Unterbrechungsregister (wodurch die Unterbrechungen gelöscht werden), dekodiert die Werte, die er findet, und bestimmt, daß der Anschluß B eine aktive Unterbrechung hat. Der Ausführer ruft die Unterbrechungsverwaltungsdienstleistung InvokeChild (KindAufrufen) auf, um den Unterbrechungsausführer für Anschluß B zu versenden, wodurch eine Kopie des Unterbrechungsregisters zum Ausführer weitergeleitet wird.
  • Nachdem die Unterbrechung für Anschluß B bedient wurde, initiiert das Unterbrechungsregister auch eine Anschluß-A- Unterbrechung, der SCC-Unterbrechungsausführer verschickt auf ähnliche Weise den Anschluß-A-Unterbrechungsausführer. Auf diese Weise benötigen die Anschlußunterbrechungsausführer niemals direkten Zugriff auf das gemeinsam verwendete Unterbrechungsregister.
  • Zusammenfassung der Architektur
  • Wie in der Philosophie des Designs festgehalten, bestand eine der wichtigsten Aufgaben darin, den Code wiederzuverwenden und Abstraktionen zu verwenden, um die E/A-Software nach vorne zu bringen. Hier ist ein einfaches Beispiel für die Art des Einflusses dieses Designs. Angenommen, ein Drittparteien-Entwickler beschließt, eine einfache Mehrwert-Karte herzustellen. Marktforschungen zeigen die Notwendigkeit für eine Erweiterungskarte mit einem SCSI-Bus und mehreren seriellen Anschlüssen auf. Der Entwickler beschließt, dieselben E/A-Chips zu verwenden, die ein anderer Hersteller in seinen Produkten verwendet, wie dies in Figur 6 dargestellt ist. Das Bauen der Hardware-Karte stellt kein Problem dar, aber das Steuern der Software durch die Karte könnte ein größeres Unterfangen werden. Eine bevorzugte Ausführungsform verringert Software-Veränderungen auf ein Mindestmaß, indem sie die Wiederverwendung bestehenden Codes auf größtmögliche Weise gestattet, wie dies in Figur 7 dargestellt ist. Aufgrund der Unterstützung sowohl auf Hardware- als auch auf der Software-Ebene muß ein Drittparteien-Entwickler nur einen geringen Teil der Software- Lösung entwickeln. Dieser Beitrag sind der Drittparteienzugriffsverwalter und der Unterbrechungsausführer; der Rest der Software kann wiederverwendeter, bestehender Code sein.
  • In Figur 6 zum Beispiel erzeugt ein Kleincomputer-Systemschnittstellen- (SCSI) Chip eine Unterbrechung, die von der Unterbrechungsdecodierung der ersten Ebene erkannt wird, wenn die Drittparteierweiterungskarte eine Unterbrechung durchführt. Danach, in Figur 7, bestimmt der Drittparteienunterbrechungsausführer, welche Unterbrechungshardware die Unterbrechung erzeugt hat. Danach wird der geeignete Unterbrechungsausführer ausgewählt, um die Unterbrechung auszuführen.
  • Konfigurationszugriffsverwalter
  • Konfigurationszugriffsverwalter sind verantwortlich für die Konfiguration einer Sammlung von Einrichtungen. Sie sind das dominierende Element in der bevorzugten Ausführungsform. Es gibt zwei Arten von Konfigurationszugriffsverwaltern. Die erste Art muß einen festgelegten Satz an Einrichtungen konfigurieren, und verfügt daher über eine klare Konfigurationsaufgabe. Die zweite Art muß eine unbekannte Anzahl und unbekannte Arten von Einrichtungen konfigurieren. Diese zweite Art muß daher ein Protokoll ausführen, um zu bestimmen, welche Einrichtungen vorhanden sind, bevor sie ihre Konfigurationsaufgaben durchführen kann.
  • Wenn ein Konfigurationszugriffsverwalter gestartet wird, trägt er die Verantwortung, alle Einrichtungen zu finden, für die er verantwortlich ist. Nachdem die Einrichtungen aufgefunden und identifiziert sind, trifft der jeweilige Konfigurationszugriffsmanager eine Politikentscheidung: entweder den geeigneten Zugriffsverwalter durch ein konkretes Beispiel darzulegen, oder einfach aufzuzeichnen, daß die Einrichtung gefunden wurde, aber nicht mit einem Zugriffsverwalter verbunden ist.
  • Figur 8 zeigt einen Konfigurationszugriffsverwalter für einen Standardkontroll-Standardschnittstellen- (SCSI) Bus. Der Zugriffsverwalter muß dem Standard-SCSI-Protokoll folgen, um zu bestimmen, welche Einrichtungen momentan am SCSI-Bus angeschlossen sind. Nachdem eine Einrichtung gefunden wurde, bestimmt der Konfigurationszugriffsverwalter, ob ein einrichtungsspezifischer Zugriffsverwalter als konkretes Beispiel dargelegt werden sollte.
  • Eine Erweiterungskarte ist ein Beispiel für einen festgelegten Satz an zu konfigurierenden Einrichtungen mit mehr als einer Einrichtung darauf. Ein Zugriffsverwalter für eine Erweiterungskarte würde eine festgelegte Politikentscheidung haben. Zum Beispiel würde bei einer Erweiterungskarte mit zwei SCSI-Kontrollern die Logik mit SCSI-Chips im Zusammenhang stehen. Die Einrichtungen an den SCSI-Bussen würde von einem SCSI-Bus-Konfigurationszugriffsverwalter konfiguriert werden müssen. Dieses Beispiel zeigt, wie ein Konfigurationszugriffsverwalter auf rekursive Weise angewandt werden kann. Die Verwendung einer Software-Hierarchie zur Verwaltung einer willkürlichen Hardware-Hierarchie ermöglicht es dem E/A-System, jede beliebige Hardware- Plattform oder Konfiguration dynamisch zu konfigurieren.
  • Nur- Software-Unterbrechungsausführer
  • Ein "Nur-Software"-Unterbrechungsausführer ist einer, der nicht mit einer Hardware-Einrichtungsunterbrechung im Zusammenhang steht. Es gibt zwei grundlegende Arten von Nur Software-Unterbrechungsausführern: reine Softwaremodule und "Aufruf"-Ausführer. Ein reines Softwaremodul bedient niemals Unterbrechungen: ein Aufruf-Ausführer wird von einem anderen Unterbrechungsausführer aufgerufen, aber er empfängt keine Unterbrechungen direkt von der Hardware.
  • Ein Beispiel für ein "reines Software"-Modul wäre der Unterbrechungsausführer (eigentlich der gesamte Treiber) für den Apple SWIM-Diskettenkontroller. Dieses Modul bedient niemals Unterbrechungen, sondern treibt stattdessen direkt das Diskettengerät auf CPU-gebundene Weise an. Andere Beispiele wären ein Leistungsmeßwerkzeug oder eines, welches eine Art spezialisierter Koprozessorunterstützung bietet.
  • Unterbrechungsausführerinteraktion
  • In manchen Fällen wird es für Unterbrechungsausführer und/oder Zugriffsverwalter notwendig sein, zu interagieren. Ein gutes Beispiel für eine Unterbrechungsausführerinteraktion ist der Fall eines Treibermoduls für ein Digitalsignalprozessor- (DSP) Modem, welches Aktualisierungen vom seriellen Zugriffsverwalter empfängt (für Modemkontrolle/Status- und Zeichenübertragung), Aufrufe an den seriellen Unterbrechungsausführer durchführt (für empfangene Zeichen) und durch die Kernuhr zur Überprüfung von Modemstatuszeilen.
  • Aufrufe
  • Ein Aufruf ist ein spezialisierter Verfahrensaufruf von einem Unterbrechungsausführer an einen anderen. Argumente an den Ruf werden von dieser Architektur nicht festgelegt, sondern sie werden zwischen beiden Teilnehmern am Aufruf vereinbart. Beispiele für Aufrufunterbrechungsausführer umfassen Funktionen, welche Aufrufe in regelmäßigen zeitlichen Abständen vom Systemuhrunterbrechungsausführer benötigen: Abruf für die Diskettenmedieneinführung bei einem SWIM, oder Wartung von Überwachungsgerät-Zeitüberschreitungen bei einer SCSI-Operation. Verfahren im Interrupt- Handler zeigen die Fähigkeiten eines Unterbrechungsausführers an, eine Liste von Aufrufklienten zu führen (z.B. Can- DoCallout, DoAddCallout, DoDeleteCallout). Der Klientenausführer verfügt über ein Aufruf-Verfahren, welches sendeberechtigungsmarkenbasierte Informationen erhält, die zum Beispiel mit Mausereignissen im Zusammenhang stehen. Die zum Aufruf weitergeleiteten Daten umfassen Verweise auf Objekte wie TCalloutData, die in Unterklassen eingeteilt werden können, so daß alle Beförderungsausführer unterschiedliche Argumente haben könnten (z.B. eine Uhr möchte eine Tickzählung) . Der Unterbrechungsverwalter bietet AddCallout- und DeleteCallout-Verfahren, so daß der Verwalter Do- DeleteCallout() aufrufen kann, um aufzuräumen, wenn ein Unterbrechungsausführer entfernt wird.
  • Flußdiagramm der detaillierten Logik
  • Figur 9 ist ein Flußdiagramm eines Flußdiagramms des Standes der Technik der Industriestandard-Unterbrechungsbeförderung. Die Einzelebenen-Unterbrechungsbeförderung ähnlich der in Figur 9 dargestellten Logik wird in vielen Computersystemen verwendet. Die Verarbeitung beginnt bei Punkt 900, wo der Unterbrechungszustand abgefragt wird. Danach wird beim Entscheidungsblock 910 ein bestimmter Unterbrechungsausführer entsprechend dem Unterbrechungszustand ausgewählt. Danach wird beim E/A-Block 920 der bestimmte Unterbrechungsausführer befördert. Schließlich wird beim Funktionsblock 930 die Unterbrechung gemäß dem ausgewählten Unterbrechungsaus führer verarbeitet.
  • Figur 10 zeigt eine Mehrebenen-Unterbrechungsbeförderung gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung. Die Verarbeitung beginnt am Punkt 1000, wo der Unterbrechungszustand abgefragt wird. Danach wird am Entscheidungsblock 1010 ein bestimmter Unterbrechungsausführer entsprechend dem Unterbrechungszustand ausgewählt. Dann wird am E/A-Block 1020 der bestimmte Unterbrechungsausführer befördert. Dann wird am Funktionsblock 1090 die Unterbrechung gemäß dem ausgewählten Unterbrechungsausführer verarbeitet. Eine bevorzugte Ausführungsform der Erfindung wird im Funktionsblock 1090 dargestellt. Die Ausführung ist in der Lage, auf rekursive Weise Unterbrechungen durch die Schritte 1030, 1040 und 1050 hindurch auszuwählen und zu befördern, welche den Schritten 1000, 1010 und 1020 entsprechen. Der Funktionsblock 1090 kann so oft wie nötig kopiert und ausgeführt werden. Schließlich löscht der Unterbrechungsausführer am Funktionsblock 1060 die Unterbrechung oder die Unterbrechungen.
  • Figur 11 zeigt den C-Quellcode, der notwendig ist, um den Funktionsblock 1090 aus Figur 10 zu implementieren. Die Beschriftungen in Figur 11 entsprechen den Beschriftungen von Figur 10. Somit wird zum Beispiel der Unterbrechungszustand bei 1030 gelesen, der Unterbrechungsausführer bei 1040 ausgewählt, und die nächste Ebene des Unterbrechungsausführers bei 1050 aufgerufen.

Claims (8)

1. Eine Vorrichtung zur Verarbeitung von Unterbrechungen (900), die Unterbrechungs-Management-Mittel zur Verteilung von Unterbrechungen an Unterbrechungsausführer (910-930) für eine Vielzahl von Einrichtungen (38, 32, 24, 26, 28, 36, 34, 18, 20) in einem Computersystem (10) benutzt,
gekennzeichnet durch:
(a) Verarbeitungsmittel zur Bestimmung eines Einrichtung-Unterbrechungszustandes (1000);
(b) Beförderungsmittel zur Verteilung der Einrichtungsunterbrechung zu einem ersten Unterbrechungsausführer (1010-1020);
(c) erste Unterbrechungsausführer-Mittel zum Analysieren des besagten Einrichtung-Unterbrechungszustandes und zur Inituerung eines zweiten Unterbrechungsausführers (1030-1050);
(d) Verarbeitungsmittel zur Übertragung von Informationen von besagtem zweiten Unterbrechungsausführer zu einer Anwendung zur Vervollständigung der Unterbrechungsanforderung (200, 1060);
(e) Mittel zur Ausführung einer Einrichtungsunterbrechung von einer oder mehreren Einrichtungen (500-510); und
(f) Mittel zur Unterstützung ineinandergeschachtelter Unterbrechungen (1030-1050).
2. Eine Vorrichtung zur Verarbeitung von Unterbrechungen nach Anspruch 1, enthaltend Verarbeitungsmittel zur Unterstützung von Unterbrechungen, die von Vielfach-Funktionskarten angefordert werden (500-510; Figur 7).
3. Eine Vorrichtung zur Verarbeitung von Unterbrechungen nach Anspruch 1, enthaltend Verarbeitungsmittel zur Ausführung von rekursiven Unterbrechungen unter Verwendung des gleichen Unterbrechungsausführers (500-510; Figure 7).
4. Eine Vorrichtung zur Verarbeitung von Unterbrechungen nach Anspruch 1, enthaltend Verarbeitungsmittel zur unabhängingen Entwicklung eines jeden Unterbrechungsausführers (500-510)
5. Ein Verfahren zur Verarbeitung von Unterbrechungen (900), das Unterbrechungs-Management-Mittel zur Verteilung von Unterbrechungen an Unterbrechungsausführer (910-930) für eine Vielzahl von Einrichtungen (38, 32, 24, 26, 28, 36, 34, 18, 20) in einem Computersystem (10) benutzt,
gekennzeichnet durch:
(a) Bestimmung eines Einrichtung-Unterbrechungszustandes (1000);
(b) Verteilung der Einrichtungsunterbrechung zu einem ersten Unterbrechungsausführer (1010-1020);
(c) Analysieren des besagten Einrichtung- Unterbrechungszustandes und zur Inituerung eines zweiten Unterbrechungsausführers (1030-1050);
(d) Übertragung von Informationen von besagtem zweiten Unterbrechungsausführer zu einer Anwendung zur Vervollständigung der Unterbrechungsanforderung (200, 1060);
(e) Ausführung einer Einrichtungsunterbrechung von einer oder mehreren Einrichtungen (500-510); und
(f) Unterstützung ineinandergeschachtelter Unterbrechungen (1030-1050).
6. Ein Verfahren zur Verarbeitung von Unterbrechungen nach Anspruch 5, enthaltend den Schritt einer Unterstützung von Unterbrechungen, die von Vielfach-Funktionskarten angefordert werden (500-510; Figur 7).
7. Ein Verfahren zur Verarbeitung von Unterbrechungen nach Anspruch 5, enthaltend den Schritt der Ausführung von rekursiven Unterbrechungen unter Verwendung des gleichen Unterbrechungsausführers (500-510; Figure 7).
8. Ein Verfahren zur Verarbeitung von Unterbrechungen nach Anspruch 5, das den Schritt enthält, einen jeden Unterbrechungsausführer (500-510) unabhängig zu entwickeln.
DE69400206T 1993-03-25 1994-01-03 Mehrstufiges unterbrechungssystem Expired - Fee Related DE69400206T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US3679193A 1993-03-25 1993-03-25
PCT/US1994/000276 WO1994022081A1 (en) 1993-03-25 1994-01-03 Multi-level interrupt system

Publications (2)

Publication Number Publication Date
DE69400206D1 DE69400206D1 (de) 1996-06-27
DE69400206T2 true DE69400206T2 (de) 1997-01-23

Family

ID=21890675

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69400206T Expired - Fee Related DE69400206T2 (de) 1993-03-25 1994-01-03 Mehrstufiges unterbrechungssystem

Country Status (7)

Country Link
US (1) US5630141A (de)
EP (1) EP0672278B1 (de)
JP (1) JPH08508125A (de)
AU (1) AU6023894A (de)
CA (1) CA2135517A1 (de)
DE (1) DE69400206T2 (de)
WO (1) WO1994022081A1 (de)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5680624A (en) * 1993-12-21 1997-10-21 Object Licensing Corporation Object oriented interrupt system
US5630101A (en) * 1994-11-22 1997-05-13 Minnesota Mining And Manufacturing Company System for communication of image information between multiple-protocol imaging devices
US6148321A (en) * 1995-05-05 2000-11-14 Intel Corporation Processor event recognition
US5758168A (en) * 1996-04-18 1998-05-26 International Business Machines Corporation Interrupt vectoring for optionally architected facilities in computer systems
US5852743A (en) * 1996-07-12 1998-12-22 Twinhead International Corp. Method and apparatus for connecting a plug-and-play peripheral device to a computer
JPH10260849A (ja) * 1997-03-19 1998-09-29 Mitsubishi Electric Corp 情報処理装置および割り込み制御方法
US6021446A (en) * 1997-07-11 2000-02-01 Sun Microsystems, Inc. Network device driver performing initial packet processing within high priority hardware interrupt service routine and then finishing processing within low priority software interrupt service routine
US6085265A (en) * 1998-01-09 2000-07-04 Toshiba America Information Systems, Inc. System for handling an asynchronous interrupt a universal serial bus device
WO2001046804A1 (en) * 1999-08-16 2001-06-28 Z-Force Corporation System of reusable software parts for implementing concurrency and hardware access, and methods of use
US20040111593A1 (en) * 2002-12-05 2004-06-10 International Business Machines Corporation Interrupt handler prediction method and system
US8024504B2 (en) * 2008-06-26 2011-09-20 Microsoft Corporation Processor interrupt determination
US8473662B2 (en) * 2009-12-18 2013-06-25 Electronics And Telecommunications Research Institute Interrupt-handling-mode determining method of embedded operating system kernel
WO2023283872A1 (en) * 2021-07-15 2023-01-19 Intel Corporation System management mode runtime resiliency manager

Family Cites Families (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4342082A (en) * 1977-01-13 1982-07-27 International Business Machines Corp. Program instruction mechanism for shortened recursive handling of interruptions
CA1184305A (en) * 1980-12-08 1985-03-19 Russell J. Campbell Error correcting code decoder
US4420806A (en) * 1981-01-15 1983-12-13 Harris Corporation Interrupt coupling and monitoring system
US4779187A (en) * 1985-04-10 1988-10-18 Microsoft Corporation Method and operating system for executing programs in a multi-mode microprocessor
US4768149A (en) * 1985-08-29 1988-08-30 International Business Machines Corporation System for managing a plurality of shared interrupt handlers in a linked-list data structure
US5062042A (en) * 1986-04-28 1991-10-29 Xerox Corporation System for managing data which is accessible by file address or disk address via a disk track map
US4821220A (en) * 1986-07-25 1989-04-11 Tektronix, Inc. System for animating program operation and displaying time-based relationships
US4885717A (en) * 1986-09-25 1989-12-05 Tektronix, Inc. System for graphically representing operation of object-oriented programs
US4891630A (en) * 1988-04-22 1990-01-02 Friedman Mark B Computer vision system with improved object orientation technique
EP0347162A3 (de) * 1988-06-14 1990-09-12 Tektronix, Inc. Einrichtung und Verfahren zum Steuern von Datenflussprozessen durch erzeugte Befehlsfolgen
US5041992A (en) * 1988-10-24 1991-08-20 University Of Pittsburgh Interactive method of developing software interfaces
US5133075A (en) * 1988-12-19 1992-07-21 Hewlett-Packard Company Method of monitoring changes in attribute values of object in an object-oriented database
US5050090A (en) * 1989-03-30 1991-09-17 R. J. Reynolds Tobacco Company Object placement method and apparatus
US5060276A (en) * 1989-05-31 1991-10-22 At&T Bell Laboratories Technique for object orientation detection using a feed-forward neural network
US5125091A (en) * 1989-06-08 1992-06-23 Hazox Corporation Object oriented control of real-time processing
US5181162A (en) * 1989-12-06 1993-01-19 Eastman Kodak Company Document management and production system
US5093914A (en) * 1989-12-15 1992-03-03 At&T Bell Laboratories Method of controlling the execution of object-oriented programs
US5075848A (en) * 1989-12-22 1991-12-24 Intel Corporation Object lifetime control in an object-oriented memory protection mechanism
DE69114321T2 (de) * 1990-02-20 1996-07-18 Nippon Electric Co Zum Durchführen der Unterbrechungsverschachtelungsfunktion geeignetes Unterbrechungssteuerungsgerät.
US5390329A (en) * 1990-06-11 1995-02-14 Cray Research, Inc. Responding to service requests using minimal system-side context in a multiprocessor environment
US5151987A (en) * 1990-10-23 1992-09-29 International Business Machines Corporation Recovery objects in an object oriented computing environment
JP2507833B2 (ja) * 1990-12-25 1996-06-19 三菱電機株式会社 マイクロコンピュ−タ
US5119475A (en) * 1991-03-13 1992-06-02 Schlumberger Technology Corporation Object-oriented framework for menu definition
US5469571A (en) * 1991-07-15 1995-11-21 Lynx Real-Time Systems, Inc. Operating system architecture using multiple priority light weight kernel task based interrupt handling
US5257375A (en) * 1991-08-23 1993-10-26 International Business Machines Corp. Method and apparatus for dispatching tasks requiring short-duration processor affinity
US5222215A (en) * 1991-08-29 1993-06-22 International Business Machines Corporation Cpu expansive gradation of i/o interruption subclass recognition
JPH0831041B2 (ja) * 1991-09-06 1996-03-27 インターナショナル・ビジネス・マシーンズ・コーポレイション プログラム条件処理方法およびコンピュータ・システム
JPH05233326A (ja) * 1991-12-19 1993-09-10 Internatl Business Mach Corp <Ibm> コンピュータシステムにおいて事象を取り扱う方法及びシステム
US5515538A (en) * 1992-05-29 1996-05-07 Sun Microsystems, Inc. Apparatus and method for interrupt handling in a multi-threaded operating system kernel
US5369770A (en) * 1992-11-02 1994-11-29 Microsoft Corporation Standardized protected-mode interrupt manager
US5483647A (en) * 1992-12-17 1996-01-09 Bull Hn Information Systems Inc. System for switching between two different operating systems by invoking the server to determine physical conditions to initiate a physical connection transparent to the user
US5410709A (en) * 1992-12-17 1995-04-25 Bull Hn Information System Inc. Mechanism for rerouting and dispatching interrupts in a hybrid system environment

Also Published As

Publication number Publication date
US5630141A (en) 1997-05-13
DE69400206D1 (de) 1996-06-27
AU6023894A (en) 1994-10-11
JPH08508125A (ja) 1996-08-27
EP0672278B1 (de) 1996-05-22
WO1994022081A1 (en) 1994-09-29
EP0672278A1 (de) 1995-09-20
CA2135517A1 (en) 1994-09-29

Similar Documents

Publication Publication Date Title
DE69400206T2 (de) Mehrstufiges unterbrechungssystem
DE68925474T2 (de) Verriegelungsrechnersysteme
DE68919631T2 (de) Verfahren zur Verarbeitung von Programmteilen eines verteilten Anwendungsprogramms durch einen Hauptrechner und einen intelligenten Arbeitsplatz in einer SNA LU 6.2-Netzwerkumgebung.
DE2856483C2 (de)
DE69815946T2 (de) Informationsverarbeitungsvorrichtung
DE69630329T2 (de) Verfahren zur Verwaltung des Deaktivierens und Ausschaltens eines Servers
DE10296798B4 (de) SMM-Lader und -Ausführungsmechanismus für Komponentensoftware für mehrere Architekturen
DE69936162T2 (de) Verfahren und Gerät für ein objektorientiertes Unterbrechungssystem
DE68926176T2 (de) Verwaltungssystem für lizenzierte Programme
DE69637436T2 (de) Objektorientiertes Kommunikationssystem mit Unterstützung für mehrere entfernte Maschinentypen
DE19983476B4 (de) Verfahren und Schaltungsanordnung zur Einplanung von Operationen unter Verwendung einer Abhängigkeitsmatrix
DE60017457T2 (de) Verfahren zur isolierung eines fehlers in fehlernachrichten
DE112004001775T5 (de) Verfahren und Vorrichtung zur Bereitstellung von automatischen Software-Updates
DE2243956A1 (de) Speicherprogrammierte datenverarbeitungsanlage
DE69727633T2 (de) Verfahren und Gerät zur Benutzerstufeunterstützung für das Synchronisieren mehrerer Ereignisse
DE10003015A1 (de) Die Erzeugung von Ereignis-Bedingungs-Aktions-Regeln aus Prozessmodellen
DE102006009617A1 (de) Systeme und Verfahren zum Steuern von mehreren Hot Plug Vorgängen
DE10119876A1 (de) Verfahren, System und Computerprorammprodukt zur Bereitstellung einer Jobüberwachung
DE60303413T2 (de) Verfahren und computersystem zum reduzieren von ausführungszeiten bei der materialbedarfsplanung
DE602006000728T2 (de) Unterstützung dynamisch typisierter Sprachen in typisierten Assemblersprachen
DE8803950U1 (de) Digitalrechner mit Befehlsmodusumwandlung
DE69737253T2 (de) Verfahren und Vorrichtung zum Bestimmen des Umfanges eines Suchvorganges für Factory-Objekte
DE602004007872T2 (de) Verteiltes semantisches Schema
EP3364257A1 (de) Verfahren zum betrieb eines engineering-systems für ein industrielles prozessautomatisierungssystem und steuerungsprogramm
EP4002098A1 (de) Verfahren zur bereitstellung der funktionalität von mehreren mikrodiensten und/oder der funktionalität von mehreren software-containern mittels einer cloud-infrastruktur, system, verwendungssystem, computerprogramm und computerlesbares medium

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8327 Change in the person/name/address of the patent owner

Owner name: OBJECT TECHNOLOGY LICENSING CORP., CUPERTINO, CALI

8339 Ceased/non-payment of the annual fee