Brevet FR2767935A1 — publié le 19990305

Procédé pour synchroniser un système informatique et système informatique ainsi synchronisé. Le domaine de l'invention est celui de la synchronisation de systèmes informatiques sur des dates évolutives au cours du temps. Dans un système informatique, il est utile de pouvoir dater différents événements intervenant sur le système. Il est par exemple intéressant de connaître la date exprimée en années, mois, jours, heures, minutes et secondes de création ou de modification d'un fichier. Pour certains événements qui déclenchent des procédures particulières, il est intéressant de préciser la date jusqu'à la milliseconde, voire la microseconde ou une portion de microseconde. l est nécessaire pour cela que le système dispose d'une date de référence qui évolue dans le temps par incrémentation de sa valeur, par exemple au moyen d'une horloge. Il est utile de pouvoir initialiser une valeur de cette date à tout moment. Par exemple, au démarrage du système, on peut vouloir prendre comme date initiale celle contenue dans une mémoire incrémentée par une batterie de sauvegarde, indépendante d'une coupure d'alimentation en puissance du système. Après démarrage du système, on peut vouloir modifier la date courante pour tenir compte de différents impératifs tels qu'à titre d'exemples non limitatifs, un changement d'heure locale, un recadrage de calendrier, une dérive d'horloge, une panne de batterie de sauvegarde ou une synchronisation avec un système différent. Pour dater avec précision certains événements traités par un processeur, il est intéressant que le processeur possède une valeur courante de date dans un registre privé auquel il accède rapidement. Cette valeur est incrémentée matériellement au moyen d'une horloge qui rythme par ailleurs le séquencement du processeur. Selon l'état de la technique connu, suite à une demande de modification de la valeur de date courante, le processeur exécute une séquence qui consiste essentiellement à ajouter à la valeur courante contenue dans son registre privé, une différence A représentative du décalage entre les valeurs courantes de date avant et après modification. On est sur ainsi que, quelque soit l'instant auquel le processeur modifie la date dans son registre, la nouvelle valeur courante tient compte de l'évolution de date dans le temps. Dans un système comprenant plusieurs processeurs, on peut envisager que chaque processeur effectue successivement ou simultanément la séquence que nous venons de décrire. On remarque que, dans le cas o tous les processeurs sont rythmés à partir d'une même horloge, si un second processeur exécute la séquence à un instant ultérieur auquel un premier processeur l'a exécutée, les registres privés des deux processeurs ont été incrémentés de la même quantité entre ces deux instants et les valeurs des registres privés des deux processeurs sont identiques après la dernière exécution de la séquence. Cette remarque reste valable pour un nombre quelconque de processeurs. Dans un système constitué de plusieurs modules, chaque module constituant un sous- système qui comprend un ou plusieurs processeurs, il est possible de distribuer sur les modules un signal issu d'une même horloge de façon à rythmer tous les processeurs du système en synchronisme. Par exemple, le brevet US5305453 décrit une solution pour caler le signal d'horloge distribué sur une phase identique à sa réception dans chaque module. Cependant, ceci nécessite une technologie de réalisation identique pour tous les modules: même fréquence de fonctionnement, même bande passante des composants physiques, etc. D'autre part, ceci nécessite aussi des raccordements physiques spécialisés entre modules. Tout remplacement ou tout ajout ultérieur de module pour augmenter les performances du système nécessite de conserver la technologie initiale ou d'effectuer des adaptations spéciales et souvent des câblages supplémentaires. Des exécutions de séquences qui consistent à mettre à jour une date en ajoutant la différence A au contenu du registre privé de chaque processeur, tel que précédemment mentionné, posent quelques problèmes pour se dispenser d'une référence d'horloge physiquement commune à tous les modules d'un système informatique. En effet, dans un système o chaque module dispose d'une référence d'horloge propre, distincte de celle des autres modules, si un processeur d'un second module ajoute la différence A à un instant t+dt après un instant t auquel un processeur d'un premier module ajoute la différence A, il est difficile de s'assurer que les registres privés des deux processeurs ont été incrémentés de la même quantité entre ces deux instants car des horloges distinctes ne sont pas nécessairement de fréquences et de phases identiques. A supposer possible une synchronisation parfaite entre les processeurs de tous les modules du système de façon à ce que toutes les exécutions de la séquence décrite se fasse au même instant t, des problèmes de dérives dans les valeurs de dates entre processeurs de différents modules restent non résolus. Des problèmes de dérive dans les valeurs de dates entre deux processeurs, se présentent lorsque les deux processeurs sont rythmés par des signaux d'horloge indépendants. Si à un instant initial, le registre privé du premier processeur contient une valeur de date identique à celle contenue dans le registre privé du deuxième processeur, l'incrémentation des registres privés par des signaux d'horloge différents, provoque un écart entre les deux valeurs qui augmente au cours du temps, il en résulte une dérive de la valeur de date d'un processeur par rapport à l'autre. En remettant périodiquement une nouvelle valeur de date dans le registre privé de chaque processeur, par exemple avant que la dérive ne fasse sortir les valeurs de date d'une plage de précision donnée, on obtient des valeurs de dates identiques dans cette plage de précision pour les processeurs de tous les modules. Ceci permet de synchroniser le système sur une date unique, considérée dans la plage de précision donnée. Cependant, une addition de A comme précédemment décrite n'est pas applicable, en particulier parce qu'il est difficile de maîtriser la valeur de dérive entre modules avec exactitude. L'invention a pour objet un procédé pour synchroniser un système informatique sur une date évolutive au cours du temps, ledit système informatique comprenant un ou plusieurs modules, chaque module comprenant plusieurs processeurs rythmés par une horloge propre à ce module, chaque processeur comprenant un registre privé TBR prévu pour contenir une valeur de ladite date et pour subir une incrémentation par l'horloge propre au module comprenant ce processeur, caractérisé en ce que: - un processeur est élu maître du système pour commander à chacun des autres processeurs de se mettre et de se déclarer dans un état prêt qui consiste, pour chaque processeur, à attendre une autorisation en provenance du processeur maître du système, sans pouvoir être interrompu; - chaque processeur possédant ladite autorisation, effectue immédiatement une lecture du contenu d'un registre TBC directement accessible aux processeurs d'un même module suivie d'une écriture de ce contenu dans son registre TBR sans pouvoir être interrompu, le contenu du dit registre TBC et le contenu d'un registre TBC directement accessible au processeur maître étant identiques au moment de ladite lecture. L'invention a aussi pour objet un système informatique comprenant un ou plusieurs modules, chaque module comprenant plusieurs processeurs rythmés par une horloge propre à ce module, chaque processeur comprenant un registre privé TBR prévu pour contenir une valeur de date et pour subir une incrémentation par l'horloge propre au module comprenant ce processeur, caractérisé en ce qu'il comprend: - des moyens pour élire un processeur maître du système de façon à commander à chacun des autres processeurs de se mettre et de se déclarer dans un état prêt qui consiste, pour chaque processeur, à attendre une autorisation en provenance du processeur maître du système, sans pouvoir être interrompu; - dans chaque module, un registre TBC directement accessible aux processeurs du module et incrémenté par l'horloge propre au module, prévu pour contenir une valeur de date identique à celle du registre TBC du module o est situé le processeur maître lorsque le processeur maître envoie ladite autorisation. D'autres aspects et détails de réalisation du procédé et du système selon l'invention seront également exposés dans la description qui va suivre. - La figure 1 représente un système synchrone selon l'invention. - La figure 2 représente des étapes de procédé conformes à l'invention. - La figure 3 représente une variante des étapes de procédé conformes à l'invention. En référence à la figure 1, un système informatique comprend un ou plusieurs modules 1, 2, 3, 4, sans que le nombre de quatre soit limitatif. Le module 1 comprend plusieurs processeurs 10, 11, 12, 13 nommés CPU, rythmés par une horloge propre au module, non représentée pour ne pas surcharger inutilement la figure. De même, le module 2 comprend plusieurs processeurs 20, 21, 22, 23 nommés CPU, rythmés par une horloge propre au module 2; le module 3 comprend plusieurs processeurs 30, 31, 32, 33 nommés CPU, rythmés par une horloge propre au module 3 et le module 4 comprend plusieurs processeurs 40, 41, 42, 43 nommés CPU, rythmés par une horloge propre au module 4. Le système reste conforme à l'invention si un module comprend un nombre de processeurs différent de quatre, par exemple deux ou six. La mémoire du système est répartie dans les modules au moyen d'unités mémoire 14, 24, 34, 44, physiquement situées chacune respectivement dans le module 1, 2, 3, 4. Chaque processeur accède en lecture et écriture à l'ensemble des mémoires 14, 24, 34, 44 au moyen de protocoles de cohérence antémémoire tel que ceux décrits dans les demandes de brevet FR9706747, FR9706388 ou FR9706387, déposées au nom de la présente demanderesse. Comme expliqué dans les demandes citées ci-dessus, la mise en oeuvre des protocoles de cohérence antémémoire est faite au moyen d'organes nommés PKC, repérés 6, 7, 8 et 9 sur la figure 1. L'organe 6 est situé physiquement dans le module 1 et communique localement avec les processeurs 10 à 13 et avec la mémoire 14 au moyen d'un bus système 15. De même, l'organe 7 est situé physiquement dans le module 2 et communique localement avec les processeurs 20 à 23 et avec la mémoire 24 au moyen d'un bus système , l'organe 8 est situé physiquement dans le module 3 et communique localement avec les processeurs 30 à 33 et avec la mémoire 34 au moyen d'un bus système 35, l'organe 8 est situé physiquement dans le module 4 et communique avec les processeurs 40 à 43 et avec la mémoire 44 au moyen d'un bus système 45. D'autre part, les organes 6 à 9 communiquent entre eux à distance au moyen d'un bus 5 extérieur aux modules 1 à 4. Le protocole de communication sur le bus 5 est par exemple le protocole connu SCI. L'architecture décrite permet de mettre en oeuvre un système d'exploitation commun à l'ensemble des modules 1 à 4 et à tout module supplémentaire dont l'organe PKC est connecté sur le bus 5. Chaque processeur CPU comprend un registre privé de base de temps nommé TBR, prévu pour contenir une valeur de date évolutive au cours du temps. Dans le module 1, chaque registre 16, 17, 18, 19, respectivement attribué au processeur 10, 11, 12, 13, est prévu pour subir une incrémentation par l'horloge propre au module 1. Par exemple, chaque registre privé TBR code la valeur de date sur 64 bits dont chaque incrément correspond à une impulsion d'horloge. Si l'horloge du module 1 est à une fréquence de 100 MHz, une impulsion d'horloge représente alors 10 vs. Un rapide calcul sur la puissance 64 de 2 montre qu'il est possible de coder dans chaque registre TBR une valeur de plus de 5849 ans avec un pas de 10 vs. A une fréquence de 1 GHz, on voit qu'il est possible de coder une valeur de plus de 584 ans avec un pas de 1 vs. Le contenu du registre TBR permet donc au processeur de dater les événements qu'il traite, sur une grande plage de temps avec une haute résolution. D'autre part le processeur CPU peut comprendre un ou plusieurs registres de décrémentation, non représentés, dont le passage à zéro provoque une interruption. En rangeant dans un registre de décrémentation, par exemple 32 bits chargés à partir du registre TBR, il est possible de déclencher un événement à une date précise et ainsi de synchroniser le système. De même, dans le module 2, chaque registre 26, 27, 28, 29, respectivement attribué au processeur 20, 21, 22, 23, est prévu pour subir une incrémentation par l'horloge propre au module 2. Dans le module 3, chaque registre 36, 37, 38, 39, respectivement attribué au processeur 30, 31, 32, 33, est prévu pour subir une incrémentation par l'horloge propre au module 3. Dans le module 4, chaque registre 46, 47, 48, 49, respectivement attribué au processeur 40, 41, 42, 43, est prévu pour subir une incrémentation par l'horloge propre au module 4. L'organe 6 comprend un registre 50, nommé TBC, commun aux processeurs 10, 11, 12, 13, en ce sens que ce registre est accessible, au moins en lecture, à ces processeurs. Le registre 50 a un format identique à celui des registres TBR. Le registre 50 est prévu pour être incrémenté en permanence par l'horloge propre au module 1. Le contenu du registre évolue donc dans le temps en concordance avec le contenu des registres 16, 17, 18, 19. Chacun des organes 7, 8, 9, comprend respectivement un registre 51, 52, 53, identique au registre 50, structurellement et fonctionnellement pour chaque module 2, 3, 4, auquel il appartient. Les contenus des registres TBC 50, 51, 52 et 53 sont identiques à tout instant dans une plage de précision donnée. Pour ce faire, toute écriture dans un registre TBC, autre que l'incrémentation précédemment décrite, provoque une recopie de ce registre TBC dans les autres registres TBC de façon matérielle, en tenant compte du temps nécessaire à une donnée pour circuler d'un organe PKC à un autre sur le bus 5. A l'initialisation du système, un module est sélectionné comme module maître de base de temps. Ce module est nommé TBMM. Si le module TBMM est par exemple le module 1, la configuration de l'organe 6 permet aux processeurs 10 à 13 d'accéder en écriture au registre 50 de façon à pouvoir y ranger une valeur de date. Dans ce cas, les registres 51, 52, 53, sont accessibles en écriture uniquement à partir du bus 5 sur lequel circulent des paquets de synchronisation pour rendre cohérent les contenus des registres 51, 52, 53 avec le contenu du registre 50. Comme il est dit précédemment, l'architecture décrite permet de mettre en oeuvre un système d'exploitation commun à l'ensemble des modules 1 à 4 désignés à titre d'exemple non limitatif. Le système d'exploitation comprend un noyau (kernel en anglais) constitué de différentes fonctions pour gérer des ressources du système. On dit qu'une application fait un appel système lorsqu'elle appelle une fonction du noyau. On s'intéresse plus particulièrement ici à une fonction nommée ksettimer, destinée à synchroniser le système, c'est à dire à fournir une base de temps de référence commune à tous les éléments du système. La fonction ksettimer peut être appelée à l'initialisation du système, par une application qui demande un changement de date de référence pour le système, date exprimée non seulement en années, mois, jours mais aussi en heures, minutes, secondes avec une résolution de l'ordre de la nanoseconde. La fonction ksettimer peut aussi être appelée régulièrement pour remettre à jour la date de façon à palier des dérives entre les différentes horloges du système et par rapport au temps universel. Un appel de la fonction ksettimer déclenche un processus principal dont l'exécution débute dans un processeur a priori quelconque du système, en fonction d'une allocation de processeurs aux processus faite par un ordonnanceur (scheduler en anglais) et par un distributeur (dispatcher en anglais), non représentés car connus de l'homme du métier. En référence à la figure 2, le processus principal commence par une étape 54 dans laquelle est vérifié si le processeur qui exécute le processus de mise à jour de la date, est un processeur du module TBMM. Si ce n'est pas le cas, le processus avec son contexte est transféré vers le module TBMM o le distributeur attribue un processeur du module TBMM, alors élu maître du système. Considérons par exemple, dans la suite de la description, le cas o le module TBMM est le module 1 avec le processeur 10 élu maître. Le processeur maître exécute alors une succession d'étapes 55 à 61. Dans l'étape 55 est vérifiée que toute mise à jour de la date précédente éventuelle est terminée. Pour cela, une boucle infinie scrute un tableau dont chaque ligne attribuée à un processeur du système, contient une variable nommée timeupdates qui, positionnée à une première valeur, signale que le processeur auquel est attribuée la ligne, n'est pas en instance de mettre à jour son registre TBK Toutes les variables time updates du tableau sont ensuite positionnées à une deuxième valeur pour signaler qu'une mise à jour de la date est en cours. Dans l'étape 56 sont masquées toutes les interruptions sur le processeur maître, de façon à définir une section critique sur le processeur maître, entre l'étape 56 et l'étape 61 o les interruptions sur le processeur maître sont démasquées. Dans l'étape 57, le processeur maître écrit la valeur de date reçue lors de l'appel de la fonction ksettimer, dans le registre TBC de son module. Dans le cas o le processeur maître est le processeur 10, la valeur de date est écrite dans le registre 50. La valeur de date est alors propagée du registre 50 aux registres 51, 52, 53, par le protocole de communication sur le bus 5, comme décrit précédemment. Si besoin est, avant d'écrire la valeur de date dans le registre 50, le processeur 10 a converti cette valeur dans un format compatible avec celui du registre 50. Chacun des registres 50, 51, 52, 53 continue à être incrémenté par l'horloge de respectivement chacun des modules 1, 2, 3, 4. L'étape 58 consiste essentiellement à préparer une opération atomique qui sera exécutée par chacun des autres processeurs, alors nommés processeurs esclaves. Le processeur maître positionne une variable nommée gotime, à une première valeur pour indiquer que l'opération atomique n'est pas autorisée. Le processeur maître envoie ensuite une interruption nommée inttimer à tous les autres processeurs. La réception de l'interruption inttimer dans chaque processeur esclave, y déclenche une exécution d'un processus auxiliaire comprenant essentiellement des étapes 62 à 67 décrites plus loin. L'étape 59 a pour but de donner aux processeurs esclaves une autorisation pour exécuter l'opération atomique. Rappelons que lors d'une opération atomique, le processeur qui l'exécute ne se branche sur aucune instruction interne autre que celles de l'opération jusqu'à ce que l'opération soit terminée. Dans l'étape 59, le processeur maître exécute d'abord une boucle d'attente dans laquelle il lit une variable logique nommée pcpuready, et sort de la boucle lorsque tous les bits de la variable pcpuready sont à un état vrai, signifiant que tous les processeurs esclaves sont prêts à exécuter l'opération atomique. En sortant de la boucle d'attente, le processeur maître positionne une variable nommée gotime dans un état vrai, signifiant l'autorisation pour exécuter l'opération atomique. Dans l'étape 60, le processeur maître exécute l'opération atomique qui consiste essentiellement à charger la valeur contenue dans le registre TBC de son module et à ranger cette valeur dans son registre TBR, en effectuant si nécessaire des conversions de mise au format adéquat du registre TBR Par exemple le processeur 10 charge la valeur contenue dans le registre 50 et la range dans le registre 16. Dans l'étape 61, le processeur maître positionne la variable nommée time updates de la ligne du tableau qui lui est attribuée à la première valeur, signalant que le processeur maître n'est pas en instance de mettre à jour son registre TBRI Le processeur maître se remet ensuite sur le niveau de priorité qui existait avant le déclenchement de l'étape 56. L'étape 62 est déclenchée dans chaque processeur esclave à réception de l'interruption inttimer. Chaque processeur esclave sauve naturellement le contexte d'un éventuel processus en cours d'exécution et masque toutes les interruptions qui le concernent, de façon à définir une section critique sur le processeur esclave, entre l'étape 62 et l'étape 67 o les interruptions sur le processeur esclave sont démasquées. Dans l'étape 63, le processeur esclave positionne, dans la variable logique nommée pcpu_ready, le bit qui lui correspond, à un état vrai, signifiant que le processeur esclave est prêt à exécuter l'opération atomique. Dans l'étape 64, le processeur esclave exécute une boucle d'attente dans laquelle il lit la variable logique nommée gotime, et sort de la boucle lorsque la variable logique gotime est vraie. Les séquences de processus dans chaque processeur esclave étant identiques, chaque processeur esclave d'un même module lit le passage de la variable gotime à l'état vrai, au même instant sur son bus local. Par exemple, les processeurs 20 à 23 lisent l'état de la variable gotime sur le bus 25 au même instant. De même, les processeurs 30 à 33 lisent l'état de la variable gotime sur le bus 35 au même instant, et les processeurs 40 à 43 lisent l'état de la variable gotime sur le bus 45 au même instant. Les processeurs 16 à 19 lisent eux aussi l'état de la variable gotime sur le bus 15 au même instant. Ceci est facilité en particulier par mise en oeuvre d'un protocole de cohérence antémémoire tel que celui décrit dans les demandes de brevet FR9706747, FR9706388 ou FR9706387, déposées au nom de la présente demanderesse. Ainsi tous les processeurs d'un même module passent simultanément dans l'étape 65. Dans l'étape 65, chaque processeur esclave exécute l'opération atomique qui consiste essentiellement à charger la valeur contenue dans le registre TBC de son module et à ranger cette valeur dans son registre TBR, en effectuant si nécessaire des conversions de mise au format adéquat du registre TBR. Par exemple chacun des processeurs 20 à 23 charge la valeur contenue dans le registre 51 et la range respectivement dans le registre 26, 27, 28, 29 au même instant t2. De même, chacun des processeurs 30 à 33 charge la valeur contenue dans le registre 52 et la range respectivement dans le registre 36, 37, 38, 39 au même instant t3 et chacun des processeurs 40 à 43 charge la valeur contenue dans le registre 53 et la range respectivement dans le registre 46, 47, 48, 49 au même instant t4. Chacun des processeurs 10 à 13 charge, lui aussi la valeur contenue dans le registre 50 et la range respectivement dans le registre 16, 17, 18, 19 au même instant tl. Il importe peu que les instants tl à t4 soient différents, par exemple à cause de latences dans le protocole de cohérence antémémoire inter-modules, en effet le contenu des registres 50 à 53 est maintenu temporellement cohérent à tout instant par le protocole de communication sur le bus 5 et l'incrémentation permanente par l'horloge respective de chaque module. Ainsi, les contenus de tous le registres TBR sont synchrones. Dans l'étape 66, le processeur esclave positionne la variable nommée timeupdates de la ligne du tableau qui lui est attribuée à la première valeur, signalant que le processeur esclave n'est pas en instance de mettre à jour son registre TBK Dans l'étape 67, le processeur esclave se remet ensuite sur le niveau de priorité qui existait avant le déclenchement de l'étape 62. Dans l'exemple de mise en oeuvre présenté, on remarque que l'étape 57 précède l'étape 58. En fait, l'ordre des étapes 57 et 58 n'est pas fondamental pour mettre en oeuvre l'invention. Cependant, l'étape 58 génère une section critique dans chaque processeur esclave, définie sur l'intervalle de temps qui sépare l'étape 62 de l'étape 67, Plus courte est cette section critique, meilleures sont les performances du système en termes de rapidité. Or cette section critique est conditionnée en étape 64 par l'étape 59. Un avantage supplémentaire est donc obtenu en faisant précéder l'étape 58 par l'étape 57, de façon à réduire l'intervalle de temps qui sépare l'étape 58 de l'étape 59. Ceci est possible en particulier, lorsqu'aucune mise à jour des registres TBR ne s'effectue en dehors des étapes et 65. La figure 3 présente une variante de mise en oeuvre de l'invention dans un cas o il est préférable de geler le contenu des registres TBR pour y ranger une nouvelle valeur. Des étapes supplémentaires 68 à 78 viennent alors s'intercaler entre les étapes 62 à 67. Le but des étapes 68 à 78 est de permettre à un processeur et un seul de chaque module de geler le contenu du registre TBR de tous les processeurs du même module pendant la mise à jour du registre TBR en étape 65. Le gel du registre TBR consiste à bloquer son incrémentation par l'horloge propre au module, le dégel consiste à débloquer son incrémentation par l'horloge propre au module. Le blocage et le déblocage d'incrémentation est réalisé par des circuits internes au processeur à l'aide d'instructions spécialisées sur lesquelles il n'est pas nécessaire de s'étendre dans le cadre de la description. Dans l'étape 68, le processeur esclave donne une autorisation de geler son registre TBR en incrémentant par exemple une variable nommée begin_mynode[nodeid]. Les étapes 69 à 74 permettent d'attribuer à un processeur et un seul, une qualification de premier processeur de chaque module pour geler le registre TBR de chaque processeur du module. Dans l'étape 69, le processeur esclave regarde s'il est le premier processeur esclave du module à exécuter le processus. Pour cela, il lit une variable nommée par exemple freeze_mynode[nodeid], propre à chaque module référencé par un identificateur nommé nodeid, et dont un premier état signifie qu'aucun autre processeur du module n'est entré dans l'étape 69 au moment d'une lecture de cette variable. Cependant, il faut garder à l'esprit que les processus s'exécutent en parallèle sur chaque processeur et que, par conséquent, il reste une indétermination sur la qualification de premier processeur si plusieurs processeurs d'un même module accèdent simultanément à la variable freeze_my_node[nodeid]. C'est pourquoi, si la variable freeze_my_node[nodeid] est dans le premier état, le processeur exécute les étapes 70 et 71. Si la variable freeze=my_node[nodeid] est dans un second état qui signifie qu'un autre processeur a déjà obtenu la qualification de premier processeur du module, le processeur se branche directement sur l'étape 63. Dans l'étape 70, le processeur prend un verrou propre au module qui, comme il est connu dans les processus exécutés en parallèle, ne peut être détenu que par un seul processeur à un instant donné. Si le verrou est déjà pris, le processeur reste en attente sur l'étape 70 jusqu'à ce que le verrou se libère. Lorsque le verrou se libère, le processeur passe dans l'étape 71.On s'assure ainsi qu'au plus un processeur exécute l'étape 71 à un instant donné, puis les étapes suivantes jusqu'à libération du verrou. Dans l'étape 71, le processeur est le seul à lire la variable freeze my_node[nodeid]. Si la variable freeze_my_node[node id] est dans le premier état, le processeur se branche sur l'étape 73. Dans l'étape 73, le processeur prend la qualification de premier processeur en mettant la variable freezemy_node[nodeid] dans le second état puis libère le verrou en étape 74. Si la variable freeze_mynode[nodeid] n'est pas dans le premier état, cela signifie qu'un autre processeur a détenu le verrou avant lui pour mettre la variable freeze_mynode[nodeid] dans le second état, le processeur se branche alors en étape 72 dans laquelle il libère le verrou. A l'étape 72 succède l'étape 63 telle que décrite précédemment. A l'étape 74 succède l'étape 75 exécutée uniquement par le premier processeur à cause du branchement conditionnel en étape 71. Dans l'étape 75, le premier processeur de chaque module se met sur une boucle d'attente d'autorisation de gel de tous les processeurs CPU du module. Pour cela, le premier processeur du module lit en permanence la variable nommée begin_mynode[nodeid]. Dès que la valeur de la variable nommée begin_mynode[nodeid] correspond au nombre de processeurs dans le module, le processeur se branche sur l'étape 76. Dans l'étape 76, le premier processeur du module gèle le registre TBR de tout les Io processeurs du module puis se branche sur l'étape 63. L'enchaînement des étapes 63 à 65 est identique à celui expliqué en référence à la figure 2. Cependant, en référence à la figure 3, l'étape 77 succède à l'étape 65 de façon à vérifier si le processeur est passé par les étapes 73 à 76 avant de passer par l'étape 65, c'est à dire si le processeur est le premier processeur du module. Si ce n'est pas le cas, le processeur se branche directement sur l'étape 66. Si le processeur est le premier processeur du module, il se branche sur l'étape 78. Dans l'étape 78, le premier processeur dégèle le registre TBR de tous les processeurs du module puis se branche en étape 66. La succession des étapes 66 et 67 est identique à celle décrite en référence à la figure 2. Revendications 1. Procédé pour synchroniser un système informatique sur une date évolutive au cours du temps, ledit système informatique comprenant un ou plusieurs modules (1,2,3,4), chaque module (1,2) comprenant plusieurs processeurs (10,11,12,13,20,21,22,23) rythmés par une horloge propre à ce module (1,2), chaque processeur (10,11,12,13,20,21,22,23) comprenant un registre privé TBR (16,17,18,19,26,27,28,29) prévu pour contenir une valeur de ladite date et pour subir une incrémentation par l'horloge propre au module (1,2) comprenant ce processeur (10,11,12,13,20,21,22, 23), caractérisé en ce que: - un processeur (10) est élu maître du système pour commander à chacun des autres processeurs (11,12,13,20,21, 22,23) de se mettre et de se déclarer dans un état prêt qui consiste, pour chaque processeur (11,12,13,20,21,22,23), à attendre une autorisation en provenance du processeur maître (10) du système, sans pouvoir être interrompu; - chaque processeur (10,11,12,13,20,21,22,23) possédant ladite autorisation, lit immédiatement le contenu d'un registre TBC (50,51) commun aux processeurs (10,11,12,13,20,21,22,23) d'un même module (1,2) et écrit ce contenu dans son registre (16,17,18,19,26,27,28,29) TBR sans pouvoir être interrompu. 2. Procédé pour synchroniser un système informatique sur une date évolutive au cours du temps, ledit système informatique comprenant un ou plusieurs modules (1,2,3,4), chaque module (1,2) comprenant plusieurs processeurs (10,11,12,13,20,21,22,23) rythmés par une horloge propre à ce module (1,2), chaque processeur (10,11,12,13,20,21,22,23) comprenant un registre privé TBR (16,17,18,19,26,27,28,29) prévu pour contenir une valeur de ladite date et pour subir une incrémentation par l'horloge propre au module (1,2) comprenant ce processeur (10,11,12,13,20,21,22, 23), caractérisé en ce que: - un processeur (10) est élu (54) maître du système pour commander (58) à chacun des autres processeurs (11,12,13,20, 21,22,23), dits esclaves, de se mettre et de se déclarer dans un état prêt (63) pour exécuter une opération atomique; - le processeur maître (10) signale une autorisation (59) d'exécuter ladite opération atomique; chaque processeur (10,11,12,13,20,21,22,23) prenant connaissance (58,63) de ladite autorisation, exécute immédiatement (60,65) ladite opération atomique. 3. Procédé pour synchroniser un système informatique selon la revendication 2, caractérisé en ce que ladite opération atomique consiste essentiellement à: - charger une valeur ayant pour unité un multiple de la période de l'horloge propre au module, contenue dans un registre TBC (50,51) commun aux processeurs (10,11,12,13,20,21,22,23) du module (1,2) et incrémenté en permanence par l'horloge propre au module (1,2), - ranger cette valeur dans le registre privé TBR (16,17,18, 19,26,27,28,29) du processeur (10,11,12,13,20,21,22,23) exécutant ladite opération atomique. 1o 4. Procédé pour synchroniser un système informatique selon l'une des revendications précédentes, caractérisé en ce que, avant de commander (58) à chacun des autres processeurs (11,12,13,20,21,22,23), dits esclaves, de se mettre et de se déclarer dans un état prêt (63) pour exécuter une opération atomique, le processeur maître (10) écrit (57) une valeur de date dans le registre TBC (50) de son module (1). 5. Procédé pour synchroniser un système informatique selon l'une des revendications précédentes, caractérisé en ce que, avant d'écrire (57) une valeur de date dans le registre TBC (50) de son module (1), le processeur maître (10) se met (56) dans un état ininterruptible. 6. Procédé pour synchroniser un système informatique selon l'une des revendications précédentes, caractérisé en ce que, avant de se mettre dans un état prêt (63), chaque processeur esclave (11,12,13,20,21,22,23) se met (62) dans un état ininterruptible. 7. Procédé pour synchroniser un système informatique selon l'une des revendications précédentes, caractérisé en ce que, après s'être mis (62) dans un état ininterruptible, chaque processeur (10,11,12,13,20,21,22,23) signale une autorisation (68) de gel de son registre TBR (16,17,18,19,26,27,28,29). 8. Procédé pour synchroniser un système informatique selon l'une des revendications précédentes, caractérisé en ce que dans chaque module (1,2), un processeur (11,20) est qualifié premier processeur pour geler le registre TBR (16,17,18,19,26,27,28,29) de chacun des processeurs (10,11, 12,13,20,21,22,23) au moyen de deux tests successifs sur un même indicateur, séparés par une prise de verrou propre à chaque module. 9. Système informatique comprenant un ou plusieurs modules (1,2), chaque module (1,2) comprenant plusieurs processeurs (10,11,12,13,20,21,22, 23) rythmés par une horloge propre à ce module (1,2), chaque processeur (10,11,12,13,20,21,22,23) comprenant un registre privé TBR (16,17,18,19, 26,27,28,29) prévu pour contenir une valeur de date et pour subir une incrémentation par l'horloge propre au module (1,2) comprenant ce processeur (10,11,12,13,20,21,22,23), caractérisé en ce qu'il comprend: des moyens pour élire un processeur (10) maître du système de façon à commander à chacun des autres processeurs (11,12,13,20,21,22,23) de se mettre et de se déclarer dans un état prêt qui consiste, pour chaque processeur (11,12,13,20,21,22,23), à attendre une autorisation en provenance du processeur (10) maître du système, sans pouvoir être interrompu; - dans chaque module (1,2), un registre TBC (50,51) directement accessible aux processeurs (10,11,12,13,20,21,22,23) du module (1,2) et incrémenté par l'horloge propre au module (1,2), prévu pour contenir une valeur de date identique à celle du registre TBC (50) du module (1) o est situé le processeur maître (10) lorsque le processeur maître (10) envoie ladite autorisation.