DE19839239B4 - Verfahren zum Synchronisieren eines Datenverarbeitungssystems und damit synchronisiertes Datenverarbeitungssystem - Google Patents

Verfahren zum Synchronisieren eines Datenverarbeitungssystems und damit synchronisiertes Datenverarbeitungssystem Download PDF

Info

Publication number
DE19839239B4
DE19839239B4 DE19839239.7A DE19839239A DE19839239B4 DE 19839239 B4 DE19839239 B4 DE 19839239B4 DE 19839239 A DE19839239 A DE 19839239A DE 19839239 B4 DE19839239 B4 DE 19839239B4
Authority
DE
Germany
Prior art keywords
processor
module
register
processors
tbc
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
DE19839239.7A
Other languages
English (en)
Other versions
DE19839239A1 (de
Inventor
Michéle Boutet
Nasr-Eddine Walehiane
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
BULL S.A., LES CLAYES SOUS BOIS, FR
Original Assignee
Bull SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bull SA filed Critical Bull SA
Publication of DE19839239A1 publication Critical patent/DE19839239A1/de
Application granted granted Critical
Publication of DE19839239B4 publication Critical patent/DE19839239B4/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/04Generating or distributing clock signals or signals derived directly therefrom
    • G06F1/14Time supervision arrangements, e.g. real time clock

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Multi Processors (AREA)
  • Computer And Data Communications (AREA)
  • Hardware Redundancy (AREA)
  • Synchronisation In Digital Transmission Systems (AREA)

Abstract

Ein Verfahren zum Synchronisieren eines Datenverarbeitungssystems auf ein sich zeitlich entwickelndes Datum. Das System enthält mehrere Module (1, 2, 3, 4), wovon jedes mehrere Prozessoren (10, 11, 12, 13, 20, 21, 22, 23) enthält, die durch einen diesem Modul eigenen Taktgeber getaktet werden. Jeder Prozessor enthält ein privates Register TBR (16, 17, 18, 19, 26, 27, 28, 29), das einen Wert des Datums hält und durch den dem diesen Prozessor enthaltenden Modul eigenen Taktgeber inkrementiert wird. Ein Prozessor wird als Master gewählt, der jeden anderen Prozessor so steuert, daß er sich in einen bereiten Zustand versetzt, in dem jeder Prozessor auf eine vom Master-Prozessor des Systems stammende Freigabe wartet, ohne unterbrochen werden zu können. Jeder freigegebene Prozessor liest sofort den Inhalt eines Registers TBC (50, 51), das den Prozessoren desselben Moduls gemeinsam ist, und schreibt diesen Inhalt in sein Register TBR, ohne unterbrochen werden zu können.

Description

  • Die Erfindung betrifft das Gebiet der Synchronisation von Datenverarbeitungssystemen auf sich zeitlich entwickelnde Datumsangaben.
  • In einem Datenverarbeitungssystem ist es nützlich, verschiedene Ereignisse, die sich auf das System auswirken, datieren zu können. Es ist beispielsweise nützlich, das in Jahren, Monaten, Tagen, Stunden, Minuten und Sekunden ausgedrückte Datum der Erstellung oder der Modifizierung einer Datei zu kennen. Für bestimmte Ereignisse, die besondere Prozeduren starten, ist es nützlich, das Datum bis auf eine Millisekunde oder sogar eine Mikrosekunde oder einen Teil einer Mikrosekunde zu präzisieren.
  • Hierzu ist es notwendig, daß das System ein Referenzdatum zur Verfügung stellt, das sich durch Inkrementieren seines Werts beispielsweise mittels eines Taktgebers zeitlich entwickelt. Es ist zweckdienlich, einen Wert dieses Datums zu jedem Zeitpunkt initialisieren zu können. Beispielsweise könnte beim Hochfahren des Systems als Anfangsdatum dasjenige erwünscht sein, das in einem Speicher enthalten ist, der durch eine Sicherungsbatterie unabhängig von einer Unterbrechung der Stromversorgung des Systems inkrementiert wird. Nach dem Hochfahren des Systems könnte erwünscht sein, das laufende Datum zu modifizieren, um bestimmte Anforderungen zu berücksichtigen, wofür als nicht beschränkende Beispiele eine Änderung der lokalen Zeit, eine Neuabstimmung des Kalenders, eine Abweichung des Taktgebers, ein Ausfall der Sicherungsbatterie oder eine Synchronisation auf ein anderes System erwähnt werden können.
  • Um bestimmte Ereignisse, die von einem Prozessor verarbeitet werden, präzise zu datieren, ist es nützlich, daß der Prozessor einen laufenden Datumswert in einem privaten Register besitzt, auf das er schnell zugreifen kann. Dieser Wert wird hardwaremäßig mittels eines Taktgebers inkrementiert, der auch den Ablauf des Prozessors taktet.
  • Der Prozessor führt als Antwort auf eine Anforderung zur Modifikation des laufenden Datumswerts eine Sequenz aus, die im wesentlichen darin besteht, dem in seinem privaten Register enthaltenen laufenden Wert eine Differenz Δ hinzuzufügen, die die Verschiebung zwischen den laufenden Datumswerten vor und nach der Modifikation repräsentiert. Dadurch ist sichergestellt, daß unabhängig von dem Zeitpunkt, zu dem der Prozessor das Datum in seinem Register modifiziert, der neue laufende Wert die zeitliche Entwicklung des Datums berücksichtigt. In einem System, das mehrere Prozessoren enthält, kann in Betracht gezogen werden, daß sämtliche Prozessoren nacheinander oder gleichzeitig die Sequenz, die eben beschrieben worden ist, ausführen. Es wird angemerkt, daß in dem Fall, in dem sämtliche Prozessoren durch denselben Taktgeber getaktet werden, dann, wenn ein zweiter Prozessor die Sequenz zu einem Zeitpunkt ausführt, der nach dem Zeitpunkt liegt, zu dem sie der erste Prozessor ausführt, die privaten Register der zwei Prozessoren zwischen diesen zwei Zeitpunkten um die gleiche Größe inkrementiert worden sind und die Werte der privaten Register der beiden Prozessoren nach der letzten Ausführung der Sequenz übereinstimmen. Diese Bemerkung ist auch für eine beliebige Anzahl von Prozessoren gültig.
  • In einem System, das aus mehreren Modulen gebildet ist, wovon jedes ein Untersystem bildet, das einen oder mehrere Prozessoren enthält, ist es möglich, an die Module ein vom selben Taktgeber ausgegebenes Signal zu verteilen, um sämtliche Prozessoren des Systems synchron zu takten. Beispielsweise ist aus dem Patent US 5.305.453 eine Lösung bekannt, um die verteilten Taktsignale bei ihrem Empfang in jedem Modul auf ein und dieselbe Phase zu verriegeln. Hierfür ist jedoch für sämtliche Module eine völlig gleiche Ausführungstechnik erforderlich: gleiche Betriebsfrequenz, gleiches Durchlassband der physischen Komponenten usw. Andererseits sind außerdem zwischen den Modulen spezielle physische Verbindungen notwendig. Jeder Austausch oder jede spätere Hinzufügung eines Moduls für eine Erhöhung der Leistungen des Systems erfordert die Beibehaltung der anfänglichen Technologie oder die Ausführung von speziellen Anpassungen und oftmals zusätzlicher Verdrahtungen.
  • Die Ausführungen von Sequenzen, die darin bestehen, ein Datum zu aktualisieren, indem wie oben erwähnt zum Inhalt des privaten Registers jedes Prozessors die Differenz Δ hinzugefügt wird, schaffen einige Probleme bei der Lösung der Bindung an einen Referenztakt, der physisch sämtlichen Modulen eines Datenverarbeitungssystems gemeinsam ist. In einem System, in dem jedes Modul einen eigenen Referenztaktgeber enthält, der von denjenigen der anderen Module verschieden ist, ist nämlich dann, wenn ein Prozessor eines zweiten Moduls die Differenz Δ zu einem Zeitpunkt t + dt hinzufügt, der nach einem Zeitpunkt t liegt, zu dem ein Prozessor eines ersten Moduls die Differenz Δ hinzufügt, sicherzustellen, daß die privaten Register der beiden Prozessoren um die gleiche Größe zwischen diesen zwei Zeitpunkten inkrementiert worden sind, da die verschiedenen Taktgeber nicht notwendig völlig gleiche Frequenzen und Phasen besitzen. Selbst wenn eine vollkommene Synchronisation zwischen den Prozessoren sämtlicher Module des Systems als möglich angesehen wird, so daß sämtliche Ausführungen der beschriebenen Sequenz zum gleichen Zeitpunkt t erfolgen, bleiben Probleme von Abweichungen der Datumswerte zwischen den Prozessoren der verschiedenen Module ungelöst.
  • Die Abweichungsprobleme der Datumswerte zwischen den beiden Prozessoren treten auf, wenn die beiden Prozessoren durch unabhängige Taktsignale getaktet werden. Falls zu einem Anfangszeitpunkt das private Register des ersten Prozessors einen Datumswert enthält, der mit demjenigen, der im privaten Register des zweiten Prozessors enthalten ist, völlig übereinstimmt, bewirkt die Inkrementierung der privaten Register durch die verschiedenen Taktsignale einen Abstand zwischen den beiden Werten, der im Lauf der Zeit zunimmt, woraus sich eine Abweichung des Datumswerts eines Prozessors in bezug auf den anderen ergibt. Indem ein neuer Datumswert im privaten Register jedes Prozessors periodisch zurückgesetzt wird, beispielsweise bevor die Abweichung einen gegebenen Genauigkeitsbereich für die Datumswerte verlässt, werden für die Prozessoren sämtlicher Module Datumswerte erhalten, die innerhalb dieses Genauigkeitsbereichs übereinstimmen. Dies ermöglicht die Synchronisation des Systems auf ein Datum, das innerhalb des gegebenen Genauigkeitsbereichs eindeutig ist. Eine Hinzufügung von A wie oben beschrieben ist jedoch nicht anwendbar, insbesondere deswegen, weil es schwierig ist, den Abweichungswert zwischen Modulen exakt zu beherrschen.
  • Der Artikel ”Time, Clocks, and the Ordering of Events in a Distributed System” von L. Lamport in Commun. ACM, 21(7), 1978, S. 558–565 befasst sich mit der Reihenfolge von Ereignissen in verteilten Systemen. Insbesondere bei der Zuteilung gemeinsamer Ressourcen ist die zeitliche Synchronisation bedeutsam. Bei der Reservierung und/oder Freigabe von Ressourcen wird dabei jeweils ein Zeitstempel mitgeführt. Die physikalischen Taktgeber aller Prozessoren sollen synchronisiert werden, damit ihr Unterschied gering wird.
  • Aus der Veröffentlichung ”Coherence Controller Architectures for SMP-Based CC-NUMA Multiprocessors” von M. M. Maged et al. in ACM SIGARCH (ISCA '97), Vol. 25 (2), S. 219–228, ISBN: 0-89791-901-7 ist ein Datenverarbeitungssystem mit mehreren Modulen bekannt, die jeweils mehrere Prozessoren sowie einen Teil eines verteilten gemeinsamen Speichers enthalten, wobei die Prozessoren auf den Speicher über Cache-Kohärenz-Protokolle zugreifen. Jedes Modul enthält mehrere durch einen Taktgeber getaktete Prozessoren. Jeder Prozessor enthält ein privates Register, das dazu vorgesehen ist, einen Wert des Datums zu halten und das durch den Taktgeber inkrementiert wird.
  • Der Artikel ”An Operating System Structuring Concept” von C. A. R. Hoare in Commun. ACM, 17 (10), 1974, S. 549–557 beschäftigt sich mit Methoden der Synchronisation und strukturierten Programmierung nebenläufiger Algorithmen, beispielsweise über Semaphoren, und gibt Beispiele zu deren Verwendung. Es wird ein Algorithmus beschrieben, der einen Master („Writer”) kennt, welcher anderen Instanzen („Reader”) befiehlt, dass sie sich in einen bereiten Zustand versetzen und dass sie sich als in diesem Zustand befindlich erklären. Die anderen Instanzen warten dann auf eine Freigabe des Masters. Sobald die Freigabe erfolgt, können diese lesen. Die Synchronisation zwischen Reader und Writer erfolgt über eine boolesche Variable innerhalb eines kritischen Bereichs. Es soll sichergestellt sein, dass nur ein Programm diesen kritischen Bereich betreten darf.
  • Der Erfindung liegt die Aufgabe zugrunde, ein Verfahren zum Synchronisieren eines Datenverarbeitungssystems und ein damit synchronisiertes Datenverarbeitungssystem zu schaffen, welche/welches hinsichtlich der Synchronisierung des Datums der einzelnen Prozessoren des Datenverarbeitungssystems verbessert ist.
  • Diese Aufgabe wird erfindungsgemäß gelöst durch ein Verfahren mit den Merkmalen des Anspruchs 1 und durch ein Datenverarbeitungssystem mit den Merkmalen des Anspruchs 7. Die abhängigen Ansprüche sind auf zweckmäßige Ausführungen der Erfindung gerichtet.
  • Die Erfindung hat ein Verfahren zum Synchronisieren eines Datenverarbeitungssystems auf ein sich zeitlich entwickelndes Datum zum Gegenstand, wobei das Datenverarbeitungssystem ein oder mehrere Module enthält, wobei jedes Modul jeweils mehrere Prozessoren enthält, die durch einen diesem Modul eigenen Taktgeber getaktet werden, wobei jeder Prozessor ein privates Register TBR enthält, das dazu vorgesehen ist, einen Wert des Datums zu halten, und durch den dem diesen Prozessor enthaltenen Modul eigenen Taktgeber inkrementiert werden kann, wobei jedes der Module jeweils ein Register TBC umfasst, das den Prozessoren desselben Moduls gemeinsam ist, und die Module über einen Bus miteinander kommunizieren, wobei der Inhalt der Register TBC durch ein Kommunikationsprotokoll auf dem Bus und durch ständige Inkrementierung durch den jeweiligen Taktgeber jedes Moduls zeitlich kohärent gehalten wird, wobei
    • – ein Prozessor als Master des Systems gewählt wird, um jeden der weiteren Prozessoren in der Weise zu steuern, daß er sich in einen bereiten Zustand versetzt und sich als in diesem Zustand befindlich erklärt, wobei der Zustand für jeden Prozessor darin besteht, auf eine vom Master-Prozessor des Systems kommende Freigabe zu warten, ohne unterbrochen werden zu können;
    • – jeder Prozessor, der die Freigabe besitzt, sofort den Inhalt des Registers TBC liest, das den Prozessoren desselben Moduls gemeinsam ist, und diesen Inhalt in sein Register TBR schreibt, ohne unterbrochen werden zu können.
  • Die Erfindung hat außerdem ein Datenverarbeitungssystem zum Gegenstand, das ein oder mehrere Module enthält, wovon jedes Modul jeweils mehrere Prozessoren enthält, die durch einen diesem Modul eigenen Taktgeber getaktet werden, wobei jeder Prozessor ein privates Register TBR enthält, das dazu vorgesehen ist, einen Datumswert zu halten, und durch einen dem diesen Prozessor enthaltenden Modul eigenen Taktgeber inkrementiert werden kann, wobei jedes der Module jeweils ein Register TBC umfasst, das den Prozessoren desselben Moduls gemeinsam ist und auf das durch die Prozessoren des Moduls direkt zugegriffen werden kann, und die Module über einen Bus miteinander kommunizieren, wobei der Inhalt der Register durch ein Kommunikationsprotokoll auf dem Bus und durch ständige Inkrementierung durch den jeweiligen Taktgeber jedes Moduls zeitlich kohärent gehalten wird, wobei das Datenverarbeitungssystem ferner umfasst:
    • – Mittel zum Wählen eines Prozessors als Master des Systems derart, daß er jeden der anderen Prozessoren so steuert, daß er sich in einen bereiten Zustand versetzt und sich als in diesem Zustand befindlich erklärt, wobei der Zustand für jeden der anderen Prozessoren darin besteht, auf eine vom Master-Prozessor des Systems stammende Freigabe zu warten, ohne unterbrochen werden zu können; und wobei
    • – das in jedem Modul vorgesehene Register TBC dazu vorgesehen ist, einen Datumswert zu halten, der mit demjenigen des Registers TBC des Moduls, in dem sich der Master-Prozessor befindet, völlig übereinstimmt, wenn der Master-Prozessor die Freigabe schickt.
  • Weitere Merkmale und Vorteile der Erfindung werden deutlich beim Lesen der folgenden Beschreibung zweckmäßiger Ausführungen, die auf die beigefügte Zeichnung Bezug nimmt; es zeigen:
  • 1 ein synchrones System der Erfindung;
  • 2 eine Ansicht zur Erläuterung der Schritte des Verfahrens gemäß der Erfindung; und
  • 3 eine Ansicht zur Erläuterung der Schritte eines abgewandelten Verfahrens gemäß der Erfindung.
  • Wie in 1 gezeigt ist, enthält ein Datenverarbeitungssystem ein oder mehrere Module 1, 2, 3 und 4, ohne daß diese Anzahl vier beschränkend ist. Das Modul 1 enthält mehrere Prozessoren 10, 11, 12, 13, die mit CPU bezeichnet sind und durch einen dem Modul eigenen Taktgeber getaktet werden, der nicht dargestellt ist, um die Figur nicht unnütz zu überladen. Ebenso enthält das Modul 2 mehrere Prozessoren 20, 21, 22, 23, die mit CPU bezeichnet sind und durch einen dem Modul 2 eigenen Taktgeber getaktet werden; das Modul 3 enthält mehrere Prozessoren 30, 31, 32, 33, die mit CPU bezeichnet sind und durch einen dem Modul 3 eigenen Taktgeber getaktet werden; schließlich enthält das Modul 4 mehrere Prozessoren 40, 41, 42, 43, die mit CPU bezeichnet sind und durch einen dem Modul 4 eigenen Taktgeber getaktet werden. Das System liegt nicht außerhalb des Umfangs der Erfindung, wenn ein Modul eine von vier abweichende Anzahl von Prozessoren, beispielsweise zwei oder sechs Prozessoren, enthält.
  • Der Speicher des Systems ist auf die Module anhand von Speichereinheiten 14, 24, 34, 44 verteilt, die sich physisch in jedem der Module 1, 2, 3 bzw. 4 befinden. Jeder Prozessor greift zum Lesen und Schreiben auf sämtliche Speicher 14, 24, 34, 44 über Cache-Kohärenz-Protokolle zu, die aus den Patentanmeldungen FR 9706747-A , FR 9706388-A oder FR 9706387-A , die im Namen der Anmelderin eingereicht worden sind, bekannt sind.
  • Wie in den obenerwähnten Anmeldungen erläutert wird, erfolgt die Ausführung der Cache-Kohärenz-Protokolle durch Elemente, die mit PKC bezeichnet sind und in 1 die Bezugszeichen 6, 7, 8 bzw. 9 besitzen. Das Element 6 befindet sich physisch im Modul 1 und kommuniziert über ein Bussystem 15 lokal mit den Prozessoren 10 bis 13 und mit dem Speicher 14. Gleichermaßen befindet sich das Element 7 physisch im Modul 2 und kommuniziert über ein Bussystem 25 lokal mit den Prozessoren 20 bis 23 und mit dem Speicher 24, während das Element 8 sich physisch im Modul 3 befindet und über ein Bussystem 35 lokal mit den Prozessen 30 bis 33 und mit dem Speicher 34 kommuniziert und das Element 9 sich physisch im Modul 4 befindet und über ein Bussystem 45 lokal mit den Prozessoren 40 bis 43 und mit dem Speicher 44 kommuniziert.
  • Andererseits kommunizieren die Elemente 6 bis 9 mittels eines außerhalb der Module 1 bis 4 befindlichen Busses 5 entfernt miteinander. Das Kommunikationsprotokoll auf dem Bus 5 ist beispielsweise das bekannte Protokoll SCI. Die beschriebene Architektur ermöglicht die Ausführung eines Betriebssystems, das sämtlichen Modulen 1 bis 4 und jedem zusätzlichen Modul, dessen Element PKC an den Bus 5 angeschlossen ist, gemeinsam ist.
  • Jeder Prozessor CPU enthält ein privates Zeitbasisregister, das TBR genannt ward und dazu vorgesehen ist, einen sich zeitlich entwickelnden Datumswert zu halten. In dem Modul 1 ist jedes Register 16, 17, 18, 19, das dem Prozessor 10, 11, 12 bzw. 13 zugeordnet ist, dazu vorgesehen, von dem dem Modul 1 eigenen Taktgeber inkrementiert zu werden. Beispielsweise codiert jedes private Register TBR den Datumswert mit 64 Bits, wovon jedes Inkrement einem Taktimpuls entspricht. Wenn der Taktgeber des Moduls 1 eine Frequenz von 100 MHz besitzt, stellt ein Taktimpuls 10 ns dar. Eine kurze Berechnung von 2<64> gibt, daß es möglich ist, in einem Register TBR einen Wert von mehr als 5849 Jahren mit einer Schrittweite von 10 ns zu codieren. Bei einer Frequenz von 1 GHz ist es möglich, einen Wert von mehr als 584 Jahren mit einer Schrittweite von 1 ns zu codieren. Der Inhalt des Registers TBR ermöglicht daher dem Prozessor, die von ihm verarbeiteten Ereignisse in einem großen Zeitbereich mit einer hohen Auflösung zu datieren.
  • Andererseits kann der Prozessor CPU ein oder mehrere nicht gezeigte Dekrementierungsregister enthalten, deren Nulldurchgang eine Unterbrechung hervorruft. Wenn in einem Dekrementierungsregister beispielsweise 32 Bits angeordnet werden, die vom Register TBR geladen werden, ist es möglich, ein Ereignis zu einem genauen Datum zu starten und so das System zu synchronisieren.
  • Ebenso ist im Modul 2 jedes Register 26, 27, 28, 29, das dem Prozessor 20, 21, 22 bzw. 23 zugeordnet ist, dazu vorgesehen, durch einen dem Modul 2 eigenen Taktgeber inkrementiert zu werden. Im Modul 3 ist jedes Register 36, 37, 38, 39, das dem Prozessor 30, 31, 32 bzw. 33 zugeordnet ist, dazu vorgesehen, durch einen dem Modul 3 eigenen Taktgeber inkrementiert zu werden. Im Modul 4 ist jedes Register 46, 47, 48, 49, das dem Prozessor 40, 41, 42 bzw. 43 zugeordnet ist, dazu vorgesehen, durch einen dem Modul 4 eigenen Taktgeber inkrementiert zu werden.
  • Das Element 6 enthält ein Register 50, das mit TBC bezeichnet ist und den Prozessoren 10, 11, 12 und 13 in dem Sinn gemeinsam ist, daß auf dieses Register wenigstens zum Lesen von diesem Prozessoren zugegriffen werden kann. Das Register 50 besitzt ein Format, das mit demjenigen der Register TBR völlig übereinstimmt. Das Register 50 ist dazu vorgesehen, ständig durch den dem Modul 1 eigenen Taktgeber inkrementiert zu werden. Der Inhalt des Registers 50 entwickelt sich zeitlich in Übereinstimmung mit dem Inhalt der Register 16, 17, 18, 19.
  • Jedes der Elemente 7, 8, 9 enthält für jedes Modul 2, 3 bzw. 4, dem es zugehört, ein Register 51, 52 bzw. 53, das mit dem Register 50 strukturell und funktional übereinstimmt.
  • Die Inhalte der Register TBC 50, 51, 52 und 53 sind zu jedem Zeitpunkt innerhalb des gegebenen Genauigkeitsbereichs gleich. Hierzu ruft jedes Schreiben in eines der Register TBC mit Ausnahme der obenbeschriebenen Inkrementierung eine hardwaremäßige Kopie dieses Registers TBC in die anderen Register TBC hervor, wobei die Zeit berücksichtigt wird, die für eine Dateneinheit erforderlich ist, um von einem Element PKC zum anderen auf dem Bus 5 zu laufen.
  • Bei der Initialisierung des Systems wird ein Modul als Zeitbasis-Mastermodul gewählt. Dieses Modul wird TBMM genannt. Falls dieses Modul TBMM beispielsweise das Modul 1 ist, ermöglicht die Konfiguration des Elements 6 den Prozessoren 10 bis 13, zum Schreiben auf das Register 50 zuzugreifen, so daß sie hier einen Datumswert anordnen können. In diesem Fall kann auf die Register 51, 52 und 53 zum Schreiben nur über den Bus 5 zugegriffen werden, auf dem die Synchronisationspakete laufen, mit denen die Inhalte der Register 51, 52 und 53 mit dem Inhalt des Registers 50 kohärent gemacht werden.
  • Wie oben erwähnt worden ist, ermöglicht die beschriebene Architektur die Ausführung eines Betriebssystems, das sämtlichen Modulen 1 bis 4 gemeinsam ist, die anhand eines nicht beschränkenden Beispiels angegeben worden sind. Das Betriebssystem enthält einen Kern (kernel im Englischen), der aus verschiedenen Funktionen gebildet ist, um die Systembetriebsmittel zu steuern. Es wird gesagt, daß eine Anwendung einen Systemaufruf ausführt, wenn es eine Funktion des Kerns aufruft. Hier ist vor allem eine Funktion von Interesse, die ksettimer genannt wird und dazu vorgesehen ist, das System zu synchronisieren, d. h. eine Referenzzeitbasis zu liefern, die sämtlichen Elementen des Systems gemeinsam ist. Die Funktion ksettimer kann bei der Initialisierung des Systems durch eine Anwendung aufgerufen werden, die eine Referenzdatumsänderung für das System anfordert, wobei das Datum nicht nur in Jahren, Monaten und Tagen, sondern auch in Stunden, Minuten und Sekunden mit einer Auflösung in der Größenordnung einer Nanosekunde ausgedrückt wird. Die Funktion ksettimer kann auch regelmäßig aufgerufen werden, um das Datum wieder zu aktualisieren, um Abweichungen zwischen den verschiedenen Taktgebern des Systems und in bezug auf die universelle Zeit zu beherrschen.
  • Ein Aufruf der Funktion ksettimer startet einen Hauptprozess, dessen Ausführung in Abhängigkeit von einer Zuweisung der Prozessoren an die Prozesse, die von einer Ablaufsteuerung (scheduler im Englischen) und von einem Abwickler (dispatcher im Englischen), die nicht gezeigt sind, weil sie dem Fachmann bekannt sind, ausgeführt wird, a priori in einem beliebigen Prozessor des Systems beginnt.
  • Wie in 2 gezeigt ist, beginnt der Hauptprozess durch einen Schritt 54, in dem verifiziert wird, ob der Prozessor, der den Datumsaktualisierungsprozess ausführt, ein Prozessor des Moduls TBMM ist. Wenn dies nicht der Fall ist, wird der Prozess mit seinem Kontext an das Modul TBMM übertragen, wo der Abwickler einen Prozessor des Moduls TBMM zuweist, der dann als Master des Systems gewählt ist. In der folgenden Beschreibung wird beispielsweise der Fall betrachtet, in dem das Modul TBMM das Modul 1 ist, wobei der Prozessor 10 als Master gewählt ist. Der Master-Prozessor führt dann eine Folge von Schritten 55 bis 61 aus.
  • Im Schritt 55 wird verifiziert, daß jede eventuell vorhergehende Datumsaktualisierung beendet ist. Hierzu fragt eine Endlosschleife eine Tabelle ab, in der jede Zeile, die einem Prozessor des Systems zugewiesen ist, eine Variable enthält, die time_updates genannt wird und die, wenn sie auf einen ersten Wert gesetzt ist, meldet, daß der Prozessor, dem die Zeile zugewiesen ist, nicht im Begriff ist, sein Register TBR zu aktualisieren. Sämtliche Variable time_updates der Tabelle werden anschließend auf einen zweiten Wert gesetzt, um zu melden, daß eine Aktualisierung des Datums im Gange ist.
  • Im Schritt 56 werden sämtliche Unterbrechungen im Master-Prozessor maskiert, um einen kritischen Abschnitt im Master-Prozessor zwischen dem Schritt 56 und dem Schritt 61, in dem die Unterbrechungen im Master-Prozessor demaskiert werden, zu definieren.
  • Im Schritt 57 schreibt der Master-Prozessor den empfangenen Datumswert bei einem Aufruf der Funktion ksettimer in das Register TBC seines Moduls. In dem Fall, in dem der Master-Prozessor der Prozessor 10 ist, wird der Datumswert in das Register 50 geschrieben. Der Datumswert wird dann vom Register 50 mit dem Kommunikationsprotokoll auf dem Bus 5 wie vorher beschrieben zu den Registern 51, 52 und 53 transportiert. Bei Bedarf hat der Prozessor 10 vor dem Schreiben des Datumswerts in das Register 50 diesen Wert in ein Format umgesetzt, das mit demjenigen des Registers 50 kompatibel ist. Jedes der Register 50, 51, 52 und 53 wird durch den jeweiligen Taktgeber der Module 1, 2, 3 bzw. 4 fortgesetzt inkrementiert.
  • Der Schritt 58 besteht im wesentlichen darin, eine atomare Operation vorzubereiten, die von jedem der anderen Prozessoren, die dann Slave-Prozessoren genannt werden, ausgeführt wird. Der Master-Prozessor setzt eine Variable, die gotime genannt wird, auf einen ersten Wert, um anzugeben, daß die atomare Operation nicht freigegeben ist. Der Master-Prozessor schickt anschließend eine Unterbrechung, die inttimer genannt wird, an sämtliche anderen Prozessoren. Der Empfang der Unterbrechung inttimer in jedem Slave-Prozessor startet hier die Ausführung eines Hilfsprozesses, der im wesentlichen die später beschriebenen Schritte 62 bis 67 enthält.
  • Der Schritt 59 hat zum Ziel, die Slave-Prozessoren für die Ausführung der atomaren Operation freizugeben. Es wird daran erinnert, daß bei einer atomaren Operation der Prozessor, der sie ausführt, zu keinem internen Befehl mit Ausnahme derjenigen der Operation springt, bis die Operation beendet ist. Im Schritt 59 führt der Master-Prozessor zunächst eine Warteschleife aus, in der er eine logische Variable liest, die pcpu_ready genannt wird, wobei er die Schleife verlässt, wenn sämtliche Bits der Variable pcpu_ready in einem wahren Zustand sind, der angibt, daß sämtliche Slave-Prozessoren für die Ausführung der atomaren Operation bereit sind. Wenn der Master-Prozessor die Warteschleife verlässt, setzt er die Variable, die gotime genannt wird, in einen wahren Zustand, was die Freigabe der Ausführung der atomaren Operation bedeutet.
  • Im Schritt 60 führt der Master-Prozessor die atomare Operation aus, die im wesentlichen darin besteht, den im Register TBC seines Moduls enthaltenen Wert zu laden und diesen Wert in seinem Register TBR anzuordnen, indem er gegebenenfalls geeignete Formatumsetzungen in ein für das Register TBR geeignetes Format ausführt. Beispielsweise lädt der Prozessor 10 den im Register 50 enthaltenen Wert und ordnet ihn im Register 16 an.
  • Im Schritt 61 setzt der Master-Prozessor die time_updates genannte Variable derjenigen Zeile der Tabelle, die ihm zugewiesen ist, auf den ersten Wert, was bedeutet, daß der Master-Prozessor nicht im Begriff ist, sein Register TBR zu aktualisieren. Der Master-Prozessor setzt sich anschließend auf das Prioritätsniveau zurück, das vor dem Start des Schritts 56 vorlag.
  • Der Schritt 62 wird in jedem Slave-Prozessor bei Empfang der Unterbrechung inttimer gestartet. Jeder Slave-Prozessor sichert selbstverständlich den Kontext eines eventuell gerade ausgeführten Prozesses und maskiert sämtliche ihn betreffenden Unterbrechungen in der Weise, daß ein kritischer Abschnitt im Slave-Prozessor zwischen dem Schritt 62 und dem Schritt 67, in dem die Unterbrechungen im Slave-Prozessor demaskiert werden, definiert wird.
  • Im Schritt 63 setzt der Slave-Prozessor in einer logischen Variable, die pcpu_ready genannt wird, das ihm entsprechende Bit auf einen wahren Zustand, was bedeutet, daß der Slave-Prozessor für die Ausführung der atomaren Operation bereit ist.
  • Im Schritt 64 führt der Slave-Prozessor eine Warteschleife aus, in der er die logische Variable, die gotime genannt wird, liest, wobei er die Schleife verlässt, wenn die logische Variable gotime wahr ist. Da die Folgen von Prozessen in jedem Slave-Prozessor völlig übereinstimmen, liest jeder Slave-Prozessor desselben Moduls den Übergang der Variable gotime in den wahren Zustand zum selben Zeitpunkt auf seinem lokalen Bus. Beispielsweise lesen die Prozessoren 20 bis 23 den Zustand der Variable gotime auf dem Bus 25 zum selben Zeitpunkt. Ebenso lesen die Prozessoren 30 bis 33 den Zustand der Variable gotime auf dem Bus 35 zum selben Zeitpunkt und die Prozessoren 40 bis 43 lesen den Zustand der Variable gotime auf dem Bus 45 zum selben Zeitpunkt. Die Prozessoren 16 bis 19 lesen ihrerseits außerdem den Zustand der Variable gotime auf dem Bus 15 zum selben Zeitpunkt. Dadurch wird insbesondere die Ausführung eines Cache-Kohärenz-Protokolls erleichtert, das aus den Patentanmeldungen FR 9706747-A , FR 9706388-A oder FR 9706387-A , eingereicht im Namen der Anmelderin, bekannt ist. Daher gehen sämtliche Prozessoren desselben Moduls gleichzeitig zum Schritt 65 weiter.
  • Im Schritt 65 führt jeder Slave-Prozessor die atomare Operation aus, die im wesentlichen darin besteht, den im Register TBC seines Moduls enthaltenen Wert zu laden und diesen Wert in seinem Register TBR anzuordnen, indem er gegebenenfalls Formatumsetzungen in ein für das Register TBR geeignetes Format ausführt. Beispielsweise lädt jeder der Prozessoren 20 bis 23 den im Register 51 enthaltenen Wert und ordnet ihn im Register 26, 27, 28 bzw. 29 zum selben Zeitpunkt t2 an. Ebenso lädt jeder der Prozessoren 30 bis 33 den im Register 32 enthaltenen Wert und ordnet ihn im Register 36, 37, 38 bzw. 39 zum selben Zeitpunkt t3 an, ferner lädt jeder der Prozessoren 40 bis 43 den im Register 53 enthaltenen Wert und ordnet ihn im Register 46, 47, 48 bzw. 49 zum selben Zeitpunkt t4 an. Jeder der Prozessoren 10 bis 13 lädt seinerseits außerdem den im Register 50 enthaltenen Wert und ordnet ihn im Register 16, 17, 18 bzw. 19 zum selben Zeitpunkt t1 an. Es ist nicht wichtig, ob die Zeitpunkte t1 bis t4 verschieden sind, beispielsweise wegen Latenzzeiten im Cache-Kohärenz-Protokoll zwischen den Modulen, da in Wirklichkeit der Inhalt der Register 50 bis 52 zu jedem Zeitpunkt durch das Kommunikationsprotokoll auf dem Bus 5 und durch die ständige Inkrementierung durch den jeweiligen Taktgeber jedes Moduls zeitlich kohärent gehalten wird. Daher sind die Inhalte sämtlicher Register TBR synchron.
  • Im Schritt 66 setzt der Slave-Prozessor die time_updates genannte Variable derjenigen Zeile der Tabelle, die ihm zugewiesen ist, auf den ersten Wert, was bedeutet, daß der Slave-Prozessor momentan nicht im Begriff ist, sein Register TBR zu aktualisieren.
  • Im Schritt 67 setzt sich der Slave-Prozessor anschließend auf das Prioritätsniveau zurück, das vor dem Beginn des Schrittes 62 vorlag.
  • Im Zusammenhang mit dem gezeigten Ausführungsbeispiel wird angemerkt, daß der Schritt 57 dem Schritt 58 vorhergeht. Die Reihenfolge der Schritte 57 und 58 ist nämlich für die Ausführung der Erfindung grundlegend. Der Schritt 58 erzeugt jedoch in jedem Slave-Prozessor einen kritischen Abschnitt, der in dem Zeitintervall definiert ist, das den Schritt 62 vom Schritt 67 trennt. Je kürzer dieser kritische Abschnitt ist, um so besser sind die Leistungen des Systems im Hinblick auf die Schnelligkeit. Nun wird dieser kritische Abschnitt im Schritt 64 durch den Schritt 59 konditioniert. Ein zusätzlicher Vorteil wird daher erhalten, wenn dem Schritt 58 der Schritt 57 vorhergeht, so daß das Zeitintervall, das den Schritt 58 vom Schritt 59 trennt, reduziert wird. Dies ist insbesondere möglich, wenn außerhalb der Schritte 60 und 65 keine Aktualisierung der Register TBR erfolgt.
  • 3 zeigt eine Ausführungsvariante der Erfindung in einem Fall, in dem vorzugsweise der Inhalt der Register TBR fixiert wird, um hier einen neuen Wert anzuordnen. Die zusätzlichen Schritte 68 bis 78 werden dann zwischen den Schritten 62 und 67 eingesetzt. Das Ziel dieser Schritte 68 bis 78 ist, genau einem Prozessor jedes Moduls zu ermöglichen, den Inhalt des Registers TBR sämtlicher Prozessoren desselben Moduls während der Aktualisierung des Registers TBR im Schritt 65 zu fixieren. Die Fixierung des Registers TBR besteht darin, ihre Inkrementierung durch den dem Modul eigenen Taktgeber zu blockieren, während die Defixierung darin besteht, die Blockierung der Inkrementierung durch den dem Modul eigenen Taktgeber aufzuheben. Die Blockierung und die Aufhebung der Blockierung der Inkrementierung erfolgt durch interne Schaltungen des Prozessors mit Hilfe von speziellen Befehlen, auf die im Rahmen der Beschreibung nicht genauer eingegangen werden muss.
  • Im Schritt 68 gebt der Slave-Prozessor die Fixierung seines Registers TBR frei, indem er beispielsweise eine Variable, die begin_mynode[node_id] genannt wird, inkrementiert.
  • Die Schritte 69 bis 74 ermöglichen die Zuweisung einer Qualifizierung als erster Prozessor jedes Moduls an genau einen Prozessor, um das Register TBR jedes Prozessors des Moduls zu fixieren.
  • Im Schritt 69 ermittelt der Slave-Prozessor, ob er der erste Slave-Prozessor des Moduls ist, der den Prozess auszuführen hat. Hierzu liest er eine Variable, die beispielsweise freeze_my_node[node_id] genannt wird und jedem Modul eigentümlich ist, das durch einen Identifizierer bezeichnet wird, der node_id genannt wird, und deren erster Zustand bedeutet, daß kein anderer Prozessor des Moduls zum Zeitpunkt eines Lesens dieser Variable in den Schritt 69 eingetreten ist. Es muss jedoch im Gedächtnis behalten werden, daß die Prozesse in jedem Prozessor parallel ablaufen und daß folglich eine Unbestimmtheit hinsichtlich der Qualifikation als erster Prozessor bleibt, falls mehrere Prozessoren desselben Moduls gleichzeitig auf die Variable freeze_my_node[node_id] zugreifen. Falls daher die Variable freeze_my_node[node_id] im ersten Zustand ist, führt der Prozessor die Schritte 70 und 71 aus. Falls die Variable freeze_my_node[node_id] in einem zweiten Zustand ist, was bedeutet, daß ein anderer Prozessor bereits die Qualifizierung als erster Prozessor des Moduls erhalten hat, springt der Prozessor direkt zum Schritt 63.
  • Im Schritt 70 setzt der Prozessor eine dem Modul eigene Sperre, die, wie für parallel ausgeführte Prozesse bekannt ist, zu einem gegebenen Zeitpunkt nur ein einziger Prozessor besitzen kann. Falls die Sperre bereits gesetzt ist, bleibt der Prozessor im Schritt 70 in Wartestellung, bis die Sperre freigegeben wird. Wenn die Sperre freigegeben wird, geht der Prozessor zum Schritt 71. Dadurch wird sichergestellt, daß höchstens ein Prozessor zu einem gegebenen Zeitpunkt den Schritt 71 und dann die folgenden Schritte bis zur Freigabe der Sperre ausführt.
  • Im Schritt 71 ist der Prozessor der einzige, der die Variable freeze_my_node[node_id] liest. Falls die Variable freeze_my_node[node_id] im ersten Zustand ist, springt der Prozessor zum Schritt 73. Im Schritt 73 nimmt der Prozessor die Qualifizierung als erster Prozessor an, indem er die Variable freeze_my_node[node_id] in den zweiten Zustand versetzt und dann die Sperre im Schritt 74 freigibt. Falls die Variable freeze_my_node[node_id] nicht im ersten Zustand ist, bedeutet dies, daß ein anderer Prozessor die Sperre vor ihm besessen hat, um die Variable freeze_my_node[node_id] in den zweiten Zustand zu versetzen, wobei der Prozessor dann zum Schritt 72 springt, indem er die Sperre freigibt.
  • Dem Schritt 72 folgt der Schritt 63, der oben beschrieben worden ist.
  • Dem Schritt 74 folgt der Schritt 75, der wegen der bedingten Verzweigung im Schritt 71 nur durch den ersten Prozessor ausgeführt wird. Im Schritt 75 geht der erste Prozessor jedes Moduls in eine Warteschleife für die Freigabe der Fixierung sämtlicher Prozessoren CPU des Moduls. Hierzu liest der erste Prozessor des Moduls ständig die Variable, die begin_mynode[node_id] genannt wird. Sobald der Wert der Variable, die begin_mynode[node_id] genannt wird, der Anzahl der Prozessoren im Modul entspricht, springt der Prozessor zum Schritt 76.
  • Im Schritt 76 fixiert der erste Prozessor des Moduls das Register TBR sämtlicher Prozessoren des Moduls und springt dann zum Schritt 63.
  • Die Verknüpfung der Schritte 63 bis 65 stimmt mit derjenigen, die mit Bezug auf 2 erläutert worden ist, völlig überein. In 3 folgt jedoch dem Schritt 65 der Schritt 77, so daß verifiziert wird, ob der Prozessor durch die Schritte 73 bis 76 gegangen ist, bevor er zum Schritt 65 geht, d. h. ob der Prozessor der erste Prozessor des Moduls ist. Wenn dies nicht der Fall ist, springt der Prozessor direkt zum Schritt 66. Falls der Prozessor der erste Prozessor des Moduls ist, springt er zum Schritt 78.
  • Im Schritt 78 defixiert der erste Prozessor das Register TBR für sämtliche Prozessoren des Moduls und springt dann zum Schritt 66.
  • Die Folge der Schritte 66 und 67 stimmt mit derjenigen, die mit Bezug auf 2 beschrieben worden ist, völlig überein.

Claims (7)

  1. Verfahren zum Synchronisieren eines Datenverarbeitungssystems auf ein sich zeitlich entwickelndes Datum, wobei das Datenverarbeitungssystem ein oder mehrere Module (14) enthält, wobei jedes Modul (14) jeweils mehrere Prozessoren (1013, 2023, 3033, 4043) enthält, die durch einen diesem Modul (14) eigenen Taktgeber getaktet werden, wobei jeder Prozessor (1013, 2023, 3033, 4043) ein privates Register TBR (1619, 2629, 3639, 4649) enthält, das dazu vorgesehen ist, einen Wert des Datums zu halten, und durch den dem diesen Prozessor (1013, 2023, 3033, 4043) enthaltenden Modul (14) eigenen Taktgeber inkrementiert werden kann, wobei jedes der Module (14) jeweils ein Register TBC (5053) umfasst, das den Prozessoren (1013, 2023, 3033, 4043) desselben Moduls (14) gemeinsam ist, und die Module (14) über einen Bus (5) miteinander kommunizieren, wobei der Inhalt der Register TBC (5053) durch ein Kommunikationsprotokoll auf dem Bus (5) und durch ständige Inkrementierung durch den jeweiligen Taktgeber jedes Moduls (14) zeitlich kohärent gehalten wird, wobei – ein Prozessor (10) als Master des Systems gewählt wird, der jedem der anderen Prozessoren (11, 12, 13, 2023, 3033, 4043) befiehlt, daß er sich in einen bereiten Zustand versetzt und sich als in diesem Zustand befindlich erklärt, wobei der Zustand für jeden der anderen Prozessoren (11, 12, 13, 2023, 3033, 4043) darin besteht, auf eine vom Master-Prozessor (10) des Systems stammende Freigabe zu warten, ohne unterbrochen werden zu können, und – jeder Prozessor (1013, 2023, 3033, 4043), der die Freigabe besitzt, sofort den Inhalt des Registers TBC (5053) liest, das den Prozessoren (1013, 2023, 3033, 4043) desselben Moduls (14) gemeinsam ist, und diesen Inhalt in sein Register TBR (1619, 2629, 3639, 4649) schreibt, ohne unterbrochen werden zu können.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß der Master-Prozessor (10) vor der Steuerung (58) jedes der anderen Prozessoren (11, 12, 13, 2023, 3033, 4043), die Slaves genannt werden, damit sie sich in einen bereiten Zustand (63) versetzen und sich als in diesem Zustand befindlich erklären, um eine atomare Operation auszuführen, einen Datumswert in das Register TBC (50) seines Moduls (1) schreibt (57).
  3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß der Master-Prozessor (10) vor dem Schreiben (57) eines Datumswerts in das Register TBC (50) seines Moduls (1) sich in einen nicht unterbrechbaren Zustand versetzt (56).
  4. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, daß jeder Slave-Prozessor (11, 12, 13, 2023, 3033, 4043) vor seiner Versetzung in den bereiten Zustand (63) sich in einen nicht unterbrechbaren Zustand versetzt (62).
  5. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, daß jeder Prozessor (1013, 2023, 3033, 4043) nach der Versetzung (62) in einen nicht unterbrechbaren Zustand eine Freigabe (68) zur Fixierung seines Registers TBR (1619, 2629, 3639, 4649) meldet.
  6. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, daß in jedem Modul (14) ein Prozessor (10, 20, 30, 40) mittels zweier aufeinanderfolgender Tests desselben Indikators, die durch eine Setzung einer jedem Modul (14) eigenen Sperre getrennt sind, als erster Prozessor für die Fixierung des Registers TBR (1619, 2629, 3639, 4649) jedes Prozessors (1013, 2023, 3033, 4043) qualifiziert wird.
  7. Datenverarbeitungssystem, das ein oder mehrere Module (14) enthält, wovon jedes Modul (14) jeweils mehrere Prozessoren (1013, 2023, 3033, 4043) enthält, die durch einen diesem Modul (14) eigenen Taktgeber getaktet werden, wobei jeder Prozessor (1013, 2023, 3033, 4043) ein privates Register TBR (1619, 2629, 3639, 4649) enthält, das dazu vorgesehen ist, einen Datumswert zu halten, und durch den dem diesen Prozessor (1013, 2023, 3033, 4043) enthaltenden Modul (14) eigenen Taktgeber inkrementiert werden kann, wobei jedes der Module (14) jeweils ein Register TBC (5053) umfasst, das den Prozessoren (1013, 2023, 3033, 4043) desselben Moduls (14) gemeinsam ist und auf das durch die Prozessoren (1013, 2023, 3033, 4043) des Moduls (14) direkt zugegriffen werden kann, und die Module (14) über einen Bus (5) miteinander kommunizieren, wobei der Inhalt der Register TBC (5053) durch ein Kommunikationsprotokoll auf dem Bus (5) und durch ständige Inkrementierung durch den jeweiligen Taktgeber jedes Moduls (14) zeitlich kohärent gehalten wird, wobei das Datenverarbeitungssystem ferner umfasst: – Mittel zum Wählen eines Prozessors (10) als Master des Systems, derart, daß er jeden der anderen Prozessoren (11, 12, 13, 2023, 3033, 4043) so steuert, daß er sich in einen bereiten Zustand versetzt und sich als in diesem Zustand befindlich erklärt, wobei der Zustand für jeden der anderen Prozessoren (11, 12, 13, 2023, 3033, 4043) darin besteht, auf eine vom Master-Prozessor (10) des Systems stammende Freigabe zu warten, ohne unterbrochen werden zu können; und wobei – das in jedem Modul (14) vorgesehene Register TBC (5053) dazu vorgesehen ist, einen Datumswert zu halten, der mit demjenigen des Registers TBC (50) des Moduls (1), in dem sich der Master-Prozessor (10) befindet, völlig übereinstimmt, wenn der Master-Prozessor (10) die Freigabe schickt.
DE19839239.7A 1997-09-04 1998-08-28 Verfahren zum Synchronisieren eines Datenverarbeitungssystems und damit synchronisiertes Datenverarbeitungssystem Expired - Fee Related DE19839239B4 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR9711026 1997-09-04
FR9711026A FR2767935B1 (fr) 1997-09-04 1997-09-04 Procede pour synchroniser un systeme informatique et systeme informatique ainsi synchronise

Publications (2)

Publication Number Publication Date
DE19839239A1 DE19839239A1 (de) 1999-03-11
DE19839239B4 true DE19839239B4 (de) 2015-05-07

Family

ID=9510771

Family Applications (1)

Application Number Title Priority Date Filing Date
DE19839239.7A Expired - Fee Related DE19839239B4 (de) 1997-09-04 1998-08-28 Verfahren zum Synchronisieren eines Datenverarbeitungssystems und damit synchronisiertes Datenverarbeitungssystem

Country Status (6)

Country Link
US (1) US6073247A (de)
JP (1) JP3500311B2 (de)
DE (1) DE19839239B4 (de)
FR (1) FR2767935B1 (de)
GB (1) GB2329987B (de)
IT (1) IT1302177B1 (de)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6292826B1 (en) * 1998-09-28 2001-09-18 Alcatel Internetworking, Inc. Shadow arrays for distributed memory multiprocessor architecture
JP3693896B2 (ja) * 2000-07-28 2005-09-14 三菱電機株式会社 通信方法および通信システム
FR2834090B1 (fr) 2001-12-24 2004-02-20 Bull Sa Procede et systeme de sauvegarde de l'horloge locale d'un perimetre informatique
JP3720825B2 (ja) * 2003-07-28 2005-11-30 ファナック株式会社 数値制御装置
FR2915589B1 (fr) * 2007-04-24 2009-07-10 Schneider Electric Ind Sas Systeme et methode pour gerer le temps dans un equipement d'automatisme

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4890222A (en) * 1984-12-17 1989-12-26 Honeywell Inc. Apparatus for substantially syncronizing the timing subsystems of the physical modules of a local area network
FR2666424B1 (fr) * 1990-08-30 1992-11-06 Bull Sa Procede et dispositif de reglage des signaux d'horloge dans un systeme synchrone.
JPH0752437B2 (ja) * 1991-08-07 1995-06-05 インターナショナル・ビジネス・マシーンズ・コーポレイション メッセージの進行を追跡する複数ノード・ネットワーク
US5537549A (en) * 1993-04-28 1996-07-16 Allen-Bradley Company, Inc. Communication network with time coordinated station activity by time slot and periodic interval number
EP0974912B1 (de) * 1993-12-01 2008-11-05 Marathon Technologies Corporation Fehlerbetriebssichere/Fehlertolerante Computerbetriebsmethode
EP0663637A1 (de) * 1994-01-12 1995-07-19 T.R.T. Telecommunications Radioelectriques Et Telephoniques Übertragungsmedium für ein Elektroniksystem mit mehreren verteilten Prozessoren
US5640523A (en) * 1994-09-02 1997-06-17 Cypress Semiconductor Corporation Method and apparatus for a pulsed tri-state phase detector for reduced jitter clock recovery
JPH08123520A (ja) * 1994-10-25 1996-05-17 Mitsubishi Electric Corp 駆動制御指令装置と複数台の駆動制御指令装置の同期制御システム及びその同期制御方法
US5455540A (en) * 1994-10-26 1995-10-03 Cypress Semiconductor Corp. Modified bang-bang phase detector with ternary output
US5729721A (en) * 1995-11-13 1998-03-17 Motorola, Inc. Timebase synchronization in separate integrated circuits or separate modules

Non-Patent Citations (8)

* Cited by examiner, † Cited by third party
Title
Anne DINNING: A Survey of Synchronization Methods for Parallel Computers, 1989, In: IEEE Computer, Vol. 22 (7) 66-77, DOI: 10.1109/2.30733 *
C.A.R. HOARE: Monitors: An Operating System Structuring Concept, 1974; In: Commun. ACM 17 (10) 549-557; DOI: 10.1145/355620.361161 *
DIEFENDORFF, K.; OEHLER, R.; HOCHSPRUNG, R.: Evolution of the PowerPC Architecture, 1994; In: IEEE Micro, Vol. 14 (2) 34-49; DOI: 10.1109/40.272836 *
G. GRAUNKE, S. THAKKAR: Synchronization Algorithms for Shared-Memory Multiprocessors; In: IEEE Computer, Vol. 23 (6) 60-69, Juni 1990; DOI: 10.1109/2.55501 *
LAMPORT, L.: Time, Clocks, and the Ordering of Events in a Distributed System, 1978; In: Commun. ACM, 21(7): 558-565; DOI: 10.1145/359545.359563 *
M. Michael MAGED, Ashwini K. NANDAT, Beng-Hong LIMT, and Michael L. SCOTT: Coherence Controller Architectures for SMP-Based CC-NUMA Multiprocessors, 1997; In: ACM SIGARCH (ISCA '97), ISBN: 0-89791-901-7, Vol. 25 (2) 219-228; DOI: 10.1145/384286.264203 *
PowerPC Microprocessor Family: The Programmer’s Reference Guide; 1995; (c) Motorola Inc. 1995, [online] URL: https://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/852569B20050FF778525699600741775/file/prg.pdf [abgerufen am 7.8.2012]
PowerPC Microprocessor Family: The Programmer's Reference Guide; 1995; (c) Motorola Inc. 1995, [online] URL: https://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/852569B20050FF778525699600741775/file/prg.pdf [abgerufen am 7.8.2012] *

Also Published As

Publication number Publication date
ITMI981950A1 (it) 2000-03-02
JP3500311B2 (ja) 2004-02-23
FR2767935A1 (fr) 1999-03-05
GB9818213D0 (en) 1998-10-14
GB2329987B (en) 2002-09-25
DE19839239A1 (de) 1999-03-11
GB2329987A (en) 1999-04-07
IT1302177B1 (it) 2000-07-31
US6073247A (en) 2000-06-06
ITMI981950A0 (it) 1998-09-02
FR2767935B1 (fr) 1999-11-12
JPH11161623A (ja) 1999-06-18

Similar Documents

Publication Publication Date Title
DE2251876C3 (de) Elektronische Datenverarbeitungsanlage
DE4216871C2 (de) Ausführungsordnen zum Sicherstellen der Serialisierbarkeit verteilter Transaktionen
DE60217157T2 (de) Verfahren und vorrichtung zum binden von shadow-registern an vektorisierte interrupts
DE69911026T2 (de) Synchronisation von prozessoren in einem fehlertoleranten multi-prozessor-system
DE3110196A1 (de) Datenverarbeitungssystem
DE3606211A1 (de) Multiprozessor-computersystem
DE69937715T2 (de) Verbessertes Zwei-Phasen-Bindungsprotokoll
EP2214104A1 (de) Umkonfigurierungs-Verfahren für programmierbare Bausteine während der Laufzeit
EP0762274A1 (de) Einrichtung und Verfahren zur Echtzeit-Verarbeitung einer Mehrzahl von Tasks
DE4033336A1 (de) Verfahren zum erzeugen einer ausfallmeldung und mechanismus fuer ausfallmeldung
DE2916658A1 (de) Selbstprogrammierbarer mikroprozessor
DE2731188A1 (de) Datenverarbeitungssystem
DE4018505A1 (de) Mikrocomputersystem mit mikroprozessorruecksetzschaltung
DE60132424T2 (de) Taktschutz für gemeinsame Komponenten einer Multiprozessor-DSP Vorrichtung
DE60132961T2 (de) Unabhängige Initialisierung von Arbitern und Agenten, um verzögerte Agent-Initialisierung zu ermöglichen
DE19839239B4 (de) Verfahren zum Synchronisieren eines Datenverarbeitungssystems und damit synchronisiertes Datenverarbeitungssystem
DE69233345T2 (de) Ein-Chip-Mikrocomputer mit zwei Zeitgeberfunktionsarten
DE10344626A1 (de) Systeme und Verfahren zum Zugreifen auf busmastergesteuerte Systembetriebsmittel
EP1428340B1 (de) Verfahren und vorrichtung zur erzeugung von programmunterbrechungen bei teilnehmern eines bussystems und bussystem
DE60127357T2 (de) Ausführung von einem PCI-Arbiter mit dynamischem Prioritätsschema
DE102006009034B3 (de) Verfahren zum Betreiben eines Bussystems sowie Halbleiter-Bauelement, insbesondere Mikroprozessor- bzw. Mikrocontroller
DE60313088T2 (de) Gatterwortakquisition in einer Multiprozessor-&#34;Write-Into-Cache&#34;-Umgebung
DE10228778B4 (de) Hardware-Verfahren zum Implementieren von atomischen Semaphoroperationen unter Verwendung von Codemakros
DE19814359C2 (de) Interface-Einrichtung, Verfahren und Überwachungs-System zum Überwachen des Status einer Hardware-Einrichtung
DE2813079C3 (de) Mehrrechnersystem hoher Sicherheit

Legal Events

Date Code Title Description
8127 New person/name/address of the applicant

Owner name: BULL S.A., LES CLAYES SOUS BOIS, FR

8110 Request for examination paragraph 44
8125 Change of the main classification

Ipc: G06F 15/16 AFI20051017BHDE

R016 Response to examination communication
R018 Grant decision by examination section/examining division
R020 Patent grant now final
R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee