Syst Distribués

Ecole Nationale d’Ingénieurs de Brest
Systèmes Distribués
Techniques et Algorithmes de mise en œuvre des systèmes répartis
P. De Loor, deloor@enib.fr
Ecole Nationale d’Ingénieurs de Brest
Algorithmes de mise en œuvre des systèmes répartis
1. GENERALITES
P. De Loor, deloor@enib.fr
Techniques et Algorithmes des systèmes répartis : Généralités
ν Systèmes répartis : Réseau
réseau
ν Machines, personnes, processus, « agents » … localisés à des

endroits différents.
page 1
ν Distribution d’un calcul.
ν Les processus coopèrent pour régler un problème unique.

Faiblement couplés
Par échange de messages souvent asynchrone
Délais arbitraires
pas d ’horloge globale
ν Optimisation des tâches (sites spécialisés), résistance aux pannes ...
page 2
ν Exemple de problème : l’observation d’un calcul distribué
message de contrôle
• Les processus ne peuvent être

observés simultanément.
• L ’observation n ’est possible que par • Pas d ’horloge globale.
le biais de messages de contrôle (avec • suivi d ’un calcul ?
des temps de transmission arbitraires).
page 3
ν Exemple : Interconnexion bancaire :
Compte A : 4500
• Pas de vision globale. Compte A : 0

• Pas de temps commun.
• Combien a-t-il d ’argent ?
page 4
ν Autre exemple : l’exclusion mutuelle.
ν Cas centralisé :
ν La clef est une variable commune (verrou).
page 5
ν Cas distribué :
ν Tous les échanges d’information se font par messages.
page 6
• Chaque feu passe au rouge de façon autonome.

• Un feu ne passe au vert que si l ’autre est rouge.
• Les temps de transfert sont arbitraires.
Observateur 1
temps
comportement autonome rouge

vert
sync mess
rouge vert
Observateur 22
Dans quelle mesure cette observation est fausse ?

page 7
Cohérence temporelle :
• A envoi un message à C puis à B

• B réagit en envoyant un message à C.
∆t B
A
(m2,A)
(m3,B)
(m1,A) C
• C peut voir (m1,A) avant ou après (m3,B).

• Peut influer sur le déterminisme de l ’algorithme global !
page 8
Résumé :
♦ Distribution :
Partage (donnée ressources) Coopération (programme)
Compétition Coordination
Synchronisation + Communication
: Sans mémoire commune.

: Sans horloge globale.
page 9
Ce qui est distribué et les problèmes associés :
1) Distribution des données : duplication et/ou partitionnement

- problème de cohérence des données à un instant.
- problème d’accès (exclusion mutuelle répartie).
- problème de définition optimale des répartitions.
2) Distribution des calculs :

- problème de blocage « inter-blocage ».
- problème de terminaison d’un calcul.
- de coordination (rendez-vous).
3) Distribution des algorithmes de mise en œuvre de la distribution

- gestion de l’exclusion mutuelle sans mémoire commune.
- gestion de la cohérence des données dans le temps.
- détection de la terminaison et de l’interblocage.
page 10
♦ L’algorithmique distribuée :
• Eléments de base : processus ou sites et voies de communication
Processus 2
Processus 1
Processus 3
page 11
♦ Voies de communication (ou liaison, ou canaux)

• Structures :
• Etoile : un processus particulier • Anneau : chaque processus

peut communiquer avec tous les communique avec ces deux voisins .
autres (hiérarchie).
• Arbre : chaque processus communique avec ses fils et son père

• Maillage complet : chaque processus communique avec tous les processus
Attention : Ne pas confondre la structure du réseau local avec la structure de

communication de l’algorithme distribué.
page 12
♦ Voies de communication :
• Propriétés comportementales : Hypothèses de simplification classiques
• H1 : La transmission sur la voie se fait sans duplication de message.
• H2 : La transmission se fait sans altération des messages.
• H3 : Pour tout couple de processus communicants, l’ordre de réception des

messages est identique à leur ordre d’émission Æ pas de déséquencement.
• H4 : Le délai d’acheminement des messages est fini (bien qu’aléatoire) Æ pas de

perte.
• H5 : Le délai d’acheminement est borné.
page 13
♦ Processus :
• Programme séquentiel, instructions classiques (tanque faire, pour tout ….)
• Réceptifs à des événements (A la réception de « message » faire : …)
• Emetteurs d’événements (envoyer(« message »)).
• Choix non déterministes : si deux événements arrivent en même temps.
• Il existe des langages dédiés : CSP, ADA, PDIL
page 14
♦ Processus : degrès de répartition, niveau de symétrie :
• non symétrie : Texte différent pour chaque processus (client-serveur)
Serveur Client
: :
gère X demander(X)
attendre demande(X) attendre (X)
envoyer(X) à client :
• symétrie de texte : Même texte, mais référençant les processus explicitement Æ chaque
processus peut avoir un comportement dépendant des messages reçus et de son identité
P1 P2
Réception de « message » Réception de « message »
Si a>3 envoyer message à P2 Si a>3 envoyer message à P1
Calculer a Calculer a
page 15
• symétrie forte : Même texte mais ne référençant plus explicitement les processus Æ pour
une même succession de messages, ils ont tous le même comportement.
P1 P2
Réception de X Réception de X
Y := f(X) Y := f(X)
Emettre Y Emettre Y
• symétrie total : Même texte indépendant des messages Æ ils ont tous le même
comportement.
Fourmis1 Fourmis2
Si obstacle : contourner Si obstacle : contourner
Si nourriture : manger Si nourriture : manger
Si prédateur : mourir Si prédateur : mourir
Avancer Avancer
envoyer (position) envoyer (position)
page 16
♦ Qualités d’un algorithme distribué :
• Degrès de répartition : rôle joué par chaque processus Æ niveau de symétrie
• Résistance aux pannes : plus un algorithme distribué est symétrique, plus il

possède une grande résistance aux pannes.
• Hypothèses sur les voies de communication : Moins il y a d’hypothèses, plus

l’algorithme est généralisable.
• Trafic engendré.
• Absence de blocage.
• Détection de terminaison.
page 17
♦ Exemple de deux techniques de distribution
1) Le calcul diffusant (diffusing computation) : très utilisé pour faire des maths.
(2) go ! Processus
feuille
(3) ok !
Processus
(1) go ! noeud (2’) go !
Processus
Processus (4) ok ! (3’) ok ! feuille
racine
(n) ok !
(1’) go !
• Cas simple : accusé de réception = diffusion d’une information

• Cas complexe : chaque processus exécute une partie d’un algorithme
• Structure arborescente, non-symétrie (au moins pour le processus racine), attente.
page 18
1) L’estampillage (Lamport) : cohérence temporelle
A (m2,A,1) B
t=1 t=1->2
A la réception, B met son
horloge à 1 A l émission, B incrémente
son horloge
Estampille = date à laquelle
le message a été envoyé (m3,B,2)
(m1,A,1)
C
C consomme les messages 2 estampilles identiques ?
t=1->3 hiérarchie entre processus
dans l ’ordre de leurs
estampilles ex : (B,2>A,2).
page 19
Développer des algorithmes distribués
- Définir leurs caractéristiques :

- Sécurité : ce qui ne doit pas arriver
- Vivacité : ce qui doit arriver
- Trouver l'algorithme non distribué
- Vue Abstraite
- Pseudo-code
- Trouver l'algorithme distribué

- Vue concrète
- Pseudo code -> code final
page 20
Sécurité versus Vivacité

Sécurité : ce que l'algorithme empêche
Exemple de l'exclusion mutuelle : deux utilisateurs ne peuvent prendre ensemble la
ressource.
Solution possible : ne jamais l'attribuer
Vivacité : ce que doit permettre l'algorithme

Exemple de l'exclusion mutuelle : si un utilisateur veut la ressource et qu'elle est
disponible, il doit l'avoir.
Solution possible : lui donner sans réfléchir
Difficulté : Sécurité + Vivacité .
page 21
Exécution atomique
Algorithme distribué = fonctions atomiques

- Exécutée en section critique / autres fonctions du processus
- non interruptible au sein du processus
- ne laisse pas le temps aux autres fonctions de modifier une variable
- l'arrivée d'un message n'est pris en compte qu'avant ou après son exécution
- plusieurs actions atomiques peuvent être exécutées en parallèle si elles ne font pas
partie du même processus
Fonction particulière interruptible

- Attente d'un événement ou d'un changement d'état provoqué par d'autres fonctions
- Pseudo – code : instruction attendre
page 22
Suite du cours :
Ce qu'on y trouve
- aspect "théorique"
- Compétition
- Synchronisation
- Etat global
- variables et ensembles
- codage "générique"
- pseudo code : instructions envoyer, recevoir, attendre,
tant que , pour, si
-
Ce qu'on n'y trouve pas
- codage "spécifique"
- C : socket thread (signal)
- Adda
- OCCAM : par, seq, ?, !
- Noyaux : OS9,VXWorks
page 23
Bilan de l’introduction :
• Algorithme distribué Æ Communication entre processus.
• Pas de mémoire commune Æ problème de représentation globale du programme
• Distribution des données, des calculs
• Distribution des algorithmes de distribution

- exclusion , élection, synchronisation, surveillance ….
• Algorithmes dépendant de la topologie.
• Systèmes complexes : Besoin de validation (réseaux de Petri, systèmes de transitions,

logique temporelle ..)
page 24
Techniques et Algorithmes des systèmes répartis : Exclusion mutuelle
2. Compétition : l’exclusion mutuelle répartie
page 25
Positionnement du problème
♦ l’objectif :
• Accorder un privilège à un processus parmis n (accès à une ressource non

partageable…).
♦ Problèmes spécifiques :
• Equité (vivacité) : Tout processus ayant besoin de la ressource y aura accès au bout
d’un temps fini Æ absence de blocage.
• Sûreté : A tout instant il y a au plus un processus accédant à la ressource.
• Minimiser les échanges.
page 26
♦ Modélisation du problème grâce aux RdP
Processus 1 Processus 2
demande_1 demande_2
T1 Demande de Demande de
ressource T2
critique_1 critique_2 ressource
Fonctionnement sans dehors_2

besoin de la
ressource : dehors_1
page 27
♦ RdP de la Solution centralisée :
Entre_1 Entre_2
demande_1 demande_2
T1 Demande de
Demande de T2
ressource
critique_1 ressource
/V critique_2
Sort_1
Sort_2
page 28
♦ Implantation Centralisée solution matériel : Verrou et fonction test&set :
Processus i : test&set(V)
Init : V = 0 temp = V
V=1
//Demande_i return(temp)
Attendre jusqu’à ce que reset(V)
test&set(V) = 0 V=0
//Entre_i
<Critique_i>
….
//Sort_i
reset(V)
• Test&set = opération atomique Æ Impossibilité qu’entre consultation et affectation il

y ait une autre consultation, instruction de base d’un µp : échanger(registre,mémoire)
page 29
♦ Echec de cette solution en architecture distribuée

• V ne peut être une variable commune, sa consultation peut prendre du temps
• test&set ne peut plus être atomique
Processus 1 consultation ∆T Processus 2
V modification ∆T
test&set(V)
P1
Section critique
V
consultation modification
P2 ∆T
Section critique
Æ ressource accordée
page 30
♦ Solution basée sur les messages « alternating mutex algorithm »
Message21
demande_1 demande_2
T1 Demande de
Demande de T2
ressource
critique_1 ressource
critique_2
dehors_1 Message12
dehors_2
• Problème : évolution globale, blocage.
page 31
♦ Exemple d’algorithme d’exclusion mutuelle fonctionnant en architecture

distribuée
Repos demande1 demande2 Repos
ReqExt1 ReqExt2
autorise1 autorise2
Silence Silence
equit1 equit2
Attente Attente
critique AcExt1 AcExt2 critique2
• priorité au processus 1 (marquage initial)
page 32
♦ Version pseudo code : autorise_i et req_j sont des flags
//Acquisition de la section critique
si (autorise_i==1)
entrer en section critique
ou (non déterministe)
si (req_j = 1)
autorise_i = 0
envoyer accord(i) //mode
silence
req_j = 0
aller en 2 // réception de Requête(j)
fsi req_j = 1
si (autorise_i==1)
sinon :
2) envoyer requête(i) autorise_i=0
attendre accord(j) envoyer accord(i)
Entrer en section critique req_j = 0
…… fsi
Fin de section critique
autorise_i =1
fsi
page 33
♦ n processus : RdP Colorés
• Couleurs :
<c1>
Repos :
:
<C> demande
C = {<ci>, 1≤i≤n} <cn>
O = {<oi>, 1≤i≤n}
autorisé
Requete
<C> <c1>
silence
f1
• Fonctions de changement f3
<c2>
:
<oi, ci> :
de couleur : <cn>
<C>
f2
f1(<ci>) = <oi> attente1
f2(<oi,cj> )= <cj>
f3(<oi,cj> )= <ci>
critique Accord
page 34
♦ Problème d’équitabilité
• Deux classes d’algorithmes
- Algorithmes fondés sur les permissions
Permissions individuelles
Permission d’arbitre
+ : rapidité
- : compléxité
- Algorithmes fondés sur un jeton

Mouvement perpétuel :
+ : simplicité
- : temps d’attente
Compromis : diffusion du jeton.
page 35
♦ Algorithmes fondés sur les permissions.

Notation : i est un processus ayant besoin de la ressource
Ri est l’ensemble des processus à qui i doit demander la permission
• Permissions individuelles :
P1 demande P5
R1={2} R5={1,2,4}
autorisation ou interdiction
P3 P2 P4
R3={1,5} R2={3,1} R4={1,2,3}
P1 et P5 veulent la section critique Æ exclusion mutuelle car P5 demande à P1 donc P1

ne prendra pas la section critique s’il a autorisé P5.
Sûreté : ∀(i,j) : i∈Rj ou j∈Ri
page 36
• Permissions d’arbitres
P1 P2
R1={3,4} demande R2={1,4,2}
autorisation
P3 P4
R3={2,4} R4={3,1}
P5
R4={2,3}
P1 et P5 veulent la section critique Æ exclusion mutuelle par « l’arbitre » P3, qui ne

l’accordera qu’à l’un des deux.
Sûreté : ∀(i,j) : Rj∩Ri ≠∅
page 37
♦ L’algorithme de Ricart et Agrawala : (permission individuelle)
• Avantage :
• Equité (l’attribution de la ressource commune s’effectue dans l’ordre des demandes)
Variables de chaque site i :
Var étati: {dehors, demande, critique} init à dehors

hi, lasti : entier croissant init à 0.
prioritéi : booléen ;
attendusi, différéi : ensemble de sites init à ∅
hi est une horloge logique, rappel : (h,i)<(k,j) ⇔ (h<k ou (h=k et i<j))

lasti : date de la dernière demande de i
attendusi : liste des sites devant fournir une reponse
différéi : liste des sites mis en attente par i.
page 38
♦ Quatre fonctions atomiques : (sauf la procédure attendre)
Acquérir : Libérer : (sortie de S.Critique)
etati := demande ; etati := dehors ;

hi := hi + 1 ; lasti := hi ; ∀j ∈ différéi : envoyer permission(i) à j ;
attendusi := Ri différéi := ∅
∀j ∈ Ri : envoyer requête(lasti,i) à j ;
attendre(attendusi = ∅) ;
étati := critique ;
Réception de requête(k,j) Réception de permission(j)

♦
♦ hi := max(hi, k) ; attendui := attendusi-{j}
prioritéi := (étati≠dehors) et (lasti,i)<(k,j) ;
♦ si prioritéi alors différéi := différéi∪{j}
sinon envoyer permission(i) à j
fsi ;
page 39
♦ sûreté de l’algorithme de Ricart et Agrawala

• Deux processus i et j peuvent-ils être en section critique.
• Pour cela, deux messages requête(h,i) et requête(h,j) ont été envoyé et deux messages
permission(i) et permission(j) ont été reçu.
• Cas 1) envoi d’une permission suivie d’une requête (processus j)

étati=demande
lasti=h k>lasti⇒(lasti,i)<(k,j)
i
Permission refusée
2 2
11>2
requête(h,i) 11
permission(j) requête(k,j)
k=hj ⇒ k>h
j
10 dehors 10 11
hj≥h lastj>hj
page 40
• Cas 2) envoi « simultané » de 2 requêtes
test2 :
étati=demande
(h,i)<(k,j)
i hi=h
lasti=h
requête(h,i)
requête(k,j)
lastj=k
j
hj=k test1 :
étatj=demande (k,j)<(h,i)
(test1= ¬ test2)⇒une seule permission accordée
page 41
♦ Vivacité de l’algorithme de Ricart et Agrawala
• Chaque requête possède une estampille distincte

• La requête d’estampille la plus faible sera toujours accordée
• Tout processus rentrant en section critique en sort au bout d’un temps fini
⇒ Vivacité assurée
♦ Trafic :
• Nb messages :
Une utilisation de la section critique requiert 2(n-1) messages
• Temps :
Si la section critique n’est pas utilisée, il faudra attendre 2T pour qu’un processus
puisse l’acquérir. T = temps de transfert d’un message.
Si elle est utilisée, il faudra attendre T, une fois sa libération effectuée (temps de
transfert du message d’autorisation)
page 42
♦ Robustesse vis-à-vis du déséquencement :
• Cas critique : déséquencement des permissions
Cqs où hi>hj (i prioritaire)
hi=α critique
i
permission(j)
requête(α+1,i) requête(α+1,i)
permission(j)
requête(β+1,j)
j
hj=β Jusqu’à ce que hi>lastj
hj=β+1
lastj=β+1
page 43
♦ Structure des liaisons
• maillage complet bi-directionnel.

• peut s’adapter à d’autres structures, au détriment d’un surplus de trafic. Exemple :
structure en anneau : n(n+1)/2 messages pour une utilisation de la section critique.
♦ Possibilité d’optimisation
• Si l’on connaît δ, temps de transfert maximum entre deux sites.
- Ne pas envoyer de permission positive.

- Envoyer un refus de permission, suivi d’une permission une fois la section libérée.
- Attendre un refus de permission durant 2δ, puis considérer que celle-ci est acquise.
toutes les permissions sont accordées : nb de messages pour 1 utilisation = n-1

aucune permission accordées : nb de messages pour 1 utilisation = 3(n-1)
Æ interessant si δ petit
page 44
♦ Problème des horloges non bornées :
• La valeur d’une variable informatique ne peut croître indéfiniement.
Æ les horloges possèdent un « modulo ».
• Comparaison d’horloges finies modulo 8 :
hi 1 2 3 4 5 6 7 8 1 2
hj 1 1 1 1 1 1 1 2 2 2
comparaison = > > > > > > > < =
• L’algorithme est perdu car hj est en réalité toujours < hi
page 45
♦ Problème des horloges non bornées

• Connaissance de l’écart Max entre 2 horloges, exemple ±2 :
hi 0 1 2 3 3 3 4 4 5
hj 0 0 1 2 3 4 5 6 7
comparaison = > > > = < < < <
• Les horloges peuvent être implantées modulo 4 :
hi 0 1 2 3 3 3 0 0 1
hj 0 0 1 2 3 0 1 2 3
comparaison = > > > = < < < <
Avec : 1>0 ; 2>0 ; 2>1 ; 3>1 ; 3>2 ;

Mais : 0>2 ; 0> 3 ; 1>3 ; 1>0 ;
page 46
♦ Borne des Horloges de l’algorithme de Ricart et Agrawala
• Constat : Il ne peut y avoir deux requêtes successives par un processus sans qu’il n’ait
reçu une permission.
hi
0 1
req(i,1)
Permission(j)
hj
0 1 2
req(j,2)
Cas extrème : tous les processus en attente
d’autorisation : horloges bloquées !
hk req(k,3)
0 2
Pour n processus :
• Il y a au maximum un écart de (n-1) entre la requête et l’autorisation
• Il y a au maximum un écart de (n-1) entre deux requêtes
⇒ La différence entre 2 horloges logiques est de ±(n-1) ⇒ modulo = 2(n-1)
page 47
♦ Algorithmes similaires :
Carvalho et Roucairol :
Si un site veut la section critique plusieurs fois de suite, alors qu’aucun site ne l’a
demandé, il n’est pas obligé de faire plusieurs requêtes.
Adaptatif : les sites peuvent se déclarer consommateurs ou non consommateurs
potentiels de la ressource durant l’évolution de l’algorithme (l’ensemble Ri évolue dans
le temps).
Les horloges ne peuvent plus être bornées.
Chandy et Misra : Adaptatif,

Variables bornées,
L’identité des sites n’est plus utilisée,
Algorithmes à permission d’arbitres
page 48
Algorithmes fondés sur l’unicité d’un jeton
♦ Algorithme de Le Lann (mouvement perpetuel)
• Le jeton tourne indéfiniment de processus en processus.
• Un processus demandeur porteur du jeton utilise la ressource commune avant de
rendre celui-ci.
Processus i jeton Processus j Processus k
• Simple.
• Trafic inutile
• Si la section critique n’est pas utilisée il faudra attendre jusqu’à (n-1)T pour qu’un
processus puisse l’acquérir Æ LENT ! !
page 49
♦ Algorithme à diffusion (le jeton est distribué au demandeur)
Processus j
tab
requête(i)
Processus i i 1
tab
j 0 k 1
Processus k jeton
k 1 tab i j k
requête(i)
i 1->2 1 2 1
j 2
• Un processus demandeur lance une requête.
• Le jeton possède l’info « combien de fois ai-je été consommé par Pn ».
• Chaque processus compte le nombre de requêtes reçues des autres processus.
• un processus p est demandeur si
jeton[p] < tab[p] (le jeton est alors envoyé à p)
page 50
♦ Algorithme à diffusion (suite).
• Pas de blocage
• Vivacité : Possibilités de famine : toujours les mêmes servis.
Solution : chaque processus opère ses tests dans un ordre différent,

Exemple : chaque processus i effectue ses tests dans l’ordre i+1, i+2 …n, 1, ..i-1
• Nombre de messages pour une utilisation de la section critique : de 0 à n.
• Delai durant lequel la section critique est inutilisée alors qu’elle est demandée :
0 à 2T
page 51
♦ Répartition d’un sémaphore :
• Rappel : Sémaphore centralisé : partage de n ressources
Processus1 Processus2 Processusj

P(S) ;
Utiliser ressource ;
V(S) P(S),
P(S), V(S)
P(S), V(S)
V(S)
Sémaphore S
P(S) : attendre (S>0) ; V(S) : S=S+1

S=S-1
page 52
♦ Sémaphore distribué : principe

• P(S) doit être exécuté en section critique Æ exclusion mutuelle.
• V(S) n’est pas critique, S doit être distribué (jeton).
Processus 1 Processus 2 Processus n

nbVs1 nbVs2 jeton nbVsn
P(S) incr P(S) P(S) Jeton :
V(S) V(S) V(S) nbPs
incr
S = #V(S) - #P(S) + S0, (#P ≈ nb exécution de P, S0≈ nb ressources)
distribué
attendre (S>0) P(S) : acquérir jeton V(S) : envoyer incr
≈ attendre (nbPs<S0 + nbVi) ;
#P(S) < S0 + #V(S) nbPs=nbPs+1
libérer jeton Réception incr :
nbPS nbVSi nbVi = nbVi+1
page 53
• Sûreté : nbVsi ≤ #V(S) et nbPs = #P(S )
Donc :
(nbPs<(S0 + nbVi)) ⇒ (#P(S) < (S0 + #V(S)).
Le test est sûr vis-à-vis d’un sémaphore centralisé
• Vivacité : dépend de l’algorithme de déplacement du jeton gérant l’exclusion mutuelle

d’accès à P(S).
• Trafic Important (trafic de l’algorithme d’exclusion mutuelle lié à P + trafic lié à V)
Æ Les sémaphores répartis ne sont intéressants que lorsqu’une simple exclusion

mutuelle ne suffit pas.
page 54
Problèmes plus complexes :
♦ Lecteurs-écrivains réparti
• Exclusion mutuelle à deux types d’opérations « lire » et « écrire » dotée de règles

d’exclusions spécifiques.
Æ Adaptation des algorithmes d’exclusion mutuelle répartie
page 55
Problèmes plus complexes :
♦ Allocation répartie de ressources
Processus 1 : Processus 2 : Processus n :

: : :
1 requérir R1 3 requérir R2
: :
2 requérir R2 4 requérir R1
: :
libérer R1 libérer R1
: :
libérer R2 libérer R2
• Problème spécifique : l’interblocage : Scénario : 1Æ3Æ ?
• Solutions :
- demande incrémentale
- demande simultanée
page 56
♦ Demande incrémentale :
Hiérarchie des ressources R0<R1<R2….
Un site ne peut demander une ressource Ri que s’il a déjà obtenu toutes les
ressources (dont il a besoin durant la session), qui sont inférieures à Ri.
Chaque ressource gère une file d’attente fifo des sites qui la réclament.
Le chemin 1Æ3Æ….. n’est plus possible !
Simple, mais peu performant (beaucoup d’attente).
page 57
♦ Demande simultanée : principe
Estampillage des messages de requête avec horloge logique (exclusion mutuelle de
Ricart et Agrawala)
• Cas pour une ressource en M exemplaires, utilisée ki fois par chaque processus i.
Processus 1 Processus 2 Processus 3

Utilisé1 Utilisé2 Utilisé3
P2 P3 P1 P3 P1 P2
M M M M M M
requête(h,1)
Différé{} Différé{} Différé{1}
requête(h,1) Prioritaire : libre(3,M-k3)

Pas interessé : libre(3,M)
Ou pas prioritaire Injection de 1 dans différé,
et envoie de libre(3,M) à 1
suite à la libération des
• M - ∑utiliséi[j] ≥ki Æ consommation des ki ressources ressources
• Lors d’un envoi de requête, utiliséi[j] := M (pire des cas)
• Lors d’une réception de libre(j, N), utiliséi[j]=utiliséi[j]-N
• Généralisation possible à plusieurs types de ressources
page 58
Informatique Répartie : Synchronisation répartie
3. Coordination : La synchronisation répartie
page 59
Coordination par rendez-vous
♦ Un rendez-vous multiple r = {i,j,k}
Invoquer r temps
Processus i
Invoquer r Rendez
Processus j -
Vous.
Invoquer r
Processus k
page 60
♦ Choix non déterministe entre plusieurs rendez-vous
Invoquer r1 ou r2
Processus i
Invoquer r1 ou r4 Rendez
Processus j -
Vous temps
Invoquer r3 ou r1
Processus k r1
♦ Problèmes spécifiques :
• Coordination synchrone : si un processus s’engage dans un rendez-vous, tous les
processus concernés doivent s’y engager.
• Exclusion : un processus ne peut être que dans un rendez-vous à la fois.
page 61
♦ Principe de la solution pour un rendez-vous : Sémaphores privés.
Processus j Processus i Processus k
Sj = 1 V(Sj) Si = 0 V(Sk) Sk = 1
• Si un processus i veut prendre le rendez-vous, il incrémente le sémaphore des autres

sites : ∀x ∈ r , x≠i : V(Sx).
• Un processus i peut entrer en rendez-vous, s’il a pu décrémenter Card{r}-1 fois son

propre sémaphore :
faire Card{r}-1 fois P(Si)
entrer en rendez-vous
page 62
♦ Principe de la solution centralisée pour n rendez-vous demandés

simultanément
• wi : nombre de fois où i a été demandeur

• ni : nombre de fois où i est entré en rendez-vous
• invariants : chaque processus ne s’engage que dans un rendez-vous à la fois

∀i : ni ≤ wi ≤ni+1
un rendez-vous rj ne peut avoir lieu que si tous les sites sont prêts
∀rj : (∀i ∈rj : wi = ni +1) ⇔ rj peut avoir lieu.
Processus controleur prêt(i) Processus i

wi=1 r1{i,j} ok(r1)
ni=0 r2{j,k} Processus j
wj=1 r3{i,j,k}
nj=0 prêt(j)
wk=0 Processus k
nk=0
page 63
♦ Principe de la solution distribuée pour n rendez-vous demandés
simultanément
Processus i Processus j Processus k

ni=0 ; wi=1 ; ctl_par{z,x} nj=0 ; wj=1 ; ctl_par{x,y,z} nk=0 ; wk=1 ; ctl_par{z,y}
ok(r1) prêt(i) prêt(i)
Processus controleur x
Processus controleur z rdv ctl x{…….} Sens des modifications
rdv_ctl_z{r1{i,j},{r2{i,k}} Jeton{nx(i)=…, wi=1Æreq(i)Ænbreqn(i)

proc_ctl_z{i,j,k}
Circulation nx(j)=…,nx(k)=…}
nbreqz(i)=1 jeton (mutex) nx(i) Æok(rl)Æn(i)
nbreqz(j)=1
nbreqz(k)=0 Processus controleur y
nx(i) : nombre de
fois où OK(r…) a
• Le jeton assure l’exclusion mutuelle des contrôleurs été envoyé à i
• Quand un contrôleur envoie ok(rj), il incrément nx(j)
page 64
Coordination par maintien d’un invariant

♦ Exemple d’invariant
• Producteurs consommateurs :
#autorisation(produire) - #terminer(consommer)≤k (taille du buffer)
#autorisation(consommer) - #terminer(produire) ≤ 0
m
• Cas général, Synchronisation : ∑ α i .xi < k (αi = constantes)
i =1
• Pour maintenir un invariant, les processus doivent évaluer une condition avant de
modifier une des variables de l’invariant. (avant de produire, il faut vérifier qu’il y a
de la place dans le buffer)
• Problème spécifiques :
• Sûreté : si la condition est fausse, aucun processus ne peut l’évaluer à
vraie
• Vivacité : Si une condition est vraie, tous les sites doivent la voir vraie au
bout d’un temps fini.
page 65
♦ Cas des variables liées à un processus :
• xi, xj et xk sont des compteurs à évolution monotone et croissante
• Vue abstraite, Conditions Abstraites
Processus i Processus j Processus k
Condition : Condition : Condition :

xi-xj-xk<k xj-xi-xk<k xk-xj-xi<k
xi xj xk
page 66
♦ Minorants et mise à jour retardée : condition de type « mk(xi) ≥ valeur »
Condition Concrète (xi≥ valeur ) ⇒ Condition Abstraite (mk(xi) ≥ valeur)
• Vue Concrète :
Processus j
Processus i Processus k
xj
Condition :
mk(xj)
mi(xj) xk-mk(xi)-mk(xj)<k
xi, mi(xj), mi(xk) xk, mk(xi), mk(xj)
mn(xm)≤ xm Æ MajR
• Sûreté :
xk-mk(xi)-mk(xj) <k ⇒xk-xi-xj<k
page 67
♦ Majorant et mises à jour anticipées : condition de type « Mk(xi) ≤ valeur »
Vue abstraite : Vue concrète :

i i
xi+xj-xg<k xi+Mi(xj)-mi(xg)<k
xi xi
• Si Mi(xj)≤xj alors (Condition Concrète ⇒ Condition Abstraite)

• Il faut au contraire que Mi(xj) ≥ xj Æ MajA
xi+Mi(xj)-mi(xg) < k
xj ≤Mi(xj), MajA
⇒ xi+xj-xg<k
xg≥mi(xg) MajR
page 68
♦ Mise à jour anticipée : implantation
j inc(j,n) i
……..
…….. reception(inc(j,n))
ok
envoyer(inc(j,n)) Mi(xj)= Mi(xj)+n
attente(ok) envoyer(ok)
xj = xj+n
• Possibilité de blocage Æ si l’incrémentation de xi est dépendante de Mi(xj)<k)

Algorithmes spécialisés limitant le crédit n.
♦ Compteur à évolution quelconque

• On décompose l’évolution d’un tel compteur par le biais de deux compteurs (un
compteur d’incrémentation et un compteur de décrémentation). Les algorithmes
précédent sont ensuite utilisables.
page 69
♦ Variables non liées à un site
• Exemple : vue abstraite de la gestion d’un parking
Entrée/sortie1 Entrée/sortie2 Entrée/sortie2
Entrée : e=e+1 Entrée : e=e+1 Entrée : e=e+1

Sortie : s=s+1 Sortie : s=s+1 Sortie : s=s+1
• Invariant à maintenir : e≤s+p (capacitée du parking)
• Avant d’autoriser une entrée, un processus vérifie que e<s+p
page 70
♦ Technique d’éclatement
• Chaque site i transmet sa valeur ei et si
• (MajR pour si et MajA pour ei)
• Vue Concrète :
Entrée/sortie2
e= ∑ ei
i
s= ∑ si
i
e3, s3
Entrée/sortie1 e1, s1 e2,s2 Entrée/sortie3
e= ∑ ei e= ∑ ei
i
e2, s2 e2, s2
e3, s3 i
s= ∑ si s= ∑ si
i
e1, s1 i
e1,s1
e3,s3
• Problème : beaucoup de messages
page 71
♦ Partitionnement et contrôle isarithmique :
• Chaque processus i gère une partie des places pi.

• Avant d’autoriser une entrée, un processus vérifie que ei<si+pi
p=∑pi
Entrée/sortie1 Entrée/sortie2
Trop de place
Crédit(n)
p1=p1+n p2=p2-n
e1,s1,p1 e2,s2,p2
• Blocage si les voitures arrivent « par un processus » et partent « par un autre ».

solution Æ Chaque pi évolu dynamiquement à l’aide de messages de crédits, en
fonction d’un seuil, afin d’éviter les blocages.
page 72
Coordination par construction d’un temps virtuel

♦ Objectif :
• Avoir une base de temps permettant de faire abstraction des problèmes liés aux temps
de transit des messages.
• Implanter des algorithmes distribués comme si le système était global.
♦ Exemple : exy sont des « événements » devant être partagés par deux processus Pi et Pj.
ei1 ei2
Pi t
ej1 ej2
Pj t
• En non réparti, les deux processus verraient ei1, ej1, ej2, ei2.
page 73
♦ Horloge virtuelle
• principe : l’émetteur d’un message précise la date virtuelle à laquelle celui-ci doit
arriver (m,t).
• Le récepteur connaît la date virtuelle à laquelle est arrivé le message.
• Problème à résoudre :
Gestion de l’évolution de l’horloge virtuelle
La cohérence temporelle (sûreté)

• Tous les processus ont la même perception de l’horloge virtuelle
• Un message estampillé à la date z doit être consommé à la date z
La vivacité
• Si du point de vu d’un processus, le temps virtuel peut progresser, il
progressera.
page 74
♦ Solution centralisée
• Un processus maître gère l’horloge virtuel hv

• Les autres processus des dates de réception des messages envoyés
Processus maitre Processus n

hv Message emis devant
être recu a… Si hv=h, alors consommer mi
….
hv = i hv Tampon
d’attente
(mi,h)
hv (mj,k)
• beaucoup de messages, processus souvent en attente (diminution du parallélisme),

faible répartition.
page 75
♦ Solution décentralisée :
• Chaque processus possède une image de l’horloge virtuelle
• Quand un message est consommé, le processus récepteur met son horloge à jour.
Pi Pj
(m,k+d)
Pz
hvi = k hvj = …
Problème d’interblocage :
• Le processus j doit-il consommer le message (m,k+d), ou existe-t-il un message
arrivant de z à une date inférieure. J est bloqué et se met en attente.
• z, peut être dans le même cas, à cause d’autres processus : interblocage.
page 76
♦ Méthode pessimiste de Chandy et Misra
• Quand un processus n envoi un message (m,y) à un processus p, il envoi également un

message (null,y) aux autres processus.
• Lorsqu’un processus j reçoit (null,y) d’un processus z, il sait que ce dernier ne lui
enverra pas de message avant y.
• Chaque processus connaît donc la date minimum à partir de laquelle chacun des
processus entrant peut lui transmettre un message. Il est donc capable de décider du
prochain message à accepter et de la valeur de son hv.
Pi Pj Pz
hvi = 5 hvj = 4Æ6 (m,7)
(m,6) (null,7) hvz = 6
i :6
z :7
• Ici : Si Pj ne possède que deux liaisons entrantes (en provenance de Pi et de Pz), il
peut consommer (m,6) et positionner hvj à 6.
page 77
♦ Interblocage et méthode pessimiste :
• Pk peut recevoir des messages de Pj qui peut en recevoir de Pk
(null,5)
Pi (m2,10) Pj Pk (m1,5) Pz
i:2
j:5
1) k envoi (m1,5) à z, (null,5) à j.
2) j reçoit (m2,10), il consomme (null,5) et met hvj = 5.
3) j met (m2,10) en attente car il attend le prochain message de k (pour faire un
choix).
4) k attend un message de j (qui est en attente de k), conditionnant le prochain
message qu’il enverra Æ Interblocage.
page 78
♦ Méthode pessimiste et anticipation.
• A la réception de (null,y), un processus sachant (par anticipation) qu’il n’enverra rien

avant y+δ, envoi sur toute ses liaisons (null, y+δ)
i 1) k envoi (m1,5) à l et (null,5) à j.

(m2,10) 2) j sait que k ne lui enverra pas de message avant 5 (hvj = 5).
3) j recoit (m2,10).
j
4) j sait qu’il n’enverra rien avant δ.
(null, 5+δ) (null, 5), 5) j envoi (null,5+δ) à k
(null, 5+δ’)
k 6) k sait qu’il n’enverra rien avant 5+δ’
(m1, 5) 7) k envoi (null,5+δ’) à j
(null, 5+δ’) 8) 5+δ’’…>10Æ j accepte (m2,10) Æ Plus d’interblocage
l
page 79
♦ Méthode optimiste de Jefferson

• Principe :
Elaboration d’une sauvegarde des états locaux des processus : ensemble

des valeurs des variables du processus à un instant donné.
Une sauvegarde des messages émis et reçus.
Une prise en compte immédiate d’un message (m,hv) dès qu’il arrive.
Si un message (m’,hv’) arrive avec hv’<hv : Exécution d’un retour arrière
de l’évolution du processus :
Recalage de l’état du processus sur l’état sauvegardé précédent ou

égal à hv’
Annulation des messages émis depuis hv’, par l’envoi d’un anti
message.
La réception de l’anti-message d’un message déjà consommé provoque un
retour arrière du récepteur à la date du message.
page 80
♦ Exemple :
Sauvegarde i10
Pi hvi
10 12 (m,13) 14 15
(m’,14) Retour arrière

Vers j9
Pj hvj
9 10 13
Sauvegarde j9 Sauvegarde j13 (m’’,12)
Retour arrière
Vers i10
Pi hvi Compromis # sauvegarde ↔ précision
15 10
anti(m,13) des décalage (temps)
anti(m’,14) Quelles sauvegardes peuvent être

Pj hvj effacées ?
9
page 81
♦ Temps Virtuel Global (GVT)
Le GVT est la borne inférieure sur les dates de retour arrière possibles.
GVT = min({hvi : 1≤i≤n}∪{t : un message (m,t) est en transit}
Le GVT est calculé à l’aide d’un algorithme réparti d’observation (chapitre suivant)
page 82
Informatique Répartie : Observation et état global
4. Observation et état global
page 83
Détection répartie de la terminaison
♦ Objectif :
• Savoir si une application répartie est terminée, sans faire aucune hypothèse sur la
structure ou l’organisation de celle-ci (surveillance d’un calcul)
♦ Sûreté :
• Si l’observation indique que le calcul est terminé, alors le calcul est effectivement
terminé
♦ Vivacité :
• Si le calcul se termine, alors l’algorithme de détection annoncera sa terminaison au bout
d’un temps fini.
page 84
♦ Principe :
• Un processus doit être « actif » pour envoyer des messages
• Un processus dans l’état actif peut passer dans l’état passif (fin d’un sous-calcul)
• Lorsqu’un processus dans l’état passif reçoit un message, il repasse dans l’état actif.
⇒ Le calcul global est terminé si tous les processus sont inactifs et qu’il n’y a aucun
message en circulation
page 85
♦ L’algorithme de quatre compteurs
• Hypothèse d’un modèle atomique :
• les temps de calcul sont infiniment courts

• Seules les communications prennent du temps
Æ Un calcul est terminé si ∑messages émis = ∑messages reçus
• 2 Compteurs associés à chaque processus i :
ei : nombre de messages émis par i

ri : nombre de messages reçus par i
• Un processus particulier demande la valeur des compteurs aux autres processus.
page 86
♦ Pourquoi 2 compteurs ne suffisent pas :

1
temps-réel
t3 t2 t1
Vague de consultation
e1 (t1 ) = 0, e2(t 2 ) = 1, e3 (t 3 ) = 0 ⎫
⎬ E = ∑ ei (ti ) = R = ∑ ri (ti )
r1 (t1 ) = 1, r2 (t 2 ) = 0, r3 (t 3 ) = 0 ⎭ i i
ei(tj) = valeur de ei renvoyépar i au temps tj
page 87
♦ Solution : 2 Vagues de consultation (E1,R1) et (E2, R2)

R1 = E2 ⇒ terminaison
♦ preuve :
définitions : di et fi ≡ début (fin de la vague i)
R(t), E(t) ≡ Nombre de messages reçus (émis) au temps t.
Faits : Démonstration :
1 : d1<f1<d2<f2 Si R1=E2
2 : ei(t) ≤ ei(t’) et ri(t) ≤ ri(t’) ∀t ≤ t’ Alors E2 ≤ R(f1) (4)
2 : E(t) ≤ E(t’) et R(t) ≤ R(t’) ∀t ≤ t’ Donc E(d2) ≤ R(f1) (4+5)
3 : R(t) ≤ E(t) ∀t Si E(d2) ≤ R(f1)
4 : R1 ≤ R(f1) Alors E(f1) ≤ R(f1) (car E(f1)≤E(d2)) (1+2)
5 : E(d2) ≤ E2
Or E(f1)≥ R(f1)
Donc E(f1) = R(f1)
Il n’y avait plus de messages en court à la fin de la 1er vague
page 88
♦ Algorithme général :
• Plus d’hypothèses sur le temps de calcul des processus, ni sur les caractéristiques des
liaisons.
♦ Structure de la solution :
Prédicats :
vide(i,j) ≡ la liaison entre i et j est vide
passi = (étati = passif) et ( ∧

j∈voi sin de i
vide(i,j))
≡ i est passif et tous les messages qu’il a envoyé ont été reçus.
term = ∧i passi ≡ le calcul est terminé
page 89
Détection répartie de l’interblocage
♦ Objectif :
• Savoir si plusieurs processus « s’inter-bloquent » lors d’un calcul plutôt que d’éviter
l’interblocage (les méthodes pessimistes sont souvent trop restrictives)
♦ Sûreté :
• Si l’algorithme de contrôle annonce qu’il y a interblocage, celui-ci est effectif.
♦ Vivacité :
• Si un interblocage existe, il doit être détecté en un temps fini
♦ Difficulté particulière :
• Seul un sous groupe des processus gérant un calcul peuvent être concernés par un
interblocage
• Il est souhaitable qu’un seul processus détecte l’interblocage
page 90
♦ Interblocage sur allocation de ressource
• p1 attend une ressource de p2 qui attend p3 qui attend p1
2 3
Graphe des processus en attente
• Détecter un interblocage revient à détecter une boucle dans le graphe des processus en
attente.
page 91
♦ Interblocage sur communications

• p1 attend un message de p2 ou de p3 ou de p4 ….
• p2 attend un message de p4 ou de p3
plus d’interblocage
4
3
2
• détecter un interblocage revient à détecter :

1) que le graphe des attente est une composante fortement connexe
2) qu’il n’y a aucun message en transit entre les processus du graphe
page 92
♦ Algorithme de Mitchell et Merrit
• Interblocage par allocation
Principe :
• Au moment d’un blocage, une valeur unique est calculée par le processus bloqué
• Cette valeur se propage par consultation/mise à jour des processus bloqués
• Si un processus bloqué constate que le processus bloquant possède la valeur

qu’il a lui même calculé, c’est qu’il y a interblocage
page 93
♦ Mise en œuvre
• Chaque processus i possède : une étiquette privi, une étiquette pubi
• L’opérateur sup(pubi, pubj) renvoi une valeur supérieure à pubi et pubj
R1 : règle de blocage
Lorsque le processus i se bloque en attente d’une ressource possédée par le site j, il
redéfinit ses étiquettes : pubi = privi = sup(pubi, pubj)
R2 : Règle de propagation
Lorsque i est bloqué par j, il consulte régulièrement la valeur de pubj et effectue :
si pubi<pubj alors pubi = pubj fsi
R3 : Règle d’activation
Lorsque j libère une ressource demandée par i,k,… celle-ci est allouée à l’un d’entre eux.
Les autres processus sont désormais bloqués par celui qui a été choisi et appliquent la règle
R1 avec lui.
R4 : Règle de détection
Si suite à la règle R2, un site i bloqué par j constate pubi = privi = pubj ⇒ il est sur un
circuit et il est le seul à le savoir.
page 94
♦ Algorithme de Chandy, Missa et Haas
• Interblocage par communication : détection d’une composante fortement connexe.
Diffusion d’un message « question(i,j) »
question(1,4)
4
0 question(0,1) 1
question(1,3) Graphe des
3 processus en attente
2
• Un processus recevant 2 fois « question() » fait parti d’une boucle
• Si tous les processus « fils » d’un processus donné font parti d’une boucle, il existe une
composante fortement connexe.
page 95
♦ Formalisation
ens_depi = ensemble des processus dont i est en attente
le processus cherchant à savoir s’il est en interblocage est k
R1 : lancer un parcourt
∀j∈ens_depk : envoyer question(k,j)
rep_attk = card(ens_depk) R3 : lors de la reception de réponse(j,i)
rep_atti = rep_atti-1
si rep_atti = 0 alors
R2 : lors de la reception de question(j,i) cas i≠ k → envoyer réponse(i,pèrei)
si non déjavisitéi alors i=k → le parcours est terminé
déjàvisitéi = vrai, pèrei=j fcas
∀r ∈ens_depi : envoyer question(i,r) à r fsi
rep_atti = card(ens_depi)
sinon envoyer réponse(i,j) à j
fsi
page 96
♦ Exemple d’exécution : j
1) pas d’interblocage : l
i
k
i♦
Rep_atti=2
question(i,j)
j
question(i,k) reponsel(k,i)
question(k,l) question(l,k) reponsel(k,l) reponsel(l,k)
l
page 97
Exemple d’exécution :
2) interblocage : j
♦ l
i
k
Rep_atti=2
i
question(i,j) reponsel(j,i)
question(i,k) reponsel(k,j) reponsel(k,i)

question(j,k)
k
question(k,l) question(l,k) reponsel(k,l) reponsel(l,k)
l
page 98
Problème de cohérence :
• Durant la recherche de l’interblocage, les processus continus à évoluer Æ le graphe des

processus en attente évolue durant la recherche de l’interblocage.
♦ Solution :
• Introduction d’une variable cont_passifi pour chaque processus
• cont_passifi ≡ le processus n’est pas repassé à l’état actif depuis la première réception
de « question ».
• Un processus ne revoit réponse que si cont_passifi est à vrai.
page 99
Calcul d’états globaux :

♦ Objectif :
• Surveiller l’évolution d’un calcul réparti
♦ Etat local d’un processus i : eli

• où en est le processus (variables locales) ?
• qu’a-t-il envoyé ?
♦ Etat global :
• Somme des états locaux
♦ Etat global cohérent :

• Etat global tel que tout message reçu par un processus est bien vu comme émis par un
autre. Tout message émis et non reçu est connu.
page 100
♦ Calcul d’états globaux :
m1
eli elj
• à l’état local eli , i a émis m1

• à l’état local elj, j à reçu m1 Æ EG = eli∪elj ≡ état global cohérent
• On pourrait stopper le calcul, mémoriser (eli et elj) et reprendre le même calcul

ultérieurement sans perte d’information.
page 101
m1
eli elj
eli∪elj ≡ incohérent
• Si (eli et elj) constituaient un point de reprise, m1 serait perdu.

⎧⎪ ⎫⎪
Æ EG = ⎨U eli, U ecij ⎬ , avec ecij ≡ messages en cours dans le canal iÆj
⎪⎩ i (i , j ) ⎪⎭
page 102
m1
eli elj
• Problème : On ne doit pas mémoriser m1 avec (elj, eli) car il n’a pas été émis en eli.
Mais elj tient compte de la réception de m1.
page 103
♦ Définitions préliminaires :
⎧⎪ ⎫⎪
• état global EG = ⎨U eli, U ecij ⎬
⎪⎩ i (i , j ) ⎪⎭
• cohérent(eli, elj, ecij) ≡ ∀ message m : (émission de m captée dans eli) ⇔ (réception de

m captée dans elj) où m∈ ecij.
• Etat global cohérent

⎧⎪ ⎫⎪
EG = ⎨U eli, U ecij tels que ∀(i, j ) : cohérent (eli, elj , ecij )⎬
⎪⎩ i (i , j ) ⎪⎭
page 104
♦ Algorithme pour les canaux FIFO :
• gestion d’une date logique d de définition d’un état global.
• d est transmise sur les canaux de sortie d’un processus i effectuant une mémorisation eli,
à l’aide d’un message particulier « marqueur »
elj
marqueur
page 105
♦ Algorithme pour les canaux FIFO
• Lorsque le marqueur est reçu par un processus j
marqueur
j
• 1) soit j n’était pas à la date d, il s’y met : mémorisation de elj et transmission du

marqueur sur ses canaux de sortie. j sait qu’il a reçu tous les messages précédents d
(canaux fifo) ⇒ecji = ∅. Cohérent(elj,eli, ∅).
• 2) soit j était déjà à la date d :

• il a déjà mémorisé elj (à cause d’un autre processus). Les canaux étant fifo, les messages
émis par i avant d et reçu par j après d, sont ceux reçus entre la mémorisation elj et la
réception du marqueur.
)
page 106
♦ Exemple :
elj
j
d- d
m3
marqueur marqueur
eli
i
d- d
m1 m2
marqueur
k
d- elk d
cohérent(elj, eli, m1)

Bibliographie :
page 107
Attiya Hagit and Welch Jennifer, « Distributed Computing, Fundamentals, Simulations and
Advanced Topics », Mc Graw Hill editor, 1998.
Hamilton John et al, « Distributed Simulation », CRC Press Computer Engineering Series,
1997.
Raynal Michel, « Synchronisation et état global dans les systèmes répartis » Eyrolles,
1992.
Raynal Michel, « La communication et le temps dans les réseaux et les systèmes répartis »,
Eyrolles, 1991.
Raynal Michel, « Gestion des données réparties : problèmes et protocoles », Eyrolles,

1992.
Helary Jean-Michel and Raynal Michel, « Synchronization and Control of Distributed

Systems and Programs », WILEY 1990.
page 108
page 109
Algorithme pour les canaux FIFO :

♦
page 110
page 111
•
♦ Solution 2 : « state testing mutex algorithm »
Pas_équit1 Pas_équit2
demande_1 demande 2
T1 Demande de
Demande de T2
ressource critique 1
critique 2 ressource
dehors 1 Noncrit 1 Noncrit 2 dehors 2
page 112
Graphe des attentes : quand y a-t-il interblocage ?
page 113
• Nœud = processus P1
• Arc = « est bloqué par

P2
• Interblocage = boucle
P3
♦ Cas simples :
• M ressources identiques requête de 1 parmis M, de k parmis M

Utilisation d’un sémaphore distribué (peu performant)
Adaptation des algorithmes d’exclusion mutuelle .
♦ Cas général : plusieurs ressources en exemplaire unique
page 114
• Demande incrémentale :
Hiérarchie des ressources R0<R1<R2….
Un site ne peut demander une ressource Ri que s’il a déjà obtenu toutes les
ressources (dont il a besoin durant la session), qui sont inférieures à Ri.
Chaque ressource gère une file d’attente fifo des sites qui la réclament.
Problème principal : la vivacité

L’algorithme de Le Lann
L’algorithme à diffusion
Equité locale =
page 115

Equité globale = tous les processus pourront accéder à la section critique
au bout d’un temps fini
Echange par message/ par consultation
Jamais de modification d’une variable d’un processus par un autre

Jamais deux consultations possibles d’une même variable (incohérence)
page 116
Solution 4 : « token-passing mutex algorithm » : passage d’un jeton dans

autorise x, par Reqx et Acx.
Repos demande1 demande2 Repos
ReqExt1 ReqExt2
autorise1 autorise2
Silence Silence
equit1 equit2
Attente Attente
critique AcExt1 AcExt2 critique2

Passage explicite de l’info de requête, pas de problème d’implantation
page 117
Concepts et Techniques de l’algorithmique distribuée

♦ La mise en œuvre des algorithmes distribués est peu “ formalisée ” Æ pas
de recette miracle. Deux orientations :
• 1. La recherche d’invariants : On est sûr que ça marchera si les processus font des
opérations dans un ordre donné, alors on “ force ” cet ordre Æ pas optimal mais sûr
(bon par construction), principe de l’algorithmique séquentielle.
• 2. Approche empirique : Fabrication de l’algorithme puis phase de validation Æ la plus
utilisée en distribué.
♦ L’algorithmique distribuée utilise des concepts similaires à ceux des

réseaux Æ émission de messages, diffusion, accusés de réception …
♦ Cependant la distribution d’un algorithme nécessite certaines précautions

Æ techniques de fonctionnement des algorithmes distribués.
page 118
D’un point de vue Rdp, les transitions de partage doivent être localement équitables :
Processus 1
Processus 1
messages
consultation
P2
p P2
t’
• Jamais de modification d’une variable d’un processus par un autre.

• Jamais deux consultations d’un même processus (incohérence temporelle).
page 119
♦ La Distribution/partage des données

• Par duplication : chaque donnée existe en n exemplaires
Données D
{x,y,z,…..}
Sîte 1 Sîte 1 Sîte 1 Sîte 1

D D D D
x1 .. x2 .. x3 .. xn ..
Problème de cohérence mutuelle des copies : x1 = x2 =……=xn à tout instant
page 120
♦ La Distribution/partage des données

• Par partitionnement : chaque donnée ne se trouve que sur un sîte.
Données D
{x,y,z,…..}
Données D
{x,y,z,…..}
D D D D
x1 .. x2 .. x3 .. xn ..
D D D D
• Problème :x1
définition
.. du partitionnement
x2 .. x3 .. xn ..
♦ Association duplication/partitionnement
♦
page 121
Les avantages du parallélisme et de la distribution
♦ Evolution :
processeur processeur processeur p p p p
mémoire mémoire m m m
• Optimisation des tâches (sites spécialisés), vitesse de calcul…
• Taille des données pouvant être traitées,
• Résistance aux pannes,
page 122
♦ Conséquence de la distribution :
Processus Partage (données, ressources) Compétition

fonctionnant en
parallèles Coopération (programmes) Coordination
• Besoins :
Compétition Synchronisation
+ +
nécessitent
Coopération Communication
page 123
♦ Caractéristiques principales de la distribution :
• Pas de mémoire commune : interaction entre processus par messages et non plus par
variables partagées.
• Absence d’un état global connu par un processus à un instant donné : où en est-on ?
Processus 1 envoi(a) = ∆t Processus 2

a :=2 a :=1
b := 2*a c := a-4
Processus 3
e = b*c
envoi(b) = ∆’t envoi(c) = ∆’’t
• Peut induire un indéterminisme comportementale, (exemple : que vaudra e si un

algorithme ne gère pas un ordre d’exécution).
page 124
2) L’estampillage (Lamport) : ordonnancement des messages (équité), symétrie de texte
possible.
Estampille (i, hi) ≡ horloge logique unique

- Chaque processus Pi possède une horloge logique hi.
- Chaque message m émis est estampillé par l’indice i et hi Æ (m, i, hi).
- A la réception de (m, hj, j) par Pi : hi = max(hi,hj) + 1.
- Avant d’émettre un message, l’horloge logique d’un processus est incrémentée.
- Elle peut également être incrémentée en dehors de toute communication, si besoin est.
(m,2,5)
P1 (m,1,3) P2 P3
(m,1,4)
(m,3,6)
Avantage : relation d’ordre totale entre les messages échangés (l’algorithme s’y retrouve)
Note : si deux valeurs d’horloge identique Æ introduction d’une hiérarchie des processus
page 125
♦ Rappel sur l’élaboration de l’exclusion mutuelle centralisée
• Dekker(1965) : Assurer l’exclusion mutuelle de deux processus sachant que :
La machine sait lire ou écrire dans une mémoire.
Le temps d’exécution d’une instruction est non nul.
Il peut y avoir un ou plusieurs processeurs.
Il existe une mémoire partagée.
page 126
♦ Modélisation du problème grâce aux RdP
Processus 1 Processus 2
demande_1 demande_2
T1 Demande de Demande de
ressource T2
critique_1 critique_2 ressource
Fonctionnement sans dehors_2

besoin de la
ressource : dehors_1
page 127
♦ Première proposition : Chaque processus gère un drapeau indiquant s’il

veut entrer en section critique.
Pi Pj
attendre(drapeau(j) = 0) ; attendre(drapeau(i) = 0) ;
drapeau(i) = 1 drapeau(j) = 1
<Critique> <Critique>
drapeau(i)
drapeau(j)
• Echec : si i et j commencent en même temps, ils entrent en section critique tous les deux
• Solution : Il faudrait qu’avant d’attendre « drapeau(x) = 0 » , un processus positionne

son propre drapeau à 1. Ainsi, les tests d’attente ne pourraient être vrai simultanément.
page 128
♦ Deuxième proposition :
Pi Pj
drapeau(i) = 1 ; drapeau(j) = 1 ;
<Critique> <Critique>
drapeau(i)
drapeau(j)
• Echec : si i et j commencent en même temps, ils se bloquent mutuellement
• Solution : Il faudrait qu’au moment où un processus change la valeur de son drapeau il

connaisse la valeur du drapeau de l’autre processus.
page 129
♦ Troisième proposition :
Pi Pj
tant que (drapeau(j) = 1) tant que (drapeau(i) = 1)
<critique> <critique>
drapeau(i)
drapeau(j)
• Echec : si i et j commencent en même temps, et vont à la même vitesse
• Solution : Manque une notion de priorité, de tour.
page 130
♦ Quatrième proposition : Dekker 1965
Pi Pj
tant que (drapeau(j) = 1) tant que (drapeau(i) = 1)
si tour=j alors si tour=i alors
finsi finsi
<critique> <critique>
tour=j tour=i
• Blocage et Vivacité respecté. Equité dépendante de la vitesse relative des processus.
page 131
• Dijkstra 1965 : Algorithme de Dekker généralisé à n processus.
• Knuth 1966 : La première solution équitable
• De Bruijn 1967, Eisenberg et Mac Guire 1972,
• Peterson 1981 : solution équitable la plus simple
drapeau(i)=vrai drapeau(j)=vrai
tour=i tour=j
attendre drapeau(j) = faux∨tour=j attendre drapeau(i) = faux∨tour=i
<section critique> <section critique>
drapeau(i) = faux drapeau(j) = faux
page 132
page 133
Solution 5 : « round-based mutex algorithm»

Repos1
Fin1
Crit1
Asymétrie (j>k) Æ1>2 Servi2

Ac2
Demande21
Local2
Demande11 Req1 k
j
local1
Demande21
Req2
Demande22
Servi1
Ac1
Crit2
Fin2
Repos2
page 134

Syst Distribués

Transféré par

Droits d'auteur :

Formats disponibles

Syst Distribués

Transféré par

Informations du document

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 Distribués

Transféré par

Droits d'auteur :

Formats disponibles

Ecole Nationale d’Ingénieurs de Brest

Techniques et Algorithmes de mise en œuvre des systèmes répartis

Algorithmes de mise en œuvre des systèmes répartis

ν Systèmes répartis : Réseau

ν Machines, personnes, processus, « agents » … localisés à des

ν Distribution d’un calcul.

ν Les processus coopèrent pour régler un problème unique.

ν Optimisation des tâches (sites spécialisés), résistance aux pannes ...

ν Exemple de problème : l’observation d’un calcul distribué

• Les processus ne peuvent être

ν Exemple : Interconnexion bancaire :

• Pas de vision globale. Compte A : 0

ν Autre exemple : l’exclusion mutuelle.

ν La clef est une variable commune (verrou).

ν Tous les échanges d’information se font par messages.

• Chaque feu passe au rouge de façon autonome.

comportement autonome rouge

Dans quelle mesure cette observation est fausse ?

• A envoi un message à C puis à B

• C peut voir (m1,A) avant ou après (m3,B).

Partage (donnée ressources) Coopération (programme)

: Sans mémoire commune.

1) Distribution des données : duplication et/ou partitionnement

2) Distribution des calculs :

3) Distribution des algorithmes de mise en œuvre de la distribution

• Eléments de base : processus ou sites et voies de communication

♦ Voies de communication (ou liaison, ou canaux)

• Etoile : un processus particulier • Anneau : chaque processus

• Arbre : chaque processus communique avec ses fils et son père

Attention : Ne pas confondre la structure du réseau local avec la structure de

• Propriétés comportementales : Hypothèses de simplification classiques

• H1 : La transmission sur la voie se fait sans duplication de message.

• H2 : La transmission se fait sans altération des messages.

• H3 : Pour tout couple de processus communicants, l’ordre de réception des

• H4 : Le délai d’acheminement des messages est fini (bien qu’aléatoire) Æ pas de

• H5 : Le délai d’acheminement est borné.

• Programme séquentiel, instructions classiques (tanque faire, pour tout ….)

• Réceptifs à des événements (A la réception de « message » faire : …)

• Emetteurs d’événements (envoyer(« message »)).

• Choix non déterministes : si deux événements arrivent en même temps.

• Il existe des langages dédiés : CSP, ADA, PDIL

• non symétrie : Texte différent pour chaque processus (client-serveur)

♦ Qualités d’un algorithme distribué :

• Degrès de répartition : rôle joué par chaque processus Æ niveau de symétrie

• Résistance aux pannes : plus un algorithme distribué est symétrique, plus il

• Hypothèses sur les voies de communication : Moins il y a d’hypothèses, plus

♦ Exemple de deux techniques de distribution

• Cas simple : accusé de réception = diffusion d’une information

1) L’estampillage (Lamport) : cohérence temporelle

- Définir leurs caractéristiques :

- Trouver l'algorithme distribué

Sécurité versus Vivacité

Solution possible : ne jamais l'attribuer

Vivacité : ce que doit permettre l'algorithme

Solution possible : lui donner sans réfléchir

Difficulté : Sécurité + Vivacité .

Algorithme distribué = fonctions atomiques

Fonction particulière interruptible

• Algorithme distribué Æ Communication entre processus.

• Pas de mémoire commune Æ problème de représentation globale du programme