Poly

ALGORITHMIQUE
DU CONTROLE REPARTI

Tlcom ParisTech

Module Algorithmique rpartie de lUE INF346

Irne CHARON

Mars 2009

Tables des matires
Chapitre 1 - Gnralits........................................................................................................... 1
1.1. Introduction.................................................................................................................................................... 1
1.2. Algorithmes bass sur lchange de messages, gnralits ......................................................................... 2
1. Maillage.......................................................................................................................................................... 2
2. Qualits des voies de communication ............................................................................................................ 2
3. Qualits dun algorithme de contrle rparti .................................................................................................. 3
1.3. Ordonnancement des vnements................................................................................................................. 3
1. Le problme ................................................................................................................................................... 3
2. Prcdence causale......................................................................................................................................... 4
3. Estampillage, horloges logiques..................................................................................................................... 5
4. Horloges vectorielles...................................................................................................................................... 5
1.4. Diffrentes techniques utilises ..................................................................................................................... 6
1. Le jeton circulant............................................................................................................................................ 6
2. Le calcul diffusant .......................................................................................................................................... 7
Chapitre 2 - Le problme de lexclusion mutuelle ................................................................ 9
2.1. Introduction.................................................................................................................................................... 9
2.2. Jeton tournant sur un anneau : lalgorithme de Le Lann (1977)............................................................. 10
2.3. Diffusion et estampillage : lalgorithme de Lamport (1978)..................................................................... 11
2.4. Permissions de chaque site donn pour chaque utilisation de la section critique : un algorithme de
Ricart et Agrawala (1981) .................................................................................................................................. 13
2.5. Permissions de chaque site gardes tant quelles ne sont pas rclames : lalgorithme de Carvalho et
Roucairol (1983) .................................................................................................................................................. 14
2.6. Permissions sans estampillage : lalgorithme de Chandy et Misra (1984) .............................................. 15
2.7. Jeton circulant par diffusion : un autre algorithme de Ricart et Agrawala (1983)................................ 18
2.8. Gestion dune file dattente avec une arborescence : lalgorithme de Naimi et Trehel (1987) .............. 19
2.9. Caractristiques des algorithmes dexclusion mutuelle............................................................................ 21
Chapitre 3 - Le problme de llection, le parcours de rseau........................................... 23
3.1. Le problme de llection............................................................................................................................. 23
1. Gnralits.................................................................................................................................................... 23
2. Algorithme de Chang et Roberts (1979) ...................................................................................................... 24
3.2. Parcours dun rseau................................................................................................................................... 25
1. Gnralits.................................................................................................................................................... 25
2. Parcours en parallle .................................................................................................................................... 26
Chapitre 4 - Proprit globale............................................................................................... 29
4.1. Linterblocage............................................................................................................................................... 29
1. Gnralits.................................................................................................................................................... 29
2. Prvention de linterblocage dans lallocation de ressources ....................................................................... 30
3. Dtection de linterblocage dans lallocation de ressources......................................................................... 34
4.2. La terminaison.............................................................................................................................................. 35
1. Communications uniquement suivant un anneau unidirectionnel ................................................................ 36
2. Premier algorithme de Mattern..................................................................................................................... 37
3. Second algorithme de Mattern pour la terminaison (1991) .......................................................................... 38
4.3. tat global cohrent ..................................................................................................................................... 39
1. Algorithme de Chandy et Lamport............................................................................................................... 40
2. Principe de lalgorithme de Mattern (1988) ................................................................................................. 41
Bibliographie ....................................................................................................................................................... 42

Chapitre 1 - Gnralits
1.1. Introduction
Lalgorithmique du contrle dun systme rparti traite du contrle de mcanismes de
communication et de synchronisation de processus qui sexcutent en parallle sur un support
rparti, cest--dire lorsque les processus participants sexcutent sur diffrents sites (cas par
exemple dun rseau local ou grande distance) ; ces processus cooprent un mme service.
De plus, un algorithme de contrle est dit distribu sil nutilise pas un mme espace
dadressage dans lesquelles les diffrents processus puissent lire et crire afin de permettre
synchronisation et communication. Lorsque des processus parallles sont contrls par des
variables partages et quils disposent donc de mmoires communes, on dit que le contrle est
centralis.
On supposera pour simplifier que lensemble des processus participant laction sont
placs sur des sites distincts, un processus par site ; mme si plusieurs processus sont
effectus sur un mme site, il ny a pas dinconvnient les imaginer sur diffrents sites.
Le problme de base dun systme distribu est que chaque site ne connat un instant donn
que son propre tat, les informations quil obtient sur ltat des autres processus ne lui
parviennent pas simultanment avec les changements dtat de ceux-ci, la rception dune
information venant dun autre site linforme sur un tat antrieur mais pas sur ltat actuel : il
ny a pas de vision globale de ltat du systme.

On peut distinguer deux types dalgorithmes rpartis.
Dune part les algorithmes o les processus ont la possibilit de lire dans la mmoire des
autres sites. Chaque processus tient jour des variables (appeles variables dtat) qui
rendent compte de leur tat, et qui peuvent tre consultes par les autres processus. Une
variable qui peut tre accde la fois en lecture et en criture par un seul processus P et
accde en lecture par les autres processus sappelle variable propre P. Dans ce genre de
mthode, on peut considrer que la communication se fait par demande dinformations dun
processus vers les autres processus.
Dautre part, les algorithmes bass sur lchange de messages entre les diffrents sites. Dans
ce type dalgorithme, on considre en gnral que cest chaque processus dinformer les
autres processus de variations sur des paramtres qui concernent la collectivit, comme le
dsir daccs une ressource partage, ou bien une information sur le rsultat dun calcul, ou
bien la modification dune donne duplique sur les diffrents sites. Les changes se font
davantage par envoi dinformations que par demande dinformations. En grande majorit, les
algorithmes distribus sont bass sur lchange de messages.

Pour mettre en uvre un algorithme bas sur les variables dtat, qui procde par lecture
rgulire dinformations sur ltat des autres processus, on peut en fait utiliser des messages :
demande dinformations dun processus P
1
un processus P
2
puis rponse de P
2
vers P
1
;
mais cela entrane des demandes dinformations inutiles vers des processus qui nont pas
modifi les paramtres utiles la synchronisation ; la mise en uvre nest en fait efficace que

sur une architecture centralise. Mais on peut se demander pourquoi, lorsque larchitecture le
permet, ne pas faire une mise en uvre centralise ; un avantage de nutiliser que des
variables locales ou propres est quon obtient souvent ainsi une meilleure tolrance aux
pannes ; par ailleurs, les algorithmes bases sur lutilisation des variables dtat sont souvent
beaucoup plus claires que ceux o plusieurs processus peuvent modifier une mme variable.

Dans le premier chapitre, nous donnons quelques gnralits propos des algorithmes bass
sur lchange de messages. Dans le deuxime chapitre, nous tudions le problme de
lexclusion mutuelle et nous donnons plusieurs algorithmes distribus de principes varis.
Dans le troisime chapitre, nous tudions deux autres exemples de problmes de contrle : le
problme de llection et la diffusion dinformations. Dans le dernier chapitre, nous
examinons brivement le problme de linterblocage et de la dtection de la terminaison.

Le premier chapitre dcrit les diffrentes hypothses quon peut faire sur le rseau, dfinit les
qualits que lon peut attendre du fonctionnement dun rseau et donne diffrents types de
mthode que lon peut utiliser (estampillage, horloges vectorielles, calcul diffusant, utilisation
dun jeton).
1.2. Algorithmes bass sur lchange de messages, gnralits
1. Maillage
Une premire caractristique importante dun systme distribu est le maillage du rseau de
communication, cest--dire lensemble des liaisons directes entres les sites. Il sagit en fait de
maillage logique ; si certaines communications prvues par le maillage ne sont pas
physiquement installes, il faut rajouter une couche logicielle qui effectue un routage pour
envoyer un message dun site un autre site suppos connect lui dans les hypothses de
structure de lalgorithme ; il est videmment ncessaire que le rseau physique soit connexe.
Les principaux maillages utiliss sont :
le maillage complet : tout processus peut communiquer avec tout processus.
le maillage en anneau : le rseau est un cycle, tout processus possde deux voisins et il ne
peut communiquer quavec ceux-ci.
le maillage en toile : un processus particulier peut communiquer avec tous les autres qui,
rciproquement, ne communiquent quavec le processus particulier. Ce maillage prsente
linconvnient de particulariser un processeur et de rendre fcheuse la panne du site
central.
le maillage en arbre : la panne de tout processus non terminal dconnecte le systme
logique.
Dans les trois derniers maillages, il est possible de prvoir une reconfiguration lorsque lun
des processeurs tombe en panne (si les connexions physiques le permettent).

2. Qualits des voies de communication
Des hypothses doivent aussi tre faites sur le comportement des voies de communication.
Les caractristiques les plus importantes considrer sont :
lordre de rception des messages dun processus donn un autre processus donn est-il
le mme que lordre dmission ? Autrement dit, y a-t-il ou non dsquencement possible
des messages ?

est-il possible que certains messages se trouvent dupliqus au cours de leur transmission ?
les messages peuvent-ils tre altrs ?
les messages peuvent-ils tre perdus ?
le dlai dacheminement des messages est-il born, cest--dire peut-on tre certain dune
valeur maximum du dlai entre mission et rception ?
Ces proprits peuvent tre assures, si elles le sont, soit par la structure matrielle du rseau
sur lequel est implant lalgorithme, soit par une couche logicielle prvue cet effet.
3. Qualits dun algorithme de contrle rparti
Voyons enfin les qualits que lon peut souhaiter pour un algorithme de contrle rparti. On
peut souhaiter :
que le nombre de messages changs soit peu important.
minimiser le temps dexcution.
que le trafic sur les voies de communication ne soit pas trop dense, quil soit bien rparti
sur les lignes de communication et quil ny ait pas de site trop sollicit par la rception ou
lenvoi de messages.
quil ne ncessite pas certaines hypothses sur les voies de communication, par exemple
quil admette le dsquencement des messages.
quil ait une bonne rsistance aux pannes, cest--dire que le systme contrl ne soit pas
irrmdiablement interrompu si lun des processeurs qui assurent le contrle devient
dfectueux.

1.3. Ordonnancement des vnements
1. Le problme
On appelle vnement un changement local dtat sur un site ou bien lenvoi ou la rception
de messages.
Les messages changs dans un systme rparti sont essentiellement destins la
coordination entre les tches, cest--dire la synchronisation. Le problme fondamental de
cette synchronisation est que les transmissions ne sont pas immdiates ; les dlais de
transmission sont en gnral beaucoup plus longs que le temps sparant deux instructions
dun mme processus, on peut valuer trs grossirement quil y a un facteur de lordre de
mille. Les consquences sont :
un instant donn, on ne peut connatre, partir dun site donn, quune approximation de
ltat dun autre site
deux vnements observables quelconques dun systme peuvent tre perus dans un
ordre diffrent dun site lautre comme lillustre le schma ci-dessous :

x' y'
x"
y"
y
x

Nanmoins, il faut souvent que les diffrents sites puissent saccorder sur lordre
chronologique . Cest entre autres le cas :
lorsque lon doit grer une file dattente virtuelle rpartie, par exemple dans un
algorithme dexclusion mutuelle ; une telle file dattente possde une reprsentation
partielle ou totale sur chacun des sites concerns par lalgorithme : il faut que les
ordres de ces reprsentations soient identiques.
dans la mise en uvre dune mmoire rpartie, o chaque site possde une copie dune
mmoire virtuelle ; il faut alors connatre la modification la plus rcente.
...
Or, dans un systme rparti, on ne peut pas utiliser une heure unique, car rien ne permet
dassurer que les horloges sont synchrones. Supposons quon dcide dattribuer un
vnement lheure indique par lhorloge du site sur lequel il se produit ; un message pourrait
alors arriver avant dtre parti , ce qui rend difficile la gestion cohrente de copies de
variables.
2. Prcdence causale
Dfinition
Soit E un ensemble et R une partie de E

E (cest--dire une relation sur E). On appelle
fermeture transitive de R lintersection des parties T de E

E vrifiant :
R T
si (x, y) T et (y, z) T, alors (x, z) T

Lordonnancement des vnements dun systme rparti repose sur la dfinition dune
relation de prcdence dfinie comme suit : si a et b sont deux vnements, on dit que a
prcde directement b si lune des conditions suivantes est satisfaite :
a et b arrivent sur le mme site et a est antrieur b sur ce site
a est lenvoi dun message depuis un site et b est la rception de ce mme message sur un
autre site.
La relation prcde est la fermeture transitive de la relation ci-dessus ; on note a b la
relation a prcde b . Cette relation est appele relation de prcdence causale ; en effet,
un vnement a ne peut avoir influ sur un vnement b que si a b.
Deux vnements a et b sont dits concurrents (ou causalement indpendants) si aucun des
deux ne prcde causalement lautre.

3. Estampillage, horloges logiques
Il sagit dune technique qui permet de dfinir un ordre partiel ou global entre les vnements
compatibles avec la relation de prcdence causale. Pour cela, on effectue une datation des
vnements.
Chaque site S
i
gre une variable h
i
appele horloge logique. h
i
est une variable entire
initialise 0, et qui ne fait que crotre. Lorsquun vnement a se produit sur un site S
i
, la
valeur de h
i
est incrmente de 1 ; la date de a, note h(a), est alors h
i
. Par ailleurs :
lors de lmission dun message par le site S
i
, h
i
est incrmente de 1 ; un message m est
alors estampill par (h
i
, i) ; il devient donc de la forme (m, h
i
, i) ; h
i
est la date dmission
du message m.
lors de la rception par S
j
dun message (m, h
i
,

i), lhorloge h
j
est actualise la valeur
(max(h
i
, h
j
) + 1) et ce dernier nombre est considr comme la date de rception du
message.

Nous illustrons ci-dessous ce mcanisme ; les vnements sont reprsents par des points ; les
dates des vnements sont entoures.
S
1
3
1 2 4
4
3
6 5
(4, 1)
5
(2, 2)
h
1
:
4
0
6
3
h
2
:
0 5
2
5
1 3
4
S
2
0

Il peut arriver quon ne tienne compte que dune partie seulement des vnements, les autres
vnements ntant alors pas dats. On peut remarquer que si a b, alors la date de a est
infrieure la date de b.
On peut dfinir un ordre sur les vnements par : un vnement a est infrieur un
vnement b si et seulement si la date de a est strictement infrieure la date de b ; cet ordre
nest que partiel car plusieurs vnements peuvent tre affects de la mme date. On peut
tendre cet ordre en un ordre total strict, not <, en dcidant que, entre deux vnements qui
ont la mme date (ce qui nest pas possible pour deux vnements distincts ayant eu lieu sur
un mme site), cest celui qui a eu lieu sur le site de plus petit numro qui est antrieur
lautre ; autrement dit, si a et b sont deux vnements ayant eu lieu sur les sites i et j :
(a < b) date(a) < date(b) ou (date(a) = date(b) et i < j)
4. Horloges vectorielles
La relation date(a) < date(b) n'est pas suffisante pour savoir s'il existe une relation de
causalit entre a et b ; cette relation implique uniquement que b ne prcde pas causalement
a ; il est possible que a prcde causalement b ou bien que a et b soient causalement
indpendants. Il est quelquefois utile de pouvoir dterminer s'il y a ou non dpendance
causale entre deux vnements, par exemple pour la recherche des causes potentielles d'une
erreur ou dune panne.
Le mcanisme des horloges vectorielles a t introduit pour caractriser la dpendance
causale.
Supposons qu'il y ait n sites. Sur un site, on appelle pass l'ensemble des vnements (y
compris les missions et les rceptions de message) qui prcdent causalement le dernier
vnement qui a eu lieu sur le site concern. Sur chaque site S
i
, on dfinit une horloge

vectorielle V
i
comme un vecteur d'entiers, de longueur n ; cette horloge est actualise de telle
sorte que :
V
i
[j]

= nombre dvnements du pass ayant eu lieu sur le site j.
On associe aussi chaque vnement a une date note date(a) qui est gale la valeur
(vectorielle) de lhorloge vectorielle locale juste aprs cet vnement.
Pour effectuer le calcul de V
i
, on opre les oprations suivantes :
au dpart, sur chaque site, V
i
est initialis (0, ..., 0).
si un vnement a se produit sur le site i, V
i
[i]

est incrment de 1 ; on affecte le vecteur V
i

date(a) qui est une valeur dhorloge vectorielle ; on remarque que date(a)[i]
comptabilise tous les vnements ayant eu lieu sur S
i
, y compris a.
avant mission dun message depuis le site i, V
i
[i]

est incrment de 1 puis le message est
estampill par (V
i
, i).
si le site j reoit un message du site i, estampill par (V
i
, i), alors V
j
[j] est incrment de 1
puis, pour 1 k n , k j, V
j
[k] devient max(V
i
[k], V
j
[k]).
Nous illustrons ci-dessous ce mcanisme, en mettant ct de chaque vnement sa date ;
les valeurs des horloges vectorielles sont donnes par la date du dernier vnement produit
sur le site :

(1, 0, 0)
(1, 3, 2)
(0, 0, 0)
(5, 4, 3)
S
1
(0, 1, 0)
(4, 4, 0)
(3, 0, 0) (2, 0, 0)
(1, 3, 0)
(1, 2, 0)
(0, 0, 0)
(1, 3, 3) (0, 0, 0)
(1, 4, 0)
(1, 3, 1)
((1, 3, 0), 2)
((1, 3, 3), 3)
((1, 4, 0), 2)
((1, 0, 0), 1)
S
2
S
3

Si V et W sont deux valeurs d'horloges vectorielles, on dit que V < W si toute composante de
V est infrieure ou gale la composante correspondante de W et si l'une au moins des
composantes de V est strictement infrieure la composante correspondante de W.
On vrifie facilement que, si a et b sont deux vnements :
a b date(a) < date(b)

1.4. Diffrentes techniques utilises
1. Le jeton circulant
Le maillage logique est un anneau ; le principe est de faire circuler un privilge unique sur
cet anneau ; le privilge est reu grce un message de type particulier venant du site
7
prcdent de lanneau ; ce message est appel jeton ; le jeton peut transporter des valeurs de
variables qui renseignent sur les autres sites au moment du dernier passage du jeton.
2. Le calcul diffusant
Ce type dalgorithme peut servir diffuser ou collecter de linformation.
Le maillage logique est un arbre couvrant. Un processus peut dclencher lalgorithme
diffusant, ce processus est appel racine de larbre. Il met pour cela un message vers tous ses
voisins, et est considr comme le pre de ceux-ci. Ceux-ci leur tour transmettent
linformation leurs voisins autres que leur pre, et sont considrs comme le pre de ces
voisins, et ainsi de suite. Quand un processus atteint est une feuille de larbre, il envoie une
rponse son pre ; quand un processus a reu une rponse de tous ses voisins diffrents de
leur pre, il envoie une rponse son pre. Lalgorithme sarrte quand le processus racine a
reu une rponse de tous ses voisins.
Il se peut quun seul processus ait le privilge de lancer lalgorithme, ou bien que tout
processus en ait la possibilit. Il se peut aussi que le maillage soit quelconque et que larbre
soit construit au fur et mesure ; lalgorithme est identique la variante suivante prs : un
processus qui a dj reu le message lui donnant lordre de diffusion tous ses voisins et
reoit nouveau ce mme ordre dun autre processus se dispense de diffuser et rpond
simplement son pre quil fait dj partie de larbre.
Plus de prcisions peuvent tre trouves dans le paragraphe 4.2.

Chapitre 2 - Le problme de lexclusion
mutuelle
2.1. Introduction
Il sagit ici dtudier le contrle de n processus entrant en comptition pour se partager une
mme ressource ; celle-ci peut tre utilise par un seul processus ; quand un processus
lutilise, on dit quil est en section critique. On suppose que lutilisation de la ressource a
toujours une dure finie. Lutilisation de la ressource par un processus suivra toujours le plan
suivant :
protocole dacquisition de la ressource
utilisation de la ressource en section critique
protocole de libration de la ressource.
Un processus P' entamant son processus dacquisition alors que la section critique est utilise
par un processus P devra attendre (rester dans la phase dacquisition) au moins jusqu ce que
P ait termin son protocole de libration.
Voyons les embches viter lorsquon met au point des protocoles dexclusion mutuelle.
Imaginons ce premier protocole dacquisition : si un processus dcouvre quil est en
comptition avec dautres pour lacquisition, il laisse passer les autres : cest lexemple le plus
simpliste quon puisse imaginer de ce qui conduit une situation dite dinterblocage ; tous les
processus entrant en comptition sont bloqus et la ressource reste ternellement non utilise.
Linterblocage dans le cas de lexclusion mutuelle peut snoncer ainsi :
interblocage = il existe au moins un processus qui dsire accder la section critique
et aucun processus ne peut latteindre.

Considrons maintenant un systme dans lequel oprent trois processus P
1
, P
2
, P
3
qui
utilisent une mme ressource R. Si le protocole est tel que P
1
et P
2
puissent alterner
lutilisation de la section critique, ou bien mme que P
1
puisse lutiliser de faon rptitive,
de telle sorte que P
3
naccdera jamais la section critique, on dit quil y a famine. Si un
protocole rend impossible la famine, on dit aussi quil assure lquit. On peut noncer :
quit = non famine
= tout processus demandant la section critique latteint en un temps fini.
La qualit dun algorithme dassurer lquit sappelle aussi la vivacit.
Lquit entrane le non interblocage.
On sintresse aussi, lorsquil ny a pas famine, aux diffrents ordres possibles de passage en
section critique par les processus :
si tous les processus accdent la section critique dans lordre o ils lont demande, on
dit que lattente est FIFO.
si tout processus demandeur peut se faire doubler pour laccs en section critique au plus
une fois par chaque autre processus, on dit que lattente est linaire ; un processus P se
fait doubler par un processus Q quand, ayant dbut en premier son protocole
dacquisition, il passe aprs Q en section critique.
10

si, pour un protocole donn, il existe une fonction f(n) (n = nombre de sites) tel quun
processus donn se fasse doubler par au plus f(n) processus, on dit que lattente est borne
par f(n).
Remarque :
Dans un contrle distribu bas sur lchange de messages, pour juger si une demande
daccs la section critique est antrieure une autre, on se rfre des horloges logiques et
non lunique chelle du temps (il est impossible un contrle distribu de connatre lordre
rel dune squence dvnements ayant lieu sur diffrents sites car il ny a pas dhorloge
commune).

La qualit minimum requise par un protocole dexclusion mutuelle est, en plus de raliser
lexclusion, dviter linterblocage.

Tous les algorithmes explicits dans ce chapitre se situent dans un contexte o il nexiste
aucune variable partage.

Nous utiliserons le modle suivant : chaque processus P
i
est associ un autre processus G
i
,
qui effectue la gestion du contrle de la ressource pour le processus P
i.
Autrement dit, chaque
processus P
i
possde un gestionnaire G
i
spcialis dans le contrle. Un processus et son
gestionnaire sont situs sur le mme site. Lorsquun processus P
i
dsire utiliser la ressource,
il envoie un message Demande_de_la_ressource son gestionnaire et attend alors un
message Ressource_disponible de son gestionnaire ; lorsquil libre la section critique, il
envoie un message Restitution_de_la_ressource son gestionnaire. Cet change de messages
pourrait tre remplac par une communication plus directe entre un processus et son
gestionnaire, par exemple par un partage de variables. Les messages changs entre un
processus et son gestionnaire ne seront pas compts dans le calcul du nombre de messages
ncessaires un contrle.
2.2. Jeton tournant sur un anneau : lalgorithme de Le Lann
(1977)
Cet algorithme utilise une structure logique en anneau. On suppose que les messages ne
peuvent pas tre perdus et que les processeurs ne tombent pas en panne. Lalgorithm consiste
faire tourner un unique jeton .
Le mot jeton reprsente ci-dessous un type de message.

Variables
demandeur : boolen, initialis faux
Rception de messages par G
i
, gestionnaire de P
i
(les indices sont pris modulo n) :
Demande_de_la_ressource (venant de P
i
)
demandeur vrai ;

Jeton
si demandeur, envoyer Ressource_disponible P
i
;
sinon envoyer jeton G
i + 1
;

11

Restitution_de_la_ressource (venant de P
i
)

demandeur faux ;
envoyer jeton G
i + 1 ;

A linitialisation, un et un seul des sites excute le texte correspondant la rception du jeton.

On peut amliorer cet algorithme pour tenir compte des risques de panne de processeur et de
perte du jeton.
Linconvnient est le nombre de messages transmis, mme si la ressource est trs peu
demande : le nombre de messages changs dune utilisation de la ressource lautre est non
born.
2.3. Diffusion et estampillage : lalgorithme de Lamport (1978)
Remarque : La version prsente ici est lgrement modifie par rapport celle de Lamport ;
lalgorithme initial de Lamport exigeait que les messages ne soient pas dsquencs, cette
hypothse nest pas utile dans la version ci-dessous.
Cet algorithme utilise un maillage complet et deux techniques : les estampilles pour tablir un
ordre total entre les demandes daccs la ressource, et la gestion dune file dattente rpartie
des processus en attente de la ressource. On fait lhypothse que les lignes sont fiables ; les
messages ne sont pas perdus.
Le principe de lestampillage laide dhorloges logiques a t expos dans le premier
chapitre ; sur un site, nous notons h

la valeur de lhorloge et lappelons heure. Un message
envoy par le gestionnaire G
i
lorsque son horloge vaut h est estampill par le couple: ( h, i).

Il y a trois types de messages :
le type requte : un message de ce type est diffus par un gestionnaire qui dsire obtenir la
ressource vers tous les autres gestionnaire.
le type libration : un message de ce type est diffus par un gestionnaire qui vient de
recevoir du processus auquel il est associ un message Restitution_de_la_ressource vers
tous les autres gestionnaires.
le type acquittement : lorsque un gestionnaire G
i
reoit dun gestionnaire G
j
un message
de type requte, il rpond G
j
par un message de type acquittement, autrement dit un
accus de rception, sauf si le site i est dans le protocole dacquisition ; dans ce dernier
cas, le site G
i
ne rpond rien.

Chaque site possde un tableau nomm T, indic par 0, 1, ..., n 1 o G
i
inscrit,

lindice j, la
valeur maximum des dates reues dans les estampilles des messages venant du site j.

Une variable nomme demandeur permet de savoir si le site correspondant est ou non
demandeur de la section critique.
G
i
range galement en T[i] lheure de sa dernire requte lorsquil est demandeur.

Un gestionnaire qui dsire obtenir la section critique pour le processus i dont il gre le
contrle ne peut le faire que si (T[i], i) est infrieur tous les autres couples (T[j], j) ; on
rappelle que (T[i], i) < (T[j], j) signifie que soit T[i] < T[j], soit T[i] = T[j] et i < j.

12

i
, gestionnaire de P
i
:
Demande_de_la_ressource(venant de P
i
)
demandeur vrai ;

diffuser (requte, h, i) ;
T[i] h ;

Message(type, k, j)
h max(h, k) + 1 ; (
*
recalage et incrmentation de lhorloge
*
)
si (T[j] < k), T[j] k ; (* on prvoit un dsquencement *)
si (demandeur)
si ( j i, (T[i], i) < (T[j], j), envoyer Ressource_disponible a P
i
;
sinon si (type = requte), envoyer (acquittement, h, i) j ;

i
)

diffuser (libration, h, i) ;
demandeur faux ;

Montrons que cet algorithme assure lexclusion mutuelle. Supposons que G
i
et G
j
soient
demandeurs. Notons respectivement T
i
et T
j
les tableaux de i et j. T
i
[i] contient la date de
la requte de i et T
j
[j] celle de la requte de j.
Le site i na envoy aucun message depuis sa requte et les messages de i prcdents la
requte avait une estampille infrieure celle de la requte. On a :
(T
i
[i], i) (T
j
[i], i).
En effet, ce rsultat est vrai si la requte de i na pas encore t reue par j du fait du non
dsquencement ; il est vrai aussi si la rception a dj eu lieu car alors T
i
[i] = T
j
[i].
De mme, (T
j
[j], j) (T
i
[j], j).
Si (T
i
[j], j) > (T
i
[i], i), alors :
(T
j
[j], j) (T
i
[j], j) > (T
i
[i], i) (T
j
[i], i), ce qui entrane :
(T
j
[j], j) > (T
j
[i], i) : G
j
ne peut pas obtenir la ressource.
Seul le gestionnaire qui a effectu la demande la plus ancienne (selon lordre total dfini par
les estampilles) peut obtenir la ressource ; cette situation nvolue quau moment o le
gestionnaire envoie un message de libration. Do lexclusion mutuelle et plus prcisment
seul le gestionnaire qui a fait la requte de plus petite estampille peut obtenir la ressource.
Inversement, grce aux messages dacquittement, le gestionnaire qui a fait la requte non
encore satisfaite de plus petite estampille ne peut pas tre bloqu pour lobtention de la
ressource : il ny a pas dinterblocage. Une requte aura au bout dun temps fini la plus petite
estampille ; il ny pas famine.

Lalgorithme peut tre amlior pour rsister aux pannes des gestionnaires (ou des processus
associs) ; lorsquun gestionnaire tombe en panne, un message est diffus pour signaler cette
panne et le test sur lanciennet de la requte nest alors fait quentre les gestionnaires non en
panne. Il faut prvoir aussi les remises jour lors dune rinsertion de gestionnaire.
On constate quune utilisation de la ressource par un processus ncessite lchange entre les
gestionnaires de 3(n 1) messages : n 1 pour la requte, au plus n 1 pour les
acquittements, n 1 pour la libration. Ricart et Agrawala ont propos en 1981 un algorithme
qui ne ncessite que 2(n 1) messages ; Carvalho et Roucairol ont prsent la mme anne
un algorithme qui ncessite, selon loccurrence de lutilisation, entre 0 et 2(n 1) messages.
13

2.4. Permissions de chaque site donn pour chaque utilisation de
la section critique : un algorithme de Ricart et Agrawala (1981)
On tudie ici un algorithme assez naturel : lorsque le gestionnaire dun processus dsire
obtenir la ressource, il demande la permission de lutiliser chacun des n 1 autres
gestionnaires ; il attend alors davoir reu toutes les permissions.
videmment, lorsquun gestionnaire reoit une demande de permission, il faut quil se pose
la question des priorits ; diffrents procds permettent de dcider de la priorit ; dans
lalgorithme que nous allons expliciter ci-dessous, chaque message est estampill par lheure
logique et lidentit du demandeur ; le gestionnaire qui reoit une demande envoie sa
permission sauf sil est demandeur et que lestampille de sa demande est infrieure celle du
site demandant une permission. Dans le cas o le gestionnaire nenvoie pas sa permission
immdiatement, il lenverra lorsque le processus pour lequel il gre le contrle de la
ressource aura restituer celle-ci.
Les noms des sites sont supposs tre 1, 2, ..., n.
Variables dun gestionnaire :
demandeur : boolen initialis faux ;
h : entier positif initialis 0 ;
heure_demande : entier ;
permissions : ensemble didentificateurs de sites initialis {i} ;
en_attente : ensemble didentificateurs de sites initialis .

i
, gestionnaire de P
i
:
i
)

h h + 1;
demandeur vrai ;
heure_demande h ;
pour tout j de {1, 2, ..., n} {i},
envoyer Demande_de_permission(heure_demande, i) j ;

Demande_de_permission(k, j)
h max(h, k) ;
si (demandeur) et (heure_demande, i) < (k, j)), en_attente (en_attente {j}) ;
sinon (* alors j permissions *) envoyer Permission(i) j ;

Permission(j)
permissions permissions {j} ;
si permissions = {1, 2, ..., n}, envoyer Ressource_disponible P
i
;

i
)
demandeur faux ;
pour tout j dans en_attente,
envoyer Permission( i) j ;
permissions {i} ;
en_attente ;

14

On peut prouver la sret de cet algorithme, mme si les lignes de transmission des messages
ne sont pas fifos (cest--dire sil est possible quil y ait dsquencement).
On remarque que les gestionnaires obtiennent la ressource dans lordre donn par les
estampillages, ce qui assure la vivacit de lalgorithme.
Lobtention de la ressource ncessite toujours exactement 2(n 1) messages.
Si on suppose que le temps de transmission des messages entre gestionnaires est de T et que
lon nglige les temps de transmission des messages entre un processus et le gestionnaire qui
lui est associ (ce qui est lgitime puisquun processus et son gestionnaire se trouvent sur le
mme site), la dure pendant laquelle la ressource est inutilise alors quau moins un
processus est demandeur est comprise entre T et 2T.

Enfin, remarquons quil est possible de borner les compteurs logiques de temps. En effet, par
construction, les dates des demandes de permission en cours un moment donn forment un
intervalle dentiers ; puisque le nombre de sites est n, si le site i fait une demande de
permission estampille avec lheure heure_demande, cest que les demandes de permission
quil peut recevoir sont estampilles par une heure k vrifiant :
(n 1) heure_demande k n 1.
Supposons que les heures soit en fait mmorises modulo 2n - 1 (ou modulo un entier au
moins gal 2n 1), les messages tant alors estampills avec les heures modulo 2n 1 ; le
calcul de la diffrence heure_demande k sera alors exact modulo 2n 1 ; lintervalle
dentiers [ (n 1), n + 1] contenant 2n 1 entiers, le nombre effectif heure_demande k
peut tre parfaitement dtermin.
2.5. Permissions de chaque site gardes tant quelles ne sont pas
rclames : lalgorithme de Carvalho et Roucairol (1983)
Cet algorithme est une amlioration du prcdent dans la mesure o lutilisation de la
ressource ncessite en moyenne lutilisation de moins de messages.

On peut considrer que, pour chaque paire de sites, il existe un unique jeton nomm
jeton(i, j). Un processus i ne peut utiliser la ressource que si son gestionnaire possde pour
tout j le jeton (i, j). Lorsquun gestionnaire veut obtenir la ressource, il fait donc des requtes
pour tous les jetons qui lui manquent aux sites concerns, et uniquement pour ceux-ci.
Lorsquun site i reoit dun site j la demande de jeton(i, j), il lenvoie uniquement sil calcule
quil nest pas prioritaire ; sinon, il enverra le jeton lorsquil aura eu satisfaction sur
lutilisation de la ressource. Le calcul des priorits se fait laide destampillages de manire
analogue lalgorithme prcdent.
On nutilise pas en fait explicitement ces jetons ; si le site i na pas jeton(i, j), on traduit cela
sur le site i par j permissions.

Variables :
tat : peut prendre les valeurs demandeur, utilisateur, ailleurs, initialise ailleurs ;
h : entier positif initialis 0.
heure_demande : entier. ;
permissions : ensemble didentificateurs de sites initialis de telle sorte que :
sur le site i, j permissions sur le site j, j permissions ;
en_attente : ensemble didentificateurs de sites initialis .

15

i
, gestionnaire de P
i
:
i
)
h h + 1;
si (permissions = {1, 2, ..., n})
tat utilisateur ;
envoyer Ressource_disponible P
i
;
sinon

etat demandeur ;
heure_demande h ;
pour tout j permissions, envoyer Demande_de_permission(h, i) j ;

Demande_de_permission(k, j)
h max(h, k) ;
si (tat = utilisateur) ou ((tat = demandeur) et ( heure_demande, i)) < (k, j)))
en_attente (en_attente {j}) ;
sinon
envoyer Permission(i) j ;
si (tat = demandeur)
envoyer Demande_de_permission(heure_demande, i) j ;

Permission(j)
si (permissions = {1, 2, ..., n})
tat utilisateur ;
i
;

i
)

tat ailleurs ;
pour tout j dans en_attente,
envoyer Permission( i) j ;
en_attente ;

Sret et vivacit sont l encore assures. Lutilisation de la ressource ncessite entre 0 et
2(n 1) messages. Si le temps de transmission dun message est de T, la dure pendant
laquelle la ressource est inutilise alors quelle est demande est comprise entre 0 et 2T.
En revanche, les dcalages entre les horloges ne sont pas borns ; en consquence, il nest pas
possible de borner les valeurs des horloges.
2.6. Permissions sans estampillage : lalgorithme de Chandy et
Misra (1984)
La diffrence essentielle entre cet algorithme et lalgorithme prcdent est que les rgles de
priorit sont dfinies sans utiliser destampillage de messages. Avec les mmes notations que
pour la prsentation de lalgorithme prcdent, lorsquun site i reoit de j la permission de i, il
est prioritaire sur j pour une utilisation de la ressource ; lorsque cette utilisation aura t
16

effectue, la priorit sera j ; si le site j demande permission i, i lui enverra cette
permission.
Labsence destampillage des messages vite aux sites de grer une heure logique ; elle vite
aussi la ncessit que chaque site ait un nom. Il suffit que chaque site puisse identifier les
canaux de transmission qui le relient aux n 1 autres sites.

Nous nous intressons au gestionnaire G du processus P, nous notons c
1
, c
2
, ..., c
n 1
les
canaux qui lient le site de ce gestionnaire aux autres sites.

Variables :
tat : peut prendre les valeurs demandeur, utilisateur, ailleurs, initialise ailleurs ;
utilis: tableau indic par c
1
, c
2
, ..., c
n 1
de boolens ; utilis(c
j
) est vrai si G possde la
permission venant du canal c
j
et si le processus pour qui il gre le contrle a utilis la
ressource au moins une fois depuis quil possde cette permission ; sinon cette variable
vaut faux ;
permissions : ensemble didentificateurs de canaux ;
en_attente : ensemble didentificateurs de canaux initialis .

La faon dinitialiser les variables permissions et utilis est explicite plus bas.

Rception de messages par G, gestionnaire de P :
Demande_de_la_ressource (venant de P)
si permissions = (c
1
, c
2
,c
n 1
)
tat utilisateur ;
envoyer Ressource_disponible P ;

sinon

etat demandeur ;
pour tout c
j
permissions,
envoyer Demande_de_permission par c
j
;

Demande_de_permission arrivant par le canal c
j

(* larrive de cette demande montre que G possde cette permission ou bien va la recevoir *)
si (tat = utilisateur) ou (utilis(c
j
) = faux)
en_attente en_attente {c
j
} ;
sinon
envoyer Permission par c
j
;
permissions permissions {c
j
} ;
si (tat = demandeur) envoyer Demande_de_permission par c
j
;

Permission arrivant par le canal c
j
(* ncessairement, tat = demandeur *)
permissions permissions {c
j
} ;
utilis(c
j
) faux ;
si permissions = (c
1
, c
2
,c
n 1
)
envoyer Ressource_disponible P ;
tat utilisateur ;

17

Restitution_de_la_ressource (venant de P)

tat ailleurs ;
pour tout c
j

si c
j
dans en_attente,
envoyer Permission par c
j
;
sinon utilis(c
j
) vrai ;
en_attente ;

Il faut tre vigilant pour linitialisation des ensembles permissions et des tableaux appels
utilis . Prcisons les hypothses quon veut avoir linitialisation et conserver au cours de
lexcution.
Il faut tout dabord que, pour chaque paire de gestionnaires, il y ait une permission virtuelle
qui soit chez lun, ou chez lautre, ou en transition de lun lautre, et en aucun cas
chez les deux gestionnaires la fois. Cela se traduit par le fait que, en appelant c le canal
joignant le gestionnaire G au gestionnaire H :
(1) soit la permission est chez G :
c permissions pour G et c permissions pour H
(2) soit la permission est chez H :
c permissions pour H et c permissions pour G
(3) soit une permission est en transit sur c de G vers H
(4) soit une permission est en transit sur c de H vers G.

G est prioritaire sur H si et seulement si :
on est dans le cas (1) et, pour G, utilis(c) est faux
on est dans le cas (2) et, pour H, utilis(c) est vrai,
on est dans le cas (4).
Considrons le graphe des priorits ; il sagit du graphe dont les sommets sont les
gestionnaires et o il existe un arc de G vers H si H est prioritaire sur G. Il est facile de vrifier
que labsence dinterblocage est assure par labsence de circuit dans le graphe des priorits ;
en effet, la dcision pour un site denvoyer ou non une permission respecte les priorits ; un
gestionnaire i prioritaire sur un gestionnaire j recevra la permission de celui-ci ; si le graphe
des priorits est sans circuit, il existe un gestionnaire prioritaire sur tous les autres, celui-ci
obtiendra la ressource.
Linitialisation doit assurer cette absence de circuits. Pour cela, il suffit de considrer au dpart
un ordre total sur les gestionnaires ; si G se trouve avant H dans cet ordre, on met la
permission chez G (c permissions pour G et c permissions pour H) ; par ailleurs, on donne
la valeur vrai toutes les composantes de tous les tableaux utilis . Dans le graphe des
priorits, larc entre G et H va de G vers H si et seulement si G est avant H dans lordre total
considr.
Les arcs du graphe des priorits ne sinversent que lorsquun processus P libre la ressource ;
le gestionnaire du processus P a alors un demi-degr intrieur nul dans ce graphe. Il ne peut
appartenir aucun circuit : aucune inversion darcs au cours de lalgorithme ne cre donc de
circuit. Linitialisation propose assure lalgorithme labsence dinterblocage.
On peut enfin vrifier que cet algorithme a la qualit de vivacit.
18

2.7. Jeton circulant par diffusion : un autre algorithme de
Ricart et Agrawala (1983)
Cet algorithme est trs performant en ce qui concerne le nombre de messages changs pour
chaque utilisation de la ressource, puisque ce nombre est, selon les cas, n ou 0 ; nanmoins, la
taille de certains de ces messages est beaucoup plus grande que dans le cas de lalgorithme de
Lamport ou des trois autres algorithmes cits ci-dessus.
On suppose que les messages ne sont jamais perdus ni altrs, mais on accepte lventualit
de messages dsquencs.

Lalgorithme est un peu intermdiaire entre lalgorithme de Le Lann (il utilise un jeton qui
circule selon un anneau logique, mais en sautant les sites des processus non demandeurs) et
lalgorithme de Lamport (un processus qui dsire utiliser la ressource mais ne possde pas le
jeton diffuse une requte suivant un maillage complet).
Un gestionnaire G
i
ne peut envoyer un message Ressource_disponible au processus dont il
gre le contrle que lorsquil possde lunique jeton. Sil veut obtenir la ressource et quil ne
possde pas le jeton, il diffuse tous les autres processus un message de type requte qui
correspond une requte faite pour avoir le jeton ; ce message comporte deux
renseignements : le numro de squence de cette requte (ce numro, initialis 1, est
incrment de 1 chaque requte), le numro didentification du gestionnaire (i pour G
i
). Il
attend alors le jeton.
Lorsque G
i
reoit du processus dont il gre le contrle la Restitution de la ressource, il
regarde sil a reu de G
i +1
une requte pour le jeton non encore satisfaite ; si oui, il lui envoie
le jeton ; si non, il reprend avec G
i

+

2
, ...., puis G
n 1
, puis G
0
, ..., puis G
i 1
; sil na ainsi
trouv aucune requte non satisfaite, il garde le jeton ; il pourra le rutiliser quand il en aura
besoin (en envoyant un message Ressource_disponible au processus dont il gre le contrle)
sauf si, entre temps, il reoit une requte pour le jeton quil doit alors satisfaire par envoi du
jeton.
Le jeton se dplace laide dun message qui indique (en plus de son type) pour tout i
compris entre 0 et n 1, le nombre de fois o le jeton est pass chez G
i
cest--dire le numro
de squence (dont il a dj t question plus haut) de la dernire requte satisfaite de G
i
; cette
information sera note jeton[i]. Lensemble de ce message sera not ci-dessous jeton. Le jeton
est donc ici porteur de renseignements sur ltat global du systme.
Dans le pseudo-code ci-dessous, on utilise une instruction dcriture dans jeton, ce qui
consiste en fait copier le jeton, crire dans la copie puis recomposer le message jeton avec
cette copie modifie.
copi
Les variables locales un site i sont :
num_seq (pour numro de squence) : compteur croissant initialis 0 indiquant le
nombre de requtes du jeton faites par G
i
.
tab_requte : tableau indic par 0, 1, ..., n 1 ; G
i
note dans tab_requte[j] le numro de
squence de la requte la plus rcente quil ait reue de P
j
. Si tab_requte[j] > jeton[j],
cest que G
j
attend le jeton.
jeton_prsent : boolen initialis faux sauf pour lun des processus o linitialisation est
vrai ; jeton_prsent est vrai si et seulement si G
i
possde le jeton .
dedans : boolen initialis faux qui est vrai entre le moment o le gestionnaire envoie
un message Ressource_disponible au processus dont il gre le contrle et le moment o il
reoit de celui-ci un message Restitution_de_la_ressource. ;
19

une variable j qui est un compteur de boucle.
Les actions effectues la rception dun message sont supposes indivisibles.

i
, gestionnaire de P
i
:
i
)
si non jeton_prsent
num_seq num_seq + 1 ;
diffuser requte(num_seq, i) ;
sinon
i
;
dedans vrai ;

Requte(k, j)
si (k > tab_requte[j]) (
*
on prvoit un risque de dsquencement
*
)
tab_requte [j] k) ;
si (jeton_prsent) et (non dedans)
jeton_prsent faux ;
envoyer (jeton) G
j ;

Jeton (*le processus associ attend ncessairement la ressource*)
jeton[i] num_seq ;
jeton_prsent vrai ;
i
;
dedans vrai ;

i
)

dedans faux ;
j (i + 1) mod n ;
tant que (jeton_prsent et j i)
si tab_requte[j] > jeton[j]
jeton_prsent faux ;
envoyer (jeton) G
j ;

j (j + 1) mod n ;

Lexclusion mutuelle est vrifie du fait de lunicit du jeton. On peut vrifier aussi labsence
dinterblocage ou de famine.

2.8. Gestion dune file dattente avec une arborescence :
lalgorithme de Naimi et Trehel (1987)
Le plus simple pour grer une ressource en exclusion mutuelle est la gestion interne dune
file dattente. Lalgorithme que nous allons exposer permet une telle gestion. Nous allons
grer une file dattente dans laquelle un gestionnaire entre quand le processus dont il gre le
contrle demande la ressource et dont il sort lorsque celui-ci libre la ressource.
Le principe est de grer une arborescence dont la racine correspond au gestionnaire qui est le
dernier dans la file dattente, sauf dans le cas o la file est vide. Lorsquun gestionnaire H
20

veut se mettre dans la file dattente, il transmet sa demande en faisant remonter sa requte
jusqu la racine de larborescence : le gestionnaire G qui sy trouve pourra alors noter que H
est le gestionnaire qui le suit dans la file ; au fur et mesure que les messages remontent ,
certains arcs sont modifis pour que H devienne la racine de la nouvelle arborescence ; la
faon de modifier ces arcs nest pas unique ; celle choisie par Naimi et Trehel en est une
parmi dautres.
Les sites sont appels 1, 2, ..., n et le gestionnaire qui est sur i est G
i
.
Un message appel jeton indique un gestionnaire quil est le premier dans la file dattente
(cest alors lui dutiliser la section critique).
Les variables utilises sur un site i sont :
a_un_pre : boolen qui prend la valeur faux uniquement pour la racine de larborescence
pre qui indique, pour les gestionnaires autres que celui correspondant la racine, le pre
de G
i
dans larborescence ; toutes ces variables sont videmment initialises pour quau
dpart lensemble des dfinitions des pre(s) constituent une arborescence ;
est_demandeur : boolen qui indique si G
i
est demandeur de la ressource ; ce boolen
nest utile que pour dtecter le cas o la file est vide : la racine de larborescence nest
alors pas dans la file ;
a_un_suivant : boolen vrai si le gestionnaire est dans la file dattente et pas le dernier
dans cette file
suivant : indique ventuellement le nom du suivant de G
i
dans la file dattente
jeton_prsent : boolen qui est vrai si le site concern utilise la ressource ou bien
ventuellement si le gestionnaire est racine de larborescence et soit quaucun site nest
demandeur, soit que des messages des demandes sont en transit ; cette variable est
initialise vrai uniquement pour le gestionnaire pour lequel a_un_pre est initialis
faux.

Lalgorithme est tel que quon a toujours hors des blocs des codes, inscables, des fonctions :
soit a_un_pre vaut vrai ;
soit jeton_prsent vaut vrai ;
soit est_demandeur vaut vrai et alors a_un_suivant vaut faux.

i
, gestionnaire de P
i
:
i
)

est_demandeur vrai ;
si a_un_pre
envoyer requte(i) pre ;
a_un_pre faux ;
sinon (*ncessairement, jeton_prsent est vrai*)
i
;

21

Requte( j)
si a_un_pre, alors
envoyer requte(j) pre ;
pre j;
sinon
a_un_pre vrai ;
pre j;
si est_demandeur
a_un_suivant vrai ;
suivant j ;
sinon (*ncessairement, jeton_prsent est vrai*)
envoyer jeton j ;
jeton_prsent faux ;

Jeton
jeton_prsent vrai ;
i
; (*ncessairement, celui-ci en est demandeur*)

i
)

est_demandeur faux ;
si a_un_suivant
envoyer jeton suivant ;
jeton_prsent faux ;
a_un_suivant faux ;

Le nombre de messages ncessaires lobtention du jeton est compris entre 0 et n. La
moyenne de ce nombre est de O(ln (n)).
Si le temps de transmission dun message est T, le temps de repos de la section critique alors
quun site est demandeur varie entre 0 et nT, avec une moyenne de O(ln (n)).
2.9. Caractristiques des algorithmes dexclusion mutuelle
Nombre
de messages
Temps inutilis Compteurs
non borns
Maillage
Le Lann (77) non born 0 nT non anneau
Lamport (78) entre 2(n 1)
et 3(n 1)
T 2T oui ? complet
Ricart et Agrawala(81) 2(n 1) T 2T non complet
Carvalho et Roucairol (83) 0 2(n 1) 0 2T oui complet
Chandy et Misra (84) 0 2(n 1) 0 2T non complet
Ricart et Agrawala (83) 0 ou n 0 2T oui ? complet
Naimi et Trehel (87) 0 n
moy. = O(log n)
0 n T
moy. = O(Tlog n)
non variable

Chapitre 3 - Le problme de llection, le
parcours de rseau
Nous traitons dans ce chapitre le problme de llection et nous tudions un mcanisme, les
parcours du rseau, qui peut servir de base de nombreux algorithmes lorsque le maillage est
quelconque.
3.1. Le problme de llection
1. Gnralits
De nombreux algorithmes de contrle, bien que dits distribus, sont en fait centraliss dans le
sens quun processeur particulier joue le rle de coordonnateur et effectue certains services
la demande des autres processeurs ; cest le schma du protocole client-serveur . On peut
ainsi mettre en uvre nimporte quel algorithme centralis dans un systme distribu ; des
changes de messages permettent de calquer les lectures et critures sur des mmoires
communes et de faire des appels de procdure distance .

Ce type dalgorithme prsente un inconvnient majeur : la panne du processus coordonnateur
entrane larrt du fonctionnement du systme. Il faut alors que les processus en tat de
fonctionnement puissent sentendre pour dcider lequel dentre eux prend dsormais le
rle de coordonnateur. Cet accord sobtient grce aux algorithmes dlection. Les protocoles
dlection peuvent aussi tre utiliss chaque fois quun processus, sans ncessairement tre
coordonnateur, joue un rle particulier.

Les processus sont en gnral identifis par des numros et on dcide que le processus qui
joue un rle part est celui qui possde le plus grand (ou le plus petit) numro. Un algorithme
dlection a donc pour objectif de dterminer le processus de plus grand numro.

Nous prsentons un seul algorithme, lalgorithme de Chang et Roberts (1979) ; cet
algorithme, qui utilise un maillage en anneau, ncessite au pire O(n
2
) messages, et en
moyenne O(n.ln(n)), pour une lection entre n processus ; dautres algorithmes, un peu plus
compliqus, utilisant aussi un maillage en anneau, ne ncessitent que O(n.ln(n)) messages au
pire pour le mme travail. Par ailleurs, les algorithmes de parcours qui seront donns dans la
deuxime partie de ce chapitre permettent de dfinir dautres algorithmes dlection utilisant
un maillage quelconque.
24

2. Algorithme de Chang et Roberts (1979)
Le maillage est un anneau logique unidirectionnel, o chaque processus sait adresser un
message son voisin de gauche par la primitive envoyer_voisin_gauche. Un ou plusieurs
processus peuvent dcider de lancer un protocole dlection. Sur chaque site, on trouve :

mon_numro : entier constant qui donne lidentificateur du site ; rappelons que
lalgorithme a pour objectif de dterminer le plus grand de ces numros et de faire
connatre aux diffrents sites la valeur de ce plus grand numro.
plus_grand : variable entire donnant un instant donn le plus grand numro de
processus connu sur le site.
participant : variable boolenne initialise faux, qui passe vrai ds que le processus est
touch par lalgorithme dlection.
vainqueur : variable entire qui, la fin de lexcution, aura pour valeur le plus grand des
numros, cest--dire le numro du processus lu.

Les messages sont de deux types :
les messages de type lection ; un processus envoie un tel message soit quand il dcide de
lancer une lection (il lui fait alors contenir son propre numro), soit quand il devient
participant (il calcule alors plus_grand et fait contenir au message cette valeur), soit
quand, dj participant, il vient dincrmenter plus_grand (il lui fait alors contenir
plus_grand).
les messages de type lu qui font circuler, aprs quil a t dtermin, le plus grand
numro de processus ; un processus qui reoit un message de type lection portant son
numro sait quil est celui de plus grand numro et envoie le premier message de type
lu ; ce message est alors retransmis en faisant le tour de lanneau.

texte excut lors de la dcision de provoquer une lection
participant vrai ;
plus_grand mon_numro ;
envoyer_voisin_gauche (lection, mon_numro) ;

texte excut lors de la rception de (lection, j)
si non participant,
participant vrai ;
plus_grand max(mon_numro, j).
envoyer_voisin_gauche (lection, plus_grand) ;
sinon
si j > plus_grand,
plus_grand j ;
envoyer(lection, plus_grand) ;
sinon si j = mon_numro,
envoyer_voisin_gauche (lu, mon_numro);

texte excut lors de la rception de (lu, j)
vainqueur j ;
participant faux ; (
*
initialisation pour la prochaine lection
*
)
si j mon_numro, envoyer_voisin_gauche (lu, j) ;

25

Un message de type lection nest pas retransmis par un processus participant si le numro
port par le message nest pas suprieur au plus grand numro dj connu sur le site ; un tel
principe sappelle principe de lextinction slective.

La preuve de lalgorithme se fait aisment en vrifiant quun et un seul numro fait le tour de
lanneau laide des messages de type lection : le plus grand des numros.
Du point de vue de la performance en temps, il faut toujours le temps dun tour danneau
entre le moment o le vainqueur sait quil est vainqueur et la fin du protocole ; on peut
cependant distinguer deux cas extrmes :
le futur vainqueur lance en premier (ventuellement en mme temps que dautres
processus) une lection ; il faut alors le temps de la transmission de n messages (le tour de
lanneau) pour quil sache quil est vainqueur.
le futur vainqueur est droite dun unique processus dclenchant llection ; il faudra
alors le temps de n 1 messages pour que le futur vainqueur devienne participant puis le
temps de n messages pour que celui-ci dcouvre quil est vainqueur, soit le temps de la
transmission de 2n 1 messages.
Dans tous les cas, le temps requis est en O(n).

Du point de vue de la performance en nombre de messages, le cas le plus favorable est celui
o seul le futur vainqueur lance llection ; le nombre total de messages envoys est alors 2n.
Le cas le plus dfavorable est celui o les numros sont en ordre dcroissants et tous les
processus lancent llection en mme temps ; il y alors
=
n
i
i
1
=
2
) 1 ( + n n
transferts de messages
pour dterminer le vainqueur (suivis de n messages pour faire tourner linformation). Nous ne
calculons pas ici le nombre moyen (O(n.ln(n))) de transferts de messages.
3.2. Parcours dun rseau
1. Gnralits
De nombreuses applications ncessitent de faire parcourir par des messages le rseau qui
supporte un systme distribu. Certains de ces parcours doivent ncessairement se faire de
faon squentielle (on fait alors en gnral un parcours dit en profondeur dabord) mais la
plupart peuvent se faire de faon parallle, ce qui permet de gagner du temps. Nous tudierons
uniquement une solution donnant un parcours en parallle.
Parmi les applications quon peut construire laide dalgorithmes de parcours, citons :
la diffusion dune information
ltude de la fiabilit du rseau : existence de points darticulation, calcul de la
connectivit
linitialisation des systmes (donner un nom chaque processus alors que ne sont connues
par le systme que les voies de communication)
les problmes dlection
la dtermination dun interblocage
la dtermination de la terminaison (tous les processus sont termins).
Lorsquon effectue un parcours de rseau partir dun site P
r
, on construit une arborescence
dont les sommets sont lensemble des processus et dont la racine est P
r.

26

2. Parcours en parallle
Le hypothses faites sur le rseau sont :
le rseau est non orient (les lignes sont bidirectionnelles) et connexe.
les sites ont tous des noms diffrents ; ces noms sont des entiers naturels.
les sites ne connaissent pas la topologie du rseau ; ils ne connaissent que les noms de
leurs voisins, et les lignes les reliant ces voisins.
les lignes sont fiables.
Le fait que le graphe soit quelconque et que la connaissance du rseau soit locale facilite des
modifications ventuelles du rseau ; la suppression ou lajout dun site ne ncessite que la
redfinition (et la re-compilation) des sites dont le voisinage a t modifi.

Lors dun parcours de graphe, le processus qui a lanc le parcours a souvent besoin dtre
inform de la terminaison du parcours, afin de pouvoir enchaner sur dautres actions.
Lalgorithme que nous proposons atteint cet objectif.
Nous supposons ici quun seul processus, celui de nom r, peut lancer un parcours et que
celui-ci ne peut lancer un parcours que quand le prcdent est termin. Nous laissons au
lecteur le soin de modifier cet algorithme dans le cas o tous les processus peuvent
simultanment lancer un parcours.

Le parcours sert ici diffuser une information issue de r, not info, et collecter un ensemble
dinformations se situant sur les diffrents sites ; on peut par exemple imaginer quil sagit
dadditionner des valeurs entires se trouvant dans les diffrents sites ; on notera info'
linformation existant au dpart sur un site puis collecte au fur et mesure ; dans le cas de
notre exemple, info' sera la somme des entiers dj collects.

Les identificateurs utiliss par le site P
i
sont :
marqu : boolen initialis faux, qui indique si P
i
a dj t atteint par le parcours ;
voisins : ensemble constant dentiers constitu des noms des voisins du sommet i ;
pre : entier qui contiendra (sauf pour P
r
) le pre de P
i
dans larborescence ;
nb_attendus : entier qui donne, aprs que P
i
a t marqu, le nombre de messages que P
i

attend encore avant dindiquer son pre que le parcours est termin dans la branche dont
il est racine.
termin : pour P
r
uniquement , initialise faux.

Tout message commence par lindication du type de ce message. Les messages sont de deux
types :
parcours : un tel message, aprs avoir prcis son type, indique linformation info quil
diffuse, puis le numro du site metteur. Un processus, qui nest pas encore marqu, et qui
reoit (parcours, info, j) sait que j est son pre et doit envoyer un message de type
parcours tous ses voisins autres que son pre ; il initialise sa variable fils lensemble
des noms de ses voisins autres que son pre et le nombre dacquittements attendus au
cardinal de cet ensemble. Sil est dj marqu, il diminue de 1 le nombre de messages
quil attend.
retour : un tel message, aprs avoir prcis son type, indique en seconde position la valeur
de info' ; le site qui reoit ce message utilise info' et les donnes qui se trouvent chez lui
pour actualiser info'. Chaque fois quun processus reoit un message de type retour, il
diminue de 1 le nombre de messages quil attend.

27

Protocole du site P
i

texte excut lors de la dcision de P
r
de lancer un parcours
marqu vrai ;
nb_attendus cardinal (voisins) ;
j voisins, envoyer (parcours, info, r) P
j
;

texte excut lors de la rception de (parcours, info, j)
si marqu, nb_attendus nb_attendus 1 ;
sinon
marqu vrai ;
pre j ;
nb_attendus cardinal (voisins) 1 ;
j voisins pre, envoyer (parcours, info, i) P
j ;

si nb_attendus = 0, envoyer (retour, info') pre

texte excut lors de la rception de (retour, info') par P
i

nb_attendus nb_attendus 1 ;
actualiser info' ;
si nb_attendus = 0, si i r, envoyer (retour, info') pre;
sinon termin vrai ;

Le processus P
r
sait que le parcours est termin quand sa variable nb_attendus vaut 0.
Sur chaque ligne du rseau transite au plus un message de type parcours dans chaque sens ;
sil y a un message de type parcours dans chaque sens, il ny aura pas de message de type
retour, ni dans un sens, ni dans lautre ; sil y a un seul message de type parcours, il y aura un
message de type retour dans lautre sens ; il circule ainsi deux messages sur chaque ligne. Le
nombre de messages changs est donc O(e), o e reprsente le nombre de lignes du rseau.
Si la plus grande distance en nombre de liaisons entre P
r
et les autres sites est d et si le temps
maximum de transfert dun message est , la complexit du temps est O(d, ).

Chapitre 4 - Proprit globale
On appelle proprit globale une proprit qui concerne lensemble des sites. Nous verrons le
cas de linterblocage, de la terminaison et du calcul dun tat dit global.
4.1. Linterblocage
1. Gnralits
Supposons quun processus P
1
attende loccurrence dun vnement qui doit tre produit par
un processus P
2
, que celui-ci attende loccurrence dun vnement qui doit tre produit par un
processus P
3
et quenfin P
3
attende loccurrence dun vnement qui doit tre produit par le
processus P
1
:
les trois processus sont contraints, en labsence dintervention, attendre
ternellement : il y a interblocage ; le mme phnomne peut avoir lieu avec tout ensemble
dau moins deux processus.
tant donn un ensemble de processus participant un systme rparti, on peut considrer ces
processus comme les sommets dun graphe orient appel graphe des attentes : on joint par
un arc un processus P
i
un processus P
j
si le processus P
i
doit attendre pour continuer
sexcuter un vnement produit par P
j
.

P
5
P
2 P
4
P
3
P
1

Il y a interblocage lorsquil existe un circuit
dans ce graphe des attentes ; nanmoins, les
processus de ce circuit ne sont pas les seuls
tre bloqus ; sur lexemple ci-contre, le
processus P
5
se trouve lui aussi bloqu. Tout
processus se trouvant sur un chemin qui
conduit un circuit est bloqu.
Une situation dinterblocage peut se produire en particulier dans les cas suivants :
plusieurs processus se partagent des ressources accs exclusif ;
le systme utilise des primitives de communication synchrones : si P
1
attend P
2
, si P
2

attend P
3
et si P
3
attend P
1
, ces trois processus risquent dattendre longtemps.

Dans ce paragraphe consacr linterblocage, nous nous intresserons uniquement au cas du
partage des ressources. Les ressources doivent tre utilises en exclusion mutuelle et certains
processus doivent utiliser plusieurs ressources simultanment.
Dans les systmes o un risque dinterblocage existe, le problme est dempcher la
formation de circuits dans le graphe des attentes ou bien de dtecter la prsence de tel circuit.
Une technique o on cherche prvenir lapparition dinterblocage est dite a priori, ou encore
30

pessimiste ; une technique o on cherche dtecter une situation dinterblocage pour la faire
disparatre est dite a posteriori, ou encore optimiste.
Nous utilisons ci-dessous le terme de transaction, terme provenant des bases de donnes, pour
dsigner une action faite par un processus ncessitant lutilisation de plusieurs ressources.
2. Prvention de linterblocage dans lallocation de ressources
Les mthodes peuvent tre diffrentes selon quon suppose ou non quune transaction peut
dclarer lavance lensemble des ressources qui lui sont ncessaires.
a) Cas o les ressources ncessaires aux transactions dun mme processus sont fixes.
On suppose ici quun mme processus fera les mmes demandes de ressources pour toutes ses
transactions. Prenons un exemple.
Un processus P
1
utilise toujours simultanment R
1
, R
2
, R
3
.
Un processus P
2
1
, R
3
.
Un processus P
3
1
, R
4
.
Un processus P
4
utilise toujours uniquement R
2
.

On considre alors le graphe ci-contre
appel le graphe des conflits :

P
3
P
2
P
1
P
4

31

Dans ce graphe, un sommet tiquet par P
i
est joint un sommet tiquet par P
j
sil nest pas
possible quune transaction de P
i
soit simultane avec une transaction de P
j
.
Tout algorithme dexclusion mutuelle utilisant des permissions peut alors tre adapt pour
rsoudre le problme ; un processus ne fait des demandes de permission quaux processus qui
lui sont voisins dans le graphe des conflits. Il ne commence une transaction que quand il a
toutes les ressources ncessaires
b) Ressources ordonnes
Nous supposons ici que les processus connaissent lavance les ressources quils vont utiliser
simultanment pour une mme transaction.
On impose un ordre total sur les ressources, ordre dont les processus ont connaissance. Les
processus demandent les ressources qui leur sont ncessaires selon lordre total qui existe sur
celles-ci, ne demandant une ressource que lorsquils ont obtenu la ressource prcdente. Les
ressources se chargent de satisfaire les requtes en suivant la file dattente des requtes
quelles reoivent. Il est clair que ce procd vite linterblocage ; en effet, les ressources
attendues par les processeurs dun chemin du graphe des attentes sont croissantes le long dun
tel chemin.
On peut remarquer que sil nest pas possible que les ressources tiennent jour les files
dattente centralises, on peut mettre en uvre pour chaque ressource un quelconque
algorithme rparti pour assurer lexclusion mutuelle sur chaque ressource ; un processus qui
obtient une ressource la garde tant quelle na pas eu sa disposition les ressources suivantes
qui lui sont ncessaires et termin sa transaction.
c) Construction du graphe des conflits potentiels
On suppose encore que les processus connaissent les besoins en ressources ncessaires une
mme transaction ; il est alors possible dallouer une ressource une transaction que si cette
allocation ne risque pas de conduire un interblocage. Pour cela est construit au fur et
mesure le graphe des conflits potentiels comme indiqu par lexemple suivant ( droite de
chaque vnement est not ltat rsultant du graphe des conflits potentiels) ; supposons que,
dans lordre chronologique :

vnement Graphe des conflits potentiels
une transaction T
1

annonce quelle
dmarre et quelle utilisera des ressources
r
1

et r
2
.

T
1
(r
1
, r
2
)

une transaction T
2

annonce quelle
r
2

et r
3
.

T
1
(r
1
, r
2
)

T
2
(r
2
, r
3
)

une transaction T
3

annonce quelle
r
3

et r
1
.

T
1
(r
1
, r
2
)

T
3
(r
3
, r
1
)

T
2
(r
2
, r
3
)

32

la transaction T
1
fait une requte pour r
1
,
requte accepte

T
1
(r
1
, r
2
)

T
3
(r
3
, r
1
)

T
2
(r
2
, r
3
)

T
1
utilise une ressource dont pourrait avoir
besoin T
3
: T
3
dpend de T
1.

la transaction T
2
2
,
requte accepte.

T
1
(r
1
, r
2
)

T
3
(r
3
, r
1
)

T
2
(r
2
, r
3
)

T
2
utilise une ressource dont pourrait avoir
besoin T
1
: T
1
dpend de T
2
.

la transaction T
3
3

Requte refuse

Si T
3
tait autorise utiliser r
3
, il apparatrait un circuit dans le graphe des conflits potentiels
car alors T
2
dpendrait de T
3
:
lallocation de r
3
est donc refuse, bien que cette ressource soit
disponible.

Soit le contrle est centralis : un processus allocateur reoit toutes les informations, construit
le graphe des conflits potentiels et gre lallocation des ressources. Soit lalgorithme est
distribu et chaque site gre une copie du graphe des conflits ; des mcanismes adquats
doivent tre mis en place pour grer la cohrence des diffrentes copies et assurer ainsi que
tous les sites prennent les mmes dcisions ; cette gestion peut seffectuer par la gestion dune
file dattente pour la modification de loriginal du graphe des conflits.
d) Gestion locale des conflit potentiels
La gestion des copies de ltat global des transactions et de lutilisation des ressources est
lourde. Dans le cas o le choix nest pas celui dun allocateur unique de ressources, chaque
site peut grer uniquement les conflits dans lesquels il risque dtre impliqu. Pour cela, on
utilise un mcanisme destampillage pour tablir une relation dordre total entre les annonces.
Pour liminer le risque dinterblocage, la solution suivante peut tre retenue : chaque
transaction ne peut se voir allouer une ressource libre que si celle-ci ne fait pas partie de
lannonce dune transaction plus ancienne non termine. Reprenons lexemple ci-dessus ; on
suppose que lestampillage fait que lannonce de T
1
prcde lannonce de T
2
qui prcde
lannonce de T
3
; tant que T
1
nest pas termine, T
2
se voit refuser r
2

qui fait partie de
lannonce de T
1
et se met en attente ; T
3

se voit refuser r
1
et r
3
; les trois transactions
sexcutent en fait ici les unes aprs les autres.
Cette mthode rduit le nombre de messages par rapport la construction distribue du
graphe des conflits potentiels car seules les annonces des transactions doivent tre gres et
ordonnes ; les informations concernant lutilisation des ressources ne sont pas utiles.
e) Prvention dynamique
De nombreux algorithmes ne ncessitent pas que les transactions dclarent lavance les
ressources dont elles auront besoin ; les conflits sont alors grs au niveau de la ressource ;
lorsquune ressource est utilise par une transaction T
1
et demande par une transaction T
2
, la
33

dcision prendre est entre deux possibilits : T
2

nobtient pas la ressource et T
1
continue ou
bien T
1
rend la ressource pour la donner T
2
et dans ce cas T
1
est annule; dans ce second cas,
on dit quil y a premption. Lorsquune transaction nobtient pas la ressource, elle peut tre
mise en attente (elle garde les ressources dont elle dispose dj) ou bien annule (elle rend les
ressources dont elle dispose). Dans le cas o une transaction est annule, il faut restituer ltat
dans lequel se trouvait le processus demandeur avant la transaction.
Dans ces mthodes, on estampille les transactions ; nous notons E(T) lestampille dune
transaction T. De faon empcher un phnomne de famine, lorsquune transaction est
abandonne, elle garde la mme estampille pour redmarrer plus tard.
Nous donnons ci-dessous trois exemples dalgorithmes ; le premier est sans premption ; le
second est avec premption ; le troisime est plus sophistiqu de faon minimiser le nombre
des abandons.

Nous supposons quune ressource r est utilise par une transaction T
1
et quune transaction T
2

demande cette ressource ; les ractions de chacun des algorithmes sont dcrites ci-dessous.

Algorithme Wait-Die sans premption

si E(T
1
) < E(T
2
) alors annuler T
2
(Die)
sinon bloquer T
2
(Wait)
(*dans tous les cas T
1
garde la ressource*)

Le long dun chemin du graphe des attentes, les estampilles des transactions sont croissantes,
ce qui interdit les circuits dans ce graphe.

Algorithme Wait-Die avec premption

si E(T
1
) < E(T
2
) alors bloquer T
2
(Wait)
(*T
1
sinon annuler T
1
(Die)
(*T
2
obtient la ressource*)
Dans cette version, une transaction nattend jamais une ressource utilise par une transaction
plus rcente. Le long dun chemin du graphe des attentes, les estampilles des transactions sont
dcroissantes, ce qui interdit les circuits dans ce graphe.

Algorithme Wound-Wait
Lallocateur dune ressource doit, pour pouvoir prendre une dcision, connatre les
transactions qui attendent et celles qui sont blesses (une transaction est blesse si une
transaction plus ancienne est en attente dune ressource quelle utilise). Au dpart, aucune
transaction nest blesse.

34

si E(T
1
) < E(T
2
) alors
si T
2
nest pas blesse, alors bloquer T
2

sinon annuler T
2

(* T
1
garde la ressource *)
sinon
si T
1
est bloque alors annuler T
1
(*T
2
obtient la ressource*)
sinon blesser T
1

et bloquer T
2
(*T
1
Dans le graphe des attentes, si on a un arc (T, T) avec E(T) < E(T), alors il ny a pas darc
(T, T) avec E(T) > E(T). Sur un chemin du graphe des attentes, les estampilles des
transactions sont dabord croissantes, puis dcroissantes et les extrmits des arcs
correspondant des estampilles dcroissantes sont des transactions blesses ; par ailleurs, on
najoute pas darc dune transaction blesse une transaction de plus petite estampille ni
dune transaction une transaction de plus grande estampille et bloque. On peut alors
vrifier quil ny aura pas de circuit dans le graphe des attentes.
3. Dtection de linterblocage dans lallocation de ressources
Le principe de dtection est unique : dterminer des circuits dans le graphe des attentes. Cette
dtection peut tre faite soit par un seul site, soit par chaque site qui tient jour une copie du
graphe des attentes, soit par une coopration de lensemble des sites. Nous allons expliciter
plus bas lalgorithme de Mitchell et Merrit qui donne un exemple dune telle coopration.
Lorsquun interblocage est repr, la solution adopte est de contraindre un processus
participant linterblocage rendre les ressources quil utilise ; celui-ci doit alors retrouver
ltat quil avait avant sa demande de ressource.

Il faut se mfier de la dtection de faux interblocages. Prenons lexemple suivant :
un processus P
1
verrouille une ressource r
1

et attend une ressource r
2

un processus P
2
verrouille une ressource r
2

et attend une ressource r
3

un processus P
3
quasi-simultanment libre r
3

et demande laccs r
1

Si le message de libration de r
3
trane par rapport celui de la demande dutilisation de
r
1
, un interblocage de ces trois processus peut tre dtect tort ; linterblocage naurait
rellement lieu que si P
3
ne pouvait librer r
3
quaprs avoir dispos de r
1
. Cette remarque
conduit des algorithmes o on conclut un interblocage lorsquun circuit dans le graphe des
attentes existe de faon continue pendant un temps donn (de tels algorithmes sont
envisageables lorsquon connat une borne suprieure sur les temps de communication).
Lalgorithme de Mitchell et Merrit (1984)
On suppose que les ressources sont demandes une une : dans le graphe des attentes, tout
processus a un degr extrieur de 0 (sil nattend rien) ou 1 (sil attend une ressource).
On suppose que chaque processus P
i
a un nom propre quon peut not i et par ailleurs gre un
entier p
i
initialis 0, qui lui sert enregistrer, lorsquil attend, le numro dordre de son
attente. Le couple (i, p
i
) constitue l identificateur propre de P
i
un instant donn. Lide
est de faire circuler certains identificateurs propres en suivant ( lenvers) les arcs du graphe
des attentes pour observer si un identificateur revient son propritaire.
Pour faire circuler les identificateurs propres, chaque processus est dpositaire par ailleurs
dun identificateur qui nest pas forcment le sien appel l identificateur circulant .
35

Lorsquun processus P
i
commence attendre quun autre processus P
j
ait libr une
ressource, il pose p
i
p
i
+ 1 et change en consquence son identificateur propre. Par ailleurs,
il recopie son identificateur propre dans son identificateur circulant.
Lorsquun processus attend, il demande de temps autre son identificateur circulant celui
qui le fait attendre. Il prend alors comme nouvel identificateur circulant le plus grand entre le
sien et celui dont il vient dtre inform.
Si P
i
appartient un circuit du graphe des attentes et a le plus grand identificateur propre de
ce circuit, celui-ci finira par faire le tour ; le processus P
i
, lors dune demande celui qui le
fait attendre de son identificateur circulant, retrouvera son identificateur propre et en dduira
quil y a interblocage. On voit ainsi que lalgorithme a la proprit de vivacit : sil y a
interblocage, celui-ci sera dtect.
Il est un peu moins facile de vrifier que lalgorithme est exact, cest--dire que si un
processus conclut linterblocage, cest quil y a bien interblocage. Il faut pour cela
remarquer que, ncessairement, si P
j
a pour identificateur circulant lidentificateur propre
dun processus P
i
en attente, alors P
j
ne pourra pas tre dbloqu avant que P
i
le soit.
4.2. La terminaison
Le problme de la terminaison est celui de la dtection de la fin dun calcul rparti. Pendant le
fonctionnement dun travail rparti, chaque processus (ou site) est soit dans un tat actif sil
est en train dexcuter du code, soit dans un tat passif sil est en attente ou sil a termin.
Pour quil y ait terminaison, il ne suffit pas que tous les processus soient passifs ; en effet, un
message en transit peut relancer le calcul. La terminaison nest garantie que si la fois tous
les processus sont passifs et aucun message nest en transit.
La terminaison, comme linterblocage, est une proprit stable : une fois la proprit vraie,
elle restera toujours vraie au cours du temps.

Considrons lexemple dun mauvais algorithme qui chercherait dtecter la terminaison
dun systme comportant quatre sites S
1
, S
2
, S
3
, S
4
;
chaque site est dans un tat passif ou
actif ; lalgorithme consiste faire circuler un jeton selon une structure danneau S
1

S
2

S
3

S
4

S
1
;
lorsquun site est passif et possde le jeton, il lenvoie au site suivant ; si le
jeton, parti de S
1
, revient S
1
, la terminaison est dcrte ; or, supposons que la succession
des vnements soit la suivante :
1) S
1
, passif, envoie le jeton S
2
.
2) S
2
, passif, reoit le jeton et le renvoie S
3
.
3)

S
4
envoie un message S
2

pour lui demander un calcul : S
4
devient passif, en attente.
4) S
3
4
.
5) S
2
, recevant le message de S
4
, devient actif.
6) S
4
1
.
7) S
1

reoit le jeton et conclut la terminaison

36

S
1
S
2
S
3 S
4
1) jeton
2) jeton
5) jeton
4) jeton
3) message

Diffrents algorithmes peuvent servir dtecter la terminaison ; le choix de lalgorithme
utilis dpend des hypothses faites sur les voies et sur le mode (synchrone ou asynchrone) de
communication
1. Communications uniquement suivant un anneau unidirectionnel
Nous supposons ici que les communications ont uniquement lieu suivant un anneau
unidirectionnel et que les messages ne peuvent pas se doubler ; la dtection de la terminaison
se fait avec un jeton circulant. On ne peut pas conclure la terminaison lorsque le jeton fait
un tour complet ou mme plusieurs tours sans rencontrer de processus actif ; en effet,
processus actifs et jetons pourrait se courir aprs autour de lanneau la mme vitesse ; il
faut donc prvoir un mcanisme supplmentaire. La terminaison est dtecte quand le jeton a
pu faire un tour complet, partant dun site quelconque S et revenant au site S, de telle sorte
que :
le jeton na rencontr que des processus passifs
S est rest passif durant le tour.
Pour savoir si un processus est rest passif entre deux passages du jeton, on attribue une
couleur , noire ou blanche, aux processus ; un processus activ devient (sil ne lest dj)
blanc ; le jeton, sil trouve le processus blanc et inactif, le met noir ; seul le jeton peut
changer de blanc noir la couleur dun processus ; le jeton est muni dun compteur qui
enregistre le nombre de processus conscutifs trouvs noir (le compteur est remis zro
lorsque le jeton rencontre un processus actif) ; lorsque ce nombre devient gal n, o n est le
nombre de processus, si le jeton arrive sur un site passif, il y a terminaison.
On appelle dbut dun traitement le tout dbut du processus ou bien larrive dun message
alors que le processus est passif, message qui rveille donc le processus. Lalgorithme est
le suivant :

Nous donnons deux versions de lalgorithme.
Le jeton est envoy lorsquon veut dtecter la terminaison au dpart un site quelconque.
.
texte excut lors du dbut dun traitement
tat actif ;

texte excut lors de la fin dun traitement
tat passif ;
si (jeton_prsent)
envoyer jeton(1) ;
couleur noir
jeton_present faux ;

37

texte excut lors de la rception de (jeton, j)
si tat = actif, jeton_prsent vrai ;
sinon si (couleur = noir)
si ( j = n) terminaison dtecte ;
sinon envoyer jeton(j + 1) ;
sinon couleur noir ;
envoyer_jeton(0) ;

Si les communications se font suivant une topologie plus complexe qui reste fortement
connexe, et si lon suppose toujours labsence de dsquencement, lalgorithme peut tre
modifi comme suit ; on dfinit un circuit passant au moins une fois par chaque voie de
communication ; chaque site connat son successeur sur le circuit ; le jeton, lorsquil est
envoy, est envoy son successeur ; le nombre n de lalgorithme prcdent est remplac par
la longueur du circuit ; toute rception de message autre que le jeton active le site rcepteur.
Lalgorithme permet alors de dtecter que tout site est passif et quaucun message nest en transit.
2. Premier algorithme de Mattern
On utilise un observateur qui va essayer de conclure qu un moment donn aucun message
nest en circulation et tout processus est passif.
Un observateur envoie sur chacun des sites P
i
une requte pour que ceux-ci indiquent les
nombres E
i
et R
i
des messages respectivement reus et envoys depuis le dbut et attend les
rsultats. On dit ainsi quil a effectu une vague dobservation.
E', R'
P
1

Vague : E', R'
Vague : E", R"
E*, R*
f'
d" d'
Passage de la vague
observateur
instant t
P
3

P
2

f"
(E
1
', R
1
')

Lobservateur calcule alors :
E =
=
n
i
i
E
1
, R =
=
n
i
i
R
1

Si les estimations des nombres E
i
et R
i
avaient t effectues exactement au mme moment
physique, lobservateur pourrait conclure, en cas dgalit, quaucun message ntait en
transit cet instant. Mais ce nest pas le cas.
En consquence, lobservateur fait deux vagues dobservation, ne lanant la seconde vague
que lorsquil a obtenu tous les rsultats de la premire. On note E' et R' les rsultats de la
premire vague, E" et R" les rsultats de la seconde vague. On note t un instant entre la fin de
la premire vague et le dbut de la seconde. On note enfin E* et R* les nombres exacts de
messages qui ont t reus et envoys avant t.
38

On a : R' R* E* E".
Si l'observateur constate E" = R', il peut alors conclure que R* = E* et donc qu'aucun message
n'tait en transit l'instant t.

3. Second algorithme de Mattern pour la terminaison (1991)
Dans la version explicite ci-dessous, un seul site est autorise lancer un calcul de
terminaison, ce site est nomm r. Ce site r ne lance le calcul que sil est passif.
On fait lhypothse que les lignes sont fifos.
Des message nomms ci-dessous information_dtat peuvent tre envoys dun site son pre
et pourront navoir que deux valeurs : passif ou actif.
Un site lance un parcours pour tester la terminaison en envoyant un message
dtection_de_terminaison chacun de ses voisins ; chaque site atteint par le parcours
(recevant un premier message dtection_de_terminaison) dcide que celui qui lui a envoy ce
message est son pre et envoie un message dtection_de_terminaison chacun de ses voisins
sauf son pre. Si un site est actif la premire rception dun message
dtection_de_terminaison, son tat (variable du site) est initialis actif, sinon son tat est
initialis passif. Un site qui apprend, par un message information_dtat, quun de ses
descendants est actif ou bien qui reoit un message autre que dtection_de_terminaison ou
information_dtat (cest--dire un message qui le rend actif) alors quil a dj t touch par
le parcours pose quil est aussi actif. Ds quun site ayant dj t touch par le parcours est
actif, si ce nest pas le site r, il informe son pre de cet tat et sinon, il conclut la non
terminaison ; il ne fera plus rien (relativement la dtection de la terminaison) la rception
des messages ultrieurs. Lorsquun site passif a reu de tous ses voisins autres que son pre
soit un message dtection_de_terminaison soit un message information_dtat portant la
valeur passif (message qui vient alors dun de ses fils dans larborescence du parcours), si ce
site nest pas r, il envoie un message information_dtat(passif) son pre, sinon il conclut
la terminaison.
Quand le site r conclut la terminaison, il en informe tous les autres sites.
Les variables utilises sont :
calcul_ commenc qui peut prendre les valeurs vrai ou faux :
tat qui peut prendre les valeurs passif ou actif ;
nb_acq qui est une variable entire ;
pre qui sera un nom de site ;

Sur le site i :
Dcision de dtecter la terminaison (* uniquement pour le site r *)
envoyer tous ses voisins un message dtection_de_terminaison(i) ;
nb_acq nombre de voisins 1 ;
calcul_ commenc vrai ;

Rception dun message dtection_de_terminaison (j)
si (non calcul_ commenc)
pre j ;
calcul_ commenc vrai ;
envoyer tous ses voisins sauf pre un message dtection_de_terminaison(i) ;
si le site est actif,
tat actif ;
envoyer information_dtat (actif) pre ;
39

sinon
tat passif ;
nb_acq nombre de voisins 1 ;
sinon si (tat = passif)
nb_acq nb_acq 1 ;
si (nb_acq = 0)
si (i r) envoyer information_dtat (passif) pre ;
sinon conclure la terminaison ;

Rception de message information_dtat(tat_fils) (* vient dun de ses fils *)
si (tat = passif)
nb_acq nb_acq 1 ;
si (tat_fils = actif)
tat actif ;
si (i r) envoyer information_dtat (actif) pre ;
sinon conclure la non terminaison ;
sinon si (nb_acq = 0)
si (i r) envoyer information_dtat (passif) pre ;
sinon conclure la terminaison ;

Rception dun message autre que information_dtat ou dtection_de_terminaison
si (calcul_ commenc) et (tat = passif)
tat actif ;
si (i r) envoyer information_dtat(actif) pre ;
sinon conclure la non terminaison ;
On laisse au lecteur la vrification de lexactitude de cet algorithme.
4.3. tat global cohrent
Nous allons voir comment calculer ce quon appelle tat global cohrent du systme. Un tel
calcul permet de calculer et mmoriser si ncessaire un point de reprise cohrent ; il permet
aussi danalyser la situation globale pour dterminer certaines proprits.

Ltat local dun site est, un instant donn, une description exhaustive de ltat du site, ce
qui correspond essentiellement lensemble des valeurs de ses variables.
On appelle tat global cohrent du systme, lensemble constitu de :
pour chaque site i : un tat local du site i not e_local
i
,
pour chaque canal (i, j) : lensemble des messages de i vers j qui ont t mis de i avant le
calcul de e_local
i
et reu en j aprs le calcul de e_local
j
,
et tel quaucun message dun site i un site j nait t mis de i aprs le calcul de e_local
i
et
ait t reu en j avant le calcul de e_local
j
.
40

e_local
1

e_local
3

e_local
2

P
1

P
2

P
3

m
1

m
4

m
3

m
2

m
5

Pour lexemple reprsent ci-dessus :
e_canal
1, 2
= {m
3
}
e_canal
2, 3
= {m
2
,

m
4
}
e_canal
1, 3
= e_canal
2, 1
= e_canal
3, 1
= e_canal
3, 2
=
1. Algorithme de Chandy et Lamport
Cet algorithme, qui a pour objectif de calculer un tat global cohrent dun systme, fait les
hypothses suivantes :
les canaux de communications sont fifos et fiables ;
les canaux de communications peuvent tre unidirectionnels ;
le graphe est fortement connexe ;
il ny a simultanment quun seul calcul dtat global ;

Le calcul de ltat global peut tre dmarr par un des sites concerns par ce calcul ; les
informations peuvent alors circuler laide dun parcours dynamique du type de ce qui est
expliqu dans le chapitre prcdent. On donne dabord une version un peu plus simple : on
suppose quil y a un site supplmentaire, dit site collecteur, qui seul lance le calcul de ltat
global par des envois de messages aux diffrents sites ; ceux-ci envoient les informations
concernant ce calcul directement au site collecteur.

Le principe de cet algorithme est fond sur lutilisation de messages particuliers appels
marqueurs :
au moment o un site calcule son tat local, la demande du site collecteur, ou bien
lorsquil reoit un marqueur dun de ses voisins, il envoie un marqueur chacun de ses
voisins extrieurs ;
un site i ayant calcul son tat local note pour chacun de ses voisins intrieurs j dans ltat
du canal (j, i) tous les messages reus de j jusqu ce quil reoive de celui-ci le
marqueur ; il aura alors bien not tous les messages partis de j avant que celui-ci calcule
son tat local et arriv aprs que lui-mme ait fait ce calcul.
Les variables utiliss par le site i sont :
e_local
i
, destin contenir un tat local du site ;
Pour tout voisin intrieur j, reu_marqueur(j) ;
e_canal
j, i
: liste de messages reus de j par i ;
tat_local_not: variable boolenne initialise faux.
41

Le pseudo-code des fonctions utilises par le site P
i
est donn ci-dessous.
Dpart local du calcul
e_local
i
rsultat du calcul de ltat local ;
tat_ local_ not vrai ;
Pour tout voisin intrieur j :
e_canal
j, i
;
reu_marqueur(j) faux ;
Pour tout voisin extrieur j, envoyer marqueur j ;

Rception de la demande du collecteur de participation au calcul de ltat global
si (non tat_ local_ not), dpart local du calcul ; (* fonction ci-dessus *)

Rception dun marqueur venant de j
si (non tat_ local_ not) dpart local du calcul ; (* fonction ci-dessus *)
reu _marqueur(j) vrai ;
si (pour tout voisin intrieur j, reu _marqueur(j))
envoyer au site collecteur
{ e_local
i
et, pour tout voisin intrieur j, e_canal
j, i
} ;

Rception dun message autre que le marqueur m venant de j
si (tat_local_not et non reu_marqueur (j))
e_canal
j, i
e_canal
j, i
m ;

On peut adapter lalgorithme Chandy et Lamport de pour que le site collecteur soit un des
sites participant au calcul et non un site supplmentaire ; les lignes doivent dans ce cas tre
bidirectionnelles (au moins ci-dessous en ce qui concerne lenvoi dun message dun site
son pre ). On utilise alors un parcours linitiative dun site r qui commence par envoyer
un marqueur chacun de ses voisins ;
un site recevant le marqueur dun site j pour la premire fois note son tat local, note
que j est son pre dans ce parcours et envoie des marqueurs tous ses voisins ;
un site recevant dun de ses voisins un marqueur alors quil a dj not son tat global
note que ce marqueur est arriv ;
un site i recevant un message dun site j entre le moment o il a calcul son tat global
et celui o il reoit le marqueur de j note ce message dans ltat de la ligne (j, i) ;
aprs avoir reu les marqueurs de tous ses voisins, un site i fait remonter son pre
toutes les informations quil a rcoltes (son tat local et ltat des lignes adjacentes) ;
le pre fera son tour remonter ces informations son propre pre jusqu ce que les
information du site i soit arrives la racine.
La seule diffrence avec la version comportant un site collecteur est la faon de diffuser la
dcision du calcul de ltat global et la faon de rcolter en un seul site le rsultat du calcul.
Cet algorithme peut facilement tre adapt pour dtecter la terminaison ; il faut pour que la
terminaison soit tablie que tous les sites soient passifs quand ils reoivent la demande du
collecteur puis quils ne reoivent aucun message avant davoir reu tous les marqueurs de ses
voisins.
2. Principe de lalgorithme de Mattern (1988)
Cet algorithme a encore pour objectif de calculer un tat global cohrent.
42

On nutilise plus de marqueurs ; il nest pas utile de supposer que les lignes sont fifos.
On explicite une version avec un site collecteur ; on pourrait comme pour lalgorithme de
Chandy et Lamport utilis un parcours partir dun des sites du systme.
Chaque site a une couleur ; il est noir avant le calcul de son tat local, rouge aprs.
Chaque message est marqu de la couleur du site metteur. Un site noir qui reoit un message
rouge calcule son tat local et devient rouge ; il fait cela avant de tenir compte du message
quil vient de recevoir ; il envoie son tat local au site collecteur ainsi que la diffrence entre
le nombre de messages quil a mis et le nombre de messages quil a reus depuis le dbut du
processus.
Quand le site collecteur possde tous les tats locaux et toutes les diffrences, il calcule en
sommant ces diffrences le nombre de messages en transit ; un site rouge envoie au fur et
mesure au collecteur tous les messages noirs quil reoit ainsi que le canal correspondant ; le
collecteur saura quand le calcul est termin : ce sera quand il aura reu un nombre de
messages gal la somme quil a calcule.

Bibliographie
Algorithmique du paralllisme ; le problme de l'exclusion mutuelle (Michel
Raynal,1984, Dunod)
Algorithmes distribus et protocoles (1985, Michel Raynal, Eyrolles)
Systmes rpartis et rseaux (Michel Raynal, 1987, Eyrolles)
Synchronisation et tat global dans les systmes rpartis (Michel Raynal, 1992,
Eyrolles)
Construction des systmes d'exploitation rpartis (ouvrage collectif, 1991, collection
didactique de l'INRIA).

Poly

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Poly

Hochgeladen von

Copyright:

Verfügbare Formate

ALGORITHMIQUE

Das könnte Ihnen auch gefallen