DE69935805T2

DE69935805T2 - Rechnersystem und verfahren zum betreiben von mehreren betriebssystemen in verschiedenen partitionen des rechnersystems und um den verschiedenen partitionen die kommunikation miteinander durch gemeinsame speicher zu erlauben

Info

Publication number: DE69935805T2
Application number: DE69935805T
Authority: DE
Inventors: Robert C. Glenmoore GULICK; Douglas E. Allentown MORRISSEY; Charles Raymond Minneapolis CALDARALE; Bruce Alan Downingtown VESSEY; Craig F. Berwyn RUSS; Eugene W. King of Prussia TROXELL; Hans Christian Afton MIKKELSEN; Sharon M. West Chester MAUER; Maureen P. Norristown CONNELL; James R. Downingtown HUNTER
Original assignee: Unisys Corp
Current assignee: Unisys Corp
Priority date: 1998-12-18
Filing date: 1999-12-17
Publication date: 2007-12-27
Anticipated expiration: 2019-12-18
Also published as: EP1145122A2; US6314501B1; JP2002532806A; DE69935805D1; ATE359550T1; WO2000036509A3; WO2000036509A2; EP1145122B1; BR9916308A; US7571440B2; JP2006216068A; CA2355065A1; CA2355065C; US20030037178A1

Description

Anmerkungen zu Urheberrecht und Marken
Ein Teil der Offenbarung dieser Patentschrift enthält Material, das dem Urheberrecht unterliegt. Der Inhaber des Urheberrechts hat keinen Einwand gegen die Faksimile-Reproduktion der Patentschrift oder der Patentoffenbarung, wie sie in den Patentakte oder Unterlagen des United States Patent & Trademark Office erscheint, egal durch welche Person; ansonsten behält er sich jedoch alle Urheberrechte vor.
Unix ist ein eingetragenes Warenzeichen von The Open Group. SCO und Unixware sind eingetragene Warenzeichen von The Santa Cruz Operation, Inc. Microsoft, Window, Window NT und/oder andere Microsoft-Produkte, auf die hierin Bezug genommen wird, sind entweder Warenzeichen oder eingetragene Warenzeichen der Microsoft Corporation. Intel, Pentium, Pentium II Xeon, Merced und/oder andere Intel-Produkte, auf die hierin Bezug genommen wird, sind entweder Warenzeichen oder eingetragene Warenzeichen der Intel Corporation.
Hintergrund der Erfindung
Gebiet der Erfindung
Die vorliegende Erfindung betrifft allgemein Computersysteme und im Speziellen ein Computersystem, das mehrere Betriebssysteme in verschiedenen Partitionen auf dem Computersystem ausführt und es den verschiedenen Partitionen ermöglicht, miteinander über einen gemeinsam benutzten Speicherbereich zu kommunizieren.
Stand der Technik
Ein Computersystem schließt typischerweise einen Prozessor, einen Hauptspeicher und Ein-/Ausgabe-Vorrichtungen (z. B. Drucker, Netzwerk-Schnittstellen, Grafikdisplay-Schnittstellen) ein. Das Computersystem verwendet ein Adressier-Schema, um die Quelle oder das Ziel eines Datenelements zu bestimmen. Speicherverwaltungsfunktionen, einschließlich des Zugriffs auf Daten sowie anderer Verwaltungsfunktionen, werden durch ein Betriebssystem gesteuert. Es gibt eine Vielzahl von Betriebssystemen auf dem Markt, von denen jedes seine eigenen spezifischen Eigenschaften und Fähigkeiten hat. Herkömmliche Computersysteme verwenden typischerweise ein einziges Betriebssystem.
Während moderne Computersysteme wachsen und die Ansprüche der Benutzer steigen, nimmt die Notwendigkeit zu, eine Vielzahl von Betriebssystemen zu verwenden. Leider erhöht eine Vielzahl von Betriebssystemen wesentlich die Komplexität des Betreibens des Computersystems.
Was benötigt wird, sind ein Computersystem und ein Verfahren, um es mehreren Betriebssystemen, einschließlich verschiedener Betriebssysteme, zu ermöglichen, in verschiedenen Partitionen auf dem Computersystem zu arbeiten, und um es den verschiedenen Partitionen, die die Betriebssysteme und andere Clients einschließen, die in den verschiedenen Partitionen ausgeführt werden, zu ermöglichen, miteinander über einen gemeinsam benutzten Speicherbereich zu kommunizieren.
Das U.S.-Patent Nr. 5,590,301 offenbart ein fest verdrahtetes Partitionsschema, in dem jedem der vier Prozessor-"Cluster" eine eigene Cluster-Nummer zugewiesen wird und anschließend diese Nummer, gemeinsam mit einer Prozessor-Speicher-Referenz, entsprechend einem fest verdrahteten, starren Übersetzungsmechanismus umgewandelt wird, dem die notwendige Flexibilität und Programmierbarkeit fehlen, um die oben genannten Ziele zu erreichen. Das U.S.-Patent Nr. 5,142,683 und die Europäische Patentanmeldung 0,444,376 A1 beschreiben Kommunikationstechniken zwischen Systemen, aber sie beschreiben nicht, alleine oder in Verbindung mit U.S.-Patent Nr. 5,590,301, die gewünschte Art von System.
Zusammenfassung der Erfindung
Die vorliegende Erfindung betrifft ein Computersystem und Verfahren, um es mehreren Betriebssystemen zu ermöglichen, in verschiedenen Partitionen innerhalb einer einzigen Rechner-Architektur zu arbeiten, und um es den verschiedenen Partitionen zu ermöglichen, miteinander über einen gemeinsam benutzten Speicherbereich gemäß den Merkmalen, die in den Ansprüchen 1 und 25 erwähnt sind, zu kommunizieren. Gemäß einem ersten Aspekt der vorliegenden Erfindung umfasst das Computersystem eine Vielzahl von Verarbeitungsmodulen und einen Hauptspeicher, mit dem jedes Verarbeitungsmodul verbunden ist, so dass die Prozessor-an-Speicher-Latenz für alle Verarbeitungsmodule über den gesamten Hauptspeicher identisch ist. Gruppen aus einem oder mehreren Verarbeitungsmodulen sind als separate Partitionen im Computersystem ausgebildet, und jede Partition arbeitet unter der Kontrolle eines eigenen Betriebssystems. Weiter ist gemäß diesem ersten Aspekt der vorliegenden Erfindung im Hauptspeicher mindestens ein gemeinsam benutztes Speicherfenster definiert, auf das mindestens zwei verschiedene Partitionen gemeinsamen Zugriff haben. Programmcode, der auf verschiedenen Partitionen ausgeführt wird, ermöglicht es diesen verschiedenen Partitionen, miteinander durch das gemeinsam benutzte Speicherfenster zu kommunizieren.
Für jede Partition, die innerhalb des Computersystems ausgebildet ist, kann im Hauptspeicher weiterhin ein exklusives Speicherfenster definiert sein, auf das nur diese Partition Zugriff hat und in dem das Betriebssystem dieser Partition ausgeführt wird. Die separaten Betriebssysteme auf zwei unterschiedlichen Partitionen können verschiedene Betriebssysteme sein, oder sie können verschiedene Instanzen desselben Betriebssystems sein.
In einer Ausführungsform implementiert der Programmcode, der die Kommunikation zwischen Partitionen ermöglicht (durch Verwaltung der Ressourcen des gemeinsam benutzten Speicherfensters), einen Prozess, durch den eine sendende Partition einen Inter-Prozessor-Interrupt in einer empfangenden Partition erzeugt, um der empfangenden Partition zu signalisieren, dass durch das gemeinsam benutzte Speicherfenster Informationen an sie gesendet werden. Gemäß dieser Ausführungsform umfasst das gemeinsam benutzte Speicherfenster einen Satz von Eingabe-Warteschlangen, verknüpft mit jeder Partition, wobei jede Eingabe-Warteschlange des Satzes, der mit einer bestimmten Partition verknüpft ist, einer anderen Partition entspricht und Eingaben speichert, die Kommunikation von dieser anderen Partition darstellen. Damit eine Partition (eine sendende Partition) mit einer anderen Partition (einer empfangenden Partition) kommunizieren kann, führt der Programmcode in der sendenden Partition folgende Schritte durch: (i) Er veranlasst, dass ein Eintrag in der Eingabe-Warteschlange der empfangenden Partition erstellt wird, der der sendenden Partition entspricht; und dann (ii) veranlasst er, dass ein Inter-Prozessor-Interrupt in der empfangenden Partition erzeugt wird, um der empfangenden Partition zu signalisieren, dass der Eintrag in der Eingabe-Warteschlange erstellt wurde.
Unter der Annahme einer Ausführungsform, in der jeder Partition nur ein einziger Interrupt-Vektor für den Empfang von Inter-Prozessor-Interrupts von anderen Partitionen aus dem gemeinsam benutzten Speicherbereich zugewiesen wird, führt der Programmcode in der empfangenden Partition folgende Schritte durch, wenn der Inter-Prozessor-Interrupt in der empfangenden Partition erkannt wird: (i) Er veranlasst die Untersuchung jeder seiner Eingabe-Warteschlangen, um zu bestimmen, welche von ihnen Einträge enthalten, die Nachrichten von anderen Partitionen repräsentieren, und (ii) er veranlasst, dass alle solchen Einträge aus den Eingabe-Warteschlangen, die sie enthalten, extrahiert werden. Vorzugsweise enthält jede Eingabe-Warteschlange eine Zählung der Einträge in der Warteschlange.
Alternativ dazu kann in einer Ausführungsform, in der jede Partition einen separaten Interrupt-Vektor für jede andere Partition, von der sie einen Inter-Prozessor-Interrupt empfangen kann, zuweist und worin die sendende Partition den ihr zugewiesenen Interrupt-Vektor angibt, wenn sie einen Inter-Prozessor-Interrupt an die empfangende Partition sendet, die empfangende Partition den angegebenen Interrupt-Vektor nutzen, um die Eingabe-Warteschlange zu identifizieren, die mit der sendenden Partition verknüpft ist, und sie direkt verarbeiten, ohne all ihre Eingabe-Warteschlangen durchsuchen zu müssen (wie es der Fall ist, wenn jede Partition nur einen einzigen Interrupt-Vektor für Inter-Prozessor-Interrupts des gemeinsam benutzten Speichers zuweist).
Weiter umfasst das gemeinsam benutzte Speicherfenster gemäß dieser ersten Ausführungsform eine Vielzahl von Speicherseiten, die den Partitionen nach Bedarf zugewiesen werden können, um den Austausch von Informationen zwischen ihnen zu erleichtern. Ein Eingabe-Warteschlangen-Eintrag, der eine Kommunikation zwischen einer sendenden Partition und einer empfangenden Partition darstellt, kann eine Kennung für eine oder mehrere zugeordnete Seiten des gemeinsam benutzten Speicherfensters umfassen. Eine sendende Partition kann eine oder mehrere zugeordnete Seiten verwenden, um Daten zu speichern, die eine Nachricht darstellen, welche an eine empfangende Partition gesendet werden soll.
Weiterhin ist gemäß dieser ersten Ausführungsform jede Eingabe-Warteschlange in der Lage, eine vordefinierte Anzahl von Einträgen zu speichern, und enthält ein Überlauf-Flag, das immer dann gesetzt wird, wenn die Eingabe-Warteschlange voll ist. Eine sendende Partition veranlasst das Setzen des Überlauf-Flags einer Eingabe-Warteschlange, wenn die Eingabe-Warteschlange durch die Erstellung eines Eintrags in dieser Eingabe-Warteschlange voll wird. Wenn auf der Empfangsseite eine empfangende Partition eine Eingabe-Warteschlange erkennt, in welcher das Überlauf-Flag gesetzt ist, leert sie die Warteschlange und setzt dann das Überlauf-Flag zurück. Die empfangende Partition kann dann eine Nachricht zurück an die sendende Partition schicken, um diese zu benachrichtigen, dass die Eingabe-Warteschlange nicht mehr voll ist. Wenn ein Versuch unternommen wird, eine Nachricht über eine volle Eingabe-Warteschlange zu versenden, kann die sendende Partition einen Fehler zurückgeben, oder alternativ kann jede Partition eine Speicherstelle in ihrem exklusiven Speicherfenster verwalten, um Eingabe-Warteschlangen-Einträge zu speichern, die nicht in eine bestimmte Eingabe-Warteschlange platziert werden konnten, weil zuvor das Überlauf-Flag dieser Eingabe-Warteschlange gesetzt wurde. Die in der exklusiven Speicherfenster-Stelle gespeicherten Einträge können dort bleiben, bis das Überlauf-Flag der designierten Eingabe-Warteschlange von der empfangenden Partition rückgesetzt wird.
Weiterhin umfasst das gemeinsam benutzte Speicherfenster gemäß der bevorzugten Ausführungsform eine Tabelle, die für jede Seite des gemeinsam benutzten Speicherfensters, die zugewiesen werden kann, anzeigt, ob die Seite in Gebrauch oder zur Zuweisung verfügbar ist. Die Seiten, die für die Zuweisung zur Verfügung stehen, sind vorzugsweise miteinander verknüpft, um eine Pool-Liste verfügbarer Seiten zu bilden. Bei mindestens einigen Arten von Seiten wird die Inhaberschaft einer oder mehrerer Partitionen an einer Seite vorzugsweise durch Informationen in einem Header innerhalb der Seite selbst angezeigt. Die Inhaberschaft an anderen Arten von Seiten kann durch Informationen in der Tabelle angezeigt werden, die auch die Verfügbarkeit jeder Seite angibt.
Der Header jeder Seite kann weiter ein Sperrfeld umfassen, durch das eine Partition exklusiven Zugriff auf eine Seite erhalten kann, um z. B. Informationen zur Inhaberschaft im Header der Seite zu aktualisieren. Dieses Feld ist Teil eines größeren Sperrmechanismus der vorliegenden Erfindung, der es verschiedenen Partitionen ermöglicht, den Zugriff auf die verschiedenen Strukturen, Seiten und Tabellen des gemeinsam benutzten Speicherfensters nach Bedarf zu blockieren und auf konsistente Art und Weise sicherzustellen, dass nur eine Partition zur Zeit eine bestimmte Struktur, Seite oder Tabelle modifizieren kann (d. h., den Zugriff auf diese Strukturen zu synchronisieren). Gemäß einer wichtigen Eigenschaft des Sperrmechanismus der vorliegenden Erfindung muss die zuweisende Partition, wenn eine Speicherseite zum ersten Mal zugewiesen wird, einen systemweiten Schlüssel erwerben, um den Zugriff auf die Seite während der Zuweisung zu blockieren. Wenn jedoch die Inhaberschaft an einer oder mehr zugewiesenen Seiten auf andere Partitionen ausgedehnt oder übertragen wird, muss nur ein Schlüssel für die betreffenden Seiten erworben werden. Das Sperrfeld auf diesen Seiten wird für diesen Zweck verwendet. Dies ermöglicht einen höheren Durchsatz von Nachrichten zwischen Partitionen, da Konkurrenz um den systemweiten Schlüssel vermieden wird.
Gemäß einer zweiten Ausführungsform implementiert der Programmcode auf jeder Partition einer Abfrageprozess, mit dem jede Partition einen Bereich innerhalb des gemeinsam genutzten Speicherfensters abfragt, um zu ermitteln, ob Nachrichten, die für sie bestimmt sind, von einer anderen Partition in das gemeinsam genutzte Speicherfenster gestellt wurden. In dieser Ausführungsform umfasst der Bereich, der von jeder Partition abgefragt wird, eine Vielzahl von Ausgabe-Warteschlangen, eine für jede Partition. Die Ausgabe-Warteschlange für eine bestimmte Partition gibt an, ob diese Partition in das gemeinsam genutzte Speicherfenster Nachrichten gestellt hat, die für eine der anderen Partitionen bestimmt sind. Jede Partition fragt die Ausgabe-Warteschlangen der anderen Partitionen ab, um zu ermitteln, ob diese anderen Partitionen Nachrichten, die für sie bestimmt sind, in das gemeinsam genutzte Speicherfenster platziert haben. Jeder Partition wird ein separater Pool von Nachrichtenpuffern zugewiesen, in den sie Nachrichten stellen kann, die für andere Partitionen bestimmt sind. Wenn eine sendende Partition eine Nachricht, die für eine empfangende Partition bestimmt ist, in einen ihrer zugewiesenen Puffer stellt, gibt sie den Speicherort dieses Puffers in ihrer Ausgabe-Warteschlange an.
Detaillierter beschrieben, umfasst die Ausgabe-Warteschlange einer bestimmten Partition eine oder mehrere Knoten-zu-Knoten-Warteschlangen, von denen jede mit einer anderen Partition verknüpft ist, an die sie Nachrichten senden kann. Jede Knoten-zu-Knoten-Warteschlange gibt an, ob Nachrichten, die für die Partition bestimmt sind, mit der sie verknüpft ist, in das gemeinsam genutzte Speicherfenster gestellt wurden. So fragt jede Partition die mit ihr verknüpften Knoten-zu-Knoten-Warteschlangen in den Ausgabe-Warteschlangen jeder anderen Partition ab, um zu ermitteln, ob eine dieser anderen Partitionen Nachrichten, die für sie bestimmt sind, in das gemeinsam genutzte Speicherfenster gestellt hat. Bei Nachrichtendaten, die von einer sendenden Partition in einen Puffer gestellt wurden, gibt die Knoten-zu-Knoten-Warteschlange, die mit der empfangenden Partition verknüpft ist, die Speicherstelle des Puffers an, so dass die empfangende Partition die Nachrichtendaten abrufen kann.
Gemäß einem zweiten Aspekt der vorliegenden Erfindung kann das Computersystem auch ein Mittel umfassen, um den physikalischen Adressraum der Prozessoren in jeder Partition auf das entsprechende exklusive Speicherfenster abzubilden, das der Partition zugewiesen ist. Im Speziellen umfasst das Mittel zur Abbildung Mittel zum Verschieben einer Referenz auf eine Speicherstelle innerhalb des physikalischen Adressraums der Prozessoren auf einer bestimmten Partition an die entsprechende Speicherstelle innerhalb des exklusiven Speicherfensters, das dieser Partition zugewiesen ist. Auf diese Art und Weise können die exklusiven Speicherfenster jeder Partition, die sich physikalisch an verschiedenen Stellen des Hauptspeichers befinden, gegenüber ihren entsprechenden Betriebssystemen so dargestellt werden, als hätten sie dieselbe physikalische Basisadresse im Hauptspeicher (z. B. Basisadresse Null). Dies ist notwendig, um bestimmte Standard-Betriebssysteme (z. B. Unix, Windows NT usw.) auf verschiedenen Partitionen auszuführen, da diese Betriebssysteme davon ausgehen, dass der Hauptspeicher bei der Adresse Null beginnt. Indem der Prozessor-Adressraum in jeder Partition auf deren exklusives Speicherfenster abgebildet wird, können die Betriebssysteme auch weiterhin auf den Speicher verweisen, wie sie dies normalerweise im physikalischen Adressraum der Prozessoren tun würden, auf denen sie ausgeführt werden. Somit ist keine Modifikation der Betriebssysteme erforderlich.
In einer bevorzugten Ausführungsform umfasst das Mittel zur Verschiebung ein Register, das einen Offset (R_L ^OS) von der physikalischen Basisadresse des Hauptspeichers zum Anfang des exklusiven Speicherfensters enthält, das einer bestimmten Partition zugewiesen ist, und einen Addierer, um den Offset (R_L ^OS) zu jeder Referenz durch einen Prozessor in dieser Partition auf eine Speicherstelle innerhalb seines physikalischen Adressraums zu addieren. Folglich werden diese Referenzen an ihre entsprechenden Speicherstellen innerhalb des exklusiven Speicherfensters der Partition verschoben.
Gemäß einem anderen Merkmal dieses Aspekts der vorliegenden Erfindung kann das Computersystem, in Fällen, in denen der physikalische Adressraum der Prozessoren einer bestimmten Partition einen Adressbereich enthält, der nicht für die Speicherung zur Verfügung steht (z. B. einen Bereich, der für Speicher-konforme E/A reserviert ist) und so eine Speicherungslücke bestimmt, weiter Mittel umfassen, um den Teil des exklusiven Speicherfensters der Partition, der ansonsten der Speicherungslücke entsprechen würde, für andere Zwecke zurückzufordern. Im Speziellen erkennt das Computersystem die Speicherungslücke und definiert Adressen oberhalb der Speicherungslücke als oberen Speicherbereich und Adressen unterhalb der Speicherungslücke als unteren Speicherbereich. Zusätzlich zum Offset (R_L ^OS) von der physikalischen Basisadresse des Hauptspeichers zum Anfang des exklusiven Speicherfensters, das einer bestimmten Partition zugewiesen ist, wird auch ein Wert (R_C ^OS) gespeichert, der die Größe der Speicherungslücke angibt. Verschieben und Zurückfordern werden dann durchgeführt durch (i) Addieren des Offsets (R_L ^OS) zu jeder Referenz durch einen Prozessor in der jeweiligen Partition auf eine Speicherstelle innerhalb des unteren Speicherbereichs seines physikalischen Adressraums (wodurch diese Referenzen an ihre entsprechenden Speicherstellen im exklusiven Speicherfenster verschoben werden) und (ii) Addieren des Offsets abzüglich des Werts, der die Größe der Speicherungslücke (R_L ^OS R_C ^OS) darstellt, zu jeder Referenz durch einen Prozessor in der jeweiligen Partition auf eine Speicherstelle innerhalb des oberen Speicherbereichs ihres physikalischen Adressraums (wodurch diese Referenzen an ihre entsprechenden Speicherstellen im exklusiven Speicherfenster verschoben werden und gleichzeitig der Teil des exklusiven Speicherfensters, der ansonsten der Speicherungslücke entsprochen hätte, zurückgefordert wird).
Gemäß einem weiteren Merkmal dieses Aspekts der vorliegenden Erfindung können gemeinsam benutzte Speicherfenster ebenfalls berücksichtigt werden. Im Speziellen kann, wie oben erwähnt, ein gemeinsam benutztes Speicherfenster zusätzlich zu den exklusiven Speicherfenstern für jede Partition bestimmt werden. Um den gemeinsamen Zugriff auf dieses Fenster zu ermöglichen, bestimmt jede Partition einen Teil des physikali schen Adressraums ihrer Prozessoren, der dem gemeinsam benutzten Speicherfenster im Hauptspeicher entsprechen soll. Dann wird gemäß der vorliegenden Erfindung dieser Teil des physikalischen Adressraums der Prozessoren auf jeder Partition auf dasselbe gemeinsam benutzte Speicherfenster im Hauptspeicher abgebildet. In einer bevorzugten Ausführungsform wird dies in jeder Partition durch folgende Schritte erreicht: (i) Speichern eines Offsets (S_BASE ^OS) von der Basisadresse des physikalischen Adressraums der Prozessoren auf der Partition zum Anfang des Teils des physikalischen Adressraums, der als der Teil definiert wurde, welcher dem gemeinsam benutzten Speicherfenster entspricht, (ii) Speichern eines weiteren Offsets (S_BASE ^MSU) von der Basisadresse des Hauptspeichers zum Anfang des gemeinsam benutzten Speicherfensters im Hauptspeicher und (iii) Addieren der Differenz zwischen den Offsets (S_BASE ^MSU – S_BASE ^OS) zu jeder Referenz durch einen Prozessor in der Partition auf eine Speicherstelle innerhalb seines definierten Teils, wodurch diese Referenzen an ihre entsprechenden Speicherstellen innerhalb des gemeinsam benutzten Speicherfensters des Hauptspeichers verschoben werden.
Verfahren der vorliegenden Erfindung werden in den verschiedenen Arbeitsweisen des Computersystems widergespiegelt.
Weitere Merkmale und Vorteile des Computersystems und der Verfahren der vorliegenden Erfindung, ebenso wie die Struktur und Arbeitsweise verschiedener Ausführungsformen der vorliegenden Erfindung, sind unten detailliert mit Bezug auf die beigefügten Zeichnungen beschrieben.
Kurze Beschreibung der Zeichnungen
Die Erfindung ist am besten mit Bezug auf die Zeichnungen zu verstehen, worin Bezugnahmen mit gleichen Bezugszeichen gleiche oder funktionell ähnliche Elemente kennzeichnen. Zusätzlich kennzeichnen die Ziffern ganz links die Abbildung, in der das Bezugszeichen in den beigefügten Zeichnungen zuerst erscheint, worin:
1 ein Blockdiagramm einer Umgebung ist, die zur Implementierung einer bevorzugten Ausführungsform der vorliegenden Erfindung geeignet ist;
2 ein Blockdiagramm eines Computersystems gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung ist;
3 eine Ansicht eines Speichers in einem Beispiel mit vier Partitionen ist, von denen jede ein exklusives Speicherfenster und Zugriff auf zwei gemeinsame Fenster hat;
4 eine Ansicht eines Speichers in einem Beispiel mit zwei Partitionen darstellt, von denen jede ein exklusives Speicherfenster hat;
5 eine Ansicht eines Speichers in einem Beispiel mit drei Partitionen darstellt, von denen jede ein exklusives Speicherfenster und Zugriff auf ein gemeinsames Fenster hat;
6 eine exemplarische Speicherkonfiguration darstellt, die verwendet wird, um die vorliegende Erfindung in Betrieb zu zeigen;
7 das Ergebnis der Anwendung der vorliegenden Erfindung auf die in 6 gezeigte Speicherkonfiguration darstellt;
8 ein Flussdiagramm ist, das einen Vorwärts-Fenstertechnik-Algorithmus darstellt;
9 ein Flussdiagramm ist, das einen Vorwärts-Übersetzungsalgorithmus darstellt;
10 eine Ausführungsform darstellt, in der das Speichersystem ein einziges gemeinsames Fenster gemäß der vorliegenden Erfindung darstellt;
11 und 12 Anwendungen der vorliegenden Erfindung darstellen;
13 ein Prozess-Flussdiagramm für einen exemplarischen Initialisierungsvorgang gemäß der vorliegenden Erfindung darstellt;
14 Datenstrukturen darstellt, die zum gemeinsamen Nutzen von Speicher gemäß einer ersten Ausführungsform eines Verwaltungsverfahrens für gemeinsam genutzten Speicher der vorliegenden Erfindung verwendet werden können;
15 eine exemplarische Ausführungsform eines Meldung-Warteschlangen-Bereichs gemäß der ersten Ausführungsform darstellt;
16A exemplarische Informationen darstellt, die in eine Knoten-Ausgabe-Warteschlangen-Datenstruktur gemäß der ersten Ausführungsform eingeschlossen sein können;
16B exemplarische Informationen darstellt, die in eine Knoten-Ausgabe-Warteschlangen-Datenstruktur gemäß der ersten Ausführungsform eingeschlossen sein können;
17 eine exemplarische Nachrichten-Datenstruktur gemäß der ersten Ausführungsform darstellt;
18 eine exemplarische Nutzung des Computersystems und der Verfahren der vorliegenden Erfindung für die Kommunikation zwischen Partitionen über den gemeinsam benutzten Speicherbereich darstellt;
19 das Layout eines gemeinsam benutzten Speicherfensters gemäß einer alternativen Ausführungsform eines Verwaltungsverfahrens für den gemeinsam genutzten Speicherbereich der vorliegenden Erfindung darstellt;
20 den Inhalt eines Kontrollstruktur-Headers gemäß der alternativen Ausführungsform darstellt;
21 den Inhalt einer Zuweisungs-Struktur gemäß der alternativen Ausführungsform darstellt;
22 ein Blockdiagramm einer anderen exemplarischen Nutzung des Computersystems und der Verfahren der vorliegenden Erfindung darstellt, worin Software, die die vorliegende Erfindung nutzt, es Betriebssystemen ermöglicht, mit gemeinsamem Speicherbereich zu kommunizieren und gleichzeitig einen Anschein von Kommunikation über Kabel aufrechtzuerhalten;
23 weitere Details der in 22 dargestellten Software zeigt;
24 weitere Einzelheiten der in 22 dargestellten Software zeigt, worin die Software konstruiert ist, um in einer Windows NT-Umgebung ausgeführt zu werden;
25 ein Prozess-Flussdiagramm ist, das weitere Details der in 22 dargestellten Software zeigt, worin die Software konstruiert ist, um in einer Windows NT-Umgebung ausgeführt zu werden;
26 ein Prozess-Flussdiagramm ist, das weitere Details der in 22 dargestellten Software zeigt, worin die Software konstruiert ist, um in einer 2200-Betriebssystemumgebung ausgeführt zu werden;
27 ein Prozess-Flussdiagramm ist, das noch mehr Details der in 22 dargestellten Software zeigt, einschließlich Details eines CPCOMM-Softwareprogramms (CPCOMM: Co-operative Processing Communications);
28 weitere Details des in 2 dargestellten Computersystems zeigt;
29 den Inhalt eines Eingabe-Warteschlangen-Headers gemäß der in 19 dargestellten alternativen Ausführungsform zeigt;
30 den Inhalt einer Eingabe-Warteschlange gemäß der alternativen Ausführungsform zeigt;
31A und 31B ein Flussdiagramm umfassen, das den Betrieb des Computersystems gemäß der alternativen Ausführungsform weiter erläutert;
32A den Inhalt eines Headers einer gemeinsam benutzten Speicherseite vom Typ 1 gemäß der alternativen Ausführungsform darstellt; und
32B den Inhalt eines Headers einer gemeinsam benutzten Speicherseite vom Typ 2 gemäß der alternativen Ausführungsform darstellt;
33 ein Blockdiagramm der Vorrichtung zur Durchführung der Verfahren der Adressenverschiebung und -zurückforderung der vorliegenden Erfindung gemäß einer bevorzugten Ausführungsform davon ist.
Detaillierte Beschreibung der bevorzugten Ausführungsformen
Inhaltsverzeichnis
I. Überblick
II. Computersystem-Plattform

A. Speicherfenster (Verschieben und Zurückfordern)
B. Verschachteln und Stapeln von Speicher (Übersetzung)
C. Initialisierung beim Booten

III. Verfahren zur Verwaltung des globalen gemeinsam genutzten
Speicherbereichs (Kommunikation zwischen Partitionen)

A. Polling von Kommunikation zwischen Partitionen
B. Interrupt-gesteuerte Kommunikation über gemeinsam genutzten Speicher
1. Struktur des gemeinsam genutzten Speicherbereichs
2. Liste freier Seiten
3. Client-Verzeichnis-Tabelle
4. Arten von gemeinsamen Speicherseiten
5. Kontrollstruktur-Header
6. Zuordnungsstruktur
7. Signale
8. Eingabe-Warteschlangen und Eingabe-Warteschlangen-Header
9. Inter-Prozessor-Interrupt-Mechanismus
10. Die Core Services-API
11. Von Clients gestellte Schnittstellen
12. Exemplarische Arbeitsweise
13. Weitere Funktionen

IV. Exemplarische Nutzungen des Computersystems und der Verfahren der vorliegenden Erfindung zur Erleichterung der Kommunikation zwischen Partitionen

A. Ein Gerätetreiber des gemeinsamen Speicherbereichs
B. Aufrechterhaltung eines Anscheins von Kommunikation per Kabel

V. Schlussfolgerungen
I. Überblick
Die vorliegende Erfindung betrifft ein Mehrprozessor-Computersystem, das ein oder mehrere Prozessor-Module und einen Hauptspeicher mit einer oder mehreren Speichereinheiten hat und es einer Vielzahl von Betriebssystemen ermöglicht, gleichzeitig in verschiedenen Partitionen innerhalb des Computersystems ausgeführt zu werden, und das es den verschiedenen Partitionen ermöglicht, miteinander über einen gemeinsam genutzten Speicher bereich zu kommunizieren. Der Hauptspeicher ist in eine Vielzahl von Speichereinheiten (memory storage units, MSUs) unterteilt. Der Hauptspeicher wird unter den verschiedenen Partitionen aufgeteilt. Die Datenkohärenz und -konsistenz werden unter den Partitionen aufrechterhalten.
Gemäß einem erfinderischen Aspekt des Computersystems wird eine Adresszuordnungs-Funktion, f_pa, zwischen einer Adressabfrage, die von einem der Prozessoren eines Prozessormoduls erzeugt wird, und einer entsprechenden Adresse in einem Fenster des Hauptspeichers bereitgestellt. Die Adresszuordnungs-Funktion, f_pa, kann begriffsmäßig als aus drei verschiedenen Teilen bestehend betrachtet werden: Fenstertechnik, Zurückforderung und Übersetzung.
Der Hauptspeicher hat einen zusammenhängenden Adressraum. Gemäß der vorliegenden Erfindung wird jeder Partition (und ihrem dazugehörigen Betriebssystem) ein exklusives Speicherfenster im Adressraum des Hauptspeichers zugewiesen. Innerhalb des Hauptspeichers kann auch ein gemeinsam benutztes Speicherfenster definiert werden, auf das mehrere Partitionen gemeinsamen Zugriff haben können. Die Fenstertechnik-Funktion bildet den physikalischen Adressraum der Prozessoren in jeder Partition auf die entsprechenden exklusiven Speicherfenster ab, die diesen Partitionen zugewiesen sind. Auf diese Art werden die exklusiven Speicherfenster jeder Partition gegenüber ihren jeweiligen Betriebssystemen so dargestellt, als hätten sie dieselbe physikalische Basisadresse (z. B. Adresse Null) im Hauptspeicher. Die Fenstertechnik-Funktion wird benötigt, um Standard-Betriebssysteme in verschiedenen Partitionen auf den Computersystemen auszuführen, da Standard-Betriebssysteme (z. B. Unix, Windows NT usw.) typischerweise erwarten, dass realer Speicher bei Adresse Null beginnt.
Durch die Zurückforderung wird Hauptspeicher zurückgefordert, der sich hinter Speicher-konformem E/A-Adressraum befindet, welcher z. B. mit Peripheral Component Interface (PCI), Advanced Programmable Interrupt Controller (APIC) und Speicher-konformen Grundsystem- und E/A-Geräten (z. B. Floppy-Controller, seriellen Ports, parallelen Ports usw.) belegt ist und für das Computersystem unbrauchbar wäre, wenn er nicht verschoben würde. Das heißt, Speicheradressen, die von jedem Betriebssystem E/A-Geräten zugewiesen werden, werden zurückgefordert, so dass das Betriebssystem zusätzlichen Speicherplatz im Hauptspeicher zu haben scheint.
Die Übersetzung bildet eine Speicher-Referenz auf eine angegebene Speichereinheit ab. Systemspeicher-Adressen können verschachtelt oder zwischen Speichereinheiten gestapelt werden, je nachdem, wie das Computersystem mit Speichereinheiten bestückt ist.
In einer exemplarischen Ausführungsform schließt das Computersystem eine Vielzahl von Verarbeitungsmodulen ein. Ein Verarbeitungsmodul kann ein Pod oder ein Sub-Pod sein. Ein Pod umfasst zwei Sub-Pods. In einer bevorzugten Ausführungsform schließt eine Maximalkonfiguration des Computersystems vier Pods, d. h. acht Sub-Pods, ein. Gemäß der vorliegenden Erfindung kann das Computersystem sowohl auf Pod- als auch auf Sub-Pod-Grenzen aufgeteilt sein. So kann in der bevorzugten Ausführungsform, in der eine Maximalkonfiguration aus acht Sub-Pods besteht, das Computersystem in maximal acht Partitionen unterteilt sein, von denen jede durch einen separaten Sub-Pod bestimmt wird. Weiterhin arbeitet gemäß der vorliegenden Erfindung jede Partition unter der Kontrolle ihres eigenen Betriebssystems. Die Betriebssysteme, die auf verschiedenen Partitionen ausgeführt werden, können verschiedene Betriebssysteme oder verschiedene Instanzen desselben Betriebssystems sein.
Die Erfindung stellt weiter eine globale Vorgehensweise mit einem gemeinsam genutzten Speicherbereich dar, um Daten von Partitionen auf dem Computersystem gemeinsam nutzen zu lassen. In einer Ausführungsform stellt der globale Ansatz mit gemeinsam genutztem Speicherbereich für jede Partition ein exklusives Speicherfenster im Hauptspeicher bereit, zuzüglich eines gemeinsam benutzten Speicherfensters, auf das mehrere Partitionen zugreifen können. Die Partitionen, einschließlich ihrer Betriebssysteme und/oder anderer Clients, die in den Partitionen ausgeführt werden, können miteinander über das gemeinsam benutzte Speicherfenster kommunizieren.
Die Kommunikation zwischen Partitionen über den gemeinsam genutzten Speicherbereich kann durch eine Vielzahl von Verfahren verwaltet werden. In einer Ausführungsform wird die Kommunikation zwischen Partitionen über den gemeinsam genutzten Speicherbereich gemäß einem Interrupt-gesteuerten Verfahren verwaltet. In einer anderen Ausführungsform wird eine Abfragetechnik angewandt, um die Kommunikation über den gemeinsam genutzten Speicherbereich zu verwalten.
Wie hierin verwendet, bezeichnet der Begriff "Computersystem" Hardware, einschließlich elektronischer und mechanischer Komponenten, und Software, einschließlich Anwendungsprogrammen und Betriebssystemen. Im Allgemeinen schließen Betriebssysteme eine Anleitung und Daten ein, die ein Computer verarbeitet, um seine Aufgaben auszuführen. Die Hardware liefert die grundlegenden Rechner-Ressourcen. Die Software bestimmt die Art und Weise, wie diese Ressourcen verwendet werden, um die Berechnungsprobleme von Benutzern zu lösen.
Wie hierin verwendet, bezeichnet der Begriff "Betriebssystem" den Programmcode, der die Aufteilung der Hardware unter den verschiedenen Anwendungsprogrammen für unterschiedliche Benutzer steuert und koordiniert. Das Betriebssystem ist der erste Programmcode, der nach Einschalten eines Computersystems in den Hauptspeicher des Computersystems geladen wird. Der Kern des Betriebssystems bleibt immer an dem Speicherraum. Wie hierin verwendet, bezeichnet der Begriff "Betriebssystemadresse" den physikalischen Adressraum (Speicher und E/A) eines Prozessors eines Computersystems und ist der Adressraum eines herkömmlichen Computersystems, wie von der Perspektive eines Betriebssystems aus gesehen, das auf diesem Computersystem ausgeführt wird.
Wie hierin verwendet, bezeichnet der Begriff "Rechner-Architektur" die Struktur und das Verhalten eines Computers, wie vom Benutzer aus gesehen. Er betrifft die Spezifikationen der verschiedenen Funktionsmodule, wie z. B. Prozessoren und Speicher, und ihre Strukturierung in einem Computersystem. Die Rechner-Architektur wird mit Hilfe von Hardware implementiert.
Wie hierin verwendet, bezeichnet der Begriff "Speichereinheit" ein Speicherraum, die in der Lage ist, Informationen zu speichern. Jede Speichereinheit schließt eine Vielzahl von Speichereinheiten, manchmal als Speicheradressbereiche von DRAM (Dynamic Random Access Memory) bezeichnet, ein. Wie hierin verwendet, bezeichnet der Begriff "Speichereinheit-Adresse" eine Adress-Stelle wie von der Perspektive des Computersystems aus gesehen.
Wie hierin verwendet, bezeichnet der Begriff "Partition" ein oder mehrere Verarbeitungsmodul(e), das (die) unter der Kontrolle einer einzigen Instanz eines Betriebssystems steht (stehen). Der Begriff "Partition" wird hierin verwendet, um Folgendes, ganz oder teilweise, zu bezeichnen: das (die) Verarbeitungsmodul(e) der Partition, das Betriebssystem, das auf der Partition ausgeführt wird, jedes exklusive Speicherfenster, das der Partition zugewiesen ist, andere Clients oder Anwendungsprogramme, die auf der Partition ausgeführt werden, oder eine beliebige Kombination davon.
Wie hierin verwendet, bezeichnet der Begriff "Verarbeitungsmodul" eine Vielzahl von Prozessoren, die zusammenwirken. Wie in der unten beschriebenen bevorzugten Ausführungsform veranschaulicht, sind sowohl Pods als auch Sub-Pods Beispiele für Verarbeitungsmodule. Ein oder mehrere Pods oder Sub-Pods (d. h. ein oder mehrere Verarbeitungsmodule) können als Partition innerhalb des Computersystems definiert sein.
Wie hierin verwendet, bezeichnet der Begriff "Programmcode" einen Befehlssatz, der, wenn er von einer Maschine, wie z. B. einem Computersystem oder Prozessor, ausgeführt wird, das Computersystem oder den Prozessor zur Durchführung einer Operation veranlasst. Da jedoch erkannt wird, dass manche Operationen oder manche Funktionalität in einem Computersystem festcodiert sein können, in Form von Schaltkreisen, die die Operation oder Funktion ausführen, oder von einer Kombination aus ausführbaren Befehlen und Schaltungen durchgeführt werden kann, schließt der Begriff "Programmcode" auch solche Schaltungen oder Kombinationen aus ausführbaren Befehlen und Schaltungen ein.
II. Computersystem-Plattform
1 zeigt ein Mehrprozessorsystem, das Prozessormodule 110, 112 und 114 einschließt. Die Prozessormodule 110, 112 und 114 sind von vergleichbarer Kompatibilität. Die vorliegende Erfindung sieht jedoch weiter vor, dass heterogene Prozessoren und/oder Betriebssysteme koexistieren können. Jedes Prozessormodul 110, 112 und 114 ist eigenständig. Die Prozessormodule 110, 112 und 114 können jeweils eine Vielzahl von Prozessoren einschließen. Zwei oder mehr der Prozessormodule 110, 112 und 114 haben gemeinsamen Zugriff auf den Hauptspeicher (oder globalen Speicher) 160 und/oder auf die E/A-Geräte 120, 122 und 124, typischerweise durch einen Systemverbindungs-Mechanismus, wie z. B. die Systemverbindung 130. Die Prozessormodule 110, 112 und 114 können miteinander über den Hauptspeicher 160 kommunizieren (durch Nachrichten und Zustandsmeldungen, die in gemeinsamen Datenbereichen hinterlassen werden).
Gemäß der vorliegenden Erfindung können ein oder mehrere Prozessormodule als separate Partition innerhalb des Computersystems ausgebildet sein, so dass mehrere Partitionen innerhalb des Computersystems existieren können, wobei jede Partition unter der Kontrolle eines eigenen Betriebssystems arbeitet. Zum Beispiel kann jedes Prozessormodul 110, 112 und 114 in 1 als separate Partition definiert sein, die durch ein separates Betriebssystem 170, 172 und 174 kontrolliert wird. Jedes Betriebssystem 170, 172 und 174 sieht den Hauptspeicher separat, als ob es die einzige Einheit wäre, die auf den Hauptspeicher 160 zugreift.
Es sollte zwischen Mehrprozessor-Systemen und Mehrcomputer-Systemen unterschieden werden. Ein Mehrcomputer-System ist ein System, in dem Computer miteinander durch Kommunikationsleitungen verbunden sind, um ein Computernetzwerk zu bilden. Die Computer sind autonom und können miteinander kommunizieren oder nicht. Kommunikation zwischen den Computern erfolgt entweder über feste Wege oder über einen Sendungsvermittlungs-Mechanismus. Ein herkömmliches Mehrprozessor-System hingegen wird von einem Betriebssystem kontrolliert, das für Interaktion zwischen den Prozessoren sorgt, und alle Komponenten des Systems wirken zusammen, um eine Lösung für ein Problem zu finden.
2 ist eine detaillierte Darstellung einer bevorzugten Ausführungsform eines Computersystems 200 gemäß der vorliegenden Erfindung. Das Computersystem 200 schließt einen Hauptspeicher, hier als Hauptspeicher 160 dargestellt, und eine Vielzahl von Verarbeitungsmodulen 240 ein, die über entsprechende Thrid-Level-Cache-Module 230 und Crossbar-Verbindungen 290 mit dem Hauptspeicher verbunden sind. In dieser Ausführungsform sind die Verarbeitungsmodule und der Hauptspeicher in einer symmetrischen Mehrprozessor-Architektur angeordnet, d. h., die Prozessor-zu-Speicher-Latenzzeit ist für alle Verarbeitungsmodule über den gesamten Hauptspeicher hinweg identisch.
In der vorliegenden Ausführungsform ist der Hauptspeicher 160 ein verzeichnisbasiertes Speichersystem und kann verschiedene Speicherkonsistenz-Modelle unterstützen, wie z. B. Speicherkonsistenz-Modelle, die auf UNIX/NT-Systemen verwendet werden. Der Hauptspeicher 160 schließt eine Vielzahl von Speichereinheiten (memory storage units, MSUs) 220 ein, wie z. B. die Speichereinheiten 220A, 220B, 220C und 220D. Vorzugsweise schließt jede Speichereinheit 220A, 220B, 220C und 220D mindestens acht Gigabyte Speicher ein. Vorzugsweise schließt jede Speichereinheit 220A, 220B, 220C und 220D sechzehn halb unabhängige Speicheradressbereiche ein, die vier doppelt breite Datenbusse und acht unidirektionale Adressbusse gemeinsam nutzen.
Die Vielzahl von Thrid-Level-Cache-Modulen 230, wie z. B. Thrid-Level-Cache-Module 230A bis 230D, schließt eine Vielzahl von Thrid-Level-Cache-anwendungsspezifischen integrierten Schaltungen (oder TCTs), wie z. B. TCTs 270A bis 270H, ein. In der vorliegenden Ausführungsform teilen sich jeweils zwei Prozessoren (z. B. 240A und 240B) einen gemeinsamen Bus (z. B. 280A) mit einer einzigen TCT (z. B. 270A) innerhalb eines bestimmten TLCs (z. B. 230A). Jede TCT 270 führt Adressenverschiebung, -zurückforderung und -übersetzung für Speicheradressen durch, die von den Prozessoren ausgegeben werden, mit denen sie verbunden ist, wie unten genauer beschrieben.
Jedes Thrid-Level-Cache-Modul 230A bis 230D ist mit einer entsprechenden Vielzahl von Prozessoren (MPs) 240A bis 2405 verbunden. Speziell ist in der vorliegenden Ausführungsform jeder TLC 230 mit vier Prozessoren verbunden. Jeder TLC 230 und seine dazugehörigen vier Prozessoren bestimmen einen Sub-Pod. Weiterhin sind gemäß der vorliegenden Ausführungsform zwei Sub-Pods durch eine Crossbar-Verbindung (z. B. Crossbar-Verbindung 290A oder 290B) verbunden, um einen Pod zu bilden. So sind in der in 2 dargestellten Ausführungsform vier Sub-Pods durch Crossbar-Verbindungen 290A bzw. 290B verbunden, um zwei Pods zu bilden.
Crossbar-Verbindungen 290 verbinden Prozessoren 240 durch Thrid-Level-Caches 230 mit Speichereinheiten 220. Crossbar-Verbindungen 290 nutzen eine Crossbar-Speicher-Vorgehensweise, wodurch eine Vielzahl von Koppelpunkten an Schnittpunkten zwischen den Prozessoren 240 und den Speichereinheiten 220 platziert werden. Innerhalb des Koppelpunkts ist ein Schalter, der den Weg von einem Prozessorbus 280 zu einer Speichereinheit 220 bestimmt. Jeder Schalter hat eine Steuerlogik, um den Übertragungsweg zwischen einem Prozessor 240 und dem Hauptspeicher 160 zu bestimmen. Die Steuerlogik untersucht die Adresse, die auf den Prozessorbus 280 platziert wird, um zu ermitteln, ob ihre jeweilige Speichereinheit 220 adressiert wird. Die Steuerlogik bearbeitet auch Mehrfachanforderungen nach Zugriff auf dieselbe Speichereinheit 220 auf der Grundlage vordefinierter Priorität. Jede Crossbar-Verbindung 290 umfasst weiter zwei Third-Level-Cache Memory Interface-anwendungsspezifische integrierte Schaltkreise (TCMs) 285, die Adressenverschiebung, -zurückforderung und -übersetzung für Speicheranforderungen von E/A-Geräten durchführen wie unten detaillierter beschrieben.
Das Computersystem 200 schließt weiter die E/A-Busse 210A bis 210D und eine Vielzahl von Peripheral Component Interconnects (PCIs) ein, wie z. B. die PCIs 260A bis 260D, die durch direkte E/A-Brücken (direct I/O bridges, DIB) 250A bis 250D, verbunden sind.
Während des Betriebs kommunizieren die Speichereinheiten 220 bidirektional über Crossbar-Verbindungen 290 mit Third-Level-Cache-Modulen 230. Die Crossbar-Verbindungen 290 kommunizieren bidirektional über die E/A-Busse 210 mit den direkten E/A-Brücken 250 und über die TCTs 270 mit den Prozessoren 240. Direkte E/A-Brücken 250 kommunizieren bidirektional mit Peripheral Component Interconnects 260.
In der vorliegenden Ausführungsform können die Prozessoren (MPs) 240 Intel-Prozessoren (z. B. Pentium Pro, Pentium II Xeon, Merced), Unisys E-Mode-Style-Prozessoren (verwendet in der Unisys A-Serie und Clearpath HMP NX Enterprise Servern) oder Unisys 2200 Style-Prozessoren (verwendet in Unisys 2200 und Clearpath HMP IX Enterprise Servern) umfassen. Vorzugsweise verwendet ein bestimmter Sub-Pod vier Prozessoren desselben Typs. Die vorliegende Erfindung sieht jedoch vor, dass verschiedene Sub-Pods verschiedene Arten von Prozessoren verwenden können. Zum Beispiel kann ein Sub-Pod vier Intel-Prozessoren verwenden, während ein anderer Sub-Pod vier Unisys E-Mode-Style-Prozessoren verwenden kann. In einer solchen Konfiguration kann der Sub-Pod, der Intel-Prozessoren verwendet, als eine Partition bestimmt werden und unter der Kontrolle eines Intel-kompatiblen Betriebssystems laufen, wie z. B. einer Version von Unix oder Windows NT, während der Sub-Pod, der Unisys E-Mode-Style-Prozessoren verwendet, als eine andere Partition bestimmt werden und unter der Kontrolle des Unisys MCP-Betriebssystems ausgeführt werden kann. Als weitere Alternative können die Sub-Pods in zwei verschiedenen Partitionen beide Intel-Prozessoren verwenden, aber eine Partition kann unter der Kontrolle eines Intel-kompatiblen Betriebssystems (z. B. Windows NT) laufen, während die andere Partition unter der Kontrolle des Unisys MCP-Betriebssystems ausgeführt werden kann, durch Emulation der Rechner-Architektur der Unisys A-Serie auf den Intel-Prozessoren in dieser Partition.
Zusätzliche Details der Architektur der bevorzugten Ausführungsform des Computersystems 200 in 2 werden in den vorhergehenden gleichzeitig anhängigen Anmeldungen, die auf den Inhaber des vorliegenden Patents übertragen wurden, erläutert, die in dem Abschnitt mit dem Titel "Querverweis auf andere Anmeldungen" aufgeführt sind und von denen jede hierin vollständig durch die Bezugnahme eingeschlossen ist.
Wie oben erwähnt, ist gemäß der vorliegenden Erfindung das Computersystem 200 auf Pod- und Sub-Pod-Grenzen aufteilbar. In 28 ist ein Teil 2801 des Computersystems 200 dargestellt, der Pod- und Sub-Pod-Grenzen einschließt. Ein Pod 2802 schließt eine Crossbar-Verbindung 290A, einen ersten Sub-Pod 2804A und einen zweiten Sub-Pod 2804B ein. Die Sub-Pods 2804A und 2804B sind einander im Wesentlichen ähnlich. Der Sub-Pod 2804A schließt z. B. den Third-Level-Cache 230A ein, der die TCTs 270A und 270B einschließt. Der Sub-Pod 2804 schließt weiter die Prozessoren 240A–240D ein. Der Pod 2802 schließt somit zwei TLCs 230, vier TCTs 270, acht Prozessoren 240 und eine Crossbar-Verbindung 290 ein.
In der vorliegenden Ausführungsform schließt eine Maximalkonfiguration des Computersystems 200 vier Pods 2802 ein, wobei jeder Pod 2802 zwei Sub-Pods 2804 einschließt wie oben beschrieben. So schließt in der Maximalkonfiguration das Computersystem 200 (4 Pods)·(8 Prozessoren pro Pod) = 32 Prozessoren ein. Das Computersystem 200 kann auf jeder Kombination von Pod- oder Sub-Pod-Grenzen partitioniert werden. Es versteht sich jedoch, dass die vorliegende Erfindung andere Mehrprozessor-Umgebungen und -Konfigurationen berücksichtigt. Zum Beispiel könnte das Computersystem 200 durch den Anschluss weiterer Speichereinheiten 220 und weiterer Pods oder Sub-Pods erweitert werden.
In einer Ausführungsform ist der Pod 2802 so definiert, dass er die direkten E/A-Brücken 250A und 250B einschließt. In einer Ausführungsform sind die Sub-Pods 2804 und 2806 so definiert, dass sie die direkten E/A-Brücken 250A bzw. 250B einschließen.
Weiterhin arbeiten gemäß der vorliegenden Erfindung mehrere Partitionen innerhalb des Computersystems, von denen jede einen oder mehrere Pods oder Sub-Pods umfassen kann; jede arbeitet unter der Kontrolle eines eigenen Betriebssystems. Auf den verschiedenen Partitionen können dasselbe oder verschiedene Betriebssysteme ausgeführt werden. Zum Beispiel sieht die vorliegende Erfindung eine Umgebung vor, worin mindestens zwei der Betriebssysteme unterschiedlich sind und ein Betriebssystem das andere nicht kontrolliert oder verwaltet.
5 zeigt eine exemplarische Speicherkonfiguration, die auf dem Computersystem in 2 erzeugt werden kann, in Übereinstimmung mit dem Aufteilbarkeits-Merkmal der vorliegenden Erfindung. In diesem Beispiel hat jedes von drei Betriebssystemen (operating systems, OS) seinen eigenen Adressraum 502 (d. h. die physikalischen Adressräume der jeweiligen Verarbeitungsmodule, auf denen diese Betriebssysteme ausgeführt werden). Der Hauptspeicher 160 hat einen Adressraum 504. Gemäß der vorliegenden Erfindung sind im Adressraum 504 des Hauptspeichers 160 drei exklusive Speicherfenster 540A, 540B und 540C, eines für jedes Betriebssystem (d. h. jede Partition), und ein gemeinsam benutztes Speicherfenster 537 definiert, auf das alle drei Betriebssysteme 540A, 540B und 540C (d. h. alle Partitionen) zugreifen können.
Zum Beispiel schließt OS#1 in seinem Adressraum ein Fenster für den unteren Speicherbereich ein, z. B. das Fenster 511 für den unteren Speicherbereich, eine Lücke für den unteren Speicherbereich, z. B. die Lücke 512 für den unteren Speicherbereich, ein Fenster für den oberen Speicherbereich, wie z. B. das Fenster 513 für den oberen Speicherbereich, einen Abschnitt, der als gemeinsam benutztes Speicherfenster definiert ist, wie z. B. das gemeinsam benutzte Speicherfenster 514, und eine Lücke für den oberen Speicherbereich, z. B. die Lücke 515 für den oberen Speicherbereich. Das Fenster 511 des unteren Speicherbereichs, die Lücke 512 des unteren Speicherbereichs, das Fenster 513 des oberen Speicherbereichs und die Lücke 515 des oberen Speicherbereichs sind exklusiv für das Betriebssystem OS#1. Der Teil des Adressraums, der als gemeinsam benutztes Speicherfenster 514 definiert ist, ist zur gemeinsamen Nutzung bestimmt.
Wie hierin verwendet, bezeichnet "Lücke des oberen Speicherbereichs" Speicherplatz in einem oberen Adressbereich einer Speichereinheit, der nicht für die Speicherung von Daten oder Befehlen zur Verfügung steht, weil die dazugehörige Adresse einem E/A-Gerät zugewiesen wurde. Wie hierin verwendet, bezeichnet "Lücke des unteren Speicherbereichs" Speicherplatz in einem unteren Adressbereich einer Speichereinheit, der nicht für die Speicherung von Daten oder Befehlen zur Verfügung steht, weil die dazugehörige Adresse einem E/A-Gerät zugewiesen wurde. Wie hierin verwendet, ist ein "Fenster" ein Adressbereich, der eine Obergrenze und eine Untergrenze hat. Die Einsehbarkeit des Fensters und der Zugriff darauf werden durch Eigentumsrechte gesteuert. Wie hierin verwendet, bezeichnet "gemeinsames Fenster" einen Adressbereich, an dem mindestens zwei Betriebssysteme gemeinsame Eigentumsrechte haben. Das heißt, mehrere Betriebssysteme haben Einsehbarkeit in und Zugriff auf ein gemeinsames Fenster. Wie hierin verwendet, bezeichnet der Begriff "exklusives Fenster" einen Adressbereich, an dem nur ein Betriebssystem Eigentumsrechte hat. Das heißt, nur ein Betriebssystem darf ein exklusives Fenster einsehen oder darauf zugreifen. Nichtsdestotrotz werden Datenkohärenz und -konsistenz zwischen den Betriebssystemen aufrechterhalten.
Die Adressräume von OS#2 und OS#3 haben eine ähnliche Struktur wie das Betriebssystem OS#1. Der Kürze halber werden diese Adressräume nicht detailliert beschrieben.
Der Adressraum vieler Prozessoren besteht sowohl aus Hauptspeicher- als auch aus Speicher-konformen Eingabe-/Ausgabe(E/A)-Adressen. Hauptspeicher-Transaktionen werden an die Hauptspeichereinheiten gerichtet. E/A-Transaktionen werden an das E/A-Teilsystem weitergeleitet. Da die E/A-Adressen auf zusätzlichen Speicher außerhalb des Hauptspeichers zugreifen, könnte das System am Ende eine Prozessoradresse haben, die auf zwei Speicherstellen verweist. Der Konsistenz halber muss eine dieser Speicherstellen deaktiviert werden. Die Deaktivierung dieser Hauptspeicherstellen erzeugt eine Lücke in der Hauptspeicheradressierung und führt dazu, dass Speicher unbenutzt bleibt. Wenn der E/A-Speicher-Adressraum groß ist, bleibt ein signifikanter Datenblock des Speichers unbenutzbar. Wenn mehrere OS-Partitionen dem System hinzugefügt werden, werden mehrere E/A-Lücken erzeugt, was in potentiell zahlreichen Lücken resultiert, die über den Hauptspeicher-Adressraum verstreut sind. Gemäß der vorliegenden Erfindung werden, wie in 5 dargestellt, Lücken im unteren Speicherbereich, wie z. B. die Lücken 511, 541 und 571 des unteren Speicherbereichs, und Lücken im oberen Speicherbereich, wie z. B. die Lücken 515, 545 und 575 des oberen Speicherbereichs, zurückgefordert und auf einen zusammenhängenden Adressraum erneut abgebildet, wie er für den MSU-Speicherplatz 504 dargestellt ist. Der MSU-Speicherplatz 504 ist eine konzeptuelle Darstellung des Hauptspeichers 160. Die Zurückforderung ist unten detaillierter beschrieben.
Zum Beispiel schließt der zusammenhängende Adressraum des MSU-Adressraums 504 einen unteren Speicherbereich, wie den unteren Speicherbereich 531, 533 und 535, einen oberen Speicherbereich, wie den oberen Speicherbereich 532, 534 und 536, und einen gemeinsamen Speicherbereich, wie den gemeinsamen Speicherbereich 537, ein. Der untere Speicherbereich 531 und der obere Speicherbereich 532 umfassen ein exklusives Fenster, das exklusiv für das Betriebssystem OS#1 ist. Der untere Speicherbereich 533 und der obere Speicherbereich 534 umfassen ein exklusives Fenster, das exklusiv für das Betriebssystem OS#2 ist. Der untere Speicherbereich 535 und der obere Speicherbereich 536 umfassen ein exklusives Fenster, das exklusiv für das Betriebssystem OS#3 ist. Es gibt keine Speicher-Adressierungslücken im Hauptspeicher 160. Der zusammenhängende Adressraum des Hauptspeichers 160 wird unabhängig von Speichererweiterung, Art der Referenzübersetzung (unten detailliert beschrieben) oder der Umgebung des gemeinsamen Speicherbereichs verwaltet.
A. Speicherfenster (Verschieben und Zurückfordern)
Ein Fenster ist ein Adressbereich, der durch (Adress-)Ober- und Untergrenzen begrenzt wird. Zugriff auf und Einsehbarkeit in diesen Bereich sind durch Eigentumsrechte beschränkt. Die vorliegende Erfindung stellt zwei Arten von Fenstern bereit: exklusive und gemeinsame.
Eine einzige Partition/ein einziges Betriebssystem hat das Eigentumsrecht an einem exklusiven Fenster. Jede Instanz eines Betriebssystems muss innerhalb der Grenzen ihres eigenen Fensters arbeiten. Der Adressraum dieses Fensters ist nicht sichtbar, und andere Partitionen/Betriebssysteme können nicht darauf zugreifen. In einer bevorzugten Ausführungsform beginnen alle Fenster an einer mod 32MB-Adressgrenze. Andere Grenzen werden jedoch von der vorliegenden Erfindung ebenfalls berücksichtigt. Aus der Sicht eines Betriebssystems, vor allem eines Standard-Betriebssystems wie Unix und Windows NT, beginnt sein Adressraum (d. h. der physikalische Adressraum des Prozessors/der Prozessoren, auf dem/denen es ausgeführt wird) immer bei der Adresse Null (d. h., seine Untergrenze ist Null), wie im linken Teil von 5 dargestellt. Aus der Perspektive des Hauptspeichers 160 beginnt der Adressbereich bei einem Verschiebungs(R_L-)Wert. Der R_L-Wert ist unten detailliert beschrieben. In einer bevorzugten Ausführungsform wird die Obergrenze eines exklusiven Fensters auf eine Basisadresse eines gemeinsamen Fensters, S_Base ^OS, gesetzt.
Ein gemeinsames Fenster ist ein Adressbereich mit einer Ober- und einer Untergrenze, worin mehrere Betriebssysteme (d. h. Partitionen) in diesen Raum einsehen und darauf zugreifen können, während jedes in seinem eigenen exklusiven Fenster ausgeführt wird. Das gemeinsame Fenster ist ein gemeinsam genutzter Bereich, über den verschiedene Partitionen, einschließlich z. B. ihrer Betriebssysteme, kommunizieren und Daten austauschen können. Dieser Bereich beginnt in einer bevorzugten Ausführungsform ebenfalls an einer mod 32MB-Adressgrenze. Das gemeinsame Fenster kann N × 32MB groß sein. Mit einem gemeinsamen Fenster sind zwei Konfigurationsparameter verbunden. Einer enthält die Basisadresse für den Teil, der als gemeinsames Fenster im Adressraum des Betriebssystems definiert ist, S_BASE ^OS (d. h. die Basisadressen der Abschnitte 514, 544 und 574 bei OS#1, OS#2 bzw. OS#3). Der andere enthält die Basisadresse für den entsprechenden gemeinsam genutzten Raum, S_BASE ^MSU, im Adressraum 504 des Hauptspeichers 160. In einer bevorzugten Ausführungsform ist die Obergrenze für den gemeinsam genutzten Bereich jedes Betriebssystems der Wert "Speicherende" für dieses Betriebssystem. Die Untergrenze, S_BASE ^OS, muss auf einer mod 32MB-Adressgrenze liegen. Falls exklusive Bereiche freigegeben sind, sollte sich die Speicherstelle des gemeinsamen Speicherbereichs 537 im MSU-Speicherbereich 504 oberhalb der jeweiligen exklusiven Fenster aller Betriebssysteme befinden, die diesen Bereich gemeinsam nutzen. Dieses letzte Erfordernis wird als Hardwaredesign-Kompromiss durchgesetzt. Der gemeinsame Bereich ist durch eine Obergrenze, T^OS, begrenzt, welche die Speicherende-Referenz eines Betriebssystems aus der Adressierungs-Sicht des Betriebssystems ist. Eine Adresse oberhalb von T^OS wird eingefangen und nie an den Hauptspeicher 160 weitergeleitet. Somit ist der gemeinsame Speicherbereich 537 vollständig begrenzt.
In anderen hierin berücksichtigten Konfigurationen kann jedes Betriebssystem mit den anderen Betriebssystemen in einem vollständig gemeinsam genutzten Raum koexistieren. Ein Beispiel hierfür ist, wenn ein gesamter MSU-Block auf "gemeinsam genutzt" gesetzt wird. In diesem Fall kann jedes Betriebssystem so konfiguriert werden, dass der Adressraum des anderen Betriebssystems eingesehen werden kann. Bei einer solchen Konfiguration liegt die Last der Verwaltung von Zugriffsrechten auf einzelne Speicherseiten auf den zusammenwirkenden Betriebssystemen. Die Hardware beschränkt Zugriffe und Einsehbarkeit nicht mehr auf einzelne Betriebssysteme. Die Betriebssysteme müssen Zugriffsrechte auf Speicherseiten durch Prozessor-Seiten-Steuerung oder ein anderes Mittel kontrollieren, um zu verhindern, dass ein Prozess den Speicher korrumpiert. Diese Arbeitsweise wird von zusammenwirkenden Betriebssystemen verwendet. Ein Betriebssystem kann die Speicherseite eines anderen Betriebssystems direkt lesen. Auch kann die Instanz eines Betriebssystems Daten, die für ein anderes Betriebssystem bestimmt sind, direkt in den Datenbereich des anderen Betriebssystems laden und dabei jede temporäre Pufferung umgehen. 10 zeigt ein Beispiel für diese Art von Konfiguration. In 10 ist jedes Betriebssystem so konfiguriert, dass sein gemeinsam genutzter Bereich eine Ansicht des gesamten MSU-Speichers, einschließlich einer Kopie seiner eigenen Betriebssystem-Instanz, bietet. Diese kopierte Adresse wird im Folgenden als "Schattenadresse" bezeichnet. Der Adressbereich, der sich innerhalb der Ansicht jedes Betriebssystems unterhalb des gemeinsamen Bereichs befindet, wird als "lokale Adresse" bezeichnet.
In der vorliegenden Ausführungsform begrenzt die vorlie gende Erfindung die Verknüpfung eines exklusiven Fensters mit maximal einem gemeinsamen Fenster. In anderen Ausführungsformen könnte ein exklusives Fenster jedoch mit mehreren gemeinsamen Fenstern verknüpft sein. In einem solchen Fall gäbe es separate S_BASE ^MSU – und S_BASE ^OS-Werte für jedes dieser gemeinsamen Fenster.
Gemäß der vorliegenden Erfindung wird der physikalische Adressraum des Verarbeitungsmoduls (der Verarbeitungsmodule) jeder Partition (d. h. der Adressraum, wie er vom Betriebssystem auf dieser Partition gesehen wird) auf das entsprechende exklusive Speicherfenster, das dieser Partition im Adressraum 504 des Hauptspeichers 160 zugewiesen ist, abgebildet oder dorthin verschoben. Für Erläuterungszwecke ist der Adressraum des Hauptspeichers 160 als einzelner Speicherblock zu betrachten. Die vorliegende Erfindung erwägt jedoch weiter eine Übersetzungsfunktion (unten beschrieben), in der Adressen zusätzlich auf eine einzelne Speichereinheit 220 abgebildet werden, um eine Adressenverschachtelung zwischen Speichereinheiten 220 herzustellen.
Als weiteres Beispiel stellt die 4 ein einfaches System dar, das zwei Betriebssysteme OS0 und OS1 enthält, von denen jedes 2GB Speicherplatz im Hauptspeicher 160 belegt. Jeder Betriebssystem-Adressraum hat seinen eigenen Speicher-konformen E/A-Raum 415 und 435. In diesem Beispiel überlagern die Lücken, die mit dem Speicher-konformen E/A zusammenhängen, nicht den DRAM-Speicherbereich.
An diesem Punkt können die Begriffe Verschiebung (R_L) und Zurückforderung R_C weiter beschrieben werden. Verschiebung ist die Zuweisung einer Basisadresse zu einem exklusiven Speicherfenster. Diese Basisadresse ist die Startadresse (d. h. der Offset von der Adresse Null) für dieses Fenster im Adressraum des Hauptspeichers 160 und muss auf einer mod 32MB-Adressgrenze liegen. In 4 ist der R_L-Wert für das Betriebssystem-Fenster 430 (OS0) Null, da das Fenster am unteren Ende des Hauptspeichers 160 beginnt. Das Betriebssystem-Fenster 410 (OS1) hat einen R_L-Wert von 2GB, da die Null-Position seiner physikalischen Adresse in den Adressraum des Hauptspeichers 160 verschoben wurde, der bei 2GB beginnt.
Zurückforderung ist die erneute Abbildung des Adressraums in einem Fenster zum Zurückfordern der Speicherstellen, die hinter einem Speicher-konformen E/A-Adressraum liegen. Falls die Zurückforderung nicht aktiv ist und einem Fenster Speicherkonformer E/A zugewiesen ist, worin der E/A-Bereich unter der Obergrenze des Speichers liegt, wird eine Lücke im Speicher-Adressraum des Fensters erzeugt. Im Beispiel in 4 ist keine Zurückforderung notwendig, da die Lücken, die mit dem Speicherkonformen E/A verbunden sind, nicht den DRAM-Speicherbereich überlagern. In 5 kann jedoch eine Zurückforderung für die Lücken 512, 542 und 572 im unteren Speicherbereich (d. h., wo die Speicher-konformen 32-Bit-E/A-Geräte abgebildet sind) durchgeführt werden. Die Zurückforderung kann als Vergrößerung des verfügbaren Speicheradressraums oberhalb der Lücke, gleich der Größe der Lücke, betrachtet werden. In einer bevorzugten Ausführungsform wird die Zurückforderung nur dann durchgeführt, wenn die Lückengröße 128MB oder mehr beträgt. Dies ist ein Hardware-Kompromiss. Aufgrund von konstruktionsbedingten Kompromissen wird außerdem nur eine Adresslücke pro Betriebssystem-Instanz zurückgefordert. Die vorliegende Erfindung zieht jedoch in Erwägung, dass ein Computersystem ohne Durchsetzung dieser beiden konstruktionsbedingten Kompromisse implementiert werden kann. Die Zurückforderung ist unten detaillierter beschrieben.
Mit erneutem Bezug auf 5 enthalten alle drei Betriebssystem-Adressräume OS#1, OS#2 und OS#3 Speicher-konformen E/A, der den Speicher-Adressraum überlagert. Die Lücke 512 des unteren Speicherbereichs des Betriebssystem-Adressraums OS#1 ist jedoch kleiner als die minimale Blockgröße von 128MB, daher wird keine Zurückforderung durchgeführt. Die Lücke im unteren Speicherbereich wird jedoch für die beiden anderen Betriebssysteme in ihren exklusiven Fenstern 540A bzw. 540B zurückgefordert.
3 zeigt eine andere mögliche Konfiguration, die vier Betriebssystem-Fenster (oder Instanzen) enthält. Hier nutzen OS#1 und OS#4 einen gemeinsamen Bereich, während OS#2 und OS#3 einen anderen nutzen. Es ist anzumerken, dass die Platzierung der einzelnen Fenster in den Adressraum des Hauptspeichers 160 von der R_L-Variable gesteuert wird. 3 stellt nur eine der vielen möglichen Abbildungen dieser Fenster auf den MSU-Speicherplatz 350 dar.
Gemäß der vorliegenden Ausführungsform ist mit jedem Betriebssystem-Fenster ein Konfigurationsregister verbunden, das einen Satz von Konfigurationsparametern bereitstellt: R_L ^OS, R_C ^OS, S_BASE ^OS und S_BASE ^MSU. Verschiedene Fenster-Abbildungen sind durch Änderung der Konfigurationsparameter der Betriebssystem-Fenster leicht zu erzeugen.
TABELLE A zeigt die Konfigurationsregister-Werte für jedes der Betriebssystem-Fenster, die in 5 dargestellt sind. Die Zurückforderung einer Speicherungslücke hängt vom Inhalt des Konfigurationsregisters ab. TABELLE A schließt eine Zeile für jedes relevante Betriebssystem ein. Das Verschiebungs-Feld, R_L ^OS, speichert die Basis-(oder Start-)adresse für das betreffende Betriebssystem-Fenster, wie sie in die Speichereinheit 220 verschoben wurde. Das Zurückforderungs-Feld, R_C ^OS, speichert einen Adressbereich, der der Größe der Lücke im unteren Speicherbereich im betreffenden Betriebssystem-Fenster entspricht. Das gemeinsame Basis-OS-Feld, S_BASE ^OS speichert die Basisadresse für den Teil des Betriebssystem-Adressraums, der als der gemeinsam genutzte Teil definiert ist. Das gemeinsame Basis-MSU-Feld, S_BASE ^MSU, speichert die Basisadresse für das gemeinsame Fenster 537 im Adressraum der Speichereinheit 220.
TABELLE A
In der vorliegenden Ausführungsform enthält die TCT 270 für jedes Paar von Prozessoren 240 das Konfigurationsregister und andere Register und Logik zur Durchführung von Verschiebung, Zurückforderung und Übersetzung, wie hierin beschrieben, für Adressen, die von den Prozessoren ausgegeben werden, die mit dieser TCT verbunden sind. Diese Register und die Logik werden außerdem in den TCMs 285 der Crossbar-Verbindungen 290 repliziert, da die TCMs 285 dieselben Verschiebungs-, Zurückforderungs- und Übersetzungsarbeiten bei Speicheranforderungen durchführen müssen, die von einem E/A-Prozessor (z. B. einer PCI-Karte) über eine entsprechende DIB 250 empfangen werden.
Im physikalischen Adressraum der Prozessoren jeder Partition bestimmen die TCTs 270 dieser Partition einen Adressbereich für den unteren Speicherbereich, oberen Speicherbereich, Lücken im unteren Speicherbereich, Lücken im oberen Speicherbereich und den gemeinsamen Speicherbereich. Zum Beispiel beginnt im Adressraum des Betriebssystems OS#3 das Fenster 571 des unteren Speicherbereichs an der Adress-Stelle 0.000_H und schließt 3,875 Gigabyte Speicherplatz ein. Das Fenster 573 des oberen Speicherbereichs beginnt an der Adress-Stelle 1.5000.000_H und schließt 5,250 Gigabyte Speicherplatz ein. Die Lücke 572 des unteren Speicherbereichs schließt 125 Megabyte nicht benutzten Speicherplatz ein, der zurückgefordert werden muss. Die Lücke 575 des oberen Speicherbereichs schließt 250 Megabyte nicht benutzten Speicherplatz ein, der zurückgefordert werden muss.
Bei der Ausführung ihrer Fenstertechnik-Funktion weist jede TCT 270 der vorliegenden Erfindung ihrer Partition weiter ein exklusives Speicherfenster im Adressraum 504 des Hauptspeichers 160 zu. In jedem exklusiven Speicherfenster befindet sich ein Adressbereich für den unteren Speicherbereich und für den oberen Speicherbereich. Zum Beispiel beginnt im exklusiven Fenster 540B das Fenster 533 des unteren Speicherbereichs mit der Adress-Stelle 1.4000.0000_H und schließt 5,000 Gigabyte Speicherplatz ein. Das Fenster 534 des oberen Speicherbereichs beginnt mit der Adress-Stelle 2.8000.000_H und schließt 10,000 Gigabyte ein; es befinden sich also insgesamt 10,500 Gigabyte Speicherplatz im exklusiven Fenster 540B. Im exklusiven Fenster 540A beginnt das Fenster 535 des unteren Speicherbereichs mit der Adress-Stelle 2.A000.0000_H und schließt 5,125 Gigabyte Speicherplatz ein. Das Fenster 534 des oberen Speicherbereichs beginnt mit der Adress-Stelle 3.E800.000_H und schließt 1,625 Gigabyte Speicherplatz ein.
Wenn einer der Prozessoren eines Verarbeitungsmoduls einer bestimmten Partition eine Adresse auf seinen Adresszeilen ausgibt (die "referenzierte Adresse" oder "Prozessoradresse"), passt die TCT 270 für diesen Prozessor die Adresse je nach Bedarf für jede Verschiebung, Zurückforderung oder gemeinsam genutzte Fenstertechnik an, um die Adresse der entsprechenden Speicherstelle im Hauptspeicher 160 zu erzeugen. Während dieses Prozesses werden die Werte in den verschiedenen Feldern des Konfigurations-Registers (TABELLE A) benutzt. Im Speziellen wird die referenzierte Adresse, wenn sie sich in dem Teil des Betriebssystem-Adressraums befindet, der als das gemeinsame Fenster definiert ist, um die Werte versetzt, die im gemeinsamen Basis-OS-Feld und den gemeinsamen Basis-MSU-Feldern des Konfigurations-Registers enthalten sind. Wenn sich die referenzierte Adresse im Fenster des oberen Speicherbereichs des Adressraums des Betriebssystems befindet, wird sie um die Werte versetzt, die in den Verschiebungs- und Zurückforderungs-Feldern des Konfigurations-Registers enthalten sind. Wenn sich die referenzierte Adresse im Fenster des unteren Speicherbereichs des Adressraums des Betriebssystems befindet, wird sie um den Wert versetzt, der in dem Verschiebungs-Feld des Konfigurations-Registers enthalten ist. Wie hierin beschrieben, stellen also die TCTs 270 ein Mittel bereit, um den physikalischen Adressraum der Prozessoren in jeder Partition auf die entsprechenden exklusiven Speicherfenster abzubilden, die jeder Partition zugewiesen sind, und im Speziellen ein Mittel zum Verschieben einer Referenz auf eine Speicherstelle im physikalischen Adressraum der Prozessoren auf einer entsprechenden Partition an die entsprechende Speicherstelle im exklusiven Speicherfenster, das dieser Partition zugewiesen ist. Wie oben erwähnt, führen die TCMs 285 auf ähnliche Weise jede Verschiebung oder Zurückforderung aus, die für Speicheradressen erforderlich ist, welche von einem E/A-Prozessor (z. B. einer PCI-Karte) empfangen werden, der über eine DIB und ein TCM mit dem Hauptspeicher kommuniziert.
TABELLE B zeigt Pseudo-Code zur Implementierung von Verschiebung und Zurückforderung von Betriebssystem-Adressräumen (d. h. den physikalischen Adressräumen der Prozessoren der verschiedenen Partitionen) in ihre entsprechenden exklusiven Speicherfenster im Hauptspeicher. Im Allgemeinen werden Speicher-konforme E/A-Adressen von der TCT 270 herausgefiltert und lassen nur Referenzen auf den Hauptspeicher 160 zurück. Die restlichen Adressen werden dann durch den in TABELLE B dargestellten Algorithmus geführt wie unten detailliert beschrieben. Schließlich wird die verschobene Speicher-Referenz an den Hauptspeicher 160 gegeben.
TABELLE B
8 zeigt ein Flussdiagramm des Adressen-Fenstertechnik-Algorithmus. Es wird außerdem auf TABELLE A verwiesen. Wie in Schritt 810 dargestellt, wird eine Prüfung durchgeführt, um zu bestimmen, ob eine referenzierte Adresse (d. h. eine Adresse, die von einem der Prozessoren eines Verarbeitungsmoduls in einer bestimmten Partition ausgegeben wird, das auf einem bestimmten Betriebssystem ausgeführt wird), OS_ADR, sich in dem Teil des Adressraums des Betriebssystems befindet, der als gemeinsam genutztes Speicherfenster definiert wurde. Wenn dies der Fall ist, wird die referenzierte Adresse anhand der Formel OS_ADR + [S_BASE ^MSU – S_BASE ^OS) an eine Adresse verschoben, wie in Schritt 815 dargestellt. Diese wird als die Verschiebungsadresse bezeichnet, die wiederum verwendet wird, um auf den Hauptspeicher 160 zuzugreifen. Die Verschiebungsadresse ist die Adresse der entsprechenden Speicherstelle im gemeinsam genutzten Speicherfenster, das im Hauptspeicher 160 definiert ist.
Anderenfalls wird eine Prüfung vorgenommen, ob die referenzierte Adresse sich im oberen Speicherbereich des Betriebssystem-Adressraums (z. B. im oberen Speicherbereich 513, 543 oder 573) befindet. Dies ist in Schritt 820 dargestellt. Ist dies der Fall, so wird die referenzierte Adresse anhand der Formel OS_ADR + [R_L ^OS – R_C ^OS] an eine Adresse verschoben wie in Schritt 825 dargestellt. Die Verschiebungsadresse kennzeichnet die entsprechende Speicherstelle im exklusiven Speicherfenster für die Partition.
Ansonsten geht der Algorithmus davon aus, dass die referenzierte Adresse im unteren Speicherbereich des Betriebssystem-Adressraums (z. B. im unteren Speicherbereich 511, 541 oder 571) liegt, wie in Schritt 830 dargestellt. In diesem Fall wird die referenzierte Adresse anhand der Formel OS_ADR + [R_L ^OS] an eine Adresse verschoben. So werden Adressverweise im physikalischen Adressraum eines Prozessors in einer Partition (d. h. dem vom Betriebssystem aus gesehenen Adressraum) an ihre entsprechenden Speicherstellen, entweder im exklusiven Speicherfenster, das für diese Partition im Hauptspeicher definiert ist, oder im gemeinsam genutzten Speicherfenster, das im Hauptspeicher definiert wurde, verschoben.
33 ist ein Blockdiagramm, das eine Vorrichtung, in Form von Registern und Logik, zur Ausführung der oben beschriebenen Verschiebungs- und Zurückforderungs-Funktionen gemäß der bevorzugten Ausführungsform darstellt. Diese Logik wird in jeder TCT 270 zur Durchführung der Verschiebungs- und Zurückforderungs-Funktionen der vorliegenden Erfindung für die Speicheradressen bereitgestellt, die von den mit der TCT 270 verbundenen Prozessoren (MP) 240 ausgegeben werden. Wie zuvor erwähnt, wird diese Logik auch in jedem TCM 285 repliziert, um Verschiebung und Zurückforderung für Speicheradressen durchzuführen, die von einem E/A-Prozessor über eine entsprechende DIB 250 ausgegeben wurden.
Gemäß der bevorzugten Ausführungsform wie in 33 dargestellt wird eine Speicheradresse, die auf den Adresszeilen eines bestimmten Prozessors 240 (oder von einem E/A-Prozessor über eine entsprechende DIB 250) ausgegeben wird, in einem Processor_Address-Register 3310 erfasst. In der bevorzugten Ausführungsform ist der Hauptspeicher in Wörtern mit 8 Byte (1 Wort = 8 Byte = 64 Bit) adressierbar, und daher werden die niedrigstwertigen 3 Bit der Prozessor_Adresse nicht zur Erstellung einer angepassten Adresse benötigt. Daher werden, wie gezeigt, nur die Bits [35:3] im Processor Address-Register 3310 erfasst. Weiterhin wird in der bevorzugten Ausführungsform der Hauptspeicher in Cache-Blöcke mit acht (8) Wörtern (8 Wörter = 64 Byte) gechasht, und daher stellen die Bits [35:6] die effektive Cache-Block-Adresse dar. Wie gezeigt, werden diese Bits in einem anschließenden Cache_Block_Address-Register 3312 erfasst.
Wie oben genauer beschrieben, müssen in der bevorzugten Ausführungsform alle Speicherfenster, ob "exklusiv" oder "gemeinsam genutzt", mit einer mod 32MB-Adressbegrenzung beginnen. Folglich werden bei der Verschiebung einer Prozessoradresse in ein bestimmtes exklusives Speicherfenster oder gemeinsam genutztes Speicherfenster nur die Bits [35:25] der Prozessoradresse für die Berechnung benötigt. Daher werden, wie gezeigt, diese Bits in einem Temporär-Register 3314 erfasst.
Die Werte S_BASE ^MSU, S_BASE ^OS, R_L ^OS und R_C ^OS werden an entsprechenden Register-Speicherstellen 3318, 3320, 3330 und 3340 gespeichert. Gemeinsam umfassen diese Register-Speicherstellen das oben beschriebene Konfigurationsregister. In der Praxis können diese Register-Speicherstellen separate Felder eines einzigen größeren Registers umfassen, oder sie können als vier separate Register implementiert werden. Bei einer Prozessor-Adresse, die in dem Teil des Adressraums des Prozessors liegt, der als gemeinsam genutztes Speicherfenster definiert wurde, subtrahiert ein Subtrahierer 3405 den S_BASE ^OS-Wert an der Register-Speicherstelle 3320 vom S_BASE ^MSU-Wert an der Register-Speicherstelle 3318 und speichert die resultierende Distanzadresse im Register 3350. Bei einer Prozessor-Adresse, die im oberen Speicherbereich des exklusiven Speicherfensters liegt, das der Partition zugewiesen ist, zu welcher der Prozessor gehört, subtrahiert ein Subtrahierer 3410 den R_C ^OS-Wert im Register 3340 vom R_L ^OS-Wert im Register 3330 und speichert die resultierende Distanzadresse im Register 3370. Wie weiter gezeigt, werden die fünf Bit des R_C ^OS-Werts (durch Anwendung einer Verkettungsfunktion 3400) mit zwei logischen Nullbits in den niedrigstwertigen Bitpositionen und vier logischen Nullbits in den höchstwertigen Bitpositionen aufgefüllt, um die Bits zur Subtraktion von den Bits des R_L ^OS-Werts korrekt auszurichten. Es wird daran erinnert, dass in der vorliegenden Ausführungsform eine Zurückforderung nur in Schritten von 128MB durchgeführt werden kann. Im Falle einer Prozessor-Adresse, die im unteren Speicherbereich des exklusiven Speicherfensters des Prozessors liegt, ist der R_L ^OS-Wert im Register 3330 die erforderliche Distanzadresse, und daher wird der Wert direkt im Register 3360 gespeichert.
Address Range Compare Logic (Adress-Bereich-Vergleich-Logik) 3390 führt die oben beschriebenen Schritte durch: die Bestimmung, ob die vom Prozessor ausgegebene Adresse in dem Teil des Adressraums des Prozessors liegt, der als gemeinsam genutztes Speicherfenster definiert ist, oder ob die Adresse entweder im unteren Speicherbereich oder im oberen Speicherbereich des exklusiven Speicherfensters liegt, das der Partition zugewiesen ist, zu welcher der Prozessor gehört. Auf der Grundlage dieses Vergleichs wird die entsprechende Distanzadresse von einem der Register 3350, 3360 oder 3370 mit Hilfe eines 3:1-Selektors 3380 ausgewählt. Ein Addierer 3420 addiert dann die ausgewählte Distanzadresse zu den Bits [35:25] der im Register 3314 gespeicherten Prozessoradresse, und das Ergebnis wird im Register 3430 gespeichert. Die Bits im Register 3430 werden dann vorne an die Bits [24:6] der Cache-Block-Adresse angehängt und bilden so die angepasste Adresse, die in einem Adjusted_Partition_Address-Register 3316 gespeichert wird. Die angepasste Adresse im Register 3316 wird dann verwendet, um auf den Hauptspeicher zuzugreifen (nach weiterer Übersetzung gemäß dem unten beschriebenen Verschachtelungsmechanismus der vorliegenden Erfindung).
Mit erneutem Bezug auf 5 und wie oben bereits erwähnt, können Adressen, die Speicher-konformem E/A zugewiesen wurden, zurückgefordert werden. Diese Adressen werden als Lücken im unteren Speicherbereich, wie z. B. Lücke 512 im unteren Speicherbereich, bezeichnet. In einer bevorzugten Ausführungsform beginnen die Lücken im unteren Speicherbereich immer direkt unterhalb von 4GB und erstrecken sich im Adressraum des dazugehörigen Betriebssystem bis zu einer Tiefe gleich der Größe der Lücke nach unten. Offensichtlich ist die Platzierung der Lücke im unteren Speicherbereich eine konstruktive Entscheidung. Die Speicher-Zurückforderung ist nur dann durchzuführen, wenn die Obergrenze von Speicheradressen für die installierte Speichergröße größer ist als die Untergrenze des überlappenden Speicherbereichs (d. h. 4GB abzüglich der Größe der Überlappungs-Lücke). Mit anderen Worten, eine Zurückforderung sollte nicht in Systemen durchgeführt werden, in denen keine Überlappung zwischen dem PCI APIC-Bereich und dem installierten DRAM-Speicher stattfindet.
Der gesamte überlagerte Speicher und der gesamte Speicherplatz direkt darüber können so dargestellt werden, dass sie im Prozessor-/Betriebssystem-Adressraum nach oben rutschen. Das heißt, dass der Speicherbereich, der dahinter liegt und an der Untergrenze der Lücke beginnt, jetzt bei der Adresse 4GB beginnt und sich von dort aufwärts erstreckt. Die Speicheradressierung bleibt von der 4GB-Startadresse an zusammenhängend und erstreckt sich zur neuen Obergrenze des Speichers, d. h. der ursprünglichen Obergrenze des Speichers zuzüglich der Lückengröße.
11 zeigt die Abbildung eines Adressbereichs anhand eines speziellen Beispiels. Bei Systemen mit 4GB oder weniger Speicher, bei denen eine partielle Speicherüberlappung mit dem PCI APIC-Bereich stattfindet, kann eine Zurückforderung durchgeführt werden. In diesen Systemen wird der überlagerte Speicher so abgebildet, dass er bei 4GB beginnt. 12 stellt dies dar. Der Sub-Pod nimmt eine angepasste Speicheranforderungs-Adresse eines Prozessors und subtrahiert davon, nachdem er ermittelt hat, dass sie oberhalb der 4GB-Grenze liegt, einen festen Wert. Diese Speicheradresse reflektiert das Einfügen des PCI APIC-Bereichs in den Systemadressraum. Daher ist der Anpassungs-Offset gleich der Lückengröße des PCI APIC-Bereichs, fixiert in Schritten von 128MB-Blöcken wie oben beschrieben.
Unten werden einige weitere Beispiele für Verschiebung und Zurückforderung gemäß der vorliegenden Erfindung geliefert. Es wird Bezug auf 5 und TABELLE A genommen. Das erste Beispiel betrifft einen Adressverweis in einem exklusiven Fenster. Das zweite Beispiel betrifft ein gemeinsames Fenster.
Wie in 5 dargestellt, wurde der Betriebssystem-Adressraum OS#3 an die Hauptspeicher-Adresse 10,5 GB verschoben (R_L). Die Zurückforderung wird so eingestellt, dass der 128MB-(0,125GB-)Speicherbereich hinter der Lücke 572 des unteren Speicherbereichs zurückgefordert wird. Unter Verwendung von OS_ADR = 1.5000.0000_H als Speicher-Referenz führt TCT 270 die Funktion OS_ADR + [R_L – R_C] aus, um eine Adresse im MSU-Speicherplatz 504 zu erzeugen. Die Werte für R_L und R_C werden in TABELLE A dargestellt. So wird OS_ADR + [R_L – R_C] zu 1.5000.0000_H + [2.A000.0000_H – 0.0800.0000_H]. Dies wird zu 1.5000.0000_H + 2.9800.0000_H, was wiederum zu 3.E800.0000_H (15.625 GB) wird. Diese Adresse entspricht einer Speicherstelle im exklusiven Fenster 540A, die mit dem Betriebssystem OS#3 zusammenhängt. Eine einfache Rechnung zeigt, dass die Adresse um 1.25GB von der Basisadresse von 4GB des oberen Speicherbereichs versetzt ist. Die oben berechnete Adresse ist auch 1.25GB von der verschobenen Basisadresse (14.375GB) von OS#3 des oberen Speicherbereichs versetzt.
Wenn ein Prozessor in der Partition, in der OS#2 ausgeführt wird, dieselbe Adresse, 1.5000.0000_H, ausgibt, liegt die verschobene Adresse stattdessen im exklusiven Speicherfenster, das dieser Partition zugewiesen ist (d. h. Fenster 540B). So wird OS_ADR + [R_L – R_C] zu 1.5000.0000_H + [1.4000.0000_H – 0.1000.0000_H]. Dies wird zu 1.5000.0000_H + 1.3000.0000_H, was wiederum zu 2.8000.0000_H(10.00GB) wird. Diese Adresse fällt eindeutig in den oberen Speicherbereich 534 des Hauptspeichers 160, der Teil des exklusiven Speicherfensters (540B) ist, welches der Partition zugewiesen ist, auf der OS#2 ausgeführt wird. Dieses Beispiel zeigt, dass die Betriebssysteme in zwei verschiedenen Partitionen ihre Adressräume jeweils so betrachten, als würden sie an derselben Basisadresse (d. h. Adresse Null) beginnen, aber Adressen-Verweise innerhalb dieser Adressräume werden korrekt an ihre entsprechenden Speicherstellen innerhalb der exklusiven Speicherfenster verschoben, die jeder Partition im Hauptspeicher zugewiesen sind. Natürlich kann die Verschiebungsfunktion der vorliegenden Erfindung verwendet werden, um alle zwei physikalischen Adressräume, die sich überlappen und auf verschiedenen Partitionen liegen (nicht nur diejenigen, die beide bei der Adresse Null beginnen), auf die entsprechenden exklusiven Speicherfenster im Hauptspeicher abzubilden.
Das zweite Beispiel verwendet Speicher-Referenzen auf das gemeinsame Fenster 575, das mit OS#3 zusammenhängt. In diesem Beispiel wird angenommen, dass OS#3 versucht, auf die Adresse 1.B900.0000_H (6.890GB) zu verweisen. TCT 270 stellt fest, dass diese Adresse in den Bereich gemeinsam genutzten Speichers fällt. Daher wendet die vorliegende Erfindung die Abbildungsfunktion OS_ADR + [S_BASE ^MSU – S_BASE ^OS] zur Erzeugung einer entsprechenden Adresse an, um auf den MSU-Speicherplatz 504 zuzugreifen. So wird die Abbildungsfunktion 1.B9000.0000_H + [4.5000.0000_H – 1.B8000.0000_H]. Dies wird zu 1.B9000.0000_H + 2.98000.0000_H, was wiederum zu 4.5100.0000_H (17.2656GB) wird. Diese Adresse liegt im Bereich des gemeinsam genutzten Speicherfensters 537 des MSU-Speicherplatzes 504.
Unter Verwendung desselben Adressen-Offsets, 0.0156GB, und seiner Anwendung auf die gemeinsame Basisadresse des Betriebssystems OS#2, kann die äquivalente Adresse für OS#2 berechnet werden. OS_ADR ist gleich 5.750GB + 0.0156GB, was gleich 5.7656GB (1.7100.0000_H) ist. Unter Anwendung der Abbildungsfunktion, OS_ADR + [S_BASE ^MSU – S_BASE ^OS], erhalten wir 1.7100.0000_H + [4.5000.0000_H – 1.7000.0000_H]. So erzeugt die Abbildungsfunktion eine Speicheradresse von 4.5100.0000_H (17.2656GB). So greifen sowohl eine Speicher-Referenz durch das Betriebssystem OS#3 von 1.B900.0000_H (6.8906GB) als auch eine Speicher-Referenz durch das Betriebssystem OS#2 von 1.7100.0000_H (5.7656GB) an der Adresse 4.5100.0000_H (17.2656GB) auf den Hauptspeicher 160 zu.
Verschachteln und Stapeln von Speicher (Übersetzung)
Übersetzung ist der Prozess, mit dem eine Speicher-Referenz (nach Verschiebung und gegebenenfalls Zurückforderung) auf eine bestimmte Speichereinheit im Hauptspeicher 160 abgebildet wird. In 2 ist der Hauptspeicher 160 konzeptuell in eine Vielzahl von MSU-Paaren 222 und 224 (bezeichnet als MSU_PAIRs) unterteilt. Einzelne MSUs 220 in einem MSU_Pair sind nicht spezifisch verbunden. Für Darstellungszwecke sind in 2 nur zwei MSU_PAIRs 222, 224 dargestellt. Die vorliegende Erfindung berücksichtigt jedoch mehr als zwei MSU_PAIRs.
Das Computersystem 200 verwendet die angepasste Adresse (oder Speicher-Referenz), die während der Verschiebung und gegebenenfalls Zurückforderung wie oben beschrieben erzeugt wurde, und verschachtelt oder stapelt dann die angepasste Speicher-Referenz zwischen den Speichereinheits-Paaren 222, 224. Ziel der vorliegenden Erfindung ist es, jede der Hauptspeicheranforderungen im Zusammenhang mit jedem Prozessor 240 über den globalen Adressraum des Hauptspeichers 160 (d. h. den gesamten DRAM-Adressraum) so zu verteilen, dass sequentielle Speicherzugriffe über verschiedene Speichereinheiten 220 verteilt werden, um den Wettbewerb um Speicherressourcen zu minimieren. Falls keine Verschachtelung durchgeführt werden kann, werden die Speicheradressen in sequentieller Reihenfolge an Speichereinheits-Paare geleitet, was hierin als Stapelung bezeichnet wird.
In einer exemplarischen Ausführungsform gibt es vier Speichereinheiten, d. h. zwei Paare von Speichereinheiten, wie z. B. das Speichereinheits-Paar 222 und das Speichereinheits-Paar 224. Jedes Speichereinheits-Paar (im Folgenden MSU_Pair genannt) schließt zwei Speichereinheiten ein, z. B. die Speichereinheiten 220A und 220B. Verschachtelung wird über die Speichereinheits-Paare 222 und 224 durchgeführt. Danach wird Verschachtelung über die Speichereinheiten 220 innerhalb der Speichereinheits-Paare 222 bzw. 224 durchgeführt. Das effektive Ergebnis ist Vierweg-Verschachtelung.
Nehmen wir z. B. an, dass es zwei Speichereinheiten, wie die Speichereinheit 220A und die Speichereinheit 220B, gibt. Optimal werden Verweise auf den Speicher zwischen Speichereinheit 220A und Speichereinheit 220B hin- und hergeschaltet. Das heißt, die erste Speicher-Referenz greift auf die Speicher einheit 220A zu, während die zweite auf die Speichereinheit 220B zugreift. Wenn bei der Speichereinheit 220A nur ein Speicheradressbereich bestückt ist, bei der Speichereinheit 220B jedoch acht Speicheradressbereiche bestückt sind und zwischen Speichereinheit 220A und Speichereinheit 220B hin- und hergeschaltet wird, hat an einem bestimmten Punkt die Speichereinheit 220A nicht mehr genügend Speicherplatz. In diesem Fall wird der restliche Speicher in der Speichereinheit 220B gestapelt, d. h. auf sequentielle Adressierung (oder Referenzierung) der Speichereinheit 220B zurückgreifen.
Eine Eigenschaft von Speichereinheiten ist, dass in einem bestimmten Speichereinheits-"Paar" eine Speichereinheit oder eine Vielzahl von Speichereinheiten vorhanden sein können. Weiterhin können die Speichereinheiten mit verschiedenen Geschwindigkeiten bestückt werden. Das heißt, bei einer Speichereinheit kann ein Speicheradressbereich des DRAM bestückt sein, während bei einer anderen Speichereinheit acht Speicheradressbereiche des DRAM bestückt sein können.
Gemäß der vorliegenden Erfindung beinhaltet der Übersetzungsprozess die Verschachtelung und Stapelung von Speicher-Referenzen zwischen dem Speichereinheits-Paar 222 und dem Speichereinheits-Paar 224 und zwischen den MSUs 220. Bei einer Speicheranforderung, die von einem Prozessor (MP) 240 ausgegeben wird, wird dieser Prozess von der entsprechenden TCT 270 durchgeführt. Bei Speicheranforderungen, die über eine DIB von einem I/O-Prozessor (z. B. einer PCI-Karte) ausgegeben werden, wird dieser Prozess vom entsprechenden TCM 285 durchgeführt.
Was die Arbeitsweise einer TCT 270 betrifft, so wird ein Mechanismus bereitgestellt, um während der Initialisierungszeit anzugeben, welches MSU_Pair oder welche MSU 220 die erste Cache-Zeilen-Adresse (d. h. eine Adresse von der TCT 270) empfangen sollte. Die TCT 270 nimmt (nach jeder Verschiebung und/oder Zurückforderung) die Speicher-Lese-/Schreib-Adresse eines Prozessors und lässt sie eine Adressumsetzungs-Funktion durchlaufen. In einer bevorzugten Ausführungsform erhält die Speichereinheit 220 eine Cache-Zeilen-Adresse (oder Speicher-Referenz) mit 28 Bit und eine 8-Byte-Container-Adresse von einem Mehrfachzyklus-Signal, das 16 Gigabyte Speicherplatz darstellt. Anhand der Einstellungen der Adressumsetzungs-Optionen, die unten beschrieben sind, erzeugt die Übersetzungs-Funktion eine MSU-Nummer, die zu der Speichereinheit gehört, welche die Anforderung empfängt, gemeinsam mit den oberen 10 Bit der in der MSU abgebildeten 28-Bit-Adresse. Die TCT 270 liefert auch die unteren 18 MSU-Bit der abgebildeten Adresse; diese Bits werden jedoch durch die Übersetzungs-Funktion nicht verändert.
Eine TCT 270 ermöglicht verschiedene Kombinationen von Verschachtelung und Stapelung von Speicherzugriffen, sowohl auf MSU_Pair-Grundlage als auch zwischen allen einzelnen MSUs 220. In TABELLE C sind die acht Kombinationen für die Verschachtelung/Stapelung von Speicher zwischen MSU_PAIRs und ihren einzelnen MSUs 220 aufgelistet.
TABELLE C
Mit Bezug auf TABELLE C verteilt der Algorithmus im III-Modus jede zweite Cache-Zeile auf alternierende MSU_PAIRS (z. B. wird die Cache-Zeilen-Adresse 0 an MSU_PAIR 222 weitergeleitet). Weiter verteilt der Algorithmus jede zweite Cache-Zeile, die an ein MSU_PAIR gerichtet ist, auf alternierende MSUs 220 im MSU_PAIR 222, 224 (z. B. wird die Cache-Zeilen-Adresse 0 an die MSU 220 mit niedrigerer Nummerierung geleitet).
Im ISI-, ISS- oder IIS-Modus verteilt der Algorithmus jede zweite Cache-Zeile auf alternierende MSU_PAIRS 222, 224 (z. B. wird die Cache-Zeilen-Adresse 0 an das MSU_PAIR 222 weitergeleitet). Bei MSUs 220 in einem MSU_PAIR 222, 224, die gemäß der vorliegenden Erfindung gestapelt sind, richtet der Algorithmus weiter sequentiell adressierte Zugriffe an die MSU 220 mit niedrigerer Nummer des ausgewählten MSU_PAIR 222, 224, bis sie voll ist, bevor anschließend die andere MSU 220 aufgefüllt wird. Bei MSUs 220 in einem MSU_PAIR 222, 224, die gemäß der vorliegenden Erfindung verschachtelt sind, verteilt der Algorithmus weiter jede zweite Cache-Zeile, die an ein MSU_PAIR 222, 224 gerichtet ist, auf alternierende MSUs 220 (d. h., die Cache-Zeilen-Adresse 0 wird an die MSU 220 mit niedrigerer Nummer im MSU_PAIR 222, 224 gerichtet).
Im SSS-Modus füllt die vorliegende Erfindung sequentiell das MSU_PAIR 222, 224 mit niedrigerer Nummer (bestimmt durch ein Konfigurationsregister) auf, bis es voll ist, bevor anschließend das andere MSU_PAIR 222, 224 aufgefüllt wird. Der Algorithmus leitet weiter Zugriffe sequentiell auf die MSU 220 mit niedrigerer Nummer im ausgewählten MSU_PAIR 222, 224, bis sie voll ist, bevor sequentiell die andere MSU 220 dieses MSU_PAIR 222, 224 aufgefüllt wird.
Im SSI-, SII- oder SIS-Modus füllt der Algorithmus sequentiell das MSU_PAIR 222, 224 mit niedrigerer Nummer auf, bis es voll ist, bevor sequentiell das andere MSU_PAIR 222, 224 aufgefüllt wird. Bei MSUs 220 in einem MSU_PAIR 222, 224, die gestapelt sind, adressiert die vorliegende Erfindung dann sequentiell die untere MSU 220 des ausgewählten MSU_PAIR 222, 224, bis sie voll ist, bevor das andere MSU_PAIR 222, 224 sequentiell aufgefüllt wird. Bei MSUs 220 in einem MSU_PAIR 222, 224, die verschachtelt sind, verteilt die vorliegende Erfindung jede zweite Cache-Zeile in einem MSU_PAIR 222, 224 an alternierende MSUs 220. Die Cache-Zeilen-Adresse 0 ist an die MSU 220 mit niedrigerer Nummer im MSU_PAIR 222, 224 gerichtet.
Zum Beispiel wird nach der ISS-Option die Verschachtelung jede zweite Cache-Zeile an alternierende Speichereinheits-Paare durchgeführt. Das heißt, eine erste Cache-Zeilen-Adresse wird an das Speichereinheits-Paar 222 weitergeleitet, und die nächste Cache-Zeilen-Adresse wird an das Speichereinheits-Paar 224 weitergeleitet. Die vorliegende Erfindung stapelt Speicher-Referenzen sequentiell in der Speichereinheit 220A, bis diese voll ist. Wenn dies der Fall ist, stapelt die vorliegende Erfindung sequentiell Speicher-Referenzen in der Speichereinheit 220B, bis sie voll ist. In ähnlicher Weise stapelt die vorliegende Erfindung, wenn die Speichereinheit 220C voll ist, sequentiell Speicher-Referenzen in der Speichereinheit 220D, bis sie voll ist.
TABELLE D definiert ein Übersetzungs- und Zurückforderungs-Register. Die Tabelle schließt für jedes relevante Adressbit im Übersetzungs- und Zurückforderungs-Register eine Zeile ein. Jede Zeile schließt ein Funktionsfeld und ein Standardwert-Feld ein. Das Funktionsfeld gibt die Funktion des relevanten Adressbits an. Das Standardwert-Feld ist der Wert, den das Adressbit bei der Initialisierung automatisch annimmt. Der Status der Bits im Speicheradressen-Übersetzungs- und Zurückforderungs-Register gibt an, ob die Speicheradressraum-Zurückforderung aktiviert ist und ob die Adressenübersetzung aktiviert ist. Er gibt auch an, welches Speichereinheits-Paar ausgewählt werden soll und welche Speichereinheit für den Übersetzungsprozess ausgewählt werden soll.
TABELLE D
Es liegt in der Zuständigkeit einer Speichersteuerung (nicht dargestellt), die Speicheradressbereiche eines MSU_PAIRs 222, 224 und MSUs 220 zu verschachteln.
Ob das Computersystem 200 eine Verschachtelung implemen tiert, hängt von den Einstellungen in einer Vielzahl von Registern ab. Zum Beispiel zeigen die TABELLEN E und F die Inhalte eines Speicheradressen-Übersetzungsregisters bei Initialisierung, entsprechend einem ersten Speichereinheits-Paar bzw. einem zweiten Speichereinheits-Paar. Das Speicheradressen-Übersetzungsregister schließt eine Zeile für jedes relevante Bit ein. Jede Zeile schließt ein Funktionsfeld und ein Standardwert-Feld ein. Das Funktionsfeld schließt die Funktion des betreffenden Adressbits ein. Das Standardwert-Feld ist der Wert, den das Adressbit bei der Initialisierung automatisch annimmt.
TABELLE E
TABELLE F
Der Status der Bits in den Speicheradressumsetzungs-Registern, dargestellt in TABELLE E und F, bestimmt, ob die Verschachtelung für ein bestimmtes Paar von Speichereinheiten aktiviert ist, oder ob die Stapelung aktiviert ist. Der Status der Bits in den Speicheradressumsetzungs-Registern gibt weiter die kleinere der zwei Speichereinheiten in einem Speichereinheits-Paar an.

TABELLE G zeigt Konfigurationsinformationen, die bei der Initialisierung für Vorwärts- und Rückwärts-Adressumsetzung erforderlich sind. TABELLE G verhält sich zu 2 wie folgt: MSU_Pair0 ist MSU_Pair 222, MSU_Pair1 ist MSU_Pair 224, MSU#0 ist MSU 220A, MSU#1 ist MSU 220B, MSU#2 ist MSU 220C, und MSU#3 ist MSU 220D. TABELLE G

Name	Definition
MSU_Pair0/Pair1-Konfigurationsregister:	verwendet, um Zugriffe auf ein bestimmtes MSU_Pair zu steuern
PAIR_MODE	Dieses 1-Bit-Register bestimmt, ob Adressenverschachtelung zwischen MSU_PAIRs ausgewählt wird. Die Adressenverschachtelung sollte nur dann aktiviert sein, wenn beide MSU_PAIRs anwesend sind. Wenn =0, dann zwischen MSU_PAIRs verschachteln =1, dann zwischen MSU_PAIRs stapeln (Pair0 zuerst, Überlauf in Pair1)
SMALLEST_PAIR_SZ	Dieses Register¹ enthält einen von zwei Speichergrößen-Werten², je nachdem, ob die Adressenverschachtelung zwischen MSU_PAIRs aktiviert ist. wenn PAIR_MODE = 0 (Verschachtelung, dann) = der kleinere der zwei Speichergrößen-Werte von MSU_Pair0 (MSU#0 + MSU#1) und MSU_Pair1 (MSU#2 + MSU#3). sonst PAIR_MODE = 1 (Stapelung) = die Speichergröße der MSU-Paare, die vom PAIR_SEL-Register ausgewählt werden

PAIR_SEL	Dieses 1-Bit-Register gibt an, welches der beiden MSU_PAIRs zuerst adressiert werden soll. Der Wert hängt davon ab, ob Adressenverschachtelung durchgeführt wird. Zum Verschachteln muss das MSU_Pair mit dem größten installierten Speicher ausgewählt werden. Zum Stapeln können beide MSU_Pairs ausgewählt werden. wenn PAIR_MODE = 0 (Verschachtelung), dann = 0 wenn Pair0 mehr Speicher hat, dann Pair1 = wenn 1 wenn Pair1 mehr Speicher hat, dann Pair0 sonst PAIR_MODE = 1 (Stapelung) = Paar, das die Speicher-"Adresse0" erhält (0 – Pair0; 1 – Pair1)
MSU_Pair0-Konfigurationsregister:	verwendet, um Zugriffe auf eine bestimmte MSU im Pair0 zu steuern
PAIR0_MODE	Dieses 1-Bit-Register steuert, ob Adressenverschachtelung zwischen MSUs innerhalb eines MSU_Pair ausgewählt wird. Adressenverschachtelung sollte nur dann aktiviert sein, wenn beide MSUs im MSU_Pair0 vorhanden sind. = 0 Verschachtelung zwischen MSUs von Pair0 (MSU#0 und MSU#1) = 1 Stapelung der MSUs von Pair0

PAIR0_SMALLEST_MSU_SZ

Dieses Register¹ enthält einen von zwei Speichergrößen²-Werten, je nachdem, ob die Adressenverschachtelung innerhalb dieses MSU_Pair aktiviert ist. = der kleinere der zwei Speichergrößen-Werte von MSU#0 und MSU#1 von MSU_Pair0. sonst (PAIR0_MODE0 = 1:Stapelung) = die Speichergröße der MSU, die vom PAIR0_SEL-Register ausgewählt wird

PAIR0_SEL

Dieses 1-Bit-Register gibt an, welche der beiden MSUs in einem MSU_Pair zuerst adressiert werden soll. Der Wert hängt davon ab, ob Adressenverschachtelung durchgeführt wird. Zum Verschachteln muss die MSU mit dem größten installierten Speicher ausgewählt werden. Zum Stapeln können beide MSUs ausgewählt werden. wenn PAIR0_MODE = 0 (Verschachtelung), dann = 0 wenn MSU#0 von Pair0 mehr Speicher hat, dann MSU#1 von Pair0 = 1 wenn MSU#1 von Pair0 mehr Speicher hat, dann MSU#0 von Pair0 sonst PAIR0_MODE = 1 (Stapelung) = MSU von Pair0, die die Speicher-"Adresse 0" erhält (0 – MSU#0; 1 – MSU#1)

MSU_Pair1-Konfigurationsregister:	verwendet, um den Zugriff auf eine bestimmte MSU innerhalb von Pair1 zu steuern
PAIR1_MODE	Dieses 1-Bit-Register bestimmt, ob Adressenverschachtelung zwischen MSUs innerhalb eines MSU_Pair ausgewählt wird. Die Adressenverschachtelung sollte nur dann aktiviert sein, wenn beide MSUs im MSU_Pair1 vorhanden sind. Wenn = 0 Verschachtelung zwischen MSUs von Pair1 (MSU#2 und MSU#3) = 1 dann Stapelung der MSUs von Pair1
PAIR1_SMALLEST_MSU_SZ	Dieses Register¹ enthält einen von zwei Speichergrößen-Werten², je nachdem, ob Adressenverschachtelung innerhalb dieses MSU_Pair aktiviert ist. wenn PAIR1_MODE = 0 (Verschachtelung), dann = der kleinere der zwei Speichergrößen-Werte von MSU#2 und MSU#3 von MSU_Pair1. sonst PAIR1_MODE = 1 (Stapelung) = die Speichergröße der MSU, die vom PAIR1_SEL-Register ausgewählt wird
PAIR1_SEL	Dieses 1-Bit-Register gibt an, welche der beiden MSUs in einem MSU_Pair zuerst adressiert werden soll. Der Wert hängt davon ab, ob Adressenverschachtelung durchgeführt wird. Zum Verschachteln muss die MSU mit dem größten installierten Speicher ausgewählt werden. Zum Stapeln können beide MSUs ausgewählt werden. wenn PAIR1_MODE = 0 (Verschachtelung), dann = 0 wenn MSU#2 von Pair0 mehr Speicher hat als MSU#3 von Pair1 = 1 wenn MSU#3 von Pair1 mehr Speicher hat als MSU#2 von Pair1 sonst PAIR1_MODE = 1 (Stapelung) = MSU von Pair1, die die Speicher-"Adresse 0" erhält (0 – MSU#2; 1 – MSU#3)

¹ Anmerkung: Die Größe dieses Registers ist nicht in dieser Tabelle angegeben. Sie ist Implementierungs-spezifisch und zum Verständnis des Übersetzungsalgorithmus nicht notwendig.
² Anmerkung: Die Speichergröße ist gleich der maximalen Speicheradresse +1. Zum Beispiel reicht ein einziger 128MB-Speicheradressbereich von 000_0000_H – 700_0000_H, aber die Größe beträgt 800_0000_H. Eine Erweiterung dieser Größe auf 36 Bit [35:0] ergibt 0_800_0000_H. Bei Verwendung der 9 höchstwertigen Bits [35:27] für die Größe wird das Größenregister für dieses Beispiel mit 000000001_B oder 001_H bestückt.

Wie zuvor erwähnt, befinden sich Logik und Register zur Implementierung der Vorwärts-Adressen-Übersetzungsfunktion sowohl in den TCMs 285 (für Speicheranforderungen von einem E/A-Prozessor über eine entsprechende DIB) als auch in den TCTs 270 (für Speicheranforderungen von einem Prozessor 240). Der Algorithmus wird in zwei Schritten durchgeführt. Der erste Schritt bestimmt, welches MSU_PAIR ausgewählt werden sollte, und der zweite Schritt bestimmt, welche MSU des ausgewählten Paars ausgewählt werden sollte, damit die Adresse dorthin gesendet werden kann. Im Anhang A ist ein vereinfachter Pseudo-Code des Vorwärts-Adressen-Übersetzungsalgorithmus dargestellt. Der Pseudo-Code schließt keine Prüfungen von Kriterien, wie z. B. der Anzahl von MSU_PAIRs oder der Anzahl von MSUs pro MSU_PAIR usw. ein. Diese Prüfungen, die für den Fachmann offensichtlich sein sollten, wurden absichtlich nicht in den Pseudo-Code aufgenommen, um ein besseres Verständnis des Übersetzungsprozesses zu ermöglichen.
Der Vorwärts-Adressen-Übersetzungsalgorithmus verwendet als Eingabe TEMP_ADDR und benutzt die Register PAIR_MODE, SMALLEST_PAIR_SZ und PAIR_SEL. Er erzeugt als Ausgabe TEMP_ADDR, die Adresse nach allen erforderlichen Anpassungen, und RCVING_PAIR, wodurch angegeben wird, welches MSU_PAIR ausgewählt wurde. Zunächst ist TEMP_ADDR [29:0] die Adresse, nachdem Adressverschiebungen durchgeführt wurden. TEMP_ADDR [29:0] ist gleich ADDR_IN [35:6]. TOP_OF_INTRLV_RANGE ist der Adresswert, bei dem kein Speicher mehr für Vernetzung übrig ist. Das bedeutet, dass dies die Adresse ist, bei der die Stapelung von Speicheradressen beginnt. TOP_OF_INTRLV_RANGE ist gleich zweimal SMALLEST_PAIR_SZ.
9 zeigt ein Flussdiagramm des Vorwärts-Adressen-Übersetzungsalgorithmus. Die Auswahl eines MSU_Pair ist in Stufe 900 dargestellt. Schritt 902 ermittelt, ob die Verschachtelung zwischen Paaren aktiviert ist. Ist dies der Fall, so überprüft der Algorithmus zunächst, ob die Adresse im verschachtelten Speicherbereich liegt, wie in Schritt 904 gezeigt. Falls die Cache-Zeilen-Adresse oberhalb des Verschachtelungs-Bereichs liegt, stapelt die vorliegende Erfindung auf das größere MSU_PAIR, wie in Schritt 910 dargestellt. Anderenfalls schreitet die Logik fort zu Schritt 906, wo bestimmt wird, welches MSU_PAIR aus der Vielzahl von MSU_PAIRs ausgewählt werden sollte. In einer bevorzugten Ausführungsform wird das niedrigstwertige Cache-Zeilen-Adressbit, TEMP_ADDR [0], verwendet, um das MSU_PAIR auszuwählen.
Falls die Verschachtelung zwischen Paaren nicht aktiviert ist, stapelt die vorliegende Erfindung Cache-Zeilen-Adressen. In einer bevorzugten Ausführungsform stapelt die vorliegende Erfindung die Cache-Zeilen-Adressen zunächst in MSU_PAIR0. Sobald MSU_PAIR0 (d. h. MSU_Pair 222) voll ist, wird die Stapelung mit MSU_PAIR1 (d. h. MSU_Pair 224) fortgesetzt. Die Stapelung wird fortgeführt, bis das höchste MSU_PAIR voll ist. Dies ist allgemein in Schritt 912 dargestellt.
Die Logik geht dann weiter zu Schritt 908 (von entweder Block 906, 910 oder 912), wo die Cache-Zeilen-Adresse angepasst wird. Die Anpassung hängt davon ab, ob Verschachtelung oder Stapelung ausgewählt wird. Bei Verschachtelung wird die Cache-Zeilen-Adresse (TEMP_ADDR) angepasst durch Verschiebung der Adresse um eine Stelle nach rechts und Setzen des höchstwertigen Adressbits auf Null. Bei Stapelung bleibt die Cache-Zeilen-Adresse entweder gleich, oder sie wird gleich TEMP_ADDR – SMALLEST_PAIR_SZ gesetzt, wie durch eine Prüfung des Pseudo-Codes offensichtlich wird.
Sobald ein MSU_PAIR für die Stapelung ausgewählt wurde, schreitet die vorliegende Erfindung fort zu Stufe 920. Diese Stufe des Algorithmus hat eine Eingabe TEMP_ADDR, die möglicherweise durch Schritt 908 angepasst wurde. Stufe 920 verwendet die folgenden Register: PAIR0_MODE, PAIR0_SMALLEST_MSU_SZ, PAIR0_SEL. Die Ausgaben der Stufe 920 sind TEMP_ADDR, d. h. die Cache-Zeilen-Adresse nach eventuell erforderlichen Anpassungen, und RCVING_MSU, womit angegeben wird, welche MSU die Cache-Zeilen-Adresse erhalten wird. Bei der Initialisierung ist PAIR0_TOP_OF_INTLV_RANGE der Adresswert, bei dem kein Speicher mehr für die Verschachtelung zwischen MSUs von MSU_PAIR0 übrig ist. PAIR1_TOP_OF_INTLV_RANGE ist der Adresswert, bei dem kein Speicher mehr für die Verschachtelung zwischen MSUs von MSU_PAIR1 mehr übrig ist.
Falls in Stufe 900 MSU_Pair0 ausgewählt wurde, bestimmt Stufe 920, ob RCVING_PAIR gleich MSU0 oder MSU1 ist. Ähnlich bestimmt die Stufe 920, wenn in Stufe 900 MSU_Pair1 gewählt wurde, ob RCVING_PAIR gleich MSU2 oder MSU3 ist. Der Kürze halber wird nur eine Auswahl zwischen MSU0 und MSU1 beschrieben.
In Schritt 924 wird bestimmt, oh die Verschachtelung zwischen den mehreren MSUs eines MSU_PAIR aktiviert ist. Ist dies der Fall, so überprüft der Algorithmus zunächst, ob die Cache-Zeilen-Adresse im verschachtelten Speicherbereich liegt, wie in Schritt 926 dargestellt. Liegt sie im verschachtelten Speicherbereich, so wird das niedrigstwertige Cache-Zeilen-Adressbit verwendet, um die entsprechende MSU auszuwählen, wie in Schritt 928 dargestellt. Als Nächstes wird die Cache-Zeilen-Adresse angepasst durch Verschiebung der Cache-Zeilen-Adressbits um eine Stelle nach rechts und Setzen des höchstwertigen Adressbits auf Null, wie in Schritt 930 dargestellt.
Falls hingegen die Cache-Zeilen-Adresse oberhalb des Verschachtelungs-Speicherbereichs liegt, stapelt der Algorithmus auf die größere MSU, wie in Schritt 932 gezeigt. Die Logik geht dann zum Schritt 930, wo die Adresse durch Setzen von TEMP_ADDR auf TEMP_ADDR – PAIR0_SMALLEST_MSU_SZ zur Stapelung angepasst wird.
Wenn die Verschachtelung zwischen MSUs von MSU_PAIR0 nicht aktiviert ist, stapelt die vorliegende Erfindung zunächst in MSU0 und stapelt dann den Rest in MSU1, wie in Schritt 934 dargestellt. Auch hier wird die Adresse in Schritt 930 angepasst, je nachdem, ob die niedrige oder die hohe MSU zuerst verwendet wird. Wenn die niedrige MSU zuerst verwendet wird, bleibt TEMP_ADDR unverändert. Wenn die hohe MSU zuerst verwendet wird, wird TEMP_ADDR auf TEMP_ADDR – PAIR0_SMALLEST_MSU_SZ gesetzt.
Wie oben erwähnt, wird ein ähnliches Verfahren zur Auswahl zwischen MSU2 und MSU3 in MSU_PAIR1 angewandt.
Schließlich wird, wie in Schritt 940 gezeigt, MSU_ADDR [29:0] der angepassten TEMP_ADDR [29:0] zugewiesen, und das RCVING_PAIR wird mit den RCVING_MSU-Indikatoren verkettet, um MSU_SEL [1:0] zu bilden. Dies vervollständigt den Vorwärts-Adressen-Übersetzungsalgorithmus.
In Anhang B ist Pseudo-Code für den Rückwärts-Übersetzungsalgorithmus dargestellt. Die Rückwärts-Adressenübersetzungs-Funktion befindet sich nur in der MSU-Steuerung (nicht dargestellt).
Es wird Bezug auf 6 genommen, um ein Beispiel für den Vorwärts-Adressen-Übersetzungsalgorithmus darzustellen. 6 zeigt einen Hauptspeicher 600 mit zwei MSU_PAIRs 610, 640. MSU_Pair 610 hat zwei MSUs 620, 630, während MSU_Pair 640 eine einzige MSU 650 hat. MSU 620 hat einen 128-Megabyte-Speicheradressbereich 1020, MSU 630 hat zwei 128-Megabyte-Speicheradressbereiche 1030 (oder 256 Megabyte Speicherplatz), und MSU 650 hat vier 128-Megabyte-Speicheradressbereiche 1040 (oder 512 Megabyte Speicherplatz). Die Obergrenze der MSU 620 ist 80.0000_H. Das heißt, 80.0000_H ist die Befehlsadresse, bei der kein Speicher mehr zur Verschachtelung übrig ist. Die Obergrenze der MSU 630 ist 100.0000_H. Daher hat MSU_Pair 610 eine Paargröße von 180.0000_H. Die Obergrenze der MSU 650 ist 200.0000_H. Somit hat MSU_Pair 610 eine Paargröße von 200.0000_H. Es ist anzumerken, dass MSU_Pair 640 konzeptuell als ein Paar von MSUs behandelt wird, obwohl es nur eine einzige MSU 650 einschließt.
Angenommen, es gäbe vier Cache-Zeilen-Adressen 0.0000.0000_H, 0.0000.0040_H, 0.0000.0080_H und 0.0000.00C0_H, die nach jeder durchgeführten Adressenverschiebung jeweils vier Speicher-Referenzen von vier Betriebssystemen darstellen. In diesem Beispiel ist der Hauptspeicher konfiguriert wie in der 6 dargestellt. Es ist anzumerken, dass dies nicht die effizienteste Speicherkonfiguration für diese Anzahl von Speicheradressbereichen ist.
Die Registereinstellung für dieses Beispiel ist wie folgt: PAIR_MODE ist gleich 0 (Verschachtelung), PAIR0_MODE ist gleich 0 (Verschachtelung), PAIR0_MODE ist gleich 1 (Stapelung), SMALLEST_PAIR_SZ ist gleich 003_H, PAIR0_SMALLEST_MSU_SZ ist gleich 001_H, PAIR1_SMALLEST_MSU_SZ ist gleich 004_H, PAIR_SEL ist gleich 1, PAIR0_SEL ist gleich 1, PAIR_SEL ist gleich 0. Die obige Einstellung stellt die IIS-Option der Übersetzung dar.
Die Verwendung dieser Registereinstellungen und die Präsentation der ersten Adresse gegenüber dem Algorithmus führt zu folgenden Ergebnissen:
Initialisierung für beide Phasen:
PROCESSOR:_ADDR[35:0] = 000000000_H
TEMP_ADDR[29:0] = 00000000_H
TOP_OF_INTRLV_RANGE = 003_H
PAIR0_TOP_OF_INTLV_RANGE = 002_H
PAIR1_TOP_OF_INTLV_RANGE = 004_H

die MSU_Pair-Auswahlphase:
In

TEMP_ADDR[29:0] = 00000000_H
Ergebnisse:

RCVING_MSU = 0(MSU_PAIR0)
TEMP_ADDR[29:0] = 00000000_H

die MSU#-Auswahlphase:

In

TEMP_ADDR[29:0] = 00000000_H
Ergebnisse:

RCVING_MSU = 0 (MSU#0)

TEMP_ADDR[29:0] = 00000000_H

die Endergebnisse:
MSU_ADDR[29:0] = 000000000_H
MSU_SEL[1:0] = 00 (MSU#0 von MSU_PAIR0)

Verarbeitung der zweiten Adresse
Initialisierung:
PROCESSOR_ADDR[35: 000000040_H0] =
TEMP_ADDR[29:0] = 00000001_H
RCVING_PAIR = 1 (MSU_PAIR1)
TEMP_ADDR[29:0] = 00000000_H
RCVING_MSU = 0 (MSU#2)
TEMP_ADDR[29:0] = 00000000_H

die Endergebnisse:
MSU_ADDR[29:0] = 00000000_H
MSU_SEL[1:0] = 10 (MSU#2 VON MSU_PAIR1)

Die dritte Adresse ergibt:
Initialisierung:
PROCESSOR_ADDR[35: 000000080_H
0] =
TEMP_ADDR[29:0] = 00000002_H
RVCING_PAIR = 1 (MSU_PAIR1)
TEMP_ADDR[29:0] = 00000001_H
RCVING_MSU = 0 (MSU#2)
TEMP_ADDR[29:0] = 00000000_H

Endergebnisse:
MSU_ADDR[29:0] = 00000000_H
MSU_SEL[1:0] = 01(MSU#1 VON MSU_PAIR0)

während die vierte Adresse folgende Endergebnisse liefert:
Initialisierung:
PROCESSOR_ADDR[35: 0000000C0_H
0] =
TEMP_ADDR[29:0] = 00000003_H
RVCING_PAIR = 1 (MSU_PAIR1)
TEMP_ADDR[29:0] = 00000001_H
RCVING_MSU = 0 (MSU#2)
TEMP_ADDR[29:0] = 00000000_H
Endergebnisse:
MSU_ADDR[29:0] = 00000000_H
MSU_SEL[1:0] = 01(MSU#2 VON MSU_PAIR1)
7 zeigt das Ergebnis dieses Beispiels.
Es soll deutlich sein, dass Ausführungsformen der vorliegenden Erfindung in Hardware, Software oder einer Kombination davon implementiert werden können. In solchen Ausführungsformen können die verschiedenen Komponenten und Schritte in Hardware und/oder Software implementiert werden, um die Funktionen der vorliegenden Erfindung zu erfüllen. In solchen Ausführungsformen der vorliegenden Erfindung können alle zurzeit erhältlichen oder zukünftig entwickelten Computersoftware-Sprachen und/oder Hardware-Komponenten verwendet werden. Im Speziellen kann der Pseudo-Code, der oben und in den folgenden Anhängen behandelt und bereitgestellt wird, bei der Erstellung der Software-Ausführungsformen besonders nützlich sein.
C. Initialisierung beim Booten
In einer exemplarischen Ausführungsform wird die Partitionierung des Computersystems 200, einschließlich der Verarbeitungsmodule und des Speichers 160, gemäß der vorliegenden Erfindung während des Bootens durchgeführt. Exemplarische Prozesse zur Partitionierung, Abbildung von Speicher und Einrichtung der Verschachtelung sind unten beschrieben. Diese Initialisierungsvorgänge können während des Bootens über eine MIP-Hochgeschwindigkeits-Scan-Schnittstelle von einem Basic Input/Output System (BIOS) und einem Management Interface Processor MIP) durchgeführt werden. Der MIP ist ein Hardware-Schnittstellen-Teil einer Management Application Platform (MAP) zur Durchführung von Initialisierung und Fehlerkorrektur für das Computersystem 200. In einer exemplarischen Ausführungsform hält sich die MIP-Hochgeschwindigkeits-Scan-Schnittstelle an die IEEE TAP Linker-Spezifikation 1149.1.
Hierin wird der Begriff "Partition" manchmal anstelle von "Fenster" verwendet. Wie hierin verwendet, sind diese beiden Begriffe synonym und stehen für einen Teil des Systems, der von einer Instanz eines Betriebssystems gesteuert wird.
Die Art und Weise, wie die Partitionierung während des Bootens durchgeführt wird, kann von einem Systemadministrator vorherbestimmt und in eine Datenbank eingegeben werden, die sich auf der MAP befindet. Die Partitionierungs-Informationen bestimmen Systemressourcen, die einem bestimmten Fenster zugeordnet werden sollen, welche Art von Betriebssystem in das Fenster geladen wird und ob und, wenn ja, wie zwei Partitionen über den gemeinsam genutzten Speicher kommunizieren. In der exemplarischen Ausführungsform in 2 findet die Partitionierung vorzugsweise auf Sub-Pod- und Direct I/O Bridge-(DIB-)Grenzen statt.
Im Allgemeinen hat jedes Betriebssystem bestimmte Hardware-Anforderungen. Zum Beispiel benötigen Standard-Betriebssysteme mit offener Architektur, wie Windows NT und Unixware (erhältlich bei The Santa Cruz Operation, Inc.), eine Plattensteuerung (SCSI-Faser-Kanal usw.), eine VGA-Steuerung, eine Kompatibilitäts-PCI-Karte und Kompatibilitäts-Peripheriegeräte (CD-ROM, Band und Platte). Die entsprechende Hardware sollte systemresident sein, und das System sollte auf eine Art und Weise partitioniert sein, die sicherstellt, dass diese Anforderungen erfüllt werden. Dies sollte beim Eingeben der Partitionierungs-Informationen in die Datenbank auf der MAP berücksichtigt werden.
In 13 ist ein Ablaufdiagramm zur Erläuterung eines exemplarischen Initialisierungsvorgangs dargestellt:
Die Verarbeitung beginnt mit Schritt 1310, wo der MIP das BIOS in den Hauptspeicher lädt.
In Schritt 1312 lädt der MIP den BIOS-Konfigurations-Datenbereich in den Hauptspeicher. Diese Information spiegelt teilweise wider, was in der Konfigurations-Datenbank gespeichert war.
In Schritt 1314 löst der MIP alle Sub-Pods nacheinander aus dem Rücksetz-Zustand. Vorzugsweise arbitrieren die Sub-Pods, und ein Sub-Pod wird der BIOS-Sub-Pod (BSP). Im BSP wird ein Prozessor der Master, und dieser Prozessor führt den BIOS-Code aus. Für den Rest dieser Spezifikation kann der Prozessor, der das BIOS ausführt, als BSP bezeichnet werden. Der BSP führt eine Reihe von Funktionen aus wie unten beschrieben.
In Schritt 1316 initialisiert der BSP jeden PCI-Bus. Der BSP erhält Zugriff auf jeden PCI-Bus im System über einen Pfad, der sich von der Crossbar-Verbindung im Sub-Pod des BSPs zur MSU, durch eine andere Crossbar-Verbindung auf einem anderen Sub-Pod und schließlich durch eine Schnittstelle bis zu den DIBs erstreckt. Der BSP kann auf die DIBs zugreifen, die mit seinem eigenen Sub-Pod verbunden sind, ohne auf die MSU zuzugreifen.
In Schritt 1318 liest der BSP Konfigurationsdaten, die in Schritt 1312 oben in den Hauptspeicher geladen wurden, um zu bestimmen, welche DIBs sich in welcher Partition befinden. Der BSP schreibt unter Nutzung des oben beschriebenen Pfads eine Partitions-ID (PID) in ein "DIBs im Partitions-Register" in jeder Kompatibilitäts-DIB. Die PID wird verwendet, wenn während des normalen Systembetriebs eine Nachricht von einer DIB empfangen wird. Die Nachricht wird nur dann verarbeitet, wenn die DIB dieselbe PID hat wie die Nachricht. Die PID ermöglicht es allen Einheiten in einer Partition, die unter demselben Betriebssystem ausgeführt werden, miteinander zu kommunizieren, und wird auch verwendet, um Nachrichten über den gemeinsam genutzten Speicherbereich zu senden.
Im fakultativen Schritt 1320 berechnet der BSP die Größe der Lücke im oberen Speicherbereich und der Lücke im unteren Speicherbereich, indem er PCI-Register in jeder der PCI-Karten liest, um E/A- und Speicheranforderungen für jede PCI-Karte zu bestimmen. Das Überlagern von E/A-Platz mit Hauptspeicher wird von der Intel Multiprozessor-Spezifikation und dadurch, dass einige Standard-PCI-Karten Adressen oberhalb von 64 Gigabyte nicht erkennen können, erforderlich gemacht.
In Schritt 1322 informiert das BIOS den MIP über die Menge an Speicher-konformem E/A-Platz, der von jeder PCI-Karte benötigt wird. Dies wird durch einen BIOS-an-MIP-Interrupt und eine dazugehörige Mailbox vorgenommen. Der MIP ist bereits über die Größe des Hauptspeichers und die Menge an Speicher informiert, der zwischen Betriebssystemen gemeinsam genutzt werden soll, da diese Informationen in die mit dem MIP verknüpfte Konfigurationsdatenbank eingeschlossen sind. Daher kann der MIP, nachdem er über die erforderliche Menge an E/A-Platz informiert wurde, mit Hilfe von Tcl-Skripts die folgenden Informationen berechnen:

a. Position der Lücken im oberen und unteren Speicherbereich
b. Position des Rückforderungs-Bereichs
c. Position des gemeinsam genutzten Speicherbereichs

Tcl ist eine Industriestandard-Simulationssprache, die von den Hardware-Entwicklern zum Schreiben von Simulationsskripts verwendet wird. Die Simulationsskripts werden auch auf den MIP portiert, um die Hardware zu initialisieren.
In Schritt 1324 verwendet der MIP die oben berechneten Speicheradressen gemeinsam mit Daten, die sich in der Konfigurationsdatenbank befinden, um Register in den Sub-Pods (TCT), Crossbar-Verbindungen (TCM) und Speichereinheiten (MSU) einzurichten. Die Initialisierung des TCM richtet die Partitionierung und Adressumsetzung für die DIBs und Speicheradressumsetzungs-Register für die DIB ein. Diese Konstanten können für Verschachtelungs-Funktionen und Speicher-Zurückforderung verwendet wer den.
In einer exemplarischen Ausführungsform gibt es mindestens zwei Sätze von Registern in jedem TCM, einen für jede DIB. Diese schließen Bereichsregister und Broadcast-Register ein.
Bereichsregister für die DIB enthalten den zulässigen Speicherbereich für jede DIB gemäß der Partitions-Definition. Schnittstellen innerhalb des TCMs sind gemäß Partitions-Definitionen aktiviert oder deaktiviert.
Ein TCT-Info-Register wird u. a. mit der Partitions-ID initialisiert, die die Partition kennzeichnet. Es wird verwendet, um zu bestimmen, ob ein bestimmter Sub-Pod bei Nachrichten aktiviert werden sollte. Nachrichten, welche dieselbe Partitions-ID haben wie in diesem Register, werden empfangen.
Broadcast-Register enthalten die Partitions-ID und werden verwendet, um Nachrichten durch eine Partition rundzusenden. Eine Broadcast-Nachricht wird mit der Partitions-ID, wie sie in diesem Register angegeben ist, markiert.
Agenten-Tabellen werden mit der Partitions-ID bestückt und verwendet, um Interrupts zu den Prozessoren eines bestimmten Fensters zu validieren.
In der DIB enthalten Bereichsregister für die PCI-Karten Adressbereiche für Speicher-konforme Räume für jeden PCI-Bus. Ein Partitions-ID-Register enthält die Partitions-ID, so dass nur Nachrichten für diese DIB empfangen werden.
In der MSU erstellen MSU_PairA/PairB-Konfigurationsregister eine Verschachtelung zwischen Speicheradressbereichen der MSU. Der MIP initialisiert die Speicheradressen-Übersetzungsregister (s. Tabellen E und F oben), um Verschachtelungs-Vorgänge einzu richten. Diese Verschachtelungs-Vorgänge werden vom Benutzer vor der Initialisierung spezifiziert.
Der MIP nutzt die Länge des Speicher-konformen E/A-Raums, wie er sie vom BIOS erhält, um die Speicherstellen des Speicherkonformen E/A-Raums, die Startadresse des gemeinsam genutzten Speicherbereichs, die Zurückforderungs-Startadresse und die neue Obergrenze des Speichers zu berechnen. Mit Hilfe des MIP-an-BIOS-Interrupts und der dazugehörigen Mailbox im Hauptspeicher sendet der MIP diese Startadressen zurück an das BIOS. Der MIP verwendet diese Informationen weiter in Verbindung mit anwenderbestimmten Konfigurationsdaten, um das Konfigurationsregister (Tabelle A, oben) und das Übersetzungs- und Zurückforderungs-Register (Tabelle D, oben) zu initialisieren. Die Initialisierungsdaten, die in diesen Registern und den Speicheradressen-Übersetzungsregistern (Tabellen E und F, oben) gespeichert sind, werden von der Adressen-Übersetzungslogik zur Durchführung der Fenstertechnik-, Zurückforderungs- und Adressumsetzungs-Funktionen benötigt. Wie oben erwähnt, befinden sich Kopien dieser Register und der dazugehörigen Logik in jeder der TCTs 270 (für Speicheranforderungen von einem Prozessor 240) und auch in jedem der TCMs 285 (für Speicheranforderungen von einem E/A-Prozessor über eine DIB). Der MIP initialisiert weiter Bereichsregister für die Prozessoren mit gültigen Adressbereichen für den Speicher-konformen Raum für jede DIB, jeden E/A-Anschluss, Speicher-konformen APIC-Raum und Speicheradressraum.
Das BIOS nutzt diese Informationen, um im Speicher eine Konfigurationstabelle für jede Partition/jedes Betriebssystem zu erstellen. Diese Informationen kommunizieren jeder Partition die Position von gemeinsamem Speicherbereich. Die Konfigurationstabelle könnte jedes benutzerdefinierte Format haben. In einer exemplarischen Ausführungsform wird eine MP-Konfigurationstabelle, wie in einer bei der Intel Corporation erhältlichen Multi-Processor-Spezifikation definiert, verwendet. Das Feld in der MP-Konfigurationstabelle, das mit "OEM Table Pointer" bezeichnet ist, wird verwendet, um auf einen benutzerdefinierten Bereich zu zeigen, der die Position und Länge des gemeinsam genutzten Speicherbereichs einschließt. Unixware- und NT-Treiber nutzen diese Informationen für Zwecke der Speicherzuordnung und um die Speicherstellen von Warteschlangen zu bestimmen.
Weiter erstellt das BIOS Register in ausgewählten Prozessoren. Dies geschieht, weil der MIP keinen Zugriff auf diese Register hat. In einer exemplarischen Ausführungsform findet dieser Vorgang nur für Intel-Prozessoren statt und beinhaltet das Schreiben von Registern in jedem der Prozessoren, um z. B. ein "Obergrenze-des-Speichers-Register" (top of memory register, TOMR) in jedem Prozessor anzugeben, das einem Betriebssystem mitteilt, wo die Obergrenze des Speichers ist. Das Betriebssystem darf nicht versuchen, auf Speicher oberhalb des TOMR-Werts zuzugreifen.
Register können auch Speicherarten-Bereichsregister (memory type range registers, MTRR) einschließen, die Prozessoren mitteilen, welche Art von Speicher in den verschiedenen Speicherbereichen existiert (z. B. abgebildeter E/A, APIC-Interrupt-Raum, Hauptspeicher usw.). MTRRs werden verwendet, um Prozessoren mitzuteilen, wie sie Speicherzugriffe bearbeiten sollen. Zum Beispiel werden Prozessor-Lesevorgänge eines Speicherbereichs, der als Speicher-konformer E/A-Raum definiert ist, nicht im Cache des Prozessors zwischengespeichert. Bei Prozessoren, bei denen eine Instanz eines Betriebssystems ausgeführt wird, sollte derselbe Wert in ihr entsprechendes MTRR geladen werden.
In Schritt 1326 liest das BIOS, nach Durchführung eventueller zusätzlicher Initialisierungs-Funktionen, für jedes Betriebssystem den Boot-Sektor in die entsprechende Speicherstelle, wie durch die Informationen in der Konfigurationsdatenbank definiert, ein.
In Schritt 1328 gibt das BIOS an einen der Prozessoren in jeder Partition einen Interrupt aus, und diese Prozessoren beginnen damit, das dazugehörige Betriebssystem aus einem vordefinierten E/A-Gerät zu laden. Danach übernimmt das Betriebssystem die Kontrolle über die Ressourcen in seinem Fenster. Damit sind der BIOS-an-Betriebssystem-Übergang und -Verarbeitung abgeschlossen.
III. Verfahren zur Verwaltung des globalen gemeinsam genutzten Speicherbereichs (Kommunikation zwischen Partitionen)
Der oben beschriebene Ansatz des globalen gemeinsam genutzten Speicherbereichs kann einen privaten Speicherplatz für jede Partition zuzüglich eines gemeinsam genutzten Speicherbereichs liefern, auf den alle Partitionen zugreifen können. Der gemeinsam genutzte Speicherbereich kann einen oder mehrere schreibgeschützte Bereiche einschließen. Partitionen, einschließlich ihrer Betriebssysteme und anderer Clients, die auf den Partitionen ausgeführt werden, können miteinander über den gemeinsam genutzten Speicherbereich kommunizieren.
Der gemeinsam genutzte Speicherbereich kann z. B. durch einen Teil des Betriebssystems verwaltet werden, der auf einer Partition ausgeführt wird, oder durch andere Software und/oder Hardware, die sich auf einer Partition befinden kann. Der gemeinsam genutzte Speicherbereich kann von verschiedenen Betriebssystemen verwaltet werden, einschließlich, aber nicht beschränkt auf Windows NT, erhältlich bei Microsoft Corp., UNIXWARE, erhältlich bei The Santa Cruz Operation, Inc. (SCO), Master Control Program (MCP), einem Betriebssystem, das für UNISYS Clearpath HMP NX-Computersysteme eingerichtet ist, welche die A-Serie von Computersystemen ablösen; beide sind erhältlich bei Unisys Corp.; oder OS 2200, einem Betriebssystem, das für UNISYS Clearpath HMP IX-Computersysteme eingerichtet ist.
Unten sind alternative Ausführungsformen zur Verwaltung eines gemeinsam genutzten Speicherbereichs gemäß der vorliegenden Erfindung beschrieben. Die Ausführungsformen sind hierin zum Zwecke der Verdeutlichung und nicht der Einschränkung beschrieben. Andere Ausführungsformen (einschließlich Äquivalenten, Erweiterungen, Variationen, Abweichungen usw. von den hierin beschriebenen Ausführungsformen) werden für den Fachmann auf dem/den betreffenden Gebiet(en) auf der Grundlage der hierin enthaltenen Lehren offensichtlich sein. Es ist beabsichtigt, und die Erfindung ist dazu ausgebildet, solche alternativen Ausführungsformen einzuschließen.
A. Polling von Kommunikation zwischen Partitionen
In einer Ausführungsform ist jedem Betriebssystem, das in seiner eigenen Partition (z. B. einem oder mehreren Pods oder Sub-Pods) auf dem Computersystem ausgeführt wird, ein Teil des gemeinsam genutzten Speicherbereichs 160 zugeordnet oder zugewiesen. Betriebssysteme können in ihre zugewiesenen Teile des gemeinsam genutzten Speicherbereichs schreiben und daraus lesen, aber sie können nicht in Teile des Speicherbereichs schreiben, die anderen Betriebssystemen zugewiesen sind. Alle Betriebssysteme können jedoch aus dem gesamten gemeinsam genutzten Speicherbereich lesen.
Vorzugsweise ist jeder Partition oder jedem Betriebssystem ein exklusives Speicherfenster (im Folgenden manchmal auch als ihr/sein "lokaler Speicherplatz" bezeichnet) zugewiesen, der für die Partition oder das Betriebssystem reserviert ist. Wenn ein Betriebssystem oder eine Anwendung, die mit dem Betriebssystem verknüpft ist, eine Nachricht an ein anderes Betriebssystem oder an eine Anwendung sendet, die mit dem Betriebssystem verknüpft ist, erstellt die sendende Entität die Nachricht in einem Puffer in ihrem lokalen Speicherplatz auf dieselbe Art wie wenn die Nachricht erstellt würde, um über ein Netzwerk übertragen zu werden. Die sendende Entität kopiert dann die gesamte Nachricht oder einen Teil davon in den ihr zugewiesenen Teil des gemeinsam genutzten Speicherbereichs 160.
Die Ziel-Partition bzw. das Ziel-Betriebssystem, die/das aus dem Teil des gemeinsamen Hauptspeicherbereichs 160 lesen, aber nicht darin schreiben kann, der dem sendenden Betriebssystem zugewiesen ist, erkennt, dass eine neue Nachricht vorliegt, und kopiert diese Nachricht aus dem gemeinsamen Hauptspeicherbereich in ihren/seinen eigenen lokalen Speicherplatz (d. h. ihr/sein exklusives Speicherfenster).
In einer exemplarischen Ausführungsform befinden sich der Code und die meisten Datenstrukturen für ein Betriebssystem im lokalen Speicherplatz für das Betriebssystem. Bestimmte neue Datenstrukturen befinden sich vorzugsweise im gemeinsam genutzten Speicherbereich 160.
In einer exemplarischen Ausführungsform werden zwei Arten von Datenstrukturen verwendet, um die Kommunikation zwischen Partitionen oder Betriebssystemen zu erleichtern. Die erste Art schließt Nachrichten-Speicherstrukturen ein, die die Nachrichtendaten speichern und die in Ausgangs-Nachrichtenpuffern erstellt werden. Die zweite Art schließt Warteschlangen-Strukturen ein, die in einem Nachrichten-Warteschlangen-Bereich gespeichert werden und Zeiger auf Nachrichtendaten enthalten, die in einem dazugehörigen Ausgangs-Nachrichtenpuffer gespeichert sind. Vorzugsweise sind diese zwei Arten von Datenstrukturen im gemeinsamen Hauptspeicherbereich 160 gespeichert, während anderer Code und andere Datenkonstrukte, die von den verschiedenen Betriebssystemen und dazugehörigen Anwendungsprogrammen verwendet werden, sich in den diesen zugewiesenen lokalen Speicherplätzen befinden. Dies schützt die Systemintegrität.
14 zeigt einen Teil des gemeinsam genutzten Speicherbereichs 160, der einen Ausgangs-Nachrichtenpuffer-Pool-Bereich 1402 und einen Meldung-Warteschlangen-Bereich 1414 einschließt. Im Allgemeinen ist mit jeder Partition ein Ausgangs-Nachrichtenpuffer-Pool-Bereich 1402 verbunden. Puffer 1410 werden einer Nachricht zugeordnet, und eine Warteschlangen-Entität, oder mehrere Warteschlangen-Entitäten, zeigen auf die Puffer, wenn eine Nachricht rundgesendet wird.
Im Allgemeinen haben alle Partitionen Lesezugriff auf alle Ausgangs-Nachrichtenpuffer-Pool-Bereiche 1402. Jede Partition hat jedoch nur Schreibzugriff auf die Puffer 1410 in ihrem zugewiesenen Ausgangs-Nachrichtenpuffer-Pool-Bereich 1402.
Der Meldung-Warteschlangen-Bereich 1414 ist in n Knoten-Ausgabe-Warteschlangen 1412 unterteilt, von denen jede einer anderen Partition zugewiesen ist. Obwohl alle Partitionen Lesezugriff auf den gesamten Meldung-Warteschlangen-Bereich 1414 haben, kann eine Partition nur die ihr zugewiesene Knoten-Ausgabe-Warteschlange 1412 verändern. Diese Zugriffssteuerung, die in der Hardware umgesetzt werden kann, macht Hardware-Sperren überflüssig und vereinfacht so Wiederherstellungs- und Diagnosevorgänge.
15A zeigt eine exemplarische Ausführungsform des Meldung-Warteschlangen-Bereichs 1414, der mit acht Knoten-Ausgabe-Warteschlangen 1412 versehen ist. Die Knoten-Ausgabe- Warteschlange 1412a ist als eine Knoten-zu-Knoten-Warteschlange 1510 für jede Partition einschließend dargestellt. Wie hierin verwendet, ist der Begriff "Knoten" äquivalent zum Begriff "Partition".
Die 16A und 16B zeigen exemplarische Informationen, die in einer Knoten-Ausgabe-Warteschlange 1412 enthalten sind. Die ersten sechzehn Wörter einer exemplarischen Knoten-Ausgabe-Warteschlange 1412 schließen Steuerinformation für den dazugehörigen Knoten ein, einschließlich der Art des Knoten-Betriebssystems (Node_OS_) 1610, der Knoten-Medien-Zugriffssteuerungs(media access control, MAC-)Adresse 1612 und verschiedener Reset-Flags (z. B. Reset_OK), die während der Wiederherstellung verwendet werden, wie unten beschrieben.
Die Steuerinformation schließt weiter acht Dequeued_offset-Felder ein, von denen jedes einen Offset in der Knoten-Ausgabe-Warteschlange eines jeweils anderen Knotens speichert und angibt, welche Nachricht als nächste von dem entsprechenden anderen Knoten empfangen werden soll, wie unten erläutert ist.
In der exemplarischen Ausführungsform in den 16A und 16B folgen die Knoten-zu-Knoten-Warteschlangen 1510 den ersten sechzehn Wörtern der Steuerinformation. Jede Knoten-zu-Knoten-Warteschlange 1510 wird vom dazugehörigen Betriebssystem genutzt, um Nachrichten an den genannten anderen Knoten zu senden. Zum Beispiel wird die Knoten-0-zu-Knoten-1-Warteschlange 1510a vom Knoten 0 genutzt, um Nachrichten an den Knoten 1 zu senden. Der Einfachheit halber kann eine Knoten-zu-Knoten-Warteschlange 1510 für jeden Knoten bereitgestellt werden, so dass er eine Nachricht an sich selber senden kann.
In den 16A und 16B schließt das erste Wort in jeder Knoten-zu-Knoten-Warteschlange 1510 Steuerinformation ein, die einen "Need_Reset"-Merker und einen "Enqueue_offset" einschließt. Der Need_Reset wird in Verbindung mit einem ausgewählten Reset_OK-Merker verwendet, wenn ein sendender Knoten eine der Knoten-zu-Knoten-Warteschlangen zurücksetzen möchte. Der "Enqueue_offset" enthält z. B. eine Nummer zwischen 1 und 511 und wird verwendet, um auf den nächsten verfügbaren Eintrag in der entsprechenden Knoten-zu-Knoten-Warteschlange 1510 zu zeigen. Die Benutzung dieses Feldes ist unten genauer beschrieben. Jedes der übrigen Wörter (z. B. 511 Wörter) der Knoten-zu-Knoten-Warteschlange 1510 schließt einen Offset-Zeiger ein, der auf eine dazugehörige Nachrichten-Datenstruktur 1416 in einem dazugehörigen Ausgabe-Nachrichtenpuffer 1410 zeigt.
In einer bevorzugten Ausführungsform ist der Offset die Anzahl der 64-Bit-Wörter vom Start des Ausgabe-Nachrichtenpuffers 1410 des jeweiligen Knotens. Der Zeiger sollte ein Offset von einer Basisadresse, nicht von einer realen oder virtuellen Adresse, sein. Er sollte nicht auf einer virtuellen Adresse basieren, da die Knoten, wenn es heterogene Knoten sind, möglicherweise keine gemeinsame virtuelle Adressumsetzung haben. Er sollte nicht auf einer realen Adresse basieren, da als Ergebnis des oben beschriebenen Adressumsetzungsschemas reale Adressen, die von einem Knoten verwendet werden, im Allgemeinen nicht mit realen Adressen übereinstimmen, die von einem anderen Knoten verwendet werden.
In einer exemplarischen Ausführungsform sind die Zeiger Offsets von einer Adresse, die jeder Knoten oder jedes Betriebssystem aus Informationen berechnen kann, die von der oben beschriebenen Management Application Platform (MAP) während der Knoten-Initialisierung empfangen wurden.
Jede der acht Knoten-zu-Knoten-Warteschlangen 1510 in einer Knoten-Ausgabe-Warteschlange 1412 kann z. B. 512 Wörter lang sein, wie in den 16A und 16B dargestellt, so dass jede Knoten-Ausgabe-Warteschlange 1412 16 + 8(512) Wörter lang ist.
Diese Warteschlangen-Länge trägt dazu bei sicherzustellen, dass eine zugewiesene Warteschlange nicht voll ist, wenn eine Nachricht zur Übertragung an den gemeinsam genutzten Speicherbereich verfügbar ist. Die Warteschlangen-Länge kann während der Initialisierung von der Manager Application Platform (MAP) angegeben werden. Wie oben erwähnt, ist die MAP ein Unterstützungs-System, um Initialisierung und Fehlerkorrektur am Computersystem 200 durchzuführen.
Um zusätzliche Flexibilität bereitzustellen, kann die MAP so eingerichtet sein, dass sie die Warteschlangen-Kapazität zum Zeitpunkt der Initialisierung angibt. Diese Daten können als Eintrag in jede der Konfigurationstabellen hinzugefügt werden, die Datenstrukturen sind, welche von MAP für jede Betriebssystem-Instanz im System bereitgestellt werden, um das jeweilige Betriebssystem über notwendige Systemparameter, wie z. B. die Position des gemeinsamen Hauptspeicherbereichs, zu informieren.
17 stellt eine exemplarische Ausführungsform einer Nachrichten-Datenstruktur 1416 dar. Jede Nachrichten-Datenstruktur 1416 befindet sich vorzugsweise an einem Offset von 0 innerhalb eines dazugehörigen Ausgabe-Nachrichtenpuffers 1410 und schließt einen Header-Bereich 1710 und einen Nachrichten-Datenbereich 1712 ein. Der Header-Bereich 1710 ist so dargestellt, dass er die Wörter 0-n einnimmt, und schließt die Pufferlänge, Header-Länge und Zähl-Informationen ein. Die Zähl-Informationen sind vorzugsweise zum Schreiben von Nachrichten durch ein 2200-Betriebssystem (d. h. ein Betriebssystem, das für einen Prozessor des 2200-Typs, erhältlich bei der Unisys Corporation, angepasst ist) eingeschlossen, da Nachrichten, die vom 2200-Betriebssystem in den Speicher geschrieben werden, zusammenhängende Speicherstellen nicht belegen werden. Wenn Knoten, auf denen das 2200-Betriebssystem ausgeführt wird, Nachrichtendaten im gemeinsam genutzten Speicherbereich speichern, speichert jedes 64-Bit-Wort im Hauptspeicher höchstens 32 Datenbits an den Stellen der niedrigstwertigen Bits jedes 64-Bit-Worts im Hauptspeicher. Manche Wörter können weniger Bits speichern, wenn die Nachrichten nicht an einer Wortgrenze beginnen oder enden. Daher gibt das erste Byte Skip Count die Anzahl von Bytes an, die zwischen einem Protokoll-Header und den Nachrichtendaten übersprungen werden sollten. Das Byte Transfer Count gibt die Bytelänge eines dazugehörigen gültigen Nachrichtenfelds an. Die Summe der Byte Skip Counts und Byte Transfer Counts sollte weniger als oder gleich (Länge des Puffers – Länge des Headers)·4 sein.
In einer Ethernet-Umgebung beträgt die maximale Nachrichten-Segmentgröße 1500 Byte oder 375 64-Bit-Wörter für die Nachricht. In einer Ausführungsform schließt die vorliegende Erfindung eine Network Input/Output Processing-(NIOP-, Netzwerk-Eingabe-/Ausgabe-Verarbeitungs-)Architektur ein, d. h. einen Nachrichten-Zuteiler, der von Unisys Corporation entwickelt wurde, wie im U.S.-Patent Nr. 5,659,794, übertragen an Unisys, beschrieben; dieser Nachrichten-Zuteiler ermöglicht die Kombination 50 separater Datenströme zu einem Nachrichtensegment, das über ein Netzwerk zu versenden ist. Somit würde eine Ausgabe-Nachrichtenpuffer-Größe von 427 Wörtern es einem 2200-Betriebssystem ermöglichen, in der gemeinsam genutzten Speicherumgebung der vorliegenden Erfindung so weiterzuarbeiten wie in einer Ethernet LAN-Umgebung. Bei einer Warteschlangen-Länge von 511 und einer Puffergröße von 427 Wörtern beträgt eine Knoten-Puffer-Pool-Größe von (511·427·8)//4096 = 1.748.992 Wörter. Der gesamte gemeinsam genutzte Speicherbereich, der pro gemeinsam genutzter Speicherumgebung benötigt wird, beträgt dann (65.536 + 1.748.992·8)//4096 = 14.057.472 Wörter.
Die Verwendung dieser Datenstrukturen kann anhand eines Beispiels erläutert werden. Angenommen, ein erstes Betriebssystem OS1 möchte eine Nachricht an ein zweites Betriebssystem OS2 senden. Vorausgesetzt, dass die OS1-an-OS2-Knoten-Ausgabe-Warteschlange 1412 nicht voll ist, erhält OS1 eine verfügbare Nachrichten-Datenstruktur (d. h. einen Puffer) 1416a im OS1-Ausgabe-Nachrichtenpuffer-Bereich 1410a. Der Puffer 1410a wird vorzugsweise durch einen Adressen-Offset-Zeiger gekennzeichnet wie oben beschrieben. OS1 erstellt einen Protokoll-Header 1710 für die Nachricht und überträgt den Header 1710 und die Nachricht 1712 vom lokalen Hauptspeicher von OS2 in diesen verfügbaren Nachrichtenpuffer 1416a. OS1 inkrementiert dann die Inhalte eines Enqueued_offset in der OS1-an-OS2-Warteschlange 1510a, um auf den nächsten verfügbaren Eintrag in der OS1-an-OS2-Warteschlange 1510a zu zeigen. OS1 kopiert den Offset-Zeiger, der auf die Nachrichten-Datenstruktur (d. h. den Puffer) 1416a zeigt, in diesen nächsten verfügbaren Eintrag. In einer bevorzugten Ausführungsform wird der Enqueued_offset als Warteschleife verwaltet.
OS2 führt ein Polling durch, um zu ermitteln, ob eine Nachricht von OS1 vorliegt. Die's findet statt anhand eines Vergleichs der Inhalte eines entsprechenden Dequeued_offset für OS2, gespeichert im Kontrollbereich der Knoten-Ausgabe- Warteschlange 1412a von OS2, mit dem entsprechenden Enqueued_offset, das in der OS1-an-OS2-Ausgabe-Warteschlange der Knoten-Ausgabe-Warteschlange 1412b von OS1 gespeichert ist. In einer bevorzugten Ausführungsform wird der Dequeued_offset als Warteschleife verwaltet.
Jeder der acht Dequeued_offsets (in der exemplarischen Ausführungsform) speichert einen Wert zwischen 1 und 511, der auf einen Eintrag innerhalb einer entsprechenden sendenden Knoten-Ausgabe-Warteschlange 1412 des Knotens zeigt. Zum Beispiel speichert der Dequeued_offset, der in Wort 8 der Ausgabe-Warteschlange von OS2 gespeichert ist, eine Distanzadresse, die auf die "Knoten-0-an-Knoten-1-Warteschlange" in der Knoten-Ausgabe-Warteschlange 1412a von OS1 zeigt. Ähnlich speichert der Dequeued_offset, der in Wort 15 der Knoten-Ausgabe-Warteschlange 1412 von OS2 gespeichert ist, eine Distanzadresse, die auf die "Knoten-7-an-Knoten-1-Warteschlange" zeigt. Wie oben erwähnt, schließen die Datenstrukturen eine Knoten-Ausgabe-Warteschlange 1412 und ein dazugehöriges Dequeued_offset ein, wodurch es jedem Knoten oder Betriebssystem ermöglicht wird, eine Nachricht an sich selbst zu senden, z. B. OS1-an-OS1-Knoten-Ausgabe-Warteschlange.
Im vorliegenden Beispiel wird das Dequeued_offset-Feld in Wort 8 der OS2-Knoten-Ausgabe-Warteschlange 1412 mit dem Enqueued_offset-Feld in der OS1-an-OS2-Warteschlange verglichen. Wenn zwei Offset-Einträge identisch sind, ist die Warteschlange leer. Wenn der Enqueued_offset sich vom Dequeued_offset unterscheidet, existieren ein oder mehrere Einträge in der OS1- bis-OS2-Warteschlange.
Nachdem OS1 festgestellt hat, dass eine Nachricht vorliegt, nutzt es die Inhalte des Dequeued_offset, um die Nachricht abzurufen, und inkrementiert dann den Dequeued_offset. Der Nachrichten-Offset-Zeiger wird benutzt, um die Nachricht abzurufen, die in den lokalen Speicher kopiert wird.
Ein sendender Knoten oder ein sendendes Betriebssystem kann einen Mechanismus anwenden, der dem oben beschriebenen Polling-Mechanismus ähnlich ist, um festzustellen, ob eine Warteschlange voll ist, bevor er/es der entsprechenden Warteschlange einen Eintrag hinzufügt. Das heißt, der Dequeued_offset in der Warteschlange des Empfängers wird mit dem entsprechenden Enqueued_offset in der Ausgabe-Warteschlange des sendenden Knotens verglichen. Falls der Inhalt des Enqueued_offset identisch ist mit dem Inhalt des Dequeued_offset, ist die Warteschlange voll, und es kann zu diesem Zeitpunkt keine Nachricht hinzugefügt werden. Enqueued_offsets und Dequeued_offsets stimmen mit der Annahme überein, dass alle Betriebssysteme die Warteschlangen-Bereiche aller anderen Betriebssysteme lesen können, ein Betriebssystem jedoch nur seinen eigenen Warteschlangen-Bereich verändern kann.
In einem virtuellen Speichersystem können Code und/oder Datenstrukturen unter der Kontrolle eines Betriebssystems aus dem Hauptspeicher an einen Massenspeicher übertragen, oder "umgespeichert", werden, um zusätzlichen Raum im Hauptspeicher zu schaffen. In einer exemplarischen Ausführungsform der vorliegenden Erfindung ist die Umspeicherung bei Code und/oder Datenstrukturen gestattet, die in einem lokalen Speicherbereich gespeichert sind, aber nicht bei Datenstrukturen, die sich im gemeinsam genutzten Speicherbereich 160 befinden. Durch diese Einschränkung wird sichergestellt, dass Betriebssysteme, die den gemeinsam genutzten Speicherplatz 160 nutzen, Bewertungen über die Speicherstellen und den Inhalt der Datenstrukturen vornehmen können, die im gemeinsam genutzten Speicherplatz 160 gespeichert sind.
In einer exemplarischen Ausführungsform kommunizieren 2200-Betriebssystem-Anwendungen mit Anwendungen auf Intel-Basis (z. B. Anwendungen, die für Windows NT auf einer Intel-Plattform geschrieben wurden), worin die einzige wesentliche Arbeit des Betriebssystems darin besteht, den gemeinsam genutzten Speicherbereich zu verwalten (z. B. durch Anforderung der Initialisierung der Meldung-Warteschlangen). In dieser exemplarischen Ausführungsform fordert das 2200-Betriebssystem keine Dienste für die Intel-Knoten an und führt keine Dienste für sie durch. Stattdessen werden Dienste durch Anfragen von einer Anwendung an eine andere durchgeführt. Der Fachmann wird erkennen, dass das 2200-Betriebssystem alternativ so verändert werden könnte, dass es direkt Dienste vom Intel-Knoten anfordert.
In einer exemplarischen Ausführungsform ermöglicht der Mechanismus des globalen gemeinsam genutzten Speicherbereichs die Kommunikation zwischen 2200-Betriebssystem-Anwendungsprogrammen und NT- und/oder Unix-Anwendungsprogrammen. Er kann auch genutzt werden, um die Kommunikation zwischen Anwendungen, die auf dem MCP-Betriebssystem ausgeführt werden, und Anwendungen, die auf einem NT- und/oder Unix-Betriebssystem ausgeführt werden, zu erleichtern, und er kann zur Kommunikation zwischen Betriebssystemen verwendet werden. In ähnlicher Weise kann er genutzt werden, um die Kommunikation zwischen Anwendungen, die unter dazugehörigen verschiedenen Instanzen eines NT-Betriebssystems ausgeführt werden, und die Kommunikation zwischen Anwendungen, die unter dazugehörigen verschiedenen Instanzen eines Unix-Betriebssystems ausgeführt werden, zu erleichtern. Der Mechanismus des gemeinsam genutzten Speichers kann verwendet werden, um die Kommunikation zwischen 2200- und MCP-Betriebssystemen zu erleichtern.
In einer exemplarischen Ausführungsform sind Nachrichten, die in den gemeinsamen Hauptspeicherbereich geschrieben werden, typischerweise ASCII-Zeichen, sie können jedoch auch positive ganze Zahlen, z. B. mit einem, zwei oder vier Bytes, und Bitinformationen einschließen. 2200-Betriebssysteme, die mit 36-Bit-Wörtern arbeiten, stellen ASCII-Zeichen als 8 Bits in einem 9-Bit-Byte dar. Intel-Plattformen, die eine IA 32- oder IA 64-Architektur nutzen und mit 32-Bit- bzw. 64-Bit-Wörtern arbeiten, stellen ASCII-Zeichen als 8 Bits in einem 8-Bit-Byte dar. Daher sollten Daten, die in den gemeinsam genutzten Speicherbereich geschrieben oder daraus gelesen werden, einem Konvertierungsprozess unterzogen werden. Diese Konvertierung kann von Hardware-Befehlen eines 2200-Betriebssystems durchgeführt werden. Ein Prozessor des 2200-Typs nutzt einen Block Transfer Pack-(BTP-)Befehl, um ASCII-Daten von 9-Bit- in 8-Bit-Bytes umzuwandeln und die höchstwertigen 32 Bits in den 64-Bit-Wörtern des Hauptspeichers auf Null zu setzen.
Typischerweise erwarten Anwendungen, die auf Intel-Plattformen ausgeführt werden, dass Nachrichtendaten in zusammen hängenden Bytes eingeschlossen sind. Da der Block Transfer Pack-(BTP-)Befehl des 2200-Betriebssystems die Nachrichtendaten nicht in benachbarten Bytes im gemeinsamen Hauptspeicherbereich speichert (normalerweise werden vier Bytes innerhalb eines Worts nicht gebraucht), müssen Gerätetreiber, die auf Intel-Plattformen arbeiten, die Nachrichtendaten in benachbarte Bytes im lokalen Hauptspeicher verschieben, bevor die Nachricht verarbeitet werden kann. In ähnlicher Weise verwendet ein Prozessor des 2200-Typs, wenn er eine Nachricht empfängt, einen Block Transfer Unpack-(BTU-)Befehl, um ASCII-Daten aus dem gemeinsamen Hauptspeicherbereich zu entpacken und in den zugewiesenen lokalen Speicherbereich zu verschieben. Die Block Transfer Pack- und Block Transfer Unpack-Befehle führen auch Big-Endian-/Little-Endian-Konvertierung durch. Beispiele für Datenverschiebung in und aus dem gemeinsam genutzten Speicherbereich 414 bei einer 2200-an-Intel-Nachricht, einer Intel-an-2200-Nachricht und einer Intel-an-Intel-Nachricht werden unten geliefert.
Vorzugsweise ist der Kommunikationsmechanismus über den globalen gemeinsam genutzten Speicherbereich für die Software, die auf dem System ausgeführt wird, so transparent wie möglich, damit Software-Änderungen minimiert werden und das System mit verschiedenen Standards für offene Systeme so kompatibel wie möglich ist. Zum Beispiel kann das System gemäß einem Aspekt der vorliegenden Erfindung gegenüber den oberen Software-Schichten so dargestellt werden, als ob die Kommunikation über Kabel aufrechterhalten würde (siehe Abschnitt IV.B unten). In einer exemplarischen Ausführungsform verwendet das System ein Ethernet-Protokoll. Der Fachmann wird erkennen, dass auch andere Protokolle, z. B. ein ATM-Protokoll, verwendet werden können.
Bei NT/UNIX-Knoten ist eine Gemeinschaftsspeicher-Schnittstelle vorzugsweise in einem NIC-Gerätetreiber sichtbar, der auf der LLC/MAC-Ebene des Open Standards Interconnection-(OSI-)Kommunikationsmodells existiert. LLC/MRC sind zwei Teilschichten des Kommunikationsmodells der OSI-Ebene 2. LLC kann eine Schnittstelle zwischen den Schichten 2 und 3 sein. MAC ist eine IEEE-Teilschicht, die mit verschiedenen LANs, wie z. B. Ethernet, Token Ring, Token Bus usw. arbeitet.
Bei Knoten mit 2200-Betriebssystemen ist diese Sichtbarkeit ebenfalls auf der LLC/MAC-Ebene vorhanden. Diese Konstruktion macht es auch einfach, manchen Partitionen die Kommunikation über den gemeinsam genutzten Speicherbereich zu ermöglichen, während andere Partitionen die Kommunikation über ein Kabel betreiben. Die zwei Arten von Kommunikation erscheinen von den oberen Software-Schichten aus gleich.
Da das Ethernet-Protokoll eine Grenze von 1500 Byte pro Übertragung festlegt, muss eine große Nachricht möglicherweise in Segmente unterteilt und in mehreren Nachrichtenübermittlungs-Schritten übertragen werden.
Ethernet hat eine Begrenzung von 1500 Byte für die Menge von Daten in einer Übertragung. Daher werden 1500 Byte, wenn eine Ethernet-Verbindung durch gemeinsam genutzten Speicher ersetzt wird, zur Begrenzung, wie viele Daten in einen Puffer platziert werden können, der zur Ausgabe an einen anderen Knoten in die Warteschlange eingeordnet wird. Wie bei allen Kommunikationsprotokollen können Nachrichten jeder Größe gesendet werden, aber sie müssen möglicherweise in einer Reihe separater Übertragungen gesendet werden (Puffer).
Ein Prozessor des 2200-Typs kann Nachrichtendaten unter Anwendung des oben erwähnten Block Transfer Pack-Befehls in den gemeinsam genutzten Speicherbereich übertragen.
B. Interrupt-gesteuerte Kommunikation über gemeinsam genutzten Speicher
Es wird nun als alternative Ausführungsform eine Interruptgesteuerte Verwaltungs-Implementierung für den gemeinsam genutzten Speicherbereich beschrieben, einschließlich einer Beschreibung, wie auf den gemeinsam genutzten Speicherbereich gemäß dieser alternativen Ausführungsform zugegriffen und wie er verwaltet werden soll. In dieser Ausführungsform wird die Verwaltung des gemeinsam genutzten Speicherfensters von Programmcode durchgeführt, der in Core Services-Software ausgeführt ist, die sich auf jeder Partition befindet. Die Core Services-Software auf jeder Partition bietet eine Anwendungspro grammierschnittstelle (application programming interface, API), die ein Client, der in dieser Partition ausgeführt wird, aufrufen kann, um bestimmte gemeinsam genutzte Speicher-Dienste anzufordern, z. B. die Kommunikation mit einem Client auf einer anderen Partition über das gemeinsam genutzte Speicherfenster. Wie hierin und in den Ansprüchen verwendet, kann ein "Client" das Betriebssystem, ein Gerätetreiber, ein Anwendungsprogramm oder jede andere Software oder jeder andere Programmcode sein, die/der auf einer Partition ausgeführt wird und die Nutzung des gemeinsam genutzten Speicherfensters erfordert. Wie ebenfalls hierin und in den Ansprüchen verwendet, kann der Begriff "eine Kommunikation" ein Signal (im Folgenden beschrieben), eine Nachricht in Form von Daten (die in einem zugewiesenen Puffer im gemeinsam genutzten Speicherfenster gespeichert sein können oder nicht) oder jede andere Form von Informationen oder Daten bezeichnen, die für irgendeinen Zweck zwischen Partitionen ausgetauscht werden sollen. Anders als in der oben beschriebenen Ausführungsform, in der eine Abfragetechnik angewandt wird, um zu ermitteln, ob eine Kommunikation zwischen Partitionen übertragen werden soll, verwendet diese Ausführungsform zur Kommunikation zwischen Partitionen einen Inter-Prozessor-Interrupt-Mechanismus wie unten detaillierter beschrieben.
Wie in der obigen Ausführungsform kann auch diese Ausführungsform verwendet werden, um die Kommunikation zwischen Partitionen zu erleichtern, welche unter der Kontrolle verschiedener Betriebssysteme (z. B. Unisys MCP, Unisys OS 2200, Windows NT, Unix usw.) oder verschiedener Instanzen desselben Betriebssystems ausgeführt werden.
1. Struktur des gemeinsam genutzten Speicherbereichs
19 zeigt die Struktur des gemeinsam genutzten Speicherfensters gemäß dieser alternativen Ausführungsform. Wie gezeigt, befindet sich an der Basis des gemeinsam genutzten Speicherfensters eine Kontrollstruktur 1900, gefolgt vom Rest des gemeinsam genutzten Speicherfensters, 1916, das in einzelne Seiten unterteilt ist. In der vorliegenden Ausführungsform umfasst jede Seite 4KByte; die Größe kann jedoch in anderen Ausführungsformen anders sein. Jede Seite kann in Gebrauch, verfügbar oder nicht in Gebrauch sein. Wie im Folgenden beschrieben, kann ein Client anfordern, dass ein Teil des gemeinsam genutzten Speicherfensters ihm zugewiesen wird, z. B. um einen Puffer zu definieren, und die Core Services-Software weist dann die erforderliche Anzahl von Seiten zu, um diese Anforderung zu erfüllen.
Die Kontrollstruktur 1900 des gemeinsam genutzten Speicherbereichs umfasst einen Header 1910, eine Zuweisungs-Struktur 1912 und eine Vielzahl von Partitions-Eingabe-Warteschlangen mit einem dazugehörigen Header 1914. Die Informationen in der Kontrollstruktur sind privat. Direkter Zugriff auf diese Informationen wird Clients der Core Services-Software nicht gewährt. Stattdessen führt die Core Services-Software-API Aufrufe durch, die Client-bezogene Informationen über Prozedur-Parameter an einen Client zurückgeben. In der vorliegenden Ausführungsform schließen Wörter in der Kontrollstruktur 64 Bit ein, worin die oberen 32 Bit Nullen sind, um die verschiedenen Wortgrößen zu berücksichtigen, die von verschiedenen Prozessor-Architekturen verwendet werden.
2. Liste freier Seiten
In der vorliegenden Ausführungsform werden, um einen Überblick über die verfügbaren gemeinsam genutzten Speicherseiten, d. h. diejenigen, die nicht schon in Gebrauch sind, zu behalten, die verfügbaren Seiten durch Zeiger im ersten Wort jeder Seite verknüpft, um eine verkettete Liste verfügbarer Seiten zu bilden. Die verkettete Liste verfügbarer Seiten wird hierin als Liste freier Seiten bezeichnet. Die Kontrollstruktur 1900 liefert einen Zeiger auf die erste Seite der verketteten Liste (d. h. den Anfang der Liste freier Seiten).
3- Client-Verzeichnis-Tabelle
Die Core Services-Software weist eine oder mehrere Seiten des gemeinsam genutzten Speicherfensters zu, um eine Client-Verzeichnis-Tabelle (nicht dargestellt) zu speichern. Die Client-Verzeichnis-Tabelle ist eine Registrierung der Clients auf jeder Partition, die das gemeinsam benutzte Speicherfenster nutzen. Im Speziellen muss in der vorliegenden Ausführungsform jeder Client der Core Services-Software auf einer bestimmten Partition bei der Core Services-Software als Mitglied einer Client-Gruppe eingetragen werden. Zwei Clients auf derselben Partition können nicht Mitglieder derselben Client-Gruppe sein; wenn es mehrere Clients der Core Services-Software auf einer Partition gibt, muss sich jeder als Mitglied einer anderen Client-Gruppe registrieren. Jede Client-Gruppe hat einen dazugehörigen Namen (Client-Gruppen-Namen) und eine dazugehörige Kennung (Client-Gruppen-ID). Die Client-Verzeichnis-Tabelle enthält einen Eintrag für jede Client-Gruppe, der den Client-Gruppen-Namen und jede Partition angibt, für die ein Client als Mitglied der Gruppe registriert ist. Wenn sich ein Client bei der Core Services-Software als Mitglied einer bestimmten Client-Gruppe registriert, liefert die Core Services-Software die Client-Gruppen-ID an den Client zurück. Die Client-Gruppen-ID wird verwendet, um die sendenden und empfangenden Clients zu kennzeichnen, wenn Nachrichten über das gemeinsam genutzte Speicherfenster übertragen werden, wie im Folgenden beschrieben.
4. Arten von gemeinsamen Speicherseiten
Die Core Services-Software kann eine oder mehrere Seiten des gemeinsam genutzten Speicherbereichs zuordnen, entweder zu ihrer eigenen Verwendung oder aufgrund einer Client-Anforderung, einen Teil des gemeinsam genutzten Speicherbereichs zu reservieren. In der vorliegenden Ausführungsform sind vier verschiedene Arten von Seiten definiert.
a. Speicherseiten des Typs 1
Speicherseiten des Typs 1 können in der vorliegenden Ausführungsform nur für die Nutzung durch die Core Services-Software auf einer Partition reserviert werden; es gibt keine Schnittstellen, die es einem Client ermöglichen, die Reservierung einer Seite des Typs 1 anzufordern. Zum Beispiel wird die oben beschriebene Client-Verzeichnis-Tabelle in einer oder mehreren Seiten des Typs 1 gespeichert, die von der Core Services-Software zugeordnet wurden. Wenn die Core Services-Software eine Speicherseite des Typs 1 zuordnet, wird ein Core Services-Header am Anfang der Seite erstellt. 32A zeigt den Inhalt des Core Services-Headers für Seiten des Typs 1 gemäß der vorliegenden Ausführungsform.
Das erste Feld (Partitions-Eigentums-Maske) wird genutzt, um eine Angabe zu speichern, welche Partitionen Zugriffsrechte auf die Seite haben. Im Speziellen enthält die Partitions-Eigentums-Maske acht Bit, eines für jede mögliche Partition im Computersystem. Für jede Partition, die Eigentumsrechte auf die Seite hat, wird das entsprechende Bit in der Partitions-Eigentums-Maske gesetzt. Im Falle der Client-Verzeichnis-Tabelle z. B. wird bei jeder Partition, die Zugriff auf die Tabelle anfordert, ihr Bit der Partitions-Eigentums-Maske in jeder Seite gesetzt, welche die ganze Tabelle oder einen Teil davon enthält.
Obwohl es in der vorliegenden Ausführungsform keine Schnittstellen gibt, die es einem Client ermöglichen, die Zuordnung von Seiten des Typs 1 anzufordern, enthält der Core Services-Header in einer Seite des Typs 1 weiter ein Client-Gruppen-ID-Feld, um zukünftige Ausführungsformen zu ermöglichen, in denen es wünschenswert sein kann, Clients die Anforderung der Zuordnung von Seiten des Typs 1 zu gestatten. Dieses Feld würde verwendet werden, um die Client-Gruppen-ID der Clients aufzunehmen, die Eigentumsrechte auf die Seite haben. In der vorliegenden Ausführungsform wird dieses Feld jedoch nicht verwendet.
Das DeallocationLock-Feld wird genutzt, um Änderungen der Eigentumsrechte auf die Seite zu koordinieren. Dieses Feld ist Teil eines größeren Sperrmechanismus der vorliegenden Erfindung, implementiert in der gesamten Core Services-Software, der es verschiedenen Partitionen ermöglicht, den Zugriff auf die verschiedenen Strukturen, Seiten und Tabellen des gemeinsam genutzten Speicherfensters nach Bedarf auf konsistente Art und Weise zu sperren, um sicherzustellen, dass nur eine Partition irgendeine bestimmte Struktur, Seite oder Tabelle zur Zeit modifizieren kann (d. h., um den Zugriff auf diese Strukturen zu synchronisieren).
Das DeallocationLock-Feld, ebenso wie alle anderen Sperrfelder, die im Folgenden beschrieben sind, besteht aus zwei 64-Bit-Wörtern, bezeichnet als Wort 0 und Wort 1. Wort 0 bezeichnet ein Sperrstatus-Wort, und Wort 1 bezeichnet ein Eigentümer-Wort. Das niederwertige Bit in Wort 0 bezeichnet ein Bit "in Gebrauch". Das Setzen dieses Bits zeigt einen Sperr-Status an. Wort 1 wird verwendet, um die Partitions-ID der Partition zu speichern, die den Riegel erwirbt, wodurch der Eigentümer des Riegels ermittelt werden kann.
Die meisten Betriebssysteme und die Prozessoren, auf denen sie ausgeführt werden, liefern ein Verfahren, mit dem das Betriebssystem und die Clients, die auf diesen Betriebssystemen ausgeführt werden, einen Riegel für eine bestimmte Datenstruktur erwerben können. Das hierin verwendete Sperrfeld-Format ist mit einer Reihe von Betriebssystemen kompatibel, einschließlich z. B. Windows NT, UnixWare und Unisys MCP. Die Core Services auf einer bestimmten Partition müssen für das Betriebssystem und die Prozessorarchitektur dieser Partition maßgeschneidert werden.
Gemäß einem wichtigen Merkmal das Sperrmechanismus der vorliegenden Erfindung muss bei der ersten Zuordnung einer Speicherseite des Typs 1 die zuordnende Partition einen systemweit gültigen Schlüssel (ein Feld der Zuordnungsstruktur, das im Folgenden beschrieben ist) erwerben, um den Zugriff auf die Seite während der Zuordnung zu sperren. Wenn jedoch die Inhaberschaft an einer oder mehreren zugeordneten Seiten auf andere Partitionen erweitert oder übertragen wird, muss nur ein Riegel für die betreffenden Seiten erworben werden. Das DeallocationLock-Feld auf diesen Seiten wird für diesen Zweck verwendet. Dies ermöglicht einen höheren Durchsatz von Kommunikation zwischen Partitionen, da Konkurrenz um den systemweiten Schlüssel vermieden wird.
b. Speicherseiten des Typs 2
Die Zuordnung dieser Art von Speicherseite kann von einem Client angefordert werden, z. B. um einen Puffer zur Übertragung von Nachrichtendaten an einen Client auf einer anderen Partition zu bestimmen. Wie bei Seiten des Typs 1 wird auch bei der Zuweisung einer Speicherseite des Typs 2 zu einem bestimmten Client ein Core Services-Header am Anfang der Seite erstellt. 32B zeigt den Inhalt des Core Services-Headers für Seiten des Typs 2 gemäß der vorliegenden Ausführungsform.
Die Felder "Partitions-Eigentums-Maske" und "Client-Gruppen-ID" sind identisch mit den entsprechenden Feldern im Header für Seiten des Typs 1. Das heißt, die Partitions-Eigentums-Maske gibt an, welche Partition(en) Eigentumsrechte auf die Seite hat/haben, und das Client-Gruppen-ID-Feld enthält die Client-Gruppen-ID der Clients, die Eigentumsrechte auf die Seite haben. Wenn die Seite zum ersten Mal zugewiesen wird, enthält dieses Feld die Client-Gruppen-ID des Clients, der die Zuweisung angefordert hat.
Das DeallocationLock-Feld wird, wie das entsprechende Feld im Header von Seiten des Typs 1, verwendet, um Änderungen in der Inhaberschaft an der Seite zu koordinieren. Jede Partition, die eine Änderung in der Inhaberschaft an einer Seite vornehmen möchte, muss vorher über das DeallocationLock-Feld den Riegel für diese Seite erwerben.
Die Felder "Typ 3-Seitenzählung" und "Typ 3-Seitenreferenz" betreffen ein zusätzliches Merkmal der vorliegenden Erfindung, wodurch als Teil einer Anforderung zur Zuordnung einer Speicherseite des Typs 2 null oder mehr Seiten des Typs 3 im Zusammenhang mit der Typ 2-Anforderung zugewiesen werden können, um den Puffer in der Zuordnungs-Anforderung zu füllen. Das Feld "Typ 3-Seitenzählung" gibt die Gesamtzahl von Speicherseiten des Typs 3 an, die mit der Anforderung nach dem Typ 2 verknüpft werden, und das Feld "Typ 3-Seitenreferenz" gibt eine Position auf der Seite des Typs 2 an, die Referenzen (d. h. Zeiger) auf die damit verknüpften Seiten des Typs 3 enthält.
c. Speicherseiten des Typs 3
Wie oben erwähnt, wird diese Art von Speicherseite in Kombination mit einer Speicherseite des Typs 2 verwendet. Eine Seite des Typs 3 enthält Client-Daten, und das Eigentumsrecht daran hat eine Client-Gruppe; die Seite vom Typ 3 enthält jedoch keine expliziten Client-Gruppen-Informationen. Stattdessen wird die Client-Gruppen-Inhaberschaft an einer Seite des Typs 3 durch die Inhaberschaft an ihrer dazugehörigen Speicherseite des Typs 2 bestimmt, wie im Client-Gruppen-ID-Feld des Core Services-Headers dieser Seite des Typs 2 angegeben. Die Inhaberschaft an einer Seite vom Typ 3 wird immer dann implizit geändert, wenn die Inhaberschaft an ihrer verknüpften Seite vom Typ 2 geändert wird.
d. Speicherseiten des Typs 4
Diese Art von Speicherseite ist für die statische Inhaberschaft einer oder mehrerer Partitionen. Anders als bei Speicherseiten des Typs 1, 2 und 3 ist die Inhaberschaft an Speicherseiten des Typs 4 in einer Zuordnungstabelle angegeben, die im Folgenden beschrieben ist. Daher erfordern alle Änderungen der Inhaberschaft an Seiten des Typs 4 das Erwerben des systemweiten Riegels.
5. Kontrollstruktur-Header
20 zeigt den Inhalt des Kontrollstruktur-Headers 1910 gemäß der vorliegenden Ausführungsform. Ein Version ID-Feld wird benutzt, um die jeweilige Ausgabe oder Version der Core Services-Software, die auf dem Computersystem ausgeführt wird, anzugeben. Ein Feld "Status des gemeinsamen Speicherbereichs" gibt den Status des gemeinsam genutzten Speicherbereichs an (z. B. "nicht initialisiert", "initialisierend", "initialisiert" und "Cleanup"). Ein Feld "Partitions-ID der Master-Partition" gibt an, welche Partition als "Master" des gemeinsam genutzten Speicherfensters bestimmt wird die Master-Partition hat zusätzliche Zuständigkeiten für die Verwaltung des gemeinsam genutzten Speicherfensters, wie unten detaillierter beschrieben. Ein Feld "Gemeinsamer Speicherbereich-Partitions-Überprüfungs-Intervall" gibt das Zeitintervall an, in dem eine Partition bestimmte Zustandsinformationen aktualisieren muss, um anderen Partitionen mitzuteilen, dass sie aktiv ist. Ein Feld "Client-Verzeichnis-Tabellen-Header" enthält einen Zeiger auf den Anfang der Client-Verzeichnis-Tabelle und ein Sperrfeld, das verwendet wird, um den Zugriff auf die Tabelle gemäß dem Sperrmechanismus der vorliegenden Erfindung zu koordinieren.
Der Kontrollstruktur-Header 1910 endet mit Informationen über jede der Partitionen im Computersystem, einschließlich der Art von Betriebssystem, das auf der Partition ausgeführt wird (z. B. NT, UnixWare, MCP usw.) und Informationen, die benötigt werden, um Inter-Prozessor-Interrupts an die Partition auszugeben.
6. Zuordnungsstruktur
Gemäß der vorliegenden Ausführungsform wird die Verwaltung der gemeinsam genutzten Speicherseiten durch eine Zuordnungstabelle (nicht dargestellt) erleichtert. Jede zuweisbare Seite im gemeinsam genutzten Speicherfenster wird durch einen Eintrag in der Zuordnungstabelle dargestellt. Jeder Eintrag gibt an, ob die entsprechende Seite "in Gebrauch" oder "verfügbar" ist, oder verweist auf Speicher, der nicht in Gebrauch ist, und kann auch den Seitentyp angeben. Bei einer Speicherseite des Typs 4 gibt der Eintrag, in Form einer Partitions-Eigentums-Maske, wie sie in den Headern der Speicherseiten des Typs 1 und Typs 2 zu finden ist, weiter an, welche Partition(en) Eigentumsrechte auf die Seite hat/haben. So wird in dieser Hinsicht Inhaberschaft an Seiten des Typs 4 anders verwaltet als bei Seiten des Typs 1, 2 und 3 (worin Eigentums-Informationen sich im Core Services-Header der Seite selbst befinden). Die Zuordnungstabelle selbst nimmt, wie die Client-Verzeichnis-Tabelle, eine oder mehrere Seiten des gemeinsam genutzten Speicherfensters ein.
Die Zuordnungsstruktur 1912 an der Basis des gemeinsam genutzten Speicherfensters steuert bestimmte Parameter, die mit der Zuordnungstabelle und anderen Strukturen verknüpft sind. 21 stellt den Inhalt der Zuordnungsstruktur gemäß der vorliegenden Ausführungsform dar. Ein Sperrfeld (Allocation Lock) wird verwendet, um den Zugriff auf die Zuordnungstabelle zu steuern. Dies ist die oben erwähnte systemweite Sperre (im Gegensatz zu den einzelnen Seiten-Sperren in den Headern der Seiten des Typs 1 und Typs 2). Partitionen müssen diesen Riegel für jede erste Zuordnung von Seiten erwerben. Dieser Schlüssel muss auch für jede spätere Änderung der Inhaberschaft an einer Seite des Typs 4 angefordert werden, da die Inhaberschaft an Seiten des Typs 4 in deren entsprechenden Einträgen in der Zuordnungstabelle verwaltet wird. Wie oben erwähnt, müssen jedoch für spätere Änderungen der Inhaberschaft an Seiten des Typs 1 und Typs 2 nur die einzelnen Seiten-Sperren in den Headern der Seiten selbst erworben werden. Diese Fähigkeit, einzelne Seiten (der Typen 1 und 2) zu sperren, ermöglicht einen höheren Durchsatz zwischen Partitionen, da Konkurrenz um den systemweiten Riegel (Allocation Lock) ausgeschlossen wird.
Ein Feld "Länge des gemeinsam genutzten Speicherbereichs" gibt die Anzahl zuweisbarer Seiten im gemeinsam genutzten Speicherfenster an. Ein Feld "Zeiger auf gemeinsam genutzte Speicherseite" liefert einen Zeiger auf den Anfang der zuweisbaren Seiten. Ein "Liste-freier-Seiten-Header" liefert einen Zeiger auf den Anfang der Liste freier Seiten, und ein "Zuordnungstabellen-Header" liefert den Zeiger auf den Anfang der Zuordnungstabelle.
7. Signale
Die grundlegende Kommunikationseinheit in dieser Ausführungsform ist ein Signal. In der vorliegenden Ausführungsform gibt es zwei Hauptkategorien von Signalen: (1) Core-Services-an-Core-Services-Signale zwischen Partitionen und (2) Client-an-Client-Signale zwischen Partitionen. Core-Services-an-Core-Services-Signale sind solche, die zwischen den Core Services-Programmen gesendet werden, welche auf verschiedenen Partitionen ausgeführt werden. Client-an-Client-Signale sind solche, die zwischen Clients auf verschiedenen Partitionen versendet werden. Jede Signalkategorie hat einen oder mehrere Signal-Subtypen. Jedes Signal umfasst einen Core Services-Informationsabschnitt und einen Client-Informationsabschnitt. Jeder dieser Abschnitte umfasst eine Reihe von Wörtern, deren Definition vom Typ abhängt.
Bei den Core-Services-an-Core-Services-Signal-Subtypen ist der Client-Informationsabschnitt nicht definiert. Alle Informationen sind im Core Services-Informationsabschnitt enthalten. Die folgenden Core-Services-an-Core-Services-Signal-Subtypen sind in der vorliegenden Ausführungsform definiert:

(1) Mitgliedschafts-Änderungs-Signal: Immer dann, wenn ein Client sich bei der Core Services-Software auf einer Partition registriert oder abmeldet, muss die Core Services-Software dieses Signal an die Core Services-Software auf jeder anderen Partition senden, bei der ein Client in derselben Client-Gruppe registriert ist, um sie zu benachrichtigen, dass ihr Client sich registriert oder abmeldet. Der Core Services-Informationsabschnitt des Signals enthält die Client-Gruppen-ID der Client-Gruppe, bei der sich der Client mit der Gruppe registriert bzw. abmeldet.
(2) Senden des Signals wieder aufnehmen: Dieses Signal wird von einer empfangenden Partition verwendet, um die Core Services-Software auf einer sendenden Partition zu benachrichtigen, dass sie das Senden von Signalen an sie wieder aufnehmen kann (die Verwendung dieses Signals ist unten in Verbindung mit der Beschreibung des Überlauf-Flags jeder Eingabe-Warteschlange genauer beschrieben).
(3) You Have Been Marked Dead Signal (Tot-Signal): Dieses Signal wird von der Core Services-Software auf der Master-Partition an eine Partition gesendet, bei welcher der Master ermittelt hat, dass sie nicht arbeitet;

Bei Client-an-Client-Signal-Subtypen werden sowohl der Core Services-Informationsabschnitt als auch der Client-Informationsabschnitt definiert. In der vorliegenden Ausführungsform wurde nur folgender Client-an-Client-Signal-Subtyp definiert: Signalübermittlungs-Signal. Wie unten detaillierter beschrieben, ruft ein Client auf einer Partition, wenn er ein Signal (und eventuell einen Puffer von Nachrichtendaten) an einen Client auf einer anderen Partition senden möchte, eine "Signal senden"-Schnittstelle der Core Services-API auf. Als Reaktion sendet die Core Services-Software das Signalübermittlungs-Signal an die Partition, auf welcher der empfangende Client ausgeführt wird. Der Core Services-Informationsabschnitt des Signalübermittlungs-Signals enthält die Client-Gruppen-ID der sendenden und empfangenden Clients und kann auch eine Kennung (d. h. eine Referenz) für eine oder mehrere Seiten gemeinsam genutzten Speicherbereichs enthalten, die dem Client zugewiesen wurden, um z. B. einen Puffer zu definieren, der ein gemeinsam genutztes Speicherobjekt enthält, das für die empfangende Partition bestimmt ist. Beispiele für gemeinsam genutzte Speicherobjekte sind Client-Nachrichten, Client-Datenströme, Client-Ereignisse und Core Services-Ereignisse. Der Client-Informationsabschnitt ist für die Core Services-Software nicht einsehbar, kann jedoch von den sendenden und empfangenden Clients für jeden gewünschten Zweck genutzt werden. Zum Beispiel kann er verwendet werden, um Kurzmeldungen zwischen Clients zu versenden. In der vorliegenden Ausführungsform umfasst der Client-Informationsabschnitt maximal fünf (5) Wörter.
8. Eingabe-Warteschlangen und Eingabe-Warteschlangen-Header
Ein Eingabe-Warteschlangen-Mechanismus, in Verbindung mit dem unten beschriebenen Inter-Prozessor-Interrupt-Mechanismus, wird verwendet, um einer empfangenden Partition zu signalisieren, dass Daten verfügbar sind. Jede Partition hat eine separate Eingabe-Warteschlange für jede andere mögliche Partition im Computersystem. In der vorliegenden Ausführungsform hat jede Partition auch eine Eingabe-Warteschlange für sich selbst, die z. B. dann verwendet wird, wenn die Core Services-Software auf der Partition ein Signal an einen Client auf derselben Partition senden muss. So hat in der vorliegenden Ausführungsform, worin das Computersystem in maximal acht separaten Partitionen konfiguriert werden kann (d. h. jedes der acht Sub-Pods bestimmt eine separate Partition), jede Partition acht separate Eingabe-Warteschlangen (eine für jede der anderen sieben Partitionen und eine für sich selbst), d. h., es sind insgesamt vierundsechzig (64) Eingabe-Warteschlangen. Diese Eingabe-Warteschlangen befinden sich im Abschnitt 1914 der Kontrollstruktur 1900 des gemeinsam genutzten Speicherbereichs, gemeinsam mit einem Header. Signale werden von der Core Services-Software auf einer Partition erzeugt und an die Core Services-Software auf einer anderen Partition über die entsprechende Eingabe-Warteschlange dazwischen geliefert.
29 zeigt den Inhalt des Eingabe-Warteschlangen-Headers gemäß der vorliegenden Ausführungsform. Ein Eingabe-Warteschlangen-Zeiger-Feld enthält einen Zeiger auf den Anfang der tatsächlichen Eingabe-Warteschlangen. Ein Feld "Anzahl der Eingabe-Warteschlangen" gibt die Anzahl der Eingabe-Warteschlangen im Eingabe-Warteschlangen-Bereich 1914 (64 in der vorliegenden Ausführungsform) an. Ein Feld "Eingabe-Warteschlangen-Länge" gibt die Länge (in Wörtern) jeder Eingabe-Warteschlange an. In der vorliegenden Ausführungsform wird die Länge mit 2048 Wörtern angegeben. Ein Feld "Eingabe-Warteschlangen-Signallänge" gibt die Gesamtlänge jedes Signals (Core Services-Informationsabschnitt + Client-Informationsabschnitt) an. Die Gesamtlänge jedes Signals ist gleich und festgelegt. Ein Feld "Anzahl der Signale in Eingabe-Warteschlange" schließlich gibt die Gesamtzahl möglicher Signale an, die jede Eingabe-Warteschlange zur Zeit aufnehmen kann.
30 zeigt den Inhalt jeder Eingabe-Warteschlange gemäß der vorliegenden Ausführungsform. Wie gezeigt, hat jede Eingabe-Warteschlange ein Sperrfeld 3010, das von der Core Services-Software genutzt wird, um den Zugriff auf die Eingabe-Warteschlange während der Aktualisierung von Informationen in der Warteschlange zu sperren, ein Zählfeld 3012, das die aktuelle Anzahl von Signalen in der Warteschlange angibt, und ein Überlauf-Flag 3014, das verwendet wird, um anzugeben, dass die Warteschlange ihre Kapazität erreicht hat, dass es jedoch zusätzliche Signale gibt, die in die Warteschlange übertragen werden sollen, sobald Platz verfügbar wird. Auf diese Felder folgt ein Raum 3016 für eine festgelegte Anzahl von Signalen (wie im Feld ""Anzahl der Signale in Eingabe-Warteschlange" des Eingabe-Warteschlangen-Headers, s. 29 angegeben).
In der vorliegenden Ausführungsform werden die 64 Eingabe-Warteschlangen nebeneinander im Eingabe-Warteschlangen-Bereich 1914 der Kontrollstruktur 1900 gruppiert. Das heißt, die ersten acht Eingabe-Warteschlangen in der Struktur gehören zur ersten Partition, und sukzessive Gruppen von acht Eingabe-Warteschlangen gehören zu den sukzessiven anderen sieben Partitionen.
a. Bevorzugte Arbeitsweise
Während des Betriebs erstellt die Core Services-Software immer dann, wenn sie eine Anfrage von einem Client erhält, ein Signal an eine andere Partition zu senden, das Signal anhand der Informationen, die vom Client geliefert werden, und versucht, das Signal in einen verfügbaren Eintrag in der entsprechenden Eingabe-Warteschlange für die empfangende Partition zu stellen. Wenn keine Einträge verfügbar sind, wird das Überlauf-Flag 3014 der Eingabe-Warteschlange gesetzt, um die empfangende Partition zu informieren, dass Signale auf ihre Übertragung warten, die nicht übertragen werden konnten, weil die Eingabe-Warteschlange voll war, und dem Client wird eine Fehlermeldung zurückgeliefert. In einem solchen Fall setzt die empfangende Partition, wenn sie anschließend die Eingabe-Warteschlange leert, das Überlauf-Flag 3014 zurück und sendet ein "Senden des Signals wieder aufnehmen"-Signal an die sendende Partition, um diese zu informieren, dass sie nun anschließende Signale, die von ihren Clients zur Kommunikation mit der empfangenden Partition in die Eingabe-Warteschlange gestellt werden, übertragen kann.
Auf der Empfangsseite untersucht die Core Services-Software auf der empfangenden Partition, wenn sie einen Inter-Prozessor-Interrupt von einer sendenden Partition empfängt, die Zählfelder in jeder ihr zugewiesenen Eingabe-Warteschlange, um zu ermitteln, bei welchen Eingabe-Warteschlangen Signale anstehen. Wenn die Core Services-Software eine Eingabe-Warteschlange findet, bei der dies der Fall ist, überträgt sie die Signale an einen lokalen Verarbeitungspuffer in ihrem exklusiven Speicherfenster und setzt die Zählung in der Eingabe-Warteschlange zurück. Jedes empfangene Signal, das aus einer bestimmten Eingabe-Warteschlange extrahiert wird, wird dann (anhand der Client-Gruppen-ID im Signal) über eine "Signal empfangen"-Call-back-Schnittstelle, die alle Clients implementieren müssen, an den entsprechenden Client geleitet.
b. Alternative Arbeitsweise
In einer alternativen Ausführungsform kann die Core Services-Software auf jeder Partition, um für eine effizientere Übertragung von Client-Signalen in die verschiedenen Eingabe-Warteschlangen als Reaktion auf Sendeanforderungen zu sorgen, in ihrem exklusiven Speicherfenster für jede mögliche Zielpartition eine Partitions-Sende-Warteschlange (d. h. einen Puffer) (nicht dargestellt) einrichten. In dieser alternativen Ausführungsform setzt die Core Services-Software auf einer Partition immer dann, wenn sie auf eine volle Eingabe-Warteschlange trifft, die sie daran hindert, zusätzliche Signale in die Eingabe-Warteschlange zu stellen, das Überlauf-Flag in der Eingabe-Warteschlange und stellt dann diese Signalanforderungen in die entsprechende lokale Sende-Warteschlange, bis wieder Einträge in der Eingabe-Warteschlange verfügbar werden.
Zusätzlich kann auf der Empfangsseite die Core Services-Software auf jeder Partition in ihrem exklusiven Speicherfenster lokale Client-Signal-Tank-Warteschlangen erstellen – eine für jeden Client, der sich der Core Services-Software zu erkennen gegeben hat. Jedes empfangene Signal, das aus einer bestimmten Eingabe-Warteschlange einer empfangenden Partition extrahiert wird, wird (auch hier auf der Grundlage der Client-Gruppen-ID im Signal) in die Client-Signal-Tank-Warteschlange übertragen. Jedes Signal in einer Tank-Warteschlange wird schließlich über einen Aufruf der "Signal empfangen"-Schnittstelle des angesteuerten Empfänger-Clients an diesen übermittelt.
Die lokalen Sende-Warteschlangen und Tank-Warteschlangen in dieser alternativen Ausführungsform, in Kombination mit der Verwendung des Überlauf-Flags wie oben beschrieben, dienen dazu, allen Clients der Core Services-Software eine effiziente und gerechte Nutzung der gemeinsam genutzten Speicherressourcen zu ermöglichen. Da die Signale jedes Clients lokal in die Warteschlange gestellt werden, bleiben die Eingabe-Warteschlangen im gemeinsam genutzten Speicherfenster auf effiziente Art und Weise offen für Kommunikation. Es gehen keine Signale verloren, wenn die Kapazität einer Eingabe-Warteschlange erreicht ist, und die Eingabe-Warteschlangen werden schnell geleert, um die Zeit zu minimieren, während der Signale an einer bestimmten Sendewarteschlange warten.
9. Inter-Prozessor-Interrupt-Mechanismus
Wie oben erwähnt, wird ein Inter-Prozessor-Interrupt-Mechanismus verwendet, um eine empfangende Partition zu informieren, dass eine sendende Partition Signale in eine ihrer Eingabe-Warteschlangen gestellt hat. Speziell erstellt in der vorliegenden Ausführungsform jede Partition einen einzelnen Interrupt-Vektor, den alle anderen Partitionen nutzen, um Inter-Prozessor-Interrupts an ihn zu senden. Immer dann, wenn eine sendende Partition ein Signal in die Eingabe-Warteschlange für eine bestimmte empfangende Partition stellt, das die Eingabe-Warteschlange aus einem Leerzustand (Zählung = 0) in einen Nich-Leerzustand (Zählung > 0) versetzt, erzeugt die Core Services-Software auf der sendenden Partition einen Inter-Prozessor-Interrupt an einen der Prozessoren der empfangenden Partition. Der Prozessor der empfangenden Partition reagiert auf den Interrupt, indem er ein Interrupt-Dienstprogramm (nicht dargestellt) der Core Services-Software auf dieser Partition aufruft. Da jede Partition nur einen einzigen Interrupt-Vektor für den Empfang von Interrupts von den anderen Partitionen reserviert, weiß die Core Services-Software auf der empfangenden Partition nicht, welche andere Partition den Inter-Prozessor-Interrupt ausgegeben hat. Folglich muss die Core Services-Software auf der empfangenden Partition das Zählfeld 3012 in jeder ihrer Eingabe-Warteschlangen überprüfen, um festzustellen, ob in einer dieser Warteschlangen Signale anstehen.
Wenn in einer Eingabe-Warteschlange Signale anstehen, überträgt die Core Services-Software diese Signale an einen lokalen Verarbeitungspuffer im exklusiven Speicherfenster der empfangenden Partition und setzt das Zählfeld 3012 in der Eingabe-Warteschlange zurück. Wenn das Überlauf-Flag 3014 einer bestimmten Eingabe-Warteschlange ebenfalls gesetzt war, setzt die Core Services-Software das Überlauf-Flag zurück und sendet ein "Senden wieder aufnehmen"-Signal zurück an die sendende Partition, wie oben erläutert. Die Core Services-Software durchsucht dann den lokalen Verarbeitungspuffer, extrahiert jedes empfangene Signal, bestimmt den Zielclient anhand der Client-Gruppen-ID im Signal und liefert dann das Signal an den Zielclient über die "Signal empfangen"-Call-back-Schnittstelle des Clients. Die Core Services wiederholen dann diese Schritte für jede andere Eingabe-Warteschlange, bei der ebenfalls Signale anstehen (d. h. Zählung > 0).
a. Exemplarische Intel/Windows NT-Implementierung
Auf der Prozessor- und der Betriebssystem-Ebene sind Inter-Prozessor-Unterbrechungsmechanismen sowohl Prozessor- als auch Betriebssystem-abhängig. Exemplarisch ist das Folgende eine Beschreibung, wie Inter-Prozessor-Interrupts gemäß der vorliegenden Ausführungsform im Falle von Partitionen, die Mikroprozessoren der Intel Pentium-Familie verwenden und auf denen das Microsoft Windows NT-Betriebssystem ausgeführt wird, erzeugt und bearbeitet werden.
Gemäß der vorliegenden Ausführungsform wird der Hardware-Abstraction-Layer (HAL) des Microsoft Windows NT-Betriebssystems modifiziert, so dass während der Initialisierung des HAL auf einer bestimmten Partition dieser zunächst einen Inter-Prozessor-Interrupt-Vektor für den Empfang von Inter-Prozessor-Interrupts des gemeinsam genutzten Speicherbereichs durch diese Partition auswählt. Ein Interrupt-Vektor ist eine Zahl, die vom HAL des Windows NT-Betriebssystems einem eingehenden Interrupt-Hardwaresignal zugewiesen wird. Zum Beispiel werden Interrupt-Vektoren vom HAL typischerweise den verschiedenen Geräte-E/A-Hardware-Interrupt-Signalen auf einem System zugewiesen. Ein Inter-Prozessor-Interrupt ist eine spezialisierte Art von Hardware-Interrupt-Signal, das von einem Prozessor an einen anderen (und nicht von einer E/A-Vorrichtung an einen Prozessor) gesendet wird. Wie bei allgemeinen E/A-Interrupts muss der HAL auch Inter-Prozessor-Interrupt-Signalen Vektoren zuweisen (aus dem Raum mit derselben Nummer, aus dem auch die E/A-Interrupt-Vektoren gewählt werden). So weist in der vorliegenden Ausführungsform der modifizierte HAL den Inter-Prozessor-Interrupts, die von der lokalen Core Services-Software auf dieser Partition empfangen werden, einen Interrupt-Vektor zu, um die Software zu informieren, dass ein oder mehrere Signale in mindestens einer ihrer Eingabe-Warteschlangen anstehen.
Im Falle eines Intel-Mikroprozessors werden Inter-Prozessor-Interrupts eigentlich von einem Advanced Programmed Interrupt Controller (APIC) erzeugt und empfangen, der mit dem Prozessor verbunden ist. Der mit dem sendenden Prozessor verbundene APIC erzeugt ein Hardware-Signal an den APIC, der mit dem empfangenden Prozessor verbunden ist. Wenn mehrere Prozessoren den Interrupt empfangen sollen, erzeugt der APIC des sendenden Prozessors ein Hardware-Signal an den APIC jedes designierten Empfängers. Der APIC jedes empfangenden Prozessors empfängt das Hardware-Signal und liefert den entsprechenden Interrupt-Vektor zur Bearbeitung an den Prozessor.
Weiter bestimmt der modifizierte HAL gemäß der vorliegenden Ausführungsform nicht nur einen Interrupt-Vektor für den Empfang von Inter-Prozessor-Interrupts von anderen Partitionen, sondern er ernennt auch einen oder mehrere Prozessoren in seiner Partition, die solche Interrupts bearbeiten. In der vorliegenden Ausführungsform müssen die designierten Prozessoren, im Falle einer Partition, die mehrere Sub-Pods umfasst, Mitglieder eines Einzigen dieser Sub-Pods sein (dies ist eine Einschränkung, die durch die vorliegende Ausführungsform der Computersystem-Plattform auferlegt wird und in anderen Ausführungsformen möglicherweise nicht besteht). Wenn mehrere Prozessoren auf einem Sub-Pod designiert wurden, wird eine eingehende Unterbrechung in den lokalen APICs jedes dieser Prozessoren empfangen. Die APICs arbitrieren dann, um zu bestimmen, welcher der Prozessoren die Unterbrechung bearbeitet. Weitere Details bezüglich dieser Arbitrierung sind im Pentium Pro Family Developer's Guide: Band 3, erhältlich bei der Intel Corporation, zu finden. Weitere Informationen zu APICs sind in der Intel Multi-Processor Specification, Version 1.4, ebenfalls erhältlich bei Intel, zu finden.
Weiter fragt gemäß der vorliegenden Ausführungsform die Core Services-Software, wenn sie auf einer Partition initialisiert wird, den HAL des NT-Betriebssystems auf dieser Partition durch eine kundenspezifische Schnittstelle ab, um den Interrupt-Vektor und die Informationen bezüglich der Prozessoren zu erhalten, die vom HAL dazu bestimmt wurden, Inter-Prozessor-Interrupts des gemeinsam genutzten Speichers, die in dieser Partition eingehen, zu bearbeiten. Die Core Services-Software speichert dann diese Informationen im Partitions-Informationsabschnitt des Kontrollstruktur-Headers 1910 (s. 20). Dies macht die Informationen für die Core Services-Software auf anderen Partitionen zugänglich. Die Core Services-Software liefert dann dem HAL über eine andere Schnittstelle eine Referenz auf ein Interrupt-Dienstprogramm, das Teil der Core Services-Software ist. Wenn ein designierter Prozessor auf dieser Partition einen Inter-Prozessor-Interrupt mit dem designierten Interrupt-Vektor empfängt, führt er das Interrupt-Dienstprogramm aus und ermöglicht es so der Core Services-Software, auf den Interrupt zu antworten.
Während des Betriebs liest die Core Services-Software auf der sendenden Partition zur Erzeugung eines Inter-Prozessor-Interrupts, um eine empfangende Partition zu informieren, dass ein Signal in eine ihrer Eingabe-Warteschlangen platziert wurde, die Inter-Prozessor-Interrupt-Informationen der designierten Empfängerpartition im Kontrollstruktur-Header 1910. Die Core Services-Software ruft dann eine andere kundenspezifische Schnittstelle zum HAL auf ihrer Partition auf und beliefert so den HAL mit der Inter-Prozessor-Interrupt-Information für die empfangende Partition. Mit dieser Information veranlasst der HAL auf der sendenden Partition die Register im APIC eines ihrer Prozessoren, die Erzeugung eines Inter-Prozessor-Interrupt-Signals von seinem APIC an die APICs jedes Prozessors herbeizuführen, der vom HAL auf der empfangenden Partition designiert wurde, solche Inter-Prozessor-Interrupts zu empfangen. Diese APICs auf der empfangenden Partition werden dann arbitrieren, um den Interrupt zu bearbeiten, und der Prozessor, der die Arbitration gewinnt, ruft das Interrupt-Dienstprogramm der Core Services-Software auf der empfangenden Partition auf.
b. Alternative Ausführungsform – mehrere Interrupt-Vektoren
In der oben beschriebenen Ausführungsform wird jeder Partition ein einziger Interrupt-Vektor für den Empfang von Inter-Prozessor-Interrupts des gemeinsam genutzten Speicherbereichs von jeder der anderen Partitionen zugewiesen. Eine empfangende Partition weiß deshalb nicht, welche andere Partition den empfangenen Interrupt erzeugt hat. Folglich muss die empfangende Partition alle ihre Eingabe-Warteschlangen nacheinander durchsuchen, um sicherzustellen, dass sie das/die Signal(e) von der sendenden Partition empfängt, welche den Interrupt erzeugt hat. Als alternative Ausführungsform kann jede Partition einen eigenen Interrupt-Vektor für den Empfang von Inter-Prozessor-Interrupts des gemeinsam genutzten Speicherbereichs von jeder anderen Partition designieren. Eine sendende Partition würde dann mit Hilfe des jeweiligen Interrupt-Vektors, der ihr von einer empfangenden Partition zugewiesen wird, einen Inter-Prozessor-Interrupt an die empfangende Partition erzeugen. Ein Vorteil dieser Ausführungsform besteht darin, dass eine empfangende Partition anhand des Interrupt-Vektors erkennen würde, welche andere Partition den eingehenden Interrupt erzeugt hat. Die Core Services-Software auf der empfangenden Partition könnte dann auf die entsprechende Eingabe-Warteschlange zugreifen, um das/die eingehende(n) Signal(e) abzurufen, ohne alle Eingabe-Warteschlangen durchsuchen zu müssen wie in der oben beschriebenen Ausführungsform.
10. Die Core Services-API (Kern-Dienste API)
Um Clients der Core Services-Software die oben beschriebene Funktionalität zu verleihen, hat die Core Services-Software eine definierte Anwendungsprogrammierschnittstelle (application programming interface, API), die Schnittstellen (d. h. aufrufbare Methoden) bereitstellt, die ein Client aufrufen kann, um die Dienste der Core Services-Software aufzurufen. Im Folgenden ist eine Liste von Schnittstellen zu finden, die als Teil der Core Services-API bereitgestellt werden, um die oben beschriebenen Funktionen auszuführen:
Client-Software initialisieren – Diese Schnittstelle wird von einem Client genutzt, um sich der Core Services-Software zu erkennen zu geben. Die Core Services-Software liefert dem Client eine Client-Referenz-Kennung zurück.
Initialisierung der Client-Software rückgängig machen – Diese Schnittstelle wird von einem Client genutzt, um die Core Services-Software zu informieren, dass er den gemeinsam genutzten Speicherbereich nicht mehr nutzen wird.
Client registrieren – Diese Schnittstelle wird von einem Client genutzt, um sich bei der Core Services-Software als Mitglied einer bestimmten Client-Gruppe zu registrieren. Jeder Client muss sich registrieren, bevor er anfordern darf, dass ihm gemeinsamer Speicherbereich zugewiesen wird. Der Client liefert den gewünschten Client-Gruppen-Namen und seine Client-Referenz-Kennung als Teil des Aufrufs. Die Core Services-Software nimmt. dann die entsprechenden Änderungen in der Client-Verzeichnis-Tabelle vor, um anzugeben, dass dieser Client der gewünschten Client-Gruppe hinzugefügt wurde. Die Schnittstelle liefert diese Client-Gruppen-ID dann an den Client zurück.
Registrierung des Clients rückgängig machen – Diese Schnittstelle wird von einem Client genutzt, um sich von einer bestimmten Client-Gruppe abzumelden.
Gemeinsamen Speicherbereich zuweisen – Diese Schnittstelle wird von einem Client verwendet, um die Zuweisung einer oder mehrerer Seiten des gemeinsamen Speicherfensters anzufordern. Der Client liefert seine Client-Gruppen-ID und die Puffergröße (in Byte), die er anfordert. Die Core Services-Software sperrt die Zuordnungstabelle, ermittelt, ob genügend Seiten in der Liste freier Seiten verfügbar sind, um die Anforderung zu erfüllen, und entfernt dann diese Seiten aus der Liste freier Seiten. Die Einträge für jede zugewiesene Seite in der Zuordnungstabelle werden aktualisiert, um anzuzeigen, dass die Seiten "in Gebrauch" sind. Für Seiten des Typs 1 und Typs 2 wird ein Core Services-Header in der Seite erstellt, der, wie oben erläutert, die Inhaberschaft von Partition und Client an der Seite anzeigt. Seiten des Typs 3, die mit einer Seite des Typs 2 verknüpft sind, werden im Header der Seite des Typs 2 referenziert. Bei Seiten des Typs 4 wird die Partitions-Inhaberschaft in den entsprechenden Einträgen in der Zuordnungstabelle reflektiert. Die Core Services-Software liefert dem Client dann eine Kennung zurück, die dieser anschließend verwendet, um auf die Seiten zu verweisen, die den zugewiesenen Puffer umfassen.
Zuweisung gemeinsamen Speicherbereichs rückgängig machen-Diese Schnittstelle wird von einem Client genutzt, um anzufordern, dass die Zuordnung aller Seiten, die mit einer bestimmten Kennung verknüpft sind, rückgängig gemacht wird. Falls die anfordernde Partition der einzige Eigentümer der Seiten ist, deren Zuordnung rückgängig gemacht werden soll, werden die Seiten an die Liste freier Seiten zurückgeliefert (hierzu muss der systemweite Schlüssel erworben werden). Anderenfalls wird nur die Eigentumsinformation (bei Seiten des Typs 1 und Typs 2 im Core Services-Header, bei Seiten des Typs 4 in den Einträgen der Zuordnungstabelle) aktualisiert.
Signal senden – Dies ist die Schnittstelle, die Clients nutzen, um ein Signal in die Eingabe-Warteschlange einer empfangenden Partition stellen zu lassen. Der Client, der diese Schnittstelle aufruft, liefert (i) die Client-Gruppen-ID der Client-Gruppe, von der er und der/die empfangende(n) Client(s) Mitglieder sind, (ii) eine Angabe, welche Partitionen einen Client haben, der das Signal empfangen wird (da nur ein Client auf einer bestimmten Partition Mitglied einer bestimmten Client-Gruppe sein kann, sind diese Angabe und die Client-Gruppen-ID die einzigen Informationen, die zur Identifizierung des empfangenden Clients auf jeder Partition benötigt werden), (iii) die eigentlichen Informationen, die mit dem Signal im Client-Informationsabschnitt mitgeliefert werden sollen, (iv) ein Flag, das angibt, ob dies ein Punkt-zu-Punkt- oder Multicast-Signal ist (Punkt-zu-Punkt hat nur eine empfangende Partition, während Multicast mehrere empfangende Partitionen hat), und (v) eine optionale Kennung für ein Objekt des gemeinsamen Speicherbereichs, wie z. B. einen Puffer (eine oder mehrere gemeinsame Speicherseiten), das eine Client-Nachricht enthält. Als Reaktion auf einen "Signal senden"-Aufruf wird die Core Services-Software folgende Schritte durchführen: (i) Erstellung der Core Services-Informations- und Client-Informationsabschnitte des Signals, (ii) Überprüfung des Status des gemeinsamen Speicherbereichs, (iii) Platzieren des Signals in die entsprechende Eingabe-Warteschlange und, falls das Signal in eine leere Eingabe-Warteschlange gestellt wurde, (iv) Erzeugung eines Inter-Prozessor-Interrupts auf der empfangenden Partition. Wenn eine Eingabe-Warteschlange einer designierten Empfängerpartition voll ist oder wenn die designierte Empfängerpartition betriebsunfähig ist, werden entsprechende Fehlermeldungen zurückgeliefert.
11. Von Clients gestellte Schnittstellen
Zusätzlich zu den oben erwähnten Schnittstellen, die von der Core Services-Software gestellt werden, muss jeder Client der Core Services-Software bestimmte Call-back-Schnittstellen implementieren, die die Core Services-Software aufrufen kann, um die Clients über bestimmte Ereignisse zu informieren. In der vorliegenden Ausführungsform schließen diese Call-back-Schnittstellen Schnittstellen für folgende Aufgaben ein: (i) Benachrichtigung des Clients, dass ein Signal empfangen wurde ("die Signal-empfangen-Schnittstelle"), (ii) Benachrichtigung des Clients, dass eine Änderung der Mitgliedschaft in seiner Client-Gruppe stattgefunden hat, (iii) Benachrichtigung des Clients, dass der gemeinsame Speicherbereich in Betrieb oder außer Betrieb ist, (iv) Benachrichtigung des Clients, dass die Core Services-Software abgeschaltet wird, und (v) Benachrichtigung des Clients, dass eine oder mehrere gemeinsame Speicherseiten einen Speicherfehler hat/haben.
12. Exemplarische Arbeitsweise
Zur weiteren Verdeutlichung der Arbeitsweise des Interruptgesteuerten gemeinsamen Speichermechanismus, der oben beschrieben ist, umfassen die 31A und 31B ein Flussdiagramm, das die Schritte darstellt, welche von den Clients und der Core Services-Software auf zwei Partitionen durchgeführt werden, um eine Nachricht von einem Client an den anderen zu leiten.
31A stellt die Schritte dar, die auf der sendenden Partition ausgeführt werden. In Schritt 3110 ruft der Client die "Gemeinsamen Speicherbereich zuweisen"-Schnittstelle der Core Services-API auf und fordert einen Puffer an, der verwendet wird, um die Nachricht an den Client auf der empfangenden Partition zu übertragen. In diesem Beispiel fordert der Client die Zuweisung einer Seite des Typs 2 an. Der Client gibt mit der Anforderung die erforderliche Puffergröße an. In der Antwort, in Schritt 3112, ermittelt die Core Services-Software die Anzahl gemeinsamer Speicherseiten, die notwendig ist, um die Pufferanforderung zu erfüllen (d. h., ob zusätzliche Seiten des Typs 3 mit der Seite des Typs 2 zugewiesen werden). In Schritt 3114 (i) erwirbt die Core Services-Software den systemweiten Zuweisungsriegel, (ii) ermittelt sie aus der Liste freier Seiten, ob die erforderliche Anzahl von Seiten verfügbar ist, und wenn sie es sind, (iii) weist sie die Seiten dem Client zu. Die Core Services-Software aktualisiert die Zuordnungstabelle, um anzuzeigen, dass die Seiten "in Gebrauch" sind, und gibt dann die Inhaberschaft an den Seiten im Core Services-Header der Seite vom Typ 2 an. In Schritt 3116 liefert die Core Services-Software dem Client eine Kennung für die zugewiesenen Seiten zurück und gibt den Zuweisungsriegel frei.
Als Nächstes, in Schritt 3118, füllt der Client den zugewiesenen Puffer mit den Nachrichtendaten. Dann, in Schritt 3120, ruft der Client die "Signal senden"-Schnittstelle der Core Services API auf und gibt folgende Informationen an: (i) die Client-Gruppen-ID und die empfangende Partition (die gemeinsam den empfangenden Client angeben), (ii) alle Informationen, die im Client-Informationsabschnitt des Signals bereitgestellt werden sollen, (iii) die Kennung des zugewiesenen Puffers und (iv) ein Flag, das angibt, dass dies eine Punkt-zu-Punkt-Anforderung und keine Multicast-Anforderung ist. Es wird daran erinnert, dass der Client die Möglichkeit hat, ein Signal mit der Multicast-Funktion der vorliegenden Erfindung an mehrere Partitionen zu senden.
Als Reaktion auf die Anforderung "Signal senden" identifiziert in Schritt 3122 die Core Services-Software die entsprechende Eingabe-Warteschlange anhand der designierten empfangenden Partition. Die Core Services-Software sperrt dann die Eingabe-Warteschlange (Schritt 3124), inkrementiert das Zählfeld (Schritt 3126) und erstellt das Signal in der Eingabe-Warteschlange (Schritt 3128) als Eintrag in diese Warteschlange. Als Nächstes erzeugt die Core Services-Software, wenn die Eingabe-Warteschlange zuvor leer war (d. h. die Zählung von Null auf Eins gesprungen ist) (Schritt 3130), einen Inter-Prozessor-Interrupt auf der empfangenden Partition (Schritt 3123). Wenn das Zählfeld der Eingabe-Warteschlange bereits nicht Null war, muss die Core Services-Software keinen Interrupt erzeugen. Sie gibt dann den Schlüssel für die Eingabe-Warteschlange frei (Schritt 3131 oder Schritt 3133).
In 31B sind die Schritte dargestellt, die auf der empfangenden Partition ausgeführt werden. In Schritt 3134 arbitriert einer der APICs auf dem vordefinierten Sub-Pod dieser Partition um den Inter-Prozessor-Interrupt, der von der sendenden Partition erzeugt wurde, und liefert diesen an seinen Prozessor. Als Reaktion ruft der Prozessor ein Interrupt-Dienstprogramm (nicht dargestellt) der Core Services-Software auf. Als Teil des Interrupt-Dienstprogramms beginnt die Core Services-Software in Schritt 3136 die erste ihrer Eingabe-Warteschlangen zu durchsuchen (in der vorliegenden Ausführungsform gibt es acht Eingabe-Warteschlangen für jede Partition). In Schritt 3138 untersucht die Core Services-Software das Zählfeld der Eingabe-Warteschlange. Wenn die Zählung Null ist, sind keine Signale von der sendenden Partition gesendet worden, die dieser Eingabe-Warteschlange entspricht, und die Core Services-Software schreitet weiter zur nächsten Eingabe-Warteschlange.
Wenn jedoch die Zählung einer bestimmten Eingabe-Warteschlange höher ist als Null, stehen Signale an, und die Steuerung geht zu Schritt 3140. In Schritt 3140 kopiert die Core Services-Software jedes Signal in der Eingabe-Warteschlange in einen lokalen Verarbeitungspuffer und setzt in Schritt 3142 die Zählung zurück auf Null. Als Nächstes stellt in Schritt 3143 die Core Services-Software fest, ob das Überlauf-Flag in der Eingabe-Warteschlange gesetzt ist. Ist dies der Fall, so setzt die Core Services-Software das Überlauf-Flag zurück und sendet dann ein "Senden wieder aufnehmen"-Signal an die sendende Partitiön, um diese zu benachrichtigen, dass die Eingabe-Warteschlange nicht mehr voll ist.
Als Nächstes werden die Schritte 3144 und 3146 für jedes Signal durchgeführt, das in den lokalen Verarbeitungspuffer kopiert wurde. Im Speziellen extrahiert in Schritt 3144 die Core Services-Software ein Signal aus dem lokalen Verarbeitungspuffer. Im Schritt 3146 ruft die Core Services-Software die "Signal empfangen"-Schnittstelle des Empfänger-Clients (wie durch die Client-Gruppen-ID im Signal gekennzeichnet) auf und gibt den Client-Informationsabschnitt und die Kennung an den zugewiesenen Puffer (falls vorhanden), der zu dem Signal gehört. In Schritt 3148 verarbeitet der Client das Signal, einschließlich z. B. der Verwendung der Kennung, um auf Nachrichtendaten im referenzierten Puffer zuzugreifen. Die Schritte 3144 und 3146 werden für jedes Signal im lokalen Verarbeitungspuffer wiederholt. Danach wiederholt die Core Services-Software die Schritte 3136 bis 3146 für jede ihrer anderen Eingabe-Warteschlangen. Obwohl nicht in 31B dargestellt, fährt in der vorliegenden Ausführungsform die Core Services-Software auf der empfangenden Partition fort, ihre Eingabe-Warteschlangen zu durchsuchen, bis sie alle Eingabe-Warteschlangen vollständig durchsucht hat, ohne anstehende Signale (d. h. mit einer Zählung > 0) zu finden. Die Verarbeitung der Eingabe-Warteschlange wird dann angehalten, bis ein neuer Inter-Prozessor-Interrupt empfangen wird.
Ein zusätzlicher Aspekt (nicht dargestellt) der Sende- und Empfangsprozesse ist das Rückgängigmachen der Zuordnung der zugeordneten gemeinsamen Speicherseiten. Wenn ein sendender Client, der die Zuweisung eines Puffers (d. h. einer oder mehrerer gemeinsamer Speicherseiten) angefordert hat, den Puffer an eine empfangende Partition überträgt, indem er seine Kennung durch ein Signal an die empfangende Partition überträgt, hat die sendende Partition die Möglichkeit, entweder (i) Eigentumsrechte auf die Seiten des Puffers auf den empfangenden Client zu erweitern (in diesem Fall haben beide Clients Eigentumsrechte) oder (ii) Eigentumsrechte auf die empfangende Partition zu übertragen (in diesem Fall gibt der sendende Client die Inhaberschaft auf). Unabhängig davon, welche Option gewählt wird, möchte ein Client möglicherweise zu irgendeinem Zeitpunkt die Zuweisung der zugewiesenen Seiten rückgängig machen. Dies wird mit Hilfe der Schnittstelle "Zuweisung gemeinsamen Speicherbereichs rückgängig machen" durchgeführt. Speziell ruft ein Client die Schnittstelle "Zuweisung gemeinsamen Speicherbereichs rückgängig machen" auf und überträgt die Kennung für die Seiten, deren Zuweisung rückgängig gemacht werden soll. Wenn keine anderen Clients Eigentümer dieser Seiten sind, werden die Seiten an die Liste freier Seiten zurückgegeben, und ihre entsprechenden Einträge in der Zuordnungstabelle werden aktualisiert, um ihre Verfügbarkeit anzuzeigen. Wenn jedoch andere Clients auch Eigentumsrechte an diesen Seiten haben, können die Seiten noch nicht an die Liste freier Seiten zurückgegeben werden. Stattdessen sperrt die Core Services-Software die Seiten und aktualisiert die Eigentumsinformationen im Core Services-Header der Seite vom Typ 2.
13. Weitere Funktionen
Zusätzlich zu oben Ausgeführtem werden die folgenden zusätzlichen Funktionen des Interrupt-gesteuerten Verwaltungsmechanismus für den gemeinsamen Speicherbereich bereitgestellt:
a. Initialisierung und Abschaltung
Wenn die Ausführung der Core Services-Software auf einer Partition beginnt, bestätigt sie zunächst die Verfügbarkeit und den Status des gemeinsamen Speicherfensters und ruft dann passende Plattform-Schnittstellen auf, um die folgenden Informationen zu erhalten: die physikalische Adresse und Größe des gemeinsamen Speicherfensters, die Partitionskennung (jede Partition hat eine dazugehörige Kennung), die Information, die von anderen Partitionen benötigt wird, um Inter-Prozessor-Interrupts auf dieser Partition zu erzeugen, und die Art und Version des Host-Betriebssystems, das auf der Partition ausgeführt wird. Die Core Services-Software speichert eine Kopie dieser Informationen im exklusiven Speicherfenster ihrer Partition und in den verschiedenen Feldern der Kontrollstruktur 1900 des gemeinsamen Speicherbereichs, wie z. B. dem Partitionsinformations-Feld des Kontrollstruktur-Headers 1910 und dem Feld "Länge des gemeinsamen Speicherbereichs" der Zuordnungsstruktur 1912.
Damit eine Partition gemeinsam mit anderen Partitionen auf das gemeinsame Speicherfenster zugreifen und es nutzen kann, muss sich die Partition mit Hilfe des gemeinsamen Speicherfensters den anderen Partitionen zu erkennen geben. Wenn es zurzeit keine Master-Partition gibt, müssen sie unter sich arbitrieren, um eine zu wählen. Zu diesem Zweck hat Core Services einen Anmeldemechanismus. Der Anmeldemechanismus ermöglicht es jeder Partition, die Gültigkeit des Feldes" Status des gemeinsamen Speicherbereichs" im Kontrollstruktur-Header zu bestimmen, ohne einen Schlüssel zu benutzen, und dynamisch einen neuen Master zu wählen, wenn kein aktiver Master vorhanden ist.
Die Core Services-Software ist auch dafür verantwortlich, dass das gemeinsame Speicherfenster immer dann ordnungsgemäß verlassen wird, wenn eine Partition es freiwillig verlässt. Dies gilt sowohl für die Master-Partition als auch für die Nicht-Master-Partitionen. Die allgemeinen Aufgaben jeder sich abmeldenden Partition sind: (i) ihre lokalen Clients zu informieren, dass sie das gemeinsame Speicherfenster verlässt, indem sie die entsprechende Client-Callback-Schnittstelle aufruft, (ii) alle Datenstrukturen freizugeben, die sie gesperrt hatte (z. B. Zuordnungstabelle, Eingabe-Warteschlange usw.), (iii) ihre Eingabe-Warteschlangen zu bereinigen, (iv) die Zuweisung aller gemeinsamen Speicherseiten, an denen sie Eigentumsrecht hat, rückgängig zu machen, (v) lokalen Speicher, an denen sie Eigentumsrecht hat, zurückzugeben, und (vi) ihren Status im Kontrollstruktur-Header 1910 in "nicht initialisiert" umzuändern.
Wenn die sich abmeldende Partition die Master-Partition ist und es keine anderen aktiven Partitionen gibt, schließt sie das gemeinsame Speicherfenster und sendet eine Nachricht an den MIP. Wenn die sich abmeldende Partition die Master-Partition ist und mindestens eine weitere Partition noch mit dem gemeinsamen Speicherfenster kommuniziert, wird von den restlichen aktiven Partitionen eine neue Master-Partition gewählt.
b. Pflichten der Master-Partition
Die Master-Partition hat bestimmte Aufgaben, wenn der gemeinsame Speicherbereich initialisiert wird, wenn eine Nicht-Master-Partition geschlossen wird und wenn der gemeinsame Speicherbereich geschlossen wird. Die folgenden Pflichten sind für die Master-Partition reserviert:

(1) Initialisierung gemeinsamer Speicherstrukturen, einschließlich des Kontrollstruktur-Headers, der Zuordnungsstruktur, der Zuordnungstabelle, der Liste freier Seiten, des Eingabe- Warteschlangen-Headers, der Eingabe-Warteschlangen, des Client-Verzeichnis-Tabellen-Headers und der Client-Verzeichnis-Tabelle
(2) Durchführung von Aufräumabläufen bei gemeinsamen Speicherstrukturen und gemeinsam genutzten Speicherseiten, wenn eine Partition stillgelegt wird, und
(3) Durchführung von Aufräumabläufen bei gemeinsamen Speicherstrukturen, wenn der gemeinsame Speicherbereich stillgelegt wird.

c. Pflichten von Nicht-Master-Partitionen
Alle Partitionen, einschließlich der Master-Partition, haben folgende Pflichten:

(1) Überprüfung des Status der anderen Partitionen im vordefinierten Überprüfungsintervall für Partitionen des gemeinsamen Speicherbereichs
(2) Bestimmung, ob eine neue Master-Partition gewählt werden muss;
(3) Aktualisierung der entsprechenden Bereiche in den gemeinsamen Speicherstrukturen und Rückgängigmachen der Zuweisung aller gemeinsamen Speicherseiten, an denen sie Eigentumsrecht haben, wenn sie sich entscheiden, das gemeinsame Speicherfenster zu verlassen, und
(4) Rückgängigmachen der Zuweisung aller gemeinsamen Speicherseiten, an denen ein Client Eigentumsrecht hat, wenn der Client seine Teilnahme am gemeinsamen Speicherfenster zurückzieht oder ausfällt.

Wie hierin beschrieben, wird der Programmcode, der den Interrupt-gesteuerten Kommunikationsmechanismus über den gemeinsamen Speicherbereich dieser alternativen Ausführungsform implementiert, als eine Kombination aus Betriebssystemcode (z. B. der Modifikation des HAL) und einem separaten Computerprogramm (z. B. der Core Services-Software) implementiert. Es versteht sich jedoch, dass in anderen Ausführungsformen der Programmcode entweder vollständig als Betriebssystemcode oder vollständig als separates Computerprogramm implementiert werden könnte, ohne vom Gedanken und Schutzumfang der vorliegenden Erfindung, wie durch die beigefügten Ansprüche definiert, abzuweichen. Weiterhin kann der Programmcode auch in fest verdrahteter Schaltung oder einer Kombination aus fest verdrahteter Schaltung und Softwarecode implementiert werden. Wie oben erwähnt, sollen mit dem Begriff "Programmcode" alle diese Möglichkeiten abgedeckt werden.
IV. Exemplarische Nutzungen des Computersystems und der Verfahren der vorliegenden Erfindung zur Erleichterung der Kommunikation zwischen Partitionen
Exemplarische Verwendungen des oben beschriebenen Computersystems, einschließlich seiner Funktionen zur Verwaltung des gemeinsamen Speicherbereichs, um die Kommunikation zwischen Betriebssystemen und/oder Anwendungen, die auf den Betriebssystemen ausgeführt werden, zu erleichtern, sind unten beschrieben. Exemplarische Ausführungsformen dieser Verwendungen sind unten zum Zwecke der Verdeutlichung und nicht der Einschränkung beschrieben. Alternative Ausführungsformen (einschließlich Äquivalenten, Erweiterungen, Variationen, Abweichungen usw. der hierin beschriebenen Ausführungsformen) auf der Grundlage der hierin enthaltenen Lehren werden für den Fachmann offensichtlich sein. Die Erfindung ist dazu bestimmt und ausgebildet, solche alternativen Ausführungsformen einzuschließen.
A. Ein Gerätetreiber des gemeinsamen Speicherbereichs
Ein Network Driver Interface Specification-(NDIS-)Gerätetreiber des gemeinsamen Speicherbereichs wie unten beschrieben kann implementiert werden, um es Standardanwendungen zu ermöglichen, auf dem oben beschriebenen Multi-Partitions-System zu arbeiten. Der NDIS-Gerätetreiber des gemeinsamen Speicherbereichs bietet Standard-Vernetzungs- und/oder Gruppierungs-Schnittstellen mit schnellerem Bandpass und geringerer Latenz als z. B. bei einer analogen LAN-Konfiguration. Dieser NDIS-Gerätetreiber des gemeinsamen Speicherbereichs basiert auf der Core Services-Software des Interrupt-gesteuerten Verwaltungsmechanismus des gemeinsamen Speicherbereichs, der oben in Abschnitt III.B beschrieben ist, und nutzt diese Software.
18 zeigt den exemplarischen NDIS-Gerätetreiber 1802 des gemeinsamen Speicherbereichs. Die nicht schattierten Kästchen stellen Standard-Windows NT-Komponenten dar. Die schattierten Kästchen stellen Komponenten dar, die als Teil der Erfindung implementiert werden können.
Der NDIS-Gerätetreiber 1802 des gemeinsamen Speicherbereichs unterstützt eine obere Schnittstelle und eine untere Schnittstelle. An der oberen Schnittstelle unterstützt der NDIS-Gerätetreiber 1802 des gemeinsamen Speicherbereichs den Standard-NDIS-Anschluss an Standard-Netzprotokoll-Treiber. Der NDIS-Gerätetreiber 1802 des gemeinsamen Speicherbereichs fungiert als mehrschichtiger NDIS-Treiber. Im Speziellen ist der NDIS-Gerätetreiber 1802 des gemeinsamen Speicherbereichs konform mit NDIS-Miniport-Schnittstellen und unterstützt jedes Netzprotokoll, das die NDIS-Schnittstellen nutzt, um über NDIS-Gerätetreiber zu kommunizieren. Es können z. B. TCP/IP- und SPX/IPX-Protokolle implementiert werden.
Die untere Schnittstelle für den NDIS-Gerätetreiber 1802 des gemeinsamen Speicherbereichs ist eine private Schnittstelle zur Core Services-Software, beschrieben in Abschnitt III.B., welche die globalen Funktionen des gemeinsamen Speicherbereichs direkt unterstützt. Die Schnittstelle schließt eine Mischung aus normalen mehrschichtigen E/A-Treiberschnittstellen (IRPs) und dicht gekoppelten E/A-Treiberschnittstellen (direkter Prozeduraufruf) ein. Die IRPs werden für asynchrone Funktionen verwendet. Die dicht gekoppelten E/A-Treiberschnittstellen werden für synchrone Funktionen verwendet.
Die Hauptfunktion des NDIS-Gerätetreibers 1802 des gemeinsamen Speicherbereichs besteht darin, die NDIS-Schnittstelle auf die Core Services-API abzubilden. Lokale Systempuffer, die Vernetzungspakete (NDIS-Pakete) enthalten, werden durch die NDIS-Schnittstelle an den Gerätetreiber 1802 des gemeinsamen Speicherbereichs NDIS geliefert. Der NDIS-Gerätetreiber 1802 des gemeinsamen Speicherbereichs kopiert das Netzwerkpaket aus dem lokalen Systempuffer (im exklusiven Speicherfenster einer Partition) in einen gemeinsamen Speicherpuffer. Ein Verweis auf den gemeinsamen Speicherpuffer wird in die Warteschlange des entsprechenden NDIS-Gerätetreibers des gemeinsamen Speicherbereichs in einer anderen Partition gestellt, wie er mit Hilfe der MAC-Zieladresse im Netzwerkpaket ausgewählt wurde. Pakete mit einer Broadcast- oder Multicast-MAC-Adresse werden in so viele gemeinsame Speicherpuffer wie nötig kopiert, um direkt an jede Partition zu senden, die einen Gerätetreiber in der gemeinsamen Speichergruppe des NDIS-Gerätetreibers 1802 des gemeinsamen Speicherbereichs unterstützt, wodurch ein Broadcast/Multicast simuliert wird. Puffer, die aus dem gemeinsamen Speicherbereich empfangen werden, werden erneut in NDIS-Pakete verpackt und der NDIS-Schnittstelle präsentiert, wo sie von Netzprotokoll-Treibern verarbeitet werden. Die NDIS-Pakete werden an den NDIS-Gerätetreiber 1802 des gemeinsamen Speicherbereichs zurückgeliefert.
Der NDIS-Gerätetreiber 1802 des gemeinsamen Speicherbereichs verwaltet für jede Partition eine Liste gemeinsamer Speicherpuffer, genannt SendList, um das Overhead der Zuweisung und des Rückgängigmachens der Zuweisung gemeinsamer Speicherpuffer über die Core Services-Software zu reduzieren. Gemeinsame Speicherpuffer werden aus der SendList ausgewählt, um Netzwerkpaket-Informationen an eine andere Partition zu senden. Die empfangende Partition hat eine RcvList von Kennungen, die der SendList der Ursprungs-Partition entspricht. Wenn die empfangende Partition die Nachrichtenverarbeitung abgeschlossen hat, sendet sie eine Nachricht, die anzeigt, dass der Puffer in der SendList wieder in den "Verfügbar"-Status versetzt werden sollte. Wenn die Anzahl der Puffer in der SendList unter einen Minimalwert fällt, werden zusätzliche Puffer von der Core Services-Software zugewiesen. Wenn die Anzahl der Puffer in der SendList ein Maximum erreicht hat und nicht alle in Gebrauch sind, werden Puffer wieder der Core Services-Software zugewiesen. Die Minimal- und Maximalgrößen der SendList haben vordefinierte Standardwerte im Code, die jedoch durch das Setzen bestimmter Schlüssel in einer Registrierung außer Kraft gesetzt werden können.
Der NDIS-Gerätetreiber 1802 des gemeinsamen Speicherbereichs nutzt die Core Services-Software auf seiner Partition 1804, um ein FDDI LAN zwischen allen Partitionen zu simulieren, auf denen Kopien des NDIS-Gerätetreibers 1802 des gemeinsamen Speicherbereichs ausgeführt werden. Der NDIS-Gerätetreiber 1802 des gemeinsamen Speicherbereichs unterstützt die grundlegende Semantik eines FDDI LAN. Dies schließt Punkt-zu-Punkt-Kommunikation, Broadcast-Kommunikation, Multicast-Kommunikation und Nachrichtengrößen von 4491 Byte ein.
B. Aufrechterhaltung eines Anscheins von Kommunikation per Kabel
In einer anderen exemplarischen Anwendung des Computersystems und seiner globalen Verwaltung des gemeinsamen Speicherbereichs wird die gemeinsame Nutzung von Speicher durch Partitionen (d. h. Pods, Sub-Pods oder Betriebssystemen) erzielt, während der Anschein von Kommunikation per Kabel aufrechterhalten wird. Dies ermöglicht die Verwendung von herkömmlichen Anwendungsprogrammen, herkömmlichen Anwendungsprogrammierschnittstellen (APIs) und herkömmlicher Kommunikations-Hardware und -Software, um Daten an den gemeinsamen Speicherbereich zu senden. Diese Anwendung beruht auf dem Mechanismus, der oben in Abschnitt III.A. beschrieben ist und in dem die Kommunikation zwischen Partitionen gemäß einer Abfragetechnik verwaltet wird.
22 ist eine exemplarische Konfiguration des Computersystems 200 der vorliegenden Erfindung, einschließlich zusätzlicher Software-Komponenten, die benötigt werden, um den Anschein einer Kommunikation über Kabel zwischen Partitionen oder Betriebssystemen zu erwecken. In 22 sind zwei Partitionen 2202a und 2202n dargestellt, von denen jede z. B. einen einzelnen Sub-Pod einschließen kann. Jeder Sub-Pod 2202 arbeitet unter der Kontrolle eines separaten Betriebssystems 2206. Die Betriebssysteme 2206 können separate Instanzen desselben Betriebssystems sein, oder sie können verschiedene Betriebssysteme sein. Ein oder mehrere Anwendungsprogramme 2208 können auf jeder Partition 2202 auf dem Betriebssystem 2206 ausgeführt werden, das auf jeder Partition arbeitet.
Ein oder mehrere Anwendungsprogrammierschnittstellen- (API-)Module 2210 können zum Senden von Nachrichten mit einem oder mehreren Anwendungsprogrammen 2208 verbunden sein. Zum Beispiel kann auf dem Sub-Pod 2202a das Anwendungsprogramm 2208a mit Hilfe der API 2208a einen Nachrichten-Sendevorgang initiieren. Die API 2208a bereitet die Nachricht zur Eingabe in ein Netzkommunikationsschnittstellen-Modul 2212 vor.
Das Netzkommunikationsschnittstellen-Modul 2212 kann ein herkömmliches System sein, das Partitionen z. B. durch ein Netzwerk miteinander verbindet. Das Netzkommunikationsschnittstellen-Modul 2212 formatiert Nachrichten zur Übertragung an andere Partitionen 2202 durch einen Netztreiber 2216 und über ein herkömmliches Netzkabel 2214. In einer exemplarischen Ausführungsform gibt das Netzkommunikationsschnittstellen-Modul 2212 Nachrichten auf den Leitungen 2220a und 2220b aus, als ob sie für ein herkömmliches Übertragungssystem 2214 mit Netzkabel bestimmt wären. So wird bis zu diesem Punkt das Senden von Nachrichten von den Partitionen 2202a auf herkömmliche Art und Weise durchgeführt.
Anstatt dass alle Nachrichten auf den Leitungen 2220a und 2220b vom Netzkommunikationsschnittstellen-Modul 2212 an einen herkömmlichen Netztreiber 2216 gesendet werden, werden Nachrichten, die für den gemeinsamen Speicherbereich 160 bestimmt sind, durch einen Treiber 2218 für den gemeinsamen Speicherbereich bearbeitet. In einer exemplarischen Ausführungsform ist mit jeder Nachricht eine Zieladresse verknüpft. Wenn eine Adresse einem Computer oder einem anderen Ziel entspricht, das mit dem Kabel 2214 verbunden ist, dann wird die Nachricht durch den Netztreiber 2216 an das Kabel 2214 geschickt. Wenn jedoch die Adresse einer Adresse im gemeinsamen Speicherbereich 160 entspricht, wird die Nachricht an den Treiber 2218 für den gemeinsamen Speicherbereich geleitet.
Der Treiber 2218 für den gemeinsamen Speicherbereich empfängt Nachrichten und formatiert sie um zur Übertragung an den und Speicherung im gemeinsamen Speicherbereich 160. Die Umformatierung kann z. B. die Umformatierung von Nachrichten in ein Standardformat einschließen, das von Anwendungsprogrammen 2208 erkannt werden kann, welche auf anderen Partitionen 2202 ausgeführt werden. Die Umformatierung kann auch z. B. die Umformatierung gemäß Spezifikationen im Zusammenhang mit dem gemeinsamen Speicherbereich 160 einschließen.
In 23 sind weitere Details des Systems 2200 dargestellt. In dieser exemplarischen Ausführungsform ist das Betriebssystem 2206a auf Partition 2202a als ein 2200-Betriebssystem dargestellt, das kommerziell bei der Unisys Corporation erhältlich ist, und das Betriebssystem 2206n auf der Partition 2202n ist als ein Windows NT- oder ein UNIX-Betriebssystem dargestellt.
In der exemplarischen Ausführungsform in 23 schließen die Netzkommunikationsschnittstellen-Module 2212 ein oder mehrere Software-Module 2310 ein, die eine herkömmliche Transportschicht (d. h. Schicht 4) eines siebenschichtigen OSI-Kommunikationsmodells (OSI: Open Systems Interconnection, offenes Kommunikationssystem) implementieren. Das siebenschichtige OSI-Kommunikationsmodell ist dem Fachmann gut bekannt. Die Transportschicht kann mit einer Reihe verschiedener Protokolle, einschließlich eines Transmission Control Protocol (TCP) und eines User Datagram Protocol (UDP), implementiert werden. Das ausgewählte Protokoll bestimmt die Zuverlässigkeit des anschließenden Kommunikationsvorgangs und das Potential zur Vervielfältigung während dieses Vorgangs. In einer exemplarischen Ausführungsform kann TCP verwendet werden, um für zuverlässige, nicht redundante Datenübertragung zu sorgen.
Das Software-Modul, das die Transportschicht implementiert 2310, ist mit einem Software-Modul verbunden, welches eine Vermittlungsschicht, d. h. Schicht 3 des siebenschichtigen OSI-Protokolls, implementiert 2312. Dies kann z. B. mit Hilfe des in der Industrie anerkannten Internet-Protokolls (IP) und des Internet Control Message-Protokolls (ICMP) durchgeführt werden. IP bestimmt das Protokoll, das zur Datenübertragung verwendet wird. ICMP bestimmt die Art und Weise, wie Fehlerbehandlung und -analyse durchgeführt werden.
Das/die Software-Modul(e), das/die Schicht 3 implementiert/implementieren 2312, ist/sind mit einem Kommunikations-Handler 2314 verbunden. Der Kommunikations-Handler 2314 formatiert Nach richtendaten zu Paketen. Ein Format kann sich an ein ausgewähltes Protokoll aus einer Reihe von Kommunikationsprotokollen halten. Diese Protokolle können z. B. Ethernet, Token Ring, Fiber Distributed Data Interface (FDDI), Asynchronous Transfer Mode (ATM) usw. einschließen. In einer exemplarischen Ausführungsform wird ein Ethernet-Handler, der ein Ethernet-Protokoll implementiert, verwendet.
Nachdem eine Nachricht im lokalen Speicher formatiert wurde, ruft der Kommunikations-Handler 2314 einen Gerätetreiber auf. Während eines "normalen" Kommunikationsszenarios wird ein E/A-Treiber aufgerufen, um über ein Netzwerk zu kommunizieren. In einer exemplarischen Ausführungsform ist dies ein Netzwerk-Input/Output-Gerätetreiber (NIOP) 2316, erhältlich bei der Unisys Corporation. NIOP 2316 implementiert die Schichten 2 und 1 des OSI-Modells, d. h. die Sicherungsschicht bzw. die Bitübertragungsschicht des Modells.
Wenn die Kommunikation nicht über ein Netzwerk, sondern über den gemeinsamen Speicherbereich 160 stattfinden soll, wird ein Treiber 2218 für den gemeinsamen Speicherbereich aufgerufen. Wenn z. B. auf Partition 2202a die Kommunikation nicht über ein Netzwerk, sondern über den gemeinsamen Speicherbereich 160 stattfinden soll, kann der Kommunikations-Handler 2314 einen HMP-Treiber 2318 für den gemeinsamen Speicherbereich anstelle des NIOP-Treibers 2316 aufrufen. Der Kommunikations-Handler 2314 muss zwischen einem Aufruf des NIOP-Treibers 2316 und einem Aufruf des HMP-Treibers 2318 für den gemeinsamen Speicherbereich nicht unterscheiden. Aus der Sicht des Kommunikations-Handlers 2314 werden alle Nachrichten über ein Netzwerk übertragen. Das Betriebssystem entscheidet, welche der beiden Arten von Aufrufen durchgeführt werden soll, wie weiter unten erläutert wird. Die Funktionalität, die in den HMP-Treiber des gemeinsamen Speicherbereichs eingeschlossen ist, ist unten beschrieben.
Die Funktionalität, die in den 2200-Betriebssystem-Software-Modulen auf der Partition 2202a eingeschlossen ist, ist auch in ähnlichen Modulen eingeschlossen, die sich im NT- oder Unix-Betriebssystem auf Partition 2202n befinden. In 23 können diese Module eine API 2210n (dargestellt als Winsock/Sockets) und Netzkommunikationsschnittstellen-Module 2212 (dargestellt als TCP/UDP/IPS 2310n, IP/ICMP 2312n und Ethernet Handler 2314n) einschließen. Die Kommunikation mit dem Speicher 160 findet über den HMP-NIC-Gerätetreiber 2320 des gemeinsamen Speicherbereichs statt. Wie bei den Software-Modulen des 2200-Betriebssystems unterscheiden die Schichten der Software, die mit dem Anwendungsprogramm verbunden sind, einschließlich der API und der Kommunikationssoftware, nicht zwischen Kommunikation über das Netzwerk und Kommunikation über den gemeinsamen Speicherbereich. Diese Softwarekomponenten betrachten alle Kommunikationsvorgänge so, als ob sie über ein Netzwerk stattfänden.
24 zeigt weitere Details des HMP-Treibers 2320 des gemeinsamen Speicherbereichs, wie er in einer Windows NT-Umgebung gemäß einer exemplarischen Ausführungsform der Erfindung implementiert wird. In dieser Figur ist eine NT-Benutzeranwendung 2410 mit einer Dynamic Link Library 2412 verbunden. Die Dynamic Link Library 2412 ist mit einem Windows-Socket 2414 verbunden. Das Windows-Socket 2414 ist mit einem Transport Driver Interface (TDI) 2416 verbunden, einer Microsoft-definierten API für NT-Systeme. API 2416 ist mit einem TCP/IP-Modul 2418 verbunden, das die Schichten drei und vier des OSI-Kommunikationsmodells ausführt. Das TCP/IP-Modul 2418 kann über eine API 2420, die gemäß einer von den Unternehmen Microsoft und 3Com entwickelten Network Driver Interface Specification (NDIS) konstruiert ist, mit einem Gerätetreiber verbunden sein. Der Gerätetreiber kann z. B. ein Standardtreiber, wie z. B. ein COTS Ethernet-Gerätetreiber 2422, sein, der Nachrichtenübertragung über ein Ethernet-Netzwerk durchführt, oder ein HMP-NIC-Gerätetreiber 2320 des gemeinsamen Speicherbereichs. Wenn die API 2420 einen Gerätetreiber aufruft, unterscheidet sie nicht zwischen den beiden Arten von Aufrufen, und die gesamte Kommunikation scheint über ein Netzwerk stattzufinden.
Der HMP-NIC-Gerätetreiber 2320 des gemeinsamen Speicherbereichs kann z. B. die Module VLAN 2424, CONTROL 2426, SHM 2428 und BIOS 2430 einschließen. Die Arbeitsweise und Funktionalität dieser Module ist unten beschrieben.
25 ist ein Prozess-Ablaufdiagramm, das weitere Details der Arbeitsweise der in den 22–24 dargestellten Softwarekomponente gemäß der vorliegenden Erfindung zeigt. Der Prozess beginnt mit Schritt 2510, wo ein Anwendungsprogramm eine Nachricht und dazugehörige Header-Informationen im lokalen Speicher erstellt.
In Schritt 2511 ruft das Anwendungsprogramm eine dazugehörige API auf. Das Programm überträgt an die API die Länge der Nachricht, die IP-Adresse des Ziel-Hosts und einen oder mehrere Zeiger auf die Nachrichtendaten. Wenn die Nachricht über ein Netzwerk übertragen werden soll, gibt die IP-Adresse einen Gerätetreiber, wie z. B. den NIOP (auf der Seite des 2200-Betriebssystems) oder einen Ethernet LAN NIC-Gerätetreiber (auf der NT- oder UNIX-Seite) an. Wenn die Nachricht über den gemeinsamen Speicherbereich übertragen werden soll, gibt die IP-Adresse an, dass ein dazugehöriger HMP-Treiber des gemeinsamen Speicherbereichs zu verwenden ist.
In Schritt 2512 geben Software-Module, welche die Schichten 3 und 4 des OSI-Modells ausführen, der Nachricht verschiedene Header und formatieren die Nachrichtendaten so, dass sie den Anforderungen des ausgewählten Kommunikationsprotokolls entsprechen. Zum Beispiel fordert das Ethernet-Protokoll, dass eine einzelne Nachrichtenübertragung nicht mehr als 1500 Byte enthält. Eine längere Nachricht muss daher in mehrere Puffer formatiert werden, die in mehreren Nachrichtenübertragungen zu versenden sind.
In Schritt 2514 ruft ein Kommunikations-Handler (in einer exemplarischen Ausführungsform, ein Ethernet-Handler) das Betriebssystem (Operating System, OS) auf, um die Adresse des Gerätetreibers zu erhalten. Der Fachmann wird erkennen, dass andere Protokolle verwendet werden können, einschließlich z. B. Protokollen mit einer größeren Netzwerk-Datenpaket-Größe.
Im Allgemeinen stellt der Kommunikations-Handlex die Verbindung zu einem Gerätetreiber her, bevor Anwendungs-Nachrichten zur Übertragung empfangen werden. Der Kommunikations-Handler sendet seine eigene "Broadcast"-Nachricht über das Netzwerk und fordert jeden Knoten auf, mit seiner Kennung zu antworten, was bei TCP/IP in der Zurückgabe von IP-Adressen resultiert. So erfährt der Kommunikations-Handler, auf welche IP-Adressen zugegriffen werden kann.
In Schritt 2516 wählt das Betriebssystem eine Gerätetreiber-Adresse aus, die mit der angegebenen IP-Adresse verknüpft ist, und leitet die Adresse an den Kommunikations-Handler. In einer exemplarischen Ausführungsform verwaltet das Betriebssystem eine Tabelle, die IP-Adressen auf verschiedene Gerätetreiber abbildet. Die Gerätetreiber-Adresse kann einen Gerätetreiber angeben, der Netzkommunikation durchführt (z. B. den NIOP oder die Ethernet LAN NIC-Treiber). Alternativ kann der Gerätetreiber einen Gerätetreiber angeben, der Kommunikation über den gemeinsamen Speicherbereich durchführt. Der Kommunikations-Handler kann die beiden Arten von Adressen nicht unterscheiden. Der 2200-Betriebssystem-Gerätetreiber für den gemeinsamen Speicherbereich kann aus einem NIOP für ein 2200-Betriebssystem entwickelt werden, wie in U.S.-Patent Nr. 5,659,794, erteilt an Unisys, beschrieben.
In den Schritten 2518–2528 wird, wenn die Adresse anzeigt, dass die Kommunikation über den gemeinsamen Speicherbereich stattfinden soll, ein HMP-Treiber für den gemeinsamen Speicherbereich (2200-Betriebssystem) 2318 oder ein HMP NIC-Gerätetreiber für den gemeinsamen Speicherbereich (NT/UNIX) 2320 aufgerufen. Der aufgerufene Treiber bildet zunächst die ID des Ziel-Hosts auf einen der Knoten ab. Dadurch wird festgelegt, welche der Warteschlangen in der Ausgabe-Warteschlange der sendenden Knoten verwendet wird.
In Schritt 2518 bestimmt der aufgerufene Treiber, ob die Warteschlange für das Ziel-System (empfangende System) zurückgesetzt werden muss. Ist dies der Fall, so schreitet die Verarbeitung fort zu Schritt 2526, wo das sendende System (oder der sendende "Knoten") die Nachricht verwirft und einen Need Reset-Merker in der Warteschlange für das Ziel-System (oder den Ziel"knoten") setzt. Wenn dieser Merker gesetzt wurde, kann ein Reset-Verfahren durchgeführt werden.
Wenn anstelle von UDP ein TCP-Protokoll verwendet wird, kann die Nachricht verworfen werden, ohne dass dies zu einem. Verlust der Nachricht führt. Der Grund hierfür ist, dass TCP auf eine Quittierung vom empfangenden System wartet, die anzeigt, dass die Nachricht empfangen wurde. Dies wird mit Hilfe von Nachrichten-IDs verfolgt. Jede Nachricht wird im lokalen Speicher des sendenden Systems gehalten, bis eine dazugehörige Quittierung eingeht. Falls innerhalb eines vordefinierten Zeitraums keine Quittierung eingeht, wird ein anderer Aufruf an das Betriebssystem vorgenommen, die Nachricht erneut zu senden. Falls UDP anstatt TCP verwendet wird, geht die Nachricht verloren, da UDP den Empfang von Quittierungen des empfangenden Systems nicht verfolgt.
Typischerweise entscheidet die sendende Anwendung, ob UDP oder TCP verwendet wird. Diese Entscheidung ist für den gemeinsamen Speicherbereich transparent. In einer exemplarischen Ausführungsform unterstützt der gemeinsame Speicherbereich der vorliegenden Erfindung UDP, TCP und Protokolle höherer Schichten, die mit dem Gerätetreiber verbunden sind, welcher den gemeinsamen Speicherbereich verwaltet. Aus der Sicht eines Kommunikations-Handlers ist der gemeinsame Speicherbereich der vorliegenden Erfindung einfach ein anderes LAN, an das nicht sehr viele Knoten angeschlossen sind.
Wenn die Ziel-Warteschlange nicht zurückgesetzt werden muss, schreitet die Verarbeitung fort zu Schritt 2520, wo das sendende System überprüft, ob die Ziel-Warteschlange voll ist. In einer exemplarischen Ausführungsform wird dies durchgeführt durch Vergleichen des Werts, der im entsprechenden Enqueued_offset (in der Ausgabe-Warteschlange des sendenden Knotens) gespeichert ist, mit dem dazugehörigen Dequeued_offset (in der Eingabe-Warteschlange des empfangenden Knotens). Wenn durch das Stellen eines neuen Eintrags in die Ziel-Ausgabe-Warteschlange das Enqueued_offset gleich dem Dequeued_offset wird, ist die Ziel-Ausgabe-Warteschlange voll.
Wenn die Ziel-Ausgabe-Warteschlange voll ist, geht die Verarbeitung weiter zu Schritt 2528, wo die Nachricht verworfen wird. Die Nachricht kann später erneut gesendet werden, wie oben mit Bezug auf die Schritte 2518 und 2526 beschrieben.
Wenn die Ziel-Ausgabe-Warteschlange nicht voll ist, schreitet die Verarbeitung weiter zu Schritt 2522, wo ein Nachrichtenpuffer im gemeinsamen Speicherbereich aus dem Nachrichtenpufferverbund des sendenden Knotens gewonnen wird. Der Fachmann wird erkennen, dass dies auf eine Vielzahl von Arten implementiert werden kann. In einer exemplarischen Ausführungsform ist ein Speicherverwaltungsmodul mit dem Gerätetreiber des gemeinsamen Speicherbereichs auf jedem Knoten verknüpft, um leere Puffer zu überwachen.
Vorzugsweise ist für jede Ausgabe-Warteschlange ein Puffer-Pool verfügbar, der z. B. mindestens 511 Puffer einschließt. Jeder Puffer kann z. B. 427 Wörter à 8 Byte lang sein. In einer exemplarischen Ausführungsform beginnt jeder Puffer-Pool auf einer 4K-Wort-Seitengrenze, worin jedes Wort 8 Byte lang ist. Das heißt, ein neuer Puffer-Pool kann auf jeder achten 4K-Byte-Seitengrenze beginnen. Dies ermöglicht eine effizientere Speicherverwaltung.
Jeder Puffer-Pool kann z. B. 511·427·8//4096 = 1.748.992 Wörter lang sein, worin 511 die Anzahl der Warteschlangen-Einträge ist, 427 die Anzahl der Wörter ist, die benötigt werden, um eine 1500 Byte lange Nachricht zu bearbeiten, und ein zusätzlicher Header benötigt wird, um die Anforderungen des 2200-Betriebssystems zu erfüllen. 1500 geteilt durch vier ist gleich 375, plus 50 maximale Teile und zwei für Puffer- und Header-Länge, also insgesamt 427. Acht steht für die maximale Anzahl von Partitionen, und 4096 dient dazu, es für Sicherheitszwecke zu einer Seitengrenze aufzurunden.
Nachdem ein Puffer gewonnen wurde, geht die Verarbeitung zu Schritt 2524, wo die Nachricht durch Kopieren vom lokalen Speicher in den gemeinsamen Speicherpuffer in die Ausgabe-Warteschlange gestellt wird. Während dieses Prozesses wird ein Header erstellt, der als der Header dient, welcher in der Bitübertragungsschicht, Schicht 1, des OSI-Modells definiert ist.
Der Header im gemeinsamen Speicherpuffer kann als eine Bitübertragungsschicht betrachtet werden, weil die MAC- und die LLC-Schicht sich auf der Nachricht befinden, wenn sie vom Gerätetreiber des gemeinsamen Speicherbereichs empfangen wird.
Diese Header bleiben bestehen, weil zumindest die LLC-Schicht für potentielle Leitweglenkung am empfangenden Knoten benötigt wird. Der Header im Puffer ist notwendig aufgrund der verschiedenen Speicherzugriffs-Eigenschaften des Prozessors vom 2200-Typ und der Intel-Plattformen, und stellt auf der Bitübertragungsschicht dar, wie die Daten sind.
Wenn ein 2200-Betriebssystem den Nachrichten-Sendevorgang durchführt, wird der Block Transfer Pack-(BTP-)Hardware-Befehl verwendet, um die Nachrichtendaten vom lokalen in den gemeinsamen Speicherbereich zu verschieben. Dieser Befehl wandelt die Nachrichtendaten von 9-Bit-Bytes in 8-Bit-Bytes um, führt einen Vorgang des Auf-Null-Setzens und eine Umwandlung von Big-Endian (Prozessor vom Typ 2200) in Little-Endian (Intel) durch. Alternativ könnte diese Umwandlung in der Software vorgenommen werden.
In einer exemplarischen Ausführungsform wird die Nachricht zur Ausgabe-Warteschlange hinzugefügt durch Einfügen des Zeigers auf den Nachrichtenpuffer an der entsprechenden Stelle in der Ausgabe-Warteschlange und anschließendes Inkrementieren des entsprechenden Enqueued_offset mit der Ausgabe-Warteschlange des sendenden Knotens. Der Zeiger ist ein Offset vom Anfang des Pufferbereichs des sendenden Knotens. Vorzugsweise werden Offsets anstatt realer oder virtueller Adressen verwendet, so dass alle Knoten im gemeinsamen Speicherbereich dieselbe Adresse erhalten können. (Die virtuellen oder realen Adressen eines empfangenden Knotens werden nicht notwendigerweise auf dieselbe Stelle im Speicher abgebildet wie die virtuellen oder realen Adressen eines anderen Knotens.)
Wie oben mit Bezug auf die 23 und 24 beschrieben, wird, wenn ein Knoten eines 2200-Betriebssystems eine Nachricht sendet, wegen einer Gerätetreiber-Adresse ein Aufruf an das Betriebssystem durchgeführt. Das 2200-Betriebssystem verwendet die IP-Adresse, um zu entscheiden, ob während des Kommunikationsvorgangs ein NIOP-Gerätetreiber oder ein HMP-Treiber für den gemeinsamen Speicherbereich verwendet werden sollte. Wenn ein NT-Knoten eine Nachricht sendet, wird eine ähnliche Funktionalität bereitgestellt. Die VLAN-Komponente empfängt den Nachricht-senden-Aufruf von NDIS. VLAN gibt diesen Aufruf an CONTROL, wo festgelegt wird, ob die IP-Adresse, die mit dem Nachrichten-Sendevorgang zusammenhängt, auf den Ethernet-Gerätetreiber oder auf den SHM-Gerätetreiber abgebildet wird, und der entsprechende Geräteaufruf vorgenommen wird. Das SHM-Modul führt die Funktionalität aus, die in den Schritten 2518–2528 dargestellt ist.
Um eine Nachricht zu empfangen, durchläuft jeder Knoten im System eine Schleife, die die Ausgabe-Warteschlangen für jeden Knoten im System überprüft. In einer exemplarischen Ausführungsform führt jeder Knoten diese Überprüfung durch, als ob das System vollständig mit der maximalen Anzahl von acht Knoten konfiguriert sei, selbst wenn weniger Knoten zur Verfügung stehen. Die Ausgabe-Warteschlangen der Knoten, die nicht zur Verfügung stehen, können initialisiert werden, so dass es so aussieht, als ob keine Nachrichten verfügbar seien. Jeder Knoten überprüft seine eigene Ausgabe-Warteschlange, um zu ermitteln, ob er eine Nachricht an sich selbst sendet, obwohl dies im Allgemeinen nicht der Fall sein wird. Dies sind Konstruktions-Entscheidungen, die implementiert werden können, um den Code zu vereinfachen.
Alternativ können die Anzahl und Identität der verfügbaren Knoten während der System-Initialisierung jedem Knoten mitgeteilt werden, so dass nur die Ausgabe-Warteschlangen von Knoten, die wirklich vorhanden sind, überprüft werden. In dieser Ausführungsform wird jede Änderung der Anzahl von Knoten, die den gemeinsamen Speicherbereich nutzen, den teilnehmenden Knoten mitgeteilt, wenn die Änderung stattfindet.
26 zeigt einen exemplarischen Nachrichten-Empfangsprozess, der für jede Partition durchgeführt wird. Der Prozess beginnt mit Schritt 2610, wo ein eine Nachricht empfangender Knoten einen Need_Reset-Merker in der Ausgabe-Warteschlange eines anderen Sub-Pods überprüft. Zum Beispiel überprüft Knoten 0 den Need_Reset-Merker in der Knoten-1-an-Knoten-0-Warteschlange in der Ausgabe-Warteschlange des Knotens 1. Wenn der Need_Reset-Merker gesetzt ist, geht die Verarbeitung weiter zu Schritt 2612, wo eine Initialisierungs-Sequenz durchgeführt wird.
Wenn der Need_Reset-Merker nicht gesetzt ist, schreitet die Verarbeitung fort zu Schritt 2614, wo der die Nachricht empfangende Sub-Pod einen entsprechenden Enqueued_offset-Merker mit einem seiner eigenen Dequeued_offset-Merker in seiner eigenen Ausgabe-Warteschlange vergleicht. Zum Beispiel vergleicht in den 16A und 16B Knoten 0 den Enqueued_offset-Merker in der Knoten-1-an-Knoten-0-Warteschlange in der Ausgabe-Warteschlange des Knotens 1 mit dem Dequeued_offset für Knoten 1 in seiner eigenen Ausgabe-Warteschlange (in Wort 1 der Dequeued_offsets). Wenn die in den beiden Feldern gespeicherten Werte gleich sind, ist die Warteschlange leer, und die Verarbeitung geht zu Schritt 2624, wo die Routine verlassen wird.
Wenn eine Nachricht vorliegt, geht die Verarbeitung zu Schritt 2616, wo ein verfügbarer Puffer im lokalen Speicher erworben wird. Der Puffer-Pool für den Treiber des gemeinsamen Speicherbereichs kann vom Betriebssystem in Verbindung mit dem Kommunikations-Handler verwaltet werden, wie unten erläutert. Wenn ein Puffer nicht verfügbar ist, kann eine Warteschleife 2617 durchlaufen werden. In Schritt 2618 wird ein Puffer erworben, und das Dequeued_offset wird als Offset in die Warteschlange verwendet, um einen Zeiger auf den gemeinsamen Speicherbereich abzurufen. Der Zeiger ist vorzugsweise ein Offset vom Anfang des Puffer-Pools des sendenden Sub-Pods. Er wird verwendet, um die Nachrichtendaten aus einem der Nachrichtenpuffer des sendenden Sub-Pods im gemeinsamen Speicherbereich abzurufen.
In Schritt 2620 werden die Nachrichtendaten in den lokalen Puffer kopiert. Auf einem NT/UNIX-Sub-Pod, der eine Nachricht von einem 2200-Betriebssystem empfängt, kann ein Kompressionsprozess durchgeführt werden, mit dem die Nachrichtenbytes an benachbarte Stellen verschoben werden, die alle Bits (z. B. 64 Bits) eines Worts nutzen. Dies wird bevorzugt, weil die Nachrichtendaten eines 2200-Betriebssystems nur die niedrigstwertigen vier Byte eines Wortes einnehmen und der Rest auf Null gesetzt wird. Auf der Seite des 2200-Betriebssystems können die Nachrichtendaten mit Hilfe des Hardware-Befehls Block Transfer Unpack (BTU), der Nachrichtendaten von 8-Bit- in 9-Bit-Bytes umwandelt und Little-Endian-(Intel)-in-Big-Endian-(2200-Prozessor)-Konvertierung durchführt, aus dem gemeinsamen Speicherbereich kopiert werden. Diese Konvertierung kann in Software, Firmware, Hardware oder einer beliebigen Kombination davon durchgeführt werden.
Alternativ können Nachrichten im gemeinsamen Speicherbereich im 2200-Prozessor-Format gespeichert werden, wodurch eine eine Nachricht empfangende Intel-Plattform zwischen Big- und Little-Endian konvertieren und das zusätzliche Bit, das vom Prozessor des 2200-Typs benötigt wird, hinzufügen bzw. entfernen würde.
Nachdem die Nachrichtendaten in einen lokalen Puffer kopiert wurden, schreitet die Verarbeitung fort zu Schritt 2622, wo der Treiber für den gemeinsamen Speicherbereich die Nachricht in eine Warteschlange des lokalen Speichers stellt. Der Treiber für den gemeinsamen Speicherbereich kann dann überprüfen, ob ein empfangender Prozess (z. B. eine Anwendung 2208) verfügbar ist, um die Nachricht zu verarbeiten. Auf der Seite des 2200-Betriebssystems überprüft der Treiber für den gemeinsamen Speicherbereich, ob ein Merker anzeigt, dass ein Co-operative Processing Communications Program (CPCOMM), entwickelt von der Unisys Corporation, "ruht". Das CPCOMM bearbeitet Kommunikationsprotokoll-Schichten, wenn Nachrichten versendet werden. Falls CPCOMM ruht, ruft der Treiber des gemeinsamen Speicherbereichs das Betriebssystem auf, um CPCOMM mit der neu in die Warteschlange gestellten Nachricht zu aktivieren. Alternativ könnte Polling angewandt werden, um zu ermitteln, ob eine Nachricht im lokalen Speicher vorliegt.
27 zeigt einen exemplarischen Prozess für CPCOMM auf der Seite des 2200-Betriebssystems, der den Empfang von Nachrichten abwickelt. Wie auch bei dem Senden von Nachrichten weiß CPCOMM nicht, dass eine empfangene Nachricht durch den gemeinsamen Speicherbereich übertragen wurde. Aus der Sicht von CPCOMM werden alle Nachrichten über ein Netzwerk gesendet und empfangen.
Möglicherweise ruht CPCOMM, wenn ein Interrupt vom 2200-Betriebssystem empfangen wird. Dieser Interrupt ist das Ergebnis davon, dass das Betriebssystem einen Aufruf vom Treiber des gemeinsamen Speicherbereichs empfängt, welcher anzeigt, dass eine Nachricht in CPCOMMs lokale Nachrichten-Warteschlange gestellt wurde. Wenn CPCOMM unterbrochen wird, tritt es in eine Verarbeitungsschleife 2708 ein. Der Prozess beginnt mit Schritt 2710, wo ein Puffer im lokalen Speicher erworben wird. In Schritt 2712 ruft CPCOMM das 2200-Betriebssystem auf und gibt die Pufferadresse weiter. Das 2200-Betriebssystem stellt den Puffer je nach Bedarf in einen der Pufferverbünde, die mit einem der Gerätetreiber verknüpft sind. Der Gerätetreiber für den gemeinsamen Speicherbereich ist mit einem dieser Pufferverbünde verknüpft. Die Puffer in diesen Verbünden stehen dann für empfangene Nachrichtendaten zur Verfügung.
Nachdem die Pufferadresse an das Betriebssystem geleitet wurde, geht die Verarbeitung zu Schritt 2714, wo CPCOMM überprüft, ob eine Nachricht in seiner Eingabe-Warteschlange vorliegt. Wenn das CPCOMM vom Betriebssystem aus unterbrochen wurde, ist eine Nachricht vorhanden.
In Schritt 2716 entfernt CPCOMM, wenn eine Nachricht vorliegt, diese aus seiner Warteschlange und gibt sie an die oberen Schichten des Codes weiter. Die Verarbeitung kehrt dann zu Schritt 2710 zurück, wo CPCOMM einen weiteren Puffer erwirbt.
In Schritt 2714 geht die Verarbeitung, wenn CPCOMM feststellt, dass keine weiteren Nachrichten vorliegen, zu Schritt 2718, wo CPCOMM ermittelt, ob ausreichend leere Puffer zur Verwendung durch die verschiedenen Gerätetreiber verfügbar sind. Ist dies der Fall, so schreitet die Verarbeitung fort zu Schritt 2720, wo CPCOMM wieder den Ruhezustand einnimmt.
V. Schlussfolgerungen
Es sollte deutlich sein, dass Ausführungsformen der vorliegenden Erfindung in Hardware, Software oder einer Kombination davon implementiert werden können. In solchen Ausführungsformen können verschiedene Komponenten und Schritte in Hardware, Firmware und/oder Software implementiert werden, um die Funktionen der vorliegenden Erfindung zu erfüllen. Alle zurzeit erhältlichen oder zukünftig entwickelten Computer-Software-Sprachen- und/oder Hardware-Komponenten können in solchen Ausführungsformen der vorliegenden Erfindung verwendet werden. Im Speziellen kann der Pseudo-Code, der oben und in den folgenden Anhängen behandelt und bereitgestellt wird, bei der Erstellung der Software-Ausführungsformen besonders nützlich sein.

Claims

Ein Computersystem (100), das eine Vielzahl von Verarbeitungsmodulen (110, 112, 114) und einen Hauptspeicher (160) umfasst, wobei jedes Verarbeitungsmodul eine Vielzahl von Prozessoren (240) umfasst, wobei Gruppen von einem oder mehreren Verarbeitungsmodulen als separate Partitionen innerhalb des Computersystems ausgebildet sind, wobei jede Partition unter der Steuerung eines separaten Betriebssystems (170, 172, 174) arbeitet und jeder Partition ein exklusives Speicherfenster (540A, 540B, 540C) im Hauptspeicher (160) zugewiesen ist, auf welches nur die Verarbeitungsmodule dieser Partition Zugriff haben und in welchem das Betriebssystem dieser Partition arbeitet, dadurch gekennzeichnet, dass jedes Verarbeitungsmodul weiter Folgendes umfasst: ein Register (3330), das ein Offset (R_L ⁰³) von der physikalischen Basisadresse des Hauptspeichers zum Start des exklusiven Speicherfensters enthält, welches der Partition zugewiesen ist, von der das Verarbeitungsmodul ein Teil ist, und einen Addierer (3420) zum Addieren des Offsets (R_L ⁰³) zu jedem Verweis durch einen Prozessor dieses Verarbeitungsmoduls auf eine Speicherstelle innerhalb seines physikalischen Adressraums, wodurch diese Verweise an ihre entsprechenden Speicherstellen im exklusiven Speicherfenster verschoben werden, wodurch der physikalische Adressraum der Prozessoren in jeder Partition auf das jeweilige exklusive Speicherfenster abgebildet wird, das der Partition zugewiesen wurde.
Das Computersystem (100) nach Anspruch 1, worin jedes exklusive Speicherfenster (540A, 540B, 540C) seinem jeweiligen Betriebssystem (170, 172, 174) so dargestellt wird, dass es eine physikalische Basisadresse von 0 hat.
Das Computersystem (100) nach Anspruch 1, worin der physikalische Adressraum der Prozessoren (240) einer bestimmten Partition einen Adressbereich enthalten kann, der nicht zur Speicherung im Speicher verfügbar ist, wobei der nicht verfügbare Bereich eine Speicherungslücke (512, 542, 572) bestimmt, wobei Adressen oberhalb der Speicherungslücke einen oberen Speicherbereich (513, 543, 573) bestimmen und Adressen unterhalb der Speicherungslücke einen unteren Speicherbereich (511, 541, 571) bestimmen, wobei das Computersystem (100) weiter Mittel umfasst, um den Teil des exklusiven Speicherfensters der jeweiligen Partition für andere Zwecke zurückzufordern, der ansonsten der Speicherungslücke entsprechen würde.
Das Computersystem (100) nach Anspruch 3, worin das Mittel zum Zurückfordern für jedes Verarbeitungsmodul der Partition ein Register (3340) umfasst, das einen Wert (R_c ⁰³) enthält, welcher die Größe der Speicherungslücke darstellt, und worin der Addierer (3420): (i) das Offset (R_L ⁰³) zu jedem Verweis durch einen Prozessor in der Partition auf eine Speicherstelle innerhalb des unteren Speicherbereichs seines physikalischen Adressraums addiert, wodurch diese Verweise an ihre entsprechenden Speicherstellen im exklusiven Speicherfenster verschoben werden, und (ii) das Offset abzüglich des Werts, welcher die Größe der Speicherungslücke (R_L ⁰³ – R_c ⁰³) darstellt, zu jedem Verweis durch einen Prozessor in der Partition auf eine Speicherstelle im oberen Speicherbereich seines physikalischen Adressraums addiert, wodurch diese Verweise an ihre entsprechenden Speicherstellen im exklusiven Speicherfenster verschoben werden und der Teil des exklusiven Speicherfensters, der ansonsten der Speicherungslücke entsprochen hätte, zurückgefordert wird.
Das Computersystem (100) nach Anspruch 1, worin einige der Partitionen unter der Steuerung verschiedener Betriebssysteme arbeiten.
Das Computersystem (100) nach Anspruch 1, worin einige der Partitionen unter der Steuerung verschiedener Instanzen eines identischen Betriebssystems arbeiten.
Das Computersystem (100) nach Anspruch 1, worin der Hauptspeicher (160) weiter ein gemeinsam benutztes Speicherfenster (537), separat von den exklusiven Speicherfenstern (540A, 540B, 540C) umfasst und worin jedes Verarbeitungsmodul einer bestimmten Partition weiter Folgendes umfasst: ein Register (3320), das ein Offset (S_BASE ^OS) von der Basisadresse des physikalischen Adressraums der Prozessoren in der bestimmten Partition zu dem Start eines bestimmten Abschnitts des physikalischen Adressraums, auf den das gemeinsam benutzte Speicherfenster abgebildet werden soll, enthält; ein Register (3118), das ein Offset (S_BASE ^MSU) von der Basisadresse des Hauptspeichers zum Start des gemeinsam benutzten Speicherfensters (537) innerhalb des Hauptspeichers enthält und worin der Addierer (3420) die Differenz zwischen den Offsets (S_BASE ^MSU – S_BASE ^OS) zu jedem Verweis durch einen Prozessor in der bestimmten Partition auf eine Speicherstelle innerhalb des bestimmten Abschnitts addiert, wodurch diese Verweise an ihre entsprechenden Speicherstellen innerhalb des gemeinsam benutzten Speicherfensters des Hauptspeichers verschoben werden.
Das Computersystem (100) nach Anspruch 7, das weiter Programmcode umfasst, der auf der Vielzahl von Partitionen ausgeführt wird und es diesen Partitionen ermöglicht, miteinander durch das gemeinsam benutzte Speicherfenster (537) zu kommunizieren.
Das Computersystem (100) nach Anspruch 8, worin einige der Partitionen unter der Steuerung verschiedener Betriebssysteme arbeiten.
Das Computersystem (100) nach Anspruch 8, worin einige der Partitionen unter der Steuerung verschiedener Instanzen eines identischen Betriebssystems arbeiten.
Das Computersystem (100) nach Anspruch 8, worin der Programmcode (1804) einen Prozess implementiert, durch den eine sendende Partition einen Inter-Prozessor-Interrupt auf einer empfangenden Partition verursacht, um der empfangenden Partition zu signalisieren, dass durch das gemeinsam benutzte Speicherfenster Informationen an sie gesendet werden.
Das Computersystem (100) nach Anspruch 11, worin das gemeinsam benutzte Speicherfenster einen Satz von Eingabe-Warteschlangen (1914) umfasst, die mit jeder Partition verknüpft sind, wobei jede Eingabe-Warteschlange des Satzes, die mit einer bestimmten Partition verknüpft ist, einer anderen Partition entspricht und Einträge speichert, die Kommunikation von dieser anderen Partition darstellen.
Das Computersystem (100) nach Anspruch 12, worin das gemeinsam benutzte Speicherfenster weiter eine Vielzahl von Seiten (1916) von Speicher umfasst, die den Partitionen nach Bedarf zugewiesen werden können, um den Austausch von Informationen zwischen ihnen zu erleichtern.
Das Computersystem (100) nach Anspruch 13, worin jede Partition Eigentumsrechte auf eine bestimmte Seite haben kann und worin die Seite einen Header hat, der Informationen enthält, welche angeben, welche Partitionen Eigentumsrechte auf die Seite haben.
Das Computersystem (100) nach Anspruch 14, worin der Header der Seite weiter ein Sperrfeld umfasst, durch das eine Partition exklusiven Zugriff auf eine Seite erhalten kann, um Eigentumsinformationen im Header der Seite zu aktualisieren und so einen Mechanismus bereitzustellen, um Vielfachzugriff auf die Seite durch verschiedene Partitionen zu synchronisieren.
Das Computersystem (100) nach Anspruch 15, worin das gemeinsam benutzte Speicherfenster ein mit ihm verbundenes systemweites Sperrfeld hat, durch das eine Partition exklusiven Zu griff auf die gemeinsam benützten Speicherseiten erhalten kann, um eine oder mehrere Seiten zuzuweisen und um so einen Mechanismus bereitzustellen, um Mehrfachanforderungen zur Zuweisung von Speicherseiten durch verschiedene Partitionen zu synchronisieren.
Das Computersystem (100) nach Anspruch 15, worin das Eigentumsrecht an einer Seite durch Erwerben des Sperrfelds dieser Seite aktualisiert werden kann, ohne dass das systemweite Sperrfeld erworben werden muss.
Das Computersystem (100) nach Anspruch 12, worin, damit eine Partition (eine sendende Partition) mit einer anderen Partition (einer empfangenden Partition) kommunizieren kann, der Programmcode auf der sendenden Partition: (i) veranlasst, dass ein Eintrag in der Eingabe-Warteschlange der empfangenden Partition erzeugt wird, welcher der sendenden Partition entspricht; und (ii) veranlasst, dass ein Inter-Prozessor-Interrupt in der empfangenden Partition erzeugt wird, um der empfangenden Partition zu signalisieren, dass der Eintrag in der Eingabe-Warteschlange erzeugt wurde.
Das Computersystem (100) nach Anspruch 18, worin, wenn die Inter-Prozessor-Interrupt auf der empfangenden Partition erkannt wird, der Programmcode (1804) auf der empfangenden Partition: (i) veranlasst, dass jede ihrer Eingabe-Warteschlangen untersucht wird, um festzustellen, welche der Eingabe-Warteschlangen Einträge enthalten, die Kommunikation von anderen Partitionen darstellen; und (ii) veranlasst, dass solche Einträge aus den Eingabe-Warteschlangen, die sie enthalten, herausgenommen werden.
Das Computersystem (100) nach Anspruch 12, worin jede Eingabe-Warteschlange in der Lage ist, eine vordefinierte Anzahl von Einträgen (3016) zu speichern, und ein Überlauf-Flag (3014) enthält, das immer dann von einer sendenden Partition gesetzt wird, wenn die Eingabe-Warteschlange voll wird, und das immer dann von einer empfangenden Partition rückgesetzt wird, wenn Einträge aus der Eingabe-Warteschlange extrahiert werden.
Das Computersystem (100) nach Anspruch 8, worin der Programmcode einen Abfrageprozess implementiert, durch den jede Partition einen Bereich (1414) innerhalb des gemeinsam benutzten Speicherfensters abfragt, um zu ermitteln, ob Kommunikation, die für sie bestimmt ist, von einer anderen Partition in das gemeinsam benutzte Speicherfenster platziert wurde.
Das Computersystem (100) nach Anspruch 21, worin der Bereich (1414) eine Vielzahl von Ausgabe-Warteschlangen (1412a, 1412b, 1412c), eine für jede Partition, umfasst, wobei die Ausgabe-Warteschlange für eine bestimmte Partition anzeigt, ob diese Partition irgendeine Kommunikation, die für eine der anderen Partitionen bestimmt ist, in das gemeinsam benutzte Speicherfenster platziert hat, wobei jede Partition die Ausgabe-Warteschlangen der anderen Partitionen abfragt, um zu ermitteln, ob diese anderen Partitionen irgendeine Kommunikation, die für sie bestimmt sind, in das gemeinsam benutzte Speicherfenster platziert haben.
Das Computersystem (100) nach Anspruch 22, worin die Ausgabe-Warteschlange der sendenden Partition für jede Kommunikation, die von einer sendenden Partition in das gemeinsam benutzte Speicherfenster platziert wird und von einer anderen Partition empfangen werden soll, die Speicherstelle eines Puffers, der diese Kommunikation enthält, innerhalb des gemeinsam benutzten Speicherfensters angibt.
Das Computersystem (100) nach Anspruch 23, worin jeder Partition ein separater Pool (1402) von Nachrichtenpuffern (1410) zugewiesen wird, in den sie Kommunikation platzieren kann, die für andere Partitionen bestimmt ist.
Ein Verfahren zur Verwendung in einem Computersystem (100), das Folgendes umfasst: (i) eine Vielzahl von Verarbeitungsmodulen (110, 112, 114), wobei jedes Verarbeitungsmodul eine Vielzahl von Prozessoren (240) umfasst, wobei Gruppen aus einem oder mehreren Verarbeitungsmodulen als separate Partitionen innerhalb des Computersystems ausgebildet sind, wobei jede Partition unter der Steuerung eines separaten Betriebssystems (170, 172, 174) arbeitet; und (ii) einen Hauptspeicher (160), in dem jeder Partition ein exklusives Speicherfenster (540A, 540B, 540C) zugewiesen ist, auf welches nur diese Partition Zugriff hat und in welchem das Betriebssystem dieser Partition arbeitet, wobei das Verfahren für jede Partition Folgendes umfasst: Speichern eines Wertes, der ein Offset (R_L ^OS) von der physikalischen Basisadresse des Hauptspeichers zum Start des exklusiven Speicherfensters darstellt, das dieser Partition zugewiesen ist; und Addieren des Offsets (R_L ^OS) zu jedem Verweis eines Prozessors in dieser Partition auf eine Speicherstelle innerhalb ihres physikalischen Adressraums, wodurch diese Verweise an ihre entsprechenden Speicherstellen innerhalb des exklusiven Speicherfensters verschoben werden, wodurch der physikalische Adressraum der Prozessoren in jeder Partition auf das jeweilige exklusive Speicherfenster abgebildet wird, das der Partition zugewiesen wurde.
Das Verfahren nach Anspruch 25, worin der physikalische Adressraum der Prozessoren einer bestimmten Partition einen Adressbereich enthalten kann, der nicht zur Speicherung verfügbar ist, wobei der nicht verfügbare Bereich eine Speicherungslücke (512, 542, 572) bestimmt, wobei Adressen oberhalb der Speicherungslücke einen oberen Speicherbereich (513, 543, 573) bestimmen und Adressen unterhalb der Speicherungslücke einen unteren Speicherbereich (511, 541, 571) bestimmen, wobei das Verfahren weiter das Zurückfordern des Teils des exklusiven Speicherfensters der bestimmten Partition für andere Zwecke umfasst, der ansonsten der Speicherungslücke entsprechen würde, und zwar als ein Ergebnis des Verschiebungs- Schritts.
Das Verfahren nach Anspruch 26, worin die Verschiebungs- und Zurückforderungs-Schritte für jede Partition Folgendes umfassen: Speichern eines Wertes, der ein Offset (R_L ^OS) von der physikalischen Basisadresse des Hauptspeichers zum Start des exklusiven Speicherfensters, das der Partition zugewiesen ist, darstellt; Speichern eines Wertes (R_C ^OS), der die Größe der Speicherungslücke darstellt; Addieren des Offsets (R_L ^OS) zu jedem Verweis eines Prozessors in dieser Partition auf eine Speicherstelle im unteren Speicherbereich ihres physikalischen Adressraums, wodurch diese Verweise an ihre entsprechenden Speicherstellen innerhalb des exklusiven Speicherfensters verschoben werden; und Addieren des Offsets abzüglich der Größe der Speicherungslücke (R_L ^OS – R_C ^OS) zu jedem Verweis eines Prozessors in dieser Partition auf eine Speicherstelle innerhalb des oberen Speicherbereichs ihres physikalischen Adressraums, wodurch diese Verweise an ihre entsprechenden Speicherstellen innerhalb des exklusiven Speicherfensters verschoben werden und der Teil des exklusiven Speicherfensters, der ansonsten der Speicherungslücke entsprochen hätte, zurückgefordert wird.
Das Verfahren nach Anspruch 25, worin der Hauptspeicher (160) weiter ein gemeinsam benutztes Speicherfenster (537), separat von den exklusiven Speicherfenstern, umfasst und worin das Verfahren weiter Folgendes umfasst: Zuweisen, auf jeder Partition, eines Teils (514, 544, 574) des physikalischen Adressraums der Prozessoren dieser Partition, sodass er dem gemeinsam benutzten Speicherfenster (537) innerhalb des Hauptspeichers (160) entspricht; und Verschieben jedes Verweises eines Prozessors einer Partition auf eine Speicherstelle innerhalb des zugewiesenen Teils seines physikalischen Adressraums an die entsprechende Speicherstelle innerhalb des gemeinsam benutzten Speicherfensters im Hauptspeicher.
Das Verfahren nach Anspruch 28, worin der Schritt des Verschiebens eines Verweises durch einen Prozessor auf einer Partition auf den zugewiesenen Teil seiner physikalischen Adresse an die entsprechende Speicherstelle im gemeinsam benutzten Speicherfenster (537) Folgendes umfasst: Speichern eines Wertes, der ein Offset (S_BASE ^OS von der Basisadresse des physikalischen Adressraums des Prozessors auf dieser Partition zum Start des zugewiesenen Teils dieses physikalischen Adressraums darstellt Speichern eines Wertes, der ein Offset (S_BASE ^MSU) von der Basisadresse des Hauptspeichers zum Start des gemeinsam benutzten Speicherfensters im Hauptspeicher darstellt; und Addieren der Differenz zwischen den gespeicherten Offsets (S_BASE ^MSU – S_Base ^OS) zu allen Verweisen durch einen Prozessor in dieser Partition auf eine Speicherstelle innerhalb des zugewiesenen Teils, wodurch diese Verweise an ihre entsprechenden Speicherstellen innerhalb des gemeinsam benutzten Speicherfensters des Hauptspeichers verschoben werden.
Das Verfahren nach Anspruch 25, worin jedes exklusive Speicherfenster (540A, 540B, 540C) gegenüber seinem jeweiligen Betriebssystem so dargestellt wird, dass es eine physikalische Basisadresse von Null hat.