Systèmes Répartis. Chapitre IV - Coordination. Amine DHRAIEF Année Master Pro Data Science. 1ère

Systèmes Répartis
Chapitre IV :
Coordination
Amine DHRAIEF
1ère année Master Pro Data Science
Contexte : Le temps
●
Depuis 1967, la seconde n’est plus définit par rapport à
l’année (1/86400ème partie du jour solaire moyen) mais
par rapport à une propriété de la matière
– « La seconde est la durée de 9 192 631 770 périodes de la
radiation correspondant à la transition entre les deux niveaux
hyperfins de l’état fondamental de l’atome de césium 133 »
●
Les horloges ne sont pas forcément synchronisées.
– Peut poser de grave problèmes pour la localisation GPS par
exemple
30/11/2018 Systèmes Répartis 2

Contexte : Le temps
exemple : trilatération GPS
● Nom / tdépart
●
Localisation
d= Distance(satellite → homme) ?
d=vitesse * temps de parcours =
c * (tarrviée - tdépart) =

Terre
Contexte : Le temps

Contexte : Le temps

Contexte : Le temps

Contexte : Le temps

Contexte : Le temps
30/11/2018 Terre
Systèmes Répartis 8
Contexte : Le temps
30/11/2018 Terre
Contexte : Le temps
Localisation OK !
30/11/2018 Terre
Contexte : Le temps
La navigation aérienne utilise largement le GPS

Contexte : Le temps
●
Erreur de synchronisation
entre l’horloge du satellite
et l’horloge du
récepteur peut avoir un
impact désastreux sur la
navigation mondiale
– Un décalage d’une
milliseconde (0,001 s),
1er juillet 2002 Collision d'Überlingen
une erreur de 300 km se
ressentira au niveau de la
position.

Et dans Internet … ????
Qui est le premier ?

Client#1 10:10
Client#2 10:15
Serveur
Client #1 Client #2

Problématique ?
●
Le temps est très important dans les
systèmes répartis. On veut savoir avec
précision quand un évènement est arrivé.
●
Il n’y a pas d’horloge globale pour mesurer
le temps à travers les systèmes répartis,
étant donné le délai pour envoyer par
réseau une lecture de temps.

Problématique ?
●
Algorithmes de synchronisation servent à
– maintenir la cohérence des données réparties,
– éliminer les mises à jour redondantes,
– vérifier l’authenticité des requêtes envoyées au
serveur,
– coordonner certaines opérations,
– tracer l'exécution du système..

Objectifs
●
Dans ce cours, nous nous concentrons sur la
façon dont les processus peuvent synchroniser et
coordonner leurs actions.
– Par exemple, il est important que plusieurs processus
n'accèdent pas simultanément à une ressource
partagée, telle qu'un fichier, mais coopèrent pour
s'accorder mutuellement un accès exclusif.
– Un autre exemple : plusieurs processus peuvent
parfois devoir s'accorder sur l'ordre des événements,
par exemple si le message m1 du processus P a été
envoyé avant ou après le message m2 du processus Q.

La synchronisation et la coordination
●
La synchronisation et la coordination sont deux phénomènes
étroitement liés.
– Lors de la synchronisation de processus, nous nous assurons qu’un
processus en attend un autre pour terminer son opération.
– En ce qui concerne la synchronisation des données, le problème
consiste à s'assurer que deux ensembles de données sont identiques.
●
En matière de coordination, l’objectif est de gérer les
interactions et les dépendances entre les activités d’un
système distribué.
– De ce point de vue, on pourrait affirmer que la coordination englobe la
synchronisation.

La synchronisation de l’horloge

●
Dans un système centralisé, le temps n’est pas
ambiguë
– Lorsqu'un processus veut connaître l'heure, il appelle
simplement le système d'exploitation.
– Si le processus A demande l'heure, puis un peu plus
tard, B demande l'heure, la valeur obtenue par B sera
supérieure (ou éventuellement égale à) à la valeur A.
– Ce ne sera certainement pas inférieur.
– Dans un système distribué, parvenir à un accord dans
les délais est une tâche difficile à réaliser.

●
Imaginons un instant les conséquences de l’absence d’une horloge
globale sur le programme Unix, par exemple.
●
Normalement, sous Unix, les programmes volumineux sont divisés en
plusieurs fichiers source, de sorte qu'une modification apportée à un
fichier source ne nécessite la recompilation d'un seul fichier, pas tous
les fichiers.
●
Si un programme contient 100 fichiers, on n’a pas à tout recompiler car
un fichier a été modifié
→ cela augmente considérablement la vitesse à laquelle les
programmeurs peuvent travaille

●
Lorsque le programmeur a fini de modifier tous les fichiers source, il
exécute make, qui examine l'heure à laquelle tous les fichiers source et
objet ont été modifiés.
●
Si le fichier source input.c a été modifié à l'heure 21 :51 et que le
fichier objet correspondant input.o a été modifié à l'heure 21 :50, make
sait que input.c a été modifié depuis la création de input.o et que
input.c doit donc être recompilé.
●
D'autre part, si output.c a été modifié à l'heure 21:44 et que output.o a
été modifié à l'heure 21 :45, aucune compilation n'est nécessaire.
● Ainsi, make parcourt tous les fichiers source pour déterminer ceux qui
doivent être recompilés et appelle le compilateur pour les recompiler.
●
Maintenant, imaginez ce qui pourrait arriver dans un système
distribué dans lequel il n’y a pas un consensus/accord sur un
temps global.
●
Supposons que output.o ait l'heure 21 :44 et que peu après,
output.c soit modifié mais que l'heure 21 :43 lui soit affectée,
car l'horloge de sa machine est légèrement en retard.
● make n'appelle pas le compilateur.

– Le programme binaire exécutable résultant contiendra alors un
mélange de fichiers objets des anciennes sources et des nouvelles
sources.
– Cela plantera probablement et le programmeur deviendra fou en
essayant de comprendre ce
30/11/2018
qui ne va pas avec le code.
1- output.o ait l'heure 21 :44

2- peu après, output.c soit modifié mais que
l'heure 21 :43 lui soit affectée, car l'horloge
de sa machine est légèrement en retard.

Est-il possible de synchroniser toutes les
horloges dans un système distribué?
La réponse est très compliqué.

Horloge physique
●
Presque tous les ordinateurs ont un circuit permettant de garder une
trace du temps. Malgré l'utilisation répandue du mot «horloge» pour
désigner ces dispositifs, ils ne sont pas réellement des horloges au
sens habituel.
– Un Timer/Une minuterie est peut-être un meilleur mot.
– Une minuterie d'ordinateur est généralement un cristal de quartz usiné avec
précision.
– Lorsqu'ils sont maintenus sous tension, les cristaux de quartz oscillent à une
fréquence bien définie qui dépend du type de cristal, de la manière dont il est
coupé et de l'intensité de la tension.
– Deux registres sont associés à chaque cristal, un compteur et une mémoire
– Chaque oscillation du cristal décrémente le compteur d'une unité.
– Lorsque le compteur atteint zéro, une interruption est générée et le compteur
est rechargé à partir du registre mémoire.
– De cette manière, il est possible de programmer une minuterie pour générer
une interruption 60 fois par seconde ou à toute autre fréquence souhaitée.
– Chaque interruption est appelée un tic d'horloge.

Horloge physique
●
Lorsque le système est démarré, il demande
généralement à l'utilisateur de saisir la date et
l'heure, qui sont ensuite converties en nombre de
tics après une date de début connue et stockées
en mémoire.
– La plupart des ordinateurs ont une mémoire RAM
CMOS spéciale sauvegardée sur batterie, de sorte que
la date et l'heure ne doivent pas être entrées lors des
démarrages suivants.
– À chaque heure d'horloge, la procédure de service
d'interruption ajoute un à l'heure enregistrée dans la
mémoire.
– De cette façon, l'horloge (logicielle) est tenue à jour.
Horloge physique
●
Avec un seul ordinateur et une seule horloge,
peu importe si cette horloge est légèrement
décalée.
– Étant donné que tous les processus de la machine
utilisent la même horloge, ils resteront cohérents
en interne.
– Par exemple, si le fichier input.c a l'heure 2151 et le
fichier input.o l'heure 2150, make recompilera le fichier
source, même si l'horloge est décalée de 2s et que les
heures vraies sont 2153 et 2152, respectivement.
– Tout ce qui compte vraiment, ce sont les temps
relatifs.
Horloge physique
●
Dès que plusieurs processeurs sont
introduits, chacun avec sa propre horloge,
la situation change radicalement.
●
Bien que la fréquence à laquelle un
oscillateur à cristal fonctionne soit
généralement relativement stable, il est
impossible de garantir que les cristaux de
différents ordinateurs fonctionnent
exactement à la même fréquence.

Horloge physique
●
En pratique, quand un système a (n) ordinateurs, tous les (n)
cristaux fonctionneront à des vitesses légèrement différentes,
ce qui entraînera une désynchronisation progressive des
horloges (logicielles) et la lecture de valeurs différentes.
●
Cette différence de temps est appelée décalage/dérive
d'horloge. En raison de ce décalage d'horloge, les
programmes qui s'attendent à ce que le temps associé à un
fichier, à un objet, à un processus ou à un message soient
corrects et indépendants de la machine sur laquelle il a été
généré (c'est-à-dire quelle horloge il a utilisée) peuvent
échouer (comme dans l’exemple de make).

Horloge physique
●
La base pour garder l'heure globale est appelée Universal Coordinated Time mais elle est
abrégée en UTC.
– UTC est la base de tout chronométrage civil moderne et est une norme mondiale.
– Pour fournir l'heure UTC aux personnes qui ont besoin d'une heure précise, une quarantaine de stations
de radio à ondes courtes du monde entier diffusent une impulsion courte au début de chaque seconde
UTC.
– La précision de ces stations est d'environ ± 1 ms, mais en raison de fluctuations atmosphériques
aléatoires pouvant affecter la longueur du trajet du signal, en pratique, la précision ne dépasse pas ± 10
ms.
●
Plusieurs satellites de la Terre offrent également un service UTC. Le satellite géostationnaire
peut fournir le temps UTC avec précision à 0,5 ms, et certains autres satellites obtiennent
même de meilleurs résultats.
– En combinant les réceptions de plusieurs satellites, il est possible de construire des serveurs d’heure au
sol offrant une précision de 50 nsec.
●
Les récepteurs UTC sont disponibles dans le commerce et de nombreux ordinateurs en sont
équipés.

Horloge physique
pour résumer...
●
Horloge d'ordinateur: cristal au quartz qui vibre à une
fréquence précise (e.g. à plus ou moins 10 −6 ), avec une
interruption après un certain nombre d'oscillations, ce qui
génère un tic.
●
L'horloge est obtenue par un calcul d'un temps initial (heure lue
mémorisé avec une pile): temps lu au démarrage+ nombre de
tics depuis ce temps initial * durée d’un tic.
●
Les cristaux diffèrent d'un ordinateur à l'autre, ce qui cause une
désynchronisation entre les systèmes multi-ordinateurs,
appelée dérive/décalage des horloges (clock skew).

Algorithmes de synchronisation d'horloge

Algorithmes de synchronisation
d'horloge
●
Si une machine est équipée d’un récepteur UTC,
l’objectif est de garder toutes les autres machines
synchronisées.
●
Si aucune machine ne dispose de récepteurs UTC,
chaque machine garde une trace de son propre temps
et le but est de synchroniser ces machines.
●
De nombreux algorithmes ont été proposés pour
effectuer cette synchronisation.

Horloge physique
●
Toutes les horloges sont basées sur un oscillateur
harmonique
– Un objet qui résonne à une certaine fréquence et dont on peut
ensuite déduire le temps.
– Les horloges atomiques sont basées sur les transitions de
l'atome de césium 133.
●
Les horloges matérielles de la plupart des ordinateurs
utilisent un oscillateur à cristal (le quartz), également
capable de produire une fréquence très élevée et stable,
bien que moins stable que celle des horloges atomiques.

Horloge physique
●
Une horloge logicielle d’un ordinateur est dérivée de
l’horloge matérielle de cet ordinateur.
●
L’horloge matérielle provoque une interruption f fois par
seconde.
– Lorsque cette minuterie est désactivée, le gestionnaire
d'interruptions ajoute 1 à un compteur qui enregistre le nombre
de tics (interruptions) depuis une certaine heure convenue dans
le passé.
– Ce compteur agit comme une horloge logicielle C, résonnant
à la fréquence F.

Objectif des algorithmes de synchronisation
d’horloges
●
Si l'heure UTC est t, on note Cp(t) la valeur de
l'horloge logicielle sur la machine p.
●
Les algorithmes de synchronisation d'horloge
ont pour objectif de conserver l'écart entre les
horloges respectives de deux machines
quelconques d'un système distribué, dans une
limite spécifiée, appelée précision (precision) π:
→ ∀t, ∀p, q: | Cp(t) - Cq(t) | ≤ π

d’horloges
●
Notez que la précision fait référence à la
déviation des horloges uniquement entre les
machines faisant partie d'un système distribué.
●
Quand on considère un point de référence
externe, comme UTC, on parle d’exactitude
(accuracy), dans le but de la maintenir inférieur
à une valeur α:
→ ∀ t, ∀ p: | Cp(t) - t | ≤ α

d’horloges
●
L'idée même de la synchronisation
d'horloge est que nous gardons des
horloges précises (precise) ou exacte
(accurate)
– précises (precise), appelées synchronisation
interne
– exacte (accurate), appelées synchronisation
externe.

d’horloges
●
Un ensemble d'horloges qui sont exactes dans une
limite α , seront précis dans une limite π = 2α.
|C p (t )−t|≤α
|C q (t )−t|≤ α
|C p (t )−C q (t )|≤2∗α = π
●
Cependant, être précis ne nous permet pas de
conclure sur l'exactitude des horloges.

d’horloges
●
Dans un monde parfait, nous aurions Cp(t) = t pour tout p et tout t, et
donc α = π = 0.
●
Malheureusement, les horloges matérielles, et donc aussi les horloges
logicielles, sont soumises à une dérive d'horloge:
– en raison de leur fréquence qui n’est pas parfaite et affecté par des sources
externes (telles que la température), les horloges de différentes machines
commencent à afficher progressivement des valeurs différentes pour le temps.
→ C'est ce que l'on appelle le taux de dérive d'horloge: la différence par unité
de temps d'une horloge de référence parfaite.
●
Une horloge matérielle typique à quartz a un taux de dérive de l’ordre
de 10-6 secondes par seconde, ou environ 31,5 secondes par an. Il
existe des horloges de matériel informatique dont les taux de dérive
sont beaucoup plus faibles.
d’horloges
●
Les spécifications d'une horloge matérielle incluent
son taux de dérive d'horloge maximal ρ.
●
Si F (t) indique la fréquence réelle de l’oscillateur de
l’horloge matérielle à l’instant t et F sa fréquence
idéale (constante), une horloge matérielle est
conforme à ses spécifications si :
F (t )
∀ t ,1−ρ≤ ≤1+ ρ
F

d’horloges
●
En utilisant des interruptions matérielles, nous couplons
directement une horloge logicielle à une horloge matérielle, et
donc également à son taux de dérive. En particulier, nous
avons :
t
1 d Cp(t) F (t )
Cp(t )= ∗∫ F (t )dt ⇒ =
F 0 dt t
●
ce qui nous amène à notre objectif ultime, à savoir garder la
dérive de l'horloge logicielle à taux également inférieur à ρ
dCp(t )
∀ t : 1−ρ≤ ≤1+ ρ
dt
d’horloges

d’horloges
●
Si deux horloges s'écartent de UTC dans la direction
opposée, à un moment ∆t après leur synchronisation, elles
peuvent être éloignées de 2ρ * ∆t.
●
Si les concepteurs de système veulent garantir une précision
π, c'est-à-dire qu'aucune horloge ne diffère de plus de π
secondes, les horloges doivent être resynchronisées (au
moyen d'un logiciel) au moins toutes les π / (2ρ) secondes.
●
Les différents algorithmes diffèrent par la manière dont cette
resynchronisation est effectuée.

Network Time Protocol (NTP)
●
Une approche courante dans de nombreux protocoles et
proposée à l'origine par Cristian en 1989 (Cristian F.
Probabilistic Clock Synchronization. Distributed Computing,
3:146–158, 1989.) est de laisser les clients contacter un
serveur de temps.
●
Ce dernier peut fournir avec précision l’heure actuelle, en
l’équipant d’un récepteur UTC ou d’une horloge atomique.
●
Le problème, bien sûr, est que lorsqu’un client contacte un
serveur de temps, les retards de messages auront dépassé la
date indiquée. L'astuce consiste à trouver une bonne
estimation de ces retards.
●
Considérez la situation présenté par la figure ci-dessous
●
Dans ce cas, A enverra une requête à B, horodatée avec la
valeur T1. B, à son tour, enregistrera l'heure de réception T 2
(extraite de sa propre horloge locale), et retournera une
réponse horodatée avec la valeur T3, en y insérant la valeur
précédemment enregistrée T2. Enfin, A enregistre l’heure de
l’arrivée de la réponse, T4.

●
Supposons que les délais de propagation de
A à B soient à peu près identiques à ceux de
B à A, ce qui signifie que :
δ T requête =T 2−T 1≃T 4 −T 3= δ T reponse

●
Dans ce cas, A peut estimer son décalage
par rapport à B comme suit:
δ =délai de propagation de A → B≈délai de propagation de B → A
θ =déclagae de A par rapport à B
T 2=T 1 + δ + θ
T 4 =T 3 + δ −θ
(T 4 −T 2 )=(T 3−T 1 )−2∗θ
2(T −T )+(T −T )
1 3 4
θ= 2

δ =délai de propagation de A →B≈délai de propagation de B → A
θ=déclagae de A par rapport à B
T 2=T 1 + δ + θ
T 4 =T 3 + δ − θ
(T 4 −T 2 )=(T 3−T 1 )−2∗θ
(T −T )+(T −T )
2 1 3 4
θ= 2

●
Si l’horloge de A est rapide, θ <0, ce qui signifie
que A devrait, en principe, reculer son horloge.
●
Ceci n'est pas autorisé car cela pourrait
entraîner de graves problèmes, tels qu'un
fichier objet compilé juste après le changement
d'horloge ayant une heure antérieure à celle de
la source qui a été modifiée juste avant le
changement d'horloge.

●
Un changement dans l’horloge de A doit être introduit
progressivement.
●
Supposons que le minuteur soit configuré pour générer 100
interruptions par seconde.
●
Normalement, chaque interruption ajoute 10 ms à l’heure.
– Lors du ralentissement, la routine d’interruption n’ajoute que 9 ms à
chaque fois que la correction est effectuée.
– De la même manière, l'horloge peut être avancée progressivement en
ajoutant 11 ms à chaque interruption au lieu de la faire avancer d'un
coup.

●
Dans le cas du protocole NTP (Network Time Protocol), ce
protocole est configuré par paires entre les serveurs.
●
En d'autres termes, B sondera également A pour son heure
actuelle.
●
Le décalage θ est calculé comme précédemment, ainsi que
l'estimation δ pour le délai
δ =délai de propagation de A → B≈délai de propagation de B → A

θ=déclagae de A par rapport à B
T 2=T 1 + δ + θ
T 4 =T 3 + δ−θ
(T 2 +T 4 )=(T 1 +T 3 )+2∗δ
(T 2−T 1 )+(T 4 −T 3 )
δ=
2
●
Les paires de valeurs (θ, δ) sont mises en
mémoire tampon, prenant finalement la
valeur minimale trouvée pour δ comme
meilleure estimation du délai entre les deux
serveurs, puis la valeur associée θ comme
estimation la plus fiable du décalage.

●
L’application symétrique de NTP devrait en principe permettre également
à B d’ajuster son horloge sur celle de A.
●
Toutefois, si l’horloge de B est réputée être plus précise, un tel ajustement
serait alors ridicule.
●
Pour résoudre ce problème, NTP divise les serveurs en strates.
– Un serveur avec une horloge de référence, telle qu'un récepteur UTC ou une
horloge atomique, est connu pour être un serveur de strate-1 (on dit que l'horloge
elle-même fonctionne à la strate 0).
– Lorsque A contacte B, il ajuste uniquement son heure si son propre niveau de
strate est supérieur à celui de B.
– En outre, après la synchronisation, le niveau de strate de A devient supérieur à
celui de B.
– En d'autres termes, si B est une strate -k serveur, alors A deviendra une strate- (k +
1) serveur si son niveau de strate d'origine était déjà supérieur à k.
– En raison de la symétrie du NTP, si le niveau de la strate de A était inférieur à celui
de B, B s’ajustera à A.

L’algorithme de Berkley
●
Dans de nombreux algorithmes de synchronisation
d'horloge, le serveur de temps est passif. D'autres
machines lui demandent périodiquement l'heure.
Tout ce qu'il fait est de répondre à leurs questions.
●
Dans le système Unix de Berkley, l'approche
exactement opposée est adoptée.
●
Ici, le serveur de temps (en fait, un démon de temps)
est actif, interrogeant chaque machine de temps à
autre pour lui demander quelle heure il est là.
●
Sur la base des réponses,
– il calcule une durée moyenne
– et demande à toutes les autres machines d’avancer leurs horloges vers
la nouvelle heure
– ou de ralentir leur horloge jusqu’à ce qu’une réduction spécifiée soit
atteinte.
●
Cette méthode convient aux systèmes dans lesquels aucune
machine n’est équipée d’un récepteur UTC.
●
L’heure du démon de temps doit être définie manuellement par
l’opérateur périodiquement.


●
Notez que dans de nombreux cas, il suffit que toutes les machines
s’accordent sur le même temps.
– Il n'est pas essentiel que cette heure soit également en accord avec le temps
réel annoncé à la radio toutes les heures.
●
Si, dans notre exemple, l’horloge du démon de temps ne serait jamais
calibrée manuellement, aucun dommage n’est causé si aucun des
autres nœuds ne communique avec des ordinateurs externes.
●
Tout le monde sera simplement d’accord sur une heure actuelle, sans
que cette valeur n’ait aucun rapport avec la réalité.
●
L'algorithme de Berkeley est donc typiquement un algorithme de
synchronisation d'horloge interne.
Les horloges logiques

●
La synchronisation de l'horloge est naturellement liée à l'heure, bien
qu'il ne soit peut-être pas nécessaire de disposer du temps réel: il
peut suffire que chaque nœud d'un système distribué s'accorde sur
une heure actuelle.
● Nous pouvons aller plus loin. Pour exécuter make, il suffit que deux
nœuds s'accordent sur le fait que input.o est obsolète avec une
nouvelle version de input.c, par exemple.
●
Dans ce cas, il est important de garder une trace des événements de
chacun (telle que la production d’une nouvelle version de input.c).
Pour ces algorithmes, il est classique de parler d'horloges comme
des horloges logiques

Processus et systèmes répartis
●
Modèle du système réparti :
– Collection de N processus Pi où i = 1, 2, 3, ..., N.
– Chaque processus Pi exécute une séquence ordonnée
d’éventements notés: ei0 , ei1 , ei2 , …
– On dit que ei1 , ei2 , … sont des éventements locaux à Pi
– ei1 intervient avant ei2 ⇒ e ei1 < ei2
●
Les événement peuvent prendre trois formes
– Calcul locaux (mise à jours d’une variable,...)
– Émission d’un message à destination d’un autre processus
– Réception d’un message émis par un autre processus

●
Les processus sont indépendants ;
– Il n’y a pas de mémoire partagée entre les processus.
● Si: état du processus Pi.

– L’état = valeurs des variables, des ressources ou des
objets locaux utilisés par le processus.
●
La communication entre les processus ne se fait
que par transmission de messages.

● Processus Pi : Ensemble des actions (send,
receive, calcul local) pouvant modifier l’état
d’un processus Si
Si S’i
Opérations qui modifient l’état d’un processus :
– Calcul local
– Envoie d’un message
– Réception d’un message

e 11 e 12 e 13 e 14
P1
P2
e 21 e22 e 23
P3
e 31 e 32

e 11 e 12 e 13 e 14
P1
P2
e 21 e 22 e 23
P3
e 31 e 32
Des événement locaux

e 11 e 12 e 13 e 14
P1
P2
e 21 e 22 e 23
P3
e 31 e 32
Des réceptions de messages

e 11 e 12 e 13 e 14
P1
P2
e 21 e 22 e 23
P3
e 31 e 32
Des émissions de messages

Évènements dans un système réparti
●
Un évènement est l’occurrence d’une seule action
– Un évènement modifie l’état d’un processus.
●
L’ordre total unique des évènements est noté : →
– e → e’ si et seulement si l’événement e est survenu avant e’
dans Pi
● Historique de Pi est une série d’évènements survenus

dans Pi et ordonnés par la relation →
– History(Pi) = hi = < e0i , e1i , e2i , ... >

La causalité
●
Définition Larousse : « Lien qui unit la cause à l'effet. »
●
Définition CNRTL : « Rapport de la cause à son effet.
Principe de causalité en vertu duquel tout phénomène a
une cause. »
●
Wikipédia : « En physique, le principe de causalité
affirme que si un phénomène (nommé cause) produit un
autre phénomène (nommé effet), alors la cause précède
l'effet (ordre temporel) »

●
Dans un article phare publié en 1978 (voir ci-dessous), Lamport a
montré que, bien que la synchronisation d'horloge soit possible, elle
ne doit pas nécessairement être absolue.
●
Si deux processus n'interagissent pas, il n'est pas nécessaire que
leurs horloges soient synchronisées car le manque de
synchronisation ne serait pas observable et ne pourrait donc pas
causer de problèmes.
●
En outre, il a souligné que l’important n’est généralement pas que tous
les processus s’accordent sur l’heure exacte, mais plutôt sur l’ordre
dans lequel les événements se produisent.
– Dans l'exemple de création, ce qui compte est de savoir si input.c est plus ancien ou
plus récent que input.o, et non leurs temps de création absolus respectifs.
Leslie Lamport. 1978. Time, clocks, and the ordering of events in a distributed system.
Commun. ACM 21, 7 (July 1978), 558-565. DOI=http://dx.doi.org/10.1145/359545.359563
Les horloges logiques de Lamport
●
Pour synchroniser les horloges logiques, Lamport a défini une relation
appelée se produit-avant (happens before).
●
L'expression a → b est lue «l'événement a se produit avant l'événement b» et
signifie que tous les processus conviennent que le premier événement a se
produit, puis l'événement b se produit. La relation se produit-avant peut être
observée directement dans deux situations:
– 1. Si a et b sont des événements du même processus et que a se produit avant b, alors

a → b est vrai.
– 2. Si a est l'événement d'un message envoyé par un processus et b est l'événement de

la réception du message par un autre processus, alors a → b est également vrai. Un
message ne peut pas être reçu avant son envoi, ni même en même temps, car il faut un
temps fini et non nul pour

●
produit-avant (happens before) est une relation
transitive, donc si a → b et b → c, alors a → c.
●
Si deux événements, x et y, se produisent dans des
processus différents qui n'échangent pas de messages
(même indirectement via des tiers), alors x → y n'est ni
vrai ni fausse
– Ces événements sont dits concurrent, ce qui signifie
simplement que rien ne peut être dit (ou n'a pas besoin
d'être dit) sur le moment où les événements se sont produits
ou quel événement est survenu en premier.

a et b sont locaux à un même processus
&
a se produit avant b
∃ un message m /
a→b a : émission(m) & b : réception(m)
∃ un évnement c /
a→c&c→b

e 11 e 12 e 13 e 14 e 1 1 → e1 2
P1
e 2 1 → e2 2
P2 e21 → e12
e2 1
e2 2
e 3 e 2 2 → e1 2
2
P3 e13→ e31
e 31 e 32

●
Ce dont nous avons besoin, c'est d'un
moyen de mesurer une notion de temps telle
que, pour chaque événement, nous pouvons
lui attribuer une valeur de temps C (a) sur
laquelle tous les processus s'accordent.
●
Ces valeurs de temps doivent avoir la
propriété que si a → b, alors C (a) < C (b).

●
Pour reformuler les conditions énoncées précédemment, si a et b
sont deux événements dans le même processus et a se produit avant
b, alors C (a) < C (b).
●
De même, si a est l'envoi d'un message par un processus et que b est
la réception de ce message par un autre processus, alors C (a) et C
(b) doivent être attribués de manière à ce que tout le monde s'accorde
sur les valeurs de C (a) et C (b) avec C (a) <C (b).
●
De plus, le temps d'horloge, C, doit toujours avancer (augmenter),
jamais reculer (diminuer).
– Des corrections au temps peuvent être apportées en ajoutant une valeur
positive, jamais en soustrayant une.

●
Examinons maintenant l’algorithme proposé par Lamport pour
attribuer des heures aux événements.
●
Considérons les trois processus P1, P2 et P3.
●
Les processus s'exécutent sur différentes machines, chacune
avec sa propre horloge.

●
Nous supposons qu'une horloge est implémentée en tant que compteur logiciel:
le compteur est incrémenté d'une valeur spécifique toutes les T unités de temps.
●
Cependant, la valeur par laquelle une horloge est incrémentée diffère selon le
processus.
●
L'horloge du processus P 1 est incrémentée de 6 unités, 8 unités du processus P
2 et 10 unités du processus P 3, respectivement.

●
A l'instant 6, le processus P1 envoie le message m1 au processus P2.
– L'horloge du processus P2 lit 16 à son arrivée.
●
Si le message porte l'heure de début, le processus P2 en conclura qu'il lui a fallu
10 tics pour effectuer le trajet.
– Cette valeur est certainement possible.
●
Selon ce raisonnement, le message m2 de P2 à P3 prend 16 tics, encore une
valeur plausible.

●
Considérons maintenant le message m3. Il quitte le
processus P3 à 60 et arrive à P2 à 56.
●
De même, le message m4 de P2 à P1 part de 64 et arrive à 54.
●
Ces valeurs sont clairement impossibles.

●
La solution de Lamport découle directement de la relation se produit-avant.
– Comme m3 est parti à 60, il doit arriver à 61 ou plus tard.
●
Lorsqu'un message arrive et que l'horloge du destinataire indique une
valeur antérieure à l'heure d'envoi du message, le destinataire avance
rapidement son horloge à une heure de plus que l'heure d'envoi.
– Dans la figure ci-dessous, nous voyons que m3 arrive maintenant à 61. De même,
m4 arrive à 70.


récapitulons
●
Idée :
– Chaque événement (e) se voit associer une
horloge C(e)
– e → é ⇒ e C(e) < C(é)
– Afin de permettre aux processus d’estampiller
les événements qu’il exécute, Lamporte
propose l’algorithme suivant :

● Initialement : chaque Processus Pi a une
horloge Ci initialisé à 0
– ∀ i, Pi , CPi ←0
● Lorsqu’un événement local (e) à Pi se produit

– Pi incrément son horloge Cpi ← Cpi + 1
– Utilise cette horloge pour estampiller l’événement
C(e) ← Cpi

● Émission d’un message m par Pi
– Pi incrémente son horloge : Cpi ← Cpi + 1
– Utilise cette horloge pour estampiller l’événement C(e) ← Cpi
– Ajoute dans le message l’estampille ts(m) ← C(e)
●
Réception d’un message m ayant l’estampille ts(m) (m, ts(m))
– Mets à jours son horloge Cpi = max( Cpi , ts(m)) +1
– Utilise cette horloge pour estampiller l’événement C(e) ← Cpi

Exemple des horloges de Lamport
e 11 e 12
P1
P2
e 21 e 22 e 23
P3
e 31 e 32

3=max(0,2) +1
3 4
0 e 1
1 e 12
P1
1 m(2) 3
0 2
P2
e 21 e 22 e 23
m(4)
1 5
P3 0
e 31 e 32

une deuxième version de l’algorithme
● Pour mettre en œuvre les horloges logiques de Lamport, chaque processus Pi
maintient un compteur local Ci. Ces compteurs sont mis à jour selon les étapes
suivantes:
(1) Avant d’exécuter un événement (c’est-à-dire envoyer un message sur le

réseau, remise d'un message à une application ou à un autre événement interne),
Pi incrémente Ci: Ci ← Ci + 1.
(2) Lorsque le processus Pi envoie un message m au processus Pj, il définit

l’horodatage de m : ts(m) égal à Ci après avoir exécuté l'étape précédente
(3) A la réception d'un message m, le processus Pj ajuste son propre compteur

local comme Cj ← max {Cj, ts(m)}, après quoi il exécute la première étape et
transmet le message à l'application.

●
Dans certaines situations, une exigence
supplémentaire est souhaitable: deux
événements ne se produisent jamais
exactement au même moment.
●
Pour atteindre cet objectif, nous utilisons
également l'identificateur de processus
unique (PID) pour utiliser des paires au lieu
des valeurs du compteur.

● Par exemple, un événement à l’heure 40 du processus P i
sera horodaté sous la forme (40, i).
●
Si nous avons également un événement (40, j) et i < j , alors
(40, i) < (40,j).
● Notons qu'en affectant l'heure d'événement C(a) ← Ci(a) si

un événement (a) s'est produit au processus Pi à l'instant
Ci(a), nous avons une implémentation distribuée de la
valeur de temps globale que nous recherchions
initialement; nous avons donc construit une horloge
logique.
3=max(0,2) +1
3 4
0 e 1
1 e 12
P1
1 m(2) 3
0 2
P2
e 21 e 22 e 23
m(4)
1 5
P3 0
e 31 e 32

Les horloges vectorielles
●
Les horloges logiques de Lamport conduisent à une situation
dans laquelle tous les événements d'un système distribué sont
totalement ordonnés avec la propriété que si l'événement (a) eu
lieu avant l'événement (b), alors C(a) < C(b).
●
Cependant, avec les horloges Lamport, rien ne peut être dit sur
la relation entre deux événements (a) et (b) en comparant
simplement leurs valeurs temporelles C(a) et C(b).
●
En d'autres termes, si C(a) < C(b), cela n'implique pas
nécessairement que (a) a bien eu lieu avant (b).

●
Considérons les messages
envoyés par les trois
processus.
● Notons Tsnd(mi) l'heure logique à

laquelle le message mi a été
envoyé, et de même par Trcv(mi)
l'heure de sa réception.
●
Par construction, nous savons
que pour chaque message,
Tsnd(mi) <Trcv(mi).
Mais que pouvons-nous conclure de Trcv(mi) < Tsnd(mj)

pour des messages mi et mj différents ?

● Dans le cas où mi = m1 et mj =
m3, Trcv(m1) =16 < Tsnd(m3) = 32
●
Nous savons que ces valeurs
correspondent à des
événements survenus au
processus P2, ce qui signifie
que m3 a bien été envoyé
après la réception du
message m1
●
Cela peut indiquer que l'envoi
du message m3 dépend de ce
qui a été reçu via le message
m1.
●
Dans le même temps,
nous savons
également que
Trcv(m1) =16 < Tsnd(m2)
= 20.
●
Cependant, l'envoi
de m2 n'a rien à voir
avec la réception de
m1.

●
Le problème est que les horloges de
Lamport ne capturent pas la causalité.
●
En pratique, la causalité est capturée au
moyen d'horloges vectorielles.

●
En fait, le suivi du lien de causalité est simple si nous
affectons à chaque événement un nom unique, tel que la
combinaison de l’ID de processus et un compteur
incrémentant localement: pk est le kème événement
survenu au processus P.
●
Le problème se résume alors à garder trace de histoires
causales.
●
Par exemple, si deux événements locaux se sont
produits au processus P, l'historique de causalité H(p2)
de l'événement p2 est {p1, p2}.

●
Supposons maintenant que le processus P
envoie un message au processus Q
– qui est un événement chez P et est donc
enregistré comme pk
●
Supposons qu’au moment de l’arrivée,
l’historique de causalité le plus récent de Q
était {q1}.

●
Pour suivre la causalité, P envoie également son
historique de causalité le plus récent
● supposons qu'il s'agisse de {p1, p2}, étendu avec

p3 exprimant l'envoi du message.
● À son arrivée, Q enregistre l'événement (q2) et

fusionne les deux historiques de causalité dans
un nouveau: { p1 , p2 , p3 , q1 , q2 } .

●
Pour vérifier si un événement p précède de manière
causale un événement q, on doit vérifier si
H ( p)⊂H (q)
●
il doit s'agir d’une inclusion stricte (excluant le cas
d'égalité)
●
En fait, avec cette notation, il suffit même de vérifier si p
∈ H (q), en supposant que q est toujours le dernier H (q), en supposant que q est toujours le dernier
événement local de H (q).

●
Le problème avec les historiques de causalité est que
leur représentation n’est pas très efficace.
– Il n'est pas nécessaire de garder une trace de tous les
événements successifs du même processus: le dernier fera
l'affaire.
●
Si, par la suite, nous attribuons un index à chaque
processus, nous pouvons représenter un historique de
causalité sous forme de vecteur, dans lequel la jème
entrée représente le nombre d'événements survenus
au processus Pj.

historique de causalité == vecteur
la jème entrée représente

le nombre d'événements
survenus au processus Pj

Vecteurs de compteurs d'événements
●
Vecteur de N entiers initialisés à 0 dans chacun des N processus.
● A chaque événement dans le processus i, Vi[i] est incrémenté.
● A chaque message envoyé par le processus i, Vi est inclus.
●
Lorsque le processus i reçoit un vecteur dans un message, il prend pour
chaque entrée de son vecteur le maximum entre l'entrée présente et celle
reçue (fusion des vecteurs).
●
Chaque entrée dans le vecteur du processus i indique le dernier événement
dans un autre processus qui peut avoir influencé le processus i (lien de
causalité).

exemple préliminaire
Et la théorie dans tout ça ???

●
La causalité peut ensuite être capturée au moyen d'horloges
vectorielles, construites en laissant chaque processus P i
maintenir un horloge vectorielle VCi avec les deux propriétés
suivantes:
1) VCi[i] est le nombre d'événements survenus jusqu'ici à P i. En

d'autres termes, VCi[i] est l'horloge logique locale du
processus Pi.
1) Si VCi[j] = k alors Pi sait que k événements se sont produits à

Pj. Pi connaît l'heure locale à Pj.

●
La première propriété est maintenue en
incrémentant VCi[i] à l'occurrence de
chaque nouvel événement qui se produit au
processus Pi.
●
La deuxième propriété est maintenue en
envoyant des vecteurs avec les messages

●
Les étapes suivantes sont effectuées :
1) Avant d'exécuter un événement (c'est-à-dire

envoyer un message sur le réseau, remettre un
message à une application ou à un autre
événement interne),
Pi exécute : VCi[i] ← VCi[i] + 1. Cela équivaut à
l'enregistrement un nouvel événement qui s'est
passé à Pi.

● 2) Lorsque le processus Pi envoie un

message m à Pj , il définit l’horodatage de m
ts(m) ← VCi après avoir exécuté l'étape
précédente (c'est-à-dire qu'il enregistre
l'envoi du message en tant qu'événement se
déroulant sur Pi).

●
3) A la réception d’un message m, le
processus Pj ajuste son propre vecteur en
régler VCj[k] ← max {VCj[k], ts(m)[k]} pour
chaque k (ce qui est équivalent fusionner
des historiques de causalité), après quoi il
exécute la première étape (enregistrement).
réception du message) puis remet le
message à l’application.

●
Notez que si un événement (a) a un horodatage
ts(a), alors ts(a)[i] - 1 indique le nombre
d'événements traités à Pi qui précèdent de
manière causale (a).
● En conséquence, lorsque Pj reçoit un message

m de Pi avec l’estampille temporelle ts(m), il
connaît le nombre d’événements survenus au
niveau de Pi qui ont précédé l’émission de m.

●
Plus important, cependant, il est également dit
à Pj combien d’événements ont eu lieu à
d’autres processus, connus de Pi, avant que Pi
n’ait envoyé le message m.
●
En d'autres termes, l'horodatage ts(m) indique
au destinataire combien d'événements dans
d'autres processus ont précédé l'envoi de m et
dont peut dépendre de la causalité de m.

exemple#1
● P2 envoie un message m1 au moment logique VC2 = (0, 1, 0) au
traitement de P1.
● Le message m1 reçoit donc l’estampille temporelle ts(m1) = (0, 1,
0).
● Dès sa réception, P1 ajuste son temps logique sur VC1 ← (1, 1,
0) et le délivre.
● Le message m2 est envoyé de P1 à P3 avec l’estampille
temporelle ts (m2) = (2, 1, 0).

exemple#1
● Avant que P1 envoie un autre message, m3, un événement
se produit sur P1, menant éventuellement à un horodatage
de m3 avec une valeur (4, 1, 0).
● Après réception de m3, le processus P2 envoie le message

m4 à P3, avec l’estampille temporelle ts (m 4) = (4, 3, 0)

exemple#2 vs. exemple#1
●
Dans l’exemple 2 (en rouge), nous avons différé l’envoi du
message m2 jusqu’à ce que le message m3 ait été envoyé et après
que l’événement ait eu lieu. Il n’est pas difficile de voir que ts (m 2)
= (4, 1, 0), alors que ts(m4) = (2, 3, 0)

ts(m2) (4,1,0) (2,1,0)
ts(m4) (2,3,0) (4,3,0)
ts(m2)<ts(m4) Non Oui
ts(m4)<ts(m2) Non Non
Conclusion m2 et m4 peuvent m2 peut précéder

entrer en conflit causlement m4
●
On utilise la notation ts(a) < ts(b) si et seulement si pour tout k,
ts(a)[k] ≤ ts(b)[k] et il existe au moins un indice k’ pour lequel
ts(a) [k’] <ts(b) [k’].
● Ainsi, en utilisant des horloges vectorielles, le processus P 3

peut détecter si m4 peut être causalement dépendant de m2 ou
s'il peut y avoir un conflit potentiel.
●
Notez en passant que sans connaître les informations
contenues dans les messages, il n’est pas possible d’affirmer
avec certitude qu’il existe bien un lien de causalité, voire un
conflit.

État Global & Coupure Cohérente

Contexte
●
Dans un système répartie :
– pas d’horloge commune
– temps de transfert des messages non borné (fini si pas de perte)
– impossible d’effectuer une observation simultanée
●
L’observation d’un état global permet :
– de détecter des propriétés caractérisant l’exécution (interblocage,
terminaison,...)
– d’effectuer des mesures de performances
– de capter des états pouvant servir de points de reprise en cas de
défaillance

Objectif
●
Notre objectif est de savoir si une propriété
particulière d'un système distribué en cours
d'exécution est vraie.
●
Nous commençons par donner les exemples :
– distributed garbage collection (Ramasse-miettes distribuée),
– détection d’interblocage,
– détection de terminaison
– débogage.

Distributed garbage collection
●
Un objet est considéré ‘garbage’ s'il n'y a
plus aucune référence à celui-ci dans le
système distribué.
– La mémoire occupée par cet objet peut être
récupérée une fois qu’on sait qu’il s’agit de déchets.
●
Pour vérifier qu'un objet est ‘garbage’, nous
devons vérifier qu'il n'y a aucune référence à
celui-ci dans le système.

●
Le processus p1 a deux objets qui ont tous deux des
références
– l'un a une référence dans p1 et l’autre est référencé par p2.
●
Le processus p2 ne contient qu'un seul objet, sans
aucune référence dans le système (noté grabage object
dans la figure).
●
Il possède également un objet pour lequel ni p1 ni p2 ne
sont référencés, mais il y est fait référence dans un
message en transit entre les processus.

●
Cela montre que lorsque nous considérons
les propriétés d'un système, nous devons
inclure l'état des canaux de communication
ainsi que l'état des processus.

Détection d'interblocage distribué
●
Un interblocage distribué se produit lorsque chaque groupe
de processus attend qu'un autre processus lui envoie un
message et qu’il existe un cycle dans le graphique de
cette relation d’attente.
●
Les processus p1 et p2 attendent chacun un message de
l’autre, de sorte que ce système ne progressera jamais.

Détection de terminaison distribuée
●
Le problème ici est de savoir comment
détecter qu’un algorithme distribué est
terminé.
●
La détection de la terminaison est un
problème qui a l'air d'une simplicité
trompeuse: il semble tout d'abord nécessaire
de vérifier si chaque processus s'est arrêté.

●
Considérons un algorithme distribué exécuté
par deux processus p1 et p2, chacun pouvant
demander des valeurs à l'autre.
●
Instantanément, nous pouvons constater
qu’un processus est soit actif, soit passif:
– un processus passif n’est pas engagé dans une
activité propre mais est prêt à répondre avec une
valeur demandée par l’autre.

●
Supposons que p1 et p2 sont dans un état passif
●
Pour voir que nous ne pouvons pas conclure que
l'algorithme est terminé, considérons le scénario suivant:
– lorsque nous avons testé la passivité de p1, un message était en
route depuis p2, qui est devenu passif immédiatement après l'avoir
envoyé.
– À la réception du message, p1 est redevenu actif - après l’avoir
découvert passif.
– L'algorithme n'était pas terminé.

●
Les phénomènes de terminaison et d’interblocage sont similaires
à certains égards, mais ce sont des problèmes différents.
●
Premièrement, un interblocage ne peut affecter qu'un sous-
ensemble des processus d'un système, alors que tous les
processus doivent être terminés.
●
Deuxièmement, la passivité du processus n’est pas la même
chose que l’attente dans un cycle d’interblocage: un processus
bloqué tente d’exécuter une action supplémentaire pour laquelle
un autre processus attend; un processus passif n'est engagé
dans aucune activité.

Débogage distribués
●
Les systèmes distribués sont complexes à déboguer, et
il faut prendre soin d’établir ce qui s’est passé pendant
l’exécution.
●
Par exemple, supposons que vous avez écrit une
application dans laquelle chaque processus Pi contient
une variable xi (i = 1,2,….,N).
●
Les variables changent au fur et à mesure de l'exécution
du programme, mais elles doivent toujours respecter la
contraintes |xi -xj| < d

Débogage distribués
●
Malheureusement, il y a une erreur dans le
programme et vous soupçonnez que, sous
certaines conditions, |xi -xj| > d pour
certains i et j, brisant ses contraintes de
cohérence.
●
Le problème est que cette relation doit être
évaluée pour les valeurs des variables qui
se produisent en même temps.

État global et coupure cohérente
●
Il est en principe possible d'observer la succession
d'états d'un processus individuel mais la question de
savoir comment déterminer un état global du système -
l'état de tous les processus - est beaucoup plus difficile à
traiter.
●
Le problème essentiel est l'absence de temps global. Si
tous les processus avaient des horloges parfaitement
synchronisées, nous pourrions nous mettre d'accord sur
une heure à laquelle chaque processus enregistrerait son
état - le résultat serait un état global réel du système.

●
À partir de la collection d'états de
processus, nous pouvons par exemple
savoir si les processus sont dans
interblocage. Mais nous ne pouvons pas
obtenir une synchronisation d'horloge
parfaite, cette méthode ne nous est donc
pas disponible.

Nous pourrions donc nous demander
si nous pouvons assembler
un état global significatif à partir
d’états locaux enregistrés à des moments différents ?

●
Pour récapituler :
– État globale = U{ États locaux des processus} +
U{États des canaux de communication}
– Si nous avions une synchronisation parfaite, il
aurait était facile d’avoir un état globale à un
temps ti
– Pas de synchronisation ⇒ e Former un état
globale avec des temps différents dans l
différents processus

●
On considère un système distribué (Ρ)) composé de N
processus Pi, i={1,2,…,N}
● Une série d’éventements (eij ) se produisent à chaque

processus et on caractérise l'exécution de chaque
processus par son historique:
history(Pi) = hi = <ei0 , ei1 , ei2 , ei3, ... >
●
De même, nous pouvons considérer n’importe quel
préfixe fini de l’historique du processus:
hik = <ei0 , ei1 , ei2 , …, eik >

●
Chaque événement est :
– soit une action interne du processus (par exemple,
la mise à jour d'une de ses variables),
– soit l'envoi ou la réception d'un message sur les
canaux de communication qui connectent les
processus.

●
Nous pouvons enregistrer ce qui s’est passé lors de
l’exécution du système distribué (P).
●
Chaque processus peut enregistrer les événements qui
s'y déroulent et la succession d'états par lesquels il
passe.
● On note sik l'état de processus Pi immédiatement avant

que le kème événement ne se produise, de sorte que si0
est l'état initial de Pi.

●
Notons que l’état des canaux de communication est parfois
pertinent.
●
Plutôt que d'introduire un nouveau type d'état, nous faisons
en sorte que les processus enregistrent l'envoi ou la
réception de tous les messages dans le cadre de leur état.
● Si nous trouvons que le processus Pi a enregistré l'envoi

d'un message m au processus Pj, i≠ j, alors en examinant si
Pj a reçu ce message, nous pouvons en déduire si m fait ou
non partie de l'état du canal entre Pi et Pj.

●
Nous pouvons également former l’histoire
globale de (P) en tant qu’union des historiques
de processus individuels:
H=h0 U h1 U h2 U….U hN-1
●
Mathématiquement, on peut prendre n'importe
quel ensemble d'états des processus individuels
pour former un état global S = (s1 ,s2,...sN ).

●
Une coupure (cut) de l'exécution du
système : est un sous-ensemble de son
historique global qui est une union de
préfixes d'historique de processus
C= h1c1 U h2c2 U….U hNcN
●
Coupe ⇐ ⇒ coupure ⇒ e coupure ⇐ ⇒ coupure ⇒ e Cliché

Définition d’une coupure cohérente
●
Plus intuitivement, une coupure C est un
sous-ensemble de l’état global
– une coupure C de l’histoire globale d’un
système est un n-uplet dont chaque
composante est un préfixe de l’histoire locale
du processus correspondant :
C=<c1,c2,….,cN> où cj =<ej1,ej2,ej3,…,ejn>

●
Nous avons ci-dessous deux coupes avec
deux frontières :
– Coupure#1 avec la frontière <e10 , e20>
– Coupure#2 avec la frontière <e12 , e22>

●
La coupure#1 , n’est pas cohérente.
– En effet, en P2, elle inclut la réception du
message m1, mais en P1, elle ne comprend pas
l’envoi de ce message.
●
⇒ e Cela montre un ‘effet’ sans sa ‘cause’.

●
La coupure#2 , est cohérente.
●
Elle inclut à la fois l’envoi et la réception du message
m1 et l’envoi mais pas la réception du message m2.

●
Un coupure C est cohérent si, pour chaque
événement qu’elle contient, elle contient
également tous les événements qui se sont
passés avant cet événement :
∀ e∈C , f →e ⇒ f ∈C

Définition d’un état global cohérent
●
Un état global cohérent correspond à une coupure cohérente.
●
On peut caractériser l'exécution d'un système distribué comme une série de
transitions entre des états globaux du système:
S1 → S2 → S3 → S4
●
Dans chaque transition, un événement se produit précisément dans un
processus unique du système.
– Cet événement est l’envoi d’un message, la réception d’un message ou un
événement interne.
– Si deux événements se produisent simultanément, nous pouvons néanmoins
considérer qu'ils se sont produits dans un ordre défini - par exemple, en fonction de
l’identificateur des processus (PID).
●
Un système évolue de la sorte à travers des états globaux cohérents.
Les snapshots

Cliché (ou snapshot)
●
Chaque application distribuée comporte un certain
nombre de processus s'exécutant sur plusieurs serveurs
physiques.
●
Ces processus communiquent entre eux via des canaux.
●
Un cliché (ou snapshot) capture les états locaux de
chaque processus (par exemple, les variables de
programme) ainsi que l'état de chaque canal de
communication.

● Deux Processus P1 et P2 ayant trois variables (X,Y,Z)
● Canal C12 de P1 → P2
● Canal C21 de P2 → P1
C12
X X
Y P1 P2 Y
Z Z
C21
●
Au départ les canaux sont vides et les variables
X,Y et Z ont les valeurs ci-dessous
●
Il s’agit d’un snapshot !
C12 [Vide]
X1 = 0 X2 = 1
Y1 = 0
P1 P2 Y2 = 2
Z1 = 0 Z2 = 3
C21 [Vide]
●
P1 demande à P2 de modifier sa variable X2 de
1à4
●
C12 [X2 → 4]
X1 = 0 X2 = 1
Y1 = 0
P1 P2 Y2 = 2
Z1 = 0 Z2 = 3
C21 [Vide]
●
P2 reçoit le message de P1
●
X2 → 4
C12 [Vide]
X1 = 0 X2 = 1
Y1 = 0
P1 P2 Y2 = 2
Z1 = 0 Z2 = 3
C21 [Vide]
● P2 change sa variable X2 de 1 à 4
●
C12 [Vide]
X1 = 0 X2 = 4
Y1 = 0
P1 P2 Y2 = 2
Z1 = 0 Z2 = 3
C21 [Vide]
Obtention d’un cliché cohérent
Algorithme de Chandy & Lamport
●
Chandy et Lamport décrivent un algorithme « de cliché
ou snapshot» permettant de déterminer les états des
systèmes distribués.
●
L’algorithme a pour but d’enregistrer un ensemble d’états
de processus et de canaux (un «cliché instantané») pour
un ensemble de processus tels que, même si la
combinaison d'états enregistrés peut ne jamais s'être
produite en même temps, l'état global enregistré est
cohérent.

●
L'algorithme enregistre l'état localement au
niveau des processus; il ne donne pas de
méthode pour collecter l'état global sur un site.
●
Une méthode évidente de collecte de l'état
consiste pour tous les processus à envoyer
l'état qu'ils ont enregistré à un processus de
collecteur désigné.

●
L'algorithme suppose que:
– Ni les canaux ni les processus n'échouent - la communication est fiable de sorte

que chaque le message envoyé est finalement reçu intact, exactement une fois.
– Les canaux sont unidirectionnels et fournissent une remise de messages

ordonnée par FIFO.
– Le graphe des processus et des canaux est fortement connecté (il existe un
chemin entre deux processus quelconques).
– Tout processus peut initier un snapshot global à tout moment.
– Les processus peuvent continuer leur exécution et envoyer et recevoir des

message pendant l’exécution de l’algorithme

●
Pour chaque processus :
– les canaux entrants sont ceux sur lesquels d’autres processus lui envoient des
messages;
– de même, les canaux sortants de sont ceux sur lesquels il envoie des messages à
d'autres processus.
●
L'idée essentielle de l'algorithme est la suivante :
– Chaque processus enregistre son état et, pour chaque canal entrant, l’ensemble de messages qui
lui sont envoyés.
– Le processus enregistre, pour chaque canal, tous les messages arrivés après que son état ait été
enregistré et avant que l'expéditeur ait enregistré son propre état.
– Cette disposition nous permet d’enregistrer les états des processus à des moments différents tout
en prenant compte des différences entre les états de processus en termes de messages transmis
mais pas encore reçus.
● Si le processus Pi a envoyé un message (m) au processus P j, mais que Pj ne l'a pas reçu,
alors nous considérons que (m) appartient à l'état du canal entre eux.

●
L'algorithme utilise des marqueurs spéciaux,
distincts des autres messages envoyés par les
processus et que les processus peuvent envoyer et
recevoir pendant leur exécution normale.
●
Le marqueur a un double rôle:
– inviter le destinataire à enregistrer son propre état, s'il
ne l’a pas déjà fait;
– et comme moyen de déterminer quels messages inclure
dans l'état du canal.

●
L'algorithme se base sur deux règles, la règle de réception du
marqueur et la règle d'envoi du marqueur.
– La règle d'envoi de marqueur oblige les processus à envoyer un

marqueur après avoir enregistré leur état, mais avant d'envoyer d'autres
messages.
– La règle de réception de marqueur oblige un processus qui n'a pas

enregistré son état à le faire. Dans ce cas, c’est le premier marqueur qu’il
a reçu. Il note par la suite quels sont les messages qui arrivent sur les
autres canaux entrants. Et envoie un marqueur sur tous ces canaux
sortant. Lorsqu'un processus qui a déjà enregistré son état reçoit un
marqueur (sur un autre canal), il enregistre l'état de ce canal (l'ensemble
des messages qu'il a reçus depuis qu'il a sauvegardé son état).

●
Tout processus peut commencer l’algorithme à tout moment.
●
Il agit comme s'il avait reçu un marqueur (sur un canal
inexistant) et suit la règle de réception du marqueur.
●
Ainsi, il enregistre son état et commence à enregistrer les
messages arrivant sur tous ses canaux entrants.
●
De cette manière, plusieurs processus peuvent lancer
l’enregistrement simultanément (à condition de pouvoir
distinguer les marqueurs qu’ils utilisent).

●
Pour un processus Pj, l'algorithme est fini
quand il a reçu un marqueur sur chacun de
ses canaux
●
L'état enregistré pour Pj est composé de
– Son état local (variable, données ...)
– Les états de tous ses canaux entrants


Déroulement de l’algorithme de Chandy & Lamport
Étape 1 : initier un snapshot
● Supposons que Pi initie le snaphsot
● Pi enregistre son état et prépare le message marqueur à envoyer
●
For j=1 to N (except i)
– Pi envoie le marqueur sur le canal sortant (i→j) Cij
START RECORDING :
●
For j=1 to N (except i)
– Pi enregistre tous les messages des canaux entrants (j → i) Cji

Étape 2 : propager un snapshot
● Lorsqu’un processus Pi (y compris l'initiateur), reçoit un marquer sur son canal
entrant j→ i : Cji
● Si c’est le premier marqueur reçu par Pi

– Pi enregistre son propre état
– marque l’état de Cji comme vide { }
– For j=1 to N (except i) :
● Pi envoi le marqueur sur le canal sortant (i→j): Cij
– START RECORDING :
– For j=1 to N (except i)
● Pi enregistre tous les messages des canaux entrants (j → i) : Cji
●
Sinon :
– Enregistrer l’état du canal Cji : Les messages qui sont arrivées sur le canal Cji depuis
l’enregistrement a commencé sur le canal Cji

Étape 3 : terminer un snapshot
●
Tous les processus ont reçu un marqueur (et
enregistré leur propre état)
●
Tous les processus ont reçu un marqueur sur tous les
N-1 canaux entrants (et enregistré leur États)
●
Plus tard, un serveur central peut rassembler les
données partielles pour construire un snapshot
global...

Exemple#1 : P1 initie a snapshot
C12 [Vide]
X1 = 0 X2 = 4
Y1 = 0
P1 P2 Y2 = 2
Z1 = 0 Z2 = 3
C21 [Vide]
Exemple#1: P1 enregistre sont état
C12 [Vide]
X1 = 0 X2 = 4
Y1 = 0
P1 P2 Y2 = 2
Z1 = 0 Z2 = 3
C21 [Vide]
Exemple#1: P1 propage un
snapshot
●
Ensuite, P1 envoie un message marqueur à P2 et
commence à enregistrer tous les messages sur les
canaux entrants.
• Pendant ce temps, P2 a envoyé un message à P1.
C12 [marqueur]
X1 = 0 X2 = 4
Y1 = 0
P1 P2 Y2 = 2
Z1 = 0 Z2 = 3
C21 [M1]
Exemple#1: P1 propage un
snapshot
●
P2 reçoit un message de marqueur pour la première
fois, enregistre donc son état
●
P2 envoie ensuite un message marqueur à P1
marqueur
C12 [vide]
X1 = 0 X2 = 4
Y1 = 0
P1 P2 Y2 = 2
Z1 = 0 Z2 = 3
M1
C21 [marqueur]
Exemple#1: P1 terminaison d’un
snapshot
●
P1 a déjà envoyé un message marqueur, il
enregistre donc tous les messages reçus sur les
canaux entrants dans l'état du canal approprié.
C12 [vide]
X1 = 0 X2 = 4
Y1 = 0
P1 P2 Y2 = 2
Z1 = 0 Z2 = 3
M1
C21 [vide]
Exemple#1: P1 terminaison d’un
snapshot
●
Les deux processus ont enregistré leur état et tous
les états de tous les canaux entrants.
●
Le snapshot est mis en surbrillance en rouge
C12 [vide]
X1 = 0 X2 = 4
Y1 = 0
P1 P2 Y2 = 2
Z1 = 0 Z2 = 3
M1
C21 [vide]
Exemple#2
source :https://courses.engr.illinois.edu/cs425/fa2015/L3.FA15.pdf

Exemple#2

Exemple#2

Exemple#2

Exemple#2

Exemple#2

Exemple#2

Exemple#2

Exemple#2

Exemple#2

Exemple#2

The End !

Systèmes Répartis. Chapitre IV - Coordination. Amine DHRAIEF Année Master Pro Data Science. 1ère

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Systèmes Répartis. Chapitre IV - Coordination. Amine DHRAIEF Année Master Pro Data Science. 1ère

Transféré par

Droits d'auteur :

Formats disponibles

Systèmes Répartis

30/11/2018 Systèmes Répartis 2

30/11/2018 Systèmes Répartis 3

30/11/2018 Systèmes Répartis 4

30/11/2018 Systèmes Répartis 5

30/11/2018 Systèmes Répartis 6

30/11/2018 Systèmes Répartis 7

La navigation aérienne utilise largement le GPS

30/11/2018 Systèmes Répartis 12

Qui est le premier ?

30/11/2018 Systèmes Répartis 13

30/11/2018 Systèmes Répartis 14

30/11/2018 Systèmes Répartis 15

30/11/2018 Systèmes Répartis 16

30/11/2018 Systèmes Répartis 17

30/11/2018 Systèmes Répartis 18

30/11/2018 Systèmes Répartis 19

30/11/2018 Systèmes Répartis 20

● make n'appelle pas le compilateur.

1- output.o ait l'heure 21 :44

30/11/2018 Systèmes Répartis 23

La réponse est très compliqué.

30/11/2018 Systèmes Répartis 24

30/11/2018 Systèmes Répartis 25

30/11/2018 Systèmes Répartis 28

30/11/2018 Systèmes Répartis 29

30/11/2018 Systèmes Répartis 30

30/11/2018 Systèmes Répartis 31

30/11/2018 Systèmes Répartis 32

30/11/2018 Systèmes Répartis 33

30/11/2018 Systèmes Répartis 34

30/11/2018 Systèmes Répartis 35

30/11/2018 Systèmes Répartis 36

30/11/2018 Systèmes Répartis 37

30/11/2018 Systèmes Répartis 38

30/11/2018 Systèmes Répartis 39

30/11/2018 Systèmes Répartis 41

30/11/2018 Systèmes Répartis 43

30/11/2018 Systèmes Répartis 44

30/11/2018 Systèmes Répartis 46

30/11/2018 Systèmes Répartis 48

30/11/2018 Systèmes Répartis 49

30/11/2018 Systèmes Répartis 50

30/11/2018 Systèmes Répartis 51

30/11/2018 Systèmes Répartis 52

δ =délai de propagation de A → B≈délai de propagation de B → A

30/11/2018 Systèmes Répartis 54

30/11/2018 Systèmes Répartis 56

30/11/2018 Systèmes Répartis 58

30/11/2018 Systèmes Répartis 59

30/11/2018 Systèmes Répartis 61

30/11/2018 Systèmes Répartis 62

30/11/2018 Systèmes Répartis 63

● Si: état du processus Pi.

30/11/2018 Systèmes Répartis 64

Opérations qui modifient l’état d’un processus :

30/11/2018 Systèmes Répartis 65

30/11/2018 Systèmes Répartis 66

30/11/2018 Systèmes Répartis 67

30/11/2018 Systèmes Répartis 68

30/11/2018 Systèmes Répartis 69

● Historique de Pi est une série d’évènements survenus

30/11/2018 Systèmes Répartis 70