Wenn mehrere Prozessoren an einer Aufgabe arbeiten sollen, muss die Verteilung der Aufgaben und der Zugriff auf Hilfsmittel geregelt werden. Selbst wenn der Programmierer dies schon vorab getan hat, werden im Betrieb dennoch Schwierigkeiten auftreten, wenn zwei Prozessoren zur gleichen Zeit ein bestimmtes Teil des Rechners benoetigen.
Der folgende Beitrag beschreibt die Loesung dieses Problems, die der Hersteller Concurrent in seinen Multiprozessor-Rechnern der Baureihe Maxion verwendet werden. IBM und Pyramid haben vergleichbare Plaene veroeffentlicht.
Seit dem Aufkommen der ersten Multiprozessor-Systeme vor etwa zehn Jahren hat sich das Konzept der "engen Kopplung" etabliert: Mehrere Prozessoren sowie das Ein- und Ausgabesubsystem greifen auf einen gemeinsamen Speicher (in DRAM-Technologie) zu und arbeiten parallel an verschiedenen Aufgaben. Die Verbindung zwischen Prozessoren, dem E/A-Subsystem und dem Speicher wird durch einen Bus (System-Bus) hergestellt. Diese Architektur ist in Abbildung 1 schematisch dargestellt.
Da der Zugriff auf den DRAM-Speicher viel Zeit kostet (etwa 70-80 Nanosekunden), erhaelt jeder Prozessor einen sehr schnellen Zwischenspeicher (Cache) in SRAM-Technologie, der einen Teil des Codes und der Daten bereithaelt. Geht man davon aus, dass in etwa 98 Prozent aller Faelle die benoetigten Daten im Cache liegen, dann muss nur bei jedem 50ten Schreib- und Lesevorgang auf Code oder Daten im DRAM-Speicher zurueckgegriffen werden. In einem Multiprozessor- System muss allerdings sichergestellt werden, dass zwei Prozessoren in ihrem Zwischenspeicher nicht unterschiedliche Kopien derselben Speicherzelle halten. Dies wird normalerweise durch ausgekluegelte Cache-Kohaerenzprotokolle gewaehrleistet: Jeder Transfer auf dem System-Bus wird von allen Prozessoren beobachtet, um festzustellen, ob die Daten im eigenen Cache betroffen sind ("Bus Snooping").
Das geschilderte Verfahren war in den vergangenen Jahren ausserordentlich erfolgreich. Heute bietet jeder namhafte Rechnerhersteller Multiprozessor-Computer mit diesem Konzept.
Voraussetzung fuer seinen Erfolg ist allerdings eine aehnliche Leistungsstaerke aller Komponenten: Prozessorleistung, Bandbreite des Bus-Systems und Zugriffszeit des Speichers. Durch die Weiterentwicklung der Prozessortechnologie, insbesondere durch das Aufkommen der RISC-Prozessoren, ist dieses Gleichgewicht gestoert worden. In den vergangenen zehn Jahren konnte die Prozessorleistung etwa um den Faktor 80, die Zugriffszeit auf DRAM-Speicher dagegen nur um den Faktor zwei verbessert werden. Der Hunger der Prozessoren auf Daten ist so stark geworden, dass Speicher und System-Bus grosse Muehe haben, ihn zu stillen.
Sollen die Daten in Echtzeit verarbeitet werden, kommt ein weiteres Problem hinzu: Multiprozessor-Systeme sollten es erlauben, zeitkritische Prozesse so zu isolieren, dass sie nicht durch Nebentaetigkeiten auf dem Rechner, wie die Verarbeitung von Interrupts durch Unix, beeinflusst werden. Dies ist mit der herkoemmlichen Multiprozessor-Architektur nur eingeschraenkt moeglich. Immer wenn der zeitkritische Prozess Daten aus dem globalen Speicher benoetigt, kann er durch Speicherzugriffe der Hintergrundprozesse abgebremst werden.
Daneben beeinflusst auch jede Ein- oder Ausgabe von Daten den Durchsatz des Echtzeitprozesses drastisch - immer dann, wenn dieser gleichzeitig auf den Speicher zugreifen muss.
Bei Concurrent haben wir die folgenden schwerwiegenden Probleme herkoemmlicher Multiprozessor-Systeme identifiziert:
- Die Leistungssteigerung moderner Prozessoren ist nicht voll nutzbar.
- Zeitkritische Prozesse lassen sich nicht hinreichend isolieren.
Verschiedene Rechnerhersteller versuchen, diesen Schwierigkeiten durch die Implementierung sehr schneller Bus-Systeme und die Verwendung groesserer Pufferspeicher zu begegnen. Gegen diesen Ansatz spricht jedoch, dass die Leistungsfaehigkeit des DRAM- Speichers nicht verbessert werden kann. Das Laden eines Elements vom Speicher in den Cache wird nur dann nachhaltig beschleunigt, wenn sich der Durchsatz aller Komponenten gleichmaessig erhoehen laesst.
Grosse Pufferspeicher nuetzen dabei wenig, wenn die Anwendung stark von externen Ereignissen abhaengt, was gerade fuer Echtzeitapplikationen gilt. Das Eintreten jedes weiteren Ereignisses macht den Cache-Inhalt unbrauchbar, da neue Daten und eine neue Programmsequenz geladen werden muessen. Will man dafuer einen besonders schnellen Bus zur Verfuegung stellen, dann treibt die noetige Hardware die Kosten des Rechners enorm in die Hoehe.
Das traditionelle Multiprozessor-Konzept hindert uns, die Fortschritte der Prozessortechnik fuer unsere Anwendung nutzbar zu machen. Da der Speicherzugriff der Engpass ist, liegt es nahe, jedem Prozessor einen eigenen Speicher zu geben. Dies ist allerdings nur dann sinnvoll, wenn jeder Prozessor nicht nur auf seinen ihm direkt zugeordneten Speicher, sondern auch auf die Speicher anderer Prozessoren zugreifen kann. Dabei muss die Konsistenz der gespeicherten Daten durch geeignete Massnahmen ("Cache-Kohaerenzprotokoll") sichergestellt werden.
Abbildung 2 zeigt das neue Konzept. Concurrent nennt es "Ultrasmart" ("Symmetric Multiprocessing Architecture for Real Time"), da es speziell fuer Echtzeitanwendungen entwickelt wurde.
Jedem Prozessor sein Arbeitsspeicher
Im Mittelpunkt der Ultrasmart-Architektur steht der "Crosspoint", eine von Concurrent entwickelte Variante des aus der Literatur bekannten Crossbar-Modells. Fuehrt ein Prozessor Code aus, so bedient er sich seines lokalen Speichersegments, um seinen Cache aufzufuellen. Dieses kann bis zu 128 MB gross sein. Diese Architektur erlaubt es jedem Prozessor, seine Leistungsfaehigkeit ganz zur Geltung zu bringen. Er wird nicht durch unabhaengige Aktivitaeten anderer Prozessoren gebremst.
Die den CPUs zugeordneten Speichersegmente sind Teil eines globalen Speichers. Aus der Sicht des Programmierers unterscheidet sich die Speicherorganisation nicht vom globalen Konzept des traditionellen Multiprozessor-Ansatzes. Will beispielsweise die CPU Nummer 2 auf das Speichersegment der CPU Nummer 3 zugreifen, so stellt der Crosspoint einen entsprechenden Zugriffspfad zur Verfuegung. Dieser Pfad ermoeglicht einen Durchsatz von 400 MB pro Sekunde. Gleichzeitig kann der Crosspoint zwei weitere solche Pfade schalten, zum Beispiel fuer den Zugriff von CPU Nummer 4 auf das Speichersegment von CPU Nummer 1 und fuer DMA (Direct Memory Access) von einem E/A-Kanal (zum Beispiel einen D/A-Wandler) auf das Speichersegment von CPU Nummer 2. Insgesamt ermoeglicht der Crosspoint somit einen Durchsatz von 1,2 GB pro Sekunde.
Vier der derzeit sechs moeglichen Crosspoint-Anschluesse koennen fuer CPUs verwendet werden. Die anderen beiden sind fuer die Ein- und Ausgabe reserviert. Als I/O-Bus wird der VME-Bus verwendet, dessen leistungsfaehige VME64-Variante unterstuetzt wird. Fuer Konfigurationen mit Bedarf an besonders hohem Datendurchsatz kann der sechste Crosspoint-Anschluss mit einem zweiten VME-Bus belegt werden.
Ein einfacher Mechanismus stellt die Cache-Kohaerenz sicher. Zu je 64 Bytes, was einer Cache-Zeile entspricht, wird ein "Cache Directory Tagword" (CDT) gefuehrt, das aus 7 Bits besteht (ein "exklusives" Bit oder E-Bit und 6 Bits, die jeweils einem der sechs Crosspoint-Anschluesse zugeordnet sind). Will ein Prozessor auf sein Speichersegment schreiben, so wird zunaechst das CDT ueberprueft. Ist darin das E-Bit gesetzt, so hat kein anderer Prozessor diese Speicherzeile in seinem Cache. Der Schreibzugriff kann erfolgen, ohne dass diese anderen Prozessoren taetig werden muessten. Will nun CPU Nummer 3 im Speichersegment von CPU Nummer 4 lesen, wird im Speicher von CPU Nummer 4 einfach das dieser CPU zugeordnete Bit im CDT gesetzt und das E-Bit geloescht.
Falls CPU Nummer 4 nun dieses Speicherwort schreiben will, so erhaelt CPU Nummer 3 vom Crosspoint eine Nachricht, dass sie ihren Cache-Eintrag invalidieren muss. Laden sich weitere CPUs die betreffende Cache-Zeile in ihren Pufferspeicher, werden im Speichersegment von CPU Nummer 4 einfach die entsprechenden CDT- Bits gesetzt. Die hier vorgestellte neue Architektur ist Grundlage des von Concurrent im Oktober 1993 angekuendig- ten "Maxion"- Multiprozessor-Systems. In der ab Mitte Januar 1994 lieferbaren ersten Version wird das Rechnersystem bis zu vier R4400- Prozessoren mit einer Taktrate von 150 Megahertz (intern) enthalten. Ein Vier-Prozessor-Maxion leistet etwa 320 Specint92, was der vierfachen Leistung einer R4400 Pentspricht. Mit der in Maxion implementierten Ultrasmart-Architektur steht ein System zur Verfuegung, das die Leistungsfaehigkeit eines der schnellsten heute verfuegbaren Prozessoren voll nutzbar macht und dem Echtzeitentwickler erlaubt, seine Applikation von stoerender Hintergrundaktivitaet zu isolieren - und dies erstmals seit Einfuehrung von Unix-Mehrprozessor-Systemen.