DE3855167T2

DE3855167T2 - Prozess-Traps in einem verteilten auf Nachrichten gegründeten System

Info

Publication number: DE3855167T2
Application number: DE3855167T
Authority: DE
Inventors: Gabor Simor
Original assignee: Computer X Inc
Current assignee: Computer X Inc
Priority date: 1987-01-05
Filing date: 1988-01-05
Publication date: 1996-11-14
Anticipated expiration: 2008-01-06
Also published as: JPS63174136A; EP0274413A2; DE3855167D1; CA1292078C; EP0274413A3; EP0274413B1

Description

VERWANDTE ERFINDUNGEN

Die vorliegende Erfindung betrifft die folgenden Erfindungen, die alle am 06. Mai 1985 eingereicht wurden und alle an den Rechtsnachfolger der vorliegenden Erfindung übertragen worden sind:
1. Titel: Nested Contexts in a Virtual Single Machine
Erfinder: Andrew Kun, Frank Kolnick, Bruce Mansfiled EP-A-0201065
2. Titel: Computer System With Data Residence Transparency and Data Access Transparency
Erfinder: Andrew Kun, Frank Kolnick, Bruce Mansfield EP-A-0201064
3. Titel: Network Interface Module With Minimized Data Paths
Erfinder: Bernhard Weisshaar, Michael Barnea EP-A-0201063
4. Titel: Method of Inter-Process Communication in a Distributed Data Processing System
Erfinder: Bernhard Weisshaar, Andrew Kun, Frank Kolnick, Bruce Mansfield EP-A-0201063
5. Titel: Logical Ring in a Virtual Single Machine Erfinder: Andrew Kun, Frank Kolnick, Bruce Mansfield EP-A-0201065
6. Titel: Virtual Single Machine With Message-Like Hardware Interrupts and Processor Exeptions
Erfinder: Andrew Kun, Frank Kolnick, Bruce Mansfield EP-A-0201065
Die vorliegende Erfindung betrifft auch die folgenden Erfindungen, die alle an dem hiermit gleichen Tag eingereicht wurden, und alle an den Rechtsnachfolger der vorliegenden Erfindung übertragen worden sind:
7. Titel: Computer Human Interface Comprising User- Adjustable Window for Displaying or Printing Information
Erfinder: Frank Kolnick EP-A-0274087
8. Titel: Computer Human Interface With Multi- Application Display
Erfinder: Frank Kolnick EP-A-0274087
9. Titel: Object-Oriented Software Architecture Supporting Input/Output Device Independence
Erfinder: Frank Kolnick EP-A-0274087
10. Titel: Self-Configuration of Nodes in a Distributed Message-Based Operating System
Erfinder: Gabor Simor EP-A-0274413
11. Titel: Computer Human Interface With Multiple Independent Active Pictures and Windows
Erfinder: Frank Kolnick EP-A-0274087

TECHNISCHES GEBIET

Die Erfindung betrifft im allgemeinen die Verarbeitung von digitalen Daten, und insbesondere ein Betriebssystem, in dem eine Benachrichtigungsnachricht immer dann angefordert werden kann, wenn ein bestimmter Prozess erzeugt oder beendet wird.

HINTERGRUND DER ERFINDUNG

Die vorliegende Erfindung ist in einem verteilten Datenverarbeitungssystem implementiert - d. h., in zwei oder mehreren Datenverarbeitungssystemen, die unabhängig voneinander arbeiten können aber die derart gekoppelt sind, daß sie Nachrichten zueinander senden und voneinander empfangen.
Ein Lokalnetz (LAN) ist ein Beispiel eines verteilten Datenverarbeitungssystems. Ein typisches LAN umfaßt eine Anzahl von autonomen Datenverarbeitungs-"Knoten", von denen jeder wenigstens einen Prozessor und einen Speicher umfaßt. Jeder Knoten kann unabhängig Datenverarbeitungsoperationen durchführen. Zusätzlich ist jeder Knoten (durch geeignete Einrichtungen wie beispielsweise ein verdrilltes Drahtpaar, ein Koaxialkabel, ein optisches Faserkabel, etc.) an ein Netzwerk anderer Knoten gekoppelt, das in Abhängigkeit von den Designerwägungen beispielsweise eine Schleife, ein Stern, ein Baum etc. sein kann.
Wie oben erwähnt, findet die vorliegende Erfindung Anwendung in einem solchen verteilten Datenverarbeitungssystem, da in einem solchen System das Erfordernis nach Prozessen besteht, die ablaufen oder die in den individuellen Knoten ausgeführt werden, so daß Daten gemeinsam benutzt und unter ihnen kommuniziert werden.
Ein "Prozess", wie er in der vorliegenden Erfindung verwendet wird, ist als geschlossenes Paket von Daten und ausführbaren Prozeduren, die diese Daten verarbeiten, vergleichsweise zu einem "Task" in anderen bekannten Systemen, definiert. In der vorliegenden Erfindung kann ein Prozess als vergleichbar zu einem Unterprogramm in Bezug auf die Größe, die Komplexität und die Weise, wie es verwendet wird, angesehen werden. Der Unterschied zwischen Prozessen und Unterprogrammen ist, daß Prozesse dynamisch erzeugt und zerstört werden können und gleichzeitig mit ihrem Erzeuger und anderen "Unterprogrammen" ausgeführt werden können.
In einem Prozess, wie er in der vorliegenden Erfindung verwendet wird, sind die Daten vollständig vertraulich und auf sie kann von außen, d. h. durch andere Prozesse, nicht zugegriffen werden. Prozesse können deshalb verwendet werden, um "Objekte", "Module" oder andere Datenabstraktionen auf höherer Stufe bzw. Niveau zu implementieren. Jeder Prozess läuft sequentiell ab. Das gleichzeitige Ablaufen wird durch mehrere Prozesse, die möglicherweise auf mehreren Prozessoren ablaufen, erzielt.
Jeder Prozess in dem verteilten Datenverarbeitungssystem der vorliegenden Erfindung hat einen eindeutige Kennung (PID), durch die auf ihn Bezug genommen werden kann. Der PID wird durch das System zugeordnet, wenn der Prozess erzeugt wird und wird von dem System verwendet, um den Prozess absolut bzw. physikalisch zu lokalisieren.
Jeder Prozess hat auch einen nicht eindeutigen, symbolischen "Namen", der eine Zeichenkette (character string) mit variabler Länge ist. Im allgemeinen ist der Name eines Prozesses systemweit bekannt. Um den Gültigkeitsbereich der Namen einzuschränken, verwendet die vorliegende Erfindung das Konzept eines "Kontexts".
Ein "Kontext" ist einfach eine Ansammlung verwandter Prozesse, deren Namen außerhalb des Kontexts nicht bekannt sind. Kontexte partitionieren den Namensraum in kleinere verwaltbarere Untersysteme. Sie "verstecken" auch Namen, wodurch sichergestellt wird, daß Prozesse, die in ihnen enthalten sind, nicht unbeabsichtigterweise mit denen in anderen Kontexten in Konflikt kommen.
Ein Prozess in einem Kontext kann nicht explizit mit Prozessen innerhalb anderer Kontexte kommunizieren und weiß nichts über diese. Alle Wechselwirkungen über die Kontextgrenzen müssen durch einen "Kontextprozess" ablaufen, womit ein Grad an Sicherheit geschaffen wird. Der Kontextprozess wirkt oftmals als ein Vermittlungseinrichtung für einlaufende Nachrichten, wobei sie zu den geeigneten Unterprozessen in seinem Kontext umgeleitet werden.
Ein Kontextprozess verhält sich wie jeder andere Prozess und hat zusätzlich die Eigenschaft, daß irgendwelche Prozesse, die er erzeugt, nur ihm selbst und untereinander bekannt sind. Die Erzeugung des Prozesses stellt die Definition eines neuen Kontexts mit demselben Namen wie dem Prozess dar.
Jeder Prozess kann Kontextprozesse erzeugen. Jeder neue Kontext, der somit definiert wird, ist vollständig innerhalb des Kontexts enthalten, in dem er erzeugt wurde, und ist deshalb von einer Bezugnahme von aussen abgeschirmt. Dieses "verschachteln" erlaubt es, daß der Namensraum hierarchisch bis zu einer erwünschten Tiefe strukturiert wird.
Konzeptionell ist das höchste Niveau in der Hierarchie das System selbst, das alle Kontexte umfaßt. Das Verschachteln wird im Top-Down-Design verwendet, um ein System in Komponenten oder "Schichten" zu teilen, wobei jede Schicht detaillierter als die vorangehende ist. Dies ist analog zu dem Teilen eines Tasks hinab in Unterprogramme, und in der Tat können viele Anwendungen, die in bekannten Systemen Einzeltasks sind, in mehrere Prozesse in geschachtelten Kontexten übersetzt werden.
Eine "Nachricht" ist ein Puffer, der Daten enthält, die einem Prozess mitteilen, was zu tun ist und/oder ihn mit Informationen beliefern, die er benötigt, um seine Operation auszuführen. Jeder Nachrichtenpuffer kann eine verschiedene Länge (bis zu 64 kByte) haben. Durch Konvention definiert das erste Feld in dem Nachrichtenpuffer den Typ der Nachricht (beispielsweise "Lesen", "Drucken", "Status", "Ereignis" bzw. "Event", etc.)
Nachrichten werden von einem Prozess zu einem anderen mit dem Namen oder der PID in eine Warteschlange eingereiht. Das Einreihen in eine Warteschlange verhindert Potentialsynchronisationsprobleme und wird anstelle von Semaphoren, Monitoren, etc. verwendet. Der Sender einer Nachricht kann frei fortfahren, nachdem die Nachricht gesendet worden ist. Wenn der Empfänger versucht eine Nachricht zu erhalten, wird er ausgesetzt, bis eine Nachricht eintrifft, falls nicht bereits eine in seiner Warteschlange wartet. Optional kann der Sender spezifizieren, daß er auf eine Antwort warten will und er wird ausgesetzt, bis die bestimmte Nachricht eintrifft. Nachrichten von einer anderen Quelle werden nicht aus der Warteschlange genommen bis zu dem Zeitpunkt, nach dem dies passiert ist.
In der vorliegenden Erfindung sind Nachrichten der einzige Weg für zwei Prozesse, um Daten auszutauschen. Es gibt kein Konzept einer "globalen Variable". Miteinander verwendete Speicherbereiche sind anders als durch Prozesse, die im wesentlichen jeden Bereich mittels Mitteilungen bewältigen, nicht erlaubt. Mitteilungen sind auch die einzige Form eines dynamischen Speichers, die das System verarbeitet. Eine Anforderung, einen Speicher zu zuteilen, gibt deshalb einen Speicherblock zurück, der lokal durch den Prozess verwendet werden kann aber nicht auf einen anderen Prozess übertragen werden kann.
Nachrichten schaffen den Mechanismus, durch den eine Hardware- Transparenz erzielt wird. Ein Prozess, der irgendwo in dem System lokalisiert ist, kann eine Nachricht an einen anderen Prozess irgendwo anders in dem System senden, (sogar auf einem anderen Prozessor), falls er den Prozessnamen kennt. Dies bedeutet, daß Prozesse zu jederzeit dynamisch über das System verteilt werden können, um einen optimalen Durchsatz zu erzielen, ohne die Prozesse, die auf sie Bezug nehmen, zu ändern. Die Auflösung der Ziele wird mittels Durchsuchen des Prozessnamenraums durchgeführt.
Das Kontextverschachtelungsniveau bestimmt den "Gültigkeitsbereich bzw. den Rahmen der Bezugnahme", wenn Mitteilungen zwischen den Prozessen mittels des Namens gesendet werden. Für einen gegebenen Prozess kann eine Mitteilung an alle Prozesse auf seinem eigenen Niveau (d. h. in demselben Kontext) und (optionalerweise) auf irgendeinem beliebigen höheren Niveau gesendet werden. Die Kontexte werden von dem derzeitigen Kontext aufwärts durchsucht, bis eine Übereinstimmung gefunden ist. Dann wird allen Prozessen mit dem gegebenen Namen auf dem Niveau eine Kopie der Mitteilung geschickt. Ein Prozess kann auch eine Nachricht an sich selbst oder an seinen Stamm (den Kontextprozess) schicken, ohne irgendeinen Namen explizit zu wissen, wobei die Existenz mehrfacher Vorkommen eines Prozesses in verschiedenen Kontexten mit verschiedenen Namen erlaubt wird.
Das Senden von Mitteilungen durch die PID macht das Erfordernis für einen Suchnamen offensichtlich und ignoriert Kontextgrenzen. Dies ist die effizienteste Methode der Kommunikation.
In einem bekannten Datenverarbeitungssystem wird ein Prozess- Steuerblock (PCB) verwendet, um verschiedene Attribute und den Status der Prozesse zu beschreiben, wobei der Status der durch die Prozesse verwendeten Betriebsmittel bzw. Ressourcen eingeschlossen ist. Beispiele solcher Ressourcen sind Dateien, Datenspeichereinrichtungen, I/O-Einrichtungen, Ports, etc.
Das Betriebssystem der vorliegenden Erfindung verwendet auch PCBs, aber sie müssen nicht Buch über den Status von Prozessen oder Ressourcen, die durch die Prozesse verwendet werden, führen, womit das System modularer und rekonfigurierbarer sein kann.
Es ist allerdings immer noch wünschenswert, die Fähigkeit des Überwachens des Status der Prozesse innerhalb des Betriebssystems der vorliegenden Erfindung und insbesondere die Tatsache, daß ein Prozess erzeugt oder beendet worden ist, zu schaffen.
Es besteht ein bemerkenswertes Erfordernis, daß man in der Lage ist, innerhalb eines Datenverarbeitungsbetriebssystems die Möglichkeit für einen Prozess zu schaffen, daß er anfordert, benachrichtigt zu werden, wenn ein bezeichneter Prozess erzeugt und/beendet worden ist. Zusätzlich besteht ein Erfordernis für eine derartige Benachrichtigung, daß sie innerhalb verschiedener Organisationsniveaus auftritt, wie beispielsweise einem Kontext der Prozesse, einem Knoten oder einem gesamten Netzwerk.
Aus der Veröffentlichung "Computer", Vol. 15, Oktober 1982, Seiten 54-68, sind Verfahren bekannt, eine Benachrichtigungsmitteilung zu schaffen, wenn auf einem der Knoten eines verteilten Datenverarbeitungssystems, wie sie entsprechend in den Präambeln des Anspruchs 1 und des Anspruchs 6 zitiert sind, ein Prozess erzeugt und beendet wird.

KURZE ZUSAMMENFASSUNG DER ERFINDUNG

Demgemäß ist es eine Aufgabe der vorliegenden Erfindung, ein verbessertes Verfahren zur Lieferung einer Benachrichtigungsmitteilung zu schaffen.
Gemäß einem ersten Aspekt der Erfindung wird ein Verfahren zur Lieferung einer Benachrichtigungsnachricht, wie es in Anspruch 1 beansprucht ist, geschaffen.
Gemäß einem zweiten Aspekt der Erfindung wird ein Verfahren zur Lieferung einer Benachrichtigungsmitteilung, wie es in Anspruch 6 beansprucht ist, geschaffen.

KURZE BESCHREIBUNG DER ZEICHNUNGEN

Die Erfindung wird insbesondere in den angefügten Ansprüchen dargelegt. Allerdings werden andere Merkmale der Erfindung offensichtlicher und die Erfindung wird am besten zu verstehen sein durch Bezugnahme auf die folgende detaillierte Beschreibung im Zusammenhang mit den beigefügten Zeichnungen, in denen:
Fig. 1 eine repräsentative Darstellung eines auf verteilten Nachrichten basierenden Einzelnetzwerk-Datensystems des Typs zeigt, das die vorliegende Erfindung umfaßt.
Fig. 2 ein Blockdiagramm zeigt, daß ein auf verteilten Nachrichten basierendes Mehrfachnetzwerk-Datensystem des Typs darstellt, der die vorliegende Erfindung umfaßt.
Fig. 3 ein Architekturmodell eines Datenverarbeitungssystems zeigt, das den Typ der vorliegenden Erfindung umfaßt.
Fig. 4 die Beziehung zwischen den Softwarekontexten und Prozessen zeigt, wie sie die vorliegende Erfindung betreffen.
Fig. 5 die Beziehung zwischen einem Benutzerprozess und einem Ressourcenprozess zeigt, wie sie die vorliegende Erfindung betreffen.
Fig. 6 zeigt, wie Nachrichten zwischen den Prozessen innerhalb eines geschachtelten Kontexts in dem Datenverarbeitungssystem der vorliegenden Erfindung gesendet werden können.
Fig. 7 das Standardformat einer Nachricht, in dem auf verteilten Nachrichten basierenden Datenverarbeitungssystem des Typs, der die vorliegende Erfindung umfaßt, zeigt.
Fig. 8 zeigt, wie Prozesserzeugungstrap(PCT)-Nachrichten und Prozessbeendigungstrap (PTT)-Nachrichten zwischen dem Prozessmanagerprozess (PMP) in einem verteilten Datenverarbeitungssystems des Typs, der die vorliegende Erfindung umfaßt, geschickt werden.
Fig. 9 ein verteiltes Datenverarbeitungssystem zeigt, wobei dargestellt wird, wie ein Benutzerprozess a und b benachrichtigt werden, wenn ein Ressourcenprozess x erzeugt oder beendet worden ist.
Fig. 10 ein verteiltes Datenverarbeitungssystem zeigt, wobei dargestellt wird, wie ein Prozessmanagerprozess benachrichtigt wird, wenn ein Prozesserzeugungstrap an einem entfernten Knoten aufgelöst wird.
Fig. 11 darstellt, wie die vorliegende Erfindung in einem Fehlermanagementmodul in einem verteilten Datenverarbeitungssystem verwendet werden kann, in dem jeder Systemknoten einen Event-Log-Service-Process (ELSP) umfaßt.
Fig. 12A ein Flußdiagramm zeigt, das eine Operation darstellt, um ein Prozesserzeugungstrap zu setzen.
Fig. 12B ein Flußdiagramm zeigt, das eine Operation darstellt, um ein Prozessbeendigungstrap zu setzen.
Fig. 12C ein Flußdiagramm zeigt, das eine Operation darstellt, um ein Prozessbeendigungstrap aufzulösen bzw. freizugeben.
Fig. 12D ein Flußdiagramm zeigt, das eine Operation darstellt, um einen Prozesserzeugungstrap aufzulösen.
Fig. 12E ein Flußdiagramm zeigt, das eine Operation darstellt, um eine Erzeugungstrap-Auflösung von anderen Knoten zu handhaben.
Fig. 12F ein Flußdiagramm zeigt, das eine Operation darstellt, um ein Prozesserzeugungstrap aufzulösen.
Fig. 12G ein Flußdiagramm zeigt, das eine Operation darstellt, um zu überprüfen, ob ein Erzeugungstrap gesetzt ist.
Fig. 12H ein Flußdiagramm zeigt, das eine Operation darstellt, um ein Prozessbeendigungstrap zu löschen.

ÜBERBLICK ÜBER DAS COMPUTERSYSTEM

Bezugnehmend auf Fig. 1 ist eine verteilte Computerkonfiguration gezeigt, die mehrere Knoten 2-7 (Knoten) umfaßt, die locker durch ein Lokalnetzwerk (LAN) 1 gekoppelt sind. Die Anzahl der Knoten, die an das Netzwerk angeschlossen werden können, ist beliebig und hängt von der Benutzeranwendung ab. Jeder Knoten umfaßt wenigstens einen Prozessor und einen Speicher, wie unter Bezugnahme auf Fig. 2 unten stehend detaillierter erläutert wird. Grundsätzlich kann jeder Knoten andere Einheiten, wie beispielsweise einen Drucker 8, ein Operator-Display- Modul (ODM) 9, ein Massenspeichermodul 13 und andere I/O- Einrichtungen 10 umfassen.
Bezugnehmend auf Fig. 2 wird nun eine verteilte Mehrfachnetzwerk-Computerkonfiguration gezeigt. Ein erstes Lokalnetzwerk LAN 1 umfaßt einige Knoten 2, 4 und 7. Das LAN 1 ist mit einem zweiten Lokalnetzwerk LAN 2 mittels eines Intelligent- Communications-Moduls (ICM) 50 verbunden. Das Intelligent- Communication-Modul umfaßt einen Link zwischen dem LAN und anderen Netzwerken und/oder fernen Prozessoren (wie beispielsweise programmierbaren Controllern).
Das LAN 2 kann mehrere Knoten (nicht gezeigt) umfassen und kann unter demselben LAN-Protokoll, wie dem der vorliegenden Erfindung, arbeiten oder es kann unter einigen kommerziell erhältlichen Protokollen, wie beispielsweise Ethernet; MAP, dem Manufacturing Automation Protocol of General Motors Corp.; System Network Architecture (SNA) of International Business Machines, Inc.; SECS-II; etc. arbeiten. Jedes ICM 50 ist programmierbar, um eines der obengenannten bestimmten Protokolle auszuführen. Zusätzlich kann das Basisverarbeitungsmodul des Knoten selbst als ein intelligenter peripherer Controller (IPC) für spezialisierte Einrichtungen verwendet werden.
Das LAN 1 ist zusätzlich an ein drittes Lokalnetzwerk LAN 3 über das ICM 52 angeschlossen. Ausserdem ist ein Prozesscontroller 55 an das LAN 1 über das ICM 54 angeschlossen.
Ein repräsentativer Knoten N (7, Fig. 2) umfaßt einen Prozessor 24, der in einer bevorzugten Ausführungsform ein Prozessor der Motorola 68000 Prozessorfamilie ist. Jeder Knoten umfaßt ein Read Only Memory (ROM) 28 und ein Random Access Memory (RAM) 26. Zusätzlich umfaßt jeder Knoten ein Netzwerk- Interfacemodul (NIM) 21, das den Knoten an das LAN anschließt, und ein Bus-Interface 29, das den Knoten an zusätzliche Einrichtungen innerhalb eines Knotens koppelt.
Während ein Minimalknoten in der Lage ist, zwei periphere Einrichtungen zu unterstützen, wie beispielsweise ein Operator- Display-Modul (ODM) 41 und ein I/O Modul 44, können zusätzliche Einrichtungen (einschließlich zusätzlicher Prozessoren, wie beispielsweise ein Prozessor 27) innerhalb eines Knotens vorgesehen werden. Andere zusätzliche Einrichtungen können beispielsweise einen Drucker 42 und ein Massenspeichermodul 43, das eine Hard Disk und eine Backup-Einrichtung (Floppy Disk oder Streamer Tape Laufwerk) umfassen.
Das Operator-Display-Modul 41 umfaßt eine Tastatur und einen Schirm, um es dem Operator zu ermöglichen, Informationen einzugeben und visuelle Information zu empfangen.
Während ein einzelner Knoten alle obengenannten Einheiten umfassen kann, sind in der typischen Benutzeranwendung individuelle Knoten normalerweise spezialisierte Funktionen zugeordnet. Beispielsweise können einer oder mehrere Massenspeicherknoten so eingerichtet werden, daß sie als Datenbankserver arbeiten. Es können ausserdem mehrere Operatorkonsolen und wenigstens ein Knoten zur Erzeugung von Hartkopie-Druckausgaben vorgesehen werden. Jeder dieser Knoten oder getrennt zugewiesener Knoten können spezielle Anwenderprogramme ausführen.
Das System ist insbesondere so konstruiert, daß eine integrierte Lösung zur Produktionsautomatisierung, Datenerfassung und anderen Realzeitanwendungen zur Verfügung gestellt werden. Als solches umfaßt es ein volles Komplement von Dienstleistungen, wie beispielsweise eine graphische Ausgabe, Windows, Menues, Icons, dynamische Anzeigen, Electronic Mail, Event- Aufzeichnung und Dateimanagement. Software Entwicklungs- Features umfassen Compiler, einen window-orientierten Editor, einen Debugger und Performance-Überwachungstools.

Lokalnetzwerk

Das Lokalnetzwerk, wie es entweder in Fig. 1 oder in Fig. 2 dargestellt ist, verbindet das ganze System und macht das oben beschriebene verteilte Virtuellmaschinenmodell möglich. Das LAN schafft einen hohen Durchsatz, garantierte Antwort, Verläßlichkeit und niedrige Zutrittskosten. Das LAN ist auch autonom, in dem Sinn, daß die ganze System- und Anwendungssoftware ihrer Existenz nicht bewußt ist. Beispielsweise könnte jedes Netzwerk-Interfacemodul (beispielsweise NIM 21, Fig. 2) ersetzt werden, ohne irgendeine Software, mit Ausnahme der, die es direkt treibt, umzuschreiben.
Das LAN Verbindungsmedium kann ein verdrilltes Paar oder Koaxialkabel sein. Zwei Kanäle (logischerweise zwei getrennte Netzwerke) können zur Verläßlichkeit und zum erhöhten Durchsatz vorgesehen werden.
Die LAN Architektur ist ein logischer Ring, in dem ein elektronisches "Token" konstant von Knoten zu Knoten mit einer hohen Geschwindigkeit weitergegeben wird. Der augenblickliche Halter des Tokens kann es verwenden, um einen "Frame" aus Daten zu senden oder kann es zu dem nächsten Knoten in dem Ring weitergeben. Das NIM muß lediglich die logische Adresse und den Status seines unmittelbar nachfolgenden Nachbars wissen.
Die Verantwortlichkeit des NIMs ist auf das Detektieren des Ausfalls dieses Nachbars oder des Einschlusses eines neuen Nachbars beschränkt. Im allgemeinen ist die Anpassung an ausgefallene oder neu hinzugefügte Knoten automatisch.
Das Netzwerk-Interface bildet direkt in den Speicher des Prozessors ab. Datenaustausch tritt durch einen Dual- Portpufferpool auf, der eine verbundene Liste von anhängigen "Frames" umfaßt. Logische Nachrichten, die in ihrer Länge variieren, werden in Frames mit fester Größe zur Übertragung geteilt und werden durch das empfangende NIM wieder zusammengesetzt. Frames werden für diesen Zweck sequenz-nummeriert. Falls ein Frame nicht innerhalb einer kurzen Zeitdauer erkannt wird, wird er mehrmals rückübertragen bevor er als fehlerhaft behandelt wird.
Wie oben unter Bezugnahme auf Fig. 2 beschrieben, kann das LAN mit anderen LANs, die unter demselben LAN-Protokoll über sogenannte "Bridgeways" verbunden werden oder es kann über "Gateways" mit anderen Typen von LANs verbunden werden.

Softwaremodell

Das Computerbetriebssystem der vorliegenden Erfindung bearbeitet Prozesse, Nachrichten und Kontexte, wie sie hierin definiert sind. Demgemäß bietet dieses Betriebssystem dem Programmierer eine Hardware-Abstraktion anstelle einer Daten- oder Steuerungsabstraktion an.
Auf Prozesse wird ohne Bezug auf ihren physikalischen Ort über einen kleinen Satz von Nachrichtenübertragungsbasiseinheiten Bezug genommen. Wie vorher erwähnt, hat jeder Prozess sowohl eine eindeutige systemerzeugte Kennungseinheit und einen nicht notwendigerweise eindeutigen Namen, der durch den Programmierer zugewiesen wird. Die Kennungseinheit schafft einen schnellen direkten Zugriff, während der Name einen beschränkten Gültigkeitsbereich hat und einen symbolischen, indirekten Zugriff schafft.
Bezugnehmend auf Fig. 3 ist ein Architekturmodell der vorliegenden Erfindung gezeigt. Die unterste oder Hardware-Schicht 63 umfaßt eine Anzahl von Prozessoren 71-76, wie oben beschrieben. Die Prozessoren 71-76 können physikalisch innerhalb eines oder mehrerer Knoten vorliegen. Die obere oder Software- Schicht 60 stellt eine Anzahl von Prozessen P1-P10 dar, die Nachrichten m1-m6 zueinander schicken. Die mittlere Schicht 61, als "virtuelle Maschine" bezeichnet, isoliert die Hardware von der Software und erlaubt es, daß Programme geschrieben werden, als ob sie auf einem einzelnen Prozessor ausgeführt werden. Umgekehrt können Programme über mehrere Prozessoren verteilt werden, ohne explizit für diesen Zweck konstruiert zu sein.

Die virtuelle Maschine

Wie vorher beschrieben, ist ein "Prozess" ein selbstenthaltendes Datenpaket mit ausführbaren Prozeduren, die diese Daten bearbeiten. Die Daten sind völlig vertraulich und auf sie kann nicht durch andere Prozesse zugegriffen werden. Es gibt kein Konzept eines gemeinsamen Speichers innerhalb der vorliegenden Erfindung. Die Ausführung eines Prozesses ist strikt sequentiell. Mehrere Prozesse laufen gleichzeitig ab und müssen durch das Betriebssystem zeitlich organisiert werden. Die Prozesse können wieder verwendbar sein, in diesem Fall ist nur eine Kopie des Codes geladen, sogar wenn mehrere Anwendungen aktiv sind.
Jeder Prozess hat eine eindeutige "Prozessidentifizierungsnummer" (PID) durch die auf ihn Bezug genommen werden kann. Die PID ist durch das System zugewiesen, wenn der Prozess erzeugt wird bis der Prozess beendet wird. Die PID-Zuordnung umfaßt einen Zufallsfaktor, der garantiert, daß das PID in der näheren Zukunft nicht wieder verwendet wird. Der Inhalt des PIDs ist für den Programmierer nicht relevant, wird aber durch die virtuelle Maschine verwendet, um den Prozess physikalisch zu lokalisieren. Einen PID kann man sich als einen "Pointer" auf einen Prozess vorstellen.
Jeder Prozess hat auch einen "Namen", der eine Zeichenkette von variabler Länge ist, die durch den Programmierer zugewiesen wird. Ein Name braucht nicht eindeutig sein und diese Mehrdeutigkeit kann verwendet werden, um neue Dienstleistungen transparent zu verwenden und die Fehlertoleranz zu unterstützen.
Fig. 4 stellt dar, daß der systemweite Namensraum in bestimmte Unterabschnitte mittels durch die Bezugszeichen 90 bis 92 bezeichneter "Kontexte" geteilt ist. Ein Kontext ist einfach eine Ansammlung verwandter Prozesse, deren Namen außerhalb des Kontexts nicht bekannt sind. Der Kontext 90 umfaßt beispielsweise die Prozesse A, a, a, b, c, d und e. Der Kontext 91 umfaßt die Prozesse B a, b, c und f. Und der Kontext 92 umfaßt die Prozesse C, a, c, d und x.
Ein bestimmter Prozess in jedem Kontext, als "Kontextprozess" bezeichnet, ist sowohl innerhalb des Kontexts als auch innerhalb des unmittelbar einschließenden Kontexts (als sein "Stammkontext" bezeichnet) bekannt. In dem Beispiel, das in Fig. 4 dargestellt ist, sind die Prozesse A-C Kontextprozesse für die entsprechenden Kontexte 90-92. Der Stammkontext des Kontexts 91 ist der Kontext 90 und der Stammkontext des Kontexts 92 ist der Kontext 91. Konzeptionell ist der Kontextprozess auf der Grenze des Kontexts lokalisiert und wirkt als Tor in denselben.
Die Prozesse innerhalb des Kontexts 92 können auf beliebige Prozesse innerhalb des Kontexts 90 und 91 durch den Namen Bezug nehmen. Ausserdem können Prozesse in dem Kontext 91 nur auf Prozesse in dem Kontext 92 durch ein Hindurchlaufen durch den Kontextprozess C zugreifen. Prozesse im Kontext 90 können nur auf Prozesse in dem Kontext 92 durch Hindurchlaufen durch die Kontextprozesse B und C zugreifen.
Die Funktion der Kontextprozesse ist es, einlaufende Nachrichten zu filtern und sie entweder zurückzuweisen oder sie zu anderen Prozessen in ihrem Kontext umzuleiten. Kontexte können auch verschachtelt sein, wodurch ermöglicht wird, eine Hierarchie von Abstraktionen zu konstruieren. Ein Kontext muß vollständig innerhalb eines Knotens resident sein. Das gesamte System wird als ein allumfassender Kontext, der immer vorhanden ist und der das höchste Niveau in der Hierarchie ist, behandelt. Im wesentlichen definieren Kontexte lokalisierte Schutzdomänen und verringern die Chancen unerwünscht er Namenskonflikte erheblich.
Falls es angemessen ist, kann ein Prozess innerhalb eines Kontextes mit einem innerhalb eines anderen Kontextes durch Austausch der PIDs "verbunden werden", sobald der Kontakt durch einen oder den anderen der Kontextprozesse hergestellt worden ist. Die meisten Prozess-Server innerhalb der vorliegenden Erfindung funktionieren auf diese Weise. Der anfängliche Zugriff findet durch den Namen statt. Sobald die erwünschte Funktion (wie beispielsweise ein Window oder eine Datei) "geöffnet" ist, kommunizieren der Benutzerprozess und die Dienstleistung direkt über PIDs.
Eine "Nachricht" ist ein Puffer mit variabler Länge (lediglich durch die physikalische Speichergröße des Prozessors beschränkt), der Information zwischen den Prozessen trägt. Ein Header, auf den durch den Programmierer nicht zugegriffen werden kann, umfaßt den Zustellungsnamen und die PID des Senders. Durch Vereinbarung wird das erste Feld in einer Nachricht eine null-terminierte Kette, die den Typ der Nachricht (beispielsweise "Lesen", "Status", etc.) definiert. Die Nachrichten werden in eine Warteschlange zu dem empfangenden Prozess gereiht, wenn sie geschickt werden. Das Einreihen in eine Warteschlange stellt seriellen Zugriff sicher und wird Semaphoren, Monitoren, etc. vorgezogen.
Nachrichten schaffen den Mechanismus, durch den die Hardwaretransparenz erzielt wird. Ein Prozess, der irgendwo innerhalb der virtuellen Maschine lokalisiert ist, kann eine Nachricht an einen anderen Prozess schicken, wenn er dessen Namen kennt. Die Transparenz wird mit einigen Beschränkungen über Bridgeways (d. h., die Interfaces zwischen LANs, die unter identischen Netzwerkprotokollen arbeiten) und, im allgemeinen überhaupt über Gateways (d. h., die Interfaces zwischen LANs, die unter verschiedenen Netzwerkprotokollen arbeiten), aufgrund von Performancedegradierung angewendet. Allerdings könnten sie in Abhängigkeit von dem erwünschten Performancelevel so arbeiten.

Zwischenprozess-Kommunikation

Die gesamte Zwischenprozess-Kommunikation findet über Nachrichten statt. Konsequenterweise sind die meisten Basiseinheiten der virtuellen Maschine mit der Nachrichtenverarbeitung beschäftigt. Die Kernel-Basiseinheiten der virtuellen Maschine sind die folgenden:
ALLOC - fordert Zuteilung eines (Nachrichten) Puffers einer gegebenen Größe an.
FREE - fordert Freigabe eines gegebenen Nachrichtenpuffers an.
PUT - schickt eine Nachricht an eine gegebene Adresse (durch den Namen oder die PID).
GET - wartet auf und entnimmt die nächste einlaufende Nachricht, optionalerweise von einem bestimmten Prozess (durch die PID) aus der Warteschlange.
FORWARD - reicht eine empfangene Nachricht zu einem anderen Prozess durch.
CALL - sendet eine Nachricht, wartet dann auf die Antwort und entnimmt sie der Warteschlange.
REPLY - schickt eine Nachricht an den Erzeuger einer gegebenen Nachricht.
ANY_MSG - gibt "wahr" zurück, wenn die Empfangswarteschlange nicht leer ist, gibt ansonsten "falsch" zurück; überprüft optionalerweise, ob irgendeine Nachricht mit einer bestimmten PID in der Warteschlange ist.
Um die Funktion der Kernel-Basiseinheiten weiter zu beschreiben, bearbeitet ALLOC alle Speicherzuteilungen. Es gibt einen Pointer an einen Puffer zurück, der zur Lokalspeicherung innerhalb des Prozesses verwendet werden kann oder der zu einem anderen Prozess (über PUT, etc.) geschickt werden kann. ALLOC führt niemals zu einem "Fehler", sondern wartet bis genügend Speicher frei ist, um die Anforderung zu erfüllen.
Die PUT-Basiseinheit gibt eine Nachricht in die Warteschlange eines anderen Prozesses. Der Sendeprozess beendet die Ausführung sobald die Nachricht in der Warteschlange ist.
FORWARD wird verwendet, um eine Nachricht schnell umzuleiten, aber die Information über den ursprünglichen Sender zu behalten (wohingegen PUT immer den Sendeprozess zu dem Erzeuger der Nachricht macht).
REPLY schickt eine Nachricht an den Erzeuger einer vorher erhaltenen Nachricht anstelle von dem Namen oder der PID.
CALL implementiert im wesentlichen ferne Unterprogrammaufrufe, wodurch bewirkt wird, daß der Aufrufer ausgesetzt wird, bis der Empfänger ein REPLY ausführt. Nachfolgend wird die beantwortete Nachricht unmittelbar auf ihre Ankunft hin aus der Warteschlangensequenz genommen und der Aufrufer fährt mit der Ausführung fort.
Die Betonung liegt auf der Gleichzeitigkeit, so daß soviel Prozesse wie möglich parallel ausgeführt werden. Daher wartet weder PUT noch FORWARD auf die Auslieferung der Nachricht. Umgekehrt setzt GET einen Prozess aus, bis eine Nachricht eintrifft und nimmt sie in einer Operation aus der Warteschlange. Die ANY_MSG-Basiseinheit wird zur Verfügung gestellt, so daß ein Prozess bestimmen kann, ob irgendetwas von Interesse in der Warteschlange ist bevor er sich selbst an ein GET überweist.
Wenn eine Nachricht durch den Namen verschickt wird, muß der Bestimmungsprozess in dem Namensraum gefunden werden. Der Suchpfad wird durch die Verschachtelung des Kontext bestimmt, in dem der Sendeprozess resident ist. Von einem gegebenen Prozess kann eine Nachricht an alle Prozesse in seinem eigenen Kontext oder (optionalerweise) an die in irgendeinem höheren Kontext verschickt werden. Es wird auf Fig. 5 Bezug genommen. Die Kontexte werden von dem momentanen Kontext in Aufwärtsrichtung durchsucht, bis eine Übereinstimmung gefunden oder bis der Systemkontext erreicht ist. In die Warteschlangen aller Prozesse mit demselben Namen in diesem Kontext wird dann eine Kopie der Nachricht eingereiht.
Unter Bezugnahme auf Fig. 5 wird beispielsweise angenommen, daß in dem Kontext 141 ein Prozess y eine Nachricht an alle Prozesse mit dem Namen x sendet. Der Prozess y sucht zuerst innerhalb des eigenen Kontext 141, findet aber keinen Prozess x. Der Prozess y sucht dann innerhalb des nächsten höheren Kontexts 131 (seinem Stammkontext), findet allerdings wiederum keinen Prozess x. Dann beginnt der Prozess y innerhalb des nächst höheren Kontext 110 zu suchen und findet einen Prozess ,x, der durch das Bezugszeichen 112 bezeichnet ist. Da er der einzige Prozess x in dem Kontext 110 ist, ist er der einzige Empfänger der Nachricht von dem Prozess y.
Wenn ein Prozess a in dem Kontext 131 eine Nachricht an ALL- Prozesse durch den Namen x schickt, sucht er zuerst innerhalb des eigenen Kontext 131 und, da er dort keinen Prozess x findet, sucht er dann innerhalb des Kontextes 110 und findet den Prozess x.
Es wird angenommen, daß ein Prozess b in dem Kontext 131 eine Nachricht an ALL-Prozesse mit dem Namen A schickt. Er würde einen Prozess A (111) in dem Kontext 110, sowie einen Prozess A (122), welcher der Kontextprozess für den Kontext 121 ist, finden.
Ein Prozess kann auch eine Nachricht an sich selbst senden oder an seinen Kontextprozess ohne irgendeinen Namen explizit zu wissen.
Das Konzept eines "logischen Rings" (analog zu LAN) erlaubt es, daß eine Nachricht zu dem NEXT-Prozess in dem System mit einem gegebenen Namen geschickt wird. Die Nachricht geht genau zu einem Prozess in dem Kontext des Senders, falls ein derartiger Prozess existiert. Andernfalls wird der Stammkontext durchsucht.
Die virtuelle Maschine garantiert, daß jede NEXT-Übertragung einen verschiedenen Prozess erreicht und daß u. U. eine Übertragung zu dem logisch "ersten" Prozess (demjenigen, der die Originalnachricht gesendet hat) in der Schleife gesendet wird, wobei die Schleife komplettiert wird. Anders ausgedrückt, können alle Prozesse mit demselben Namen auf dem gleichen Level miteinander kommunizieren, ohne zu wissen, wie viele es von ihnen gibt oder wo sie lokalisiert sind. Der logische Ring ist wesentlich für eine verteilende Dienstleistung, wie beispielsweise eine Datenbank. Die Reihenfolge der Prozesse in dem Ring ist nicht vorhersehbar.
Wenn beispielsweise ein Prozess a (125) in dem Kontext 121 eine Nachricht an einen Prozess a unter Verwendung der NEXT- Basiseinheit sendet, findet die Suche einen ersten Prozess a (124) in demselben Kontext 121. Der Prozess a (124) wird so markiert, daß er die Nachricht empfangen hat, und dann sendet der Prozess a (124) die Nachricht an den NEXT-Prozess a (123) in dem Kontext 121. Der Prozess a (123) wird so markiert, daß er die Nachricht empfangen hat, und dann sendet er die Nachricht an den NEXT-Prozess a, welcher der ursprüngliche Senderprozess a (125) ist, der weiß, daß er diesen nicht weiterschickt, da er so markiert worden ist, daß er die Nachricht bereits empfangen hat.
Das Senden von Nachrichten direkt durch die PID vermeidet das Erfordernis einer Namenssuche und ignoriert Kontextgrenzen. Dies ist als DIRECT-Übertragungsmodus bekannt und ist am effizientesten. Beispielsweise sendet der Prozess A (111) eine Nachricht im DIRECT-Modus an den Prozess y in dem Kontext 141.
Wenn ein Prozess eine Nachricht im LOCAL-Übertragungsmodus sendet, sendet es diesen nur zu einem Prozess, der den gegebenen Namen in dem eigenen Kontext des Senders hat.
Zusammenfassend gibt es einschließlich des DIRECT- Übertragungsmodus fünf Übertragungsmodi, die mit PUT, FORWARD, und CALL-Basiseinheiten verwendet werden können:
ALL - an alle Prozesse mit dem gegebenen Namen in dem ersten Kontext, der diesen Namen enthält, wobei mit dem Kontext des Senders begonnen wird und aufwärts durch alle Stammkontexte gesucht wird.
LOCAL - nur an alle Prozesse mit dem Namen in dem Kontext des Senders.
NEXT - an den nächsten Prozess mit dem gegebenen Namen in demselben Kontext wie der Sender, falls überhaupt; andernfalls sucht er aufwärts durch alle Stammkontexte, bis der Name gefunden worden ist.
LEVEL - sendet zu "sich selbst" (dem Senderprozess) oder zum "Kontext" (dem Kontextprozess, der dem Kontext des Senders entspricht); "selbst" kann nicht mit der CALL-Basiseinheit verwendet werden.
DIRECT - gesendet mit der PID.
Nachrichten werden herkömmlicherweise durch Einreihen eines Pointers in eine Warteschlange des Puffers, der die Nachricht enthält, übertragen. Eine Nachricht wird nur kopiert, wenn es mehrere Bestimmungsorte gibt oder wenn der Bestimmungsort ein anderer Knoten ist.

Betriebssystem

Das Betriebssystem der vorliegenden Erfindung besteht aus einem Kernel, der die oben beschriebenen Basiseinheiten implementiert, plus einem Satz von Prozessen, die eine Prozesserzeugung und Beendigung schaffen, einem Zeitmanagement (setzen der Zeit, setzen eines Alarms, etc.), und der ein Hochfahren und Konfigurieren des Knotens durchführt. Ausserdem sind Treiber für Einrichtungen implementiert als Prozesse (EESPs), wie oben beschrieben. Dies ermöglicht es, daß sowohl Systemdienstleistungen und Gerätetreiber leicht hinzugefügt und ersetzt werden. Das Betriebssystem unterstützt auch ein Swapping und Paging, obwohl beide für die Anwendersoftware unsichtbar sind.
Anders als bekannte verteilte Computersysteme verwendet das in der vorliegenden Erfindung nicht einen distinkten "Namensserver"-Prozess, um die Namen aufzulösen. Die Namenssuche ist auf den Kernel beschränkt, der den Vorteil hat, daß er viel schneller ist.
Ein minimales Bootstrap-Programm (Urladerprogramm) ist permanent (im ROM) auf jedem Knoten resident, beispielsweise im ROM 28 in dem Knoten N von Fig. 2. Das Bootstrap-Programm läuft automatisch, wenn ein Knoten angeschaltet wird, ab und führt grundlegende Diagnostik auf der Platine durch. Es versucht dann, ein Initialisierungssystem-Codemodul zu finden und zu starten. Das Modul wird auf dem ersten Disklaufwerk auf dem Knoten, wenn überhaupt, gesucht. Falls keine Disk vorhanden ist und der Knoten auf dem LAN ist, wird eine Nachricht geschickt, die das Modul anfordert. Falls dies fehlschlägt, muß die benötigte Software in dem ROM resident sein. Das Initialisierungsprogramm des Kernels führt einen Set-up aller Kernel- Tabellen durch und ruft dann einen vordefinierten Eintrittspunkt des Prozesses auf.
Im allgemeinen exisitiert eine Schablonendatei, die die Anfangssoftware und Hardware für jeden Knoten in dem System beschreibt. Die Schablone definiert einen Satz anfänglicher Prozesse (im allgemeinen einen pro Dienstleistung), die sofort nach dem Hochfahren des Knotens zeitlich organisiert werden. Diese Prozesse fahren dann ihre entsprechenden Untersysteme hoch. Eine Knotenkonfigurationswartung auf jedem Knoten schickt Konfigurationsnachrichten an jedes Untersystem, wenn begonnen wird, es zu initialisieren, wobei es die Einrichtungen über seine eigene informiert. Danach werden ähnliche Nachrichten immer dann gesendet, wenn ein neues Gerät zu dem Knoten hinzugefügt wird oder wenn ein Gerät ausfällt oder von dem Knoten entfernt wird.
Somit gibt es keine wohl definierte Bedeutung für "System up" oder "System down" - solange irgendein Knoten aktiv ist, kann das System als Ganzes als "up" angesehen werden. Knoten können abgeschaltet werden oder dynamisch hochgefahren werden ohne andere Knoten in dem Netzwerk zu beeinflussen. Das selbe Prinzip gilt auch, in beschränktem Umfang, für Peripherie- Einrichtungen. Geräte, die sich selbst in Bezug auf Typ, Modellnummer, etc. identifizieren können, können ohne Eingriff des Betreibenden hinzugefügt oder entfernt werden.

Standard Nachrichtenformat

Fig. 7 stellt das Standardformat einer Nachricht in dem verteilten Datenverarbeitungssystems von dem hierin beschriebenen Typ dar. Das Nachrichtenformat umfaßt einen Nachrichten-I.D.- Abschnitt 288, einen oder mehrere "Triples" 289 und 290 und einen Nachrichtenende-Abschnitt 292. Jedes "Triple" umfaßt eine Gruppe von drei Feldern, wie beispielsweise die Felder 293- 295. Das erste Feld 293 des ersten Triples 289 spezifiziert, daß ein Prozesserzeugungstrap (CRTR) gesetzt werden soll.
In dem zweiten Triple 290 spezifiziert das erste Feld 296, daß das Datenfeld den Namen des Prozesses, auf den eingewirkt werden soll, beispielsweise des Prozesses, dessen Erzeugung getrapt werden soll, darstellt. Das zweite Feld 297 gibt die Größe des Datenfelds. Das dritte Feld 298 ist das Datenfeld. Eine Nachricht kann eine beliebige Zahl von "Triplen" haben.
Wie derzeitig implementiert, hat der Abschnitt 288 eine Länge von 16 Byte, das Feld 296 ist 4 Byte, das Feld 297 ist 4 Byte, das Feld 298 ist variabel in der Länge und der EOM-Abschnitt 160 ist 4 Byte.
Wie in Fig. 7 gezeigt, beschreibt der Nachrichten-I.D.- Abschnitt 288 einen "SET"-Befehl und das Feld 298 bezeichnet einen Prozess. Wenn die Nachricht durch den Anfrageprozess an einen Prozessmanagerprozess geschickt wird, ist der Nachrichtenabschnitt 291 leer, wenn allerdings die Nachricht an den anfragenden Prozess durch den PMP zurückgegeben wird, enthält der Nachrichtenabschnitt 290 den Prozess-"Connector". Der Prozessconnector identifiziert den bezeichneten Prozess durch die Prozessor-Identifizierungsnummer (PID) und seinen Prozesskanal und bildet die Verbindung zwischen dem bezeichneten Prozess und dem anfragenden Prozess. Die Prozessorconnectoren werden in größerem Detail in der oben angegebenen Erfindung Nummer 11 beschrieben.

Ressource/Connector Model

Das verteilte System der vorliegenden Erfindung kann auf mehreren Komplexitätslevels betrachtet werden. Das Basislevel ist die virtuelle Maschine, die die Geräte unabhängiger Architektur definiert und implementiert, welche aus virtuellen "Befehlen", d. h. den Kernelbasiseinheiten besteht.
Unmittelbar über diese geschichtet und mit dieser eng verbunden ist das Prozess/Nachrichtenmodell, das definiert, wie Programme in dem System konfiguriert werden und wie sie miteinander kommunizieren.
Genau über dieser Stufe ist ein abstrakteres Modell, das "Ressourcen" und "Connectoren" behandelt. Wie vorher erwähnt, können Ressourcen als "logische Einrichtung" angesehen werden. Auf Ressourcen wird durch "Connectoren", die im wesentlichen logische "Pointer" sind, zugegriffen.
Eine Anwendung muß einen Connector zu einer Ressource haben, um mit ihr wechselzuwirken. Connectoren werden durch "Ressourcemanagerprozesse", d. h. Prozesse, die anfordern können, daß Ressourcen erzeugt, gelöscht etc. werden, zugeteilt und gesteuert.
Ressourcemanagerprozesse antworten auf Connector-Nachrichten, so daß neue Ressourcen "erzeugt" werden und alte "gelöscht" werden, und daß eine existierende Ressource "geöffnet" wird (d. h. nach einer Verbindung zu dieser gefragt wird) und daß später diese "geschlossen" wird (die Verbindung zu ihr beendet wird).
Die Antwort auf die Erzeugung einer Ressource oder das Öffnen einer Verbindung zu ihr ist eine Verbindungsnachricht. Diese Nachricht enthält eine wartungsunabhängige Connector- Datenstruktur, welche die Ressource eindeutig definiert.
Eine Anwendung kann eine neue Ressource erzeugen oder den Zugriff zu einer existierenden dadurch zu erfassen, daß eine Anfrage an den geeigneten Ressourcemanagerprozess gestellt wird. (Es ist zu bemerken, daß alle Ressourcen durch den Ressourcemanagerprozess weiter kontrolliert und geschützt werden und sie in seinem Kontext gehalten werden). Als Ergebnis wird ein Connector zu der Ressource an die Anwendung zurückgegeben, wobei erlaubt wird, daß er direkt mit der Ressource kommuniziert. Es ist anzumerken, daß im allgemeinen zwei Connectoren erforderlich sind - einer für den Ressourcemanagerprozess und einer für die Ressource (obwohl in vielen Fällen durch einen Namen auf den Ressourcemanagerprozess zugegriffen werden kann).
Wenn ein Connector in einer Nachricht empfangen wird, identifiziert er eine bestimmte Ressource, zu welcher der empfangende Prozess Zugriff hat. Der gesamte Connector muß in die nachfolgenden Anforderungsnachrichten an die Ressource kopiert werden. Die Nachrichten selbst werden herkömmlicherweise im "Direct"-Modus gesendet, wobei die Adresse des Connectors übergeben wird. Wie oben erwähnt, können Nachrichten an den Manager der Ressource durch den Namen gesendet werden, falls dies geeignet ist, oder über einen expliziten Connector (zu dem Manager), falls dieser vorhanden ist.
Sowohl "Erzeugungs"- als auch "Öffnungs"-Anfragen an den Ressourcemanagerprozess erwarten gewöhnlicherweise einen Prozessnamen als Parameter, und beide geben eine Verbindungsnachricht zurück. Eine "Erzeugungs"-Anfrage ohne einen Namen bewirkt, daß die Dienstleistung einen eindeutigen Namen erzeugt. Eine "Öffnungs"-Anfrage unter Verwendung eines Connectors anstelle eines Namens kann verwendet werden, um auf die Ressource in verschiedener Weise zuzugreifen oder einen Zugriff auf eine nah benachbarte Ressource zu bekommen. Die "Lösch"- und "Schließ"-Anfragen können entweder einen expliziten Connector zu der Ressource oder den Ressourcennamen akzeptieren.
Es gibt fünf Formate für Verbindungsnachrichten: "Erzeugen", das die Erzeugung einer neuen Ressource anfordert; "Öffnen", das eine Verbindung zu einer existierenden Ressource herstellt; "Löschen", das anfordert, daß eine spezifizierte Ressource von dem System entfernt wird; "Schließen", das anfordert, daß die Verbindung zu einer Ressource beendet wird; und "Verbinden", das eine Verbindung zu einer Ressource schafft. Die "Verbinden" -Nachricht stellt normalerweise eine Antwort auf eine "Erzeugen"- oder "Öffnen" -Anforderung und wird im allgemeinen nicht unangefordert gesendet.
Datenaustausch-Nachrichten sind ein anderer Typ von Nachrichten, die in dem verteilten System der vorliegenden Erfindung verwendet werden. Daten in irgendeinem Format werden allein mittels der "Schreiben"-Nachricht gesendet. Daten werden durch die "Lesen"-Nachricht angefordert, zu der "Schreiben" oder "Fehler" die einzigen Antworten sind.
Prozesse, die nur Daten erzeugen, sollten mit "Fehler" auf "Schreiben"-Anfragen antworten. Umgekehrt sollte eine Ressource, die nur schreibt, "keine Daten" (d. h. eine "Schreiben"- Nachricht ohne ein Daten-"Triple") zurückgeben, falls sie eine "Lesen"-Anforderung empfängt.
Es gibt zwei Formate für Datenaustausch: "Schreiben", das zum Senden von Daten verwendet wird; und "Lesen", das zum Anfordern von Daten verwendet wird. Eine "Schreiben"-Nachricht umfaßt die Quelle der Daten, die Bestimmungsressource, den Urheber der Daten, den Typ der Daten (falls bekannt), und sie enthält einen Block von Daten. Eine "Lesen"-Nachricht umfaßt die Bestimmungsressource, einen optionalen Promptstring (der genau geschrieben werden muß bevor irgendwelche Daten geschrieben werden) und einen Schutzparameter, der anzeigt, daß die Eingabe, falls möglich, geschützt werden soll.
Geeignete Statusnachrichten werden verwendet, um den Beendigungsstatus einer Anforderung oder den derzeitigen Status einer Dienstleistung oder Ressource zu befördern. In dem letzteren Fall kann die Statusnachricht explizit angefordert werden oder kann als Ergebnis eines synchronen Ereignisses bzw. Events innerhalb der Ressource selbst gesendet werden.
Es gibt vier Formate für Statusnachrichten: "Anfragen", das nach dem momentanen Status einer Ressource frage; "durchgeführt", das andeutet, daß eine vorherige Anfrage erfolgreich beendet worden ist; "Fehler", das anzeigt, daß eine vorherige Anforderung nicht beendet worden ist; und "Status", das den Status einer Ressource entweder als Antwort auf "Anfrage" oder als Ergebnis einer asynchronen Bedingung gibt.

DETAILLIERTE BESCHREIBUNG DER ERFINDUNG

Fig. 8 zeigt, wie Prozesserzeugungstrap-(PCT-)Nachrichten und Prozessbeendigungstrap- (PTT-)Nachrichten zwischen dem Prozessmanagerprozess (PMP) in einem verteilten Datenverarbeitungssystem des Typs, der die vorliegende Erfindung umfaßt, gesendet werden. Ein Prozessmanagerprozess exisitiert auf den meisten Basisstufen des Betriebssystems, d. h. dem Kernel. Es ist der einzige Prozess, der Prozesse erzeugen und beenden kann. Es ist genau ein Prozessmanagerprozess in jedem Knoten des Systems, wie beispielsweise in dem Knoten 152-154, die in Fig. 8 gezeigt sind.
Jeder Prozess, wie beispielsweise der Prozess " " auf dem Knoten 152, kann eine Prozesserzeugungstrap-(PCT-) Anfragenachricht oder eine Prozessbeendigungstrap-(PTT-) Anforderungsnachricht an den Prozessmanagerprozess (PMP), der auf seinem eigenen Knoten resident ist, senden. Falls die Trapanforderung sich auf einen Prozess bezieht, der auf anderen Knoten erzeugt oder beendet werden soll, gibt der PMP des Hauptknotens die Anforderung an den PMP des anderen oder aller anderen Knoten weiter oder überträgt ihn.
Die Anforderung zur Benachrichtigung kann spezifisch für einen Knoten, mehrere Knoten oder das gesamte System gemacht werden. Andererseits kann sie auf einen Kontext beschränkt werden. Der Anforderungsprozess kann irgendwo in dem System lokalisiert sein.
Eine Anforderung wird nicht zu irgendeinem anderen Knoten weitergegeben oder übermittelt, wenn der Anforderungsprozess explizit auf den Gültigkeitsbereich der Anforderung zu dem lokalen Knoten beschränkt ist; falls er auf den Gültigkeitsbereich der Anforderung zu einem Kontext von Prozessen, die bezüglich des Hauptknotens lokal sind, beschränkt ist; oder falls die Anforderung explizit einen Prozess identifiziert, der getrapt werden soll, der auf dem lokalen Knoten existiert. Beispielsweise wird die PTT-Anforderung "m1" zu dem Trap-Prozess "x", der auf demselben Knoten existiert, durch den PMP auf dem Hauptknoten 152 gehalten.
Eine Trapanforderung wird zu einem anderen Knoten weitergegeben, falls der anfordernde Prozess explizit den Gültigkeitsbereich der Anforderung auf den eines anderen Knotens beschränkt; falls er den Gültigkeitsbereich der Anforderung auf einen Kontext eines Prozesses, der lokal zu dem anderen Knoten ist, beschränkt; oder falls die Anforderung explizit einen Prozess identifiziert, der getrapt werden soll, der auf diesem anderen Knoten existiert. Beispielsweise wird die PCT- Anforderung "m2" zur Traperzeugung von Prozessen in dem Kontext des "z"-Prozesses, der auf dem Knoten 153 existiert, an den PMP dieses Knotens weitergegeben und er wird nicht auf dem lokalen Knoten gehalten.
Eine Trapanforderung wird an alle Knoten übermittelt, wenn der anfordernde Prozess nicht auf den Gültigkeitsbereich der Anforderung beschränkt ist und er nicht irgendeinen spezifischen existierenden Prozess identifiziert oder wenn er den Gültigkeitsbereich der Anforderung auf einen Kontext von Prozessen, die alle Knoten auf dem Netzwerk aufspannen, beschränkt. Eine Trapanforderung, die zu allen Knoten übertragen wird, wird ausserdem auf dem Hauptknoten gespeichert. Beispielsweise wird die PCT-Anforderung "m3" zur Traperzeugung von Prozessen mit dem Namen von "foo" unabhängig von seinem Ort in dem Netzwerk zu beiden Knoten 153 und 154 übertragen, sowie zusätzlich auf dem Knoten 152 gehalten.
Die Prozesserzeugungstrap- oder Prozessbeendigungstrapanforderung spezifiziert, daß ein empfangender Prozessmanagerprozess dem anfordernden Prozess y mitteilt, wann immer ein bezeichneter Prozess auf den Knoten 152, 153 oder 154 erzeugt oder beendet wird.
Wenn ein Prozess mit dem Namen, der in dem Prozesserzeugungstrap bezeichnet ist, erzeugt wird, antwortet der Prozessmanagerprozess, der die Erzeugungstrapanforderung empfangen hat, dann dem Prozess oder den Prozessen, der oder die ein Setzen des Prozesserzeugungstraps angefordert haben und das Trap wird aufgelöst. Dies wird als "Auflösung" eines Prozesserzeugungstraps bezeichnet.
Auf gleiche Weise antwortet der Prozessmanagerprozess, der für die Beendigung eines derartigen Prozesses verantwortlich ist, wenn ein Prozess, der in dem Prozessbeendigungstrap identifiziert war, dann dem Prozess oder den Prozessen, der oder die angefordert haben, daß das Prozessbeendigungstrap gesetzt wird, und das Trap wird aufgelöst. Dies wird als "Auflösung" eines Prozessbeendigungstraps bezeichnet.
Fig. 9 zeigt ein verteiltes Datenverarbeitungssystem, das ein Netzwerk 171 mit Knoten 172 und 173 umfaßt, von denen jeder einen Prozessmanagerprozess (PMP) hat. Auf dem Knoten 172 wünschen Benutzerprozesse a und b, daß sie informiert werden, falls und wenn ein Prozess x erzeugt wird, somit senden sie Prozesserzeugungstrap-Anfragenachrichten an den Prozessmanagerprozess auf den Knoten 172. Wenn der Prozess x nachfolgend erzeugt wird, durch welchen Prozess in dem System und für welchen Grund auch immer, benachrichtigt der Prozessmanagerprozess auf dem Knoten 172 beide Prozesse a und b von der Tatsache.
Es ist nützlich für Anwenderprozesse, zu wissen, wo sie verschiedene Wartungsprozesse, die erzeugt worden sind, beispielsweise einen Fast-Fourier-Analysenprozess, einen Event- Log-Service-Process (siehe Fig. 11), etc. finden.
In Bezug auf andere Merkmale der Erfindung können verschiedene andere Aktionen spezifiziert werden, die das Setzen oder Freigeben von Prozesserzeugungstraps oder Prozessbeendigungstraps betreffen, oder getrapte Prozesse betreffen. Beispielsweise können Prozesserzeugungstrapanforderungen von der momentanen Existenz von Prozessen mit den bezeichneten Namen abhängig gemacht werden. Ebenso können Prozesstrapanforderungen spezifizieren, daß aufgelöste Traps automatisch wieder in Stand gesetzt werden. In diesem Fall ist ein beantwortetes Trap nicht aufgelöst.
Zusätzlich kann eine Prozesserzeugungstrapanforderung spezifizieren, daß getrapte Prozesse ausgesetzt werden sollen bis eine derartige Aussetzung aufgelöst wird. Der Anforderungsprozess kann auch das Entfernen eines Prozesstraps, das innerhalb einer Zeitdauer unaufgelöst gewesen ist, anfordern oder er kann ein derartiges Entfernen bedingungslos anfordern. Weiter kann der Anforderungsprozess anfordern, daß Information, die den erzeugten/beendeten Prozess betrifft, zusätzlich zu dessen Namen an den anfordernden Prozess auf eine Auflösung des Prozesstraps hin zurückgegeben werden soll.
Ein Prozesserzeugungstrap kann oder kann nicht den Namen des Prozesses, dessen Erzeugung getrapt werden soll, spezifizieren. Falls der Prozessname nicht spezifiziert ist, wird ein Prozess, der in dem spezifizierten Gültigkeitsbereich erzeugt wurde, getrapt.
Falls der Gültigkeitsbereich einer Prozesserzeugungstrapanforderung das gesamte Netzwerk, wie beispielsweise das Netzwerk 151, ist, dann überträgt der Prozessmanagerprozess des anfordernden Knotens (beispielsweise des Knotens 152) die Trapanforderung auf Prozessmanagerprozess aller Knoten 152-154 des Netzwerks. Wenn der Prozesserzeugungstrap durch den Prozessmanagerprozess auf einem Knoten aufgelöst ist, und die Trapentfernung auf die Auflösung hin angefordert ist, wird die Trapauflösung an die Prozessmanagerprozesse aller Knoten berichtet. Ein entfernt aufgelöstes Prozesserzeugungstrap wird immer durch den Prozessmanagerprozess auf dem anfragenden Knoten beantwortet, um Zeitbedingungen zu eliminieren, die im Fall gleichzeitiger Trapauflösung auftreten können.
Fig. 10 zeigt ein verteiltes Datenverarbeitungssystem, wobei dargestellt ist, wie der Prozessmanagerprozess benachrichtigt wird, wenn ein Prozesserzeugungstrap auf einem entfernten Knoten aufgelöst wird. Ein Netzwerk 181 umfaßt Knoten 182, 185, 187 und 189, wobei jeder einen Prozessmanagerprozess (PMP) hat. Jeder Knoten hat auch eine assoziierte Liste von Traps 183, 186, 188 und 190. Zu jedem Zeitpunkt, zu dem ein solcher Knoten ein PCT mit einem Prozessnamen empfängt, addiert er zu der Liste der Traps den Namen des Prozesses, dessen Erzeugung berichtet werden soll.
Es wird angenommen, daß ein auf dem Knoten 187 lokalisierter Prozess eine Prozesserzeugungstrapanforderung für ein Prozess x überträgt. Jeder der Knoten fügt dann den Prozess x zu seiner assoziierten Liste von Traps hinzu. Es wird weiter angenommen, daß der Prozess x nachfolgend auf dem Knoten 182 erzeugt wird. Dann wird der Prozessmanagerprozess auf dem Knoten 182 Prozess x von seiner Trapliste löschen und den Prozess x zu seiner Prozessliste 184 hinzufügen. Der PMP des Knotens 182 benachrichtigt als nächstes den PMP des Knotens 187, daß der Prozess x erzeugt wurde. Dann benachrichtigt der PMP des Knotens 187 die anderen PMPs des Netzwerks (d. h. auf den Knoten 185 und 189), daß der Prozess x erzeugt wurde.
Falls der in einem Prozessbeendigungstrap spezifizierte Prozess nicht auf dem anfordernden Knoten lokalisiert werden kann, wird die Anforderung zu dem Prozessmanagerprozess des nächsten Knotens weitergeleitet. Es wird in dem Ring der Prozessmanagerprozesse weitergeleitet, bis der Prozess gefunden ist. Ein aufgelöstes Prozessbeendigungstrap wird immer direkt von dem Knoten der Auflösung an den Prozess, der das Prozessbeendigungstrap angefordert hat, unabhängig von seinem Ort in dem Netzwerk, beantwortet.
Die vorliegende Erfindung hat einen signifikanten Nutzen in vieler Hinsicht, insbesondere in dem verteilten hierin offenbarten Prozess/Nachrichtensystem. Eine Anzahl von Modulen des Betriebssystems verlassen sich auf die Benachrichtigung der Prozesserzeugungen und -beendigungen - beispielsweise das Konfigurationsmanagement, das Fehlermanagement, die Debugwartung, Performance-Monitor, Prozessverzeichnisse und Systemstatistikreporter.
Prozesserzeugungs- und Beendigungstrap-Nachrichten schaffen eine Möglichkeit, das Prozessmanagement von diesen Modulen in Laufzeit zu linken. Die Prozesstrap-Nachrichten verringern auch die Abhängigkeit dieser Module von den Prozessbeschreibungs-Darstellungsdetails.
In einem herkömmlichen Betriebssystem werden Ressourcen (beispielsweise Dateien), die durch Prozesse zugeteilt werden, in den Prozessbeschreibungs-Datenstrukturen aufgezeichnet. Die Auflösung von Ressourcen, die durch beendete Prozesse zugeteilt werden, müssen explizit durch einen Prozessbeendigungsalgorithmus initiiert werden. Deshalb müssen Änderungen in der Konfiguration der systemweit unterstützten Ressourcetypen dem Prozessbeschreibungs-Datenstrukturen und in dem Prozessbeendigungsalgorithmus widergespiegelt werden.
In der vorliegenden Erfindung wird durch Anforderung eines Prozessbeendigungstraps bei jeder Ressourcezuteilung für einen Prozess, der Ressourcemanager benachrichtigt, wenn der zugeteilte Prozess endet, und die Ressourcefreigabe kann durch den Ressourcemanager selbst initiiert werden. Ein Addieren von neuen Typen von Ressourcemanagern zu dem System ändert die Prozessbeschreibungs-Datenstruktur oder den Prozessbeendigungsalgorithmus.
Beispielsweise ist es normalerweise wichtig, wenn ein Prozess beendet wird, weil er einen Fehler aufweist oder weil er abgeschlossen ist, alle Ressourcen freizugeben, die einem solchen Prozess zugeteilt worden sind.
Auch in Multiprozess-Systemen können verschiedene Funktionen auf die Erzeugung eines Prozesses hin aufgerufen werden. Prozesserzeugungstraps liefern einen einfachen, effizienten und konfigurierbaren Weg, eine Steuerung zwischen Funktionen und synchronisierenden Funktionen weiterzugeben.
Fig. 11 zeigt, wie die vorliegende Erfindung verwendet werden kann, um das Fehlermanagement in einem verteilten Datenverarbeitungssystem zu erleichtern. In dem Netzwerk 161 kann jeder Knoten 162-164 eine oder mehrere Ressourcen (nicht gezeigt), die mit ihm assoziiert sind, aufweisen. Für einen Fehlermanagementprozess (EMP) ist es wünschenswert, auf einen Event-Log- Service-Prozess (ELSP) auf irgendeinem Knoten zuzugreifen, um verschiedene mit derartigen Knotenressourcen assoziierte Events anzumelden. Wenn ein ELSP zuerst, beispielsweise auf Knoten 154 erzeugt wird, können einer oder mehrere Fehlermanagementprozesse in dem Netzwerk benachrichtigt werden, so daß einem derartigen Fehlermanagementprozess der Ort des ELSP in dem System bekannt wird, so daß das ELSP gewählt werden kann, ihm Befehle gegeben werden können, etc.
Andererseits, falls auf kein ELSP zugegriffen werden kann, muß der Fehlermanagementprozess Wartungen auf niedrigerem Niveau verwenden, um Ereignisse in einfacherer Form anzumelden; diese sind auf jedem Knoten verfügbar.

BESCHREIBUNG DES PROGRAMMS

Eine Ausführungsform der Erfindung besteht aus einer "C"- Sprachenimplementation der Konzepte, die die hierin beschriebenen Prozesstraps betreffen. Diese Konzepte sind in Flußdiagrammform durch die Fig. 12A-12H zur Annehmlichkeit für den Leser dargestellt.
Fig. 12A zeigt ein Flußdiagramm, das eine Operation durch einen Prozessmanagerprozess (PMP) zum Setzen eines Prozesserzeugungstraps darstellt. In dem Entscheidungsblock 200 wird die Routine beendet, falls der PMP seine eigene Übertragung empfängt; falls nicht, geht sie zu dem Entscheidungsblock 201 weiter. Wenn die Trapanforderung in dem Entscheidungsblock 201 korrekt ist, geht die Routine zu Block 203 weiter; falls nicht, geht die Routine zu Block 202 um eine Benachrichtigung einer fehlerhaften Anforderung zu erzeugen.
In dem Entscheidungsblock 203 wird die Anforderung überprüft, ob sie einen korrekten lokalen Gültigkeitsbereich für den Knoten hat; falls ja, wird in Block 204 eine Erzeugungstrap- Datenstruktur zugeteilt und initialisiert; andernfalls wird die Anfrage entweder an andere Knoten weitergeleitet oder zurückgewiesen.
In Block 205 wird die neue Trapdatenstruktur entweder in die Liste der unaufgelösten Erzeugungstraps für einen gegebenen Prozessnamen, die in einer Hash-Tabelle organisiert sind, eingesetzt, oder es wird in die Liste der unbezeichneten Prozesserzeugungstraps, die gemäß dem Gültigkeitsbereich des Traps gelinkt werden, eingesetzt.
Wenn dieses im Entscheidungsblock 206 ein an eine Bedingung geknüpftes Trap ist, geht die Routine als nächstes zu dem Entscheidungsblock 207; wenn nicht, fährt sie zu Entscheidungsblock 208 fort. Wenn der Prozess im Entscheidungsblock 207 bereits existiert, geht die Routine zu Block 212 weiter, wo das Erzeugungstrap aufgelöst wird; falls nicht, fährt sie zu Entscheidungsblock 208 fort.
In dem Entscheidungsblock 213 kann das aufgelöste, von einer Bedingung abhängige Trap, wenn es gehalten werden soll, an weitere Knoten übertragen werden; andernfalls endet die Routine.
Wenn in dem Entscheidungsblock 208 kein Knoten in dem Netzwerk ist, endet die Routine; andernfalls fährt sie zu Entscheidungsblock 209 fort. Wenn das Trap in Entscheidungsblock 209 von einem anderen Knoten übertragen wurde, endet die Routine; andernfalls fährt sie zu Entscheidungsblock 210 fort. Wenn in Entscheidungsblock 210 dieses Trap nicht auf den lokalen Knoten beschränkt ist, geht die Routine zu Block 211, wo das Trap an alle PMPs in dem Netzwerk übertragen wird; andernfalls endet die Routine.
Fig. 12B zeigt ein Flußdiagramm, das eine Operation zum Setzen eines Prozessbeendigungstraps darstellt. In dem Entscheidungsblock 220 überprüft sie, ob ein einzelner Prozess getrapt ist; falls ja, fährt sie fort, so daß in Block 221 überprüft wird, ob dies ein Prozess ist, der auf dem lokalen Knoten existiert. Falls nicht, überprüft sie in dem Entscheidungsblock 222, ob die Anfrage einen entfernten Prozess betrifft; falls ja, wird in Block 223 die Anforderung zu dem nächsten Knoten in dem Ring weitergeleitet; andernfalls endet die Routine, wobei die Anfrage zurückgewiesen wird.
Falls der lokale Prozess existiert, wird in Block 224 eine Beendigungstrap-Datenstruktur erzeugt; dann wird sie in Block 225 an den Prozess-Control-Block des spezifizierten Prozesses gelinkt.
Falls die Anforderung nicht einen einzelnen Prozess spezifiziert, wird in einem Entscheidungsblock 226 die Spezifikation eines Knotens oder einer Gruppe von Prozessen überprüft; falls diese ebenfalls nicht spezifiziert sind, wird die Anforderung in Block 227 zurückgewiesen.
Andernfalls wird im Entscheidungsblock 228 die Existenz des Gültigkeitsbereichs auf dem lokalen Knoten überprüft; falls sie existiert, wird das Beendigungstrap in die Liste der gültigen Beendigungstraps für diesen Knoten in dem Block 229 eingesetzt; andernfalls wird der Gültigkeitsbereich eines Fernziels gesucht, wobei von dem Entscheidungsblock 222 ähnlich zu den Einzelprozessbeendigungstrap-Anfragen begonnen wird.
Fig. 12C zeigt ein Flußdiagramm, das eine Operation zum Auflösen bzw. Freigeben eines Prozessbeendigungstrap darstellt. In dem Entscheidungsblock 230 endet die Routine, falls das Trap für den Beendigungsprozess nicht gesetzt ist; andernfalls geht sie zu Block 231, wo eine Antwort auf die Trapanforderungsnachricht erzeugt wird und das Trap aufgelöst wird. Nach Block 231 geht die Routine zu dem Entscheidungsblock 232 weiter. Wenn in dem Entscheidungsblock 232 für den Beendigungsprozess keine Traps gesetzt sind, geht die Routine zu Block 233 weiter, wo der Trap-Pointer in dem Prozess-Steuerblock gelöscht wird; falls nicht, kehrt die Routine zu Block 231 zurück.
Nachdem alle möglichen Beendigungstraps auf diesem einen spezifizierten Prozess aufgelöst worden sind, löst in Block 234 ein ähnlicher Algorithmus alle gültigen Traps auf, wo der Beendigungsprozess in den spezifizierten Gültigkeitsbereich fällt.
Fig. 12D zeigt ein Flußdiagramm, das eine Operation zur Auflösung eines Prozesserzeugungstraps darstellt. Falls in dem Entscheidungsblock 240 der erzeugte Prozess im Gültigkeitsbereich des lokalisierten Traps liegt, geht sie zu Block 241, um zu überprüfen ob das Trap gehalten werden soll; andernfalls geht sie zu Block 245, um zu überprüfen, ob es mehrere Traps gibt, um für denselben Prozessnamen oder Gültigkeitsbereich zu überprüfen.
Falls das Trap nicht gehalten werden soll, wird es in Block 242 beantwortet; andernfalls wird in Block 246 nur eine Benachrichtigung an den anfordernden Prozess gesendet. In den Blöcken 243 und 247 wird in beiden Fällen überprüft, ob das Trap an eine Bedingung geknüpft war; falls ja, wird die Datenstruktur des aufgelösten Traps entfernt.
Falls das Trap nicht an eine Bedingung geknüpft war und es nicht gehalten werden sollte, wird in Block 244 eine Erzeugungstrap-Entfernungsanforderung an alle Knoten des Netzwerks übertragen.
Falls keine Traps mit demselben Prozessnamen und auf einem einschließenden Gültigkeitsbereich gesetzt sind, werden die aufgelösten Datenstrukturen in Block 248 entfernt; andernfalls wird das nächste Trap in der Liste in Entscheidungsblock 240 überprüft.
Fig. 12E zeigt ein Flußdiagramm, das eine Operation zur Behandlung einer Erzeugungstrap-Auflösung von anderen Knoten darstellt. Falls in dem Entscheidungsblock 250 die Trap-Liste für den erzeugten Prozessnamen gefunden wird, geht die Routine zu Entscheidungsblock 251; falls nicht, fährt sie zu Block 256 fort, wo die Fernnachricht freigegeben wird.
Wenn im Entscheidungsblock 251 das Trap gesperrt ist, dann geht die Routine zu Block 256 weiter; falls nicht, fährt sie zu Entscheidungsblock 252 fort. Wenn in dem Entscheidungsblock 252 ein Trap mit einem übereinstimmenden Gültigkeitsbereich vorhanden ist, geht die Routine zu Block 253; andernfalls fährt sie zu Entscheidungsblock 255 fort. In Block 253 wird eine Antwort auf die Trapanforderung erzeugt, und die Routine läuft dann zu Block 254, wo eine Anforderung zum Entfernen des Traps übertragen wird. Nach Block 254 geht die Routine zu Block 256.
Wenn in Entscheidungsblock 255 mehr Traps auf denselben Prozessen gesetzt sind, kehrt die Routine zu Entscheidungsblock 252 zurück; falls nicht, läuft sie zu Block 256.
Fig. 12F zeigt ein Flußdiagramm, das eine Operation zum Löschen eines Prozesserzeugungstraps darstellt. Wenn in Entscheidungsblock 260 eine eigene Übertragung empfangen wird, endet die Routine; andernfalls wird in Entscheidungsblock 261 überprüft, ob in der Löschanforderung irgendein Gültigkeitsbereich spezifiziert ist. Falls ja, geht sie zum Entscheidungsblock 262, um zu überprüfen, ob der Gültigkeitsbereich zu einem fernen Knoten gehört; andernfalls läuft sie zu Block 265 weiter.
Falls ein Ferngültigkeitsbereich spezifiziert wurde, wird die Anforderung in Block 263 an den nächsten Knoten weitergegeben; andernfalls wird die Korrektheit des spezifizierten Gültigkeitsbereichs in Entscheidungsblock 264 überprüft: ob der gültige Prozess existiert und ob es ein Kontextprozess ist. Wenn der lokale Gültigkeitsbereich nicht korrekt ist, wird die Anforderung zurückgewiesen und die Routine endet; andernfalls fährt sie zu Block 265 fort.
In Block 265 wird ein Trap, das die Spezifikation der Löschanforderung füllt, gesucht, und in Block 266 wird überprüft, ob ein derartiges Trap gefunden wurde; falls nicht, fährt sie zu Block 272 fort; andernfalls wird in dem Entscheidungsblock 267 überprüft, ob das lokalisierte Trap einen spezifischen Prozessnamen enthält. Falls ja, werden in Block 270 alle Traps von der Hash-Liste der mit Namen versehenen Prozess-Traps entfernt, die denselben Prozessnamen und einen Gültigkeitsbereich spezifizieren, der den Gültigkeitsbereich, der in der Löschanforderung spezifiziert wurde, einschließt; falls nicht, werden in Block 271 alle Traps von der Liste der namenlosen Prozess- Traps, die einen einschließenden Gültigkeitsbereich spezifizieren, entfernt.
Falls keine Traps auf dem Knoten gefunden wurden oder wenn alle übereinstimmenden Traps entfernt worden sind, fährt die Routine zu Entscheidungsblock 272 fort, um zu überprüfen, ob die Löschanforderung übertragen werden muß. Falls ja, fährt sie zu Block 273 fort, um die Löschanforderung zu übertragen; andernfalls fährt sie direkt zu Block 272 fort, um die Löschanforderung zu beantworten, falls dies angefordert wurde, oder um die Anforderungsnachricht freizugeben.
Fig. 12G zeigt ein Flußdiagramm, das eine Operation darstellt, um zu überprüfen, ob ein Erzeugungstrap gesetzt ist. In Entscheidungsblock 280 wird eine Überprüfung durchgeführt, um zu sehen ob der Trap-Zähler auf Null gesetzt ist; falls ja, geht die Routine zu Block 281, um eine FALSCH-Anzeige zurückzugeben; falls nicht, geht sie zu Block 282, wo sie das erste Trap mit einem übereinstimmenden Namens-Hash findet, und fährt dann zu dem Entscheidungsblock 283 fort.
Falls der zu überprüfende Name in dem Entscheidungsblock 283 derselbe wie in dem Trap ist, und der erzeugte Prozess in dem Gültigkeitsbereich des Traps liegt, geht die Routine zu Block 284, wo das Trap gesperrt wird, und dann zu Block 285, um eine WAHR-Anzeige zurückzugeben; falls nicht, geht sie zu Entscheidungsblock 286. Wenn in dem Entscheidungsblock 286 mehr Traps mit übereinstimmendem Namens-Hash vorhanden sind, kehrt die Routine zu Entscheidungsblock 283 zurück; falls nicht, fährt sie zu Block 287 fort.
In Block 287 wird ein ähnlicher Algorithmus verwendet, um zu bestimmen, ob es irgendwelche namenlosen Erzeugungstraps gibt, die derart gesetzt sind, daß der neue Prozess in dem Gültigkeitsbereich des Traps liegt; falls ja, fährt die Routine zu Block 288 fort, um einen Booleschen FALSCH-Wert zurückzugeben, wobei angezeigt wird, daß kein aufzulösendes Erzeugungstrap gefunden worden ist.
Fig. 12H zeigt ein Flußdiagramm, das eine Operation zum Löschen eines Prozessbeendigungstraps darstellt. Wenn im Entscheidungsblock 290 ein Zielprozess bzw. Targetprozess spezifiziert ist, geht die Routine zu Entscheidungsblock 292; andernfalls geht sie zu Block 287, wo sie überprüft, ob ein Gültigkeitsbereich in der Trap-Löschanforderung spezifiziert ist. Wenn der Prozess in Entscheidungsblock 292 auf demselben Knoten erwartet wird, geht die Routine zu Entscheidungsblock 294; falls nicht, geht sie zu Block 293, wo das Beendigungstrap in dem logischen Ring weitergegeben und beendet wird.
Falls in dem Entscheidungsblock 294 der Targetprozess existiert und das Trap gesetzt ist, geht die Routine zu Block 295, wo alle gesetzten Traps durch den Löschprozess entfernt werden, und sie geht dann zu Block 296, wo eine Antwort, wenn sie angefordert worden ist, erzeugt wird. Wenn die Bedingungen in dem Entscheidungsblock 294 nicht wahr sind, dann geht die Routine zu Block 296 und endet.
Wenn in dem Entscheidungsblock 287 kein Lösch- Gültigkeitsbereich spezifiziert worden ist, wird die Anforderungsnachricht in Block 291 als fehlerhafte Anforderung zurückgewiesen; andernfalls fährt sie zu 298 fort, wo alle relevanten gültigen Beendigungstraps unter Verwendung eines ähnlichen Algorithmus gelöscht werden, und die Routine endet.
Es wird dem Fachmann offensichtlich sein, daß die hierin offenbarte Erfindung auf vielfältige Weise modifiziert werden kann und viele Ausführungsformen annehmen kann, die anders als die bevorzugte Form, die insbesondere dargelegt und oben beschrieben wurde, sind. Beispielsweise kann die Erfindung auf anderen Typen von Datenverarbeitungssystemen implementiert werden. Sie kann auch verwendet werden, um zusätzliche Attribute, welche erzeugte und/oder beendete Prozesse betreffen wie beispielsweise, ob der Prozess ein Kontextprozess ist, zu schaffen. Ausserdem kann sie zur Schaffung von Benachrichtigungen anderer Typen von Ereignissen verwendet werden.
Demgemäß ist es beabsichtigt, durch die angefügten Ansprüche alle Modifikationen der Erfindung zu erfassen.

Claims

1. Ein Verfahren zur Lieferung einer Benachrichtigungsmitteilung in einem verteilten Datenverarbeitungssystem mit einer Mehrzahl von zusammengeschalteten Knoten (172, 176; Fig. 9) bei Erzeugung eines Prozesses auf einem der Knoten, wobei das System eine Mehrzahl von Prozessen (a, b, x) umfaßt, wobei die Prozesse miteinander durch Meldungen kommunizieren, wobei das Verfahren die Schritte aufweist:

a) Schaffen eines Prozeßmanager-Prozesses (172) auf dem einen Knoten;

b) wobei wenigstens ein Anforderungsprozeß eine Anforderungsmeldung an den Prozeßmanager-Prozeß sendet, so daß er eine Benachrichtigungsmitteilung für den wenigstens einen Anforderungsprozeß generiert, wenn ein Prozeß auf dem einen Knoten erzeugt wird;

und dadurch gekennzeichnet, daß

c) der Prozeßmanager-Prozeß auf Empfangen der Anforderungsmeldung hin ein Prozeßerzeugungs-Trap (183, 186, 188, 190, Fig. 10) setzt; und

d) der Prozeßmanager-Prozeß auf Erzeugung des Prozesses hin eine Benachrichtigungsmitteilung an den wenigstens einen Anforderungsprozeß sendet und das Prozeßerzeugungs-Trap freigibt.

2. Das Verfahren zur Lieferung einer Benachrichtigungsmitteilung nach Anspruch 1, in welchem die Anforderungsmeldung einen Prozeß mit einem bestimmten Namen bezeichnet.

3. Das Verfahren zur Lieferung einer Benachrichtigungsmitteilung nach Anspruch 1, in welchem die Anforderungsmeldung von einer Mehrzahl von Knoten stammt, und in welchem die Benachrichtigungsmitteilung auf die Mehrzahl der Knoten übertragen wird.

4. Das Verfahren zur Lieferung einer Benachrichtigungsmitteilung nach Anspruch 1, in welchem das System eine Mehrzahl von Knoten umfaßt, in welchem die Anforderungsmeldung durch irgendeinen Prozeß auf einem der Knoten generiert und auf die anderen Knoten weitergegeben wird, in welchem die Benachrichtigungsmitteilung auf den einen Knoten der Knoten, auf dem der neue Prozeß erzeugt wird, übertragen wird, und in welchem der eine Knoten die Antwort auf den Anforderungsprozeß generiert.

5. Das Verfahren zur Lieferung einer Benachrichtigungsmitteilung nach Anspruch 1, in welchem die Anforderungsmeldung durch irgendeinen oder mehrere der Mehrzahl der Prozesse in dem System generiert werden kann.

6. Ein Verfahren zur Lieferung einer Benachrichtigungsmitteilung in einem verteilten Datenverarbeitungssystem mit einer Mehrzahl von zusammengeschalteten Knoten (172, 176; Fig. 9) bei Beendigung eines Prozesses auf einem der Knoten, wobei das System eine Mehrzahl von Prozessen (a, b, x) umfaßt, wobei die Prozesse miteinander durch Meldungen kommunizieren, wobei das Verfahren die Schritte aufweist:

a) Schaffen eines Prozeßmanager-Prozesses (172) auf dem einen Knoten;

b) wobei wenigstens ein Anforderungsprozeß eine Anforderungsmeldung an den Prozeßmanager-Prozeß sendet, so daß er eine Benachrichtigungsmitteilung für den wenigstens einen Anforderungsprozeß generiert, wenn ein Prozeß auf dem einen Knoten beendet wird;

und dadurch gekennzeichnet, daß

c) der Prozeßmanager-Prozeß auf Empfangen der Anforderungsmeldung hin ein Prozeßbeendigungs-Trap (183, 186, 188, 190, Fig. 10) setzt; und

d) der Prozeßmanager-Prozeß auf Beendigung des Prozesses hin eine Benachrichtigungsmitteilung an den wenigstens einen Anforderungsprozeß sendet und das Prozeßbeendigungs-Trap freigibt.

7. Das Verfahren zur Lieferung einer Benachrichtigungsmitteilung nach Anspruch 6, in welchem die Anforderungsmeldung einen Prozeß mit einem bestimmten Namen bezeichnet.

8. Das Verfahren zur Lieferung einer Benachrichtigungsmitteilung nach Anspruch 6, in welchem die Anforderungsmeldung von einer Mehrzahl von Knoten stammt, und in welchem die Benachrichtigungsmitteilung auf die Mehrzahl der Knoten übertragen wird.

9. Das Verfahren zur Lieferung einer Benachrichtigungsmitteilung nach Anspruch 6, in welchem das System eine Mehrzahl von Knoten umfaßt, in welchem die Anforderungsmeldung durch einen der Knoten generiert und auf die anderen Knoten weitergegeben wird, und in welchem die Benachrichtigungsmitteilung auf den einen Knoten der Knoten, auf dem der Prozeß beendet wird, übertragen wird.

10. Das Verfahren zur Lieferung einer Benachrichtigungsmitteilung nach Anspruch 6, in welchem die Anforderungsmeldung durch irgendeinen oder mehrere der Mehrzahl der Prozesse in dem System generiert werden kann.