Systèmes et applications répartis

SMB111, 6 ECTS

Chapitre 3 – Séance 4
Synchronisation
Le plus grand soin a été apporté à la réalisation de ce support pédagogique afin de vous fournir une information
complète et fiable. Cependant, le Cnam Champagne-Ardenne n'assume de responsabilités, ni pour son utilisation,
ni pour les contrefaçons de brevets ou atteintes aux droits de tierces personnes qui pourraient résulter de cette
utilisation.

Les exemples ou programmes présents dans cet ouvrage sont fournis pour illustrer les descriptions théoriques. Ils
ne sont en aucun cas destinés à une utilisation commerciale ou professionnelle.

Le Cnam ne pourra en aucun cas être tenu pour responsable des préjudices ou dommages de quelque nature que
ce soit pouvant résulter de l'utilisation de ces exemples ou programmes.

Tous les noms de produits ou autres marques cités dans ce support sont des marques déposées par leurs
propriétaires respectifs.

Ce support pédagogique a été rédigé par Cyril Rabat, enseignant vacataire au Cnam Champagne-Ardenne.

Copyright  2013-2014 - Cnam Champagne-Ardenne.

Tous droits réservés.

L'utilisation du support pédagogique est réservée aux formations du Cnam Champagne-Ardenne. Tout autre usage
suppose l'autorisation préalable écrite du Cnam Champagne-Ardenne.

Toute utilisation, diffusion ou reproduction du support, même partielle, par quelque procédé que ce soit, est
interdite sans autorisation préalable écrite du Cnam Champagne-Ardenne. Une copie par xérographie,
photographie, film, support magnétique ou autre, constitue une contrefaçon passible des peines prévues par la loi,
du 11 mars 1957 et du 3 juillet 1995, sur la protection des droits d'auteur.

Édition du 31 octobre 2013

 Les différents processus d’un système réparti sont exécutés de manière indépendante sur
différents sites distants. Il faut donc trouver des techniques permettant à ces processus de coopérer et
de se synchroniser. Cette synchronisation peut exister de différentes manières dont voici les
principales que nous aborderons dans ce chapitre :
- La synchronisation temporelle ;
- L’ordonnancement des événements ;
- L’accès aux ressources partagées (ou l’exclusion mutuelle) ;
- L’élection.

Dans ce cours, nous présentons les deux premières manières1. Dans un premier temps, nous
montrons les problématiques liées à la synchronisation temporelle entre des machines distantes (nous
présentons rapidement le protocole NTP), puis dans un deuxième temps, nous présentons le concept
d’horloge logique avec les horloges logiques de Lamport, les horloges vectorielles et matricielles.

1. Synchronisation temporelle

Dans un système distribué, il est important, dans certaines conditions, de synchroniser

temporellement un ensemble de machines. On peut citer, par exemple, le problème d’une transaction
financière réalisée sur un client, puis envoyée à un serveur. La date de valeur de cette transaction
correspond à la date d’envoi sur le client, indépendamment du temps nécessaire pour acheminer
l’ordre au serveur (la date de réception). La comparaison entre deux transactions est donc réalisée
suivant la date d’émission : si les clients ne sont pas synchronisés, la comparaison n’a aucun sens. Un
autre exemple couramment cité est celui de l’utilitaire make qui vérifie la date de compilation de
différents éléments pour exécuter des règles. Une règle correspond par exemple à la compilation de
bibliothèques, opération qui peut être assez coûteuse en termes de temps et de ressource processeur.
La date de compilation étant locale, si les machines ne sont pas synchronisées, des règles peuvent
être exécutées inutilement.

1.1. Problématique

Chaque machine possède une horloge interne qui lui permet de maintenir le temps localement.
Mais cette horloge ne possède pas la même précision quelle que soit la machine : elle est sujette à un
certain taux d’erreur lié à sa conception même. Ainsi, les horloges de deux machines différentes ne
seront pas totalement synchronisées et une différence peut être observée à un instant t donné : c’est
la notion de déviation. Une horloge est caractérisée par sa précision qui est une déviation par rapport
au temps réel (défini dans la suite).

Figure 1 : précision et déviation

À cause d’une différence de fréquence, lorsque l’on compare le temps de deux horloges, on
peut noter une divergence qui augmente dans le temps : c’est la dérive (on parle aussi de déviation
croissante). En particulier, on s’intéresse à la dérive entre l’horloge de la machine et l’horloge dite
« idéale », c’est-à-dire l’horloge permettant d’obtenir le temps réel. Le taux de dérive est la mesure de
la dérive entre deux horloges, exprimée en déviation par seconde. Les montres de bas de gamme
peuvent avoir un taux de dérive de 5,8μs/s soit une dérive de plus ou moins 15 secondes par mois.
Ces montres utilisant le quartz, les écarts varient suivant la température.

1
L’exclusion mutuelle et l’élection font l’objet du prochain cours.
Synchronisation 1 / 14
 Le temps réel est défini par une convention internationale nommée UTC (pour Coordinated
Universal Time). Ce temps est calculé à partir d’horloges atomiques par le BIPM (le BIH pour Bureau
International de l’Heure, maintenant appelé BIPM pour Bureau International des Poids et Mesures)
situé à Paris. Différentes horloges atomiques sont installées à différents endroits dans le monde : elles
se basent sur un nombre fixe de transitions de l’atome de césium 133 pour déterminer une seconde
(9192631770 transitions = 1 seconde). À partir du temps calculé par ces différentes horloges, le BIPM
détermine une valeur moyenne appelée le TAI (pour Temps Atomique International). Or, ce temps
ainsi calculé n’est pas totalement identique au jour solaire (qui n’est d’ailleurs pas constant). Pour
résoudre ce problème, le BIPM introduit des secondes sautées permettant de réduire l’écart entre le
TAI et le jour solaire (dès qu’un écart de 800ms intervient). Ce temps est appelé le Temps Universel
Coordonné, abrégé en TUC ou en UTC2.

Le but de la synchronisation temporelle est de faire en sorte que les horloges des machines du
système réparti indiquent le même temps. On distingue habituellement deux types de
synchronisation : la synchronisation externe et la synchronisation interne. Alors que la première utilise
une source externe (une horloge atomique par exemple), la seconde exploite uniquement les horloges
des machines en les comparant.

1.2. Synchronisation externe

Une première solution consiste à utiliser un serveur central qui permet de synchroniser les
machines (voir Figure 2). Chacune d’entre elles interroge régulièrement ce serveur pour obtenir la
valeur de l’horloge du serveur et mettre à jour la valeur de sa propre horloge.

Serveur de temps
t0 td tt tr t3
Machine 1

Serveur de temps
t1 t2
Machine 1 Machine 2 Machine 3
(b)
(a)

Figure 2 : serveur de temps (a) et déroulement d'une requête (b)

Comme le montre la Figure 2 (b), les machines récupèrent le temps du serveur mais les délais
de communication doivent être pris en compte. En effet, au temps t 0, la machine envoie sa requête.
Cette requête est reçue après un délai td qui correspond au temps passé depuis l’envoi du message
jusqu’à sa réception. Le serveur prend un certain temps (un temps de traitement), noté t t, avant
d’envoyer sa réponse qui met un temps tr pour arriver jusqu’à la machine. Si le temps du serveur t 2
est appliqué directement à la machine, il y aura donc un décalage de tr entre la machine et le serveur.
Comment estimer ce décalage et adapter l’horloge de la machine ?

Du point de vue de la machine, la première hypothèse est que le temps d’envoi et de réception
sont sensiblement équivalents (td ≈ tr). Donc, si l’on prend le temps t0 correspondant à l’envoi de la
requête et le temps t3 correspondant à la réception de la réponse, on sait que l’intervalle de temps
entre t3 et t0 correspond à deux fois le temps de transfert, autrement dit t3 - t0 = td + tr. Donc, la
machine doit mettre à jour la valeur de son horloge par le temps t2 envoyé par le serveur auquel on
ajoute ce temps de transfert estimé. Cette nouvelle valeur est donc : t2 + (t3 – t0) / 2.

Par contre, ceci ne prend pas en compte le temps de traitement t t. Or, ce temps ne peut pas
être estimé du côté de la machine. Il dépend du temps de réaction du serveur, c’est-à-dire de sa
charge au moment de la réception de la requête. C’est donc le serveur qui doit envoyer une

2
L’abréviation UTC est l’accord trouvé entre l’abréviation anglaise CUT et l’abréviation française TUC.
SMB111 2 / 14
information supplémentaire au client pour l’aider à ajuster au mieux la valeur de son horloge. Lorsque
le serveur reçoit la requête, il mémorise le temps de réception t1 et l’envoie à la machine en plus du
temps t2 (ou il envoie tout simplement l’intervalle de temps entre t 1 et t2). À la réception, la machine a
juste à ajouter cette différence au temps calculé précédemment.

1.3. Synchronisation interne

L’un des exemples de synchronisation interne est l’algorithme de Berkeley. L’idée est toujours
de synchroniser les machines entre elles, mais sans exploiter de serveur de temps, autrement dit
aucune machine ne connaît le temps réel. L’objectif de l’algorithme est qu’entre tout couple de
machines, l’écart entre les horloges soit inférieur à une borne donnée.

Il est basé sur la notion de coordinateur. Celui-ci demande à l’ensemble des participants, la
valeur de leur horloge. Tout comme le précédent algorithme, il est nécessaire d’estimer le temps aller-
retour pour obtenir les valeurs « exactes ». À partir de tous ces temps ajustés, le coordinateur calcule
un temps moyen qui est ensuite diffusé à tous les participants. Reste ensuite aux participants de
s’ajuster à ce temps. Lorsqu’un participant est en avance, il ne recule pas son horloge (pour des
raisons évidentes) : il la ralentit jusqu’à rattraper cette avance.

La principale difficulté de l’algorithme réside dans le calcul de la moyenne : il ne faut pas que
des machines dont l’horloge est corrompue (ou de mauvaise qualité) ne viennent constamment
modifier le temps. Aussi, les valeurs extrêmes sont ignorées.

1.4. Network Time Protocol

Basé sur ce principe, le protocole NTP (pour Network Time Protocol) a été proposé pour
synchroniser des machines mises en réseau. Il a été conçu afin de fournir une précision inférieure à la
seconde : une dizaine de millisecondes dans un WAN. Il est basé sur le temps UTC avec une différence
de quelques secondes intercalaires.

horloges
atomiques

Serveur de temps
strate 1

Serveur local
strate 2

Internet
strate 3

(b)

(a)
Figure 3 : architecture générale de NTP (a) et architecture conseillée pour un LAN (b)

L’architecture de NTP est sous forme arborescence comme le montre la Figure 3 (a). Les
serveurs dits de strate 1, ou serveurs primaires, sont directement reliés à des références de temps

Synchronisation 3 / 14
comme les horloges atomiques ou une machine particulière dédiée. Ces serveurs peuvent ensuite être
contactés par d’autres serveurs de temps, via le protocole NTP. Les serveurs du dessous de strate
supérieure à 2 sont appelés des serveurs secondaires : ils sont capables de contacter un serveur
primaire pour se synchroniser ou utiliser un autre serveur secondaire. Lorsqu’un client se connecte à
un serveur NTP, il contacte un serveur de strate la plus haute possible, afin d’obtenir la meilleure
précision. Il existe aujourd’hui un grand nombre de serveurs accessibles depuis Internet (plusieurs
milliers). Dans chaque pays, il existe au moins un serveur primaire.

NTP utilise les protocoles IP et UDP. Les communications entre les serveurs et les clients
peuvent être en point-à-point, mais aussi en diffusion ou en multicast. Le choix d’UDP permet d’éviter
l’établissement d’une connexion, coûteuse en termes de ressources et de temps.

Pour améliorer la sécurité, il est conseillé d’empêcher les clients de contacter directement un
serveur NTP extérieur (voir Figure 3 (b)). Un serveur local est alors installé qui sera synchronisé avec
un serveur de temps extérieur dit sûr. Le protocole NTP inclut aussi l’authentification et le contrôle
d’accès : seuls les paquets NTP authentifiés seront alors autorisés. Une liste de machines autorisées
est aussi possible à mettre en place.

Pour des raisons de redondance, plusieurs sources doivent être spécifiées. Dans ce cas, le client
NTP peut déterminer la meilleure source de synchronisation. Des algorithmes de filtrage, de sélection
et de combinaison ont été proposés en plus du protocole.

Lorsque deux hôtes NTP communiquent ensemble, appelés des pairs, il existe plusieurs types
d’association :
- Serveur : l’hôte se contente de répondre aux requêtes des pairs et ne peut être synchronisé
lui-même par ces pairs ;
- Mode symétrique actif : l’hôte NTP envoie des messages périodiques pour synchroniser ou
se synchroniser sur ses pairs ;
- Mode symétrique passif : idem, mais dans ce cas, c’est à l’initiative des autres hôtes ;
- Mode diffusion : les informations sont diffusées dans le réseau local ;
- Mode client : le client envoie des requêtes de synchronisation à son pair.

2. Horloges logiques

Le temps réel ou absolu n’est pas toujours nécessaire dans un système distribué et notamment
lorsqu’il s’agit d’ordonnancer des événements (exécutions de processus, communications entre
processus). En effet, ce qui est important dans ce cas, c’est l’ordre dans lequel les événements sont
exécutés par rapport aux autres.

2.1. Diagramme espace-temps et ordre causal

Pour représenter les différents événements (exécution ou émission/réception de messages)

dans le système réparti, nous utilisons un diagramme espace-temps. L’axe des abscisses du
diagramme représente le temps et l’axe des ordonnés les processus. Les différents événements
possibles sont soit un calcul interne (représenté par un point), soit l’envoi/la réception d’un message
(représenté par une flèche, le sens indiquant le sens du message). La Figure 4 montre un exemple de
diagramme espace-temps. À noter que le temps de propagation des messages est quelconque, ce qui
explique la longueur plus ou moins grande des flèches.

Pour décrire un événement interne (comme un calcul), nous utilisons la notation I(j) avec j
l’identité du processus. Pour l’envoi d’un message, nous utilisons la notation E(j, k) avec j l’identité du
processus émetteur et k l’identité du processus récepteur. La réception est notée R(j, k) avec j
l’identité du processus récepteur et k l’identité du processus émetteur. L’émetteur et le récepteur du
message sont intervertis dans les deux dernières notations.

SMB111 4 / 14
Exemple. Supposons un système comportant 4 sites. Nous considérons les événements suivants :
e0 = I(1) ; e1 = I(4) ; e2 = E(3, 1) ; e3 = R(1, 3) ; e4 = E(4, 2) ; e5 = E(3, 1) ;
e6 = E(2, 4) ; e7 = R(2, 4) ; e8 = R(1, 3) ; e9 = R(4, 2) ; e10 = I(3)

La Figure 4 montre le diagramme espace-temps correspondant à ces événements :

P1
P2
P3
P4

e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 e10
Figure 4 : exemple de diagramme espace-temps

Le diagramme espace-temps permet d’observer l’ordre d’exécution des événements dans les
différents processus. Il permet aussi d’observer les chaînes causales. Suivant l’ordre d’exécution des
événements (interne ou envoi/réception d’un message), l’état d’un site peut être différent d’une
exécution à une autre. Si l’on considère donc l’état global du système, celui-ci dépend de l’ordre de ces
exécutions. Si un événement e est dépendant d’un événement e’, on note e  e’.

Une chaîne causale correspond à une liste d’événements dépendants. Tant qu’un site exécute
un code sans communication, cette action n’est liée à aucun événement. Par contre, si ce calcul
intervient après la réception d’un message, il devient donc dépendant de cette réception. Ces deux
événements forment alors une chaîne causale. En modifiant l’ordre de ces événements, l’état local du
site est possiblement modifié.

Exemple. Depuis le diagramme représenté sur la Figure 4, il est possible d’extraire plusieurs chaînes
causales : par exemple, les chaînes (e2, e3, e8) et (e1, e4, e7). En effet, il n’est pas possible
d’échanger l’ordre de ces événements. Pour la première chaîne, les événements e2 et e3
correspondent à l’envoi et la réception du message : c’est donc évident qu’il n’est pas possible
d’échanger leur ordre d’exécution. Pour l’événement e8, il intervient après la réception d’un message,
soit l’événement e3. L’état du processus peut être différent si l’événement e8 est exécuté avant
l’événement e3.

L’état global du système est-il modifié si l’ordre des événements est changé ? Comme la
synchronisation absolue n’est pas possible dans un système réparti, rien ne dit que les événements
soient exactement exécutés dans un ordre précis. Cependant, à condition de respecter l’ordre causal
des événements, il est tout à fait possible de modifier l’ordre des événements sans modifier l’état
global final du système. On parle alors d’exécution équivalente.

Exemple. Si nous reprenons les événements de l’exemple précédent :

e0 = I(1) ; e1 = I(4) ; e2 = E(3, 1) ; e3 = R(1, 3) ; e4 = E(4, 2) ; e5 = E(3, 1) ;
e6 = E(2, 4) ; e7 = R(2, 4) ; e8 = R(1, 3) ; e9 = R(4, 2) ; e10 = I(3)

Les Figure 5 (a) et (b) montrent des exécutions équivalentes.

Synchronisation 5 / 14
 P1 P1
P2 P2
P3 P3
P4 P4

e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 e10 e1 e2 e0 e3 e5 e4 e6 e9 e7 e10 e8
(a) (b)

Figure 5 : exécution des événements (a) et exécution équivalente (b)

2.2. Les horloges logiques de Lamport

Leslie Lamport dans son article de référence de 1978 (référence [3]), décrit le fonctionnement
de ses horloges logiques, appelées depuis horloges logiques de Lamport. Elles sont basées sur des
estampilles : chaque événement est associé à une valeur temporelle (l’estampille). Pour cela, chaque
processus possède un compteur local. Ce compteur est incrémenté de 1 avant que le processus
n’exécute une action (événement interne ou envoi d’un message). Lorsqu’un processus envoie un
message, il le marque avec la valeur de son compteur. Enfin, lorsqu’un processus reçoit un message, il
peut mettre à jour son compteur local : il prend la valeur de son propre compteur, la compare à
l’estampille du message et prend le maximum des deux. Il affecte ce maximum à son compteur et
l’incrémente ensuite de 1.

L’algorithme est donc le suivant :

- Chaque processus i possède une horloge locale notée Ci initialisée à 0 ;
- À chaque événement (interne ou envoi de message), Ci est incrémenté de 1 ;
- Lorsqu’un message est envoyé, il est estampillé par Cm = Ci ;
- Lors de la réception d’un message, le site destinataire met à jour son horloge locale comme
suit : Ci = max(Cm, Ci) + 1.

Exemple. Si nous reprenons les événements de l’exemple précédent :

e0 = I(1) ; e1 = I(4) ; e2 = E(3, 1) ; e3 = R(1, 3) ; e4 = E(4, 2) ; e5 = E(3, 1) ;
e6 = E(2, 4) ; e7 = R(2, 4) ; e8 = R(1, 3) ; e9 = R(4, 2) ; e10 = I(3)

Les valeurs des horloges logiques de Lamport sont représentées sur la Figure 6. L’événement
e0 est estampillé par 1 : la valeur de l’horloge de P1 est initialisée à 0, à laquelle on ajoute 1.
L’événement e4 correspond à un envoi de message. Le processus P4 estampille le message par 2.
Lorsque le processus P2 reçoit le message, la valeur de son horloge est à 1 : le maximum entre les
deux est 2. Il y ajoute donc 1, ce qui fait que l’événement e7 est estampillé avec 3.

0 1 2 3
P1
0 1 3
P2 3
0 1 2
P3 1
0 2 3
P4

e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 e10
Figure 6 : les valeurs des horloges logiques de Lamport (en rouge)

SMB111 6 / 14
 Grâce aux valeurs des horloges associées à chaque événement, il est maintenant possible de
dire que :
- Tous les événements sur un processus possèdent des estampilles différentes ;
- Plusieurs événements peuvent posséder la même estampille : e0, e1 e2 et e6 ;
- Les estampilles sur une chaîne causale ont des valeurs croissantes : les estampilles de la
chaîne causale (e2, e3, e8) sont (1, 2, 3) et celles de la chaîne (e1, e4, e7) sont (1, 2, 3) ;

Si l’on note H(i) l’estampille d’un événement i, on remarque que si deux événements i et j ont
un ordre causal (i  j), alors H(i) < H(j). Par contre, la réciproque est fausse : si H(i) < H(j), alors soit
e  e’, soit les deux événements sont indépendants (on note e || e’).

2.3. Ordre total

À partir des valeurs des horloges de Lamport, il est tout de même possible de définir un ordre
total sur les événements. Pour cela, on associe à chaque événement un couple (h, i) où h est la valeur
de l’horloge et i est l’identité du processus. De par les propriétés des horloges de Lamport, il est
possible d’ordonner tous ces couples puisqu’aucun d’entre eux n’est identique. Pour comparer deux
couples, on utilise la relation suivante :

(h, i) < (h’, i’)  (h < h’)  (h = h’  i < i’)

Autrement dit, on compare en premier lieu les valeurs des horloges des couples et si cette
valeur n’est pas suffisante pour les comparer, on utilise les identités des processus. Une fois que
l’ensemble des couples est ordonné, on donne la valeur 1 au premier couple, la valeur 2 au deuxième,
et ainsi de suite.

Exemple. Si on reprend les événements du diagramme espace-temps de la Figure 6, nous leur

associons leur couple et nous obtenons le diagramme de la Figure 7 (a).

(1,1) (2,1) (3,1)

P1 P1
(1,2) (3,2)
P2 (3,3) P2
(1,3) (2,3)
P3 (1,4) P3
(2,4) (3,4)
P4 P4

e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 e10 e0 e6 e2 e1 e3 e5 e4 e8 e7 e10 e9
(a) (b)
Figure 7 : couples horloges de Lamport et identité (a) et ré-ordonnancement des événements (b)

Les couples peuvent être ordonnés comme suit :

(1, 1), (1, 2), (1, 3), (1, 4), (2, 1), (2, 3), (2, 4), (3, 1), (3, 2), (3, 3), (3, 4)

En réordonnant les événements, nous obtenons l’exécution équivalente représentée sur la

Figure 7 (b).

Cet ordre total est arbitraire. En effet, s’il existe une dépendance causale entre deux
événements, l’ordre total la respecte. Cependant, en l’absence de dépendance causale, deux
événements sont tout de même ordonnés car une préférence est réalisée de par la valeur de l’horloge
et de par l’identité du processus. Ceci n’est pas réellement un problème, les deux événements sont
indépendants.

2.4. Les horloges vectorielles

Le principal inconvénient des horloges de Lamport est qu’elles ne respectent pas la réciproque :
uniquement à partir des estampilles, il n’est pas possible de savoir si deux événements sont
dépendants ou non. Il est donc nécessaire d’ajouter un mécanisme supplémentaire qui a été proposé
Synchronisation 7 / 14
par Fidge et Mattern en 1988 (références [4] et [5]). Les horloges vectorielles sont basées sur les
horloges de Lamport, à ceci près qu’on utilise un vecteur d’horloges : chaque processus maintient
localement un vecteur qui comporte n coordonnées pour les n processus. La coordonnée i du vecteur
correspond à l’horloge du processus i3. Les vecteurs sont échangés lors des envois de messages, ce
qui permet de maintenir la connaissance des horloges des autres processus.

Initialement, le vecteur comprend n fois la valeur 0. Lorsqu’un événement interne a lieu sur le
processus i ou si le processus i envoie un message, la coordonnée i du vecteur est augmentée de 1.
Lors de l’envoi du message, le vecteur est envoyé. À la réception d’un message, un processus met à
jour son vecteur en prenant le maximum des coordonnées entre son vecteur et le vecteur reçu. Il
augmente ensuite de 1 la coordonnée correspondant à sa propre horloge.

Exemple. Nous reprenons les mêmes événements que la Figure 6. Nous obtenons les horloges
vectorielles représentées sur la Figure 8.

1 2 3
0 0 0
P1 0 0
0 1 2
1 2
P2 0 0 0 0 0 0
0 0
0 0 0 0
P3 0 0 0 2
1 2 1 3
0 0
P4 0 0 0 0
0 0
3
1 2
e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 e10
Figure 8 : horloges vectorielles

Contrairement aux horloges de Lamport, les horloges vectorielles ne permettent pas de créer
un ordre total. Par exemple, les deux vecteurs (0, 1, 0) et (0, 0, 1) possèdent 2 coordonnées
différentes. Pour le premier vecteur, la deuxième coordonnée est supérieure à la deuxième coordonnée
de l’autre vecteur, alors que sa troisième coordonnée est inférieure à la troisième de l’autre vecteur. Il
n’est donc pas possible d’ordonner ces deux événements.

Cependant, les horloges vectorielles possèdent une propriété très intéressante : un événement
e est antérieur à un autre événement e’, si toutes ses coordonnées sont inférieures ou égales aux
coordonnées correspondantes. Par exemple sur la Figure 8, nous avons e1 = (0, 0, 0, 1) et e7 = (0, 2,
0, 2). En comparant chaque coordonnée, on s’aperçoit que celles de e1 sont bien toutes inférieures à
e7 : e1 est bien antérieur à e7. Par contre, pour les événements e5 = (0, 0, 2, 0) et e9 = (0, 1, 0, 3),
il est impossible de décider l’antériorité. Ces événements ne sont pas comparables : ils sont
concurrents ou indépendants causalement. Ils ne font pas partie d’une même chaîne causale. En effet,
tout événement exécuté le long d’une chaîne causale a une horloge inférieure à toutes les horloges des
événements suivants de la chaîne. Par exemple, nous avons la chaîne causale e1 = (0, 0, 0, 1), e4 =
(0, 0, 0, 2) et e7 = (0, 2, 0, 2).

D’une manière générale, nous avons les comparaisons suivantes :

- V ≤ V’ si quel que soit i, V[i] ≤ V’[i]
- V < V’ si V ≤ V’ et qu’il existe i tel que V[i] < V’[i]
- V || V’ si  (V ≤ V’)   (V < V’)

Si les horloges vectorielles permettent de comparer des événements et éventuellement les

réordonner, il n’est pas possible de garantir un ordre dans la réception des messages comme le
montre les deux diagrammes de la Figure 9. Sur les diagrammes (a) et (b), nous avons inversé les
événements e4 et e5 qui correspondent à la réception de deux messages estampillés par (0, 1, 0) et
(2, 2, 0). Si l’on compare ses deux messages, il faut d’abord traiter celui estampillé par (0, 1, 0) puis
celui par (2, 2, 0) : c’est le cas sur le diagramme (a). Sur le diagramme (b), la réception du premier
message a été retardée. Après coup, il est possible de le savoir pour le processus P3 à partir des

3
Plus exactement à la connaissance que le processus possède de l’horloge du processus i.
SMB111 8 / 14
horloges reçues. À noter que les états des horloges sur P3 sont les mêmes après les 2 exécutions.

1 2 1 2
0 2 2 0 2 2
0 2 0 0 0 2 0 0
P1 0
2
P1 2
2
1 0 1 0
1 2
P2 0 2 P2 0 2
1 1
2 2
P3 P3

e0 e1 e2 e3 e4 e5 e0 e1 e2 e3 e4 e5
(a) (b)

Figure 9 : cas d'une réception différée

2.5. Les horloges matricielles

Les horloges matricielles ont pour but de corriger l’inconvénient majeur des horloges
vectorielles : être capables de réordonner les messages. Pour cela, les estampilles sont maintenant
des matrices de n x n, avec n le nombre de processus. Sur un processus i, la i-ème ligne de la matrice
correspond aux informations du processus i. Ainsi, dans la case (i, i), nous avons le nombre
d’événements réalisés par i et dans les autres cases (i, j) de la ligne i, c’est le nombre de messages
envoyés par i vers le processus j. Les autres lignes de la matrice correspondent à la connaissance que
le processus possède sur les autres sites (nombre d’événements, messages échangés). La Figure 10
montre un exemple d’horloge vectorielle.

Figure 10 : horloge matricielle

L’algorithme de mise-à-jour des horloges matricielles est le suivant :

- Lorsqu’un événement local sur le processus i se produit, on incrémente M[i, i] ;
- Lorsque le processus i envoie un message au processus j, on incrémente à la fois M[i, i] et
M[i, j] ;
- Lorsqu’un message est reçu sur le processus i et qu’il respecte la causalité (nous
expliquerons dans la suite comment le vérifier), on incrémente à la fois M[i, i] et M[j, i] et
on met à jour toutes les coordonnées de la matrice (on note ici Mm l’estampille du
message) :
 k ≠ i, et  l ≠ i, M[k, l] = max(M[k, l], Mm[k, l])

Exemple. Nous supposons 3 processus numérotés de 1 à 3. La Figure 11 (a) montre l’état de l’horloge
du processus 1. Celui-ci réalise tout d’abord un événement interne. La case (1, 1) est incrémentée
comme le montre la Figure 11 (b). Puis le processus envoie un message au processus 2. La case (1, 1)
est incrémentée, puis la case (1, 2) correspondant au nombre de messages envoyés par le processus
1 pour le processus 2. Le message est donc estampillé par l’horloge représentée sur la Figure 11 (c).

0 0 0 1 0 0 2 1 0
0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0
(a) (b) (c)
Figure 11 : événement interne et envoi de message avec les horloges vectorielles
Synchronisation 9 / 14
 Le processus 2 reçoit le message ainsi estampillé. L’état de l’horloge de ce processus est
représenté sur la Figure 12 (a). Nous supposons que le message respecte l’ordre causal et il est donc
traité immédiatement par le processus 2. Celui-ci met à jour son horloge comme le montre la Figure
12 (b).

0 0 0 2 1 0
0 0 0 0 1 0
0 0 0 0 0 0
(a) (b)
Figure 12 : réception d'un message avec les horloges vectorielles

Lorsqu’un message estampillé M’ est envoyé par un processus j et est reçu sur un processus i, il
faut vérifier qu’il respecte la causalité. Pour rappel, la case M[j, i] correspond au nombre de messages
envoyés par j vers i. Si c’est bien le message suivant de j pour i, il doit y avoir une différence de 1
entre M[j, i] et M’[j, i]. Autrement dit : M’[j, i] = M[j, i] + 1.
Ensuite, il faut s’assurer que le processus i a bien reçu tous les autres messages qui sont
causalement antérieurs au message courant. On vérifie donc toutes les cases de la colonne i (qui
comprend le nombre de messages destinés à i et envoyés par les autres processus), exceptées les
cases des lignes i et j (la case M[i, i] correspond au nombre d’événements exécutés sur i donc j ne
peut avoir une meilleure vision que i lui-même, et la case M[j, i] a été vérifiée juste avant).

Exemple. Nous allons montrer dans cet exemple, le cas d’un message reçu qui ne respecte pas la
causalité. Nous partons sur 3 processus et le diagramme espace-temps avec les horloges vectorielles
est représenté sur la Figure 13. La réception du premier message envoyé par le processus P1 est
décalée dans le temps (à cause de la congestion du réseau, par exemple).

101 211
000 000
000 000
P1
211
021
000
P2
211 211
010 021
000 002
P3
101
000
001
e0 e1 e2 e3 e4 e5 e6
Figure 13 : cas d'un message ne respectant pas la causalité

Comme nous pouvons le voir, le premier message reçu par le processus P3 (événement e4) est
détecté comme ne respectant pas la causalité. En effet, le processus P3 n’a pas encore reçu de
message : sur toutes les lignes, les valeurs de la colonne 3 sont égales à 0. Or, le message est
estampillé par une matrice dont la troisième colonne contient deux fois la valeur 1 : il y a donc un
message qui avait été envoyé au processus P3 avant ce message. Le message n’est donc pas délivré
immédiatement, jusqu’à ce que le message provenant du processus 1 soit reçu (événement e5).

Pour résumer le calcul des horloges matricielles, voici un exemple complet.

SMB111 10 / 14
Exemple. Nous reprenons toujours les mêmes événements représentés sur la Figure 6 et nous
calculons les horloges matricielles. Nous obtenons le diagramme espace-temps représenté sur la
Figure 14.

1 0 0 0 2 0 0 0 3 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 1 0 1 0 2 0 2 0
0 0 0 0 0 0 0 0 0 0 0 0
P1
0 0 0 0 0 0 0 0
0 1 0 1 0 2 0 1
0 0 0 0 0 0 0 0
0 0 0 0 0 1 0 2
P2
0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0
1 0 1 0 2 0 2 0 2 0 3 0
0 0 0 0 0 0 0 0 0 0 0 0
P3
0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 1 0 1
0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 1 0 1 0 2 0 1 0 3
P4

e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 e10

Figure 14 : horloges matricielles

En prenant les diagonales de chaque matrice, nous pouvons observer qu’elles correspondent
aux valeurs des horloges vectorielles calculées sur la Figure 8 : en effet, les diagonales permettent de
compter le nombre d’événements traités en chaque site, ce qui correspond au but des horloges
vectorielles.

3. Conclusion

Dans ce cours, nous avons vu deux types de synchronisation : la synchronisation du temps

entre les machines et la synchronisation logique des événements.

La problématique de la synchronisation temporelle est de s’assurer que le temps est identique

sur chaque machine et si possible, qu’il soit égal au temps réel : le temps UTC. Ce temps étant obtenu
sur des horloges atomiques, il faut que ce temps soit accessible depuis des serveurs possédant des
connexions spéciales pour obtenir ce temps. Ensuite, les clients qui interrogent ces serveurs doivent
prendre en compte les délais de communication qui peuvent être variables. Nous avons vu une
description rapide du protocole NTP qui permet de synchroniser des machines en réseau.

La synchronisation des machines sur le temps réel n’est pas tout le temps nécessaire : l’ordre
dans lequel les événements sont réalisés est parfois suffisant (la causalité des événements). Nous
avons vu tout d’abord les horloges de Lamport qui permettent d’estampiller les événements à partir de
temps locaux. Puis nous avons expliqué les horloges vectorielles qui vont plus loin en permettant
d’obtenir une vision partielle de l’état des voisins ; elles permettent de caractériser la dépendance
causale. Enfin, les horloges matricielles permettent en plus de vérifier la causalité des messages reçus
et éventuellement de reporter leur traitement si cette causalité n’est pas vérifiée.

4. Références/bibliographie

[1] http://www.bipm.org/ : le site officiel du BIPM (Bureau International des Poids et Mesures) ; il
indique le temps UTC et le délai de transmission estimé avec votre machine.

[2] http://www.ntp.org/ : le site officiel du projet NTP (Network Time Protocol) ; il comporte toutes les
documentations sur l’implémentation du protocole NTP (en anglais).

Synchronisation 11 / 14
[3] Leslie Lamport, Time, Clocks, and the Ordering of Events in a Distributed System, Communications
of the ACM, vol. 21, no 7, 1978 (l’article original sur les horloges logiques de Lamport) (en anglais).

[4] Colin J. Fidge, Timestamps in Message-Passing Systems that Preserve the Partial Ordering,
Proceedings of the 11th Australian Computer Science Conference, 1988 (horloges vectorielles) (en
anglais).

[5] Friedemann Mattern, Virtual Time and Global States of Distributed Systems, Proceedings of the
Workshop on Parallel and Distributed Algorithms, 1989 (horloges vectorielles) (en anglais).

[6] Andrew Tanenbaum et Maarten Van Steen, Distributed Systems : Principles and paradigms 2th
Edition, Pearson, 2007 (en anglais).

SMB111 12 / 14
5. Exercices

5.1. QCM

1. Le temps réel de référence est noté UTC :

 Vrai  Faux
2. La déviation est le nombre de secondes de décalage que prend une horloge par rapport au
temps réel :
 Vrai  Faux
3. La notion de couche des serveurs de temps dans le protocole NTP est synonyme de précision :
 Vrai  Faux
4. L’événement e2 estampillé par la valeur 5 est causalement dépendant de l’événement e1
estampillé par la valeur 2 :
 Vrai  Faux
5. Les événements estampillés par (2, 3, 2) et (3, 2, 2) sont causalement indépendants :
 Vrai  Faux

5.2. Questions

1. Soit l’horloge matricielle locale d’un processus suivante :

2 1 0
0 3 1
1 1 4

a. Combien de messages ont été échangés dans le système ?

b. Combien d’événements internes ont eu lieu sur chaque processus ?
c. Est-il possible de déterminer quelle aurait été l’horloge vectorielle sur ce site ?
d. Sachant que cette horloge correspond à l’estampille d’un message à destination du
processus 2, ce message respecte-t-il l’ordre causal si la matrice du processus 2 est la
suivante ?
1 1 0
0 2 1
0 0 0

5.3. Exercices

Soit les événements suivants :

e1 = E(1, 2) ; e2 = R(2, 1) ; e3 = E(3, 2) ; e4 = I(4) ; e5 = R(2, 3) ; e6 = E(2, 4) ; e7 = E(4, 1) ;

e8 = R(4, 2) ; e9 = E(4, 3) ; e10 = R(3, 4) ; e11 = E(3, 1) ; e12 = R(1, 3) ; e13 = R(1, 4)

1. Donnez le diagramme espace-temps correspondant à cette exécution.

2. Donnez plusieurs chaines causales.
3. Complétez ce diagramme et calculez les valeurs des horloges logiques de Lamport.
4. Donnez l’ordre total de tous les événements puis donnez le diagramme espace-temps
correspondant.

Synchronisation 13 / 14
 5. À partir du diagramme espace-temps donné à la question 1, calculez les valeurs des horloges
vectorielles.
6. À partir du diagramme espace-temps donné à la question 1, calculez les valeurs des horloges
matricielles.

SMB111 14 / 14