DE10045916A1

DE10045916A1 - Methode und System zum Implementieren eines Remstat-Protokolls und Einbeziehung und Nicht-Einbeziehung von L1-Daten im L2-Cache zur Verhinderung einer gegenseitigen Lesesperre

Info

Publication number: DE10045916A1
Application number: DE10045916A
Authority: DE
Inventors: Sanjay Raghunath Deshpande; Peter Steven Lenk; Michael John Mayfield
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1999-09-23
Filing date: 2000-09-16
Publication date: 2001-04-12
Also published as: US6587930B1; US20030120874A1

Abstract

Bereitstellen einer verteilten Systemstruktur für ein weitreichendes Multibus- und Multiprozessorsystem unter Verwendung eines Bus-basierten Cache-Kohärenz-Protokolls. Die verteilte Systemstruktur umfasst einen Adressschalter, mehrere Speichersubsysteme und mehrere Master-Geräte, entweder Prozessoren, E/A Agents oder kohärente Speicheradapter, eingeteilt in einen Knotensatz, unterstützt von einem Knoten-Controller. Der Knoten-Controller empfängt Befehle von einem Master-Gerät, kommuniziert mit einem Master-Gerät als ein weiteres Master-Gerät oder als ein Slave-Gerät und stellt Befehle in die Warteschlange, die vom Master-Gerät empfangen wurden. Das System ermöglicht die Implementierung eines Busprotokolls, das den Status einer Cachezeile an ein Master-Gerät zusammen mit der ersten Datenlieferung für ein cachebares kohärentes Lesen weitergibt. Da das Erreichen von Kohärenz zeitlich und räumlich verteilt ist, wird die Ausgabe der Datenintegrität über eine Reihe von Aktionen erreicht. In einer Implementierung unterstützt der Knoten-Controller die Cache-Kohärenz für Befehle durch Blockieren eines Master-Geräts vom Empfang bestimmter Transaktionen, um gegenseitige Lesesperren zu verhindern. In einer anderen Implementierung verwenden die Master-Geräte ein Busprotokoll, das gegenseitige Lesesperren in einem verteilten Multibus- und Multiprozessorsystem verhindert.

Description

Hintergrund der Erfindung Technischer Bereich

Die vorliegende Erfindung befasst sich im allgemeinen mit einem verbesserten Datenverarbeitungssystem und im besonderen mit einer Methode und einem System zum Verbessern des Datendurchsatzes in einem Datenverarbeitungssystem. Die vorliegende Erfindung befasst sich im besonderen mit einer Methode und einem System zur Verbesserung der Leistung beim Zugriff sowie bei der Steuerung des Speichers unter Verwendung von Cache-Kohärenz.

Der Stand der Technik

Traditionell werden symmetrische Multiprozessoren für einen gängigen Systembus entwickelt, auf dem alle Prozessoren und andere Geräte, wie etwa der Speicher und E/A-Geräte miteinander verbunden sind, indem einfach physische Kontakte zu den Kabeln mit den Bussignalen hergestellt werden. Dieser gemeinsame Bus ist der Pfad zum Übertragen von Befehlen und Daten zwischen Geräten sowie zum Erreichen von Kohärenz zwischen Cache und Hauptspeicher des Systems. Die Entwicklung eines einzelnen gemeinsamen Busses ist eine gängige Methode für die Multiprozessor-Konnektivität aufgrund der Einfachheit der Systemorganisation.

Diese Organisation vereinfacht auch die Aufgabe zum Erreichen von Kohärenz zwischen den Caches des Systems. Ein von einem Gerät ausgegebener Befehl wird simultan und im gleichen Taktzyklus, in dem der Befehl auf dem Bus platziert wird, an alle anderen Systemgeräte gesendet. Ein Bus ermöglicht eine feste Reihenfolge für alle darauf platzierten Befehle. Diese Reihenfolge wird von allen Geräten im System bestätigt, da sie alle die gleichen Befehle erhalten. Die Geräte können ebenfalls ohne besonderen Aufwand den Endeffekt einer Befehlssequenz bestätigen. Dies ist einer der Hauptvorteile für einen Einzelbus-basierten Multiprozessor.

Eine Gestaltung mit einem einzelnen, gemeinsamen Bus begrenzt jedoch den Umfang des Systems, bis sich jemand für eine niedrigere Systemleistung entscheidet. Die technologischen Grenzen ermöglichen es normalerweise nur einigen Geräten, mit dem Bus verbunden zu sein, ohne eine Beeinträchtigung Geschwindigkeit, mit der ein Bus umschaltet und somit ohne eine Beeinträchtigung der Geschwindigkeit, mit der das System arbeitet, zu verursachen. Wenn mehr Master-Geräte, wie Prozessoren und E/A-Agents, auf dem Bus platziert werden, muss der Bus mit verringerter Geschwindigkeit schalten, was seine verfügbare Bandbreite verringert. Eine geringere Bandbreite kann die Warteschlangenzeiten erhöhen, was wiederum zu einer Verringerung der Auslastung des Prozessors und zu einer Verringerung der Systemleistung führen kann. Ein weiterer entscheidender Nachteil in einem Einzelbus- System ist die Verfügbarkeit eines einzelnen Datenpfads zum Übertragen von Daten. Dies erhöht weiter die Warteschlangenzeiten und trägt zur Verringerung der Systemleistung bei.

Es existieren im weitesten Sinne zwei Klassen von Cache- Kohärenz-Protokollen. Die eine Klasse besteht aus Bus basierten Suchprotokollen, in der alle Caches des Systems mit einem gemeinsamen Bus verbunden sind und nach Transaktionen suchen, die an den gemeinsamen Bus durch andere Caches ausgegeben werden, um dann die entsprechenden Maßnahmen zu ergreifen, um die gegenseitige Kohärenz zu wahren. Die andere Klasse umfasst Verzeichnis-basierte Protokolle, wobei jede Speicheradresse über eine "Home Site" verfügt. Sobald ein Cache auf diese Adresse zugreift, wird ein "Verzeichnis" auf der Home Site aktualisiert, um die Identität des Cache und den Status der darin enthaltenen Daten zu speichern. Wenn es notwendig wird, den Status der Daten in dem Cache zu aktualisieren, sendet die Home Site explizit eine Meldung an das Cache und fordert es zu der entsprechenden Maßnahme auf. Hinsichtlich der Komplexität bei Implementierung und Prüfung ist das Bus-basierte Suchprotokoll sehr viel einfacher strukturiert als das Verzeichnis-basierte Protokoll und damit das bevorzugte Protokoll bei symmetrischen Multiprozessor (SMP)-Systemen. Das Bus-basierte Suchprotokoll kann jedoch nur effektiv in einem System eingesetzt werden, in dem eine kleine Zahl an Prozessoren, normalerweise 2 bis 4, arbeiten. Auch wenn also eine Einzel-Systembus-Gestaltung derzeit die bevorzugte Gestaltung darstellt, um ein Kohärenz-Protokoll zu implementieren, kann es nicht für ein weitreichendes Multiprozessorsystem mit langen Wegen eingesetzt werden. Es ist daher von Vorteil, über eine Gestaltung weitreichender, verteilter Multibus- und Multiprozessorsysteme unter Verwendung von Bus-basierten Cache-Kohärenz-Protokollen zu verfügen.

Zusammenfassung der Erfindung

Eine verteilte Systemstruktur für ein weitreichendes Multibus- und Multiprozessorsystem unter Verwendung eines Bus-basierten Cache-Kohärenz-Protokolls wird offengelegt. Die verteilte Systemstruktur umfasst einen Adressschalter, mehrere Speichersubsysteme und mehrere Master-Geräte, entweder Prozessoren, E/A-Agenten oder kohärente Speicheradapter, die in einem Knotensatz angeordnet sind, der von einen Knoten-Controller unterstützt wird. Der Knoten- Controller empfängt Befehle von einem Master-Gerät, kommuniziert mit einem Master-Gerät als ein weiteres Master- oder als Slave-Gerät und ordnet Befehle in eine Warteschlange ein, die von einem Master-Gerät empfangen wurden. Das System ermöglicht die Implementierung eines Busprotokolls, das einem Master-Gerät über den Status einer Cachezeile, zusammen mit der ersten Datenlieferung für ein chachebares, kohärentes Lesen berichtet. Da das Erzielen von Kohärenz auf Zeit und Raum verteilt ist, betrifft das Problem der Datenintegrität eine Reihe von Aktionen. In einer Implementierung hilft der Knoten-Controller bei der Unterstützung der Cache-Kohärenz für Befehle durch Blockierung des Master-Geräts für den Empfang bestimmter Transaktionen, um gegenseitige Lesesperren zu verhindern. In einer anderen Implementierung verwenden die Master-Geräte ein Busprotokoll, das gegenseitige Lesesperren in einem verteilten Multibus-, Multiprozessorsystem verhindert.

Kurzbeschreibung der Zeichnungen

Die neuartigen Funktionen der vorliegenden Erfindung werden in den angehängten Ansprüchen weiter erklärt. Die Erfindung selbst sowie das bevorzugte Ausführungsbeispiel, weitere Ziele und Vorteile daraus werden verständlich unter Verweis auf ein anschauliches Ausführungsbeispiel und die begleitenden Zeichnungen, wobei:

Fig. 1 ein Blockdiagramm ist, das die Grundstruktur eines konventionellen Multiprozessorsystems darstellt;

Fig. 2 ein Blockdiagramm ist, das eine typische Architektur darstellt;

Fig. 3 ein Blockdiagramm ist, das ein Multiprozessorsystem mit drei Verarbeitungseinheiten darstellt,

Fig. 4 ein Blockdiagramm ist, das eine verteilte Systemstruktur für ein verteiltes Multiprozessorsystem darstellt, mit der Unterstützung eines Bus-basierten Cache- Kohärenz-Protokolls aus der Perspektive von Adresspfaden im Multiprozessorsystem;

Fig. 5 ein Blockdiagramm ist, das eine verteilte Systemstruktur für ein verteiltes Multiprozessorsystem darstellt, mit Unterstützung für ein Bus-basiertes Cache- Kohärenz-Protokoll aus der Perspektive von Datenpfaden im Multiprozessorsystem;

Fig. 6 ein Blockdiagramm ist, das die Adresspfade darstellt, die sich im Knoten-Controller befinden;

Fig. 7 ein Diagramm ist, das die internen Adresspfade eines Adressschalters zwischen Knoten-Controllern und Speichersubsystemen darstellt;

Fig. 8 ein Diagramm ist, das ein Speichersubsystem darstellt, das mit dem Adressschalter des verteilten Systems der vorliegenden Erfindung verbunden ist;

Fig. 9 ein Blockdiagramm ist, das die Datenpfade darstellt, die sich in einem Knoten-Controller befinden;

Fig. 10A-10B Blockdiagramme sind, die die Systemstruktur zum Bestimmen von Busantwortsignalen für eine verteilte Systemstruktur darstellt;

Fig. 10C-10D Blockdiagramme sind, die die Komponenten darstellen, deren Signale an den lokalen und globalen Zyklen teilnehmen;

Fig. 11 eine Tabelle ist, die die Definition der Transaktionsphasen im vorliegenden System wiedergibt;

Fig. 12A-12B Tabellen mit den von einem Knoten- Controller generierten Antworten darstellen, in Reaktion auf die Erkennung eines kollidierenden Transaktionspaares;

Fig. 13 ein Flussdiagramm ist, das einen Prozess innerhalb des Knoten-Controllers darstellt, zum Verhindern einer gegenseitigen Lesesperrbedingung zwischen Master-Geräten, die unter Einbeziehung von L1-Daten im L2-Cache arbeiten; und

Fig. 14 ein Flussdiagramm ist, das einen Prozess innerhalb des Knoten-Controllers darstellt, zum Verhindern einer gegenseitigen Lesesperrbedingung zwischen Master-Geräten, die unter Nicht-Einbeziehung von L1-Daten im L2-Cache arbeiten.

Detaillierte Beschreibung des bevorzugten Ausführungsbeispiels

In Fig. 1 wird die Grundstruktur eines konventionellen Multiprozessor-Computersystems 110 dargestellt. Das Computersystem 110 verfügt über mehrere Verarbeitungseinheiten 112a, 112b und 112c, die mit verschiedenen peripheren Geräten verbunden sind, einschließlich Eingabe/Ausgabe (E/A)-Agents 114, die mit dem Datenfluss von und zu einem Monitoradapter 102, einem Anzeigemonitor 105, einem Tastaturadapter 104, einer Tastatur 107, einem Datenträgeradapter 103, einem permanenten Speichergerät 106, Speichergerät 116 (wie etwa ein dynamischer Random Access Memory oder DRAM) befasst sind, verwendet von den Verarbeitungseinheiten, um Programmanweisungen auszuführen sowie Firmware 118, deren vornehmlicher Zweck es ist, ein Betriebssystem aus den peripheren Geräten (normalerweise dem permanenten Speichergerät) zu suchen und zu laden, sobald der Computer das erste Mal eingeschaltet ist. Die Verarbeitungseinheiten 112a-112c kommunizieren mit den peripheren Geräten mit Hilfe verschiedener Mittel, einschließlich einem Bus 120. Das Computersystem 110 kann über viele zusätzliche Komponenten verfügen, die nicht gezeigt werden, wie etwa serielle und parallele Ports zur Verbindung mit peripheren Geräten, so etwa Modems oder Drucker. Fachleuten werden weiter erkennen, dass weitere Komponenten bestehen, die in Verbindung mit denen im Blockdiagramm von Fig. 1 gezeigten Komponenten verwendet werden können, beispielsweise kann ein Anzeigeadapter eingesetzt werden, um einen Videoanzeigemonitor zu steuern, ein Speicher-Controller kann für den Zugriff auf den Speicher 116 verwendet werden, usw. Zusätzlich kann das Computersystem mit einer größeren oder geringeren Zahl von Prozessoren konfiguriert werden.

In einem symmetrischen Multiprozessor (SMP)-Computer sind all diese Verarbeitungseinheiten 112a bis 112c generell identisch, das heißt, dass sie alle einen gemeinsamen Satz oder Untersatz an Anweisungen und Protokollen verwenden, um zu arbeiten und dass sie im allgemeinen über die gleiche Architektur verfügen.

Fig. 2 zeigt eine typische Organisation. Eine Verarbeitungseinheit 112 umfasst einen Prozessor 122 mit einer Vielzahl an Registern und Ausführungseinheiten, die Programmanweisungen ausführen, um den Computer zu betreiben. Der Prozessor kann ebenfalls über Caches verfügen, etwa ein Anweisungs-Cache 124 und ein Daten-Cache 126. Diese Caches werden als eingebaut bezeichnet, wenn sie in die Register und Ausführungseinheiten des Prozessors integriert sind. Caches werden im allgemeinen verwendet, um Werte temporär zu speichern, auf die wiederholt von einem Prozessor zugegriffen wird, um die Verarbeitung zu beschleunigen, indem der länger dauernde Schritt zum Laden der Werte aus dem Hauptspeicher, wie dem Speicher 116 in Fig. 1 gezeigt, umgangen wird.

Die Verarbeitungseinheit 112 kann zusätzliche Caches umfassen, wie etwa Cache 128. Cache 128 wird als ein Level 2 (L2)-Cache bezeichnet, da es die eingebauten (Level 1)-Caches 124 und 126 unterstützt. Mit anderen Worten, Cache 128 agiert als eine Verbindung zwischen dem Speicher 116 und den eingebauten Caches und kann einen sehr viel größeren Umfang an Informationen (Anweisungen und Daten) speichern als die eingebauten Caches, wenn auch mit bei einer längeren Zugriffszeit. Beim Cache 128 beispielsweise kann es sich um einen Chip mit einer Speicherkapazität von 256 oder 512 Kilobyte handeln, während es sich bei dem Prozessor 112 um IBM PowerPC^TM der Prozessor Serie 604 handeln kann, der über eingebaute Caches mit 64 Kilobytes Gesamtspeicher verfügt. Obwohl Fig. 2 nur eine zweistufige Cache-Hierarchie darstellt, können auch mehrstufige Hierarchien geboten werden, bei denen mehrere Level seriell verbundener Caches vorhanden sind.

In einem SMP Computer ist es wichtig, ein kohärentes Speichersystem zur Verfügung zu stellen, das heißt ein Schreiben auf jedem einzelnen Speicherort zu veranlassen, das in einer bestimmten Reihenfolge für alle Prozessoren serialisiert werden muss. Es wird beispielsweise ein Ort im Speicher durch eine Schreibsequenz bearbeitet, um die Werte 1, 2, 3 und 4 zu erhalten. In einem Cache-kohärenten System überwachen alle Prozessoren die Schreibvorgänge in einem bestimmten Ort, damit diese in der gezeigten Reihenfolge stattfinden können. Es ist jedoch für ein Verarbeitungselement möglich, dass ein Schreibvorgang im Speicherort fehlt. Ein gegebenes Verarbeitungselement, das den Speicherort liest, könnte die Reihenfolge 1, 3, 4 erkennen, wobei die Aktualisierung des Wertes 2 fehlt. Ein System, das sicherstellt, dass jeder Prozessor über gültige Datenreihenfolgen verfügt, wird als kohärent bezeichnet. Es ist wichtig, dass wirklich alle Kohärenz-Protokolle nur bis zur Größe eines Cacheblocks arbeiten. Das bedeutet, dass das Kohärenzprotokoll die Bewegung der Schreibberechtigungen für Daten auf einer Cacheblockbasis und nicht separat für jeden einzelnen Speicherort steuert.

Es besteht eine Anzahl an Protokollen und Techniken zum Erreichen der Cache-Kohärenz, die den Fachleuten bekannt sein dürften. Kernstück all dieser Mechanismen zur Unterstützung der Kohärenz ist die Anforderung, dass die Protokolle jeweils nur einem einzigen Prozessor die "Berechtigung" erteilen, auf einen gegebenen Speicherort (Cacheblock) zu schreiben und das zu einem bestimmten Zeitpunkt. Als Konsequenz aus dieser Anforderung müssen bei jedem Versuch eines Verarbeitungselements, auf einen Speicherort zu schreiben, alle anderen Verarbeitungselemente von der Absicht informiert werden, auf diesen Ort zu schreiben, um den Schreibbefehl auszuführen. Hauptproblem dabei ist, dass alle anderen Prozessoren im System über den Schreibbefehl durch den auslösenden Prozessor informiert werden müssen, bevor der Schreibvorgang ausgeführt wird. Um weiterhin darzustellen, wie Cache-Kohärenz in einer mehrstufigen Hierarchie implementiert wird, siehe Fig. 3.

Fig. 3 zeigt ein Multiprozessor-Computersystem mit drei Verarbeitungseinheiten (140, 141, 142) mit Prozessoren (140a, 141a, 142a) mit jeweils einem L1-Cache (140b, 141b, 142b) und einem L2-Cache (140c, 141c, 142c) und letztlich einem L3- Cache (140d, 141d und 142d). In dieser Hierarchie ist jedes niedrigstufige Cache (das heißt, ein L3-Cache ist niedriger als ein L2-Cache) normalerweise größer in seinem Umfang und verfügt über eine längere Zugriffszeit als der Cache der nächsthöheren Stufe. Weiterhin ist es üblich, wenn auch nicht zwingend notwendig, dass die niedrigstufigen Caches Kopien aller Blöcke haben, die sich in den höherstufigen Caches befinden. Wenn sich beispielsweise im L2-Cache einer gegebenen Verarbeitungseinheit ein Block befindet, bedeutet dies auch, dass der L3-Cache dieser Verarbeitungseinheit ebenfalls über eine (potienziell nicht aktuelle) Kopie des Blocks verfügt. Wenn weiterhin ein Block im L1-Cache einer gegebenen Verarbeitungseinheit vorhanden ist, ist dieser auch in den L2- und L3-Caches dieser Verarbeitungseinheit vorhanden. Diese Eigenschaft ist als Einbeziehung bekannt und den Fachleuten vertraut. Somit wird, wenn nicht anders beschrieben, davon ausgegangen, dass die Prinzipien der Einbeziehung auf den Cache der vorliegenden Erfindung angewendet werden.

Um Cache-Kohärenz in einem System zu implementieren, wie in Fig. 3 gezeigt, kommunizieren die Prozessoren über eine übliche allgemeine Zwischenverbindung (143). Die Prozessoren geben Nachrichten über die Zwischenverbindung weiter, mit der Absicht auf Speicherorte zu schreiben oder von ihnen zu lesen. Wenn eine Operation auf der Zwischenverbindung platziert wird, suchen alle anderen Prozessoren nach dieser Operation und entscheiden darüber, ob der Status ihrer Caches die angeforderte Operation zulässt und wenn dies der Fall ist, unter welchen Bedingungen. Diese Kommunikation ist notwendig, da in Systemen mit Caches die zuletzt erstellt Kopie eines gegebenen Speicherblocks vom Systemspeicher 144 zu einem oder mehreren Caches im System bewegt worden sein kann. Wenn ein Prozessor (beispielsweise 140a) versucht, auf einen Speicherort zuzugreifen, der sich nicht in seiner Cache-Hierarchie (140b, 140c und 140d) befindet, kann sich die richtige Version des Blocks mit dem tatsächlichen Wert für den Speicherort entweder im Systemspeicher 144 oder in einem der Caches in den Verarbeitungseinheiten 141 und 142 befinden. Wenn sich die richtige Version in einem der anderen Caches im System befindet, muss der richtige Wert dem Cache im System anstatt dem Systemspeicher entnommen werden. Der Prozessor 140a beispielsweise versucht, einen Ort im Speicher zu lesen. Er durchsucht zunächst seinen eigenen L1- Cache (140b). Wenn der Block im L1-Cache (140b) nicht vorhanden ist, wird die Anforderung zum L2-Cache (140c) weitergeleitet. Wenn sich der Block nicht im L2-Cache befindet, wird die Anforderung an den L3-Cache (140d) weitergeleitet. Wenn sich der Block nicht im L3-Cache (140d) befindet, wird die Anforderung an die allgemeine Zwischenverbindung (143) zur Weiterverarbeitung gegeben. Sobald eine Operation auf der allgemeinen Zwischenverbindung platziert wurde, suchen (suchen) alle anderen Prozessoren nach der Operation und ermitteln, ob sich der Block in ihren Caches befindet. Wenn eine gegebene Verarbeitungseinheit, beispielsweise 142, über den von der Verarbeitungseinheit 140 angeforderten Datenblock in ihrem L1-Cache (142a) verfügt und die Daten nach dem Prinzip der Einbeziehung bearbeitet werden, verfügen auch der L2-Cache (142c) und der L3-Cache (142d) über Kopien des Blocks. Wenn daher der L3-Cache (142d) der Verarbeitungseinheit 142 nach der Leseoperation sucht, wird festgestellt, dass der angeforderte Block vorhanden ist und im L3-Cache (142d) bearbeitet wurde. Wenn dies stattfindet, kann der L3-Cache (142d) eine Nachricht auf der allgemeinen Zwischenverbindung platzieren, um die Verarbeitungseinheit 140 darüber zu informieren, dass sie ihre Operation zu einem späteren Zeitpunkt wiederholen muss, da sich der neueste aktualisierte Wert des Speicherorts für die Leseoperation im L3-Cache (142d) befindet, der sich außerhalb des Hauptspeichers 144 befindet, und dass Aktionen unternommen werden müssen, damit dieser Wert für die Ausführung der Leseanforderung der Verarbeitungseinheit 140 zur Verfügung steht.

Das L3-Cache (142d) kann einen Prozess zum Schieben der bearbeiteten Daten vom L3-Cache zum Hauptspeicher 144 beginnen. Der neueste aktualisierte Wert für den Speicherort wird damit den anderen Prozessoren zur Verfügung gestellt. Alternativ dazu kann der L3-Cache (142d) in einem Prozess namens "Intervention" den neuesten aktualisierten Wert für den Speicherort direkt an die Verarbeitungseinheit 140 senden, die diesen angefordert hat. Der L3-Cache kann dann einen Prozess starten, um die bearbeiteten Daten vom L3-Cache zum Hauptspeicher zu verschieben.

Die Verarbeitungseinheit 140, d. h. ihr L3-Cache (140d), stellt die Leseanforderung auf der allgemeinen Zwischenverbindung dar. An diesem Punkt jedoch wurden die bearbeiteten Daten vom L1-Cache der Verarbeitungseinheit 142 abgerufen und die Leseanforderung vom Prozessor 140 wird somit erfüllt. Das gerade beschriebene Szenario wird im allgemeinen als "Snoop Push" bezeichnet. Es wird nach einer Leseanforderung auf der allgemeinen Zwischenverbindung gesucht, die die Verarbeitungseinheit 142 veranlasst, den Block an das Ende der Hierarchie zu verschieben, um die von der Verarbeitungseinheit 140 gemachte Leseanforderung zu erfüllen.

Der Hauptpunkt ist der, dass bei einer Anforderung durch einen Prozessor zum Lesen oder Schreiben auf einem Block diese Anforderung an die anderen Verarbeitungseinheiten im System weitergegeben werden muss, damit die Cache-Kohärenz gewahrt bleibt. Um dies zu erreichen, weist das Cache- Kohärenz-Protokoll mit jedem Block auf jeder Stufe der Cache- Hierarchie einen Status-Indikator zu, der den aktuellen Status des Blocks wiedergibt. Die Statusinformationen werden verwendet, um bestimmte Optimierungen im Kohärenz-Protokoll zu ermöglichen, damit sich der Nachrichtenverkehr auf der allgemeinen Zwischenverbindung 143 sowie der Umfang der Cache-Verbindungen untereinander 140x, 14y, 141x, 141y, 142x, 142y verringern. Als ein Beispiel dieses Mechanismus bei der Ausführung eines Lesevorgangs durch eine Verarbeitungseinheit, erhält diese eine Nachricht darüber, ob der Lesevorgang zu einem späteren Zeitpunkt wiederholt werden muss. Wenn die Leseoperation nicht wiederholt wird, enthält die Nachricht normalerweise Informationen, die es der Verarbeitungseinheit ermöglichen, zu ermitteln, ob eine andere Verarbeitungseinheit über eine aktive Kopie des Blocks verfügt (dies wird ebenfalls ausgeführt, indem den anderen Niedrigst-Stufen Caches eine geteilte oder ungeteilte Indikation gegeben wird für jeden Lesevorgang, der nicht wiederholt wird).

Auf diese Wiese kann eine Verarbeitungseinheit bestimmen, ob ein anderer Prozessor im System über eine Kopie des Blocks verfügt. Wenn keine andere Verarbeitungseinheit über eine aktive Kopie des Blocks verfügt, markiert die lesende Verarbeitungseinheit den Status des Blocks als "exklusiv". Wenn ein Block als "exklusiv" markiert wird, kann die Verarbeitungseinheit die Erlaubnis erhalten, zu einem späteren Zeitpunkt auf den Block zu schreiben, ohne dass zuvor mit anderen Verarbeitungseinheiten im System ein Austausch stattfinden muss, da keine andere Verarbeitungseinheit über eine Kopie des Blocks verfügt. Es ist daher im allgemeinen für einen Prozessor möglich, auf einen Ort zu schreiben oder von ihm zu lesen, ohne zuvor diese Absicht auf die Zwischenverbindung zu schreiben. Dies tritt jedoch nur in Fällen auf, in denen das Kohärenz- Protokoll sichergestellt hat, dass kein anderer Prozessor an dem Block beteiligt ist. Mehrere Details des exakten Vorgehens eines mehrstufigen Cache-Kohärenz-Protokolls wurden in dieser Beschreibung ausgelassen, um diese zu vereinfachen. Die wesentlichen Aspekte für diese Erfindung wurden jedoch beschrieben. Diejenigen Aspekte, die Bestandteil der Erfindung sind, wurden beschrieben. Die nicht beschriebenen Aspekte sind den Fachleuten bekannt. Ein anderer Aspekt mehrstufiger Cache-Strukturen, der für die Erfindung wichtig ist, sind die Operationen, die als Freigaben bezeichnet werden. Die Blöcke in jedem Cache werden unterteilt in Blockgruppen namens Sätze. Ein Satz bezeichnet eine Sammlung von Blöcken, in denen sich ein gegebener Speicherblock befinden kann. Für jeden gegebenen Speicherblock besteht ein eindeutiger Satz im Cache, auf den der Block abgestimmt werden kann, entsprechend den voreingestellten Abstimmungsfunktionen. Die Anzahl der Blöcke in einem Satz wird als Assoziativität des Cache bezeichnet (beispielsweise eine 2-Wege-Satz-Assoziativität bedeutet für einen gegebenen Block, dass sich zwei Blöcke im Cache befinden, auf den der Speicherblock abgestimmt werden kann). Es können jedoch mehrere verschiedene Blöcke im Hauptspeicher in jedem beliebigen Satz gesetzt werden.

Wenn alle Blöcke in einem Satz für einen gegebenen Cache voll sind und dieser Cache eine Anforderung erhält, ob nun zum Lesen oder Schreiben, für einen Speicherort, der sich im vollen Satz befindet, muss der Cache einen der Blocks freigeben, der sich derzeit im Satz befindet. Der Cache wählt einen Block aus, der von einem der zahlreichen Mittel ausgeschlossen wird, die den Fachleuten bekannt sein dürften (zumindest das kürzlich eingesetzte (LRU); Random, Pseudo-LRU usw.) Wenn die Daten im ausgewählten Block bearbeitet werden, werden diese Daten auf die nächstniedrigere Stufe in der Speicher-Hierarchie geschrieben, bei der es sich um ein weiteres Cache handelt (im Falle des L1 oder L2-Cache). Es ist zu beachten, dass nach den Prinzipien der Einbeziehung die niedrigere Stufe der Hierarchie bereits über einen Block verfügt, auf den die in den Schritten bearbeiteten Daten festgehalten werden können. Wenn jedoch die Daten im ausgewählten Block nicht bearbeitet werden, wird der Block einfach verlassen und nicht in die niedrigste Stufe der Hierarchie geschrieben. Dieser Prozess des Entfernens eines Blocks von einer Stufe der Hierarchie wird als Ausschluss ("eviction") bezeichnet. Am Ende dieses Prozesses umfasst der Cache nicht länger eine Kopie des ausgeschlossenen Blocks und nimmt auch nicht länger aktiv am Kohärenz-Protokoll für den ausgeschlossenen Block teil, da beim Suchen des Caches nach einer Operation (entweder auf der allgemeinen Zwischenverbindung 143 oder zwischen den Cache-Verbindungen 140x, 141x, 142x, 140y, 141y, 142y) der Block nicht auffindbar ist.

Die vorliegende Erfindung legt eine verteilte Hardware- Struktur offen, um die Beschränkungen durch einen einzelnen gemeinsamen Busses in einem Multiprozessorsystem zu überwinden, unter Verwendung der Eigenschaften des Einzelbusses auf die Art, dass keine Bearbeitung des Busprotokolls notwendig wird. Das sich ergebende System verfügt über eine skalierbare Systemgröße, ohne dass Kompromisse beim Mechanismus des bekannten Systembusses eingegangen werden. Die vorliegende Erfindung ist in der Lage, eine große Zahl von Geräten miteinander in einem verteilten, Multibus- und Multiprozessorsystem zu verbinden und die Beschränkungen durch eine Einzelbus-basierte Gestaltung zu überwinden.

Obwohl die folgende Beschreibung die Erfindung unter Berücksichtigung der 6XX-Busarchitektur erklärt, ist die vorliegende Erfindung nicht auf eine bestimmte Busarchitektur beschränkt, da das unten aufgeführte System auch auf andere Busarchitekturen angewendet werden kann.

Systemadresspfad-Topologie

Fig. 4 ist ein Blockdiagramm, das eine verteilte Systemstruktur für ein Multiprozessorsystem zeigt, mit Unterstützung eines Bus-basierten Cache-Kohärenz-Protokolls aus der Perspektive von Adresspfaden innerhalb des Multiprozessorsystems. Fig. 4 zeigt eine Anzahl an Master- Geräten, die einen Befehl geben können, wie etwa eine Speichertransaktion. Diese Master-Geräte, wie Prozessoren, E/A-Agents und kohärente Speicheradapter, - werden in Cluster unter einer Vielzahl an N Gruppen, Knoten genannt, verteilt. Jedem Knoten geht ein Knoten-Controller voraus, mit dem die Master verbunden sind.

Fig. 4 zeigt die Knoten 410 und 420, die Gruppierungen von Systemelementen umfassen. Die Anzahl der Knoten je nach Systemkonfiguration variieren. Der Knoten 410, auch als Knoten₀ bezeichnet, enthält die Prozessoren 411 und 412, auch als Prozessor₀ und als ProzessorP_P-1 bezeichnet, die die Master für den Knoten 410 sind. Jeder Knoten-Controller verfügt über mehrere standardmäßige bidirektionale Adressdatenbusse für Prozessoren, über die die Master mit dem verteilten System verbunden sind. Die Prozessoren 411 und 412 sind mit dem Knoten-Controller 415, der auch als Knoten-Controller NC₀ bezeichnet wird, über die Busse 413 und 414 verbunden, die auch entsprechend als P₀Bus und P_P-1Bus bezeichnet werden. Der Knoten 420, auch Knoten_N-1 genannt, umfasst den Prozessor 421 und E/A-Agent 422, die die Master für den Knoten 420 sind. Der Prozessor 421 und das E/A-Gerät 422 sind mit dem Knoten- Controller 425, auch als Knoten-Controller NC_N-1 bezeichnet, entsprechend über die Busse 423 und 424 verbunden. Die Anzahl an Mastern kann variieren, entsprechend der Konfiguration des Systems und die Anzahl der Master an jedem Knoten muss nicht an allen Knoten des Systems gleich sein.

Der Knoten-Controller bildet die physische Schnittstelle zwischen einem Master und dem Rest des Systems, und jeder Knoten-Controller im System umfasst die gesamte notwendige Logik, um über einzelne Prozessorbusse zu entscheiden und um mit den lokalen Mastern als ein weiterer Master oder Slave, d. h. als ein Gerät, das Masterbefehle akzeptiert und ausführt, jedoch keine Masterbefehle generiert, zu kommunizieren. Ein Prozessor sendet über seinen lokalen Knoten-Controller einen Befehl in das System. Obwohl Fig. 4 einen Master pro Port anzeigt, sind bei einem gegebenen Entscheidungsschema für den Bus des Ports auch mehrere Master pro Port möglich. Der Prozessor 411 beispielsweise könnte einer von vielen Prozessoren sein, die mit dem Bus 413 verbunden sind. Wenn jedoch mehrere Prozessoren mit einem einzelnen Port verbunden sind, arbeitet deren Adressbus in der Buszykluszeit langsamer.

Alternativ dazu kann einer der Master des Knoten 420 einen kohärenten Speicheradapter umfassen, der Kommunikation mit einem anderen Datenverarbeitungssystem zur Verfügung stellt, das Cache-Kohärenz bietet. Der kohärente Speicheradapter kann nah oder entfernt arbeiten und einen Port eines Knoten- Controllers belegen, um Speichertransaktionen zu senden und zu empfangen, um wie ein Master/Slave-Gerät auf ähnlich Weise wie ein E/A-Agent zu arbeiten. Als ein Beispiel kann ein anderer Knoten-Controller von einem anderen Datenverarbeitungssystem mit dem kohärenten Speicheradapter verbunden sein, so dass Datenverarbeitungssysteme, die mit der vorliegenden Erfindung arbeiten, miteinander verknüpft werden können.

Die Knoten-Controller 415 und 425 sind über Paare aus unidirektionalen Nur-Adressbussen mit einem Gerät verbunden, das als Adressschalter (ASX) bezeichnet wird. Die Busse 416 und 417, auch als AOut₀ und AIn₀ bezeichnet, verbinden den Knoten-Controller 415 mit dem Adressschalter 430. Die Busse 426 und 427, auch als AOut_N-1 und AIn_N-1 bezeichnet, verbinden den Knoten-Controller 425 mit dem Adressschalter 430. Wie gezeigt, befördern die Busse AOut_X Adressen von den Knoten- Controllern zum Adressschalter, und die Busse AIn_X befördern Adressen vom Adressschalter zu den Knoten-Controllern. Der Adressschalter 430 verfügt über zusätzliche unidirektionale Busverbindungen 431 und 432, auch als AIn_N und AIn_(N+S+1) bezeichnet, zu den Speicher-Controllern oder Speichersubsystemen 442 und 444, auch als Speichersubsystem MS₀ und MS_S-1 bezeichnet. Die Speicher-Controller werden als Slave-Geräte vorausgesetzt und verfügen nicht über die Fähigkeit, im verteilten System Befehle auszugeben. Die Anzahl an Speichersubsystemen kann je nach Konfiguration des Systems variieren.

Systemdatenpfad-Topologie

Fig. 5 zeigt ein Blockdiagramm mit einer verteilten Systemstruktur für ein verteiltes Multiprozessor-System mit Unterstützung Bus-basierter Cache-Kohärenz-Protokolle aus der Perspektive von Datenpfaden innerhalb des Multiprozessorsystems. Auf ähnliche Weise wie in Fig. 4 zeigt Fig. 5 eine Anzahl an Master-Geräten an. Diese Master- Geräte werden in Clustern unter einer Reihe von N Gruppen verteilt, die als Knoten bezeichnet werden. Jedem Knoten geht ein Knoten-Controller voraus, mit dem der Master verbunden ist. Fig. 5 zeigt die Knoten 510 und 520 mit den Prozessoren 511 und 512. Die Prozessoren 511 und 512 sind mit dem Knoten- Controller 515 über die Busse 513 und 514 verbunden. Der Knoten 520, auch als Knoten_N-1 bezeichnet, umfasst den Prozessor 521 und das E/A-Gerät 522, das mit dem Knoten- Controller 525, auch als Knoten-Controller NC_N-1 bezeichnet, entsprechend über die Busse 523 und 524 verbunden ist. Die Knoten-Controller in Fig. 4 und Fig. 5 könnten physikalisch gesehen die gleichen Systemkomponenten darstellen, werden jedoch aus unterschiedlichen Perspektiven beschrieben, um die unterschiedlichen Funktionen zu zeigen, die von den Knoten-Controllern ausgeführt werden. Während die Fig. 4 Adresspfade im Multiprozessorsystem darstellt, zeigt die Fig. 5 die Datenpfade im Multiprozessorsystem. Alternativ dazu können die Adress- und Datenpfade in einem bevorzugten Ausführungsbeispiel implementiert werden, mit Unterstützungsfunktionen in physisch separaten Komponenten, Chips oder Kreisläufen, wie etwa ein Knotendaten-Controller oder ein Knotenadress-Controller. Die Entscheidung, einen Knoten-Controller mit separaten oder kombinierten Daten- und Adressfunktionen zu implementieren, kann von den Parametern anderer Systemkomponenten abhängen. Wenn beispielsweise die Größen der Busse, die im System unterstützt werden, klein genug sind, werden sowohl Adress- als auch Datenfunktionen in eine einzelne Knoten-Controller-Komponente gestellt. Wenn die Busse jedoch 128 Datenbits unterstützen, können Pinbegrenzungen es physisch erforderlich machen, die Adress- und Datenfunktionen in separate Knoten-Controller-Komponenten zu stellen.

Alternativ dazu kann ein separater Knotendaten-Controller weiter in mehrere Knotendaten-Controller pro Knoten unterteilt werden, so dass jeder Knotendaten-Controller Unterstützung für einen Teil des Datenpfades des Knotens bieten kann. Auf diese Wiese wird der Datenpfad des Knotens in mehrere Knotendaten-Controller aufgesplittet.

In Fig. 5 wird jeder Knoten-Controller mit Verbindungen zu mehreren Speicher-Controllern gezeigt, wie etwa zu den Speichersubsystemen MS₀ und MS_S-1. Obwohl jeder Knoten- Controller so gezeigt wird, dass er mit jedem Speicher- Controller über einen unabhängigen Datenbus verbunden werden kann, können mehrere Knoten und/oder mehrere Speicher- Controller mit dem gleichen Datenbus verbunden werden, wenn ein entsprechender Entscheidungsmechanismus vorhanden ist. Mit Verbinden einer Vielzahl an Master-Geräten mit einem einzelnen Knoten-Controller über einen einzelnen Bus entspricht die Schaltrate der Anzahl an Geräten, die mit dem Bus verbunden sind. Der Knoten-Controller 515 verbindet ein Speichersubsystem 542 über einen Datenbus 516 und mit einem Speichersubsystem 544 über den Bus 517, auch als N₀D₀ und N₀D_S- ₁ bezeichnet. Der Knoten-Controller 525 ist mit einem Speichersubsystem 544 über einen Datenbus 527 und mit einem Speichersubsystem 542 über einen Datenbus 526 verbunden, auch als N_N-1D₀ und N_N-1D_S-1 bezeichnet.

Anstelle eines einzelnen Busses, der Daten weiterleitet, die zu allen Masters gehören, bestehen mehrere Datenbusse, die jeweils nur über einen kleinen Teil des Datenverkehrs verfügen, der ausgeführt würde, wenn die Masters mit einem einzelnen Bus verbunden wären. Dadurch können die Komponenten-Schnittstellen mit schnelleren Takten versehen werden, als es bei einem einzelnen Bus möglich wäre. Diese Konfiguration ermöglicht die Zuordnung mehrerer Datenbusbandbreiten pro Master, als es mit einem einzelnen Bus möglich wäre, was wiederum zu geringeren Warteschlangenzeiten führt.

Interne Adresspfade des Knoten-Controllers

Fig. 6 zeigt ein Blockdiagramm mit den Adresspfaden in einem Knoten-Controller. Der Knoten-Controller 600, auch als NC_X bezeichnet, ähnelt den Knoten-Controllern 415 und 425 in Fig. 4 oder den Knoten-Controllern 515 und 525 in Fig. 5. Einzelne Ports des Knoten-Controllers 600 verfügen über ihre eigenen Warteschlangen, um Befehle von den Masters zu puffern, wenn diese Befehle in den Knoten-Controller eingehen. Ein Befehl kann nicht bestimmende Verzögerungen verursachen, während sie in diesen Puffern auf eine progressive Auswahl für den Adressschalter warten. Der Knoten-Controller 600 verfügt über bidirektionale Busse 601 bis 604, die mit den Master-Geräten verbunden sind. Die Busse 601 bis 604 sind verbunden über Bustransceiver 605 bis 608 mit den Input-Grenz-Latches 609 bis 612 und mit den Output-Grenz-Latches 613 bis 616 verbunden. Die Input-Grenz- Latches 609 bis 612 versorgen die Puffer 617 bis 620, in denen sich die Befehle von den Master-Geräten befinden. Ein Befehl von einem Master-Gerät kann aus einem Transaktions- Tag, einem Transaktionstyp, einer Ziel- oder Quelladresse und anderen, ähnlichen Informationen bestehen. Die Puffer 617 bis 620 können alle Informationen beinhalten, die mit einem Befehl verbunden sind, oder alternativ dazu nur die Informationen umfassen, die für die Funktion des Adresspfades im Knoten-Controller notwendig sind. Die Informationen in den Inputpuffern können variieren, je nach den unterschiedlichen Konfigurationen eines Knoten-Controllers. Die Puffer 617 bis 620 versorgen eine Steuereinheit (bzw. Multiplexer) 621, die jeweils einen Befehl auswählt, welcher an den Adressschalter über das Latch 622, Transmitter 623 und den Bus 624, auch AOut_X genannt, gesendet wird.

Der Knoten-Controller 600 empfängt Befehle über die Busse 601 bis 604 von den Masters für eine mögliche Weiterleitung über das Grenz-Latch 622 und den Transmitter 623 an den Adressschalter über den Bus 624, auch AOut_X genannt. Auf gleiche Weise akzeptiert der Knoten-Controller 600 Befehle vom Adressschalter über den Bus 625, auch AIn_X genannt und den Receiver 626 zur Erfassung in Grenz-Latch 627, auch FROM_ASX_BL genannt. Diese Befehle folgen einem Adresspfad und passieren eine feste Anzahl an Grenz-Latches mit einem festen Zeitraum, wie etwa ein Zwischen-Latch 628 und Output- Grenz-Latches 613-616, bevor die Busse 601-604 erreicht werden. Zusätzlich dazu passieren die Befehle an die Master- Geräte einen Multiplexer pro Port, wie etwa Steuereinheiten/Multiplexer 629-632, die ebenfalls über einen festen Zeitraum verfügen. Auf diese Weise passieren Befehle, die über einen Bus 625 ankommen, einen Pfad mit einem festen Zeitraum in einer bestimmenden Anzahl an Zyklen entlang des Pfades. Mit anderen Worten, es entsteht eine feste Zeitperiode zwischen dem Punkt, an dem ein Befehl den Latch FROM_ASX_BL erreicht, bis zu dem Punkt, an dem jedem Master- Gerät, wie etwa einem Satz Prozessoren, verbunden mit dem Knoten-Controller, ein ankommender Befehl präsentiert wird. Die Schiedsrichter für die mit den Master-Geräten verbundenen Ports wurden so entwickelt, dass sie die höchste Priorität an die Knoten-Controller vergeben, die die Portbusse steuern. Wenn ein Master-Gerät eine Anforderung ausführt, um einen Bus zur gleichen Zeit zu steuern, zu der ein Knoten-Controller ihn steuern würde, wird dem Knoten-Controller höhere Priorität eingeräumt. In einem bevorzugtem Ausführungsbeispiel wird zur Unterstützung dieses Schiedsrichter-Szenario ein Signal namens "SnoopValid" (nicht gezeigt) durch den Adressschalter geltend gemacht, der sich vor dem Befehl befindet, der vom Adressschalter gesendet wurde. Dadurch kann die Entscheidung über den Buszugriff zwischen einem Knoten-Controller und seinen Master-Geräten früh genug ausgeführt werden, um sicherzustellen, dass ein Befehl, der vom Adressschalter über den Bus AIn_X ankommt, keinen Zyklus blockiert, während er sich im Knoten-Controller befindet. Dadurch wird garantiert, dass die Zeitperiode für die feste Anzahl an Latches entlang der AIn_X-zu-P_X-Buspfade auf eine bestimmende Anzahl an Zyklen aufgelöst wird. Die Steuerlogikeinheit 633 wird ebenfalls mit dem eingehenden Befehl dargestellt, eingegeben in den Latch FROM_ASX_BL für eine entsprechende Bestimmung der Steuersignale für andere Einheiten oder Komponenten im Knoten-Controller 600. Die Steuerlogikeinheit 633 beispielsweise kommuniziert mit den Puffern 617-620 über Steuersignale 634, Steuereinheit /Multiplexer 621 über Steuersignale 636 und die Steuereinheiten/Multiplexer 629-632 über die Steuersignale 635, um Befehle auszuwählen, Kollisionen aufzulösen und Befehlsfelder zu ändern, einschließlich eines Befehlstyps, falls notwendig, um den kontinuierlichen Befehlsfluss innerhalb von Knoten-Controller 600 zu gewährleisten. Die Steuerlogikeinheit 633 empfängt ebenfalls weitere Signale 637, falls notwendig.

Interne Adresspfade im Adressschalter

Fig. 7 zeigt ein Diagramm mit den internen Adresspfaden eines Adressschalters, der Knoten-Controller und Speichersubsysteme verbindet. Der Adressschalter 700 verbindet einen Satz mit vier Knoten-Controllern und zwei Speichersubsystemen. Befehle kommen in den Warteschlangen First-In-First-Out (FIFO) 721-724 von den Bussen 701-704, auch AOut₀-AOut₃ genannt, über die Empfänger 709-712 und Input-Grenz-Latches 713-716 an. Diese Befehle können sich in einem FIFO befinden, bevor sie von der Steuereinheit/Multiplexer 725 ausgewählt werden. Ein Befehl kann eine finite, aber nicht bestimmende Zahl an Zyklen durchlaufen, während er sich im FIFO befindet. Die Steuerlogikeinheit 726 empfängt ebenfalls andere Steuersignale 733, falls notwendig.

Die Steuereinheit/Multiplexer 725 wählt einen Befehl zu einem Zeitpunkt aus, zu dem er an die Knoten-Controller und Speichersubsysteme über Pfade gesendet werden soll, die hinsichtlich der Anzahl an Zyklen bestimmend sind. Im Beispiel, das in Fig. 7 gezeigt wird, werden Befehle an die Speichersubsysteme über unidirektionale Busse 731 und 732, auch AIn₄ und AIn₅ genannt, über Output-Grenz-Latches 717-720 und Transmitter 741-744 gesendet. In diesem Beispiel gibt es nur einen einzelnen Zyklus an den Output-Grenz-Latches 717- 720, 727 und 728.

Bei den Beschreibungen für die Fig. 4 bis 7 sollte es klar sein, dass eine Transaktion durch ein Master-Gerät über dessen Bus und Port an seinen Knoten-Controller ausgegeben wird. Der Knoten-Controller bietet eine Art von sofortiger Antwort zum Master-Gerät über den Bus und kann die Transaktion für eine spätere Ausgabe an das restliche System in die Warteschlange stellen. Sobald die Transaktion an das restliche System ausgegeben wurde, stellt der Adressschalter sicher, dass die Transaktion an das restliche System mit einer bekannten Verbreitungszeit gesendet werden kann, so dass die anderen Geräte nach der Transaktion suchen können. Entsprechend der verteilten Systemstruktur der vorliegenden Erfindung wäre jedes der Geräte im System in der Lage, die Transaktion im gleichen Zyklus zu sehen und eine Kohärenz- Antwort im gleichen Zyklus zu geben. Der Adressschalter ist in der Lage, eine Transaktion an alle Knoten-Controller zu senden, einschließlich des Knoten-Controllers des Knotens, der das Gerät enthält, das die Transaktion ausgegeben hat. Die entsprechende Logik wird in jedem Knoten-Controller eingebettet, so dass ein Knoten-Controller ermitteln kann, ob die eingehende Transaktion, nach der gesucht wird, ursprünglich von einem Gerät seiner Ports ausgegeben wurde. Wenn dies der Fall ist, stellt der Knoten-Controller sicher, dass der Bus an dem Port, der die Transaktion ausgegeben hat, nicht für eine Transaktion gesucht wird, die von diesem Port empfangen wurde. Andernfalls wird das Gerät irregeführt, da er nach seiner eigenen Transaktion durchsucht wird. Wenn das Gerät eine Suche der eigenen Transaktion empfängt, kann das Gerät eine Antwort ausgeben, die auf eine Kollision mit der ursprünglichen Transaktion hinweist. Sollte dies der Fall sein, da die ursprüngliche Transaktion tatsächlich die Transaktion ist, nach der gesucht wird, wird die "Kollision" nie aufgelöst und die Transaktion wird nie beendet. Weitere Details zur Art, in der Transaktionen ausgegeben und ausgeführt werden, werden im folgenden gegeben.

Interne Adresspfade des Speichersubsystems

Fig. 8 zeigt ein Diagramm eines Speichersubsystems, das mit dem Adressschalter des verteilten Systems der vorliegenden Erfindung verbunden ist. Fig. 8 zeigt ein Speichersubsystem 800, auch Speichersubsystem MS_X genannt. Der Speicher- Controller 801 im Speichersubsystem 800 empfängt einen Befehl vom Adressschalter über einen unidirektionalen Bus 802, auch AIn_X genannt, über eine Anzahl an Latches FD 803, die einfach eine feste Zeitfolge darstellen. Auf diese Weise passiert ein Befehl, der von dem Adressschalter gesendet wird, eine feste Anzahl an Zyklen, bevor dieser Befehl dem Speicher-Controller zur Verfügung steht.

Wie zuvor gezeigt, passiert ein Befehl, der an einem Knoten- Controller über den Bus AIn_X ankommt, einen bestimmenden Zykluspfad, von seiner Erfassung im Latch FROM_ASX_BL bis zu seiner Ausgabe an ein Master-Gerät. Auf ähnliche Weise passiert ein Befehl einen bestimmenden Zykluspfad von der Steuereinheit/Multiplexer im Adressschalter zur festen Zeitfolge innerhalb des Speichersubsystems. Wenn der Zeitraum der Latches FD 803 innerhalb des Speichersubsystems an den entsprechenden Wert angepasst wurde, kann sichergestellt werden, dass dem Speicher-Controller zum gleichen Zeitpunkt ein Befehl zugeht, zu dem die Master-Geräte, die mit den Ports verbunden sind, den gleichen Befehl empfangen. Somit besteht eine bestimmende Anzahl an Zyklen zwischen dem Punkt, an dem die Steuereinheit/Multiplexer im Adressschalter eine Transaktion sendet und dem Punkt, an dem die Master-Geräte und Speicher-Controller den Befehl empfangen.

Da nur eine geringe Anzahl an Master-Geräten mit jedem Port eines Knoten-Controllers verbünden ist, ist die Geschwindigkeit, mit der jeder Bus mit diesen Port verbunden ist, unabhängig von der Gesamtzahl an Ports im System. Wenn beispielsweise ein einzelnes Master-Gerät mit jedem Port verbunden ist, kann der Bus in einem Punkt-zu-Punkt-Modus in der bestmöglichen Geschwindigkeit ausgeführt werden. Daher ist die verteilte Struktur der vorliegenden Erfindung in der Lage, bekannte und einfacher zu prüfende, Bus-basierte Cache- Kohärenz-Protokolle für Multiprozessoren zu skalieren, um die Bandbreite des Systems zu erweitern.

Interne Datenpfade im Knoten-Controller

Fig. 9 zeigt ein Blockdiagramm der Datenpfade in einem Knoten-Controller. Der Knoten-Controller 900, auch NC_X genannt, ähnelt den Knoten-Controllern 415 und 425 in Fig. 4 oder den Knoten-Controllern 515 und 525 in Fig. 5. Die einzelnen Ports des Knoten-Controllers 900 verfügen über eigene Warteschlangen, um Daten von Master-Geräten zu puffern, wenn Daten in den Knoten-Controller eingehen. Daten können nicht bestimmende Verzögerungen mit sich bringen, während sie in diesen Pufffern auf eine progressive Verschiebung zu den Zielorten hin warten.

Der Knoten-Controller 900 verfügt über bidirektionale Busse 901 bis 904, auch P_XBus genannt, die die Verbindung mit dem Master-Gerät herstellen. Die Busse 901 bis 904 verbinden mit den Input-Grenz-Latches 909 bis 912 und mit den Output-Grenz- Latches 913 bis 916 über Bus-Transceiver 905 bis 908. Input- Grenz-Latches 909 bis 912 versorgen die Datenpuffer 917 bis 920, die die Daten der Master-Geräte enthalten. Eingehende Daten aus einem der Ports des Knoten-Controllers können an ein Speichersubsystem oder ein anderes Cache geleitet werden. In dem in Fig. 9 gezeigten Beispiel, einer Weiterführung des Beispiels aus Fig. 6, können eingehende Daten von einem der Ports des Knoten-Controllers zu einem von drei Standorten geleitet werden: zum Speichersubsystem MS₀, zum Speichersubsystem MS_S-1 oder zu einem Cache-zu-Cache FIFO (FIFO C2C) zum Weiterleiten von Daten innerhalb des Knotens. Mit dem FIFO C2C-Mechnanismus ist jeder Knoten in der Lage, Daten von einem seiner Ports an einen anderen Port weiterzugeben, und dabei den Transfer von Daten von einem Master-Gerät zu einen anderen zu ermöglichen. Die Puffer 917 bis 920 versorgen die Multiplexer 925 bis 927, die eine Datenquelle zum Weitergeben von Daten auswählen. Die Steuerlogikeinheit 939 bietet Steuersignale für Multiplexer 925, um Daten auszuwählen, die an das Speichersubsystem MS₀ gesendet werden sollen sowie für Multiplexer 926, um Daten auszuwählen, die an das Speichersubsystem MS_S-1 gesendet werden sollen. Der Knoten-Controller 900 sendet Daten von den Multiplexern 925 und 926 über Grenz-Latches 931 und 933 und die Transceiver 935 und 936 an das Speichersubsystem MS₀ sowie an das Speichersubsystem MS_S-1 über bidirektionale Busse 937 und 938, auch N_XD₀ und N_XD_S-1 genannt. Die Steuerlogikeinheit 939 bietet Steuersignale für Multiplexer 927, um Daten auszuwählen, die innerhalb des Knotens weitergegeben werden sollen. Die Daten werden dann in FIFO 928 in die Warteschlange gestellt.

Auf ähnliche Weise akzeptiert der Knoten-Controller 900 Daten über die Transceiver 935 und 936 sowie die Grenz-Latches 932 und 934 vom Speichersubsystem MS₀ und Speichersubsystem MS_S-1 über bidirektionale Busse 937 und 938. Die Daten werden in eine Warteschlange in den entsprechenden FIFOs 929 und 930 gestellt. Die Daten aus den FIFOs 928 bis 930 passieren dann einen Multiplexer pro Port, wie etwa Steuereinheiten/Multiplexer 921 bis 924. Die Steuerlogikeinheit 939 bietet Steuersignale für die Multiplexer 921 bis 924, um Daten auszuwählen, die an die Master-Geräte gesendet werden sollen. Die Steuerlogikeinheit 939 empfängt ebenfalls andere Steuersignale 940, falls vorhanden. Somit verfügt der Knoten-Controller über Entscheidungslogik für Datenbusse und genügt sich hinsichtlich der Steuerung der parallelen Datentransfers selbst. Auf diese Weise ist die verteilte Systemstruktur der vorliegenden Erfindung in der Lage, den Systemdatendurchsatz zu optimieren.

Antwortkombinationsblock (Response Combination Block = RCB)

Die Fig. 10A und 10B zeigen Blockdiagramme der Systemstruktur zur Bestimmung der Busantwortsignale für eine verteilte Systemstruktur, ähnlich der in Fig. 4 und Fig. 5 gezeigten. Die Fig. 10A und 10B zeigen die Konnektivität von Geräten in der verteilten Systemstruktur der vorliegenden Erfindung mit einem Steuerlogikblock zum Kombinieren der Bussignale (Antworten) AStat und AResp. Aus Gründen der Übersichtlichkeit wurden die Signale AStat und die AResp separat dargestellt. Es wird nochmals darauf hingewiesen, dass E/A Agents als Master-Geräte eingesetzt werden können, die mit den Ports der Knoten-Controller in den Fig. 10A und 10B verbunden werden können.

Wie in Fig. 10A gezeigt, verfügen die Prozessoren 1001 bis 1004, auch als P_X bezeichnet, über unidirektionale AStatOut Signale 1005 bis 1008, auch als P_XN_XAStatOut bezeichnet, sowie über AStatIn Signale 1009 bis 1012, auch als P_XN_XAStatIn bezeichnet, die eine Verbindung zwischen den Prozessoren und dem Antwortkombinationsblock (RCB) 1000 herstellen. Die Slave-Geräte, wie etwa die Speichersubsysteme 1005 und 1006, auch MS_X genannt, verbinden über AStatOut Signale 1013 und 1014, auch M_XAStatOut genannt, sowie über die AStatIn Signale 1015 und 1016, auch M_X_AStatIn genannt, mit dem RCB. Die Knoten-Controller 1017 und 1018, auch NC_X genannt, verbinden mit dem RCB ebenfalls über einen ähnlichen Satz an unidirektionalen AStatOut Signalen 1019 bis 1022 pro Port, auch N_XP_XAStatOut genannt, und über AStatIn Signale 1023 und 1026, auch N_XP_XAStatIn genannt. Der Adressschalter 1027, auch ASX genannt, nimmt teil an der Bestimmung der eigenen Logik zur Systemverarbeitung einer Transaktion, indem das Sendesignal 1028 und die Transaktionsquellen-ID 1029 zur Verfügung gestellt werden, die eine Codierung einer Knoten- Identifikation zusammen mit einer Port-Identifikation innerhalb des Knotens darstellt, durch die ein Master-Gerät eine Transaktion an das System ausgegeben hat.

Wie in Fig. 10B gezeigt, verfügen die Prozessoren 1001 bis 1004 über unidirektionale ARespOut Signale 1055 bis 1058, auch P_XN_XAReOut genannt, sowie über ARespIn Signale 1059 bis 1062, auch P_XN_XAReIn genannt, die die Prozessoren mit dem RCB 1000 verbinden. Die Speichersubsysteme 1005 und 1006 verbinden mit dem RCB über ARespIn Signale 1065 und 1066, auch M_X_AReIn genannt. Die Speichersubsysteme 1005 und 1006 stellen keine Verbindung mit ARespOut-Verbindungen her, die von diesen Slave-Geräten nicht betrieben werden. Die Knoten- Controller 1017 und 1018 verbinden ebenfalls mit dem RCB über einen ähnlichen Satz an unidirektionalen ARespOut Signalen 1069 bis 1072, auch N_XP_XAReOut genannt und über ARespIn Signale 1073 bis 1076, auch N_XP_XAReIn genannt. Der Adressschalter 1027 nimmt teil an der Bestimmung der eigenen Logik einer Transaktion, durch Bereitstellung des Sendesignals 1028 und der Transaktionsport-ID 1029. Wie in den Fig. 10A und 10B zu erkennen ist, wird ein Satz von AStatIn/AStatOut Signalen und ARespIn/ARespOut Signalen von/Zu einem Master-Gerät mit einem ähnlichen Paar an AStatIn/AStatOut Signalen und ARespIn/ARespOut Signalen von/zu seinem Knoten-Controller gepaart. Diese Paarung geschieht auf einer portweisen Grundlage. Wie oben beschrieben, wird jeder Port in dem Beispiel mit einem einzelnen Master-Gerät gezeigt, der mit jedem einzelnen Port verbunden ist. Wenn jedoch mehr als ein Master-Gerät pro Port verbunden sind, werden die Paare AStatIn/AStatOut Signale und ARespIn/ARespOut Signale von dem mit dem Bus des Ports verbundenen Satz an Master-Geräten wie in einer standardmäßigen Einzelbus-Konfiguration verwendet. Im bevorzugten Ausführungsbeispiel kombiniert der RCB die AStatOuts und die ARespOuts aus mehreren QuellGeräten und erstellt AStatIn und ARespIn Signale entsprechend der 6XX Bus-Spezifikation, wie beschrieben in IBM Server Group Power PC MP System Bus Description, Version 5.3, hier als Verweis aufgeführt. Der RCB empfängt die AStatOut und ARespOut Signale und gibt entsprechende AStatIn und ARespIn Signale aus. Nicht alle Geräte empfangen die gleichen Antworten für eine spezielle Transaktion. Die von jedem Gerät empfangenen Signale werden auf einer zyklusweisen Grundlage bestimmt, wie im weiteren näher erläutert.

Lokale/Globale Zyklen

Während eines beliebigen gegebenen Zyklus kann ein Master- Gerät an einem Port eine Transaktion über den Portbus ausgeben, die zum Empfang durch den Knoten-Controller bestimmt ist, oder der Knoten-Controller kann dem Master- Gerät eine Transaktion zur Verfügung stellen, die vom Adressschalter weitergeleitet wurde, um nach der Transaktion zu suchen. Wenn das Master-Gerät eine Transaktion ausgibt, wird der Zyklus als "Lokal" bezeichnet. Wenn der Knoten- Controller eine Transaktion zur Verfügung stellt, wird der Zyklus als "global" bezeichnet. Wie oben beschrieben, versendet der Adressschalter jeweils eine Transaktion an alle Knoten-Controller und es besteht eine feste Zeitspanne zwischen dem Zeitpunkt, zu dem der Adressschalter eine solche Transaktion ausgibt und dem Zeitpunkt, zu dem diese an den Ports der einzelnen Knoten-Controller erscheint. Mit dieser Regelung, nachdem ein Knoten-Controller eine versendete Transaktion vom Adressschalter erhalten hat und anschließend, eine vorbestimmte Anzahl an Zyklen später, diese Transaktion an die Geräte der Busse der Ports der Knoten-Controller während eines Zyklus ausgibt, führen alle Knoten-Controller die gleiche Aktion an allen ihren Ports während des gleichen Zyklus aus, mit einer Ausnahme, die im folgenden beschrieben wird. Wenn also ein globaler Zyklus auf dem Bus eines Ports ausgeführt wird, werden globale Zyklen auf allen Ports im System ausgeführt. Alle übrigen Zyklen sind lokale Zyklen. Während lokaler Zyklen ist eine Aktivität an einem Port nicht verbunden mit den Aktivitäten an anderen Ports innerhalb des Systems. Je nachdem, ob Geräte eine Transaktion ausgeben mussten, wird der lokale Zyklus belegt oder befindet sich im Leerlauf. Somit tritt ein globaler Zyklus auf, wenn alle Geräte im System nach einer Transaktion suchen und nur ein lokaler Zyklus von einem Gerät verwendet werden kann, um eine Transaktion auszugeben.

Betrieb des RCB während lokalen und globalen Zyklen

Vorausgesetzt, dass alle Zyklen des Systems als lokal oder global gekennzeichnet sind, werden die Zyklen für Antwortgenerierung, Antwortkombination oder Antworterhalt, die nach einer festen Anzahl an Zyklen nach der Ausgabe einer Transaktion auftreten, ähnlich als Fenster Local Response oder Fenster Global Response bezeichnet. Aus diesem Grund wird die RCB-Funktion zur Antwortkombination entweder in einem lokalen oder in einem globalen Modus während eines gegebenen Zyklus betrachtet. Während lokaler Zyklen kombiniert der RCB die Antworten auf einer portweisen Grundlage. Das heißt, dass der RCB die Antwort eines Ports mit der Antwort kombiniert, die der Knoten-Controller entsprechend diesem Port erstellt. Während globaler Zyklen kombiniert der RCB Antworten aller Ports und Knoten- Controller im System (mit Ausnahme für nur einen Port, wie oben beschrieben).

Um eine ordnungsgemäße Schaltung zwischen lokalen und globalen Kombinationsmodi zu erlangen, wird der RCB mit einem Signal zur Verfügung gestellt, das die Versendung einer Transaktion durch den Adressschalter an die Knoten-Controller anzeigt, gezeigt als Sendesignal 1028 in Fig. 10A sowie das Transaktionsquell-ID-Signal 1029. Informationen zur Konfiguration werden im RCB gespeichert und zeigen den exakten Zyklus an, in dem die Kombination von Antworten für die versendete Transaktion ausgeführt werden soll, nach Eingang des versendeten Transaktions-Signals. Auf diese Weise wird der RCB für jeden globalen Zyklus angeordnet, um die Antworten von den entsprechenden Quellen zu kombinieren.

Primäre und sekundäre lokale Zyklen

Ein Prozessor kann eine Transaktion nur während lokaler Zyklen ausgeben. Bei bestimmten Arten von Transaktionen gibt der Prozessor die Transaktion nur einmal aus. Bei bestimmten anderen Arten von Transaktionen kann es für den Prozessor erforderlich sein, die Transaktion mehrmals auszugeben. Der Prozessor wird durch seinen Knoten-Controller, in Verbindung mit dem RCB, durch Verwendung der AStatIn/AStatOut Signale und der ARespIn/ARespOut Signale zur Ausführung der notwendigen Aktionen angeleitet.

Die lokalen Zyklen, in denen ein Prozessor Transaktionen zum ersten Mal ausgibt, werden als "primäre lokale Zyklen" bezeichnet, wobei alle weiteren lokalen Zyklen als "sekundäre lokale Zyklen" bezeichnet werden. In der 6XX Busarchitektur wird eine sekundäre Transaktion durch das "R"-Bit gekennzeichnet, das auf "1" gesetzt wird. Mit anderen Worten, die Antwort-verbundenen Zyklen werden entsprechend der Transaktionsausgabe als primär oder sekundär gekennzeichnet.

Erreichen von Kohärenz durch Suchen auf eine zeitlich und räumlich verteilte Weise

In der weiteren Beschreibung sollte klar sein, dass Prozessoren und Geräte Transaktionen von anderen Prozessoren und Geräten empfangen, und dies während eines anderen Zyklus, als dem, zu dem die Transaktionen ausgegeben wurden. Es verhält sich hier anders als in einer Situation mit einem Suchprotokoll in einer Einzelbusumgebung, in der alle Geräte im System eine Ausgabe der Transaktion zur gleichen Zeit erhalten und gleichzeitig eine kohärente Antwort erstellen und in der der Ersteller der Transaktion die Antworten zur gleichen Zeit erhält. So wird im aktuellen System die Erreichung von Kohärenz sowohl zeitlich als auch räumlich verteilt, d. h. über mehrere Zyklen und mehrere Busse, verbunden mit mehreren Knoten-Controllern.

Bei Verwendung der verteilten Systemstruktur ist es wichtig, eine globale Kohärenz auf effiziente Weise zu erzielen. Dazu werden alle Transaktionen in zwei Kategorien sortiert: (1) Transaktion, für die eine Vorhersage der globalen Kohärenz- Antwort und deren Bereitstellung im Fenster Primary Response möglich ist und (2) Transaktionen, für die eine globale Suche notwendig ist, bevor die ultimative Antwort berechnet werden kann.

Im ersten Fall akzeptiert der Knoten-Controller die Transaktion und gibt eine globale Kohärenz-Antwort an die ausgebende Einheit im Fenster Primary Response aus. Der Knoten-Controller übernimmt dann vollständig die Ausführung der Transaktion im System zu einem späteren Zeitpunkt und den Empfang der globalen Antwort.

Im zweiten Fall unternimmt der Knoten-Controller drei Schritte. Zunächst akzeptiert der Knoten-Controller die Transaktion und stellt eine primäre Antwort bereit, die die Verschiebung des Empfangs und die Bereitstellung der globalen Antwort anzeigt. In der 6XX Busarchitektur wird diese Antwort als "Rerun" Antwort bezeichnet. Als nächstes empfängt der Knoten-Controller eine globale Kohärenz-Antwort für diese Transaktion. Und in einem dritten Schritt fordert der Knoten- Controller an, dass der Prozessor eine zweite Transaktion ausgibt und die globale Antwort im Fenster Secondary Response bereitstellt. In der 6XX Busarchitektur wird diese Anforderung an den Prozessor zur Ausgabe einer sekundären Transaktion ausgeführt, indem ein Befehl Rerun mit einer Markierung ausgegeben wird, die der ursprünglichen Transaktion entspricht. Der Prozessor kann dann die Markierung nutzen, um anzugeben, welche der Transaktionen wiederholt werden soll.

Wiederholungsbefehle und Sekundäre Antworten

Wie oben erwähnt, wird nach einer von einem Gerät akzeptierten Transaktion im restlichen System gesucht. Während einer solchen Suche wird das Gerät, das die Transaktion ausgegeben hat, nicht durchsucht, damit das Gerät nicht durch die Suche nach der eigenen Transaktion fehlgeleitet wird.

Tatsächlich wird für Transaktion im ersten, oben genannten Fall, d. h. für Transaktionen, bei denen der Knoten-Controller die Transaktion akzeptiert und eine globale Kohärenz-Antwort an die ausgebende Einheit im Fenster Primary Response ausgibt, der Port des Geräts, das die Transaktion ausgegeben hat, im lokalen Modus im Transaktionssuchzyklus gehalten, so dass der Prozessor eine weitere Transaktion ausgeben kann. Wie oben erläutert, wird der RCB, während das Antwortfenster dem Suchzyklus der Transaktion entspricht, so konfiguriert, dass alle Antworten von allen Quellen kombiniert werden, die nicht von dem Port des Knoten-Controllers stammen, der die Transaktion ausgegeben hat. Der Knoten-Controller ist dann in der Lage, eine primäre oder sekundäre Antwort über diesen Port auszugeben, wenn der Prozessor eine Transaktion ausgeben will.

Bei Transaktionen im zweiten, oben genannten Fall, d. h. bei Transaktionen, für die eine globale Suche vor der Berechnung der ultimativen Kohärenz-Antwort notwendig ist, hält der Knoten-Controller den bestimmten Port im lokalen Modus, gibt jedoch eine Wiederholungstransaktion aus. Die Steuereinheit /Multiplexer, die den ausgehenden Grenz-Latch am Port versorgt, ermöglicht dem Knoten-Controller diese Funktion. Alternativ dazu kann der Knoten-Controller auch weniger offensiv vorzugehen und statt dessen dem Gerät die Ausgabe einer Transaktion zu gestatten, wobei der Knoten-Controller selbst eine Null- oder Wiederholungstransaktion an das Gerät in dem Zyklus ausgeben kann, während dem die Transaktion des Geräts im restlichen System gesucht wird.

Die Fig. 10C und 10D zeigen Blockdiagramme mit den Komponenten, deren Signale an den lokalen und globalen Zyklen teilhaben. Fig. 10C zeigt die Signale, die vom RCB während eines globalen Zyklus berücksichtigt werden. In dem gezeigten Beispiel nehmen die Signale für ein einzelnes Master-Gerät, Prozessor 1001, nicht an der Bestimmung durch den RCB der entsprechenden Signale an die anderen Geräte, Knoten- Controller und Speichersubsysteme für die globale Antwort teil. Die Signale für den Prozessor 1001 werden mit den entsprechenden Signalen vom Knoten-Controller gepaart, die ebenfalls nicht für eine globale Antwort berücksichtigt werden. Aus der Perspektive von Prozessor 1001 wird sie in einem lokalen Zyklus gehalten, während eine vom Prozessor 1001 ausgegebene Transaktion im restlichen System gesucht wird. Wie zuvor erwähnt, auch wenn ein Prozessor abgebildet ist, werden die Signale auf einer portweisen Grundlage berücksichtigt, und der Bus eines bestimmten Ports wird in einem lokalen Zyklus gehalten, während sich das restliche System in einem globalen Zyklus befindet.

Fig. 10D zeigt die Signale, die vom RCB bei einem lokalen Zyklus berücksichtigt werden. In dem gezeigten Beispiel nehmen die Signale von einem einzelnen Master-Gerät, Prozessor 1001, an der Bestimmung durch den RCB der entsprechenden Signale teil, die an den Prozessor 1001 und seinen Knoten-Controller auszugeben sind. Signale von den anderen Geräten, Knoten-Controllern und Speichersubsystemen können simultan ebenfalls an der Antwort für die globale Antwort teilnehmen. Die Signale für den Prozessor 1001 werden mit den entsprechenden Signalen von seinem Knoten-Controller gepaart, die die globale Antwort ebenfalls nicht betreffen. Aus der Perspektive von Prozessor 1001 kann eine weitere Transaktion ausgegeben werden, während die andere Transaktion im restlichen System gesucht wird. Aus Gründen der Übersichtlichkeit werden die Signale vom Adressschalter für den lokalen Zyklus nicht gezeigt, obwohl der RCB diese Signale verwendet, um den Port zu bestimmen, der im lokalen Zyklus platziert werden soll.

Erreichen der richtigen Reihenfolge bei den Busspeicher- Transaktionen

Damit ein Computersystem ordnungsgemäß arbeiten kann, müssen bestimmte Zugriffstransaktionen und andere Arten von Transaktionen, ausgegeben von Master-Geräten, ordnungsgemäß und eindeutig angeordnet werden. In einem System mit einem einzelnen Systembus wird diese Aufgabe ganz einfach gelöst, da die Reihenfolge der Darstellung der Transaktionen auf dem Bus der erforderlichen Reihenfolge für die Transaktionen entspricht. In einem verteilten System mit mehreren Bussen jedoch ist es erforderlich, dass eine Reihenfolge für die Transaktionen in der Warteschlange des Systems festgelegt ist. Die verteilte Architektur der vorliegenden Erfindung ermöglicht eine korrekte und eindeutige Reihenfolge für einen Satz an Transaktionen. Die Erfindung bietet weiterhin ein effizientes Mittel zum Erreichen dieser Reihenfolge, damit ein Such-, Hardware-Cache-Kohärenz-Protokoll unterstützt werden kann.

Wenn Geräte in einem Multiprozessorsystem auf Speicher zugreifen, entweder durch Programme oder Steuersequenzen, werden von ihnen Speichertransaktionen ausgegeben. Die Geräte können ebenfalls weitere Bustransaktionen ausgeben, um Kohärenz, Sortierungen, Unterbrechungen usw. im System zu erzielen. Diese Transaktionen können normalerweise parallel ausgeführt werden, ohne Eingreifen durch andere Transaktionen. Wenn jedoch zwei Transaktionen beispielsweise auf Adressen im gleichen Doppelwort verweisen, wird davon gesprochen, dass sie kollidiert sind, gemäß der 6XX- Busterminologie und die beiden Transaktionen müssen in einer speziellen Reihenfolge ausgeführt werden. In einigen Fällen kann die Ausführungsreihenfolge gestattet werden und zu einem anderen Zeitpunkt ist die Reihenfolge fest und durch die Arten von Transaktion festgelegt. Wenn beispielsweise eine Lesetransaktion und eine Schreibtransaktion versuchen, auf eine Adresse zuzugreifen, bei der die Speicherkohärenz als nicht erforderlich gekennzeichnet ist, ist jede beliebige Ausführungsreihenfolge für die beiden Transaktionen möglich. Wenn sie jedoch auf eine cachebare Adresse zugreifen, die kohärent bleiben muss, muss die Ausführungsreihenfolge zuerst die Schreib- und dann die Lesetransaktion vorsehen.

Mittel zum Erzwingen einer Standardreihenfolge der Transaktionen

Im verteilten Multiprozessorsystem, beschrieben in den Fig. 4-10D können mehrere Prozessoren und Geräte Transaktionen simultan über die Vielzahl von Bussen im System ausgeben. Somit besteht anfangs eine Gleichheit hinsichtlich der Reihenfolge der Transaktionen bei deren Ausgabe. Wenn sie in einem ersten Schritt durch das System geleitet werden, erzwingt das System eine "heuristische Reihenfolge der Ankunft", die geeignet und gerecht ist. Die vorläufige Reihenfolge ist nicht unbedingt die Reihenfolge, in der die Transaktionen letztlich im System ausgeführt werden. Wenn zwei kollidierende Transaktionen gleichzeitig im System aktiv sind, wird die Transaktion, die als "erste der beiden" durch die heuristische Reihenfolge der Ankunft festgelegt wurde, als zuerst durchzuführen eingestuft, falls die Kohärenz es nicht anders erforderlich macht.

Sobald Befehle in das System eingegeben werden, werden diese von den Knoten-Controllern "registriert", d. h. sie werden von den Knoten-Controllern gespeichert und stehen für eine Analyse und Kollisionsprüfungen zur Verfügung. Knoten- Controller senden jeweils eine der registrierten Transaktionen an den Adressschalter. Der Adressschalter wählt jeweils eine Transaktion ausgehend von einer fairen Entscheidung zwischen den zugesendeten Transaktionen aus und sendet die ausgewählte Transaktion anschließend zurück an die Knoten-Controller und zu den Speichersubsystemen. Der Adressteil der durch den Adressschalter versendeten Transaktion wird zunächst im Knoten-Controller im Grenz-Latch FROM_ASX_BL vermerkt. Wie oben beschrieben, wird in jedem Zyklus eine eindeutige Transaktion in FROM_ASX_BL in allen Knoten-Controllern und Speichersubsystemen vermerkt und alle anderen registrierten Transaktionen, die seitdem in den Zyklus eingegeben wurden und noch aktiv sind, einschließlich der aktuell in FROM_ASX_BL vorhandenen Transaktion, können diese Transaktion "sehen". Diese beiden Merkmale werden verwendet, um die Reihenfolge der Ankunft von Transaktionen zu definieren, mit Hilfe der folgenden geeigneten und fairen Heuristik: Die Reihenfolge der Ankunft einer Transaktion im System entspricht der Reihenfolge der Ankunft in FROM_ASX_BL. Wenn eine Transaktion in FROM_ASX_BL zum ersten Mal ankommt, wird sie als "gesucht" markiert, um anzugeben, dass die Transaktion in einer festen Anzahl an Zyklen zum Suchen dargestellt wird, beim ersten Mal, für alle Geräte im System. Die folgende Regel wird verwendet, um einer Transaktion ihre relative Position in der Reihenfolge auszuführender Transaktionen zuzuweisen, ungeachtet der tatsächlichen Eingabezeit im System: Eine registrierte Transaktion, die bereits als gesucht markiert wurde, wird nominell als früher im System eingegeben definiert als die aktuelle Transaktion in FROM_ASX_BL. Diejenigen, die noch nicht als gesucht markiert wurden, werden nominell als später in das System eingeben definiert als die aktuelle Transaktion in FROM_ASX_BL.

Methode zum Erreichen der korrekten Ausführungsreihenfolge für Transaktionen

Die Transaktion in FROM_ASX_BL bleibt dort für einen Zyklus. Während dieses Zyklus wird die Transaktion verglichen mit jeder anderen Transaktion, die derzeit im gesamten System zur Erkennung von Kollisionen und Reihenfolge-Entscheidungen registriert ist. Es können zwei Ergebnissätze für diese paarweisen Vergleiche auftreten: Das eine Ergebnis beeinflusst die Ausführung der aktuell in FROM_ASX_BL vorhandenen Transaktion und ein zweites Ergebnis beeinflusst die Ausführung einer anderen Transaktion.

Jeder Vergleich führt zu einer Entscheidung, um entweder die derzeitige Darstellung der Transaktion in FROM_ASX_BL zum Ausführen der Suche zuzulassen oder sie auf einen späteren Zeitpunkt zu verschieben. Die Verschiebung erfolgt durch die Berechnung eines Signals AStat Retry. Diese Signale aus den einzelnen Vergleichen werden auf einer knotenweisen Grundlage innerhalb des Knoten-Controllers kombiniert. Eine Entscheidung zur Verschiebung erhält die höchste Priorität, so dass sogar ein einzelner Vergleich, der eine Verschiebung nach sich zieht, Priorität erhält und dazu führt, dass der Knoten die Transaktion verschiebt. Nur wenn alle Vergleiche innerhalb eines Knotens die Ausführung der aktuellen Suche zulassen, entscheidet der Knoten auf die Ausführung der Transaktion.

Die kombinierten Signale AStat Retry und AResp Retry werden durch den Knoten-Controller in den Codes für AStat Retry und AResp Retry codiert und an den RCB zur Teilnahme an den Fenstern Global AStat und AResp der gesuchten Transaktion übertragen. Bei diesen Fenstern werden Antworten von allen Geräten, die die Transaktion nicht ausgegeben haben, und von Knoten-Controllern vom RCB kombiniert, um eine globale Antwort zu erstellen, die an alle Teilnehmer zurückgegeben wird, wie hinsichtlich der Fig. 10A bis 10D oben erläutert wurde. Auf dieser globalen Ebene verfügt die Antwort Retry über höchste Priorität (Sperren eines Fehlercodes) und ist die letzte Antwort, falls eine der Input-Antworten eine Wiederholung war. Der Effekt einer globalen Antwort Retry ist der Abbruch der aktuellen Suche der Transaktion. Durch Empfang einer globalen Antwort Retry für die Transaktion, gibt der Knoten-Controller, in dem die Transaktion registriert wurde, die Transaktion für ein globales Suchen erneut aus oder wiederholt die ursprüngliche Transaktion, von der diese Transaktion abstammt.

Diese globalen Wiederholungen können wiederholt werden, bis die richtige Reihenfolge erzielt wurde. Wenn aus irgendeinem Grund eine Transaktion eine Antwort Retry erhält, wird die Markierung Suche zurückgesetzt und sie verliert so ihre nominale Position in der Transaktionsreihenfolge im System. Wenn sie für eine Suche ausgegeben wird, erhält die Transaktion eine neue Position, entsprechend der oben gegebenen Regel. Der Mechanismus schließt nicht unweigerlich die Möglichkeit der neu ausgegebenen Transaktion aus, hinter anderen Transaktionen eingeordnet zu werden, die im System später eingegeben wurden. Wenn jedoch andererseits die aktuelle Transaktion ausgeführt wurde, kann das dazu führen, dass andere Transaktionen wiederholt werden

Phasen der Transaktion

Anstelle eines gängigen Busses zur Verbindung der Prozessoren, E/A Agents usw. verwendet die vorliegende Erfindung Knoten-Controller zur Erstellung eines verteilten Multiprozessorsystems. Wie zuvor erwähnt, wird die Erreichung von Kohärenz sowohl zeitlich als auch räumlich im aktuellen System verteilt, d. h. auf mehrere Zyklen und mehrere Busse, die mit mehreren Knoten-Controllern verbunden sind. Mit dieser Architektur können zeitlichen Paradoxien zwischen den Transaktionen auf jedem gegebenen Prozessorbus entstehen. Ein Paradoxon kann aus den verschiedenen Perspektiven einer Transaktion durch einen Prozessor und seinen Knoten- Controller entstehen. Vor allem ein Prozessor und sein Knoten-Controller können über verschiedene Perspektiven hinsichtlich der Reihenfolge der Initiierung der Transaktionen verfügen, die auf dem Prozessorbus vorhanden sind. Wenn ein erster Prozessor eine erste Transaktion an das System ausgibt und ein zweiter Prozessor dann eine zweite Transaktion an das System ausgibt, ist die Ansicht des ersten Prozessor auf die Reihenfolge der beiden Transaktionen konsistent mit der des restlichen Systems, unabhängig davon, ob die erste Transaktion vor der zweiten Transaktion gesucht wurde oder nicht. Dies ist der Fall, weil der erste Prozessor seine Transaktion richtigerweise als die Transaktion ansieht, die vor der zweiten Transaktion ausgegeben wurde. Wenn jedoch der Prozessor eine Transaktion ausgibt, die einen Zyklus vor einer vom Knoten-Controller ausgegebenen Transaktion liegt, kann der Prozessor seine eigene Transaktion als eine vor der vom Knoten-Controller ausgegebenen Transaktion generierte Transaktion ansehen. Tatsächlich wurde die letztere Transaktion aus Sicht des Systems mehrere Zyklen vor der früheren Transaktion in das System eingegeben. Die Inkonsistenz der beiden Perspektiven auf die Transaktionsreihenfolge führt dazu, dass die Kohärenz-Antwort des Prozessors nicht korrekt ist, aus der Perspektive des Systems, falls die beiden Transaktionen kollidieren sollten. Der Knoten-Controller muss die verschiedenen Perspektiven einbeziehen und seine eigenen Antworten darauf abstimmen, um das Paradoxon in der Reihenfolge zu lösen.

Um die Aktionskohärenz eines Knoten-Controllers zu organisieren, wird das Leben einer Transaktion im mehrere Phasen unterteilt, je nach Art der Transaktion. Eine Transaktion wird von dem Punkt an als aktiv betrachtet, an dem sie vom Knoten-Controller akzeptiert wird, bis zu dem Punkt, an dem sie aus Sicht des System beendet wird. Die Kohärenzaktionen eines Knoten-Controller hinsichtlich der Transaktion sind eine Funktion der aktuellen Phase der Transaktion und anderer kollidierender Transaktionen. Fig. 11 zeigt eine Tabelle mit Definitionen der Phase der Transaktion im vorliegenden System. Die Phasen der Transaktion sind chronologisch geordnet, von Phase 1a bis Phase 5. Die Länge jeder Phase, die Bestimmung des Beginns und des Endes jeder Phase und der Standort der Transaktion innerhalb des Systems oder der Aktion, die für die Transaktion im System ausgeführt wird, werden in dieser Tabelle gegeben.

Phase 1a ist die erste Phase einer Transaktion und diese Phase dient primär dem Akzeptieren einer Transaktion an einem der Ports einer der Knoten-Controller. Die Länge der Phase 1a ist ein einzelner Zyklus, der mit der Transaktion beginnt und endet, die sich im eingehenden Grenz-Latch für einen Port befindet. Fig. 6 zeigt Phase 1a, die aus dem Zyklus besteht, während dem sich die Transaktionen in einem der Grenz-Latches IN_BLx befinden, wobei x die Port-ID ist, die die Transaktion empfangen hat, wie etwa die Grenz-Latches 609 bis 612. Phase 1b 43883 00070 552 001000280000000200012000285914377200040 0002010045916 00004 43764ist die nächste Phase einer Transaktion und diese Phase besteht aus der Zeitperiode für das Fenster Primary Response für die Transaktion, die vom Knoten-Controller empfangen wurde. Die Länge der Phase 1b ist abhängig von der Art der empfangenen Transaktion. Die Phase beginnt mit dem zweiten Zyklus der Transaktion innerhalb des Systems und die Phase endet mit dem letzten Zyklus, mit dem eine Primary Address Response Out für die Transaktion durch den Knoten- Controller beeinflusst werden kann. Während dieser Phase wird die Transaktion innerhalb des Knoten-Controllers verarbeitet, der die Transaktion im System empfangen hat und der Knoten- Controller stellt die Transaktion in eine Warteschlange, während die entsprechende primäre Antwort bestimmt wird, die an das Master-Gerät gegeben wird, das die Transaktion ausgegeben hat. Wie zuvor beschrieben, werden alle Transaktionen in zwei Kategorien eingeteilt, je nachdem, ob die globale Kohärenz-Antwort für die Transaktion im Fenster Primary Response bereitgestellt werden kann oder nicht. Während Phase 1b bestimmt der Knoten-Controller, ob eine globale Kohärenz-Antwort für die ausgebende Einheit im Fenster Primary Response bereitgestellt werden muss. Phase 2a ist die nächste Phase der Transaktion und diese Phase befasst sich mit der Zeitperiode, während der die Transaktion in einem Knoten-Controller verweilt, während sie auf ihre Versendung für eine globale Suche wartet. Die Länge der Phase ist nicht genau festgelegt. Die Phase beginnt mit dem Zyklus, nachdem Phase 1b abgeschlossen ist und die Phase endet mit dem Zyklus, bevor die Transaktion vom Knoten- Controller für eine globale Suche empfangen wird. Während dieser Phase wird die Transaktion in eine Warteschlange im Knoten-Controller gestellt und für die Versendung für eine globale Suche ausgewählt. Die Länge dieser Phase ist nicht festgelegt, da der Status des gesamten Systems Einfluss darauf hat, wann eine Transaktion für eine globale Suche ausgewählt wird. Die Phase wäre extrem kurz, wenn sich nur eine einzige Transaktion in den Warteschlangen aller Knoten- Controller befände. Wenn das System stark ausgelastet ist, kann die Transaktion eine große Zahl an Zyklen abwarten, bevor sie für eine Suche ausgewählt wird. Fig. 4 zeigt Phase 2a, die die Zeitperiode betrifft, in der sich die Transaktion innerhalb eines Knoten-Controllers befinden kann, wie etwa Knoten-Controller 415, bis die Transaktion für die Versendung an die anderen Komponenten im System ausgewählt wird. Somit umfasst die Phase 2a jene Zyklen, während derer die Transaktion den Adressschalter passiert, wenn die Transaktion beispielsweise über den Bus 416 zum Adressschalter 430 gesendet wird und von dort über Bus 417 und andere Busse an andere Teile des Systems weitergeleitet wird.

Phase 2b ist die nächste Phase einer Transaktion und diese Phase betrifft den Zyklus, in dem die Transaktion vom Knoten- Controller für eine globale Suche empfangen wird. Die Länge dieser Phase beträgt einen einzelnen Zyklus und die Phase beginnt und endet mit dem Zyklus, während dem die Transaktion sich im Grenz-Latch FROM_ASX_BL befindet. Fig. 6 zeigt Phase 2b, in deren Zyklus die Transaktion an die Knoten-Controller versendet wird und im Grenz-Latch 627 festgehalten wird, auch Grenz-Latch FROM_ASX_BL genannt. Wie zuvor beschrieben, wird eine eindeutige Transaktion in FROM_ASX_BL in allen Knoten- Controllern festgehalten. Es kann sich nur eine Transaktion in Phase 2b befinden. Dieses Merkmal wird verwendet; um die relative Reihenfolge der im System ausgeführten Transaktion festzulegen. Wenn eine Transaktion diese Phase erreicht, wird sie als "gesuchte Transaktion" bezeichnet und der Knoten- Controller, in dem die Transaktion registriert ist, markiert die Transaktion als gesucht. Wenn sich eine Transaktion in dieser Phase befindet, durchläuft sie eine globale Kollisionserkennung, indem bestimmt wird, ob sie mit anderen Transaktionen kollidiert, die derzeit in einem der Knoten- Controller des Systems aktiv sind. Die Ergebnisse dieser Kollisionen werden während des entsprechenden Zyklus vom Antwortkombinationsblock kombiniert, um eine globale Antwort, sowohl AStat und AResp, für die Transaktion zu erstellen. Phase 3 ist die nächste Phase der Transaktion und diese Phase befasst sich mit der Zeitperiode, während der die Transaktion die Knoten-Controller passiert und an die Master-Geräte für eine globale Suche gesendet wird. Die Länge der Phase umfasst eine feste Zahl an Zyklen, abhängig von der Systemimplementierung, d. h. der Anzahl an Zyklen zwischen dem Such-Latch und einem Port innerhalb der Knoten-Controller- Implementierungen. Die Phase beginnt mit dem Zyklus, nachdem die Phase 2b beendet ist und die Phase endet, wenn der Knoten-Controller die Global Adress Response In für die Transaktion erhält. Während dieser Phase wird die Transaktion durch die Master-Geräte gesucht, die mit dem Knoten- Controller verbunden sind.

Fig. 6 zeigt Phase 3, die die Zyklen umfasst, während der sich die Transaktion vom Grenz-Latch FROM_ASX_BL zu den Ports eines Knoten-Controllers verschiebt, um über die mit dem Knoten-Controller verbundenen Busse versendet zu werden. Phase 3 umfasst ebenfalls diejenigen Zyklen, während der die Master-Geräte Antworten erstellen, die durch den Antwortkombinationsblock kombiniert werden, um eine globale Antwort für die gesuchte Transaktion zu erstellen. Phase 4 ist die nächste Phase einer Transaktion und diese Phase befasst sich mit der Verarbeitung, die vor der Beendigung der Transaktion stattfindet. Phase 4 kann unter Berücksichtigung zweier Kategorien von Transaktion beschrieben werden: Lesetransaktionen und alle anderen Transaktionen, die nicht Lesetransaktionen sind. Die Länge der Phase hängt ab von der Art der Transaktion. Die Phase beginnt mit dem Zyklus nach Beendigung der Phase 3 und endet an dem Punkt, der von der Kategorie der Transaktion abhängig ist. Für Lesetransaktionen endet die Phase mit dem Zyklus, bevor der Datentransfer an den Anfordernden beginnt. Für Nicht-Lesetransaktionen endet die Phase mit der Beendigung der Transaktion im System.

Phase 5 ist die nächste Phase einer Transaktion und diese Phase befasst sich mit der Ausführung von Lesetransaktionen. Wie oben zur Phase 4 erwähnt, kann die Ausführung der Transaktion in zwei Kategorien unterteilt werden: Lesetransaktionen und Nicht-Lesetransaktionen. Für Lesetransaktionen ist die Phase 4 die letzte Phase einer Transaktion. Phase 5 wird ausschließlich für Lesetransaktionen definiert, und die Länge der Phase 5 ist abhängig von der Art der Lesetransaktion und dem Umfang an Daten, die für die Lesetransaktion übertragen werden sollen. Die Phase beginnt mit dem Zyklus nach Beendigung der Phase 4 und die Phase endet mit der Beendigung der Lesetransaktion im System.

Arten von Transaktionen

Transaktionen werden zum Zwecke der Kollisionserkennung unter folgenden Gesichtspunkten unterteilt: die mögliche letzte globale Kohärenz-Antwort der Transaktion, der Zeitpunkt, zu dem die letzte globale Kohärenz-Antwort an die Master geliefert werden kann, die die Transaktionen ausgegeben haben, und die Art der Transaktion. Die folgenden Kategorien werden bei der Bestimmung der globalen Kohärenz-Antwort verwendet:
Lesebefehle, für die der Kohärenzstatus der Cachezeile zusammen mit Daten festgehalten wird;
Lesebefehle, für die die Kohärenz-Antwort garantiert Null ist;
Lesebefehle, für eine Primary Response of Retry gegeben wird;
Befehle, die tatsächlich global gesucht werden müssen und für die eine globale Antwort nicht vorhergesagt werden kann, wie beispielsweise DClaim und RWITM Transaktionen des 6XX- Protokolls;
Befehle, die keine Lesebefehle sind, für die die letzte globale Kohärenz als Null vorhergesagt werden kann, wie etwa Clean, Dkill, Flush usw.
Nichtkohärentes Schreiben, das nicht von den Master-Geräten gesucht wird, beispielsweise WWC/WWK M = 0;
Kohärentes Schreiben, beispielsweise WWK/WWF M = 1; und
andere, verschiedene Befehle, die nicht Gegenstand kohärenz verwandter Kollisionen sind, beispielsweise SYNC und TLBIE.

Kohärenzaktion der Knoten-Controller

Die primären und globalen Kohärenz-Antworten, verteilt durch den Knoten-Controller für eine Transaktion, die im Knoten- Controller registriert oder in die Warteschlange gestellt wird, in Kollision mit einer gesuchten Transaktion sind eine Funktion der folgenden Bedingungen: Die Art und die Phase der lokalen Transaktion und AStat und AResp Antworten, die die Transaktion zu dem Zeitpunkt erhalten hat, zu dem der Knoten- Controller seine Antwort beiträgt; die Art der gesuchten Transaktion; die temporäre Nähe der gesuchten Transaktion zu anderen Transaktionen und das Busprotokoll, das im System implementiert ist.

Für jede eindeutige Paarung kollidierender Transaktionen innerhalb eines Knoten-Controllers verteilt der Knoten- Controller Eingaben, d. h. AStat und AResp Antworten an die Antwort, die vom Antwortkombinationsblock ausgewählt wird. Für das 6XX-Protokoll beispielsweise können die AStat Antorten entweder Null Ack oder Retry sein, AResp Antworten können entweder Null, Shared oder Retry sein. Zusätzlich können die AResp Antworten für jede eindeutige Paarung kollidierender Transaktionen konditional oder nicht konditional sein. Somit bestimmt für jedes eindeutige Paar kollidierender Transaktionen jeder Knoten-Controller seine Antwort, die die Verwendung konditioneller Regeln umfasst, die für die Bestimmung der Antwort verwendet werden können. Fig. 12A-12B zeigt Tabellen mit den Antworten, die von einem Knoten-Controller in Reaktion auf die Erkennung eines kollidierenden Transaktionspaars generiert werden. Fig. 12A zeigt eine Tabelle mit Antworten für ein kollidierendes Paar einer DClaim Transaktion und einer Lesetransaktion, für die der Kohärenzstatus der Cachezeile zusammen mit den Daten festgehalten wird, die durch einen Knoten-Controller erstellt werden können. "X" in den Tabellen kennzeichnet, dass der Knoten-Controller keine "abschlägige" Antwort für die Transaktion für diese Kollision ausgibt, d. h. der Knoten-Controller gibt im 6XX-Protokoll eine Nullantwort und kein Retry aus. In diesem Beispiel ist DClaim eine lokale Transaktion, d. h. eine Transaktion, die empfangen, in die Warteschlange gestellt oder im Knoten-Controller registriert wurde, und die Lesetransaktion ist eine Transaktion, die gesucht wird, d. h. die befindet sich im Grenz-Latch FROM_ASX_BL des Knoten-Controllers und ist hinsichtlich des Knoten-Controllers, in dem sie registriert ist, in Phase 2b. Phase 1a und Phase 1b bezeichnen die Phasen, die im Fenster Primary Response liegen. Somit trägt der Knoten-Controller eine Null-Antwort zur gesuchten Transaktion in diesen Phasen bei. In Phase 2a kann die lokale Transaktion oder die globale Transaktion einen Beitrag zur globalen Antwort empfangen. Phase 2b wird stets durch eine leere Spalte in einer Antworttabelle dargestellt, da sich die gesuchte Transaktion immer in Phase 2b befindet, d. h. immer im Grenz-Latch FROM_ASX_BL ist und da sich nur eine Transaktion im System in diesem Status befinden darf können die lokale und gesuchte Transaktion nicht mit sich selbst kollidieren. In den Phasen 3 und 4 kann die gesuchte Transaktion einen Beitrag zu ihrer globalen Antwort erhalten, da die lokale Transaktion kurz vor dem Abschluss steht.

In Fig. 12A, falls der Knoten-Controller eine DClaim Transaktion in Phase 1a hat und eine Lesetransaktion zum Suchen empfängt, gibt der Knoten-Controller ein Primary AStat Retry für die DClaim Transaktion aus. Die Primary AResp Antwort ist jedoch für die DClaim Transaktion im Knoten- Controller, in dem die DClaim Transaktion registriert ist, nicht betroffen. Weder die globalen AStat noch die AResp Antworten für die Lesetransaktion sind von der Kollision betroffen. Wenn der Knoten-Controller über eine DClaim Transaktion in Phase 1b verfügt und eine Lesetransaktion zum Suchen empfängt, gibt der Knoten-Controller keine primäre AStat Antwort für die DClaim Transaktion aus. Die primäre AResp Antwort für die DClaim Transaktion erhält jedoch ein Retry vom Knoten-Controller, in dem die DClaim Transaktion registriert ist. Weder die globalen AStat noch die AResp Antworten für die Lesetransaktion sind von der Kollision betroffen.

Wenn der Knoten-Controller über eine DClaim Transaktion in Phase 2a verfügt und eine Lesetransaktion zum Suchen erhält, empfängt die globale AResp Antwort für die DClaim Transaktion ein Retry vom Knoten-Controller, in dem die DClaim Transaktion registriert ist. Die spezielle Antwort wird eine "Selbstwiederholung" genannt. Da Phase 2a einer Transaktion die Zeitperiode darstellt, in der die Transaktion in die Warteschlange innerhalb des lokalen Knoten-Controllers gestellt wird, wird diese Antwort im lokalen Knoten- Controller zur späteren Verwendung gespeichert. In diesem Beispiel, wenn die DClaim Transaktion später zur globalen Suche gegeben wird, gibt der lokale Knoten-Controller die gespeicherte Selbstwiederholungsantwort zum gegebenen Zeitpunkt aus. Obwohl die Lesetransaktion, mit der die DClaim Transaktion kollidiert, geraume Zeit zuvor abgeschlossen worden sein kann, wird die DClaim Transaktion für eine globale Suche gegeben und DClaim "verliert" in diesem speziellen Kollisionsszenario, da die genannte Antwort notwendig ist, um die richtige Reihenfolge der Ausführung der Transaktionen zur Unterstützung von Cache-Kohärenz sicherzustellen.

Wenn der Knoten-Controller über eine DClaim Transaktion in Phase 3 verfügt und eine Lesetransaktion zum Suchen empfängt, kann die globale AResp Antwort für die Lesetransaktion ein Retry vom Knoten-Controller empfangen, in dem die DClaim Transaktion registriert wurde. Dieses Retry ist konditional für den Fortschritt der kollidierenden DClaim Transaktion. Wenn die DClaim Transaktion kein globales Retry empfängt, dann empfängt die Lesetransaktion ein Retry vom Knoten- Controller, in dem die kollidierende DClaim Transaktion registriert ist, wie in der Tabelle gezeigt. Wenn die DClaim Transaktion ein globales Retry empfängt, empfängt die Lesetransaktion eine Null-Antwort vom Knoten-Controller, in dem die kollidierende DClaim Transaktion registriert ist, d. h. das Retry in der Tabelle wird in eine Null umgewandelt.

Wenn der Knoten-Controller über eine DClaim Transaktion in Phase 4 verfügt und eine Lesetransaktion zum Suchen empfängt, empfängt die Globale AResp Antwort für die Lesetransaktion ein Retry vom Knoten-Controller, in dem die DClaim Transaktion registriert ist, wie in der Tabelle gezeigt. Dieses Retry ist nicht bedingend für den Fortschritt der kollidierenden DClaim Transaktion.

Fig. 12B zeigt eine Tabelle mit Antworten, die durch einen Knoten-Controller für ein kollidierendes Paar aus DClaim und Lesetransaktionen erstellt würden. Nochmals, "X" in der Tabelle zeigt an, dass der Knoten-Controller keine "abschlägige" Antwort für die Transaktion für diese Kollision ausgibt, d. h. im 6XX-Protokoll gibt der Knoten-Controller eine Null-Antwort und kein Retry aus. In diesem Beispiel, im Gegensatz zu Fig. 12A, ist das Lesen eine lokale Transaktion, d. h. eine Transaktion, die empfangen, in eine Warteschlange gestellt oder im Knoten-Controller registriert worden ist und die DClaim Transaktion ist eine Transaktion, die gesucht wird, d. h. die sich im Grenz-Latch FROM_ASX_BL des Knoten-Controllers befindet und im Knoten-Controller, in dem sie registriert ist, in Phase 2b ist.

In Fig. 12B, wenn der Knoten-Controller über eine Lesetransaktion in Phase 1a verfügt und eine DClaim Transaktion zum Suchen empfängt, gibt der Knoten-Controller ein primäres AStat Retry für die Lesetransaktion aus. Die Primäre AResp Antwort für die Lesetransaktion bleibt jedoch vom Knoten-Controller, in dem die Lesetransaktion registriert ist, unberührt. Weder die globalen AStat noch die AResp Antworten sind von der Kollision betroffen. Wenn der Knoten- Controller über eine Lesetransaktion in Phase 2a verfügt und eine zu suchende DClaim Transaktion empfängt, gibt der Knoten-Controller keine "abschlägigen" Globalen AStat oder AResp Antworten für die Lesetransaktion aus. Die Globale AStat Antwort für die DClaim Transaktion ist von der Kollision nicht betroffen, doch die Globale AResp Antwort für die DClaim Transaktion empfängt ein Retry vom Knoten- Controller.

Wenn der Knoten-Controller über eine Lesetransaktion in Phase 3 oder Phase 4 verfügt und eine zu suchende DClaim Transaktion empfängt, gibt der Knoten-Controller keine "abschlägigen" Globalen AStat oder AResp Antworten für die Lesetransaktion aus. Die Globale AStat Antwort für die DClaim Transaktion ist jedoch von der Kollision nicht betroffen, doch die Globale AResp Antwort für die DClaim Transaktion empfängt in jedem Fall ein Retry vom Knoten-Controller. Diese Retries sind in beiden Fällen nicht konditional.

Durch Vergleich der Tabellen in den Fig. 12A und 12B kann beobachtet werden, dass die Tabellen keine gespiegelten Abbildungen voneinander sind, d. h. das Muster der Antworten für ein Paar kollidierender Transaktionen muss nicht unbedingt symmetrisch sein. Solche Antworten können vorberechnet und codiert werden und diese Codes können in einem ROM als Teil eines Mikroprogramms gespeichert werden. Wenn eine Kollision stattfindet, kann auf das entsprechende Mikrowort zugegriffen werden, um die notwendigen Antworten neu zu generieren. Alternativ dazu können die Antworten unter Verwendung logischer Gates fest codiert werden.

Methode zur Implementierung eines RemStat Protokoll unter Einbeziehung und Nicht-Einbeziehung von L1-Daten in L2-Cache zur Verhinderung von gegenseitigen Lesesperren

In einem verteilten Multibus- und Multiprozessorsystem kann beim Versuch einer Implementierung des RemStat Protokolls mit zwei potentiellen Problemen gerechnet werden. RemStat AResp wird nur für cachebares kohärentes Lesen definiert und zeigt dem die Antwort ausgebenden Prozessor an, dass der Status der Cachezeile zusammen mit der ersten Datenlieferung festgehalten werden wird. Die Statusinformationen werden über die DCache_Leitung geliefert, die Teil der 6XX- Busschnittstelle ist. Diese Art der Antwort wird nur von einer Busbrücke oder einen Brückenchip, wie etwa dem oben beschriebenen Knoten-Controller im System ausgegeben, um anzuzeigen, dass der Status der in der Lesetransaktion angeforderten Cachezeile nicht zur Hand und im AResp Fenster nicht bestimmbar ist, d. h. das Fenster Primary Response der Lesetransaktion.

Das erste potentielle Problem kann auftreten, wenn die Prozessoren oder Master-Geräte im verteilten Multibus- und Multiprozessorsystem unter Einbeziehung von L1-Daten im L2 Cache arbeiten. In der Standard-Implementierung des RemStat Protokolls, wenn ein Prozessor ein RemStat AResp als Antwort auf ein Lesen ausgibt, wird der Prozessor kritisch, d. h. er unterstellt Eigentum an der in der Lesetransaktion angeforderten Cachezeile, unabhängig vom Status der Cachezeile innerhalb der Caches des Prozessors. Der anfordernde Prozessor gibt ein Retry für jede Anforderung für die Cachezeile von einem anderen Prozessor aus, bis der anfordernde Prozessor die angeforderte Cachezeile empfangen hat. Wenn ein anderer Prozessor ebenfalls eine Lesetransaktion an die gleiche Cachezeile ausgibt und einen RemStat AResp empfängt, wird dieser Prozessor kritisch. Ein Prozessor wird kritisch und wiederholt eine andere Anforderung an der gleichen Cachezeile, um die komplizierten Hardware-Aktionen zu umgehen, die notwendig werden, wenn eine Suche eine Änderung des Status der Cachezeile erfordert, von Shared in Invalid oder, noch schlimmer, von Geändert in Ungültig, während ein Lesen für die Cachezeile ansteht. Diese Bedingung von mehr als einem kritischen Prozessor mit anstehenden Lesetransaktionen für die gleiche Cachezeile kann in einem verteilten Multibus-, gemeinsam genutzten Speicher- Multiprozessorsystem leicht auftreten, wie beispielsweise beim oben beschriebenen System. Wenn die Leseanforderung von einem anfordernden Prozessor gesucht würde, erhielte die Leseanforderung ein Retry, da ein anderer anfordernder Prozessor in der Cachezeile bereits kritisch geworden wäre. Eine gegenseitige Lesesperre würde dazu führen, dass jede Lesetransaktion ein Retry von einem anderen Prozessor erhielte.

Für dieses erste mögliche Problem einer gegenseitigen Lesesperre zwischen Lesetransaktionen, angefordert von Master-Geräten, die unter Einbeziehung von L1-Daten in L2- Cache in einem verteilten Multibus- und Multiprozessorsystem unter Implementierung des RemStat Protokolls arbeiten, erfordert es eine allgemeingültige Lösung, dass ein Master- Gerät, das eine Lesetransaktion ausgegeben hat, keine kollidierende Lesetransaktion erhalten darf. Dies verhindert, dass mehr und mehr Master-Geräte kritisch werden und daher wird die Entstehung einer gegenseitigen Lesesperrbedingung verhindert.

Im oben beschriebenen verteilten Multiprozessorsystem unterstützen die Knoten-Controller bei dieser Art von Prävention eine Sperrbedingung bei der Blockierung einer Lesetransaktion, die potentiell mit einer anstehende Lesetransaktion kollidieren würde, so dass jene nicht an ein Master-Gerät gesendet würde, welches die anstehende Lesetransaktion ausgegeben hat. Mit anderen Worten, der Knoten-Controller blockiert selektiv kollidierende Transaktionen, wo dies erforderlich wird.

Im allgemeinen jedoch wird in einem verteilten Multibus- und Multiprozessorsystem die gegenseitige Lesesperrbedingung umgangen, indem sichergestellt wird, dass der Prozessor mit einer anstehenden Lesetransaktion keine kollidierende Lesetransaktion erhält.

Fig. 13 zeigt ein Flussdiagramm mit einem Prozess innerhalb eines Knoten-Controllers zum Verhindern einer gegenseitigen Lesesperrbedingung zwischen Master-Geräten, die unter Einbeziehung von L1-Daten in L2-Cache arbeiten. Die im Flussdiagramm aufgeführten Schritte zeigen nur einige der Aktionen des Knoten-Controllers und beschränken sich in der Auflistung nicht auf alle Aktionen, die vom Knoten-Controller in dieser Situation ausgeführt werden. Die Knoten-Controller führt beispielsweise zusätzlich einige der bezüglich den Fig. 11 und 12 beschriebenen Schritte aus.

Der Prozess beginnt damit, dass der Knoten-Controller eine Lesetransaktion für eine bestimmte Cachezeile von einem Prozessor innerhalb des Knoten empfängt (Schritt 1302). Der Knoten-Controller gibt ein RemStat AResp an den anfordernden Prozessor aus (Schritt 1304) und der Knoten-Controller registriert anschließend die Transaktion und stellt sie zur weiteren Verarbeitung in die Warteschlange (Schritt 1306). Zu einem späteren Zeitpunkt empfängt der Knoten-Controller eine gesuchte Transaktion von einem anderen Prozessor (Schritt 1308). Der Knoten-Controller bestimmt, ob die Transaktion eine nicht-kollidierende Transaktion ist (Schritt 1312). Der Prozess ist dann abgeschlossen, hinsichtlich der erforderlichen Verarbeitung des Knoten-Controllers für die nicht-kollidierende, gesuchte Transaktion.

Wenn es sich bei der empfangenen Transaktion um eine kollidierende Transaktion handelt, bestimmt der Knoten- Controller, ob es sich um eine Nicht-Lesetransaktion handelt (Schritt 1314). Wenn dies der Fall ist, leitet der Knoten- Controller die kollidierende Nicht-Lesetransaktion weiter (Schritt 1316). Der Prozess ist abgeschlossen, hinsichtlich des erforderlichen Prozesses für den Knoten-Controller für die kollidierende Nicht-Lesetransaktion.

Wenn die gesuchte Lesetransaktion mit der Lesetransaktion kollidiert, die zuvor registriert wurde, blockiert der Knoten-Controller die gesuchte Lesetransaktion vom Prozessor, der die registrierte Lesetransaktion ausgegeben hat, indem der ursprüngliche Transaktionstypcode der gesuchten Transaktion, d. h. ein Lesetransaktionstypcode, gegen einen Nulltransaktionstypcode ausgetauscht wird (Schritt 1318). Der Knoten-Controller sendet dann die geänderte Kopie der gesuchten Transaktion und die unveränderten Kopien der gesuchten Transaktion an die Prozessoren im Knoten (Schritt 1320). Der Knoten-Controller trägt anschließend zur Globalen Antwort der gesuchten Transaktion bei, so dass die Kollision zu einer gemeinsam genutzten AResp Antwort führt (Schritt 1322). Der Prozess ist dann hinsichtlich der erforderlichen Verarbeitung des Knoten-Controllers beendet.

Ein Knoten-Controller ist in der Lage, eine Transaktion für einen speziellen Port auf die folgende Art zu blockieren. In Fig. 6 passieren Befehle an Prozessoren/Master-Geräte einen Multiplexer pro Port, wie etwa Steuereinheiten/Multiplexer 629-632. Der Knoten-Controller 600 ist in der Lage, den Transaktionstypcode einer Transaktion über den geeigneten Gebrauch von Steuersignalen 635 zu ändern. Wenn der Knoten- Controller bestimmt, dass die Blockierung eines bestimmten Master-Geräts für den Empfang einer gesuchten Transaktion blockiert werden soll, so dass das Master-Gerät die Transaktion nicht "sieht", ändert der Knoten-Controller an der entsprechenden Steuereinheit/Multiplexer den Transaktionstypcode der Transaktion, die an das bestimmte Master-Gerät gesendet wird. Durch Ersetzen des Transaktionstypcodes durch einen Nulltransaktionstypcode, sollte das Master-Gerät, das die Nulltransaktion empfängt, eine zustimmende Antwort für die Transaktion bereitstellen, auch wenn das Master-Gerät über eine anstehende, kollidierende Transaktion verfügt. Statt zuzulassen, dass das Master-Gerät eine Antwort für die kollidierende Transaktion bereitstellt, wodurch eine gegenseitige Lesesperrbedingung verursacht würde, gibt der Knoten-Controller ein entsprechendes Signal an die Globale Antwort für die kollidierende Transaktion aus. Durch Blockieren der Transaktionen auf diese Weise stellt der Knoten-Controller sicher, dass die kollidierenden Lesetransaktionen mit einer Antwort Shared passieren und der Speicher sendet eine Kopie der Daten für jede einzelne Lesetransaktion.

Wie oben erläutert, ist für die Lösung des ersten potentiellen Problems einer gegenseitigen Lesesperrbedingung zwischen Lesetransaktionen, angefordert von Master-Geräten, die unter Einbeziehung von L1-Daten in L2-Caches in einem verteilten Multibus- und Multiprozessorsystem mit implementiertem RemStat Protokoll erforderlich, dass ein Master-Gerät, das eine Lesetransaktion ausgegeben hat, keine kollidierende Lesetransaktion empfängt. Im allgemeinen Fall bedeutet der Begriff "Blockieren", dass ein Empfang einer kollidierenden Lesetransaktion für eine der anstehenden Transaktionen von einem Master-Gerät verhindert wird, was ansonsten dazu führen würde, dass das Master-Gerät kritisch werden würde. Für das verteilte Multibus- und Multiprozessorsystem oben können die Knoten-Controller Transaktionen für bestimmte Ports "blockieren", womit auch das Master-Gerät blockiert wird. Im allgemeinen Fall jedoch wäre die Systemkomponente, die eine Brücke zwischen Busdomänen in einem verteilten Multibus- und Multiprozessorsystem bietet, ansprechbar für blockierende, kollidierende Transaktionen in der entsprechenden Weise. Es sollte erwähnt werden, dass die RemStat-verbundene Logik vorberechnet und codiert werden kann und diese Codes können in einem ROM als Teil eines Mikroprogramms gespeichert werden. Wenn Transaktionen verarbeitet werden, kann auf das entsprechende Mikrowort zugegriffen werden, um die notwendigen Antworten zu generieren. Alternativ dazu können die Antworten über logische Gates fest codiert werden. Wie zuvor erwähnt, können zwei potentielle Probleme auftreten, wenn ein Versuch zum Implementieren des RemStat Protokolls unternommen wird. Die oben beschriebenen Prozesse verhindern das erste potentielle Problem, in dem eine gegenseitige Lesesperrbedingung auftreten kann, wenn die Prozessoren oder Master-Geräte in einem verteilten Multibus- und Multiprozessorsystem unter Einbeziehung von L1-Daten in L2-Cache arbeiten. Das zweite potentielle Problem kann auftreten, wenn die Prozessoren oder Master-Geräte im verteilten Multibus- und Multiprozessorsystem unter Nicht- Einbeziehung von L1-Daten in L2-Cache arbeiten und in dem ein Prozessor ein Lesen einer Cachezeile generieren kann, die sich im L1-, und nicht im L2-Cache befindet. Diese Situation kann auftreten aufgrund von Vorablesezugriffsmöglichkeiten innerhalb des Prozessors. Wie oben erwähnt, kann eine gegenseitige Lesesperrbedingung, in der mehr als ein Prozessor kritisch wird, mit ausgegebenen Lesetransaktionen, die für die gleiche Cachezeile anstehend ist, leicht auftreten, wie in dem oben beschriebenen System. Wenn die Leseanforderung von einem anfordernden Prozessor in einem ähnlichen Prozessor gesucht würde, würde die Leseanforderung ein Retry empfangen, da ein anderer anfordernder Prozessor für die Cachezeile bereits kritisch geworden wäre. Eine gegenseitige Lesesperre würde sich ergeben, wobei jede Lesetransaktion ein Retry von einem anderen Prozessor empfangen würde.

In der Lösung für das erste Problem wurde eine kollidierende gesuchte Lesetransaktion von einem Prozessor blockiert, der eine kollidierende Transaktion ausgegeben hat, so dass der Prozessor keine Transaktionsantwort bereitgestellt hat, die eine Sperrbedingung generiert hat. Beim zweiten Problem ist eine Blockierung einer kollidierenden Lesesuche von einem Prozessor, der bereits über einen anstehenden Lesevorgang für die gleiche Cachezeile verfügt, nicht ausreichend in der Situation, in der ein anfordernder Prozessor die Cachezeile in seinem L1-Cache geändert hat, da die Kopie der Cachezeile im Speicher veraltet ist. In diesem Szenario, wenn die gesuchte Lesetransaktion von dem Prozessor blockiert wurde, der über die aktuelle Kopie der Cachezeile verfügt, würde der anfordernde Prozessor nicht darüber benachrichtigt, dass ein anderer Prozessor über eine aktuelle Kopie der Cachezeile verfügt. Statt dessen müssen die Daten, die an einen anfordernden Prozessor gegeben werden, eine aktuelle Kopie der Daten sein, die beim anderen Prozessor zur Verfügung stehen, der über die geänderte Cachezeile in seinem L1-Cache verfügt.

Um dieses potentielle zweite Problem zu lösen, ist es für die Prozessoren in einem verteilten Multibus- und Multiprozessorsystem erforderlich, nicht kritisch zu werden beim Empfang eines RemStat AResp Signals für die eigenen Lesevorgänge. Zusätzlich ist es für die Prozessoren erforderlich, die folgenden Busprotokollfunktionen beim Empfang einer gesuchten Transaktion zu implementieren. Es sollte erwähnt werden, dass diese Anforderungen vorberechnet und codiert werden können und diese Codes können in einem ROM als Teil eines Mikroprogramms in einem Prozessor oder Master-Gerät gespeichert werden. Alternativ dazu können die Antworten unter Verwendung eines logischen Gates fest codiert werden.

a) Falls der Prozessor über keine Kopie der Cachezeile in einem Cache und über keine anstehende Lesetransaktion verfügt, muss der Prozessor ein Null AResp erstellen.
b) Falls der Prozessor über keine Kopie der Cachezeile in einem Cache und über eine anstehende Lesetransaktion verfügt, muss der Prozessor eine Null oder eine Shared AResp, kein Retry erstellen.
c) Falls der Prozessor über eine Kopie der Cachezeile in einem Status Shared und über eine anstehende Lesetransaktion verfügt, muss der Prozessor eine Shared AResp, kein Retry erstellen.
d) Falls der Prozessor über eine Kopie der Cachezeile in einem Status Exklusiv in einem Cache und über eine anstehende Lesetransaktion verfügt, muss der Prozessor eine Shared oder Retry AResp erstellen
e) Falls der Prozessor über eine Kopie der Cachezeile in einem Status Modified in einem Cache und über eine anstehende Lesetransaktion verfügt, muss der Prozessor ein Modiefed oder Retry AResp erstellen.
f) Falls der Prozessor über eine Kopie der Cachezeile in einem Status Exklusiv und nicht über eine anstehende Lesetransaktion verfügt, muss der Prozessor ein Shared AResp erstellen.
g) Falls der Prozessor über eine Kopie der Cachezeile in einem Status Modified in einem Cache und nicht über eine anstehende Lesetransaktion verfügt, muss der Prozessor ein Modified AResp erstellen.
Zusätzlich zu den oben genannten Änderungen verfügt die Brücke über die folgenden Busprotokollanforderungen:
h) Falls der Prozessor über eine anstehende Lesetransaktion verfügt, die mit einer Lesetransaktion kollidiert, muss die Brücke, die ein RemStat AResp an den Prozessor für den Lesevorgang ausgibt, ein Shared AResp an die gesuchte Lesetransaktion erstellen.
i) Falls der Prozessor über eine anstehende Lesetransaktion verfügt, mit einer gesuchten Nicht-Lesetransaktion kollidiert, muss die Brücke, die ein RemStat AResp an den Prozessor für seinen Lesevorgang ausgegeben hat, ein Retry AResp an die gesuchte Nicht-Lesetransaktion ausgeben.

Da die Brücke die Transaktion in diesem Fall wiederholen wird, hat der Prozessor keine besondere Anforderung zum Antworten auf die Transaktion in diesem Fall. Wenn die Nicht- Lesetransaktion nicht mit einer Transaktion des Prozessors kollidiert, kann der Prozessor mit einer entsprechenden Antwort reagieren.

Es ist zu beachten, dass in dem Falle, in dem die Prozessoren des verteilten Multibus- und Multiprozessorsystems diese RemStat-verbundenen Anforderungen im vollen Umfang implementieren, kein Bedarf mehr besteht, den Transaktionstyp zu blockieren, wenn die Prozessoren unter Einbeziehung oder Nicht-Einbeziehung arbeiten; die zuvor beschriebene gegenseitige Lesesperrbedingung tritt dann nicht ein. Somit können zwei verschiedene Lösungen für die potentielle gegenseitige Lesesperrbedingung implementiert werden: Falls die Prozessoren die RemStat-verbundenen Anforderungen nicht implementieren, müssen sie unter Einbeziehung arbeiten und es muss eine Blockierung im Brückenchip implementiert sein, d. h. in den Knoten-Controllern im verteilten Multibus- und Multiprozessorsystem, wie oben beschrieben. Wenn die Prozessoren die RemStat-verbundenen Anforderungen umfassen, können die Prozessoren ohne Einbeziehung arbeiten und keine externe Logik ist erforderlich, um diese Lese-Lese-Kollision zu erkennen und kollidierende Lesetransaktionen zu blockieren.

Unter Nicht-Einbeziehung von L1-Daten in L2-Cache muss Lesetransaktionen zur Ausführung im System Priorität eingeräumt werden, alle Lesetransaktionen müssen ausgeführt werden, bevor irgendein anderer Typ von Transaktion ausgeführt wird. Mit anderen Worten, Nicht-Lesetransaktionen können keinen Retry für eine Lesetransaktion herbeiführen und alle Nicht-Lesetransaktionen sind ausgegebene Retries durch Lesetransaktionen. Diese Anforderung wird von entsprechend konfigurierten Steuertabellen unterstützt, wie beispielsweise jene in den Fig. 12A und 12B oben.

Unter Einbeziehung von L1-Daten im L2-Cache ist für einen Prozessor, der eine Transaktion für eine bestimmte Cachezeile anfordert, sichergestellt, dass sich die Cachezeile nicht in seinem Cache oder seinen Caches befindet. In diesem Beispiel ist es möglich, eine der folgenden Aktionen auszuführen: Lesetransaktionen erhalten eine höhere Priorität als jeder andere Transaktionstyp, wie etwa die oben beschriebenen Aktionen für Nicht-Einbeziehung, oder andere Typen von Transaktionen erhalten eine höhere Priorität als Lesetransaktionen. Letzteres impliziert, dass das System Aktionen ausführt, die umgekehrt zu den oben beschriebenen unter Nicht-Einbeziehung stehen. Alternativ dazu können einige Typen von Transaktion eine höhere Priorität als die Lesetransaktionen erhalten, während andere Transaktionen keine höhere Priorität als die Lesetransaktionen erhalten. Fig. 14 zeigt ein Flussdiagramm mit einem Prozess innerhalb eines Knoten-Controllers zum Verhindern einer gegenseitigen Lesesperrbedingung zwischen Master-Geräten, die unter Nicht- Einbeziehung von L1-Daten in L2-Cache arbeiten. Die gezeigten Schritte im Flussdiagramm zeigen nur einige der Aktionen des Knoten-Controllers und erheben keine Anspruch auf Vollständigkeit bei der Auflistung aller ausgeführten Aktionen durch den Knoten-Controller in dieser Situation. Beispielsweise führt der Knoten-Controller zusätzlich einige der in Fig. 11 und 12 beschriebenen Schritte aus. Der Prozess beginnt mit dem Knoten-Controller, der eine Lesetransaktion für eine bestimmte Cachezeile von einem Prozessor innerhalb des Knoten empfängt (Schritt 1402). Der Knoten-Controller gibt ein RemStat AResp an den anfordernden Prozessor aus (Schritt 1404) und der Knoten-Controller registriert dann die Transaktion und stellt sie zur weiteren Verarbeitung in die Warteschlange (Schritt 1406). Zu einem späteren Zeitpunkt empfängt der Knoten-Controller eine gesuchte Transaktion von einem anderen Prozessor (Schritt 1408). Der Knoten-Controller ermittelt, ob es sich bei der Transaktion um eine nicht-kollidierende Transaktion handelt (Schritt 1410). Wenn dies der Fall ist, leitet der Knoten-Controller die nicht-kollidierende Transaktion weiter (Schritt 1412). Der Prozess ist dann hinsichtlich der erforderlichen Verarbeitung des Knoten-Controllers für die nicht-kollidierende gesuchte Transaktion ausgeführt. Wenn es sich bei der empfangenen Transaktion um eine kollidierende Transaktion handelt, ermittelt der Knoten- Controller, ob es sich um eine Lesetransaktion handelt (Schritt 1414). Wenn dies der Fall ist, leitet der Knoten- Controller die kollidierenden Lesetransaktion weiter (Schritt 1416). Der Prozess ist dann hinsichtlich der erforderlichen Verarbeitung des Knoten-Controllers für die kollidierende Lesetransaktion ausgeführt.

An diesem Punkt hat der Knoten-Controller festgestellt, dass es sich bei der empfangenen Transaktion um eine kollidierende Nicht-Lesetransaktion handelt. In einem optionalen Schritt blockiert der Knoten-Controller zunächst die Transaktion vom Prozessor, der die kollidierende registrierte Lesetransaktion ausführt, d. h. dem Prozessor, der den in der lokalen Warteschlange innerhalb des Knoten-Controllers befindlichen Lesevorgang ausgegeben hat, durch Ersetzen des ursprünglichen Transaktionstypcodes der Nicht-Lesetransaktion durch einen Nulltransaktionstypcode (Schritt 1418).

Der Knoten-Controller leitet die Transaktion wie erforderlich weiter (Schritt 1420). Falls beispielsweise der Knoten- Controller die Transaktion blockiert hat, leitet der Knoten- Controller die geänderte Kopie der gesuchten Transaktion an den Prozessor weiter, durch den die Transaktion blockiert wurde und leitet andere Kopien der unveränderten, gesuchten Transaktion an die anderen Prozessoren des Knotens weiter. Wenn andernfalls der Knoten-Controller die Transaktion nicht blockiert hat, leitet der Knoten-Controller Kopien der gesuchten Transaktion an die Prozessoren des Knotens weiter. In jedem Fall berechnet der Knoten-Controller anschließend eine Global Response of Retry für die gesuchte Transaktion (Schritt 1422). Der Prozess ist dann hinsichtlich der erforderlichen Verarbeitung des Knoten-Controllers ausgeführt.

Mit diesen Regeln, auch unter Nicht-Einbeziehung, wenn mehrere Prozessoren versuchen, zu selben Zeit die gleiche Zeile zu lesen, wird in den meisten Fällen mit einem Retry reagiert. Daher empfängt die Lesetransaktion von einem der Prozessoren keinen Retry von dem anderen Prozessor und die anstehende Lesetransaktion schreitet voran, was eine potentielle gegenseitige Lesesperrbedingung verhindert. Die Vorteile der vorliegenden Erfindung sollten durch die oben gegebene detaillierte Beschreibung klar geworden sein. Die vorliegende Erfindung ermöglicht ein Skalieren standardisierter und leichter zu prüfender Protokolle in einem weitreichenden Multibus- und Multiprozessorsystem, durch dessen großen Umfang normalerweise physische Busse zu einem uneffizienten Medium zur Kommunikation zwischen Systemkomponenten werden, wie etwa Prozessoren, Speichersubsysteme oder E/A Agents. Durch Verwendung der verteilten Systemstruktur der vorliegenden Erfindung wird die Entwicklung weiterer komplizierter verzeichnisbasierter Protokolle usw. überflüssig. Die vorliegende Erfindung ermöglicht es Komponentenschnittstellen ebenfalls, einen schnelleren Takt anzunehmen als er mit einem Einzelbus möglich wäre, wobei gleichzeitig die Bandbreiten der Komponentenschnittstellen erweitert werden und eine höhere gesamte Systembandbreite und Leistung erzielt wird. Die vorliegende Erfindung unterstützt mehrere Datenbusse, wobei die Datenbandbreite des Systems vervielfacht wird und die Effizienz des Prozessors erhöht wird. Der parallele Datentransfer der vorliegenden Erfindung verbessert ebenfalls den gesamten Datendurchsatz des Systems.

Es ist zu erwähnen, dass die vorliegenden Erfindung zwar im Kontext eines voll funktionierenden Datenverarbeitungssystems beschrieben wurde, es den Fachleuten klar sein sollte, dass die Prozesse der vorliegenden Erfindung in Form eines computerlesbaren Mediums von Anweisungen und einer Vielzahl weiterer Formen verteilt werden können, und dass die vorliegende Erfindung auch Anwendung finden kann, unabhängig vom Medium mit speziellem Signaltyp, der zur Verteilung eingesetzt wird. Beispiele für computerlesbare Medien umfassen Medien zur Aufzeichnung, wie etwa Floppy Disc, Festplattenlaufwerke, RAM und CD ROMs und Übertragungsmedien, wie digitale und analoge Kommunikations-Verknüpfungen. Die Beschreibung der vorliegenden Erfindung dient der Illustration und Beschreibung, erhebt jedoch keinerlei Anspruch, die offengelegte Erfindung darauf zu beschränken. Es ist eine Vielzahl an Änderungen oder Abweichungen für den Fachmann denkbar. Das Ausführungsbeispiel wurde ausgewählt und beschrieben, um die Prinzipien und die praktische Umsetzung der Erfindung bestmöglich zu erläutern und die Erfindung anderen Fachleuten nahe zu bringen, mit verschiedenen Änderungen, wie sie je nach Anwendungsgebiet möglich werden könnten.

Claims

1. Eine Methode zur Unterstützung der Cache-Kohärenz in einem Multiprozessorsystem, wobei die Methode die folgenden Schritte umfasst:
Empfang einer ersten Transaktion von einem ersten Anforderer;
Bereitstellen einer Kohärenz-Antwort zur Anzeige von Statusinformationen für Daten, die von der ersten Transaktion gelesen werden und mit den Daten geliefert werden;
Empfang einer zweiten Transaktion von einem zweiten Anforderer, wobei der erste Anforderer und der zweite Anforderer zusammenarbeiten, unter Verwendung eines ersten oder zweiten Cachearbeitsmodus; und
Verarbeiten der zweiten Transaktion auf der Grundlage eines Transaktionstypcodes der zweiten Transaktion und einer Kollisionsbedingung zwischen der ersten Transaktion und der zweiten Transaktion.

2. Die Methode nach Anspruch 1, weiterhin folgendes umfassend: Bereitstellen der Kohärenz-Antwort an den ersten Anforderer in einem Fenster Primary Response der ersten Transaktion.

3. Die Methode nach Anspruch 1, wobei es sich bei der Kohärenz-Antwort um ein RemStat AResp Antwortsignal handelt.

4. Die Methode nach Anspruch 1, weiterhin folgendes umfassend: In Reaktion auf die Feststellung, dass die zweite Transaktion nicht mit der ersten Transaktion kollidiert, Weiterleiten der zweiten Transaktion zum ersten Anforderer.

5. Die Methode nach Anspruch 4, weiterhin folgendes umfassend: Weiterleiten der zweiten Transaktion an andere Master- Geräte im Multiprozessorsystem.

6. Die Methode nach Anspruch 1, wobei der erste Cachearbeitsmodus die Einbeziehung von Level 1-Cache (L1)-Daten im Level-2-Cache vorsieht.

7. Die Methode nach Anspruch 6, weiterhin folgendes umfassend: Blockieren der zweiten Transaktion vom ersten Anforderer.

8. Die Methode nach Anspruch 7, wobei es sich bei der ersten Transaktion um eine Lesetransaktion handelt.

9. Die Methode nach Anspruch 7, wobei es sich bei der zweiten Transaktion um eine Lesetransaktion handelt, die mit der ersten Transaktion kollidiert.

10. Die Methode nach Anspruch 7, wobei es sich bei der ersten Transaktion um eine Lesetransaktion und bei der zweiten Transaktion um eine Lesetransaktion handelt, die mit der ersten Transaktion kollidiert.

11. Die Methode nach Anspruch 6, weiterhin folgendes umfassend: Blockieren der zweiten Transaktion vom ersten Anforderer durch Ändern der zweiten Transaktion, um den Transaktionstypcode der zweiten Transaktion durch einen Nulltransaktionstypcode zu ersetzen.

12. Die Methode nach Anspruch 11, wobei es sich bei der ersten Transaktion um eine Lesetransaktion handelt.

13. Die Methode nach Anspruch 11, wobei es sich bei der zweiten Transaktion um eine Lesetransaktion handelt, die mit der ersten Transaktion kollidiert.

14. Die Methode nach Anspruch 11, wobei es sich bei der ersten Transaktion um eine Lesetransaktion handelt und auch bei der zweiten Transaktion um eine Lesetransaktion handelt, die mit der ersten Transaktion kollidiert.

15. Die Methode nach Anspruch 11, weiterhin folgendes umfassend: Weiterleiten der geänderten zweiten Transaktion an den ersten Anforderer.

16. Die Methode nach Anspruch 11, weiterhin folgendes umfassend: Weiterleiten einer zweiten Transaktion an andere Master-Geräte im Multiprozessorsystem.

17. Die Methode nach Anspruch 6, weiterhin folgendes umfassend: Ausgeben einer Antwort Shared an den zweiten Anforderer in einem Fenster Global Response der zweiten Transaktion.

18. Die Methode nach Anspruch 6, weiterhin folgendes umfassend: In Reaktion auf eine Feststellung, dass die zweite Transaktion eine Nicht-Lesetransaktion ist, Weiterleiten der zweiten Transaktion an den ersten Anforderer.

19. Die Methode nach Anspruch 18, weiterhin folgendes umfassend: Weiterleiten der zweiten Transaktion an andere Master- Geräte im Multiprozessorsystem.

20. Die Methode nach Anspruch 1, wobei der zweite Cachearbeitsmodus die Nicht-Einbeziehung von Level 1- Cache (L1)-Daten in Level 2-Cache (L2) vorsieht.

21. Die Methode nach Anspruch 20, weiterhin folgendes umfassend: Blockieren der zweiten Transaktion vom ersten Anforderer.

22. Die Methode nach Anspruch 21, wobei es sich bei der ersten Transaktion um eine Lesetransaktion handelt.

23. Die Methode nach Anspruch 21, wobei es sich bei der zweiten Transaktion um eine Lesetransaktion handelt, die mit der ersten Transaktion kollidiert.

24. Die Methode nach Anspruch 21, wobei es sich bei der ersten Transaktion um eine Lesetransaktion und bei der zweiten Transaktion um eine Nicht-Lesetransaktion handelt, die mit der ersten Transaktion kollidiert.

25. Die Methode nach Anspruch 20, weiterhin folgendes umfassend: Blockieren der zweiten Transaktion vom ersten Anforderer durch Ändern der zweiten Transaktion, um den Transaktionstypcode der zweiten Transaktion durch einen Nulltransaktionstypcode zu ersetzen.

26. Die Methode nach Anspruch 25, wobei es sich bei der ersten Transaktion um eine Lesetransaktion handelt.

27. Die Methode nach Anspruch 25, wobei es sich bei der zweiten Transaktion um eine Nicht-Lesetransaktion handelt, die mit der ersten Transaktion kollidiert.

28. Die Methode nach Anspruch 25, wobei es sich bei ersten Transaktion um eine Lesetransaktion und bei der zweiten Transaktion um eine Nicht-Lesetransaktion handelt, die mit der ersten Transaktion kollidiert.

29. Die Methode nach Anspruch 25, weiterhin folgendes umfassend: Weiterleiten der geänderten zweiten Transaktion an den ersten Anforderer.

30. Die Methode nach Anspruch 25, weiterhin folgendes umfassend: Weiterleiten der zweiten Transaktion an andere Master- Geräte im Multiprozessorsystem.

31. Die Methode nach Anspruch 20, weiterhin folgendes umfassend: Ausgeben einer Antwort Retry an den zweiten Anforderer in einem Fenster Global Response der zweiten Transaktion.

32. Die Methode nach Anspruch 20, weiterhin folgendes umfassend: In Reaktion auf die Feststellung, das es sich bei der zweiten Transaktion um eine Nicht-Lesetransaktion handelt, Weiterleiten der zweiten Transaktion an den ersten Anforderer.

33. Die Methode nach Anspruch 32, weiterhin folgendes umfassend: Weiterleiten der zweiten Transaktion an andere Master- Geräte im Multiprozessorsystem.

34. Die Methode nach Anspruch 1, weiterhin folgendes umfassend: Empfang der ersten Transaktion und der zweiten Transaktion an einem Knoten-Controller.

35. Die Methode nach Anspruch 1, wobei das Multiprozessorsystem folgendes umfasst:
Den Knoten-Controller;
Eine Vielzahl an Master-Geräten; und
Eine Vielzahl an bidirektionalen Master-Gerätebussen, wobei ein Master-Gerätebus ein oder mehrere Master- Geräte innerhalb eines Knoten mit dem Port eines Knoten- Controllers verbindet.

36. Die Methode nach Anspruch 35, wobei der Knoten- Controller folgendes umfasst:
Eine Vielzahl an Master-Geräte-Ports, wobei jeder Master-Geräte-Port mit einem Master-Gerätebus verbunden ist;
Ein Paar von Adressschalterports, wobei jeder Adressschalterport mit einem Paar aus unidirektionalen Adressschalterbussen verbunden ist, wobei eines der Paare der Adressschalterbusse eine Adresse vom Knoten- Controller zum Adressschalter weitergibt und ein Paar aus Adressschalterbussen eine Adresse vom Adressschalter zum Knoten-Controller weitergibt; und
Eine Vielzahl an Speichersubsystemports, wobei jeder Speichersubsystemport mit einem bidirektionalen Speichersubsystembus verbunden ist, wobei ein Speichersubsystembus Daten zwischen dem Knoten- Controller und einem der Speichersubsysteme weiterleitet.

37. Eine Methode zur Unterstützung der Cache-Kohärenz in einem Multiprozessorsystem, wobei die Methode die folgenden Schritte umfasst:
Anfordern einer Lesetransaktion;
In Reaktion auf den Empfang einer Kohärenz-Antwort Anzeigen von Statusinformationen für Daten, die von der Lesetransaktion zu lesen sind und mit den Daten zusammen bereitgestellt werden, ohne dass ein kritischer Zustand erreicht wird.

38. Die Methode nach Anspruch 37, weiterhin folgendes umfassend: Empfang der Kohärenz-Antwort in einem Fenster Primary Response der Lesetransaktion.

39. Die Methode nach Anspruch 37, wobei die Kohärenz-Antwort ein RemStat AResp Befehlsantwortsignal ist.

40. Die Methode nach Anspruch 37, weiterhin folgendes umfassend: Empfang einer gesuchten Transaktion für eine Cachezeile.

41. Die Methode nach Anspruch 40, weiterhin folgendes umfassend: In Reaktion auf die Feststellung, dass der Prozessor nicht über eine Kopie der Cachezeile in einem Cache und nicht über eine anstehende, kollidierende Lesetransaktion verfügt, Erstellen einer Null AResp für die gesuchte Transaktion.

42. Die Methode nach Anspruch 40, weiterhin folgendes umfassend: In Reaktion auf eine Feststellung, dass der Prozessor nicht über eine Kopie der Cachezeile in einem Cache, aber über eine anstehende kollidierende Lesetransaktion verfügt, Erstellen einer Null oder Shared AResp für die gesuchte Transaktion.

43. Die Methode nach Anspruch 40, weiterhin folgendes umfassend: In Reaktion auf die Feststellung, dass der Prozessor über eine Kopie der Cachezeile in einem Status Shared in einem Cache und über eine anstehende, kollidierende Lesetransaktion verfügt, Erstellen einer Shared AResp für die gesuchte Transaktion.

44. Die Methode nach Anspruch 40, weiterhin folgendes umfassend: In Reaktion auf die Feststellung, dass der Prozessor über eine Kopie der Cachezeile in einem Status Exclusive oder Modified in einem Cache und über eine anstehende, kollidierende Lesetransaktion verfügt, Erstellen einer Shared oder Retry AResp für die gesuchte Transaktion.

45. Die Methode nach Anspruch 40, weiterhin folgendes umfassend: In Reaktion auf die Feststellung, dass der Prozessor über eine Kopie der Cachezeile in einem Status Modified in einem Cache und über eine anstehende, kollidierende Lesetransaktion verfügt, Erstellen einer Modified oder Retry AResp für die gesuchte Transaktion.

46. Die Methode nach Anspruch 40, weiterhin folgendes umfassend: In Reaktion auf die Feststellung, dass der Prozessor über eine Kopie der Cachezeile in einem Status Exclusive in einem Cache und über keine anstehende, kollidierende Lesetransaktion verfügt, Erstellen einer Shared AResp für die gesuchte Transaktion.

47. Die Methode nach Anspruch 40, weiterhin folgendes umfassend: In Reaktion auf die Feststellung, dass der Prozessor über eine Kopie der Cachezeile in einem Status Modified in einem Cache und nicht über eine anstehende, kollidierende Lesetransaktion verfügt, Erstellen einer Modified AResp für die gesuchte Transaktion.

48. Die Methode nach Anspruch 37, weiterhin folgendes umfassend: Empfang einer Kohärenz-Antwort von einem Knoten- Controller.

49. Ein Computerprogramm in einem computerlesbaren Medium zur Verwendung in einem Datenverarbeitungssystem zur Unterstützung der Cache-Kohärenz in einem Multiprozessorsystem, wobei das Computerprogramm folgendes umfasst:
Anweisungen zum Empfang einer ersten Transaktion von einem ersten Anforderer;
Anweisungen zum Bereitstellen einer Kohärenz-Antwort zur Anzeige von Statusinformationen für Daten, die von der ersten Transaktion gelesen werden und mit den Daten geliefert werden;
Anweisungen zum Empfang einer zweiten Transaktion von einem zweiten Anforderer, wobei der erste Anforderer und der zweite Anforderer zusammenarbeiten, unter Verwendung eines ersten oder zweiten Cache-Arbeitsmodus; und
Anweisungen zum Verarbeiten der zweiten Transaktion auf der Grundlage eines Transaktionstypcodes der zweiten Transaktion und einer Kollisionsbedingung zwischen der ersten Transaktion und der zweiten Transaktion.

50. Das Computerprogramm nach Anspruch 49, weiterhin folgendes umfassend: Anweisungen zum Bereitstellen der Kohärenz-Antwort an den ersten Anforderer in einem Fenster Primary Response der ersten Transaktion.

51. Das Computerprogramm nach Anspruch 49, wobei es sich bei der Kohärenz-Antwort um ein RemStat AResp Antwortsignal handelt.

52. Das Computerprogramm nach Anspruch 49, wobei der erste Cachearbeitsmodus die Einbeziehung von Level 1-Cache (L1)-Daten in Level 2-Cache (L2) vorsieht.

53. Das Computerprogramm nach Anspruch 52, wobei es sich bei der ersten Transaktion um eine Lesetransaktion und bei der zweiten Transaktion um eine Lesetransaktion handelt, die mit der ersten Transaktion kollidiert.

54. Das Computerprogramm nach Anspruch 53, weiterhin folgendes umfassend: Anweisungen zum Blockieren der zweiten Transaktion vom ersten Anforderer.

55. Das Computerprogramm nach Anspruch 53, weiterhin folgendes umfassend: Anweisungen zum Ausgeben einer Shared Antwort an den zweiten Anforderer in einem Fenster Global Response der zweiten Transaktion.

56. Das Computerprogramm nach Anspruch 49, wobei der zweite Cachearbeitsmodus die Nicht-Einbeziehung von Level-1- Cache (L1)-Daten in Level 2-Cache (L2) umfasst.

57. Das Computerprogramm nach Anspruch 56, wobei es sich bei der ersten Transaktion um eine Lesetransaktion und bei der zweiten Transaktion um eine Nicht-Lesetransaktion handelt, die mit der ersten Transaktion kollidiert.

58. Das Computerprogramm nach Anspruch 57, weiterhin folgendes umfassend: Anweisungen zum Blockieren der zweiten Transaktion vom ersten Anforderer.

59. Das Computerprogramm nach Anspruch 57, weiterhin folgendes umfassend: Anweisungen zum Ausgeben einer Retry Response an den zweiten Anforderer in einem Fenster Global Response der zweiten Transaktion.

60. Ein Computerprogramm in einem computerlesbaren Medium in einem Datenverarbeitungssystem zur Unterstützung von Cache-Kohärenz in einem Multiprozessorsystem, wobei das Computerprogramm folgendes umfasst:
Anweisungen zum Anfordern einer Lesetransaktion;
Anweisungen zum Verzichten auf kritischen Zustand in Reaktion auf den Empfang einer Kohärenz-Antwort, die Statusinformationen für Daten anzeigt, die von der Lesetransaktion gelesen werden sollen und zusammen mit dem Daten geliefert werden.

61. Das Computerprogramm nach Anspruch 60, weiterhin folgendes umfassend: Anweisungen zum Empfang der Kohärenz-Antwort in einem Fenster Primary Response der Lesetransaktion.

62. Das Computerprogramm nach Anspruch 60, wobei die Kohärenz-Antwort ein RemStat AResp Befehlsantwortsignal ist.

63. Das Computerprogramm nach Anspruch 60, weiterhin folgendes umfassend: Anweisungen zum Empfang einer gesuchten Transaktion für eine Cachezeile.

64. Das Computerprogramm nach Anspruch 60, weiterhin folgendes umfassend: Anweisungen zum Erstellen einer Antwort auf die gesuchte Transaktion auf der Grundlage eines Status einer Kopie der Cachezeile in einem Cache des Prozessors und aufgrund der Tatsache, ob ein Prozessor über eine anstehende kollidierende Transaktion verfügt.

65. Das Computerprogramm nach Anspruch 60, weiterhin folgendes umfassend: Anweisungen zum Empfang der Kohärenz-Antwort von einem Knoten-Controller.