Livre SR

Prcis de rpartition
Dpartement Informatique et Mathmatiques appliques

Grard Padiou
23 novembre 2010
Prambule
Le document suivant nest quun rsum trs condens de ce que lon appelle la rpartition dans le
domaine de linformatique. De surcrot, ne seront envisager que deux aspects : dune part, lalgorithmique
rpartie qui a donn naissance tout un courant de recherche dalgorithmes nouveaux pour programmer des
applications rparties, et dautre part, quelques services de base qui existent maintenant dans la plupart des
systmes dexploitation ou intergiciels prenant en compte la rpartition.
Pour les lecteurs intresss, la lecture des livres suivants est recommande :
pour laspect algorithmique :
Un premier essai de bonne facture :
Michel Raynal, Algorithmes distribus et protocoles, ditions Eyrolles, 1985.
Une suite intressante :
Michel Raynal, Synchronisation et tat global dans les systmes rpartis et Gestion des donnes
rparties, ditions Eyrolles, 1992.
La bible des algorithmes rpartis par une sommit du domaine, Nancy A. Lynch. Le formalisme
utilis pour la description des algorithmes est cependant dicile daccs :
Nancy A. Lynch, Distributed algorithms, Morgan Kaufmann Publichers, Inc., 1996.
pour laspect systmes rpartis :
Une bonne introduction sur les aspects systme dexploitation :
Pradeep Kumar Sinha, Distributed Operating Systems, IEEE Computer society press, 1996.
Un livre de base trs complet :
Sape Mullender, Distributed Systems, ACM Press Frontier Series, Addison Wesley, 1993.
Un livre trs complet, orient systme , bien crit et facile daccs :
George Coulouris, Jean Dollimore et Tim Kindberg, Distributed Systems : concepts and design, Third
Edition, Pearson Education Limited, 2001.
Une bible sur la tolrance aux fautes dans les systmes rpartis :
Kenneth P. Birman, Building secure and reliable network applications, Manning Publications Co.,
1996.
Et pour les lecteurs intresss par la simulation rpartie :
Richard M. Fujimoto, Parallel and distributed simulation systems, Wiley series on Parallel and
distributed computing, John Wiley & sons, Inc., 2000.
Remerciements
Ces quelques pages ne seraient pas ce quelles sont aujourdhui sans les nombreux relecteurs ou relectrices
qui ont dtect les erreurs, oublis, points obscurs tout au long des mises jour annuelles.
Il y a bien sr parmi eux des gnrations dlves du dpartement, mais aussi, les collgues qui ont
particip lenseignement des systmes dexploitation, des intergiciels et des systmes parallles de faon
rcurrente ou temporaire. En tout premier lieu, je tiens remercier Philippe Quinnec, Philippe Mauran et
Michel Charpentier pour leurs critiques toujours constructives.
Prcis de rpartition Dpartement Informatique et Mathmatiques appliques 1
Table des matires
1 Dnition et problmatique 7
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 Les pines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.1 Pas dtat global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.2 Pas dhorloge globale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.3 Fiablilit relative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.4 Scurit relative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.5 Non-dterminisme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3 Les parfums. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.1 Partage et Mise disposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.2 Rpartition gographique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.3 Autres avantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4 La recherche de solutions (Conceptualiser, comprendre, exprimenter) . . . . . . . . . . . . . 10
1.4.1 La thorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4.2 Lalgorithmique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4.3 Les langages de programmation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4.4 Les systmes dexploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4.5 Les environnements dexcution rpartie (middleware) . . . . . . . . . . . . . . . . . . 12
1.5 Principes de conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.5.1 Transparence daccs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.5.2 Transparence de localisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.5.3 Transparence du partage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.5.4 Transparence de la rplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.5.5 Transparence des fautes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.5.6 Transparence de la migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.5.7 Transparence de charge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.5.8 Transparence dchelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.6 Exemple de rpartition : Variations sur un thme de location . . . . . . . . . . . . . . . . . . 15
1.6.1 Exposition du problme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.6.2 Le contrle des mouvements de vhicules . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.6.3 Enrichissement du systme (Plusieurs orchestres) . . . . . . . . . . . . . . . . . . . . . 18
1.6.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.6.5 Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
I Algorithmique rpartie 21
2 Les principes 23
2.1 Modlisation de la rpartition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1.1 Processus communiquant par messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3
2.1.2 Formalisation du modle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1.3 Mises en uvre du modle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2 Le modle standard de lalgorithmique rpartie . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.1 Structuration dun programme rparti . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.2 Le chronogramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.3 Reprsentation dun calcul rparti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.4 La causalit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2.5 Description des algorithmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.6 Classes dalgorithmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.7 Flots de contrle rparti (ou comment mettre de lordre dans les messages) . . . . . . 30
2.2.8 valuation de la complexit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.2.9 Un exemple dalgorithme : le problme de llection . . . . . . . . . . . . . . . . . . . 35
2.3 Au-del du modle standard (ou comment oublier les messages) . . . . . . . . . . . . . . . . . 37
3 Temps et causalit 39
3.1 Datation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.1.1 La datation Temps rel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.1.2 Datation Temps logique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2 Protocoles dordre causal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2.1 Implantation du protocole dans le cas point point . . . . . . . . . . . . . . . . . . . 44
3.2.2 Implantation du protocole dans la cas de la diusion . . . . . . . . . . . . . . . . . . . 46
3.3 Tolrance aux fautes : modle dexcution ISIS, HORUS . . . . . . . . . . . . . . . . . . . . . 47
3.3.1 Groupe de processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.3.2 Les solutions traditionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.3.3 Le synchronisme virtuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.3.4 La bote outils Isis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.3.5 Programmer avec Isis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.3.6 Horus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.3.7 Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4 Synchronisation et supervision 59
4.1 Lexclusion mutuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.1.1 Rappel de la spcication du problme . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.1.2 Lutilisation dun jeton circulant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.1.3 Les algorithmes base de permission . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.2 Le problme de la terminaison dun calcul rparti . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.2.1 La notion de calcul diusant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.2.2 Spcication du problme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.2.3 Algorithme fond sur la gestion dun crdit (Mattern) . . . . . . . . . . . . . . . . . . 63
4.2.4 Algorithme fond sur la gestion de compteurs (Mattern) . . . . . . . . . . . . . . . . . 64
4.2.5 Algorithme fond sur la notion de chemin rparti . . . . . . . . . . . . . . . . . . . . . 65
4.3 Interblocage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.3.1 Rappel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.3.2 Interblocage des communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.3.3 Un algorithme de dtection (Chandy et Misra) . . . . . . . . . . . . . . . . . . . . . . 70
4.4 Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
II Systmes et services rpartis 73
5 Les services de base 75
5.1 Calcul dun tat global : prise de clich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.1.2 Notion de coupure cohrente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.1.3 Un algorithme de prise de clich (Chandy et Lamport) . . . . . . . . . . . . . . . . . . 76
5.2 Le problme du consensus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.2.1 Spcication du problme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.2.2 Les dirents contextes de rsolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.2.3 Preuve de limpossibilit du consensus en asynchrone . . . . . . . . . . . . . . . . . . . 78
5.2.4 Un algorithme simple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.2.5 Quelques problmes voisins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6 Conclusion 83
Appendices 85
A Quelques sujets dexamens avec ou sans correction. . . 87
A.1 Causalit, Horloge et Prise de clich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
A.1.1 Causalit (4 points) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
A.1.2 Une horloge minimaliste (8 points) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
A.1.3 Prise de clich global(8 points) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
A.2 Horloge et causalit directe (daprs Vilay K. Garg) . . . . . . . . . . . . . . . . . . . . . . . 90
A.3 Causalit et horloges de Mattern, Interblocage et terminaison . . . . . . . . . . . . . . . . . . 93
A.3.1 Causalit et horloges de Mattern (10 points) . . . . . . . . . . . . . . . . . . . . . . . 93
A.3.2 Interblocage et terminaison dans un calcul rparti (11 points) . . . . . . . . . . . . . . 94
A.4 Clichs et datation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
A.4.1 Proprit de sret : cohrence dun clich global (6 points) . . . . . . . . . . . . . . . 95
A.4.2 Datation des clichs locaux (8 points) . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
A.4.3 Proprit de vivacit : collecte de clichs globaux (6 points) . . . . . . . . . . . . . . . 96
A.5 Flux multimedia et agents mobiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
A.5.1 Quelques problmes de causalit entre ux multimedia . . . . . . . . . . . . . . . . . . 97
A.5.2 Rencontres entre agents mobiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
A.6 Datation causale et simulation rpartie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
A.6.1 Causalit et horloges de Mattern (10 points) . . . . . . . . . . . . . . . . . . . . . . . 102
A.6.2 Simulation parallle du trac arien (10 points) . . . . . . . . . . . . . . . . . . . . . 102
Chapitre 1
Dnition et problmatique
1.1 Introduction
La rpartition des applications informatiques fait lobjet dun fort dveloppement depuis une vingtaine
dannes. Cet essor sest accentu avec les progrs technologiques des rseaux de tlcommunication. En
eet, les applications rparties doivent leur naissance en tout premier lieu au mariage de linformatique et
des tlcommunications.
Un point anecdotique concerne la terminologie. Doit-on parler de systmes rpartis ou de systmes dis-
tribus. Les construteurs dordinateurs ou de rseaux utilisent plutt le terme distribu. Les spcialistes
du logiciel prfrent le terme rparti . Appartenant cette confrrie, jutiliserai donc le mot rpartition
et ses drivs. De toute faon, lobjet de ce petit prcis est justement de donner une smantique prcise
ces termes.
1.2 Les pines. . .
La problmatique de la rpartition est ne avec lide de faire communiquer des ordinateurs via un rseau
de communication. Par simple change de messages, il est en eet possible de dvelopper des applications
qui peuvent disposer de lensemble des ressources de larchitecture compose des nuds ordinateurs et
du rseau.
1
La puissance et lintrt dune telle architecture rpartie est videmment troitement lie la
capacit de communication oerte par le rseau. De ce point de vue, les progrs technologiques raliss en
la matire ont largement contribu au dveloppement rapides des applications rparties.
Reste le problme du dveloppement, de la programmation des applications rparties. En eet, la concep-
tion dapplications rparties a soulev de nombreux problmes. Aujourdhui, des principes et concepts, mais
aussi des langages, des systmes dexploitation, des environnements sont disponibles. Ils sont le rsultat dune
vingtaine dannes de maturation travers des centaines de projets de recherche. Tous les problmes ne sont
pourtant pas encore rsolus et les applications futures soulveront sans doute de nouveaux ds.
Une question essentielle est de percevoir pourquoi un tel eort de recherche a t ncessaire. Autre-
ment dit, pourquoi et en quoi la programmation dapplications rparties se distingue dune application
centralise ?
Lorigine des dicults tient deux hypothses perdues et deux proprits aaiblies.
Pas dtat global
Pas dhorloge globale
Fiabilit relative
Scurit relative
1. Il faut bien remarquer que cette dnition exclut une architecture compose dun ordinateur et de terminaux de sai-
sie/achage, mme si ceux-ci sont distants.
7
1.2.1 Pas dtat global
Dans une architecture rpartie, un nud ne possde pas une connaissance immdiate exacte de ltat
dun autre nud. En eet, cette connaissance passe par lchange dun message qui introduit obligatoirement
un dlai. Un nud connat son tat local et na quune connaissance du pass (certes parfois trs proche)
des autres. Cette dicult conduira la recherche dalgorithmes qui permettent de construire des clichs
globaux qui reprsenteront un tat pass possible de lapplication.
1.2.2 Pas dhorloge globale
Chaque nud possde sa propre horloge pour dater les vnements qui lui sont locaux. Par consquent, si
les horloges indpendantes de chaque nud ne sont pas parfaitement synchronises, lordre des vnements
rpartis dans lapplication nest pas dductible partir des datations locales. Cette dicult conduira
dnir des datations logiques qui permettent de corriger ce problme.
Ces deux proprits augmentent fondamentalement la dicult de comprhension et danalyse des appli-
cations rparties.
Deux autres proprits doivent tre prises en compte, en loccurrence, la abilit et la scurit.
1.2.3 Fiablilit relative
Une architecture rpartie est compose de nuds actifs dont le fonctionnement correct est relativement
indpendant. Si deux nuds sont simplement relis par un rseau de communication, larrt de lun est
gnralement indpendant de larrt de lautre.
2
Contrairement aux systmes centraliss, un systme rparti
peut donc tolrer la dfaillance de certains de ses lments et continuer assurer certains services ses
usagers. Cependant, larrt dun site parmi un nombre lev, contrairement une unit isole, nest pas
un vnement exceptionnel. Par consquent, il faudra que le concepteur prenne en compte ce risque non-
ngligeable de dfaillance. Une architecture rpartie est une bonne base pour dvelopper une application
tolrante aux fautes, mais le traitement des dfaillances doit y tre soigneusement tudi.
1.2.4 Scurit relative
Une architecture rpartie est plus dicile protger contre les malversations quune architecture centra-
lise. Ceci pour deux raisons :
les points daccs aux ressources du systme global sont multiples et souvent hors les murs . Autre-
ment dit, lutilisateur doit tre authenti.
le rseau de communication est un point daccs potentiel pour toute tentative dintrusion.
Plus gnralement, les nuds connects peuvent apparatre et disparatre dynamiquement et la congu-
ration globale voluer dynamiquement au cours du temps. Ceci peut conduire ne pas connatre exactement
la totalit de larchitecture rpartie. Cette tendance est de plus en plus forte avec les possibilits de connexion
via des ordinateurs portables.
1.2.5 Non-dterminisme
Enn, il ne faut pas oublier quune application rpartie est aussi une application parallle asynchrone. Les
nuds sexcutent en parallle et chaque nud peut lui-mme comporter plusieurs activits parallles (pro-
cessus, threads). Il existe ainsi un non-dterminisme, une non-reproductibilit et une explosion combinatoire
des tats qui constituent les dicults classiques de la programmation parallle asynchrone.
2. Except quelques cas trs particuliers : coupure lectrique globale concernant des ordinateurs en rseau local.
1.3 Les parfums. . .
Aprs ce qui prcde, peut-on encore trouver un intrt la rpartition ? Malgr les handicaps prcdents,
la rponse est oui. Il sut de lister les principaux avantages.
1.3.1 Partage et Mise disposition
La rpartition est avant tout un moyen de mise disposition et donc de partage de ressources et ser-
vices. Cette ide de partage et de disponibilit constitue mme la smantique que lon peut donner au mot
rpartition.
Exemples
Une ressource telle quune imprimante peut tre rendue accessible tous les usagers dune architecture
rpartie. Elle peut mme constituer un nud du rseau.
Des chiers localiss sur un disque dun nud peuvent tre rendus visibles voire modiables par des
usagers connects un nud distant. Un service de gestion de chiers rpartis est un des services de
base des systmes dexploitation rpartis.
1.3.2 Rpartition gographique
La rpartition est un moyen essentiel pour mettre disposition des usagers les moyens informatiques
locaux dont ils ont besoin tout en gardant la possibilit daccder aux ressources et services distants de leurs
collgues.
Exemples
Un systme de rservation (dhotels, davions, de trains, ou de tout la fois) est un exemple de systme
qui peut avoir plusieurs centres dans dirents lieux, par pays, par compagnie, par agences.
Un systme bancaire peut comporter un ensemble dagences rgionales qui communiquent avec le sige
central.
Le contrle arien peut ncessiter un dcoupage en secteurs dont il faudra coordonner les interactions.
1.3.3 Autres avantages
Moins essentiels mais non ngligeables, on noubliera pas les autres points suivants :
Puissance de calcul La connexion de machines en rseau permet dobtenir moindre cot une
puissance de calcul importante. Bien entendu, lexploitation optimale de ces performances potentielles
ncessite de parallliser les algorithmes de calcul et de disposer dun environnement dexcution rpartie
adquat. En la matire, quelques produits de ce type sont aujourdhui largement diuss (PVM, MPI
par exemple).
Disponibilit La disponibilit dun service dvelopp sur une architecture rpartie peut tre rendue
plus grande que celle dun service centralis. La relative indpendance des dfaillances qui peuvent
survenir dans les nuds, permet de continuer orir un service mme dgrad. En particulier, la rpli-
cation dun mme service par linstallation de plusieurs serveurs quivalents est une solution classique
mais de mise en uvre dlicate notamment si les serveurs sont tat rmanents.
Flexibilit Une architecture rpartie est par nature modulaire. Il est donc plus facile dajouter ou
denlever un nud connect au rseau, le systme global continuant tre disponible. Cette caract-
ristique tend jouer un rle important avec la mobilit de plus en plus grande des usagers. En eet, ce
sont maintenant des ordinateurs portables qui se connectent par un rseau commut pour accder un
systme rparti aux frontires parfois mal connues (par exemple le rseau Internet). Les points daccs
sont donc mobiles. On parle dinformatique nomade. La connexion est temporaire et doit tre mme
minimise cause des cots de communication non ngligeables. Les problmes poss concernent donc
essentiellement la localisation, lidentication et lauthentication des usagers mobiles et loptimi-
sation des temps de connexion (par lutilisation dagents mobiles par exemple).
Cette exibilit se situe aussi au niveau logique. Un nouveau service peut tre install sur un nud
sans ncessiter une reconguration des autres nuds.
Autrement dit, un systme rparti peut en principe mieux sadapter dune part, une croissance des
besoins informatiques dune entreprise en permettant une adaptation dynamique et continue et dautre
part, au nombre variable et la mobilit de ses usagers.
Les avantages prddents ont fait le succs des systmes rpartis. Ils permettent aussi de donner une
dnition plus prcise du mot rpartition.
La rpartition est la mise disposition dun ensemble de res-
sources et services connects via un rseau pour tous les usagers
qui possdent un droit daccs en un point quelconque.
1.4 La recherche de solutions (Conceptualiser, comprendre, exp-
rimenter)
La recherche de solutions face aux dicults intrinsques poses par la rpartition sest dploye dans
dirents domaines :
1.4.1 La thorie
Pour bien comprendre la problmatique de la rpartition, il est important de pouvoir modliser le plus
formellement possible sa smantique. Il sagit donc dlaborer des modles de calcul traduisant de faon
abstraite et formelle (mathmatique) les proprits dun calcul rparti.
Une premire cole a pour origine les travaux de Milner[19] et Hoare[14]. Elle sappuie sur la dnition
dalgbres de processus communicants. Un calcul rparti est un terme algbrique qui dcrit un ensemble de
processus qui sont autant de termes composants. La communication entre processus apparat sous la forme
dun rendez-vous, cest--dire dune communication synchrone (tampon de taille nulle) point point la plus
lmentaire.
Une deuxime cole sappuie sur le concept dacteur. Le protocole de communication entre acteurs est
asynchrone, chaque acteur possdant une boite lettres pour recevoir les messages des autres acteurs. Le
typage des messages permet dassocier un comportement ractif spcique et modiable dynamiquement
la rception de chaque message. Ce modle dacteurs communiquant par message a lui aussi t formalis.
Enn, les systmes de transitions et la logique temporelle sont aussi utilisables et utiliss pour spcier
et modliser des traitements rpartis. Dans ce cas, la communication est souvent modlise simplement sous
la forme de squences de messages.
1.4.2 Lalgorithmique
Lcriture dalgorithmes adapts une architecture rpartie soulve des problmes algorithmiques
spciques[24]. Ceux-ci ont pour origine les deux hypothses perdues bien utiles au programmeur. Un
courant de recherche sest donc dvelopp pour tudier et proposer des algorithmes rpartis apportant en
particulier des solutions des problmes gnriques.
Une importante classe dalgorithmes concerne la dnition de protocoles de communication point point
ou diusion. En eet, pour pouvoir cooprer via des changes de messages, les partenaires doivent se
mettre daccord sur le squencement et le type de ces messages. La dnition de nouveaux protocoles de
communication est donc une activit importante. Sous une simplicit apparente, la spcication de protocoles
est une activit dlicate qui a ncessit la recherche de formalismes de description (automates communicants,
rseaux de Petri, langage LOTOS,. . .) et doutils daide la validation. Certains standard existent comme
par exemple, lappel procdural distance. Mais beaucoup de protocoles sont adapts une classe spcique
dapplications (par exemple, le temps rel).
On trouve ensuite des problmes plus gnraux que lon peut classer en deux catgories : dune part, des
problmes connus du monde parallle (exclusion mutuelle, interblocage, atomicit, rplication par exemple)
mais qui ont d tre reconsidrs et dautre part, des problmes nouveaux apparus avec la rpartition des trai-
tements et des donnes. On peut citer par exemple le problme de la terminaison dune application rpartie[10]
(problme simple en centralis, mais dlicat en rparti) ou celui de linterblocage[8], le calcul dtats globaux
(appels clichs)[25], la dtection dtats stables ou invitables, la ralisation dun consensus[13]
3
, . . .
1.4.3 Les langages de programmation
premire vue, la rpartition nimplique pas de grande rvolution dans les langages de programmation.
En eet, dans un eort minimaliste, il sut dutiliser une interface de programmation (API) permettant
dchanger des messages, soit deux primitives mettre et recevoir un message. Linterface base de prises
(sockets) oerte par le systme Unix nen propose pas beaucoup plus encore aujourdhui.
On peut cependant tre plus ambitieux en proposant par exemple des structures de contrle facilitant
le raisonnement et la programmation des changes de messages. De nombreuses propositions ont t faites.
Il est dicile den donner une liste exhaustive. Les approches gardant une communication explicite par
messages, ont introduit la notion de non-dterminisme en rception voire en mission. Le non-dterminisme
en rception est en eet important car lon doit souvent exprimer lattente dun message parmi plusieurs
possibles de type dirent. Il est alors intressant de possder une structure de contrle permettant dassocier
chaque type de message une action spcique. On trouve ce type de construction dans des langages comme
OCCAM et Ada[15].
Enn et surtout, une extension de la notion de procdure a t propose : lappel procdural distance.
Le programmeur garde son modle de programmation de type procdural, mais en fait les procdures appeles
par une processus donn peuvent tre localises sur des sites distants. Ce modle de programmation rparti
est celui qui est aujourdhui le plus utilis et connu sous le nom de modle client-serveur. Au niveau langage,
il faut introduire un langage de dnition dinterface (IDL
4
) qui permet de dcrire linterface des procdures
qui doivent pouvoir tre appeles distance. Les problmes dimplantation sont masqus au programmeur par
une gnration automatique des routines de traitement des appels ct client (appelant) et serveur (appel)
partir des descriptions IDL.
1.4.4 Les systmes dexploitation
Les systmes dexploitation sont videmment les premiers concerns par la rpartition. Il leur revient
dassurer linterface avec le medium de communication.
Les concepteurs de systmes ont envisag deux approches possibles :
reprendre le problme la base et concevoir de nouveaux noyaux dexcution rpartie partir dune
architecture matrielle. Lavantage dune telle approche est de rduire la taille du noyau dexcution,
quali de micro-noyau, en limitant celui-ci aux fonctionnalits de base : gestion des ressources locales
(mmoire, priphriques), gestion du paralllisme et de la communication. Les services classiques dun
systme dexploitation (tel que la gestion des chiers) deviennent simplement des services hors du
noyau dexcution proprement-dit. La modularit du systme obtenu est de ce fait beaucoup plus
leve que celle dun systme dexploitation centralis. Linconvnient dune telle approche est quil
faut redmarrer zro. On peut citer une russite franaise en la matire avec le systme CHORUS
qui est un micro-noyau dexcution rpartie orient Temps Rel.
tendre les systmes dexploitation centraliss en ajoutant au minimum une interface de communica-
tion et si possible quelques services rpartis, par exemple, un systme de gestion de chiers rpartis.
Lavantage de cette approche est la continuit et la rutilisation. Cest ainsi par exemple que le systme
3. Ce problme consiste obtenir quune mme dcision soit adopte par tous les participants (ici processus)
4. IDL : Interface Denition Language
Unix a t progressivement tendu avec une interface de communication par sockets, par RPC
5
[21]
avec ses direntes smantiques, puis par un service de chiers rpartis (NFS
6
).
Linconvnient de cette approche est le caractre moins modulaire du systme obtenu. Les services
oerts, comme la gestion des chiers, sont inclus dans le noyau et donc pratiquement gs.
En ralit, les deux approches se sont mutuellement fertilises dans la mesure o les concepts introduits
dans les micro-noyaux rpartis ont amen modier la conception des systmes classiques en essayant de
leur donner une plus grande modularit.
1.4.5 Les environnements dexcution rpartie (middleware)
Un problme de base des systmes rpartis est de matriser lhtrognit aussi bien matrielle que
logicielle (systmes dexploitation, langages de programmation par exemple). Lobjectif est de pouvoir faire
communiquer et cooprer des composants a priori htrognes. Pour rsoudre ce problme, le modle adopt
repose sur dune part, le schma de communication client/serveur et dautre part, sur la notion de bus
logiciel . Un bus logiciel doit permettre daccder des services spcis par leur interface. Ces interfaces
sont enregistres dans des sortes dannuaires qui permettent de trouver le ou les nuds serveurs (qui auront
t au pralable rpertoris).
Une norme de fait existe actuellement avec lenvironnement CORBA (Common Object Request Broker)
dni par lOMG (Object Management Group Architecture). Une spcication dun bus logiciel objet a
t dnie et implante par de nombreux dveloppeurs. Cette couche logicielle se place donc entre le systme
dexploitation et les applications.
1.5 Principes de conception
La dmarche adopte par les concepteurs de systmes rpartis repose sur un paradoxe un peu dcevant.
Pour caricaturer, on pourrait rsumer leur principe fondamental par :
Pour concevoir un bon systme rparti, concevez un
systme qui a lair centralis ( qui sutilise comme )
Autrement dit, lobjectif est de faire en sorte que le systme rparti ait une interface la plus proche possible
de celle dun systme centralis. Pourquoi une telle approche ?
La raison en est simple : le programmation sous les hypothses centralises (horloge globale et mmoire
globale) est plus simple que la programmation sous les hypothses rparties. Par consquent, il vaut mieux
masquer le plus possible les proprits dlicates de la rpartition.
En fait, il est impossible de masquer totalement la rpartition. Dune part, parce quil faut parfois savoir
o est physiquement la ressource que lon utilise (par exemple, une imprimante), dautre part et surtout
parce que la abilit du systme global nest pas susante.
titre dexemple, considrons le mcanisme dappel procdural distance (RPC). Ce mcanisme permet
dutiliser le concept bien connu de procdure en ltendant au contexte rparti. La procdure appele peut
tre excute sur un site dirent de celui de la procdure appelante. Cette extension permet de programmer
simplement des traitements rpartis mettant en jeu plusieurs nuds en conservant le style de programma-
tion procdural. Cependant, la abilit dun appel rellement distant est bien infrieure celle dun appel
procdural local. La mise en uvre du mcanisme de RPC ncessite des changes de messages, met en jeu
deux sites distincts, pose des problmes de conversion de format des donnes,. . ..
Le rsultat est quil faut que le programmeur prvoit, par exemple, quun appel peut chouer parce que
le site appel est arrt. Pire, la dtection de cette vnement peut tre errone : lappelant considre que
lappel a chou, mais en ralit, le site appel a excut la procdure.
Ds lors, quelles sont les proprits qui peuvent masquer en partie ou totalement la rpartition des donnes
et des traitements ? On appelle de telles proprits, des proprits de transparence.
5. Remote Procedure Call
6. Network File System
1.5.1 Transparence daccs
Cette proprit consiste assurer que linterface daccs une ressource (chier par exemple), sera
identique que la ressource soit locale ou distante.
Exemples
Considrons un opration douverture dun chier sous Unix :
fd = open("projet/test.data",...) ;
Que le chier spci soit local ou distant, le sous-systme de gestion de chiers rpartis NFS permet
dutiliser la mme primitive open. On a bien la transparence daccs.
Considrons une commande dimpression sous Solaris :
lp -d lj test.data
Limprimante peut tre connecte localement ou distante, la commande utilise restera lp;
Considrons une opration de connexion distance :
rlogin blaise.irit.fr -l arthur
La transparence daccs nest pas vrie puisque lon utilise une commande dirente de la commande
locale.
1.5.2 Transparence de localisation
Cette proprit consiste assurer que la dsignation de la ressource est indpendante de la localisation de
cette ressource. Autrement dit, les usagers peuvent ignorer la localisation relle. Si la transparence daccs est
de plus assure, on peut alors utiliser une ressource en ignorant si elle est locale ou distante. Cette proprit
peut tre ane en assurant que tous les usagers de la ressource pourront la dsigner par le mme nom global
indpendamment de leur propre localisation. La dsignation est alors qualie duniforme.
Exemples
Si lon reprend lopration douverture dun chier,
fd = open("projet/test.data",...) ;
NFS assure la transparence de localisation
7
Pour la commande dimpression :
lp -d lj test.data
limprimante porte un nom symbolique qui ne contient pas dinformation sur sa localisation ( pour ce
type de ressource, il est bien entendu utile de savoir nalement o elle se trouve) ;
Pour lopration de connexion distance :
rlogin blaise.irit.fr -l arthur
la transparence de localisation nest videmment pas possible.
1.5.3 Transparence du partage
Cette proprit consiste assurer que les accs concurrents la ressource seront contrls de telle faon
que lintgrit de la ressource soit assure. titre dexemple, pour un chier, la transparence du partage
7. Attention, NFS nassure pas forcment une dsignation uniforme. Le mme chier sera ventuellement accessible sous des
noms dirents selon la localisation de lappelant.
implique de garantir les rgles de synchronisation dites des lecteurs/rdacteurs. Pour une imprimante, il
sagit dviter les mlanges des requtes dimpression en assurant un accs exclusif.
Les systmes dexploitation rpartis se contentent en gnral dassurer le minimum vital. Si le partage
dune imprimante est garanti sans problme (principe du spooling), le partage des chiers est plus probl-
matique. titre dexemple, le systme NFS essaie de minimiser les risques dincohrence, mais sans garantie
absolue (cf. chiers rpartis). Une telle approche tient au cot de supervision du partage pour des chiers
qui, dans leur grande majorit, ne seront que des chiers temporaires non partags.
Ce sont donc des systmes plus ddis un contexte dapplication particulier qui garantissent cette
transparence. Le contexte le plus rpandu est celui des bases de donnes rparties et des sous-systmes tran-
sactionnels associs. Les enregistrements dune base de donnes sont bien des ressources fortement partages
par nature. Il est donc important dorir dans un contexte rparti le mme type de service que celui apport
par les systmes transactionnels centraliss. Le problme de base est celui de latomicit des traitements
(transactions) sur la ou les bases de donnes.
1.5.4 Transparence de la rplication
Cette proprit consiste assurer que laccs une ressource soit identique quel que soit la forme dim-
plantation de cette ressource, en particulier rplique. Cest la mme ide que la transparence daccs mais
tendue la rplication.
Ce genre de transparence est videmment ddi des systmes trs spciques. La rplication a pour
objectif dobtenir une plus grande robustesse vis--vis des fautes. Cest donc pour les systmes tolrants aux
fautes que la rplication est en gnral mise en uvre.
1.5.5 Transparence des fautes
De faon plus gnrale, nous avons vu quun systme rparti devait obligatoirement considrer les d-
faillances de certains de ses nuds comme des vnements probables. Il est donc important dassurer une
bonne tolrance aux fautes de lensemble des services dun systme rparti. titre dexemple, pour un sys-
tme de gestion de chiers, la dfaillance dun volume mont distance mais momentanment non utilis ne
doit pas bloquer le fonctionnement global du service.
1.5.6 Transparence de la migration
Cette proprit consiste assurer quune ressource pourra migrer dun nud un autre sans que les
usagers sen apercoive. Ce genre de problme a t en particulier tudi sur la ressource processus. En eet,
ceci permet de dplacer un service dynamiquement vers un nud moins charg et donc de mettre en uvre
des stratgies de rgulation de charge sur une architecture rpartie.
1.5.7 Transparence de charge
Dans une architecture rpartie, la rgulation de la charge de chaque nud peut permettre une meilleure
exploitation du systme global et une meilleure satisfaction des utilisateurs.
La mise en uvre est cependant dlicate car une rgulation de la charge globale implique une bonne
connaissance de ltat global du systme. Or, cette connaissance est justement dicile obtenir comme
nous lavons vu. Au mieux peut-on esprer avoir une observation dun pass rcent. Cest pourquoi, des
algorithmes rpartis doivent tre conus spciquement.
1.5.8 Transparence dchelle
Nous avons vu quune architecture rpartie est plus modulaire et adaptable dynamiquement quune
conguration centralise. Lajout de nuds ne ncessite pas larrt du systme. Cependant, le passage dun
systme comportant une dizaine de sites un systme dune centaine de sites nest pas forcement transparent
0 <= R D <= N
R
Droit de restitution :
R L < N
( il existe une place)
Droit de location :
(il existe un vhicule)
Invariant :
Parking de N places D
R D > 0
Figure 1.1 Spcication du problme
pour les usagers. Cest ce phnomne de changement dchelle quil faut pouvoir contrler et rendre le plus
transparent possible.
1.6 Exemple de rpartition : Variations sur un thme de location
Pour bien comprendre les problmes algorithmiques poss par la rpartition, nous utiliserons un exemple
que nous enrichirons progressivement. Au cours de ces variations, nous nous concentrons sur laspect contrle,
synchronisation du systme et de ses usagers.
1.6.1 Exposition du problme
Considrons un garage de vhicules de location qui possde les proprits suivantes :
la capacit du garage est limite N places ;
il existe deux guichets daccs au garage : lun que lon peut qualier de guichet de dpart pour les
prises de vhicules, lautre que lon peut qualier de guichet de retour pour les restitutions. Ces deux
guichets sont distants gographiquement pour faciliter la circulation des vhicules (par exemple lun
au nord du garage et lautre au sud).
Les vhicules prsents dans le garage peuvent tre lous et sortir par lissue correspondante et rcipro-
quement, des vhicules lous peuvent tre restitus.
Les vhicules lous ne sont pas forcement restitus ce garage et inversement, les vhicules restitus
ne sont pas obligatoirement issus de ce garage.
On notera Restituer et Louer les deux oprations qui constituent linterface du garage. Le guichet de
retour contrle lexcution de lopration Restituer. Celui de dpart contrle lexcution de lopration
Louer.
1.6.2 Le contrle des mouvements de vhicules
Spcication
Les locations et restitutions des vhicules doivent donc tre contrles de faon garantir quil ny a pas
trop de vhicules dans le garage ni quon loue plus de vhicules quil nen existe. Cette proprit de sret se
traduit simplement sous la forme dun invariant en introduisant deux compteurs monotones croissants : lun
comptant les vhicules restitus (R) et lautre les vhicules lous (D). Leur dirence doit tre exactement
le nombre de places occups (le nombre de vhicules prsents) dans le garage.
invariant 0 (R D) N (1.1)
La gure (1.1) illustre les spcications de ce systme de location.
Remarques
1. Il faut bien noter que les compteurs R et D nont pas forcment une valeur nulle initialement. Il faut
simplement que leur dirence (R D) rete bien le nombre de vhicules prsents dans le garage
conformment linvariant.
2. Ce problme constitue un systme dit ractif compos dune partie environnement reprsente par
les vhicules et dune partie contrle assurant la gestion correcte de la ressource garage.
3. Linvariant (1.1) doit tre vri par le systme global compos des vhicules et des deux issues guichets.
Indpendamment de tout problme de rpartition, lentre ou le dpart dun vhicule est donc soumis
prcondition.
Pr(Restituer) : (R D) < N
Pr(Louer) : 0 < (R D)
Compte tenu des hypothses, la connaissance du compteur des entres R est localise au guichet de
restitution. Celle du compteur des dparts D est localise au guichet de dpart. Or, on peut constater que
le guichet de retour, comme celui de dpart, doit avoir une connaissance globale des deux compteurs pour
pouvoir dcider si une opration est acceptable en valuant la prcondition correspondante.
Autrement dit, nous sommes en face dun problme rparti. Comment chaque guichet peut-il avoir une
connaissance susante du compteur gr par lautre pour pouvoir assurer un contrle correct sachant quils ne
peuvent que schanger des messages ? Nous allons envisager plusieurs possibilits de rpartition du contrle.
Rpartition par accs distant (maintien dun chef dorchestre)
Une version simple consiste centraliser les variables dtats R et D de faon pouvoir valuer les deux
prdicats. Il faut donc introduire un troisime nud central qui implante un service Contrle accessible
distance orant les deux oprations :
interface Contrle() {
IncrR() /* incrmenter le compteur R */
IncrD() /* incrmenter le compteur D */
}
Sur le nud central, il faudra donc dmarrer un serveur acceptant linterface prcdente. Ce serveur devra
assurer le maintien de linvariant (1.1) par une synchronisation correcte des deux oprations. Le guichet de
restitution excute une opration locale de restitution en commenant par appeler la procdure IncrR
distance. La terminaison de cet appel autorise le guichet continuer son opration locale de restitution dun
vhicule. Il en est de mme pour le guichet de dpart avec lopration IncrD.
Linconvnient de cette solution est quelle ncessite un appel procdural distance pour chaque opration
de restitution ou de location. De plus, la disponibilit du service repose sur le bon fonctionnement des trois
nuds.
Rpartition par image (deux solistes mais ils sobservent)
Supposons que, par un protocole adquat dnir, chaque guichet puisse avoir une image du compteur
distant (source) de lautre. La smantique dun compteur image peut tre dnie informellement par les
proprits de sret et de vivacit suivantes :
le compteur image a initialement la mme valeur que le compteur source ;
le compteur image ne peut prendre que des valeurs prises par le compteur source et ceci dans le mme
ordre chronologique ;
le compteur image peut ne pas prendre toutes les valeurs successives du compteur source ;
si le compteur source prend la valeur k, le compteur image nira par prendre une valeur gale ou
suprieure k.
On notera cette relation dite dobservation entre une source et une image
8
par le symbole . Pour le
garage, on peut donc supposer que les relations dobservations suivantes vont tre mises en uvre :
R R D D
8. Cette notion dimage est similaire la notion de cache en cohrence faible
Compte tenu des proprits nonces sur les observations, limage dun compteur croissant est toujours
infrieure ou gale la valeur de sa source (Petit thorme facile dmontrer). On a donc :
invariant R R D D (1.2)
On a par consquent le thorme suivant :
R D D D (R D < N R D < N)
Autrement dit, le guichet de restitution, sil possde localement limage D, peut dcider coup sr en
valuant le prdicat local mais approch R D < N. Il en est de mme pour le guichet de location avec :
R D R R (R D > 0 R D > 0)
Une solution au problme consiste donc ici localiser lvaluation des prconditions rparties grce
lutilisation dimages. Il sura dimplanter le mcanisme dobservation. Ceci peut tre fait de multiple faons.
Par exemple, si lon suppose que les deux guichets sont relis par un canal de communication bidirectionnel
respectant lordre chronologique des envois de messages, le mcanisme dobservation peut tre implant par :
lenvoi priodique ou chaque modication de la valeur de la source vers le nud de limage ;
lappel procdural distance, issu de la source, de lopration image.incr(1) par la source rpliquant
chaque opration locale source.incr(1) ;
lappel procdural distance, issu de limage, de lopration source.lire pour obtenir la valeur de la
source, appel qui peut tre priodique ou la demande lorsque le prdicat valuer est faux par
exemple ;
etc, etc , . . .
Cet exemple montre labsence dtat global ncessitant ici dutiliser une connaissance approche impli-
quant la condition globale attendue.
Les avantages que lon peut tirer de la rpartition du contrle dans cette solution sont varis :
minimisation possible des changes de messages. Le protocole dobservation peut sajuster aux besoins
applicatifs ;
abilit du systme : il y a un composant en moins ;
disponibilit : mme si un des deux guichets connat une dfaillance momentane, lautre peut assurer
encore son rle dans la mesure o la prcondition reste valide avec la dernire valeur dimage obtenue.
Sur ce dernier point, le redmarrage du guichet dfaillant pose cependant le problme de la restauration
dune valeur correcte du compteur associ. Il faut assurer que la valeur courante des compteurs de chaque
guichet est robuste, cest--dire quelle survit un arrt.
Rpartition par circulation (une partition nomade)
Lide de base de cette solution est que lon peut simuler des variables globales en faisant circuler
quitablement entre les nuds un message qui contient la valeur courante de ces variables. On parle aussi
de jeton circulant valu. Lorsquun nud possde ce jeton ( a reu le message unique qui circule), il peut
considrer quil possde le droit dutilisation ainsi que la valeur courante de la variable globale.
Dans notre problme, il sut de faire circuler entre les deux guichets un message jeton unique valu
par la dirence des deux compteurs V P = RD. Cette dirence reprsente, ne loublions pas, le nombre
de vhicules prsents dans le garage. Le guichet de restitution incrmente V P et le guichet de dpart le
dcrmente en garantissant linvariant : invariant 0 V P N.
Les oprations de restitution et de location sont alors conditionnes non seulement par linvariant prc-
dent, mais aussi par la prsence du jeton. Lobjet jeton doit passer par le site pour que celui-ci soit accd
et ventuellement modi. Ceci peut tre dcrit par un objet de classe Passage ayant comme interface :
class Passage {
int obtenirJeton() ; void librerJeton(int val) ;
}
titre dexemple, lalgorithme dune opration de restitution de vhicule utilisant le jeton valu sera de
la forme suivante :
int vpl = unPassage.obtenirJeton() ; unPassage.librerJeton(vpl++) ;
titre dexercice, se pencher sur lopration de location. Quel est sont algorithme ?
Remarque Ne pas oublier quil faut assurer la traverse du nud par le jeton lorsquil nexiste aucune
requte en attente localement.
La circulation du jeton se fait en gnral sur un anneau logique passant par tous les nuds. Un problme
non ngligeable de cette approche est donc le bruit de fond provoqu par la circulation permanente du
message jeton mme si aucune opration nest en attente sur un nud. Un deuxime problme se pose avec
le risque de perte du jeton en cas de dfaillance dans les communications (perte du message jeton) ou de
dfaillance dun nud (arrt du nud).
1.6.3 Enrichissement du systme (Plusieurs orchestres)
Supposons maintenant quil existe plusieurs compagnies de location (Hertz,Ada, Europcar,. . .) et quelles
aient dcid de partager le garage sans pour autant mettre en commun leurs systmes dinformation. Chaque
compagnie possde donc un guichet de retour et un de dpart et ne loue que ses propres vhicules. Si lon
suppose quil existe P compagnies, on a donc P compteurs D
i
et P compteurs R
i
rpartis dans chaque
guichet.
Rpartition par observation et circulation
Pour un guichet de dpart i, la prcondition valuer est :
Pr(Louer) : (R
i
D
i
) > 0
Cette condition indique que la compagnie i possde encore au moins un vhicule louer dans le garage.
Une solution simple pour une valuation locale au guichet de dpart, est dutiliser des observations. Le
guichet de dpart doit possder une image R
i
du compteur R
i
. On aura la proprit :
(R
i
D
i
> 0) (R
i
D
i
> 0)
Pour un guichet de retour, le problme est un peu plus dicile. Il faut en eet tester la prcondition :
Pr(Restituer) : (
i=P
i=1
R
i

i=P
i=1
D
i
) < N
Pour les compteurs D
i
, chaque guichet de retour peut se contenter dune approximation. On peut donc placer
sur un guichet de retour i
0
, les images de tous les autres compteurs D
j
, j ,= i
0
9
.
Pour un guichet i
0
, on aura donc besoin des relations dobservation j = 1, P : D
i0
j
D
j
) et, par
suite, limplication suivante sera satisfaite :
(
i=P
i=1
R
i

j=P
j=1
D
i0
j
) < N (
i=P
i=1
R
i

i=P
i=1
D
i
) < N
Reste le problme de la somme des compteurs R
i
. Il faut pouvoir disposer de la valeur exacte ou dune
approximation par excs. Une solution possible est celle du jeton. Une variable globale abstraite S
R
peut tre
reprsente par un jeton circulant entre les guichets de retour placs sur un anneau logique. Pour prciser la
localisation de lobjet (de la variable) jeton mobile, on introduit le prdicat X@node(i). Ce prdicat est vrai
si la variable X est localise sur le site node(i). Le test devient alors possible sous la forme :
S
R
@node(i
0
) (S
R

j=P
j=1
D
i0
j
) < N
9. Pour simplier lcriture des formules, on suppose que sur le site i
0
, limage D
i
0
est un alias pour dsigner la source D
i
0
puisque image et source sont sur le mme site
Rpartition par rplication
Une autre solution consiste rpliquer la variable somme S
R
sur tous les guichets de retour. Il se pose
alors le problme de la cohrence globale de ces copies. Il est ncessaire de respecter un protocole bien prcis
pour assurer une mise jour dite atomique des direntes copies
10
. titre dexemple des problmes qui
peuvent survenir, il sut de considrer le cas de deux guichets de retour G
R1
et G
R2
. Supposons que lon ait
donc deux copies S
R1
et S
R2
. On peut envisager le maintien de la cohrence des deux copies en rpliquant
tout simplement chaque opration logique sur les deux copies. Ainsi, une opration de restitution ayant pour
origine G
R1
devra se traduire par une opration locale S
R1
.incr(1) et une opration distante S
R2
.incr(1).
Symtriquement pour une opration de restitution ayant pour origine G
R2
, il faudra excuter une opration
locale S
R2
.incr(1) et une opration distante S
R1
.incr(1).Supposons le droulement chronologique suivant :
Restitution ayant pour origine le guichet G
R1
G
R2
Opration locale S
R1
.incr(1)
S
R2
.incr(1)
Opration distante S
R1
.incr(1)
S
R2
.incr(1)
Si la valeur des deux copies tait cohrente avant ces deux oprations de restitution mais que la prcondition
(S
Ri

j=P
j=1
D
i0
j
) < N est devenue fausse aussi bien pour R
1
que pour R
2
aprs les deux incrmentations
locales, les deux oprations distantes deviennent impossibles. En fait, les deux oprations de restitution ont
t partiellement xcutes. Pourtant, il tait possible dexcuter compltement une SEULE des deux resti-
tutions. Il ne fallait simplement pas entrelacer les oprations dincrmentation. Des protocoles de diusion
atomiques ont t proposs pour rsoudre ce genre de situation.
1.6.4 Conclusion
Nous avons vu travers cet exemple, la fois les dicults et la richesse des solutions rparties. Encore,
navons nous pas considr le systme dinformation proprement dit. En eet, chaque guichet devra sans
doute grer un journal des oprations quil a trait par exemple dans une journe. Ces journaux enregistrs
sur chaque guichet seront ventuellement transmis un site central chaque nuit durant la fermeture du
garage. Inversement, un site central(isateur) pourra interroger rgulirement les guichets.
On peut aussi envisager une rgulation entre garages sil en existe plusieurs implants dans direntes
villes. Il faudra alors dnir un protocole dchange permettant dviter la fois les ruptures de stock et
les engorgements des garages.
Dans tous les cas, certains problmes rcurrents devront tre rsolus : choix de la rpartition des donnes,
synchronisation globale, atomicit des oprations, rplication, diusion,. . ..
1.6.5 Exercices
1. Un jeton se perd. Imaginer des solutions pour dtecter cette perte et engendrer un nouveau jeton
(Attention, il doit tre unique !).
2. La circulation permanente du jeton consomme de la bande passante rseau inutilement. Imaginer un
protocole permettant darrter le jeton sur un site et de le remettre en mouvement lorsquune requte
apparat sur un site quelconque.
3. Rchir au problme pos par larrt dun guichet de retour, de dpart notamment vis--vis des
observations.
4. Concevoir une rgulation possible entre plusieurs garages de location.
5. Imaginer un protocole qui viterait le problme des entrelacements errons doprations rpliques.
10. Latomicit est une proprit qui nest pas spcique aux systmes rparties. Les systmes transactionnels (centraliss)
ont largement tudi ce problme. Cependant, la rpartition pose des problmes de mise en uvre plus complexes.
Premire partie
Algorithmique rpartie
21
Chapitre 2
Les principes
2.1 Modlisation de la rpartition
Pour mieux comprendre la rpartition, il est ncessaire davoir une modlisation la plus prcise possible
dun systme rparti. Un certain nombre dabstractions ont t proposes. Elles conduisent des modles
de calcul rparti dirents.
On peut distinguer deux grande classes de modles :
dune part, les modles fonds sur la notion de processus communicants. Ces modles dexcution
rpartie conservent la notion fondamentale de processus des systmes parallles.
1
Par contre, divers
modes de communication entre processus sont possibles et ils modient trs profondment le modle
nal. A titre dexemple, la communication peut tre synchrone ou asynchrone, point point ou par
diusion, etc.
dautre part, les modles fonds sur la notion dobjet. Cette approche sest dveloppe avec le succs
de la technologie objet dans les langages de programmation. Toutefois, lutilisation du concept dobjet
qui en est faite est trs dirente. Laccent est mis sur la modularit apporte par le concept, laspect
rutilisation tant beaucoup plus secondaire.
Dans ce chapitre, nous nous concentrons sur le modle des processus communiquant par messages. Cest
en eet le modle de base qui a bien videmment t le plus tudi et exploit. Cest en particulier celui
utilis pour la description des algorithmes rpartis. Cest pourquoi nous dcrirons plus spciquement un
modle standard de processus communicants utilis dans ce contexte dtude.
2.1.1 Processus communiquant par messages
Les processus communiquant par messages constituent le modle la fois le plus ancien et le plus tudi
des modles de calcul rparti. Un calcul rparti est tout dabord un calcul parallle. Cest pourquoi la
notion de processus squentiel a t rutilise pour exprimer cette fois-ci le grain de rpartition. Cependant,
labsence de mmoire globale aux sites dune architecture distribue a conduit introduire des primitives
de communication permettant aux processus dchanger des messages. De multiples protocoles dchange de
messages tant envisageables, ce modle possde de nombreuses variantes et a t lobjet aussi bien dtudes
thoriques approfondies que dimplantations diverses.
2.1.2 Formalisation du modle
Dun point de vue thorique, ce modle a t formalis sous forme dalgbres de processus [1]. Deux
approches algbriques ont t particulirement dveloppes : le modle CSP (Communicating Sequential
Processes) de Hoare et le modle CCS (Calculus of Communicating Systems) de Milner. Les termes de
1. Un processus est une unit dallocation de ressources locales, donc de rpartition. Il fournit dune part des resssources
mmoires, chiers, programme et dautre part, de la puissance de traitement sous forme de processus lgers ou threads.
23
lalgbre permettent de dcrire le comportement des processus. Les changes de messages sont des actions
lmentaires simultanes synchrones (on parle de rendez-vous) entre deux processus ou plus. Cette approche
algbrique modlise un calcul rparti de faon susamment formelle pour valider certaines proprits de
sret telles que linterblocage. Cependant, la complexit du raisonnement crot trs rapidement avec le
nombre des interactions par messages et rend dicile la validation de telles applications. Paradoxalement,
bien que le formalisme de description algbrique soit trs abstrait, deux obstacles se combinent et rduisent
les possibilits oertes par cette approche : dune part, les concepts modliss sont eux trs lmentaires
et dautre part, la communication est considre comme synchrone et idalement atomique, masquant ainsi
bien des dicults rencontres dans les systmes rels.
2.1.3 Mises en uvre du modle
Au niveau systme dexploitation, limplantation de ce modle est videmment la plus rpandue puis-
quindispensable dun point de vue pratique. Depuis le systme ACCENT jusquaux protocoles dInternet,
en passant par PVM/MPI, de nombreux systmes dexploitation ont intgr des primitives de communica-
tion permettant lchange de messages entre processus distants. De faon pratique, chaque machine est le
support dexcution de plusieurs processus, ce qui amne distinguer pour xer lorigine ou la destination
dun message, dune part, un nom de site global larchitecture distribue (cette dsignation tant elle-mme
structure en domaines, sous-domaines. . .) et dautre part, un nom local associ au processus (notion de port
dans IP par exemple).
Limpact de la rpartition sur les systmes dexploitation ne sest pas rduite lintroduction de primitives
de communication par messages. Des services accessibles distance sont trs vite apparus (service de chiers
par exemple). La notion mme de processus a t sensiblement modie. lorigine, lobjet systme
processus recouvrait le suivi et la gestion de lexcution dun programme squentiel xant ainsi la granularit
du paralllisme. Le modle client-serveur a amen structurer lactivit dun processus en plusieurs sous-
activits squentielles ddies chacune la gestion des changes avec un client mais partageant les ressources
du mme processus. Ainsi, un processus peut comporter un degr quelconque de paralllisme sous forme de
processus lgers (ou threads). On distingue alors le grain de rpartition x par les processus dit lourds qui
gardent leur rle dunit dallocation de ressources et le grain de paralllisme dtermin par les processus
lgers.
Lintgration de ce modle de calcul rparti dans les langages a donn lieu de nombreuses propositions.
Lapproche la plus lmentaire est dintroduire dans le langage un type prdni canal dot doprations
de communication mettre et recevoir. Ces oprations peuvent tre synchrones (rendez-vous du langage
Occam) ou asynchrones. Pour faciliter la prise en compte du non-dterminisme inhrent aux changes de
messages, la notion de commande garde, propose par Dijkstra, a t la base de structures de contrle
permettant lcoute de plusieurs canaux simultanment.
Hormis les langages classiques impratifs, une approche issue des langages fonctionnels a aussi t pro-
pose. Il sagit en loccurrence des langages acteurs. Dans de tels langages, les activits sont reprsentes
sous forme dacteurs. Un acteur peut changer des messages avec ses acteurs voisins (accointances). Comme
dans le modle processus, il peut crer de nouveaux acteurs, mais il peut aussi changer dynamiquement
de comportement en interprtant tout message reu comme une continuation. Ce modle, de par son ori-
gine fonctionnelle, inclut la fois un fort degr de rexivit et de dynamisme. Il a t mis en uvre, par
exemple, par la ralisation de machines virtuelles acteurs orant un langage intermdiaire. Des implanta-
tions rparties ont pu tre ainsi dveloppes simplement. On peut donc souligner que de nombreuses ides
des langages acteurs sont aujourdhui exploites dans les environnements rpartis tels que Java (machine
virtuelle, rexivit, mobilit du code).
2.2 Le modle standard de lalgorithmique rpartie
Le problme de base des systmes rpartis est de trouver des principes et concepts pour matriser la
communication par messages.
Pour concevoir puis dcrire des algorithmes rpartis, il est ncessaire de choisir un modle de calcul rparti.
Plusieurs modles existent selon le niveau dabstraction des communications que lon choisit (communication
synchrone ou non, par message ou par appel de procdure, point point ou multipoint, able ou non, . . .).
Un modle lmentaire assez standard est cependant utilis pour dcrire les algorithmes. Nous en donnons
une description dtaille.
2.2.1 Structuration dun programme rparti
Un programme rparti peut tre naturellement structur en un ensemble xe de processus ou noeuds. La
description de lalgorithme consistera donc fournir le programme excut par chaque noeud (processus).
CR = i = 1, N :: P
i
)
Dnition dun processus communicant
Un processus communicant est lunit de rpartition. Il satisfait les proprits suivantes :
Encapsulation Un processus encapsule un ensemble de variables dites locales quil est seul pouvoir
utiliser. Les valeurs courantes de ces variables dnissent ltat courant du processus.
Comportement Un processus excute squentiellement une suite dinstructions. Lexcution dune ins-
truction peut modier atomiquement cet tat (transition), envoyer un message ou recevoir un message. Le
comportement dun processus peut donc tre dcrit par la suite des transitions quil excute. Cependant,
lhypothse datomicit permet dadopter un point de vue vnementiel : chaque instruction peut tre
associ un vnement qui traduit loccurrence de lexcution de cette instruction. Par consquent, il est aussi
possible de tracer et dabstraire lexcution dun processus sous la forme dune suite dvnements. En
gnral, ce sont videmment les vnements denvoi et de rception de message qui sont particulirement
signicatifs.
Lhypothse datomicit des instructions peut paratre trs restrictive. En fait, pour quun usager peroive
des instructions atomiques, il sut quune instruction localement non atomique ne soit pas interrompue
par la rception ou lmission dun message. Ce type de comportement est en gnral acceptable dans les
applications sans contraintes de temps rel.
Identication Chaque processus possde une identication distincte des autres. On peut distinguer deux
niveaux : un nom symbolique (une URL, par exemple bach.enseeiht.fr) ou une adresse IP. Cest une hypothse
communment admise.
Connaissance locale Un processus na quune connaissance trs partielle du calcul auquel il participe.
Initialement, une hypothse couramment admise est quil connat son identication, ses voisins via les canaux
quil peut utiliser et son tat interne x par la valeur de ses variables locales. Il ne peut connatre quune
approximation des tats des autres processus.
La communication par messages
Les changes de messages peuvent se faire via des canaux logiques de communication point point dont
les proprits peuvent varier : (a)synchrone, canal uni/bidirectionnel, able ou non, respectant la chronologie
denvoi en rception (canal FIFO), de capacit limite ou non,. . .
Des hypothses trs usuelles (car les plus commodes utiliser dans les algorithmes) consistent considrer
des canaux asynchrones, bidirectionnels ables et FIFO de capacit illimite.
Lensemble des canaux xe la topologie de communication.
c5
P1
P2
P3
P4
c1
c2 c3
c4
Figure 2.1 Structure dun calcul rparti
0
e1 r2 e3 e4
i1
e2
r1
e
t
P1
P2
P3
P4
Figure 2.2 Exemple de chronogramme
Remarques Bien remarquer les restrictions du modle :
le nombre de processus est constant et la topologie de communication est xe ;
Les seules interactions possibles sont les changes de messages ;
Aucun processus nest isol. Autrement dit, le graphe du rseau de communication est connexe.
Reprsentation graphique
Cette structure peut tre reprsente sous forme dun graphe non orient dont les sommets sont les
processus et les artes sont les canaux. La gure (2.1) est un exemple dun tel graphe comportant 4 processus.
2.2.2 Le chronogramme
Lorsquon cherche analyser le comportement dun calcul rparti, il est intressant den avoir une image
graphique. La notion de chronogramme est un outil lmentaire et indispensable. Il permet dabstraire
graphiquement une excution rpartie en ne considrant que les vnements signicatifs issus de chaque
processus. Trois types dvnements sont distingus : les vnements internes au processus, les missions de
message et les rceptions de message.
Le chronogramme de la gure 2.2 montre par exemple un vnement interne i1, des envois de message
point point (par exemple couple e1; r1), une diusion (mission e2), la perte dun message (mission e
),. . .
2.2.3 Reprsentation dun calcul rparti
Sous les hypothses prcdentes, un calcul rparti peut tre abstrait en terme des ensembles dvnements
produits par chaque processus au cours dune excution particulire. Cest le point de vue vnementiel.
tout processus P
i
peut donc tre associ une suite nie ou non dvnements C
i
totalement ordonns dnotant
des vnements internes, des envois ou des rceptions de messages issus de P
i
ayant eu lieu pour une excution
m1
a1 a2 a3 a4 a5
b1
b2
b3 b4
A
B
C
c2 c3 c1
m3
m4
c4
m5
m2
Figure 2.3 Exemple de calcul rparti
donne. Globalement, un calcul rparti est reprsent par une union de toutes ces suites :
C =
N
1
C
i
Les vnements issus de processus dirents ne sont pas forcment ordonns. Un ordre partiel les relie
cependant, induit par les messages changs.
Un calcul rparti va donc tre caractris par une ordre partiel fond sur une relation dite de causalit.
titre dexemple, la gure (2.3) montre une suite dvnements ayant lieu sur trois sites dirents durant
une excution rpartie comportant des changes de messages entre les sites.
2.2.4 La causalit
La causalit dnit une relation dordre partiel entre les vnements dun calcul rparti. Cette relation
dordre partiel, note , est la plus petite relation transitive satisfaisant les deux conditions suivantes :
Pour tout couple dvnements (e, e
) issu dun mme processus, tel que e prcde e
dans la suite
associe au processus, la relation e e
est vrie ;
Lorsque deux processus changent un message M, les vnements denvoi e et de rception r sont
lis : e prcde toujours r dans un temps global et e est la cause de r. En consquence, pour tout
message M, on aura la relation e r.
Dote de cette relation de causalit, une union C =
N
1
C
i
peut reprsenter un calcul rparti si la relation
est acyclique. En eet, tout calcul rel implique que (C, ) est un ordre partiel strict.
Lide gnrale est que, si e e
, alors e
est potentiellement la consquence de e. Un intrt de lordre

causal tient au fait quil peut tre implant plus ecacement quun ordre total sur les vnements et quil
est nanmoins susant pour beaucoup dapplications.
Dans lexemple de la gure (2.3), certains couples dvnements sont lis causalement, soit directement,
par exemple a
1
c
1
, soit par transitivit de la relation causale, par exemple a
1
b
3
. Par ailleurs, certains
couples dvnements ne sont pas causalement lis, par exemple a
3
et c
1
. On note par [[, labsence de causalit
entre vnements. Autrement dit :
e [[ e
((e e
) (e
e))
Attention, cette relation [[ dnote une relation logique de paralllisme. Elle ne signie pas que les deux
vnements se sont produits simultanment dans le temps global rel mais simplement quils auraient pu
sans enfreindre la causalit.
Si lon se place dans un rfrenciel de temps global, les vnements dun calcul rparti sont ordonns
totalement avec possibilit dvnements simultans (on notera ce cas par e [[[ e
pour le distinguer du cas

prcdent.).
Si lon reprend les vnements de la gure (2.3), lordonnancement rel est par exemple :
a
1
c
1
a
2
b
1
a
3
(b
2
[[[c
2
) a
4
b
3
c
3
b
4
a
5
c
4
Il ne sagit cependant pas de la seule squence dexcution possible compatible avec les contraintes de
causalit existant entre les vnements de ce calcul. Par exemple, lordonnancement suivant est dirent de
la ralit mais parfaitement compatible avec la causalit :
a
1
b
1
c
1
a
2
a
3
(b
2
[[[c
2
) a
4
b
3
a
5
c
3
b
4
c
4
Nous verrons que le mcanisme dhorloge logique de Lamport permet dordonner totalement les v-
nements dun calcul rparti en garantissant nanmoins le respect de la causalit. Cependant, comme nous
venons de le voir, cet ordonnancement ne sera pas forcment dle par rapport la ralit de lexcution.
2.2.5 Description des algorithmes
Puisquun calcul rparti peut tre abstrait sous la forme dun ensemble dvnements relis par la rela-
tion de causalit, la description des algorithmes rpartis utilise souvent une approche de programmation de
type vnementiel. La description dun algorithme prend la forme dune liste de couples (occurrence dv-
nement, routine de traitement). Les occurrences dvnement portent soit sur la rception dun message soit
sur latteinte dun tat par le processus. Chaque processus apparat comme un systme de transitions, le
dclenchement dune transition tant li ltat courant du processus et ventuellement la rception dun
message. Les rgles syntaxiques utilises empruntent aux langages tels que CSP ou Occam trs proches de ce
modle de calcul. titre indicatif, la description de lalgorithme symtrique excut par N processus prend
la forme suivante :
process P(i :0..N-1) {
type Etat = { <Dfinition des tats possibles> } ;
Etat EtatCourant= Init ;
<Dclaration de variables locales>
<Action dinitialisation>
while (<Condition>) {
upon <Condition-1> {<Action-1>}
[]
...
[]
upon <Condition-M> {<Action-M>}
}
}
avec
<Condition-i> = <Prdicat> | reception <message>
La clause upon permet de conditionner une action un prdicat sur ltat courant du processus et la
clause upon reception permet dassocier lexcution dune action lvnement de rception dun message.
Dans les actions, lmission dun message est traduite sous la forme dune instruction send prcisant le type
et le contenu du message ainsi que le ou les destinataires. titre dexemple, lenvoi dun message de type
Calc et de contenu (x, y, z) vers un processus P
j
prendra la forme : send Calc(x, y, z) to P
j
.
Pour certains algorithmes ncessitant du paralllisme interne au processus, plusieurs threads pourront
tre introduits, chacun tant dcrit sous la forme prcdente.
2.2.6 Classes dalgorithmes
Il existe un ensemble de classes gnriques dalgorithmes. Ceux-ci reposent sur des hypothses relatives la
topologie de communication et au comportement des nuds. Aprs une prsentation dun modle de calcul
trs utilis comme hypothse, en loccurrence le calcul diusant, nous prsentons les classes dalgorithme
proprement dit.
Calcul diusant
Le paralllisme des processus et le caractre asynchrone des changes de messages engendrent une dicult
majeure pour apprhender le droulement dun calcul rparti. Il est donc important de pouvoir dnir
quelques schmas gnriques dexcution capables de modliser une large classe de programmes rpartis.
Parmi eux, un modle de base est celui du calcul diusant.
Un programme rparti SR compos de N processus communicants obit au schma dexcution dun
calcul diusant si ses processus respectent les rgles suivantes :
Initialement, un ou plusieurs processus mette(nt) un premier message spontanment ;
Puis, tous les processus sans exception adoptent le mme comportement cyclique gnrique :
while ( Calcul en cours ) {
Recevoir un message M ;
Traiter le message M ;
Diuser ventuellement un ou plusieurs messages dautre processus ;
}
Tout processus passe alternativement dun tat passif (attente de message) un tat actif et inversement.
Ce modle de comportement est assez gnral dans la mesure o il exclut simplement lenvoi spontan
dun message alors que le processus est dans ltat passif.
Un problme important dans ce schma est celui de la terminaison. En eet le test de la boucle nest pas
une condition locale ; il sagit bien de la terminaison globale du calcul. Une faon de dtecter la n du calcul
est de dtecter que tous les processus sont passifs (en attente de message) et que plus aucun message nest
en transit.
Les protocoles
La conception des algorithmes rpartis utilise souvent le principe de couches hirarchises. Ce principe
est en particulier mis en uvre pour les protocoles. Chaque niveau de protocole sappuie sur les messages
du niveau infrieur. Tout niveau de protocole interprte certains champs des messages, champs qui seront
ignors par les niveaux infrieurs.
titre dexemple, un protocole de datation des messages dune application sappuie sur les messages
de cette application pour assurer le service de datation globale des messages. Aucun message spcique
de datation nest ncessaire. Les informations ncessaires au protocole de datation sont concatnes aux
messages applicatifs de manire transparente.
Ce type dapproche prsente lavantage de ne pas engendrer de nouveaux messages mais simplement
daugmenter leur longueur.
Les services
Une deuxime classe dalgorithmes est ddie la ralisation de services pour une application. Comme
pour les systmes centraliss, les concepteurs de systmes rpartis ont essay de dgager un ensemble de
services systme dintrt gnral.
Un service possde une interface dnissant un type abstrait de donne (une classe dobjets).
Les principales classes de services sont :
les services de synchronisation : exclusion mutuelle, allocation de ressources, lection, srialisation,. . .
les services de chiers, de ramasse-miettes, de transactions, . . .
les services de nommage ;
Les services peuvent tre spcis par deux classes de proprits.
Une proprit de sret exprime le service garanti sous la forme dun invariant. Par exemple, pour un
allocateur de ressource critique, linvariant prcise quune ressource ne peut jamais tre alloue plus
dun processus.
Une proprit de vivacit exprime que toute requte doit nalement tre traite. Par exemple, pour le
service dallocation, toute requte devra tre nalement satisfaite. Des contraintes plus fortes dquit
entre les requtes peuvent aussi tre spcies.
Les algorithmes de supervision
Les algorithmes de supervision constituent une classe particulire de services relevant souvent des services
oerts par un systme dexploitation.
Le contrle et la supervision dune application rpartie pose un problme dalgorithmique . . .rpartie.
Par exemple, pour dtecter la terminaison dune application, tous les sites participants doivent tre inter-
rogs. Ainsi, la dtection de proprits globales, en particulier stables, ncessite de superviser lapplication
sans altrer le rsultat nal de lexcution. Pour ces algorithmes de supervision il est donc important de
distinguer dune part, les messages de lapplication et dautre part, les messages ncessaires la collecte des
informations de supervision.
Les tches de supervision consiste en particulier dtecter des proprits stables. Une proprit est
qualie de stable si, ds quelle devient vraie, elle le reste dnitivement dans tout tat ultrieur.
Les algorithmes de dtection de proprits stables constituent une classe importante des algorithmes de
supervision. Si lon note par P.Algo le prdicat qui est vrai lorsque lalgorithme Algo a dtect P et P.SR
le prdicat qui est vrai lorsque le systme supervis SR vrie P, les deux proprits suivantes doivent tre
assures :
une proprit de sret assurant labsence de fausse dtection reprsente par un invariant :
invariant P.Algo P.SR
une proprit de vivacit assurant que si ltat stable est atteint, il sera nalement dtect par lalgo-
rithme :
P.SR P.Algo
Symtrie
Lorsque les N processus P
i
du calcul excutent le mme code, lalgorithme est dit symtrique. Seules les
valeurs initiales des variables (rpliques) de chaque processus peuvent tre direntes. Le comportement
des processus peut donc tre dirent selon leurs tats locaux initiaux.
2.2.7 Flots de contrle rparti (ou comment mettre de lordre dans les mes-
sages)
Si lon nimpose aucune rgle dans lchange des messages, un calcul rparti a de forte chance dapparatre
chaotique et impossible mettre au point. Un ensemble de rgles ou de protocoles particuliers ont donc t
proposs pour matriser la complexit en structurant le ot global des messages.
La dmarche consiste assujettir les changes de messages certaines rgles qui permettent ainsi de
structurer lvolution du contrle. En eet, les ux de messages de nud en nud jouent un rle
dterminant dans lenchanement des traitements. Puisquil sagit dchanges de messages, un premier type
de rgle possible concerne la topologie logique de communication laquelle on se conformera, bien sr
compatible avec les possibilits oertes par larchitecture relle. Par exemple, une architecture peut orir un
maillage complet des nuds. Cependant, pour implanter un service dexclusion mutuelle, on se limitera
faire circuler un message jeton sur un anneau logique passant par tous les sites.
Un deuxime type de rgle porte sur le dcoupage de lalgorithme en phases successives ou vagues. La
notion de vague permet par exemple dtendre la notion de boucle au contexte rparti.
Enn, la notion de synchronisme virtuel permet dassurer quun groupe de processus reoit les mmes
messages en respectant les rgles de causalit qui les relient. Nous envisageons successivement : lanneau,
larbre de recouvrement pour les aspects de topologie logique, la vague pour la notion ditration rpartie,
les protocoles ordonns et le synchronisme virtuel.
Anneau
Lutilisation dune topologie danneau restreint fortement le ux de messages dun calcul rparti. Cette
structure est cependant trs utile et utilise. Nous avons vu un exemple avec la notion de jeton qui permet de
trouver un solution simple (sur un rseau able) au problme de lexclusion mutuelle ou de llection. Cette
topologie permet aussi une mise en uvre simple de la diusion dun message tous les sites connects
lanneau.
Arbre de recouvrement
La topologie darbre dun arbre de recouvrement (cest--dire incluant tous les nuds) permet, comme
lanneau, de propager un message vers tous les autres sites. Cette structure est bien adapte un calcul
rparti comportant une ou plusieurs tapes de type (enqute, collecte) lances par dirents nuds quand
ils le veulent. Il faut cependant que lon dispose donc dun arbre de recouvrement spcique chaque nud
de dpart, nud qui doit alors tre racine de larbre. En consquence un problme classique est de rsoudre
la construction mme de larbre en mettant en uvre un algorithme rparti.
Hypothses On considre un ensemble de nuds connects par des canaux bidirectionnels ables. La
topologie du rseau est connexe. Chaque site connait son identit et les canaux avec ses voisins immdiats.
Rsultat Si un nud i dcide de lancer lalgorithme, celui-ci devra conduire la construction dun arbre
de recouvrement ayant pour racine i. Une fois lalgorithme termin, chaque nud doit tre plac dans larbre
cest--dire connatre son pre et la liste de ses ls ( la liste des canaux conduisant des ls).
Nous prsentons la dnition dune classe Java implantant un nud. Si lon admet que la mthode
parcourir peut tre appele distance par un protocole de type RMI (Remote Method Interface), une
construction squentielle de larbre peut tre obtenue par lappel de Racine.parcourir(null). On suppose
que le voisinage de chaque noeud est initialis aprs la cration de tous les noeuds (liste publique voisins).
import java.util.*;
public class Noeud {
private Noeud pere = null ; // pre du noeud
public List voisins ; // voisins du noeud
private List fils = new ArrayList(); // fils du noeud
// Place le noeud this et poursuit ou stoppe le parcours si this est en place
public Noeud parcourir ( Noeud appelant ) {
if (pere != null) return null ; // Dj plac
pere = appelant; // Placement
Iterator lnd = voisins.iterator(); // Recherche des descendants
while (lnd.hasNext()) {
Noeud unNd = (Noeud) lnd.next();
// Appel de type RPC
if (unNd.parcourir(this) == unN) { fils.add(unNd);}
}
return this ;
}
}
Exercice
1. On voudrait pouvoir construire des arbres de recouvrement issus des dirents nuds. Il faut alors
identier les arbres. Modier la classe Nud pour orir cette possibilit.
2. Il est possible de parcourir tous les voisins dun nud en parallle. Modier la classe pour obtenir ce
parcours parallle.
Itration rpartie (notion de vague)
De nombreux algorithmes obissent un schma gnrique de type (enqute, collecte) auprs des autres
sites participants. Par exemple, pour savoir si une application de type calcul diusant est termine, un
processus superviseur peut dclencher une enqute pour connatre ltat des autres. Il sera amen rpter
cette enqute ultrieurement si la collecte des rsultats fait apparatre un ou plusieurs sites actifs et/ou des
messages encore en transit.
Ce type de comportement, que lon peut qualier ditration rpartie, peut tre implant grce au mca-
nisme de vague [22]. Une vague est caractrise par les oprations suivantes :
interface Vague {
public void Enqueter (Object Quoi ) ;
/* lance une nouvelle vague */
public void Visiter (Object Quoi, Collecte) ;
/* passage dune vague sur un site */
public void Faire_Suivre(Object Quoi, Collecte) ;
/* propagation de la vague par un site */
public Collecte Collecter() ;
/* collecte des rsultats et fin de la vague */
}
Proprits
Un site origine peut lancer une nouvelle vague par lopration Enqueter en prcisant la nature de
lenqute. Chaque nud cible de la vague doit accepter lopration de visite. Celle-ci permet de collecter
des informations. Aprs quoi, le nud fera suivre la vague vers dautres sites. Sur le site origine, lopration
Collecter permet de collecter lensemble des rsultats et la terminaison de cette opration coincidera avec
la n de la vague.
Remarque Lorsque les nuds participent lexcution dune vague, ils respectent les rgles dun calcul
diusant. Une vague est donc un exemple de calcul diusant.
Rgles de causalit
Si lon considre les oprations dune vague comme des oprations atomiques, il est possible dassocier
un vnement toute occurrence dopration. On notera op
i
s
, lexcution de op sur le site s pour la i-ime
vague.
Une itration rpartie issue dun site s
0
doit alors obir aux rgles de causalit suivantes :
Chronologie des vnements dans une vague
s : Enqueter
i
s0
V isiter
i
s
Faire_Suivre
i
s
Collecter
i
s0
Squentialit des vagues
i : Collecter
i
s0
Enqueter
i+1
s0
Ralisation
Une vague peut tre implante de plusieurs manires. Cest en cela mme quelle constitue une abstraction
en masquant la topologie exacte de communication utilise pour mener bien la collecte.
titre dexemple, une vague peut-tre implante laide dun jeton circulant. Le tableau de la gure
(2.4) prcise limplantation de chaque opration dune vague laide dun jeton.
Site Vague Jeton
Site origine Enqueter Emettre(Quoi)
Site visit Visiter Recevoir(Quoi,Collecte)
Site visit Faire_Suivre Emettre(Quoi,Collecte)
Site origine Collecter Recevoir(Collecte)
Figure 2.4 Implantation dune vague laide dun jeton
t
0
P3
P2
P1
e1 e
r
e2
r2 r1
m
m1
m2
Figure 2.5 Liaison causale en mission
Exercices
1. Vrier que limplantation dune vague laide dun jeton respecte les rgles de causalit des vnements
associs une vague ;
2. Quelle possibilit doptimisation des performances nest pas utilise dans limplantation dune vague
laide dun jeton?
3. Reprendre le tableau de la gure (2.4) en supposant que la vague est propage via un arbre de recou-
vrement ayant pour racine le nud origine de la vague.
Les protocoles ordonns
Nous avons vu quun nud possde une perception approximative de son environnement. En particulier,
si deux messages lui parviennent de deux sites distincts, il peut trs bien ignorer quel message a t mis le
premier (dans un rfrentiel de temps global). Or, il peut exister une causalit entre les vnements dmission
des deux messages. Il sut de considrer le chronogramme (2.5) :
Le message m
1
est reu aprs m
2
sur le site P3 alors quun lien causal existe entre les deux messages en
mission (e
1
(e r ) e
2
). Autrement dit, le message m2 reu par P3 peut tre incomprhensible
pour celui-ci si dune part, m2 est une consquence de m1 (via m) et dautre part, P3 na pas vu m1.
Il est donc intressant et important de concevoir des protocoles qui vitent ce genre dincohrence poten-
tielle. Pour de tels protocoles, on est amen distinguer dune part lvnement de rception du message par
le nud et dautre part, la dlivrance eective du message lapplicatif. On doit donc associer un vnement
de dlivrance d
m
tout message m.
Un protocole ordonn (dordre causal) est un protocole qui assure la proprit suivante pour tout site de
destination S :
m, m
vers S : e
m
e
m
d
m
d
m
Diverses implantations de tels protocoles sont possibles. On peut remarquer que le contrle pour la
dlivrance dun message est toujours local au site rcepteur : on a toujours comparer des vnements
dmission de messages reus sur le mme site.
m2
0
P3
P2
P1
t
m1
m3
Figure 2.6 Diusion simple
dun groupe
S3
S2
S1
Cl2
Cl1
Frontire
Figure 2.7 Diusion anarchique
Le synchronisme virtuel
Lun des intrts importants de la rpartition est de pouvoir rpliquer des traitements ou des donnes
de faon obtenir des services plus ables et disponibles. Cependant, la rplication implique lutilisation de
protocoles non plus point point mais de diusion.
Or, la complexit des changes de messages est plus grande lorsque lon utilise des protocoles de diusion.
Deux problmes majeurs apparaissent :
Squentialit : Les messages successifs mis par un nud seront-ils reus dans le mme ordre par tous
les nuds cibles de la diusion;
Atomicit : Tous les sites cibles recevront-ils chaque message dius ?
Le chronogramme de la gure (2.6) montre limbroglio de messages pouvant rsulter dun protocole de
diusion faible cot.
Or, la diusion vers des groupes de processus (multicast) est utile pour raliser des applications robustes
et haute disponibilit. En eet, une mthode classique pour obtenir ces proprits de robustesse et de
disponibilit est dutiliser la redondance des ressources oertes par une architecture rpartie.
Dans un schma classique client-serveur, le service peut tre rendu plus robuste en activant deux serveurs
jumeaux. Larrt de lun nentranera pas larrt du service.
Cependant, il faut alors diuser les requtes vers les deux serveurs en assurant que celles-ci arriveront
dans le mme ordre et que toute requte sera prise en compte par les deux serveurs ou par aucun.
Le modle dexcution quali de synchronisme virtuel a pour objectif de fournir des protocoles capables
de respecter de telles proprits. Les systmes ISIS et HORUS [4] sont des exemples denvironnements
dexcution rpartie orant de tels protocoles.
Un calcul rparti virtuellement synchrone assure que les processus appartenant un mme groupe peuvent
tre cibles de diusions totalement ordonnes atomiques.
Les gures (2.7) et (2.8) rsument les dirences essentielles entre un protocole de diusion de base et
un protocole assurant un modle dexcution virtuellement synchrone.
La ralisation dun noyau dexcution support du synchronisme virtuel ncessite de fournir deux types
de primitives :
les primitives de gestion des groupes : on distingue lopration dentre dans un groupe (de sortie dun
groupe) et lopration de connexion en tant que client un groupe (de dconnexion) ;
les primitives de diusion : protocole de diusion ordonne assurant le respect de la causalit, protocole
Cl1
S3
S2
S1
Cl2
Figure 2.8 Diusion virtuellement synchrone
de diusion atomique assurant un ordre total et le caractre atomique de la diusion.
2.2.8 valuation de la complexit
La complexit des algorithmes rpartis se mesure essentiellement en terme des paramtres lis la com-
munication. Des paramtres cls sont la longueur des messages et leur nombre. un niveau dabstraction un
peu plus lev, on peut souvent distinguer des phases squentielles de calcul (vagues successives par exemple).
Il sagit alors de minimiser le nombre de phases successives. Enn, des proprits particulires peuvent tre
prises en compte telles que : la tolrance aux fautes de lalgorithme, son caractre auto-stabilisant, sa
symtrie, etc . . .
2.2.9 Un exemple dalgorithme : le problme de llection
Hypothses
On considre N processus < P
i
>
0i<N
communiquant via un rseau en anneau unidirectionnel. Chaque
processus connat donc un prdcesseur P
i
.pred dont il peut recevoir des messages et un successeur P
i
.suc
auquel il peut envoyer des messages. Chaque processus a une identit distincte des autres mais ne connait
pas lidentit des autres.
Il existe un ordre total entre les identits de chaque processus (par exemple lordre lexical si les processus
sont identis par un nom symbolique).
Le problme de llection consiste ce quun processus unique se reconnaisse comme lu au terme de
lexcution dun algoritme dlection identique pour tous les processus.
Compte tenu des hypothses faites, une solution simple consiste propager, via des messages sur lanneau,
les identits de chaque processus an quun processus P
i0
nissent par avoir la connaissance globale suivante :
P
i0
.Elu i : 0 i < N i ,= i
0
:: P
i0
.nom < P
i
.nom
Autrement dit, le processus i
0
sait quil possde la plus petite identit et sera dclar lu.
Une spcication du problme
De faon habituelle, on peut abstraire les processus participants en considrant seulement deux tats et
une transition cl . Initialement, tout processus est dans ltat non lu. Lobjectif est de parvenir un
tat o un seul processus nit par tre dans ltat lu. Le graphe (2.2.9) illustre cette abstraction de chaque
processus en terme dun systme de transitions.
Lalgorithme doit assurer lunicit de llu en garantissant linvariant :
invariant i, j : 0 i, j < N :: P
i
.Elu P
j
.Elu i = j
Elu
Elu
Non
Figure 2.9 Abstraction des tats dun processus participant
Seule la transition de ltat non lu lu est autorise :
stable P
i
.Elu
Par ailleurs, il doit garantir que nalement un processus sera lu :
true i
0
: P
i0
.Elu
Pour dcider de llection, nous avons vu quil fallait valuer, pour chaque processus P
i
, le prdicat global
j : 0 j < N j ,= i :: P
i
.nom < P
j
.nom
Les changes de messages selon les rgles imposes par une topologie du rseau en anneau permettent de
dvelopper une solution simple pour valuer ce prdicat global.
Chaque processus commence par envoyer son identit son successeur. Puis il entre dans une boucle
consistant accepter les noms envoys par son prdcesseur. Pour chaque nom reu, il adopte le comportement
suivant :
soit le nom reu est plus grand que celui du processus rcepteur : celui-ci ne retransmet pas le nom
reu son successeur ;
soit le nom reu est plus petit que celui du rcepteur : celui-ci propage ce nom son successeur ;
soit le nom reu est celui du processus rcepteur : alors celui-ci peut se dclarer lu. En eet, si
le nom quil a mis est revenu, cest quil est pass par tous les processus et donc que le prdicat
P
i0
.nom < P
i
.nom a t trouv vrai par chaque processus P
i
, i ,= i
0
.
La rception dun nouveau nom permet un processus i dvaluer un nouveau terme P
i
.nom < P
j
.nom. Le
fait quun nom revienne son metteur signie quil a t compar tous les autres et trouv plus petit que
tous les autres. La dcision dlire le processus rcepteur peut donc tre prise.
Lalgorithme ralise donc simplement une valuation rpartie du prdicat global.
Une description de lalgorithme peut se faire sous forme dune classe. Le dploiement pour excution
consistera, pour chaque processus de lanneau, instancier un objet de cette classe, lanneau de communi-
cation tant suppos cr :
public class Election {
private String nom = java.net.InetAddress.getLocalhost().getHostName();
private String unCandidat = null;
private boolean elu = false ;
public void Election() {
Anneau.envoyer(nom) ;
while (!elu) {
Anneau.recevoir(unCandidat) ;
/* propagation ventuelle */
if (unCandidat < nom) Anneau.envoyer(unCandidat) ;
/* test dlection */
elu = (unCandidat == nom) ;
}
}
Remarques
Une telle description suppose que le media de communication Anneau est capable de mmoriser
des messages en transit. En eet, tous les processus commencent par mettre. Il faut donc que ces
missions ne soient pas toutes bloquantes. La communication devra tre de type asynchrone ;
Tous les processus tentent leur chance en commenant par mettre leur nom vers leur successeur. En
fait, il surait quun seul en prenne linitiative et que chaque processus modie son comportement
lors de larrive dun nom. Si le nom reu ne doit pas tre propag (il est plus grand que le nom du
rcepteur), alors le rcepteur dcide de tenter sa chance en envoyant cette fois-ci son nom;
Le comportement des processus prsente les proprits dun calcul diusant.
Exercices
1. Dans lexemple prsent, seul llu se termine. Complter lalgorithme de faon ce que tous les
participants connaissent le nom de llu et se terminent ;
2. Pour ce mme algorithme, il surait quun seul processus prenne linitiative denvoyer son nom son
successeur pour dclencher le calcul. Quelle modication doit-on faire dans le comportement de chaque
processus pour obtenir nalement la terminaison de llection ; alors le rcepteur dcide de tenter sa
chance en envoyant cette fois-ci son nom;
3. Vrifer quun tel calcul rparti satisfait les proprits dun calcul diusant ;
4. valuer la complexit de lalgorithme en nombre moyen de messages changs. En dduire sil est
moins complexe quun algorithme qui consisterait, pour tous les processus, diuser leur nom tous
les autres.
2.3 Au-del du modle standard (ou comment oublier les messages)
La description de la communication en terme de messages est dun niveau dabstraction peu lev. Cest
pourquoi, les concepteurs de systmes dexploitation ont propos des mcanismes de communication plus
labors. Un objectif ambitieux de ces mcanismes est souvent de masquer le phnomne de communication
(de rpartition).
En ce qui concerne les traitements, un concept bien accept est celui de procdure accessible distance.
Elle est la base du modle client/serveur qui structure la plupart des applications rparties actuelles. La mise
en uvre dun mcanisme dappel procdural distance (RPC) est cependant dlicate. Plusieurs variantes
dimplantation peuvent tre envisages avec des smantiques distinctes.
En ce qui concerne les donnes, on peut distinguer dune part la communication par mmoire partage
et dautre part, la communication par chiers partags.
La notion de mmoire partage rpartie a pour objectif de fournir au programmeur dapplications un
modle de programmation centralis. Il peut disposer dune mmoire globale pour communiquer entre
processus distants. La dicult majeure pour raliser une telle abstraction sur une architecture rpartie
est dviter une trop forte synchronisation des accs cette mmoire partage rpartie. Lutilisation de la
rplication permet daugmenter le paralllisme daccs la mmoire mais des contraintes de cohrence des
copies doivent tre garanties pour garder une smantique de mmoire globale.
Enn, un service de chiers rpartis a t un des premiers services tre implant. Laccs des chiers
distants en assurant la transparence daccs (mme interface que pour un chier local) et de localisation
(dsignation logique indpendante du site) constituent les deux proprits de base garanties par les systmes
de gestion de chiers rpartis. De nombreux systmes ont t dvelopps. Un standard de fait est le systme
NFS (Network File System) de SUN. Une dicult majeure est de garantir une smantique quivalente
celle dun systme de chiers centraliss. En eet, le partage de chiers pose des problmes voisins du
partage mmoire prcdent. Des problmes dordonnancement des accs en lecture-criture par plusieurs
clients doivent tre contrls pour garantir que la version lue par un client est la dernire version crite. En
la matire, les concepteurs ont d trouver un compromis entre une smantique centralise garantie coup
sr et des performances acceptables.
Chapitre 3
Temps et causalit
3.1 Datation
Un problme de base des systmes rpartis est la datation des vnements signicatifs (mission et
rception des messages en particulier) durant lactivit du systme. Ceci permet de reconstituer lexcution
des ns de mise au point par exemple ou de contraindre la prise en compte de requtes dans un certain
ordre.
En gnral, un mcanisme de datation doit respecter une rgle fondamentale : tre compatible avec la
relation de causalit qui peut exister entre toute paire dvnements. Autrement dit,
e, e
: e e
date(e) < date(e
)
On peut distinguer deux approches :
une approche temps rel consistant dater les vnements avec une horloge la plus prcise possible.
La dicult est alors de disposer de cette horloge globale ;
une approche temps logique consistant dater les vnements en respectant la causalit selon la rgle
nonce.
3.1.1 La datation Temps rel
Cette approche pose le problme de la disponibilit dune horloge globale. En eet, comme nous lavons
soulign, un systme rparti ne dispose justement pas dun rfrentiel global de temps. Chaque nud possde
une horloge locale plus ou moins prcise et surtout non synchronise a priori avec les horloges des autres
nuds. Une datation directe laide de telles horloges ne convient donc pas car des anomalies causales
peuvent tre engendres. Il sut que lhorloge du nud metteur soit en avance sur celle du nud rcepteur
pour obtenir un message dont la date de rception est antrieure la date dmission.
Pour rsoudre ce problme, des algorithmes de synchronisation dhorloges ont t conus et implants.
Ils permettent de recaler les horloges des nuds de faon ce que leur dirence reste dans un intervalle
born connu. Lalgorithme doit maintenir un invariant du type :
invariant Max(h
i
: i = 1, N) Min(h
i
: i = 1, N) <
On obtient ainsi une prcision qui garantira une datation correcte si tous les vnements causalement lis
sont spars par un dlai suprieur la prcision de lhorloge globale ainsi implante.
La datation temps rel ncessite donc un protocole de synchronisation dhorloge complexe et relativement
couteux. La disponibilit dun metteur unique (diusion de tops par une horloge atomique par exemple)
peut apporter une simplication dans la mise en uvre et plus de prcision. Cependant, la solution est
alors centralise par nature et donc moins tolrante aux dfaillances : dfaillance de lmetteur, mais aussi
dfaillance locale des rcepteurs.
39
Enn, pour de nombreuses applications, seul le respect de la causalit est important. Il est mme parfois
souhaitable de savoir si deux vnements sont causalement lis ou non. Une datation temps relle ordonne
totalement tous les vnements et ne permet donc pas de distinguer ceux qui sont indpendants (sans
causalit) malgr leur prcdence temporelle.
Face ces inconvnients, des solutions fondes sur un temps logique ont t tudies.
3.1.2 Datation Temps logique
Deux solutions ont t dcouvertes :
la premire, due L. Lamport, permet de dater les vnements selon un ordre total. Linconvnient
ventuel de cette approche est donc de mme nature que celui dune datation relle : lintroduction
dun ordre arbitraire entre des vnements indpendants.
la seconde, due F. Mattern, permet de dater les vnements selon un ordre partiel isomorphe
la relation de causalit. Ce mcanisme est plus prcis mais plus coteux implanter et permet de
distinguer (dtecter) les vnements indpendants. Toutefois, un tel mcanisme ne permet pas de
dcider de lexistence dun vnement entre deux vnements causalement lis.
Horloges de Lamport
Une date est un couple (s, cpt), o s est un numro de site et cpt est un entier, la numrotation des sites
tant suppose totalement ordonne. Lentier permet de comparer deux dates et en cas dgalit, le numro
de site permet de distinguer les deux dates. Si deux dates, ayant le mme champ site, nont jamais la mme
valeur entire, toutes les dates sont direntes et comparables.
Une horloge locale chaque site permet de dater les vments ayant lieu sur le site correspondant. Cette
horloge mmorise une date courante (s, cpt) o s est donc le site local de lhorloge. Pour que les dates obtenues
partir de ces horloges soient toutes direntes mais comparables, lalgorithme de gestion dhorloge doit
assurer linvariant :
invariant d, d
: d.s = d
.s (d.cpt ,= d
.cpt)
Pour cela, il sut que toute consultation de lhorloge pour dater un vnement, entrane lincrmentation de
lentier compteur.
Les classes Date et Horloge suivante donnent une implantation possible du mcanisme de datation.
class Date implements Cloneable { // dfinition et comparaison de date
protected int s ; protected int cpt ;
static boolean Prec ( Date d1, Date d2 ) {
return (d1.cpt < d2.cpt) ||( (d1.cpt == d2.cpt) && (d1.s < d2.s)) ;
}
}
class Horloge extends Date {
// Cration de lhorloge
Horloge( int o ) { s = o ; cpt = 0 ; }
// Lecture-Incrmentation de lhorloge
Date Top()
{ Date dc = (Date) super.clone(); this.cpt++; return dc ; }
// Recalage de lhorloge
void Recaler( Date d ) { if (Prec(this,d)) this.cpt = d.cpt + 1 ; }
// soit encore this.cpt = Max(this.cpt,d.cpt) + 1
}
(C,1)
a1 a2 a3
c1 c3 c2
<(A,2),m2>
b3 b2
A
B
C
(A,0)
(B,0)
(C,0)
b1
(A,3) (A,2) (A,1)
<(A,0), m1>
a4
(B,3) (B,4) (B,5)
(A,4)
<(B,3),m3>
<(B,4),m4>
(C,5) (C,0)
Figure 3.1 Horloges de Lamport
Les actions suivantes seront excutes sur occurrence de chaque type dvnement :
Type dvnement sur un site s Action mettant en jeu lhorloge du site s
vnement interne sur s H
s
.Top()
mission sur s de m dm = H
s
.Top() ; envoi de < dm, m >
Rception sur s de < dm, m > H
s
.Recaler(dm)
Le chronogramme de la gure (3.1) montre lvolution des horloges de chaque site et la surcharge des
messages par la date dmission de chaque message. On remarquera que les vnements de rception ne
sont pas dats. Ils ne sont loccasion que dun recalage de lhorloge du site de rception mais nentrane pas
dopration Top().
Les horloges de Lamport permettent un ordonnancement total des vnements dun calcul rparti en
respectant la causalit qui peut exister entre ces vnements. Nanmoins, lordre introduit entre des vne-
ments causalement indpendants ( logiquement simultans) est arbitraire. titre dexemple, la gure (3.1)
montre que lvnement a
3
a pour date (A, 2) et lvnement c
2
a pour date (C, 1) : on a donc c
2
qui prcde
a
3
avec cette datation alors que dans le temps absolu cest linverse qui sest produit. Ceci nest pas erron
puisque ces deux vnements ne sont pas causalement lis.
Horloges de Mattern
Nous venons de voir que le mcanisme de datation par les horloges de Lamport respecte lordre causal
mais ne permet pas davoir limplication rciproque : e, e
: d
e
< d
e
e e
. Cest ce que les horloges

de Mattern vont assurer.
Pour ce faire, il faut passer une datation vectorielle. Une date (globale) est un vecteur D de dimension
gale au nombre de sites. La composante D[i] dun tel vecteur indique le nombre dvnements ayant eu lieu
sur le site i et qui prcde causalement cette date. La relation dordre entre 2 dates devient alors :
D, D
: D D
i : D[i] D
[i]
et
D, D
: D < D
D D
k : D[k] < D
[k]
On peut alors constater que deux dates peuvent videmment tre non comparables puisquil peut exister des
dates telles que :
D [[ D
(D < D
) (D
< D)
En fait, la relation dordre dnie peut correctement traduire la relation de causalit par un mcanisme
adquat de gestion des horloges correspondantes.
Chaque site s gre une horloge vectorielle H
s
. La datation dun vnement se produisant sur un site s
entranera lincrmentation de la composante correspondante de lhorloge locale au site. Deux vnements
distincts quelconques nauront donc jamais la mme date et par consquent seule la relation < nous intresse.
Comme prcdemment, chaque message sera surcharg par la date de lvnement dmission.
La classe dcrivant une date vectorielle devient :
class DateV { // dfinition et comparaison de date
protected int cpt[] ;
// Oprateur de prcdence
public boolean Prec ( DateV d1, DateV d2 ) {
for ( int i = 0 ; i < cpt.length ; i++)
if (d1.cpt[i] > d2.cpt[i]) return false ;
return true;
}
// Constructeur
DateV(int dim) {
cpt = new int[dim] ; for ( int i=0 ; i < cpt.length ; i++) cpt[i] = 0 ;
}
}
On peut remarquer que la notion de site nintervient plus en composante dune date puisque lon a une
valeur propre chaque site. Par contre, un objet horloge reste prsent sur chaque site.
Les actions associes aux vnements internes, dmission et de rception restent les mmes que pour les
horloges de Lamport, seul le type date ayant chang (voir A.2).
class Horloge extends DateV {
protected int s ; // localisation de lhorloge
// Cration de lhorloge
Horloge( int o , int dim ) { super(dim) ; this.s = o ; cpt[o] = 1 ;}
// Lecture-Incrmentation de lhorloge
DateV Top() throws Exception
{ DateV dc = (DateV)super.clone(); this.cpt[s]++; return dc ; }
void Recaler( DateV D ) {
for (int i=0 ; i < cpt.length ;i++)
this.cpt[i] = Math.max(this.cpt[i],D.cpt[i]) ;
this.cpt[s]++ ; // Top implicite
}
}
Le tableau suivant prcise les actions excutes lors sur les vnements internes ainsi que lors des missions
et rceptions.
s
.Top()
mission sur s de m dvm = H
s
.Top() ; envoi de < dvm, m >
Rception sur s de < dvm, m > H
s
.Recaler(dvm)
La gure (3.2) illustre lvolution des horloges vectorielles sur 3 sites. On remarquera que la composante
locale du vecteur (H
s
[s]) comptabilise exactement le nombre dvnements ayant lieu sur le site. Par ailleurs,
toute date vecteur d
e
associe un vnement e mmorise le nombre dvnements causalement lis e.
titre dexemple, lvnement c
3
est dat (3, 3, 3) et lon constate quil y a eectivement 3 vnements sur les
sites A (a
1
, a
2
, a
3
) et B (b
1
, b
2
, b
3
) et 2 vnements sur C (c
1
, c
2
) qui prcdent c
3
.
Enn, on remarquera que les vnements de rceptions sont dats explicitement et comptabiliss.
(3,3,4)
a1 a3
c1 c3 c2
b3 b2
A
B
C
b1
a4 (1,0,0)
(0,0,1)
(2,0,0)
a2
(3,0,0) (4,0,0)
<(1,0,0), m1>
<(3,0,0),m2>
(1,0,2) (1,0,3)
(0,1,0) (3,2,0) (3,3,0)
<(3,3,0),m4>
<(3,2,0),m3>
(5,2,0)
(3,4,0)
Figure 3.2 Horloges de Mattern
Exercices
1. Dans le mcanisme dhorloge de Lamport, pourrait-on ne pas dater explicitement les vnements dmis-
sion ?
2. On essaie de dnir un mcanisme de datation avec seulement un compteur local par site (on limine la
composante site des horloges de Lamport). Donner les rgles de gestion de telles horloges pour assurer
le respect de la relation : e, e
: e e
d
e
< d
e
3. Montrer sur un exemple, que le mcanisme prcdent nassure pas la rciproque :

e, e
: d
e
< d
e
e e
4. Montrer que les horloges de Mattern assurent :

e, e
: e e
d
e
< d
e
5. Pourrait-on ne pas dater explicitement les vnements de rception avec des horloges de Mattern ?
(Tout en conservant leur proprit prcdente).
3.2 Protocoles dordre causal
Le transfert des messages dans un rseau ne respecte pas forcment des rgles dordonnancement strictes.
Par exemple, dans un protocole point point, lordre de rception des messages issus dun mme site par
un site x nest pas forcment identique leur ordre denvoi.
Plus gnralement, il peut tre intressant dordonner la dlivrance des messages reus par un site de
faon respecter la causalit qui peut exister entre les vnements dmission de ces messages. Pour ce
faire, on doit donc distinguer dune part, lvnement de rception dun message par un site et dautre part,
lvnement de dlivrance de ce message au niveau applicatif. En eet, des messages reus dans lordre inverse
de leur causalit dmission devront tre rordonns sur le site de rception pour tre dlivrs dans le bon
ordre.
Cette contrainte peut tre formalise de la faon suivante :
s : (m, m
: r
s
r
s
:: e e
d d
))
La gure (3.3) montre un exemple qui peut trs bien se produire lorsquon communique par e-mail. Un
usager A pose une question deux usagers B et C en leur envoyant un message chacun. Lusager B reoit en
premier le message question m. Il rpond alors A et C (constatant que la question a t aussi envoy
C grce au champ destinataires du message). Lusager C reoit alors via le message m2 une rponse dont
il ne connat pas la question. Celle-ci arrivera plus tard sous la forme du message m1. On remarquera que
cette anomalie tient au fait que les deux messages m1 et m2 qui sont reus par le site C dans lordre inverse
de leur prcdence causale dmission puisque e
1
e
2
. Dans ce cas un protocole dordre causal dlivrera les
messages dans lordre inverse. Si lon note d
1
et d
2
les vnements de dlivrance des deux messages, alors on
aura d
1
d
2
.
m3
A
C
B
e1 e
m
r
m1
m2
e2
r2 r1 d1 d2
(1,0,0)
(2,2,0)
Figure 3.3 Protocole point point dordre causal
3.2.1 Implantation du protocole dans le cas point point
Si lon utilise le mcanisme dhorloge de Mattern pour dater les vnements, les messages m
1
et m
2
emportent avec eux la date de leur mission. Sur lexemple de la gure (3.3), on constate que lon a bien
d
e1
d
e2
( puisque (1, 0, 0) < (2, 2, 0)). Mais, lors de la rception du message m
2
, la date d
e2
ne permet pas
de conclure quun message m
1
existe et aurait d tre dj reu et dlivr. Ce nest que lorsque le message
m
1
arrivera que lon dtectera lanomalie de causalit dans la rception des deux messages. Par consquent,
il faut mettre en uvre un protocole spcique.
Approche par matrice de prcdence (Raynal)
Pour dcider si un message m peut tre dlivr lapplicatif dun site s, il faut savoir si tous les messages
qui devaient tre reus par s et dont lmission prcde causalement ce message m sont arrivs et ont t
dlivrs.
Pour ce faire, un site s doit grer :
dune part, un vecteur Dernier[N] indiquant le numro dordre du dernier message reu par ce site et
provenant de chaque site origine possible.
dautre part, une matrice carre de prcdence MP[N, N] dont chaque lment MP[i, j] indique le
nombre dmissions du site i vers le site j connu du site s.
Les actions suivantes seront excutes sur occurrence des vnements dmission et de rception :
mission sur s de m vers s
MP
s
[s, s
] + +; envoi de < MP
s
, m >
Rception sur s
de < MP
s
, m > Rordonner(MP
s
, m)
Une description en Java de ce protocole comporte deux classes :
dune part, la classe Prcdence qui dcrit le type de matrice carre NxN captant la causalit des
messages ;
import java.util.* ;
class Prcdence {
protected int[][] cpt ; // matrice de prcdence
protected int orig; // identit du crateur
protected int N ; // nombre de sites
// Cration de la matrice de prcdence
Prcdence ( int loc, int nbSite ) {
cpt = new int[nbSite][nbSite] ;
for (int i=0 ; i < nbSite; i++)
for (int j=0 ; j < nbSite ; j++) cpt[i][j] = 0 ;
orig = loc ; N = nbSite ;
}
// Recaler la matrice sur une autre
void Max(Prcdence MX) {
for (int i=0 ; i < N ; i++)
for (int j=0 ; j < N ; j++)
cpt[i][j]=Math.max(cpt[i][j],MX.cpt[i][j]);
}
}
dautre part, la classe Protocole qui dcrit lalgorithme de traitement des missions (TopEnvoi) et des
rceptions (Rordonner).
Le contrle de lordonnancement des messages reus pour assurer leur dlivrance dans un ordre causa-
lement correct sappuie sur la prcondition suivante pour un message < MP, m > reu par s :
dune part, ce message issu du site MP.orig doit bien tre le prochain message dlivrer (caractre
FIFO de la communication entre le site metteur et le site rcepteur). Autrement dit le prdicat
suivant doit tre vri :
with Protocole@s :: MP.cpt[MP.orig][s] = Dernier[MP.orig] + 1
dautre part, ce message ne doit pas prcder des messages dont lmission le prcde causalement,
cest--dire :
with Protocole@s :: i ,= s :: MP.cpt[i, s] Dernier[i]
Cest cette conjonction qui est teste par la fonction dlivrable.
Toute rception de message se traduira par un appel la mthode Rordonner qui retardera ventuel-
lement la dlivrance du message correspondant.Les messages applicatifs seront consomms dans lordre
chronologique de terminaison des oprations Rordonner.
class Protocole extends Prcdence {
protected int s ; // localisation
protected int[] Dernier ; // vecteur de comptage des reus
protected List AttDel ; // liste dattente de dlivrance
// Top sur envoi de message vers le site $dest$
Prcdence TopEnvoi(int dest) throws Exception {
this.cpt[s,dest]++;
return (Prcdence)super.clone();
}
// test si le message associ la matrice de prcdence est dlivrable
boolean dlivrable(Prcdence MP) {
for (int i=0 ; i < N ;i++)
if ((i == s && MP.cpt[MP.orig][s] != Dernier[MP.orig] + 1)
|| (i != s && MP.cpt[i][s] > Dernier[i])) return false ;
return true ;
}
// Ordonnancement de la dlivrance des messages
synchronized void Rordonner( Prcdence MP, String Message ) throws Exception {
if (!dlivrable) { AttDel.add(MP) ; MP.wait() ; }
// dlivrable(MP) => mise--jour de this
this.Dernier[MP.orig]++ ; this.Max(MP) ;
// Rveil de messages en attente
ListIterator curseur = AttDel.listIterator(0) ;
while (curseur.hasNext()) {
Prcdence mp = (Prcdence) curseur.next() ;
if (dlivrable(mp)) { mp.notify() ; curseur.remove() ; }
}
}
// Constructeur
Protocole(int o , int dim) {
super(o,dim) ; s = o ; Dernier = new int[dim] ;
for (int i=0 ; i < N ; i++) Dernier[i]=0 ;
AttDel = Collections.synchronizedList(new LinkedList());
}
}
Le transport dune matrice carre de dimension N gale au nombre de sites pose deux problmes : dune
part, il faut connatre N, dautre part, pour N grand, le cot en communication devient important. Cest
pourquoi une autre approche a t utilise.
Approche par gestion dhistoires
Une autre approche consiste concatner tout message la suite des messages qui le prcde causalement.
On appelle cette technique piggybacking. La gure (3.4) montre que la rception du message m
2
sur le site
C saccompagne en fait de la rception dune copie du message m
1
qui tait lui aussi destin C et plac
dans lhistoire causale de m
2
. Dans un tel cas, cest le message m
1
qui sera dlivr, puis le message m
2
. La
rception ultrieure du message original m
1
issu du site A se traduira par loubli pur et simple de ce message
(dont une copie a dj t dlivre lapplicatif).
<(m1,C);(m,B)>, m2
A
C
B
e1 e
r
e2
r2 r1 d1 d2
<>,m1
message ignor
<m1,C>,m
Figure 3.4 Approche par piggybacking
Un avantage de cette approche est quelle apporte une certaine redondance par les copies de messages
qui sont engendres apportant ainsi un degr de tolrance vis--vis des pertes de messages. Par contre,
la surcharge des messages est importante. Lhistoire causale des nouveaux messages salourdit au fur et
mesure du calcul. Il faut pouvoir optimiser ce cot qui peut devenir prohibitif en rduisant la taille de
lhistoire emporte par un nouveau message. La gure (3.5) montre un exemple dlimination dun message
dans une histoire. Aprs la rception des messages m
2
et m
3
, le site B sait que le message m
1
a t envoy
ET dlivr. Par consquent, il peut tre dsormais ignor par B.
3.2.2 Implantation du protocole dans la cas de la diusion
Pour un protocole de diusion se pose les mmes problmes de causalit. La gure (3.6) illustre un dbut
de calcul rparti utilisant la diusion. Cependant, limplantation dun protocole de diusion ordre causal
devient plus simple lorsquon utilise lapproche par compteurs. En eet, la matrice de prcdence se simplie :
un site envoie un message vers tous les autres sites systmatiquement. Par consquent, dans cette matrice,
liminer (m1,C)
A
C
B
<>,m1
<(m1,C)>,m2
<(m1,C),m3
<(m2,B);(m3,B)>,m4
Figure 3.5 Optimisation des histoires
<(1,1,1),m>
Vecteur local
Dfaut de
causalit
(a,b,c)
A
C
B
(1,0,0)
(1,1,0)
(0,0,0)
(1,0,0)
<(1,1,0),m>
Figure 3.6 Diusion et causalit
on a j : MP[i, j] = k. Il sut donc dun vecteur V P[N] tel que V P[i] indique le nombre de messages
envoy par i vers tout site.
Le contrle de lordonnancement des messages reus sappuie cette fois-ci sur la prcondition suivante
pour un message < V P, m > reu par le site s :
dune part, ce message issu du site V P.orig doit bien tre le prochain message dlivrer :
with Protocole@s :: cpt[V P.orig] = Dernier[MP.orig] + 1
dautre part, ce message ne doit pas prcder des messages dont la diusion le prcde causalement,
cest--dire :
with Protocole@s :: i ,= s :: V P.cpt[i] Dernier[i]
La gure (3.6) montre que les message m et m
seront retards puisque les vecteurs associs ces messages

ne satisfont pas la prcondition attendue.
3.3 Tolrance aux fautes : modle dexcution ISIS, HORUS
Remarque prliminaire : Ce cours est inspir de dirents articles de Kenneth Birman, prin-
cipalement les deux articles dans les Communications de lACM, respectivement sur Isis [3] et
Horus [28], le livre runissant divers articles sur Isis [7] et bien videmment, le manuel dIsis [5].
La bote outils Isis est issue de travaux de lquipe de Kenneth P. Birman Cornell University, de
1983 1990. Ces mmes travaux ont dni la notion de synchronisme virtuel, sur lequel repose Isis. Isis
a ensuite t commercialis par une compagnie ultrieurement rachete par Stratus Computer, Inc. Aprs
avoir poursuivi le dveloppement de la bote outils Isis, Stratus a intgr Isis dans Orbix pour dnir un
ORB Corba tolrant aux fautes. Actuellement, Isis semble avoir disparu lintrieur du produit Radio pour
ladministration de serveurs tolrants aux fautes sous Windows NT. Paralllement, la recherche Cornell
sest poursuivie au travers du nouveau projet Horus. Ce projet, initialement une refonte dIsis, a notamment
tudi lutilisation modulaire de micro-protocoles pour construire des protocoles de communication volus.
Isis est une bote outils fournissant principalement des primitives de communication pour construire
des applications distribues tolrantes aux fautes, bases sur des groupes de processus cooprants. ce titre,
Isis fournit des primitives pour grer les groupes, dtecter et traiter les fautes, synchroniser des processus et,
bien sr, changer des messages.
3.3.1 Groupe de processus
Isis est bas sur la notion de groupe de processus avec un modle dexcution bien dni : le synchronisme
virtuel. On rencontre principalement deux types de groupes :
Les groupes anonymes : ils apparaissent quand une application publie des donnes selon des thmes,
et que dautres processus souhaitent sabonner ce thme. Pour quune telle application soit tolrante
aux fautes, les groupes anonymes doivent fournir plusieurs proprits :
Il doit tre possible denvoyer un message un groupe via une adresse, sans que le programmeur ait
besoin dexpanser lui-mme les membres du groupe.
Si lmetteur et les souscripteurs fonctionnent correctement, un message doit tre dlivr exactement
une fois. Si lmetteur sarrte, un message doit tre dlivr tous les souscripteurs ou aucun dentre
eux. Le programmeur de lapplication na pas se proccuper des messages perdus ou dupliqus.
Les messages doivent tre dlivrs aux abonns selon un ordre bien dni. Par exemple, une appli-
cation pourra ncessiter un ordonnancement causal.
Il doit tre possible un abonn dobtenir un historique du groupe : lensemble des vnements
importants (entre et sortie de membres du groupe) et des messages changs, ainsi que lordre de
ces vnements.
Les groupes explicites : un groupe est explicite quand ses membres cooprent directement. Ils savent
quils sont membres du groupe et utilisent explicitement la liste des membres. Un changement dans
la liste des membres est une information visible et utilise dans un groupe explicite. Par exemple, un
service tolrant aux fautes peut tre ralis avec un serveur primaire qui ralise le service et un ensemble
ordonn de serveurs secondaires qui prendront successivement en charge le service si le primaire sarrte.
Si tous les vnements ne sont pas vus dans le mme ordre par tous les sites, il peut arriver quaucun
primaire nexiste, ou, linverse, que plusieurs sites pensent tre le serveur primaire. On utilise aussi
un groupe explicite lorsquon souhaite parallliser un traitement sur n sites, en assurant un partage
correct du travail.
Lorsque lon souhaite utiliser des groupes de processus, trois problmes doivent tre rsolus :
support pour la communication de groupe : il faut pouvoir adresser un groupe, changer des messages
en respectant certaines proprits dordonnancement (fo, causal, total), et grer atomiquement les
dfaillances ;
connaissance de la relation dappartenance (membership) : il faut pouvoir connatre quel(s) groupe(s)
appartient un site, de quels sites est compos un groupe donn, quelle a t lvolution dun groupe. . .
synchronisation : pour obtenir un comportement correct dune application distribue, il est ncessaire
de synchroniser lordre dans lequel les actions des dirents membres dun groupe sont eectues.
Lintgration de ces trois problmes interdpendants forme la base du modle dexcution nomm synchro-
nisme virtuel. Avant de prsenter ce modle, commenons par un rapide survol des solutions traditionnelles.
3.3.2 Les solutions traditionnelles
Transfert de messages
Les systmes dexploitation fournissent gnralement les mcanismes suivants pour communiquer :
datagrammes : le seul service assur est la dtection de corruption. Hors cela, les messages peuvent
tre perdus, dupliqus ou rordonns.
appel de procdure distance : un RPC est relativement able mais en cas dchec, lmetteur ne peut
gnralement pas savoir si le rseau a perdu la requte ou perdu la rponse ou si le destinataire sest
arrt avant ou aprs avoir trait la requte.
C
P
S
Figure 3.7 Etat incohrent lors dune faute
canaux ables : il sagit du moyen de communication le plus courant. Un canal able assure la dlivrance
able des messages dans leur ordre dmission. Cependant, des dicults similaires celles du RPC
existent aussi. Considrons lexemple de la gure 3.7 : le client C est connect un serveur primaire
P et son secours S. La connexion entre C et P est rompue. Le client C et le primaire P ne peuvent
connatre ltat de lautre site (bien souvent, ils sont mme incapables de savoir si la rupture de la
connexion provient dune dfaillance du rseau ou dun arrt de lautre site). Pire, le secours S nest
pas au courant du problme, et, constatant que le primaire est toujours oprationnel, ignorera les
requtes de C.
Gestion des groupes et ordonnancement
La gestion des groupes se fait au moyen dun service dappartenance (membership service). Le rle de
ce service est dassurer la liaison entre ladresse dun groupe et la liste de ses membres. Ce service doit
videmment tre tolrant aux fautes. Lorsquun site diuse un message aux membres dun groupe, il est
ncessaire que cette liste de membres soit valide, et ne corresponde pas un tat intermdiaire du service
dappartenance (atomicit des mises jour).
La notion de temps logique compatible avec la causalit, introduite par Lamport en 1978, est fondamentale
la bonne intgration entre volution des groupes et dlivrance des messages. Lide est quun message dius
un groupe doit tre dlivr tous les membres au mme instant. En labsence dhorloges synchronises, il
est impossible dassurer cette dlivrance au mme instant physique. Par contre, il est possible dassurer que,
sur tous les sites, lordre de dlivrance est raisonnable, cest--dire compatible avec les liens de causalit.
Un observateur est alors incapable de distinguer entre une dlivrance au mme instant et une dlivrance au
bon moment.
La gure 3.8 illustre plusieurs des problmes qui peuvent survenir si le service dappartenance et le
systme de diusion nassurent pas un bon ordonnancement. Nous considrons un groupe compos de trois
sites S
1
, S
2
, S
3
. Les messages m
1
et m
2
sont mis sans lien causal par deux clients. Avec une diusion causale,
ils peuvent tre dlivrs dans des ordres dirents aux membres du groupe (par exemple sur S
1
et S
2
) ; une
telle situation est par contre interdite avec une diusion atomique
1
. Suite m
2
, le site S
1
diuse un message
m
3
lintrieur du groupe. Le schma prsente une dlivrance non causale sur S
3
: ce site reoit le message
m
3
avant le message responsable m
2
. Enn, nous supposons que le site S
3
sarrte suite une dfaillance.
Une nouvelle liste dappartenance est constitue avec seulement S
1
et S
2
. Le message m
4
est dlivr S
1
avant quil nait connaissance de larrt de S
3
, mais il est dlivr S
2
aprs la nouvelle constitution. De
manire symtrique, lorsque S
3
rejoint le groupe, le message m
5
est dlivr et trait par S
1
avant la jonction,
mais S
2
nen a pas connaissance lorsquil transmet son tat S
3
.
Tolrance aux fautes
En se basant sur les mcanismes de communication prcdemment voqus, il est possible de construire un
protocole de diusion qui tolre les arrts de site, en particulier de lmetteur. Cependant de tels protocoles
1. Dans Isis, une diusion est dite atomique si elle impose un ordre total compatible avec la causalit vis--vis des autres
diusions atomiques.
S1 S2 S3
C2 C1
m4
m5
crash
m3
m2
m1
Figure 3.8 Mauvais ordonnancements de messages
sont relativement complexes et coteux (la mthode nave conduit 5n messages, o n est la taille du groupe).
En outre, il est dicile dintgrer de manire cohrente la dlivrance dvnements comme lapparition ou la
disparition dun membre.
3.3.3 Le synchronisme virtuel
Pour rsumer, lutilisation des systmes dexploitation traditionnels soulve plusieurs problmes : le sup-
port pour les communications ables (notamment les diusions) est faible et conduit des incohrences
lors des ruptures de canaux ; lexpansion de ladresse dun groupe en sa liste de membres doit tre faite
explicitement par le programmeur ; lordonnancement des messages concurrents ou causalement lis doit tre
fait au sein mme de lapplication; la gestion cohrente des fautes est complexe et coteuse. Cest dans ce
cadre quIsis propose un ensemble de primitives de diusion et de gestion des groupes associes un modle
dexcution simpliant lcriture dapplications distribues.
Synchronisme fort
Idalement, on voudrait pouvoir dvelopper des applications dans le modle de synchronisme fort (close
synchrony), dans lequel les proprits suivantes sont garanties :
les communications sont ables ;
une diusion est considre comme un vnement atomique, i.e. de temps logique nul ;
lexpansion dune adresse de groupe en sa liste de membres est un vnement atomique qui se produit
linstant logique de la diusion;
les messages concurrents sont dlivrs tous les destinataires dans le mme ordre ;
les messages causalement lis sont dlivrs selon un ordre compatible avec cette causalit ;
le transfert de ltat dun site lors de la jonction dun nouveau site est eectu atomiquement vis--vis
de tous les autres vnements (notamment les diusions) ;
les fautes sont atomiques vis--vis des diusions, et sont ordonnes identiquement sur tous les sites.
Malheureusement, un tel synchronisme fort est, dune part, impossible raliser en prsence de fautes,
et dautre part, extrmement coteux obtenir. Il impose gnralement une excution pas pas de tous
les sites, et dsavantage donc les interactions asynchrones, dans lesquelles un site continue son excution
immdiatement aprs avoir initi une communication sans attendre la dlivrance du message. Le modle de
synchronisme virtuel est un aaiblissement du modle de synchronisme fort, o latomicit des communi-
cations est relche de manire privilgier les communications asynchrones mais o le respect dun ordre
bien dni de dlivrance est conserv.
Ordre total et ordre causal
Le synchronisme fort impose un ordre total entre tous les vnements. Cet ordre total peut tre obtenu
au moyen de la diusion atomique, nomme ABCAST dans Isis. Cependant, dans nombre de cas, lordre
causal sut. Selon lordre causal, des vnements causalement lis doivent tre dlivrs selon ce lien causal.
Par exemple, sur la gure 3.8, le message m
3
est causalement ultrieur m
2
, il doit donc tre dlivr
aprs. Par contre, il ny a pas de lien causal entre m
1
et m
2
qui peuvent donc tre dlivrs dans des ordres
dirents selon les sites. La diusion causale, ou CBCAST, assure un tel ordre causal. Lintrt principal
de la diusion causale est son faible cot, tant dun point de vue retard de dlivrance que dun point de
vue surcot de communication : un message dune diusion atomique ne peut tre dlivr que quand le
site est sr que tous les ABCAST prcdents (vis--vis de lordre total) sont termins ; pour une diusion
causale, il sut de sassurer que les messages causalement prcdents ont t dlivrs. Cela signie en outre
que, si lmetteur est membre du groupe auquel il diuse, il peut se dlivrer immdiatement le message.
Limplantation performante du CBCAST disis se base sur des vecteurs dhorloges, ce qui entrane un faible
surcot dans les messages.
Les changements dans les groupes (dus un retrait volontaire ou une dfaillance pour les rductions)
doivent par contre tre ordonns totalement vis--vis des dlivrances, pour viter des incohrences similaires
celles illustres par les messages m
4
et m
5
de la gure 3.8.
3.3.4 La bote outils Isis
Hypothses sur lenvironnement
La bote outil Isis fait les hypothses suivantes sur son environnement : le rseau est constitu de rseaux
locaux (LAN) interconnects par des rseaux grande distance (WAN), beaucoup plus lents. Les horloges
des dirents sites ne sont pas synchronises. Sur un LAN, les messages peuvent tre perdus, dupliqus ou
r-ordonns ; si une partition se produit, une partition majoritaire est dtermine et sera la seule pouvoir
continuer travailler. Les seules fautes de sites sont des arrts, sans action ou mission illgale (crash
failure). Du fait de la rgle de la majorit pour les partitions, il est dconseill dutiliser des groupes rpartis
sur plusieurs rseaux locaux, mais plutt dutiliser un paquetage spcial de communication pour les rseaux
grande distance.
Styles de groupes
Isis est optimis pour traiter de manire ecace quatre styles dutilisation des groupes (gure 3.9), sans
quil soit pour autant ncessaire de se conformer lune de ces structures :
groupe de diffusion groupe hirarchique Groupe clientserveur Groupe de pairs
Figure 3.9 Styles de groupes
groupe de pairs (peer group) : tous les processus cooprent troitement, par exemple pour rpliquer
des donnes. Lapplication utilise explicitement lappartenance et un ordre parmi les membres.
groupe client-serveur : un client communique avec un groupe qui remplit un service. Le client nest pas
membre du groupe, mais, pour des raisons de performance, il peut senregistrer en tant que client.
groupe de diusion : cest un groupe client-serveur o les clients sont enregistrs et o les serveurs
diusent tous les clients sans que ceux-ci ne dposent de requtes.
groupes hirarchiques : pour viter quun groupe ne soit composs de trop de membres, il peut tre utile
de construire une structure hirarchique arborescente pour structurer ces membres. Une application
contacte initialement le groupe racine puis ne communique plus quavec un des sous-groupes. La plupart
des communications se limitent lintrieur dun sous-groupe, et ne concernent que rarement lensemble
des sous-groupes.
3.3.5 Programmer avec Isis
La programmation avec Isis est un programmation de type vnementiel, o le dveloppeur dclare des
points dentre pour grer la rception dun message. Quand un message est reu, Isis cre une nouvelle tche
pour excuter le code associ au point dentre.
Structure de lapplication
Une application suit les tapes suivantes :
1. initialise les librairies Isis et se connecte Isis ;
2. dclare les tches et les points dentres ;
3. dclare les gestionnaires de signaux et dentres-sorties ;
4. initialise ltat de lapplication ;
5. se joint des groupes et/ou devient client ;
6. indique Isis quelle est prte recevoir les messages.
Initialisation et connexion Isis
Trois mthodes dinitialisation sont disponibles :
connexion lIsis local :
int isis_init (int client_port) ;
Se connecte Isis via la port tcp client_port. Il sagit du deuxime port list dans le chier sites
(gnralement 1602).
Une version longue permet de spcier de nombreux drapeaux, notamment ISIS_AUTORESTART (la
bibliothque tente de dmarrer Isis sil ne tourne pas actuellement sur la machine) et ISIS_TRACE (Isis
achera tous les messages reus ou envoys).
connexion un Isis distant :
int isis_remote (char *mother_host, int flags) ;
Tente de se connecter lIsis tournant sur mother_host
connexion libre : les deux prcdentes formes dinitialisation sont remplaces par une unique routine :
int isis_remote_init (char *hostlist, int lport, int rport, int flags) ;
hostlist est une chane de caractres contenant la liste des machines, spares par des virgules, o
tenter de se connecter. Utiliser (char *)0 pour ne tenter que la machine locale. lport est le port local
de connexion une machine locale (port tcp, 1602). rport est le port utiliser pour trouver Isis sur
une machine distante (port bcast, 1603).
Dclaration des tches et point dentre
Dclaration des tches Cette partie nest pas obligatoire, mais est trs utile pour que les enregistrements
ou les traces contiennent des noms symboliques, plutt que des numros arbitraires allous par Isis.
int isis_task (void (*routine) (void *arg), char *taskname) ;
Une tche est une procdure prenant un paramtre de type pointeur.
Dclaration des points dentres Cette partie dnit les points dentres o seront reus les messages.
Elle est donc obligatoire, si jamais lapplication espre recevoir des messages.
int isis_entry (int entry, void (*handler) (message *mp), char *name) ;
entry est le numro de lentre. Il doit tre strictement positif, et identie lentre (voir 3.3.5).
handler est la routine appeler quand un message est reu. La routine sera appele avec le message
reu en paramtre. Pour excuter cette routine, Isis crera une nouvelle tche qui sera dtruite la n du
traitement.
name permet Isis dtre plus bavard dans ses explications.
Initialisation de lapplication et entre dans Isis
Ceci se fait par :
void isis_mainloop (void (*task) (void *arg), void *arg) ;
Isis cre alors une tche pour excuter task (avec largument pass en paramtre). Cette tche a pour but
dinitialiser compltement lapplication, de se joindre des groupes ou de devenir client dautres groupes.
Quand lapplication a ni de sinitialiser (ie sest connecte aux groupes souhaits, . . .), il est ncessaire
dindiquer Isis que lapplication est maintenant prte recevoir des messages. Ceci est fait au moyen de :
void isis_start_done (void) ;
Tant que lapplication na pas appele cette routine, elle ne peut pas mettre ou recevoir de messages, et
aucune tche ne peut tre cre implicitement. Si la tche principale cre par isis_mainloop se termine
sans avoir appele isis_start_done, Isis le fait automatiquement.
Groupes et clients
Jonction des groupes La routine de jonction un groupe est :
address *pg_join (char *gname, [int key, [arg,]...]..., 0) ;
gname est le nom du groupe auquel lapplication essaie de se connecter. Un nom de groupe a une syntaxe
de nom de chier Unix, ie /sys/databases/CCP. Par dfaut, le working group est /. Contrairement
Unix, les groupes intermdiaires nont pas besoin dexister. En cas de succs, pg_join renvoie une adresse
qui sera utilise pour envoyer des messages.
Pour tester lchec, il convient dutiliser la routine :
int addr_isnull (address *adr) ;
qui renvoie vrai si ladresse est nulle (invalide).
Enn, pg_join accepte de nombreux paramtres optionnels. Les principaux sont :
PG_DONTCREATE (pas de paramtre) : ne cre pas le groupe sil est inexistant (par dfaut le groupe est
cr).
PG_LOGGED (4 paramtres non dtaills) : pour enregistrer tout ce qui se passe dans le groupe.
PG_INIT, void (*routine) (address *) : la routine est appele quand un groupe est cr et quaucun
enregistrement ne permet de reconstruire un tat.
PG_MONITOR, void (*routine) (groupview *, void *arg), void *arg : la routine est appele
chaque changement dans la composition du groupe (jonction ou retrait de membres). Noter que la
routine sera aussi appele pour cette jonction.
PG_XFER, int domain, void (*send) (int position, address *group, address *whojoined),
void (*receive) (int position, message *msg) : permet linitialisation de ltat dun nouveau
membre par copie de ltat dun autre membre. Dans notre cas, domain est gnralement spci 0.
Voir 3.3.5 pour les dtails.
Client Un client obtient ladresse dun groupe avec :
address *pg_lookup (char *groupname) ;
Comme prcdemment, on utilise addr_isnull pour vrier si le groupe existe. Un client peut utiliser
ladresse quil a obtenue par pg_lookup pour envoyer une requte et obtenir la rponse.
Par ailleurs, un client rgulier dun groupe peut avoir intrt se dclarer comme tel. Outre le fait quil
existe des moyens pour obtenir la liste des clients dclars dun groupe, cela permettra aussi au client de
dtecter des vnements survenant dans le groupe. Un processus se dclare client avec :
int pg_client (address *groupaddr, char *credentials) ;
Le paramtre credentials sert lauthentication, et peut tre NULL si le groupe ne fait pas dauthen-
tication.
Surveiller ltat dun groupe Il est possible de surveiller ltat dun groupe, de faon encore plus riche
que le PG_MONITOR de pg_join. En outre, il nest pas ncessaire dtre membre du groupe. Nous ne prsentons
ici que la routine qui dtecte la disparition dun groupe. Il sagit de :
int pg_detect_failure (address *group, int (*routine) (address *, int what, void
*arg), void *arg) ;
Quand le groupe spci disparat, une tche est cre pour excuter le paramtre procdure de
pg_detect_failure avec routine(group, W_FAIL, arg) ;. Une telle surveillance est trs coteuse sauf
dans deux cas particuliers : soit le processus est membre du groupe quil surveille, soit il est client et il sest
dclar comme tel avec pg_client.
Il existe deux autres routines pour surveiller un groupe ou un processus, qui sont pg_monitor et pg_watch.
Ces routines ne marchent que pour un membre du groupe ou un client dclar. Pour un membre du groupe,
pg_monitor est identique largument PG_MONITOR de pg_join.
Transfert de ltat Lorsquun nouveau membre est introduit dans un groupe, il peut tre ncessaire
de lui donner ltat courant du groupe. Pour cela, PG_XFER est fourni. Isis slectionne un membre actif du
groupe, et appelle la routine send de ce membre. Si tout va bien, ce membre enverra (au moyen de xfer_out,
voir 3.3.5) ltat au nouveau membre. La routine receive du nouveau membre est appele pour chacun des
messages envoys, et il rcuprera ltat au moyen de msg_get (voir 3.3.5).
Comme le transfert dun tat peut ncessiter plusieurs messages, le paramtre position de send et
receive permet de dterminer o en est le transfert. Noter enn que Isis soccupe de tout vis--vis des
ventuelles dfaillances du membre retenu pour transfrer ltat (un autre membre sera choisi et Isis lui
fournira, au moyen du paramtre position, lendroit o le prcdent stait arrt).
La routine void xfer_refuse peut tre utilise par un membre du groupe pour signier Isis que ce
membre nest pas apte transfrer ltat (et Isis en trouvera alors un autre).
Autres routines sur les groupes Quelques routines utiles :
int pg_leave (address *) ; pour quitter un groupe (que le processus soit membre ou client dclar).
int pg_delete (address *) ; pour dtruire un groupe.
int pg_rank (address *group, address *paddr) ; renvoie le rang du processus paddr dans le groupe
spci. Tout processus possde un rang unique dans le groupe (commenant 0), qui est fonction du moment
o pg_join a t appel. pg_rank retourne 1 si paddr nest pas membre du groupe. Ce rang est souvent
utilis lorsquil faut lire un coordinateur ou un matre.
address my_address ; est ladresse du processus courant. Elle peut tre utilise avec pg_rank pour
obtenir son propre rang dans un groupe.
Diusions et messages
Nous ne prsentons ici que les formes les plus simples de lenvoi de messages. Il en existe de nombreuses
variantes pour les situations les plus particulires. Toutes les routines dmission et de rception de messages
utilisent des formats la printf/scanf, plus de nombreuses extensions pour manipuler les tableaux ou les
entits dIsis (address, message,. . .).
mission de message
Diusion sans rponse : Pour envoyer un message sans rponse, utiliser :
int bcast (address *addr, int entry, char *outformat, [arg,]..., 0) ;
o addr est ladresse du groupe ou du processus concern, et entry est lentre sur laquelle dlivrer le
message. bcast peut tre fbcast, cbcast, abcast ou gbcast, selon que lon souhaite une diusion FIFO,
causale, atomique ou de groupe (la diusion de groupe est une diusion imposant un ordre total vis--vis de
toutes les diusions. En ce sens, elle est similaire un vnement de changement dans la composition dun
groupe).
Dans le cas o aucune rponse nest attendue, il sagit dun envoi asynchrone (lapplication continue
immdiatement aprs le bcast).
Diusion avec rponse : Pour envoyer un message avec rponses attendues, utiliser :
int bcast (address *addr, int entry, char *outformat, [arg,]..., int nwant, char
*replyformat [, replyarg] ...) ;
nwant indique le nombre de rponses attendues. Ce peut tre un entier (notamment 1) ou les constantes
MAJORITY ou ALL. Si nwant nest pas nul, il sagit dun appel bloquant, jusqu rception des nwant messages.
Si lapplication est membre du groupe vers lequel elle diuse, elle recevra aussi ce message.
Transfert de ltat : Le transfert de ltat se fait au moyen de :
int xfer_out (int position, char *format [, arg]...) ;
Rception dun message
Un message rcupr comme paramtre dun point dentre (ou de la routine de rception de ltat) est
analys au moyen de :
int msg_get (message *msg, char *format [, arg]...) ;
Rponse un message
Pour rpondre un message, utiliser :
int reply (message *m, char *outformat [, arg]...) ;
m est le message auquel le processus rpond.
Pour viter de rpondre (alors quune rponse tait attendue), on utilise :
int nullreply (message *m) ; Ceci est dirent de reply (m, "") ; qui indique une rponse vide.
Enn, il est possible de rpondre avec
int abortreply (message *m) ;
Dans ce cas, la diusion du client se termine immdiatement en retournant 1, et isis_errno contient
IE_ABORT.
Vrication de la cohrence questions/rponses
Quand un processus diuse un message avec ALL rponses, comment sait-il quil a bien eu autant de
rponses que de messages envoys ? Deux variables peuvent alors servir :
int isis_nsent ;
int isis_nreplies ;
La variable isis_nsent contient le nombre de messages envoys par le dernier bcast. La variable
isis_nreplies contient le nombre de rponses rcupres. Les non-rponses gnres par nullreply ne
sont pas comptabilises dans isis_nreplies.
Pour tre prcis, une diusion se termine quand lune des trois conditions suivantes devient vraie :
linitiateur de la diusion a reu le nombre de messages dsir ;
chacun des processus qui a reu le message a renvoy une rponse (par reply), ou a renvoy une
non-rponse (par nullreply), ou sest arrt ;
un des processus a renvoy un abort (par abortreply).
Les tches
Les tches dans Isis sont non-premptives sauf si Isis a t construit avec une librairie de tches premp-
tives (Sun lwp ou Mach), et que lapplication le demande explicitement. Chaque tche possde sa propre
pile.
Des tches sont cres implicitement pour appeler les points dentre de messages ou les handlers de
signaux et dentres-sorties.
Il est par ailleurs possible de crer explicitement une tche avec :
int t_fork (void (*routine)(void *arg), void *arg) ;
int t_fork_msg (void (*routine) (message *arg), message *arg) ;
La routine est alors appele avec le deuxime paramtre de t_fork. Quand la routine se termine, la tche
est termine.
Si une tche bloque, une autre tche active peut tre excute, et la tche bloque sera ractive quand
la condition de bloquage disparatra. Si aucune tche nest active, Isis attend quune tche devienne active.
Une tche bloque sur certaines oprations telles lenvoi de messages avec rponses, ou t_wait.
Synchronisation par jeton
partir de la diusion atomique, il est ais de construire un jeton dexclusion mutuelle dans un groupe. La
gestion de larrt du processus possdant le jeton est par contre un peu plus dlicate. Isis fournit directement
des routines de manipulations de jeton.
Obtention du jeton int t_request (address *gaddr, char *tokenname, int pass_on_fail) ;
Un jeton est identi par son nom (une chane de caractres). Lors de t_request, si le jeton nexiste
pas, il est cr. Le paramtre pass_on_fail est TRUE si le jeton doit tre transmis quand le processus le
possdant sarrte sans lavoir transmis. Sil vaut FALSE, le jeton nest pas transmis automatiquement en cas
de panne.
Passage du jeton int t_pass (address *gaddr, char *name) ;
Normalement, seul le processus possdant le jeton peut le passer. Cependant, si t_request avait t
appel avec pass_on_fail FALSE, nimporte quel processus peut utiliser t_pass en cas de dfaillance du
processus possdant. Il obtient alors le jeton.
Possesseur du jeton address *t_holder (address *gaddr, char *name) ;
permet dobtenir ladresse du possesseur du jeton.
3.3.6 Horus
Horus prsente un modle de communication de groupes extrmement exible. Pour cela, les protocoles
volus sont obtenus en empilant des micro-protocoles rendant des services bien spciques. Bas sur lexp-
rience dIsis, Horus permet dobtenir une implantation trs performante du modle de synchronisme virtuel,
mais il ninterdit pas dautres modles plus adapts une application donne, par exemple dans le domaine
du multimdia ou du temps rel. Horus fournit une architecture o le protocole supportant un groupe peut
tre modi dynamiquement lexcution, en fonction des besoins de lapplication et des volutions de
lenvironnement.
Voici quelques-uns des modules fournis par Horus :
COM : mission de message vers une liste de destinataires et rception dun message, en utilisant des
protocoles de plus bas niveau tel UDP ou ATM;
NAK : assure lordre FIFO et la abilit, au moyen daccuss ngatifs de rception ;
FRAG : fragmentation/rassamblage de messages ;
MBRSHIP : assure, au moyen dun algorithme de consensus, la correspondance entre nom de groupe et
liste des membres accessibles ;
TOTAL : assure la dlivrance selon un ordre total ;
CRYPT : chirage/dchirage ;
MERGE : transfert dtat lors de lintgration dun nouveau membre ou lors de la rsolution dune parti-
tion.
Par exemple, le protocole TOTAL :MBRSHIP :FRAG :NAK :COM :ATM correspond une implantation
de la diusion atomique sur ATM. MERGE :MBRSHIP :CRYPT :FRAG :NAK :COM :UDP correspond
la diusion causale avec dchirage des messages et transfert de ltat.
Pour pouvoir empiler exiblement les modules, les interfaces (montantes et descendantes) sont standar-
dises. Par exemple, il existe un appel descendant pour mettre un message, et un appel montant pour
recevoir un message. Ces interfaces sont dnies par le Horus Common Protocol Interface. Ces interfaces se
dcomposent en deux catgories : celles qui traitent lchange de messages, et celles qui concernent la gestion
des groupes.
Ensemble est une nouvelle tape dans le projet Horus. Ensemble est une implantation des protocoles
dHorus en Caml qui sattache spciquement la manipulation des micro-protocoles pour recongurer
dynamiquement des macro-protocoles. La structure en pile permet de simplier le problme de la recon-
guration : la dcision est la charge du niveau suprieur (souvent lapplication) et la ralisation est la
charge de la couche infrieure. Ces travaux ont aussi permis de montrer quil est possible de compiler une
pile de protocoles pour le cas gnral de manire obtenir une performance accrue en vitant le surcot d
un nombre trop lev de couches. Par exemple, sur un rseau local, les messages sont rarement perdus ou
dlivrs dans le dsordre et les changements dans la composition des groupes sont relativement peu frquents.
On souhaite donc pouvoir court-circuiter les couches responsables de ces traitements.
3.3.7 Bibliographie
Compte tenu de la dure du projet et de son ampleur, les publications sur Isis et Horus sont trs nom-
breuses. Pour dbuter, larticle [3] est le premier article lire, qui, plus quIsis lui-mme, prsente les concepts
de groupe et de synchronisme virtuel tel quils ont t utiliss dans Isis. Pour continuer, le livre [7] runit
de nombreux papiers sur Isis, sur les concepts (reprenant larticle prcdent et dtaillant le synchronisme
virtuel ainsi que les notions de causalit), limplantation des dirents protocoles et de la gestion des groupes
dans Isis, et direntes applications dveloppes au-dessus dIsis. Le problme des rseaux grande dis-
tance (WAN) est abord dans [16], ce problme dicile tant malheureusement trop souvent ignor. Sur la
tolrance aux fautes dans Isis, [6], [29] et [2] prsentent clairement le problme et les choix eectus.
La littrature sur Horus est heureusement encore assez limite. On trouve un premier papier dans [7],
mais larticle [28] est la meilleure introduction Horus, complter ensuite par [26]. Ensemble est prsent
dans [27]. Enn, de manire plus gnrale, je ne peux que conseiller la lecture enrichissante du livre [4].
Chapitre 4
Synchronisation et supervision
4.1 Lexclusion mutuelle
Le problme de lexclusion mutuelle doit tre revisit dans le contexte dune architecture rpartie. En
fait, la rpartition apporte de nouvelles stratgies dimplantation.
On peut distinguer plusieurs classes dalgorithmes :
les algorithmes fonds sur lunicit dun jeton circulant matrialisant le privilge daccs en exclusion
mutuelle ;
les algorithmes fonds sur la notion de permissions darbitres ;
les algorithmes fonds sur la notion de permissions individuelles.
Les variantes (nombreuses) de ces trois classes dalgorithmes reposent en particulier sur des hypothses
direntes concernant la abilit des communications. Pour les algorithmes base de permissions, le d est
de minimiser le nombre de permissions obtenir pour avoir le droit dentrer en exclusion mutuelle.
4.1.1 Rappel de la spcication du problme
On considre N processus (ou sites) P
i
dont le graphe de transitions dtats peut tre abstrait vis--vis du
problme par la gure (4.1.1). Un processus cycle sur les trois tats successifs : hors, demandeur, exclusion.
Les proprits vrier par les N processus sont les suivantes :
1. Sret 1 : exclusion mutuelle
i, j :: P
i
.exclusion P
j
.exclusion i = j
2. Sret 2 : maintien des demandes
i, j :: P
i
.demandeur unless P
i
.exclusion
3. Vivacit : toute requte est nalement satisfaite
i :: P
i
.demandeur P
i
.exclusion
demandeur
exclusion
hors
Figure 4.1 Comportement dun processus
59
La proprit de vivacit ne peut bien entendu tre vrie que si tout processus en exclusion nit par
sortir, cest--dire si la proprit suivante est vrie :
i :: P
i
.exclusion P
i
.hors
4.1.2 Lutilisation dun jeton circulant
Pour obtenir les proprits prcdentes, une solution simple consiste faire circuler un message jeton
entre les sites. Lunicit du jeton garantit que, seul, le processus qui possde le jeton peut tre en exclusion.
Deux problmes se posent cependant avec cette approche :
la circulation du jeton entre les processus consomme des ressources mme lorsque les processus ne sont
pas demandeurs. Pour palier ce dfaut, des algorithmes ont t proposs pour bloquer le jeton sur un
site sil nexiste pas de requte en attente. Un algorithme optimal vis--vis de la circulation du jeton
consiste guider celui-ci de site en site demandeurs (Algorithme de Nami Trehel [20])
cette approche repose sur la abilit de la communication. En eet, la perte du message jeton empche
tout processus dentrer en exclusion. Cest pourquoi des algorithmes permettant de rengendrer un
jeton ont t proposs. La dicult principale tient alors la dtection de la perte du jeton (pas de
fausse dtection) et lunicit du jeton engendr (pas de double), ce qui soulve un problme dlection
(un seul processus lu doit engendr un seul jeton).
4.1.3 Les algorithmes base de permission
Ces algorithmes reposent sur un principe commun : tout processus qui veut entrer en exclusion mutuelle
doit obtenir un certains nombre de permissions de la part des autres processus. Pour tout processus P
i
, il
faut donc xer un ensemble D
i
de processus interroger.
Pour les algorithmes permissions darbitres, chaque processus possde un droit unique quil peut prter
(distribuer) tour de rle aux processus qui le lui demandent. Autrement dit, il possde une ressource critique
(la permission) quil peut accorder, allouer un seul processus demandeur. Une fois prt, le processus
prteur doit attendre que le processus emprunteur lui rende son droit darbitrage (sa ressource critique).
Un condition ncessaire pour garantir lexclusion est alors :
i, j :: i ,= j, D
j
D
i
,=
Autrement dit, P
i
et P
j
sadressent au moins un processus commun qui pourra servir darbitre.
Pour les algorithmes permissions individuelles, chaque processus autorise individuellement les processus
qui lui demandent entrer en exclusion. Il peut donc donner son accord plusieurs processus (tant que lui-
mme ne souhaite pas entrer en exclusion par exemple). Un condition ncessaire pour garantir lexclusion
est alors :
i, j :: i ,= j, i D
j
j D
i
Autrement dit, une interaction aura lieu entre P
i
et P
j
si les deux processus deviennent demandeurs. Sans
cette interaction, il ne serait pas possible dempcher 2 processus dentrer en exclusion.
Exemple dalgorithme permissions darbitre
Une stratgie simple consiste utiliser un UNIQUE arbitre. Tout processus qui demande entrer en
exclusion mutuelle demande un serveur arbitre via par exemple un appel procdural distance. Ceci
revient opter pour des ensembles D
i
tous identiques et rduits au processus arbitre :
i :: D
i
= a
Cette solution est rpartie au sens du contrle ( selon le classique schma client-serveur) mais totalement
centralise du point de vue gestion de laccs en exclusion mutuelle.
Une possibilit plus rpartie est de dnir des ensembles multi-arbitres. titre dexemple, le tableau
suivant dcrit le choix fait pour 5 processus sadressant toujours 2 arbitres :
i prend pour arbitre : 1 2 3 4 5
1
2
3
4
5
Les processus 2, 3 et 4 servent darbitres. Si les processus 1 ou 5 sarrtent alors quils ne sont pas en exclusion,
le systme global peut continuer. De mme, si le processus 4 sarrte sans tre possesseur de la permission
de 2, les processus 1 et 5 peuvent encore utiliser leurs arbitres. On obtient donc une certaine tolrance aux
fautes de la solution.
Cependant, certains processus ont un rle darbitre qui les particularise. Il est possible dobtenir une
solution plus symtrique en cherchant obtenir des ensembles D
i
vriant les deux proprits suivantes :
1. Les ensembles D
i
sont de mme cardinalit i : Card(D
i
) = K, celle-ci tant la plus petite possible.
Autrement dit, tous les sites ont le mme nombre minimal de permissions obtenir ;
2. Le nombre densembles D
i
auxquels appartient un site est identique pour tous les sites :
i : + j :: i D
j
: 1) = P
Autrement dit, aucun site ne joue un rle prpondrant par rapport aux autres.
En fait, le nombre total doccurrences de sites dans les n ensembles D
i
est donc n K qui doit aussi tre
gal au nombre n P. Par consquent, K = P sous ces conditions. On ne peut cependant pas trouver une
valeur de K minimale pour toute valeur de n.
On peut obtenir une solution simple en utilisant une matrice contenant les numros de site comme
lments. Pour 9 sites, on obtient par exemple :
1 2 3
4 5 6
7 8 9
Un site demande alors aux sites situs sur la mme ligne et sur la mme colonne. Par exemple, le site 1
aura pour ensemble D
1
= 2, 3, 4, 7. Pour un nombre de sites qui nest pas un carr, certains lments de
la matrice restent vides.
En ce qui concerne la vivacit, tout algorithme arbitrage multiple pose le problme classique des
systmes ressources critiques. Les processus, dans leur rle darbitre, gre une permission qui est une
ressource critique. Obtenir plusieurs permissions revient donc obtenir lallocation (le droit daccs)
plusieurs ressources critiques. Un tel systme risque donc linterblocage. La solution pour viter linterblocage
est dintroduire un ordre dans les requtes par un mcanisme destampillage.
Exemple dalgorithme permissions individuelles
Avec des permissions individuelles, une faon de garantir simplement la proprit dexclusion est de forcer
un processus demandeur sadresser tous les autres. Autrement dit :
i : 0 i < N :: D
i
= 0, 1, . . . , N 1 i
Supposons que la seule condition pour dlivrer une permission un processus demandeur soit le fait que
le processus interrog soit hors exclusion (ni demandeur, ni en exclusion). Alors, une attribution dsordonne
des permissions peut conduire une situation dinterbocage : par exemple, deux processus demandeurs ne
peuvent obtenir la permission (rciproque) de lautre.
Comme pour les arbitres, il faut donc mettre en uvre une stratgie pour viter ce risque dinterblocage.
Les permissions ne peuvent tre attribues sans respecter un ordonnancement global des requtes. Lalgo-
rithme de Ricart et Agrawala adopte une telle approche en datant les requtes dentre en exclusion laide
du mcanisme dhorloge de Lamport. La requte la plus ancienne est alors prioritaire.
C
A
B
Figure 4.2 Un exemple de calcul diusant
Fin dtape
actif
passif
Recevoir(m)
Figure 4.3 Comportement dun processus
4.2 Le problme de la terminaison dun calcul rparti
La terminaison dun calcul dans un contexte rparti est un problme dlicat et beaucoup plus complexe
quen milieu centralis. Il a t particulirement tudi sur un modle de calcul gnrique appel calcul
diusant. Ce modle a donn lieu de nombreux algorithmes depuis Dijkstra [11] jusqu Mattern [17, 18].
Il a t notamment mis en vidence ltroite relation entre ce problme et ceux du ramasse-miettes [31] ou
de la dtection dun interblocage dans un contexte dexcution rpartie [23].
4.2.1 La notion de calcul diusant
On considre un ensemble de processus ou sites P
i
: 0 i < N pouvant communiquer par messages de
faon asynchrone. Le rseau de communication est suppos able mais aucune hypothse dordonnancement
des messages nest ncessaire.
Un processus initial, P
0
par exemple, dbute le calcul en envoyant un ou plusieurs messages vers dautres
processus. Puis tous les processus, y compris ce processus initial, adoptent le comportement suivant :
loop
/* un pas de calcul */
recevoir(m) ;
traiter m;
envoyer 0 N 1 messages ;
end loop
Le chronogramme de la gure (4.2) montre un exemple de calcul diusant. Un processus commute ainsi
de ltat passif en attente de message ltat actif pour excuter un pas de calcul qui se terminera par lenvoi
ventuel dun ou plusieurs messages.
4.2.2 Spcication du problme
On considre N processus (ou sites) P
i
dont le graphe de transitions dtats peut tre abstrait vis--vis du
problme par la gure (4.2.2). Un processus cycle sur les deux tats successifs : passif, actif. Initialement,
tous les processus sont passifs sauf un.
La dtection de la terminaison repose sur un prdicat stable : tous les processus sont passifs et il nexiste
plus de messages en transit. Si un tel tat global est atteint, le calcul est termin puisquaucun message ne
pourra plus ractiver au moins un processus. Il sagit dun tat stable que lon peut spcier sous la forme
0
A
B
C
1/2 1/2
1/2
1/2
1/2
1/4
1/4
1/4
Superviseur
1/2 3/4
1/2
1/4 1/4
1
1
Figure 4.4 Dtection par la mthode du crdit
dune proprit de sret :
stable i :: P
i
.passif EnTransit = (4.1)
La variable EnTransit est une variable abstraite ayant pour valeur lensemble des messages en transit tout
instant.
Lobjectif est de dnir un algorithme qui permette de dtecter que ltat stable de terminaison est atteint.
On suppose donc un (N + 1)-ime processus superviseur (appel aussi collecteur) qui peut interroger les
processus pour essayer de dterminer si la terminaison est eective.
1
On suppose que le processus superviseur gre une variable boolenne Term. La correction de lalgorithme
excut par ce processus repose alors sur les proprits suivantes :
Sret : pas de fausse dtection :
Term ( i :: P
i
.passif EnTransit = )
Vivacit : si le calcul se termine, la terminaison sera nalement dtecte :
( i :: P
i
.passif EnTransit = ) Term
4.2.3 Algorithme fond sur la gestion dun crdit (Mattern)
Une ide simple consiste considrer que le processus initiateur possde un crdit quil partagera
entre les messages initiaux quil enverra pour dmarrer le calcul diusant. titre dexemple, on peut choisir
un crdit gal 1 et si le processus initiateur envoie 3 messages, il transmettra un crdit gal 1/3
chacun des processus cibles. Les processus participants (y compris le processus initiateur) adopteront alors
le comportement suivant :
si le processus rcepteur envoie un ou plusieurs messages en n dtape de calcul, il partagera, comme
le processus initiateur, le crdit quil a reu entre les processus cibles de ses messages ;
si le processus rcepteur ne propage pas le calcul, celui-ci enverra le crdit quil avait reu vers le
processus superviseur.
Le processus superviseur reoit donc au cours du droulement du calcul diusant, les parcelles du crdit
initial transmis par les processus ne propageant pas le calcul. Lorsque la somme de ces crdits atteint le
crdit initial (ici 1), le calcul est termin. La gure 4.4 montre un exemple avec un crdit initial de valeur 1.
Pour cet algorithme, le prdicat de dtection de la terminaison est donc
Term
c
i
= C
avec C pour valeur du crdit initial et c
i
pour les valeurs de crdits reus par le superviseur.
La dicult de mise en uvre de cet algorithme tient au partage du crdit. Des erreurs darrondi doivent
absolument tre vites.
1. On peut aussi supposer que cest lun des processus qui interroge les autres sans remettre en question le principe des
algorithmes prsents.
m
A
B
C
(2,2)
(4,3)
(2,3)
Passage de la vague i
M
(mis,reus)
Figure 4.5 Un exemple de fausse dtection
4.2.4 Algorithme fond sur la gestion de compteurs (Mattern)
Une hypothse simplicatrice peut tre faite sur les priodes dactivit des sites : on peut supposer que
tout pas de calcul est ininterruptible vis--vis de larrive dun nouveau message. Sur un chronogramme,
on peut alors modliser un pas de calcul par un point celui-ci ayant un caractre atomique. On vite ainsi
la gestion explicite dun tat actif/passif des sites. Pour dtecter la terminaison dun calcul diusant sous
cette hypothse, une ide simple est de compter les vnements dmission et de rception de messages
globalement. Si lon suppose connu un instant t o aucun pas de calcul nest excut, E(t) le nombre
dvnements dmissions et R(t) le nombre dvnements de rceptions, alors la terminaison du calcul est
atteinte ssi E(t) = R(t) puisquil ny a plus de messages en transit. On a bien :
E(t) = R(t) EnTransit =
Nanmoins, la connaissance des compteurs E et R nest pas immdiate. En eet, pour connatre ces
derniers, on ne peut que se contenter dune approximation en allant interroger chaque site. On peut supposer
que chaque site s gre deux compteurs E
s
et R
s
et, que par interrogation, un site observateur peut valuer
dune part

s
E
s
et dautre part

s
R
s
. Le mcanisme de vague peut tre utilis pour cette collecte. On
note E
i
la somme des missions value par la collecte de la i-me vague et R
i
la somme des rceptions.
E
i
=
s=N1
s=0
E
i
s
, R
i
=
s=N1
s=0
R
i
s
Le problme de la dtection de la terminaison serait alors rsolu si lon avait le prdicat suivant vri
aprs une i-me vague :
E
i
= R
i
t f
i
: E(t) = R(t)
o f
i
est linstant de n de la i-me vague.
Malheureusement, la gure (4.5) montre que ce nest pas le cas. Le passage de la vague aux instants
prciss sur le chronogramme conduit une fausse dtection. Lgalit entre les deux sommes est vraie, mais
le calcul nest pas termin car un message en transit existe encore (M). Lanomalie tient la prise en compte
dun vnement de rception dun message (m) dont lvnement dmission na pas t comptabilis. Nous
reviendrons sur ce genre danomalie avec la notion de coupure cohrente.
Par consquent, il faut trouver un autre prdicat en partie gauche de limplication. En fait, il sut
dutiliser deux vagues successives. Un prdicat susant est alors :
Term E
i+1
= R
i
En eet, si le nombre de messages mis collect par la vague i + 1 est gal au nombre de messages reus
collect par la vague prcdente i, alors il existe un instant t tel que E(t) = R(t). Cet instant t est au plus
tard linstant de n de la vague i. Autrement dit, le calcul tait termin avant le dbut de la vague i + 1.
di
A
B
C
ime vague
(i+1)me vague
di+1 fi+1 fi
Figure 4.6 Vagues squentielles
La preuve de la validit du prdicat peut sappuyer sur les instants de dbut d
i
, d
i+1
et de n f
i
, f
i+1
des vagues correspondantes, ces instants tant ordonns dans le temps : d
i
< f
i
< d
i+1
< f
i+1
comme sur la
gure (4.6).
Au moment f
i
de la n de la vague i, comme tout autre instant du calcul, le nombre de messages
reus ne peut tre quinfrieur ou gal aux nombre de messages mis, autrement dit :
t : R(t) < E(t) R(f
i
) E(f
i
)
Mais, le nombre de messages E(f
i
) mis jusqu linstant f
i
est lui, infrieur ou gal la somme E
i+1
rsultat de la collecte de la vague (i + 1) et de manire analogue, la somme R
i
rsultat de la collecte
de la vague i est infrieure ou gale au nombre de messages reus linstant de la n de cette vague i.
Si le prcidat Term est vri, on obtient limplication suivante :
E(f
i
) E(d
i+1
), E(d
i+1
) E
i+1
, Term E
i+1
= R
i
, R
i
R(f
i
)
E(f
i
) R(f
i
)
Par consquent, on en dduit que : E(f
i
) = R(f
i
). linstant f
i
, on avait donc bien lgalit du nombre
de messages mis et reus. Cet tat est stable, donc le calcul tait bien termin.
4.2.5 Algorithme fond sur la notion de chemin rparti
On suppose, comme pour lalgorithme prcdent, que tout pas de calcul est atomique et que lenvoi de
plusieurs messages est une seule opration de diusion. Nous verrons dans ce qui suit comment ces hypothses
peuvent tre interprtes et implantes de direntes manires.
Lobservation du calcul constitue loriginalit de lapproche. En eet, le calcul diusant nest pas vu
comme une suite dchanges de message, mais comme le dploiement dun ensemble de chemins dans larbre
du calcul. Cest cette interprtation (abstraction) qui va permettre de dtecter la terminaison. En eet, au
cours de lexcution du calcul, de nouveaux chemins apparaissent et disparaissent. Cest leur comptage qui
permettra de dire si le calcul est termin ou non au lieu de compter les messages.
Plus prcisment, lalgorithme sappuie sur le comptage des chemins maximaux issus de la racine du
calcul. Un chemin maximal est donc ici dni comme une suite darcs adjacents conduisant du nud racine
une feuille. Dans ce qui suit, nous dsignons sous le terme de chemins exclusivement des chemins maximaux
issus de la racine.
Ainsi, un calcul diusant apparat plutt sous la forme dun calcul arborescent comme la gure (4.7) en
donne une ide.
De faon classique, on suppose quun processus collecteur recevra les informations qui lui seront nces-
saires pour dtecter la terminaison du calcul.
Quelques remarques importantes avant daborder lalgorithme :
lalgorithme utilise comme mcanisme de base la notion de vecteur de chemin. Tous les messages
changs sont surchargs par un tel vecteur de taille gale au nombre de processus ;
S4
S1
S2 S3
S1
S1
S2 S3
S2
Site
Migration
Chemin
S4 S5 S6
S7 S8
S5
S8
S5 S1
S6 S5
Figure 4.7 Une vision par chemins du calcul
le simple passage dun chemin via un processus nimplique aucune action dans lalgorithme. Autre-
ment dit seules les actions locales entranant une destruction de chemin ou le dbut dun ou plusieurs
nouveaux chemins entrent en jeu ;
lalgorithme retarde la connaissance par le processus collecteur de la cration de nouveaux chemins
jusquau moment o un chemin disparat. Cest en eet ce moment quil faut savoir quel est le pass
causal du chemin qui disparat ;
lalgorithme nengendre pas de messages supplmentaires except un message par vnement n de
chemin envoy au processus collecteur. Ce principe de base de lalgorithme est lutilisation classique
de la surcharge des messages de lapplication par un seul vecteur de taille xe gale au nombre de
processus ;
si le rseau perd des messages, lalgorithme reste sr (pas de fausse dtection puisquaucune contrainte
dordonnancement des messages nest impose) mais non vivace.
Le processus collecteur, grce aux informations quil recevra au cours du calcul, pourra nalement dduire
que le calcul est termin.
Les proprits les plus intressantes de lalgorithme sont les suivantes :
lalgorithme ne ncessite aucune proprit dordonnancement des messages par le rseau (les canaux
peuvent tre non FIFO par exemple). Il faut cependant que les communications soient ables. ;
lalgorithme ne ncessite quun seul compteur local chaque processus ;
lalgorithme dtecte la terminaison ds que le site collecteur a reu tous les messages de n de chemin.
En rsum, lalgorithme sappuie sur les hypothses de base suivantes :
le rseau de communication est able et connexe ; la communication est asynchrone ;
un processus collecteur peut recevoir des messages de tous les autres processus ;
toute phase dactivit dun processus est considre comme atomique y compris lenvoi dun ou plusieurs
messages en n dtape ;
La modlisation du calcul par chemins
Lalgorithme repose sur lutilisation de vecteurs de chemins qui permettent, comme leur nom lindique,
dvaluer le nombre de chemins en cours de dploiement.
Lorsquun message arrive destination, il appartient toujours un chemin et 3 cas distincts dactions
locales peuvent se produire :
1. Follow : laction locale traite le message entrant et en rponse poursuit le calcul en envoyant un unique
message vers un autre processus : dans ce cas, on peut considrer que le chemin entrant se poursuit ;
2. End : laction locale traite le message entrant et nenvoie aucun message. Ce cas correspond la n
dun chemin;
3. Split : laction locale traite le message entrant et envoie p messages (p > 1) vers dautres processus
2
.
Ce cas correspond la cration de p1 nouveaux chemins. Lalgorithme propos impose que lenvoi de
ces p messages soit vu comme atomique cest--dire que le protocole de terminaison doit savoir combien
2. ventuellement, le processus peut senvoyer un message lui-mme, ce qui peut tre interprt comme une continuation
du mme processus.
de messages seront envoys avant lenvoi du premier de ces p messages. Ceci peut tre assur en gardant
les messages dans un tampon associ laction locale mettrice tant que celle-ci na pas explicitement
dit quelle se terminait. Dans le systme Chorus, cette approche tait adopte pour assurer latomicit
des tapes dun acteur [32].
La dtection de la terminaison repose sur le comptage des chemins. Si lon appelle C le compteur des
chemins crs et T le compteur des chemins termins, le prdicat de dtection est simplement C = T. Le
problme consiste donc russir valuer ce prdicat de faon rpartie sans provoquer de fausse dtection.
Pour le compteur de terminaison T, chaque action de type End se termine par lenvoi dun message vers
le processus collecteur. Ce message informe le processus collecteur quun chemin est termin et quil faut
donc incrmenter de 1 le compteur T. Nous allons voir que ce message doit contenir aussi un vecteur de
chemins.
Mise en uvre de lalgorithme
Pour compter les crations de chemins, le mcanisme de vecteur de chemins est mis en uvre. La gestion
de ces vecteurs dentiers repose sur les principes suivants :
dune part, on associe un compteur local C
i
chaque processus. Celui-ci enregistre le nombre de
chemins crs via ce processus. Initialement, ces compteurs sont nuls.
dautre part, un vecteur de chemins va surcharger tous les messages du calcul. Ce vecteur est transport
par les messages successifs qui construisent peu peu le chemin et sa taille est gale au nombre N
de processus. Soit V le vecteur associ un chemin, ce vecteur va tre modi au fur et mesure du
dploiement du chemin. Il enregistrera le nombre de crations de nouveaux chemins issus de chaque
processus et causalement antrieurs au message qui le contient. Un processus unique initialise le calcul
en excutant une action Split avec un vecteur initial nul.
Algorithme des processus participants
Soit V le vecteur du message reu par un processus P
i
. Les actions de mise jour de ce vecteur sont les
suivantes :
Action de type Follow : le vecteur V est simplement recopi dans le message sortant ;
Action de type End : le vecteur V est envoy au processus collecteur ; il signale ainsi au processus
collecteur quun chemin sest termin et quun ensemble de chemins existent. On peut remarquer que
cette action nest rien dautre quune opration Follow avec le processus collecteur comme destinataire
du message mis ;
Action de type Split : le compteur local est mis jour selon le nombre de chemins crs par laction :
C
i
:= C
i
+(p1). Aprs quoi, la composante i du vecteur V reoit cette valeur : V [i] := C
i
. Ce vecteur
mis jour est le vecteur qui sera plac dans tous les messages sortants. En eet, tous les chemins crs
hritent de la mme causalit issue de celle qui existait dj (chemin origine). Tout vecteur V sortant
dun processus P
i
connat donc exactement le nombre de chemins crs par le processus P
i
.
Remarque Laction Follow pourrait tre considre comme une action Split de degr 1. Cependant, une
telle action Split entrane une aectation (V [i] := C
i
) non ncessaire bien que tout fait compatible avec
lalgorithme.
Algorithme du processus collecteur
Grce aux vecteurs quil reoit, le processus collecteur value peu peu le nombre de chemins crs et
dtruits. Il gre un vecteur MT initialement nul et le compteur T lui aussi initialement nul.
Le processus collecteur reoit les vecteurs de chemins qui lui sont adresss jusqu ce quil puisse conclure
la terminaison. Pour chaque vecteur V reu par le collecteur, celui-ci :
value le nouveau vecteur maximum MT laide de la fonction max dnie par :
i :: max(A, B)[i] = if (A[i] < B[i]) then B[i] else A[i]
3
Collecteur
1
CMax (=0,0,0)
T = 0
1
0
0
0
Compteur locaux
P0
P2
P1
0,1,0
0 1 1
1,1,0
1,1,0
1,1,0
0,1,0
1,1,0
1,1,0 1,1,0 0,1,0
0,1,0
2
Figure 4.8 Exemple de dtection
(2,3,0)
0
1
0
1
0
2 2
0 0 0 0
(x,y,z) : vecteur gr par le site
0,1,0
0,1,0
1
1,1,0
1,1,0
(1,1,0)
0,1,0
(1,2,0)
3
2,3,0
(2,3,0) (1,2,0)
2,3,0
2,1,0
2,1,0
(2,1,0)
1,2,0
1,2,0
2,1,0
2,3,0
2
2,3,0
Figure 4.9 Exemple plus complet
enregistre la terminaison dun chemin (incrmentation de T)
et teste le prdicat de terminaison en comparant la somme des lments du vecteur MT
3
avec le
nombre de chemins termins indiqu par la variable T.
process Collecteur
integer MT[N] = [0, . . . , 0]; /* vecteur maximum */
integer T = 0; /* compteur des chemins termins */
repeat
integer V [N];
recevoir(V );
MT, T := max(MT, V ), T + 1; /* Term */
until ( MT + 1 = T) /* Detect */
Le chronogramme de la gure (4.8) montre lvolution du calcul sur un exemple simple.

Lexemple de la gure (4.9) prsente un autre cas plus complet montrant limportance du compteur local
chaque processus. Le processus collecteur nest pas reprsent. On notera que les messages envoys vers le
collecteur peuvent tre reus dans un ordre quelconque.
4.3 Interblocage
Le problme de linterblocage ne disparat naturellement pas avec la rpartition. Tout schma dalloca-
tion de ressources critiques rparties conduit un systme parallle sujet au risque dinterblocage. Pire, la
3. On utilise la notation X pour abrger : X =< + : 0 k < N :: X[k] >.
P attend la ressource R
R
P P
P1
P2
P3
P4
A
B
D
P5
C
C
possde par P
Figure 4.10 Cycle dinterblocage dans le modle et
classe R possde par P
R
P P
P1
P2
P3
P4
P5
A
B
B
C
D
E
E
P attend la ressource de
Figure 4.11 Graphe CFCT dinterblocage dans le modle ou
communication elle-mme peut tre lorigine de situations dinterblocage sous certaines conditions.
4.3.1 Rappel
Rappelons quen milieu centralis, lallocation de ressources critiques peut prendre deux formes di-
rentes :
Modle et : les processus acquirent des ressources identies. Autrement dit, toute requte a pour
objectif dobtenir une ressource critique spcique (ventuellement plusieurs simultanment, mais il
faudra alors les obtenir toutes) ;
Modle ou : les processus acquirent des ressources prises parmi des classes de ressources. Autrement
dit, une requte demande lobtention dun exemplaire quelconque dune ressource dune certaine classe.
Dans le modle de type et, un tat dinterblocage est caractris par la dtection dun cycle dans le graphe
dattente des processus. La gure (4.10) montre un tel graphe dans lequel les processus P
1
, P
2
et P
3
sont en
tat dinterblocage.
Dans le cas du modle de type ou, la dtection dun interblocage repose sur la formation dune composante
fortement connexe terminale (en abrg CFCT ou knot en anglais). Un graphe G = (S, A) o S est lensemble
des sommets et A est lensemble des arcs est un graphe CFCT ssi il satisfait la proprit suivante :
s S : suc(s) ,= suc(s) S
Autrement dit, dans un tel graphe, tout sommet possde au moins un arc sortant et tout arc sortant conduit
un sommet qui appartient aussi au graphe.
La gure (4.11) illustre un tel graphe entre 5 processus. Le processus P
2
(resp.P
5
) attend une ressource
de classe B (resp. E) sachant que les exemplaires de cette classe de ressources sont possds par P
3
et P
5
(resp. P
1
et P
4
).
4.3.2 Interblocage des communications
Les changes de messages peuvent conduirent des situations dinterblocage similaires au modle ou
prcdemment dcrit. En eet, considrons un systme de processus communiquant par messages en mode
synchrone : lmission dun message est bloquante tant que le message na pas t reu.
Alors, le ou les processus metteurs possibles apparaissent comme des ressources critiques demandes
par les rcepteurs. Dans la gure (4.11), on peut donner ainsi chaque arc la signication suivante : un arc
existe de P vers P
si P attend un message issu de P
. On remarquera que cette interprtation implique de

connatre le ou les metteurs qui peuvent envoyer un message vers le rcepteur
4
.
Compte tenu des arcs existants, les processus de la gure (4.11) sont tous dans ltat en attente de
rception . titre dexemple, le processus P
5
peut tre considr comme en attente dun message issu du
processus P
1
ou P
4
.
Une communication en mode asynchrone peut aussi conduire une situation dinterblocage mais il faut
alors vrier une condition supplmentaire : les canaux de communication sous-jacents aux arcs du graphe
sont vides.
4.3.3 Un algorithme de dtection (Chandy et Misra)
Un algorithme de dtection a t propos par Chandy et Misra sous la forme dun calcul diusant. Cet
algorithme permet un processus enquteur (qui peut tre lun des processus participants) de savoir sil
appartient une CFCT. Tant quil nobtient pas de rponse, le doute subsiste. Attention, cet algorithme ne
permet pas de savoir si une CFCT existe quelque part parmi les processus applicatifs.
Modlisation des processus applicatifs
Chaque processus commute, au cours du calcul, de ltat actif ltat passif lorsquil se met en attente
de rception dun message. La rception du message provoquera le retour ltat actif.
Dans ltat passif, tout processus i possde un ensemble de dpendance D
i
non vide constitu des pro-
cessus dont il peut esprer un message.
Droulement du calcul diusant
Le calcul diusant, dmarr par le processus enquteur, est propag par les processus visits dans ltat
passif. Un processus visit alors quil est actif ignore lenqute.
La propagation du calcul par un processus passif i se fait vers les sites appartenant lensemble de
dpendance correspondant D
i
.
Le calcul diusant parcourt ainsi les arcs du graphe dattente. Pour dtecter une CFCT, il faut dtecter
les cycles prsents dans le graphe. Autrement-dit, ds quun processus est revisit par le calcul diusant alors
quil est toujours passif, un cycle a t parcouru (et dtect).
Pour viter les fausses dtections et assurer la terminaison du calcul diusant (SI une CFCT incluant le
processus enquteur existe bien), au cours de son dploiement, le calcul diusant place les processus visits
dans un arbre de recouvrement selon les rgles suivantes :
dune part, lors de la premire visite, un processus passif prend pour pre, le processus metteur ;
dautre part, la propagation de la dtection des cycles ne se fera dun ls vers son pre que lorsque le
ls aura lui-mme reu une rponse de la part de chacun des processus appartenant son ensemble de
dpendance.
Autrement dit, la dtection de la CFCT est quivalente la russite de la construction de larbre ou, ce
qui est quivalent, la terminaison du calcul diusant qui le construit). Si larbre se construit ( le calcul
diusant se termine), il existe une CFCT. Si la construction de larbre ne se termine pas ( le calcul diusant
ne se termine pas), il ny a pas interblocage incluant le processus enquteur.
4. Au pire, et par dfaut, il faudra considrer que tout autre processus peut tre metteur.
cycle
Rponse Enqute
P2
P3
P4
P5
P1
P2
P3 P5
P1 P4
P2 P4
P3
P2 P1
P4 P5
P2 (2)
(3)
(2)
(5)
(3)
1re visite
2me visite
2me visite
3me visite
Arbre construit
cycle
Figure 4.12 Calcul diusant de dtection dune CFCT
titre dexemple, la gure (4.12) montre le droulement du calcul diusant dbut par P
2
et conduisant
la conclusion que ce dernier appartient bien une CFCT englobant les 5 processus. La dtection de la
CFCT repose ici sur la dtection de 2 cycles.
4.4 Exercices
1. On utilise le principe du jeton circulant pour rsoudre le problme de lexclusion mutuelle. On suppose
que le message jeton peut se perdre. Proposer un algorithme de dtection de la perte du jeton. On
supposera que les canaux de communication sont FIFO;
2. La dtection de la perte du jeton tant faite, il faut engendrer un nouveau jeton. Proposer un algorithme
dlection qui permettra dassurer quun seul processus engendrera un jeton;
3. Lalgorithme de dtection dun interblocage par dtection dune CFCT utilise un calcul diusant.
Par ailleurs, cette dtection repose sur la terminaison de la construction dun arbre de recouvrement.
Proposer une adaptation de cet algorithme en utilisant lalgorithme de dtection de la terminaison dun
calcul diusant utilisant les vecteurs de chemins.
Deuxime partie
Systmes et services rpartis
73
Chapitre 5
Les services de base
5.1 Calcul dun tat global : prise de clich
5.1.1 Introduction
Labsence dtat global est une des caractristiques essentielle (et malheureuse. . .) des systmes rpartis.
Un site ou processus na quune connaissance approximative de ltat des autres sites ou processus puisque,
seul, lchange de messages permet dobtenir des informations sur les partenaires distants (logiquement).
Lintrt de capter un clich global dun calcul rparti est avant tout de pouvoir, en cas de dfaillance,
reprendre le calcul partir dun tel clich. Il sagit donc de dnir des points de reprise potentiels.
Un grand nombre dalgorithmes ont donc t proposs sur le thme de lvaluation dtats globaux
cohrents dun calcul rparti. Lobjectif de ces algorithmes est darriver collecter un ensemble dtats
locaux aux processus an dobtenir un tat global pass cohrent du calcul. Cette prise de clich (snapshot)
pose surtout un problme de cohrence des informations collectes incluant dventuels messages en transit.
La gure (5.1) montre cette dicult : le processus collecteur capte un tat local E
A
du processus A pour
lequel le message m na pas encore t envoy, alors que ltat local E
B
du processus B est postrieur la
rception de m. Cest ce genre dincohrence qui peut par exemple, dans un algorithme de dtection dun
tat stable, provoquer une fausse dtection. Dans cette exemple, sil sagit de dtecter la terminaison dun
calcul diusant par comptage des messages envoys et reus par chaque processus, ltat global incohrent
collect peut conduire une fausse dtection du fait de la prise en compte de la rception du message m
sans avoir pris en compte son mission.
r
m
A
B
Collecteur
E(A)
E(B)
e
Figure 5.1 Prise de clich incohrent
Une proprit de base prciser est donc la notion de cohrence dun tat global. Pour ce faire, on utilise
la notion de coupure cohrente.
5.1.2 Notion de coupure cohrente
De faon standard, le calcul rparti est abstrait sous la forme dun ensemble dvnements partiellement
ordonns. On appelle coupure cohrente C un sous-ensemble des vnements ( dun calcul rparti vriant
75
m
A
B
C
e
m
r
e
r
e
r
Figure 5.2 Prise de clich cohrente mais dun tat potentiel
la proprit suivante :
e C : e
( : e
e e
C
Autrement dit, si un vnement e appartient une coupure, alors tous les vnements du calcul qui le
prcdent causalement appartiennent aussi la coupure. Une coupure, comme son nom le suggre, tablit
une frontire sur tous les sites entre un ensemble dvnements qui sont avant et la suite du calcul
aprs . Lexemple de la gure (5.1) montre une coupure incohrente puisque lvnement dmission e de m
nest pas dans lensemble des vnements collects qui contient, par contre, lvnement r.
Un algorithme de prise de clich devra donc tout dabord raliser une coupure cohrente du calcul.
Cependant, ltat global construit naura pas forcment exist dans le temps global. titre dexemple, la
gure (5.2) montre une coupure cohrente bien quelle suppose un tat global dans lequel lvnement e est
arriv et lvnement r
est encore venir alors que dans la ralit lvnement r
a eu lieu avant e. Ceci na

cependant pas dimportance puisque les deux vnements ne sont pas causalement lis.
Par ailleurs, lvnement de rception du message m nest pas capt dans la prise de ltat local du site
B, alors que lmission de ce message appartient au pass de ltat local capt du site A. Pour obtenir un
tat cohrent, il faudra donc aussi mmoriser que la message m est un message en transit. Un tat global
cohrent associ la coupure de la gure (5.2) devra donc aussi prciser que le message m est en transit.
5.1.3 Un algorithme de prise de clich (Chandy et Lamport)
Cet algorithme assure la collecte dun clich cohrent constitu des tats locaux de chaque site et des
messages en transit associs. Pour ce faire, certaines hypothses simplicatrices sont faites :
la communication est suppose point point sur des canaux FIFO unidirectionnels. Chaque site i
connat dune part ses canaux entrants E
i
et dautre part ses canaux sortants S
i
;
la topologie du rseau de communication doit tre fortement connexe ; cette contrainte est due au
principe de marquage utilis.
Comme il nest pas possible de synchroniser la prise de chaque tat local un instant t, la prise dun
clich global est asynchrone. Chaque processus peut dcider de dbuter une phase dvaluation dun tat
local complt par dventuels messages en transit.
Phase dvaluation dun clich local
Cette phase consiste mmoriser son tat local et capter, partir de cet instant, les messages en
transit sur ses canaux entrants. Pour cela, une fois cet tat local mmoris, un message marqueur est
mis sur chaque canal de sortie S
i
. Aprs quoi, tout message entrant est mmoris comme message en transit
appartenant un canal donn. Si un message marqueur arrive parmi ces messages entrant, alors tous les
messages en transit sur ce canal ont t pris en compte. Lorsquun message marqueur aura t capt sur
chaque canal entrant, ltat local mmoris complt par les messages en transit de chaque canal entrant
peut tre envoy au processus collecteur.
Lorsquun processus reoit un message marqueur, deux cas sont possibles :
soit il a dj mmoris son tat local, auquel cas, il est en phase de rception des messages marqueurs
et il na donc qu enregistrer que la collecte des messages en transit sur un canal entrant est termine ;
soit il na pas encore mmoris son tat local, auquel cas, il dbute la phase dvaluation dun clich
local.
5.2 Le problme du consensus
Le problme du consensus est considr par certains comme LE problme fondamental pos aux systmes
rpartis pour les rendre tolrants aux fautes sous les hypothses asynchrones. Il est en eet sous-jacent
toute situation o lon utilise la redondance pour obtenir un systme tolrant certaines fautes.
Par exemple, dans un systme de gestion de transactions rparties, tous les processus ayant particips
une transaction doivent nalement dcider de sa validation ou de son annulation. Ils doivent TOUS prendre
la mme dcision. Dans les protocoles de diusion, il faut pouvoir dcider si un message a bien t reu
par tous les processus cibles. Chacun dentre eux devra l encore prendre la mme dcision vis--vis dun
message donn. Lorsquon met en uvre de la rplication, il faudra que chaque processus rpliquant un calcul
se mette daccord avec les autres sur le rsultat.
Le problme majeur du consensus est de tolrer les dfaillances de sites ou de communication. Il faudra
en particulier distinguer les processus corrects des processus dfaillants. La dfaillance mme dun processus
pourra prendre plusieurs formes. Une forme simple est larrt. Mais des comportements plus complexes
pourront tre considrs comme par exemple, au pire, un comportement arbitraire : un processus met par
exemple des messages errons (voir problme des gnraux byzantins). Pourtant, le problme est simple
spcier : comment N sites (processus) peuvent se mettre daccord, donc atteindre un consensus, en
communiquant par messages ?
Sous ces apparences simples, le consensus se rvle un problme dlicat qui ne doit pas tre rduit
un simple problme dacquittement de message. Il sut pour sen convaincre dun exemple comportant
seulement deux interlocuteurs.
Romo et Juliette se donnent rendez-vous par e-mail
Supposons que Romo souhaite donner rendez-vous Juliette une date et en un lieu x en utilisant
le-mail et supposons que le service e-mail puisse perdre des messages.
Romo envoie donc un premier message pour proposer un rendez-vous Juliette. Tout ce passe bien et
celle-ci le reoit 5 mns plus tard. Elle rpond oui par un message qui parvient 10mns plus tard Romo.
Le consensus semble alors atteint entre Romo et Juliette et ils devraient donc se rencontrer. Cependant,
Romo est alors pris dun doute : Si Juliette ne sait pas que jai reu sa rponse positive, elle peut supposer
que son message rponse sest perdu et peut-tre nira-t-elle pas au rendez-vous. Je devrais donc lui envoyer
un message conrmant que jai bien reu sa rponse. Mais dans ce cas, une suite infernale dacquittements
rciproques dbute. En fait, sous ces hypothses, il nexiste alors pas de protocole qui permette dtre sr
que les deux prendront la mme dcision.
Le scnario prcdent amne les remarques suivantes :
Mme pour seulement deux processus, le problme est insoluble ;
Le problme du consensus est strictement distinct de celui de lacquittement dun message. Romo
reoit bien un acquittement de son premier message lorsque lui parvient la rponse de Juliette. Il sait
alors que son premier message est bien parvenu Juliette. Par contre, Juliette ne sait pas quil possde
cette connaissance. Elle peut avoir un doute ! Le problme du consensus soulve donc un problme plus
dicile de coordination mutuelle ;
Si Romo et Juliette avaient pris un tlphone, ils seraient parvenus un consensus sans dicult. En
eet, la communication assure alors une borne suprieure la dlivrance ou la perte dun message
(coupure de la ligne). Cest lhypothse dun dlai non born de dlivrance des messages qui rend le
consensus impossible ;
Une approche probabiliste peut tre adopte : Romo et Juliette auraient pu dupliquer leurs messages
de faon minimiser le risque de perte dun message. Il est alors intressant de concevoir des algorithmes
de consensus de type probabiliste garantissant quun consensus sera atteint dans un dlai born avec
une forte probabilit. Ceci est possible car les situations rendant le protocole impossible 100% sont
rares.
5.2.1 Spcication du problme
Plus prcisment, une modlisation du problme peut tre faite sous la forme des hypothses de base
suivantes :
le systme est compos de N processus ;
chaque processus possde une valeur initiale v
0
T;
Un algorithme correct doit vrier les spcications suivantes :
1. Terminaison : lalgorithme doit tre vivace cest--dire que tout processus correct doit nalement dcider
dune valeur nale ;
2. Validit : si tous les processus ont initialement la mme valeur v
0
, tous les processus corrects choisiront
nalement pour valeur nale v
0
;
3. Cohrence : si un processus correct choisit une valeur v, tous les autres processus choisiront aussi v.
Des variantes existent selon les contraintes de validit de la valeur nale : par exemple, la valeur nale
doit tre la valeur initiale possde par une majorit de sites, voire par tous les sites. titre dexemple,
on peut supposer que les processus doivent se mettre daccord sur une valeur boolenne (T = Boolen). La
contrainte de validit peut tre alors pour la validation dune transaction :
FAUX nengendre pas VRAI : (i : P
i
.v
0
) (i : P
i
.v
f
)
VRAI nengendre pas FAUX : (i : P
i
.v
0
) (i : P
i
.v
f
)
Une seule valeur initiale fausse entraine linvalidation :
(i : P
i
.v
0
) (i : P
i
.v
f
)
5.2.2 Les dirents contextes de rsolution
Le problme du consensus peut tre envisag dans dirents contextes de communication :
le support des changes dinformation entre processus peut tre aussi bien une mmoire partage ac-
cessible aux dirents processus pour communiquer (architecture multiprocesseurs dote dune zone
mmoire globale) aussi bien quun simple rseau de communication par messages (architecture distri-
bue) pour communiquer entre processus,
systme synchrone ou systme asynchrone : les processus sexcutent en synchronisme rel ou sont
indpendants les uns des autres.
La dicult survient ds que lon se place dans un contexte o tous les composants du systme ne sont
pas ables et peuvent donc provoquer des fautes. Les dfaillances peuvent se situer au niveau des communi-
cations (perte de message par exemple) ou au niveau des processus (processeurs). Pour ces derniers, il faudra
distinguer dune part larrt pur et simple dun processus et dautre part, le passage un comportement
arbitraire (comportement byzantin).
Un autre paramtre important est, dans le cas dune communication par messages, lexistence ou non
dune borne connue sur le dlai de transfert dun message. Lexistence dun dlai maximum connu permet
de retrouver des hypothses proches de celle dun systme synchrone au sens strict.
Un rsultat important et symbolique est quil nexiste pas dalgorithme rsolvant le consensus dans
le cas dun systme asynchrone ds quun seul processus peut tre dfaillant (par arrt).
5.2.3 Preuve de limpossibilit du consensus en asynchrone
Il est important de bien prciser les hypothses :
Chaque processus volue son rythme (systme asynchrone) ;
Les processus communiquent par un protocole point--point
1
;
1. Mme si le protocole est un protcole de diusion, il nexiste pas de solution si ce protocole nest pas ordonn
Il ny a pas de dlai maximal connu pour la transmission des messages ;
La preuve, due M. Fisher, N. Lynch et M. Paterson [12], repose sur la mise en vidence dune squence
dexcution empchant tout consensus en prsence dune dfaillance dun seul processeur. Plus exactement,
larrt dun processus peut entraner limpossibilit de conclure.
De faon standard, lexcution du protocole peut tre abstraite sous la forme des vnements engendrs
par les messages et en particulier on sintresse aux rceptions des messages. On note E(t) ltat courant du
systme linstant t compos, classiquement, dune part par les tats locaux des processus et dautre part,
par les messages en transit.
Dnition 5.2.1 Un tat E(t) est dit dterministe sil conduit toujours la mme valeur nale consen-
suelle. Dans le cas contraire, il est dit bivalent.
La dmonstration repose sur les deux lemmes suivants :
Lemme 5.2.1 Il existe un tat initial bivalent.
Lemme 5.2.2 Partant dun tat bivalent, on peut trouver (il existe potentiellement) une squence non vide
de transitions vers un autre tat bivalent.
Lexistence dun tat initial bivalent (lemme 5.2.1) et lexistence dun chemin inni dtat bivalent
tat bivalent amne conclure linexistence du protocole.
Pour simplier, on suppose que les processus doivent se mettre daccord sur une valeur boolenne. Ini-
tialement, ils possdent donc chacun une valeur V ou F. Les processus devront se mettre daccord sur lune
de ces deux valeurs.
Preuve du lemme 5.2.1
Si lon considre les tats initiaux possibles, on peut constater quil est possible de les ordonner de telle
faon que 2 tats adjacents ne dirent que par une seule valeur correspondant un processus x.
P
1
P
2
. . . P
N1
P
N
Rsultat
E
1
V V ... V V V
E
2
F V ... V V ?
E
3
F F ... V V ?
. . .
E
N
F F ... F V ?
E
N+1
F F ... F F F
Supposons que tous les tats initiaux soient dterministes ( pas dtat initial bivalent). Il existe alors
forcment parmi ces tats E
i
, deux tats E
v
et E
f
lun conduisant la valeur consensuelle V et lautre la
valeur F mais ne dirant que par un seul composant :
i ,= i
0
: E
v
[i] = E
f
[i] E
v
[i
0
] = E
f
[i
0
]
Ce qui revient dire quil faut donc quil existe une fonction Consensus prenant en paramtre les tats et
telle que :
Consensus(E
v
) = Consensus(E
f
)
Or, si le processus i
0
est larrt ds le dbut du protocole (ou avant davoir pu communiquer quoi que
se soit aux autres processus) les deux tats prcdents deviennent :
i ,= i
0
: E
v
[i] = E
f
[i] E
v
[i
0
] = E
f
[i
0
] = E
v
= E
f
Et par consquent, on aura Consensus(E
v
) = Consensus(E
f
). Les deux congurations E
v
et E
f
conduisent
donc alors au mme consensus contrairement lhypothse faite.
Il existe donc bien des tats initiaux bivalents.
Preuve du lemme 5.2.2
Partant dun tat bivalent E(t), il existerait un algorithme si aucune squence de transition vers un autre
tat bivalent ne pouvait tre trouve. Supposons donc que partant un tat bivalent, il existe un vnement
de rception r
v
dun message provoquant le passage dans un tat dterministe conduisant V , et il existe
donc aussi un vnement de rception r
f
dun message provoquant le passage dans un tat dterministe
conduisant F. Lhypothse dun tat bivalent impose lexistence de ces deux vnements.
Cas 1 : les deux vnements r
v
et r
f
ont lieu dans des processus rcepteurs distincts Loccur-
rence de ces deux vnements peut avoir lieu dans nimporte quel ordre et donne le mme tat rsultat. Or,
selon lordre doccurrence, ltat rsultat serait V ou F. Un mme tat ne peut donner un rsultat dirent.
Cas 2 : les deux vnements r
v
et r
f
ont lieu dans le mme processus Dans ce cas, un premier
vnement peut avoir lieu et le processus peut sarrter. Alors, ltat atteint ainsi est le mme quel que soit
lvnement arriv avant la panne. Or, ltat avant la panne avait conduit dcider V si lvnements tait
r
v
et dcider F si lvnement tait r
f
. On voit donc qu nouveau une contradiction existe.
Lhypothse initiale supposant quil nexistait pas de squence possible de transitions vers un autre tat
bivalent tait donc fausse.
5.2.4 Un algorithme simple
Pour que tous les processus prennent la mme dcision, valuent le mme rsultat nal, il sut quils
aient connaissance des toutes les valeurs initiales et quils utilisent une mme fonction pour valuer la valeur
nale :
i : P
i
.v
f
= F(P
0
.v
0
, . . . , P
N1
.v
0
)
Initialement, un processus i ne connat que P
i
.v
0
et il ne peut donc valuer F.
Si les communications sont ables, un algorithme rsolvant le problme peut tre trs simplement trouv.
Chaque processus diuse sa valeur initiale tous les autres processus. Il recevra donc lui-mme la valeur
initiale de tous les autres processus. Une fois en possession de toutes ces valeurs, chaque processus pourra
prendre une dcision partir des MMES donnes. Par consquent, la fonction F donnera le mme rsultat
quel que soit le processus.
5.2.5 Quelques problmes voisins
Le problme du consensus comporte de nombreuses variantes applicatives. Parmi elles, on peut en dis-
tinguer deux classiques :
Un processus Matre m propose une valeur V
m
quil diuse aux autres et nalement, tout processus
correct choisit la mme valeur qui peut tre soit la valeur propose V
m
si le processus matre tait
correct, soit une valeur par dfaut si celui-ci tait incorrect. Ce problme est plus connu sous le terme
de problme des gnraux byzantins. Il a t largement tudi dans le domaine de la tolrance aux
fautes.
Chaque processus propose une valeur v
i
et les processus corrects doivent nalement construire un
vecteur V d
i
identique dans lequel V d
i
[j] = v
j
pour tout processus i correct. Cest de cette faon que
des processus peuvent se mettre daccord sur un tat global par exemple.
5.3 Conclusion
Labsence dalgorithme pour obtenir un consensus dans le cas dun systme asynchrone nempche pas de
trouver des solutions ds que lon change quelque peu les hypothses sur les proprits de la communication.
En eet, il sut, par exemple, davoir un dlai born connu pour la transmission des messages, pour obtenir
un cadre o des algorithmes existent. Lexistence dhypothses minimales a mme t dmontre. Il faut
introduire la possibilit pour chaque participant davoir une certaine connaissance de ltat des autres. Cette
connaissance peut tre cependant imparfaite. La modlisation consiste introduire le concept de dtecteur de
dfaillance (failure dtector)[9]. Un tel dtecteur est associ chaque processus participant et est capable de
dtecter la dfaillance (larrt) des autres processus. Les proprits garanties par les dtecteurs de dfaillance
peuvent prendre diverses formes.
titre dexemple, les plus faibles proprits que doivent garantir les dtecteurs sont dnotes par 3J :
Condition faible 3J
Compltude faible : nalement tout processus dfaillant est suspect de faon permanente par au moins
un processus correct ;
Exactitude faible : il existe une date partir de laquelle au moins un processus correct nest pas
suspect par tous les autres processus corrects.
Un autre type de dtecteur, dnot 3o, garantit une compltude plus forte sur la dtection des d-
faillances :
Condition forte 3o
Compltude forte : nalement tout processus dfaillant est suspect de faon permanente par tous les
processus corrects ;
Exactitude faible : il existe une date partir de laquelle au moins un processus correct nest pas
suspect par tous les autres processus corrects.
Lexistence de ces dtecteurs vriant les conditions 3J ou 3o permet de dvelopper des algorithmes
corrects apportant des solutions au problme du consensus dans un contexte restant fondamentalement
asynchrone et non able [30].
Enn, le problme du consensus est quivalent au problme dune diusion vers un groupe (multicast)
able totalement ordonne. En particulier, si lon dispose dun tel protocole de diusion, le problme du
consensus peut tre simplement rsolu. Il sut que chaque processus diuse sa valeur au groupe. La premire
valeur reue par chaque processus est la mme et peut donc constituer la valeur choisie par tous.
Chapitre 6
Conclusion
Les principes fondamentaux de la rpartition sont maintenant bien tablis. Le modle standard vne-
mentiel dun calcul rparti permet de capter un tel calcul un niveau dabstraction susant pour observer et
contrler une excution rpartie. La relation de causalit apporte une formalisation de lordre partiel existant
entre les vnements.
Une algorithmique dites rpartie sest dveloppe pour classier et spcier les problmes gnriques
de la rpartition. Cet eort de recherche se poursuit aujourdhui compte tenu de lvolution des architectures
rparties. En eet, la plupart de ces algorithmes taient proposs dans un contexte trs statique : nombre xe
de processus, communication ge entre ces processus et hypothses de abilit simples. Aujourdhui, avec
les rseaux mobiles en particulier ad hoc, ces hypothses ne tiennent plus. Il faut envisager des algorithmes
fonds sur hypothses plus souples en terme de communication et de nombre de processus participants.
Par ailleurs, le nombre mme de participants a tendance augmenter de faon trs importante. L encore, ce
facteur dchelle peut conduire des remises en cause de lexistant. Les rseaux de capteurs sont un exemple
de cette volution.
Si le schma client-serveur reste dactualit, dautres formes de communication prennent aussi de limpor-
tance, en particulier dans les jeux en rseaux via Internet ou dans des applications mtiers plus spciques :
robotique et/ou simulation avec des contraintes de temps rel par exemple.
La preuve des algorithmes rpartie reste aussi un d dicile atteindre. Leur complexit est trs le-
ve et les mthodes de preuve par vrication de modle (model-checking) se heurtent encore lexplosion
combinatoire du nombre dtats possibles de tels calculs. Lusage de plus en plus frquent darchitectures ma-
trielles ayant des proprits rparties dans les systmes critiques (avionique, espace par exemple), ncessite
donc un eort important de recherche de mthodes de dveloppement sr de tels systmes rpartis.
Les systmes rpartis ont donc encore de beaux jours devant eux . . .
83
Appendices
85
Annexe A
Quelques sujets dexamens avec ou sans
correction. . .
A.1 Causalit, Horloge et Prise de clich
A.1.1 Causalit (4 points)
On considre le chronogramme suivant :
e1
e4 e6
r1
r4
r5
e5 r3
r6
m1
m3
m4
m5
m6 m2
e2
r2
e3 r1
Figure A.1 Chronogramme 1 : Causalit
Questions
1. Prcisez si les vnements r
4
et r
5
sont causalement lis ou pas. Justiez votre rponse.
2. Montrez que la rception du message m
1
la date relle r
1
au lieu de r
1
ne change pas les relations
de causalit qui existaient. Autrement dit, les relations de causalit directe entre lvnement r
1
et les
autres vnements sont les mmes que celles existant entre r
1
et ces mmes vnements.
A.1.2 Une horloge minimaliste (8 points)
On considre un schma de datation minimaliste utilisant simplement un compteur croissant sur chaque
site. Chaque site possde une horloge locale H
s
grant une date logique sur laquelle les oprations dincr-
mentation Top et de recalage Recaler peuvent tre excutes :
class Horloge {
int cpt = 0 ;
int Top() { cpt++; return cpt ; } // Incrmentation-Lecture
void Recaler( int d ) { if (cpt < d ) cpt = d ; } // Recalage
}
87
Lopration Top() incrmente sa valeur et renvoie la nouvelle valeur de lhorloge. Lopration Recaler(d)
aecte la valeur fournie en paramtre lhorloge si et seulement si celle-ci tait en retard.
Enn, les actions de mise jour de ces horloges lors les dirents types dvnements sont les suivantes,
o d
e
(respectivement et d
r
) dnote la date de lvnement dmission (respectivement la date de lvnement
de rception) dun message m :
s
.Top()
mission sur s de m int d
e
= H
s
.Top() ; envoi de < d
e
, m >
Rception sur s de < d
e
, m > H
s
.Recaler(d
e
); d
r
= H
s
.Top()
Figure A.2 Tableau des actions de mise--jour des horloges
e4
e1
r1
r3
m1
r5
e5
e3
m2
r2
e2
m3
m5
m4
H1=0
H2=0
H3=0
r4
Figure A.3 Chronogramme 2 : Datation
Questions
3. Dcorez le chronogramme de la gure A.3 en prcisant la date de chacun des vnements aects par
le mcanisme dhorloge propos. (Note : vous pouvez utiliser le chronogramme de la gure A.5 en n
de sujet comme support de la rponse.)
4. Quelle proprit peut-on dduire des dates aectes aux vnements distincts e et e
lorsque d
e
= d
e
?
5. On appelle chemin causal C(e
n
) conduisant un vnement e
n
, une suite dvnements e
1
, e
2
, . . . , e
n
vriant la proprit suivante : e

1
e
2
. . . e
n
.
La longueur dun chemin causal, note [C(e
n
)[ est gale au nombre dvnements de la suite.
1
Montrez
que la valeur de la date associe un vnement quelconque e est gale la longueur du (ou des) plus
long(s) chemin(s) causal(causaux) conduisant e. Autrement dit, linvariant suivant est vri :
e : C(e) : d
e
= [C(e)[ C
(e) : [C
(e)[ [C(e)[
Pour cela, montrez que si cette proprit est vraie avant lvnement, elle reste vraie aprs lexcution
de laction correspondant au type dvnement considr (voir tableau A.2).
6. Proposez une modication de lopration de recalage qui permettrait dobtenir linvariant suivant : la
date dun vnement est toujours suprieure au nombre total dvnements qui prcdent lvnement
dat. Autrement dit, on aurait la proprit suivante :
e : d
e
Card(G
e
) avec G
e
= e
: e
e
Note : Proposez une solution simple qui ne fasse toujours intervenir que la date " incidente" en para-
mtre et la valeur courante de lobjet horloge " rceptrice" .
1. Par convention, on admet quun chemin causal C(e) rduit lvnement lui-mme (C(e) = {e}) est donc de longueur 1.
A.1.3 Prise de clich global(8 points)
On considre un ensemble de N processus P
i
observs par un processus Collecteur. On suppose que
les communications sont ables et point point mais non FIFO. On cherche un algorithme permettant
au Collecteur de construire un clich global cohrent en utilisant le mcanisme de vague et un schma de
coloriage des processus et messages applicatifs.
Rappel Un clich global comprend dune part, les tats locaux de chaque processus et dautre part, les
messages en transit associs la coupure " trae" par les tats locaux collects. Une coupure est cohrente si
et seulement si les messages en transit traversent cette coupure du pass vers le futur (sur un chronogramme,
lvnement dmission est gauche de la coupure et lvnement de rception correspondant est droite de
celle-ci). Un clich est cohrent ssi il constitue une coupure cohrente.
Rgles de coloriage On utilise seulement deux couleurs : blanc et noir.
initialement, tous les processus et messages sont blancs ;
un processus rcepteur devient noir sil reoit un message noir ;
un processus met toujours des messages de sa propre couleur ;
un fois noir, tout processus reste noir ;
Le processus Collecteur lance une vague de couleur noire. Un processus visit devient donc noir ds
le passage de la vague (sil ne ltait pas dj). Lorsquun processus blanc reoit la visite de la vague, il
enregistre un clich local de son tat et devient noir.
m
Collecteur
P1
P2
P3
dbut de vague fin de vague
Instant de la visite
r
Message applicatif noir
Message applicatif blanc
Figure A.4 Prise de clich par vague
Questions
7. Si un processus noir visit par la vague prend son clich local au moment du passage de la vague
(comme le fait un processus blanc), montrez que le clich obtenu peut tre incohrent (Sappuyer sur la
gure A.4). En consquence, pour obtenir un clich cohrent, quelle mesure doit prendre un processus
blanc lorsquil devient noir par rception dun message applicatif noir (vnement r dans la gure A.4) ?
8. Le Collecteur doit aussi obtenir les messages en transit tels que le message m dans la gure A.4.
Caractrisez la classe dvnements de rception qui permettent de dtecter les messages en transit
(couleur du message reu, couleur du processus rcepteur).
9. On suppose que, chaque vnement de rception prcdent (dtecteur dun message en transit),
le processus rcepteur transmet le message reu au collecteur. Proposez un algorithme pour que le
Collecteur puisse savoir quil a reu tous les messages en transit associs au clich (problme particulier
de terminaison).
10. Proposer une modication de lalgorithme pour pouvoir faire plusieurs clichs successifs partir dun
mme collecteur.
Chronogramme pour la question 3
Aecter chaque vnement e
i
ou r
i
sa date.
e4
e1
r1
r3
m1
r5
e5
e3
m2
r2
e2
m3
m5
m4
H1=0
H2=0
H3=0
r4
Figure A.5 Chronogramme dcorer
A.2 Horloge et causalit directe (daprs Vilay K. Garg)
On considre un schma de datation utilisant des horloges vectorielles. Une date est reprsente par un
vecteur de dimension N o N est le nombre de processus communicants. Chaque processus P
i
possde une
horloge vectorielle locale H
i
dote des oprations classiques dincrmentation et de recalage. Initialement,
lhorloge H
i
du processus P
i
a la valeur H
i
[i] = 1 j ,= i :: H
i
[j] = 0. La classe Horloge suivante dcrit
lalgorithme des oprations Top et Recaler.
class Horloge {
int[] cpt ; int loc = 0 ;
// Lecture et incrmentation de lhorloge
int[] Top() { int[] hr = cpt.clone() ; cpt[loc]++ ; return hr ; }
void Recaler( int j, int vj ) { /* message issu du processus dindice j */
cpt[loc] = Math.max(cpt[loc],vj + 1) ;
cpt[j] = Math.max(cpt[j],vj) ;
}
// Constructeur : "loc" localise le site de lhorloge
Horloge(int o, int N) {
loc = o; cpt = new int[N] ;
for (int i = 0; i<N; i++) cpt[i]=0; cpt[loc] = 1 ;
}
}
La smantique de Recaler et Top sur une horloge H
i
sexprime sous la forme de triplets de Hoare par :
Lopration Top renvoie la valeur courante de lhorloge et incrmente de 1 llment dindice i.
H
i
= h Top() H
i
[i] = h[i] + 1 j ,= i :: H
i
[j] = h[j]
Lopration Recaler(j, vj) comporte deux paramtres dentre :
dune part, le paramtre j reprsente lindice du processus P
j
metteur du message conduisant
lappel de lopration Recaler ;
dautre part, le paramtre vj reprsente la valeur de llment h
e
[j] datant lvnement dmission e
du message mis par P
j
.
H
i
= h Recaler(j, vj) H
i
[i] = Max(h[i], vj+1) H
i
[j] = Max(h[j], vj) k ,= i, j :: H
i
[k] = h[k]
Enn, les actions de mise jour de ces horloges lors les dirents types dvnements sont les suivantes,
o h
e
dnote la date de lvnement dmission dun message par P
i
et h
r
la date de lvnement de rception
par P
i
dun message m mis par le processus P
j
:
Type dvnement du processus P
i
Action mettant en jeu lhorloge H
i
vnement interne sur i int[] h = H
i
.Top()
mission sur i de m int[] h
e
= H
i
.Top() ;
envoi de < i, h
e
[i], m >;
Rception sur i de < j, vj, m > H
i
.Recaler(j, vj);
mis par P
j
int[] h
r
= H
i
.Top();
Figure A.6 Tableau des actions de mise--jour de lhorloge vectorielle H
i
dun processus P
i
m5
0
P
1
P
2
H
0
H
2
H
1
r1
m1
e1
=
=
=
0
0
0
0
0
0
1
1
1
e3
r3
m4
e4
r4
e5
r5
e2
r2
e6
m6
r6
m2
m3
P
Figure A.7 Chronogramme exemple
Notations
Pour tout vnement e, on note e.p lindice du processus ayant provoqu cet vnement.
La relation classique de causalit est note .
Remarque prliminaire Pour la plupart des questions, utiliser la smantique par triplet de Hoare et
le tableau des actions de la gure A.2 pour donner une schma de preuve de la proprit demande. En
particulier, pour les invariants, montrer que si linvariant est vrai avant une opration Top ou Recaler, celui-
ci est encore vrai aprs lexcution de lopration.
Questions
1. Dcorer le chronogramme de la gure A.7 en prcisant la date aecte par le mcanisme dhorloge
propos chacun des vnements. (Note : vous pouvez utiliser le chronogramme de la gure A.8 en
quatrime page comme support de la rponse.)
2. Montrer que toute horloge H
i
vrie linvariant suivant :
invariant j ,= i :: H
i
[j] < H
i
[i]
3. Montrer que lhorloge dun processus est croissante. Autrement dit, deux vnements distincts e et e
ayant lieu dans le mme processus i et tels que e prcde causalement e
, sont dats par lhorloge H

i
du processus avec des dates croissantes :
invariant e ,= e
: e.p = e
.p = i :: e e
h
e
< h
e
4. On appelle chemin causal C(e

n
) conduisant un vnement e
n
, une suite dvnements e
1
, e
2
, . . . , e
n
vriant la proprit suivante : e

1
e
2
. . . e
n
. La longueur dun chemin causal, note [C(e
n
)[ est
gale au nombre dvnements de la suite.
2
2. Par convention, on admet quun chemin causal C(e) rduit lvnement lui-mme (C(e) = {e}) est donc de longueur 1.
Montrez que, pour tout vnement e dun processus P
e.p
, la valeur de llment h
e
[e.p] du vecteur hor-
loge h
e
datant cet vnement est gale la longueur du (ou des) plus long(s) chemin(s) causal(causaux)
conduisant e. Autrement dit, linvariant suivant est vri :
invariant e : h
e
[e.p] = Max([C(e)[ : C(e))
5. Montrer que ce type dhorloge capte la causalit entre vnements. Autrement dit, si deux vnements
distincts e dat par le vecteur h
e
et e
dat par le vecteur h

e
sont tels que e e
, alors h
e
[e.p] < h
e
[e
.p] :
invariant e ,= e
:: e e
h
e
[e.p] < h
e
[e
.p]
Causalit directe
On introduit la relation de causalit directe, note
m
dans laquelle m dnote un message. Cette relation
est vrie entre deux vnements e et e
ayant lieu dans deux processus distincts si et seulement si il existe

un chemin causal ne comportant quun seul message m entre e et e
. Autrement dit, il existe au moins une

communication de P
e.p
P
e
.p
dans lintervale de temps [e, e
]. titre dexemple, dans le chronogramme de

la gure A.7, on a les relations :
r
1

m4
e
6
, e
1

m1
r
6
, e
1

m6
r
6
, e
1

m2
r
3
Questions
6. Donner, partir du chronogramme de la gure A.7, deux autres exemples dvnements vriant la
relation de causalit directe et deux exemples ne vriant pas cette relation (paires dvnements (e, e
)
tels que (e
m
e

m
e)).
7. Montrez que : e, e
: e.p ,= e
.p :: e
m
e
e e
.
8. Montrer que le systme de datation propos vrie :
invariant e ,= e
: e.p ,= e
.p :: h
e
[e.p] h
e
[e.p] e
m
e
Coupe cohrente
On suppose que les processus, au cours de leur excution, dcident (sparment) de prendre un clich
de leur tat local L[i] en le datant avec lhorloge locale du processus. Ces clichs locaux dats sont ensuite
envoys un processus collecteur. Lorsque celui-ci possde une copie de tous les clichs locaux L[i], il dispose
dun clich global sous la forme du tableau L.
Questions
9. Montrez que le tableau des clichs locaux L[i] constitue un clich global cohrent si aucun des tats
locaux nest causalement li. Autrement dit si :
i ,= j : (L[i].e L[j].e)
o L[x].e dsigne lvnement de prise de clich local sur P
x
.
10. Comment vrier, partir des dates L[i].h des clichs locaux collects, la cohrence du clich global que
ces clichs locaux reprsentent ? Penser utiliser (les proprits de) la causalit directe des questions
(6, 7, 8).
m5
0
P
1
P
2
H
0
H
2
H
1
r1
m1
e1
=
=
=
0
0
0
0
0
0
1
1
1
e3
r3
m4
e4
r4
e5
r5
e2
r2
e6
m6
r6
m2
m3
P
Figure A.8 Chronogramme : complter
A.3 Causalit et horloges de Mattern, Interblocage et terminaison
A.3.1 Causalit et horloges de Mattern (10 points)
Le diagramme de la gure A.9 reprsente le dbut dune excution rpartie. Les premiers vnements
sont dats laide du mcanisme dhorloge de Mattern qui associe tout vnement x un vecteur horloge
H
x
. On note x y la relation de prcdence causale et H
x
< H
y
la relation dordre entre vecteurs horloges.
Questions (2 points par question)
1. Donner tous les chemins causaux dbutant par les vnements origines e
1
ou e
2
et aboutissant
lvnement r
4
dans le diagramme dexcution de la gure A.9. Mme question pour les chemins causaux
dbutant par les vnements origines e
1
ou e
2
mais aboutissant lvnement r
5
.
2. On suppose que lexcution relle a ordonn les vnements dans le temps global rel selon la squence
suivante :
e
1
; e
2
; r
1
; r
2
; e
3
; i
1
; r
3
; e
4
; r
4
; e
5
; i
2
; r
5
Prciser, en le justiant, si cette squence est causalement quivalente celle de la gure A.9. Au-
trement dit, reprsente-t-elle une excution relle quivalente celle prsente dans la gure A.9 ?
3. Complter le diagramme en aectant leur vecteur horloge (leur date) aux vnements non dats.
Figure A.9 Diagramme vnementiel dune excution rpartie
4. Dduire du calcul prcdent si les vnements internes i
1
et i
2
sont causalement lis ou pas.
5. Montrer que, pour deux vnements x de vecteur horloge H
x
et y de vecteur horloge H
y
, si les com-
posantes des deux vecteurs horloges pour un site s vrient H
x
[s] < H
y
[s], alors tout chemin causal
aboutissant x est pass pour la dernire fois sur le site s avant tout chemin causal aboutissant y.
A.3.2 Interblocage et terminaison dans un calcul rparti (11 points)
Figure A.10 Graphe de communication
On considre un calcul rparti compos de N processus (N x et connu) qui communiquent par messages
via des canaux unidirectionnels. Le graphe orient de communication est connu et xe comme dans lexemple
de la gure A.10 comportant 4 processus et 5 canaux. on suppose que tous les processus sont accessibles
partir du processus initial ( au moins un chemin entre le processus initial P
0
et tout autre processus).
Les rgles du calcul rparti constitu par ces N processus sont les suivantes :
Tout processus reoit des messages sur les canaux dentre ;
Chaque processus P
i
doit recevoir un message avant dexcuter une tape ;
Tout processus P
i
, aprs lexcution dune tape envoie systmatiquement un message sur chaque canal
de sortie ;
Au moins un processus puits na pas de canaux en sortie (P
3
dans la gure A.10) ;
Un processus initial (P
0
dans g. A.10) met un message sur ses canaux de sortie pour activer le calcul.
En rsum, le comportement de tout processus participant obit au schma gnrique suivant
3
:
process P(i:0..N-1) {
if (i==0) Emettre un message sur chaque canal de sortie ;
while (true) {
Recevoir un message sur lun des canaux dentre ;
Etape de calcul exploitant le message lu ;
[ Emettre systmatiquement un message sur chaque canal de sortie existant. ]
}
}
Questions (1 point par question)
6. Dans quel modle gnrique de calcul rparti peut-on classer le calcul dcrit prcdemment ?
7. Montrer la proprit stable suivante : si un processus appartenant un cycle de communication (comme,
par exemple, dans la gure A.10, le cycle entre P
0
, P
1
et P
2
) reoit un message, alors il existera dsormais
toujours un message qui circulera sur ce cycle.
8. Montrer que, pour tout cycle de communication, un processus au moins du cycle recevra nalement
un message. En dduire que les processus ne peuvent pas tre interbloqus mme sil existe des cycles
dans le graphe de communication.
9. Montrer, par contre, que le calcul ne peut pas se terminer sil existe au moins un cycle.
3. Un processus puits ne peut videmment pas mettre de message puisquil na pas de canal de sortie.
10. Donner une condition ncessaire et susante du graphe de communication pour que le calcul se termine
en justiant votre proposition.
11. En supposant quil existe un SEUL processus puits, proposer un algorithme de terminaison permettant
ce processus puits de dtecter la terminaison globale du calcul (sil se termine !).
12. Adapter votre solution au cas dun calcul comportant plusieurs processus puits.
13. On considre maintenant que chaque processus attend davoir reu un message de chaque canal den-
tre avant de dbuter une tape de calcul. Montrer que, dans un graphe sans cycle, le calcul est sans
interblocage et se termine. Dans un graphe nayant quun puits, donner le critre trs simple de dtec-
tion de la terminaison en le justiant.
A.4 Clichs et datation
Remarque : Toutes les questions valent 2 points
Prambule
Le problme a pour objectif dtudier les proprits de sret (cohrence) et de vivacit associes au calcul
de clichs globaux partir de clichs locaux ainsi que les relations existant entre prise de clich global et
datation par des horloges vectorielles de Fidge-Mattern. Pour simplier, on ne sintresse ici qu la collecte
dun ensemble de clichs locaux permettant de construire un clich global.
A.4.1 Proprit de sret : cohrence dun clich global (6 points)
Le diagramme de la gure A.11 reprsente le dbut dun calcul rparti sous forme vnementielle. Les 3
processus A, B et C changent des messages applicatifs (de m
1
m
5
) et prennent des clichs locaux de leur
tat courant chaque vnement interne not a
i
, b
i
ou c
i
.
Figure A.11 Calcul rparti sur 3 processus A, B et C
Questions
1. En vous basant sur la notion de coupure, prciser la proprit que doit vrier un clich global construit
partir dun clich local de chacun des processus an que celui-ci soit cohrent.
2. Montrer que le clich global construit partir des clichs locaux a
1
, b
1
, c
2
est incohrent.
3. Montrer que le clich global construit partir des clichs locaux a
2
, b
1
, c
2
est, par contre, cohrent et
prciser le(s) message(s) en transit associ(s) ce clich global.
A.4.2 Datation des clichs locaux (8 points)
On dcide de dater tous les vnements (prises de clichs locaux, missions et rceptions de message) avec
des horloges vectorielles de Fidge-Mattern. On suppose quil existe n processus communicants numrots de 1
n. On note H
i
[1..n] le vecteur horloge local au processus P
i
et e.D[1..n] la date vectorielle de lvnement e.
Au dbut du calcul, les horloges de chaque processus vrient : i : 0 < i n : H
i
[i] = 1(j ,= i : H[j] = 0)
Questions
4. Dans la gure A.11, valuer la date vectorielle associe chaque vnement de prise de clich local
(et exclusivement ceux-ci) et prciser aussi la date surchargeant chaque message envoy de m
1
m
5
.
5. En considrant le clich incohrent construit partir des clichs locaux correspondant aux vnements
(a
1
, b
1
, c
2
), montrer que lincohrence est mise en vidence par les dates des clichs a
1
et b
1
qui vrient :
a
1
.D[1] < b
1
.D[1]
6. En dduire de faon plus gnrale quun clich est cohrent si et seulement si les dates associes aux n
clichs locaux D
i
vrient :
D
1
[1]
. . .
D
i
[i]
. . .
D
n
[n]
= Max(D
1
, . . . , D
i
, . . . , D
n
)
Max(D
1
[1], . . . , D
i
[1], . . . , D
n
[1])
. . .
Max(D
1
[i], . . . , D
i
[i], . . . , D
n
[i])
. . .
Max(D
1
[n], . . . , D
i
[n], . . . , D
n
[n])
(A.1)
7. Peut-on encore vrier la cohrence dun clich global partir des dates des clichs locaux si les seuls
vnements dats sont ces clichs locaux, autrement dit si les vnements dmission et de rception
ne sont pas dats et si les messages ne servent quau recalage ? Justier avec prcision votre rponse.
A.4.3 Proprit de vivacit : collecte de clichs globaux (6 points)
On considre un calcul rparti compos de n processus ne communiquant que par un protocole dchange
dun message jeton via un anneau logique comprenant tous les processus. Pour simplier, on suppose que
cet anneau de communication place les processus dans lordre de leur numrotation : P
1
, . . . , P
i
, . . . , P
n
.
Le processus P
1
dmarre le calcul en mettant le message jeton vers son successeur P
2
. Aprs quoi, tous
les processus ont le mme comportement rptitif : attente de la rception du jeton issu du prdcesseur,
traitement local, puis envoi du jeton vers le successeur. Le processus P
1
peut dcider darrter le calcul en
ne propageant plus le jeton. On ne sintresse pas au contenu du message jeton.
Questions
8. Chaque processus prend un clich local chaque fois quil possde le jeton. Montrer quil est alors
impossible, pour un processus collecteur qui recevrait ces clichs, de construire un clich cohrent.
9. On choisit de prendre les clichs locaux lorsque le processus na pas le jeton. Un clich local est pris
au k-me cycle sil a t pris aprs la k-me visite du jeton. Montrer quun clich global construit avec
les clichs pris lors dun k-me cycle est cohrent et prciser le nombre de message(s) en transit.
10. On suppose maintenant quun protocole causalement ordonn est utilis pour transmettre les clichs
locaux au collecteur. Lors de quels cycles peut-on prendre les clichs locaux pour tre toujours sr
que le collecteur reoit des sries de n clichs locaux conscutifs, chaque srie contenant des clichs
appartenant au mme cycle et constituant un clich global cohrent ?
Question Bonus (1 point)
Comment pourrait-on assurer trs simplement que le collecteur dtecte (sait) que le calcul est termin ?
A.5 Flux multimedia et agents mobiles
A.5.1 Quelques problmes de causalit entre ux multimedia
On considre une application changeant des ux multimedia de type MPEGx par exemple. Un site A
diuse un ux vido vers 2 autres sites B et C. Aprs avoir reu le dbut du ux mis par A, le site B met
un ux son tour (ux audio par exemple) vers les sites A et C. Le chronogramme de la gure (A.12) donne
une vision vnementielle du droulement de lexcution rpartie en ne conservant que les vnements de
dbut et n de ux quil sagisse dun ux en mission ou dun ux en rception.
A.f2
C.f2
B.d2
C.f1 C.d2 C.d1
A.d1
B.d1
C
B
A
B.f2
A.d2 A.f1
B.f1
Figure A.12 Vision vnementielle des ux
Questions
1. Sur le chronogramme de la gure (A.12), les paires dvnements suivants sont-elles lies par la relation
de causalit : (A.d1, B.d2), (A.f1, B.f2), (A.d2, B.f2), (A.d2, C.f1) ? Justiez vos rponses.
Rponse
A.d1 B.d2 car A.d1 B.d1 B.d1 B.d2
A.f1 | B.f2 car (A.f1 B.f2 B.f2 A.f1)
A.d2 | B.f2 car (A.d2 B.f2 B.f2 A.d2)
A.d2 C.f1 car A.d2 A.f1 A.f1 C.f1
2. Montrer que la rception des ux 1 et 2 sur le site C prsente une anomalie par rapport la causalit
en ce qui concerne leur dbut.
Rponse Le site C voit le ux 2 commencer avant le ux 1 alors que le site B a vu dbuter le ux 1
avant de commencer la diusion du ux 2.
Cette anomalie se traduit en terme de causalit par : A.d1 B.d2 C.d2 C.d1
3. Un protocole ordonn pourrait-il corriger cette anomalie sur lordre de dmarrage des ux sur le site
de rception C? Justiez votre rponse.
Rponse Oui, puisquil assurerait : A.d1 B.d2 C.d1 C.d2. Les vnements C.d1 et C.d2
sont alors les vnements de dlivrance du premier message de chaque ux au niveau applicatif.
4. De faon similaire, la gure A.12 montre que les ns de ux sur les sites A et B se produisent dans un
ordre dirent : sur A, la n de lmission A.f1 du ux 1 prcde la n de la rception A.f2 du ux 2
et sur B, la n de lmission B.f2 du ux 2 prcde la n de la rception B.f1 du ux 1. Montrez que
malgr cette inversion, aucune anomalie causale nexiste.
Rponse Il ny a pas danomalie causale puisquil ny a pas de relation causale entre les vnements
de n dmission de ces deux ux : A.f1 | B.f2.
5. Dans le chronogramme tudi, la question prcdente conduit considrer que la n de rception des
ux 1 et 2 sur le site C peut se produire dans nimporte quel ordre. Modier le chronogramme pour
obtenir une situation o la rception des ux 1 et 2 devrait tre forcment ordonne comme dans le
chronogramme fourni (dans lequel C.f2 C.f1) sans provoquer danomalie causale.
Rponse Le chronogramme ci-dessous introduit une causalit entre la n des missions des 2 ux,
en loccurrence B.f2 A.f1.
A.d2
C.f2
B.d2
C.f1 C.d2 C.d1
A.d1
B.d1
C
B
A
A.f1 A.f2
B.f2
B.f1
Figure A.13 Terminaison causalement ordonne des 2 ux
A.5.2 Rencontres entre agents mobiles
On considre une application rpartie base dagents mobiles. Ces agents se rencontrent pour changer
des informations lorsquils se trouvent simultanment sur le mme site
4
. Une telle rencontre est considre
comme atomique et ralise toujours entre une paire dagents
5
.
La gure (A.14) illustre le dplacement et les rencontres de tels agents dsigns par A, B, C, . . .
S3
A
B
C
D
B
D
A
C
(B,C) (A,B)
(A,C)
(A,C)
(A,C)
(A,D)
(C,D)
S0
S1
S2
Figure A.14 Rencontres dagents mobiles sur des sites
On se propose de tracer des informations sur les rencontres qui ont lieu durant lexcution des agents.
Pour cela, on peut envisager de collecter des informations soit sur les sites de rencontre, soit dans le contexte
local de chaque agent. On sintresse plus particulirement la datation des rencontres.
Trace sur les sites
On mmorise sur chaque site les dates des rencontres qui ont eu lieu. Le mcanisme de datation sinspire
du systme de datation de Mattern. Une date est reprsente par un vecteur de dimension N o N est le
nombre de sites. Chaque site possde une horloge vectorielle H
i
dote dune opration permettant de dater
4. On ne sintresse pas leurs communications ventuelles distance.
5. Un agent peut par contre rencontrer successivement plusieurs agents avant de se dplacer vers un autre site.
les rencontres et les agents vont transporter un vecteur courant unique reprsentant la date de leur dernire
rencontre. On veut que la smantique dune date T aecte une rencontre sur un site i
0
soit la suivante :
invariant (i ,= i
0
: T[i] = Card(R
i
)) T[i
0
] = Card(R
i0
) + 1
dans lequel lensemble R
i
contient tous les vnements de rencontre ayant eu lieu sur le site i et qui prcdent
causalement la rencontre date T. titre dexemple, la date T aecte la rencontre (A, D) sur le site S
1
devrait tre le vecteur T = (2, 2, 2, 1).
Initialement, lhorloge H
i
dun site S
i
est initialise zro : j :: H
i
[j] = 0. La classe Horloge suivante
possde une seule opration Dater qui ne sert qu dater les vnements de rencontre.
class Horloge {
int cpt[]; int loc; // "loc" localise le site de lhorloge
// Datation dune rencontre
public int[] Dater( int T1[], int T2[] ) { ... }
public Horloge(int o, int N) {
loc = o; cpt = new int[N] ;
for (int i = 0; i<N; i++) cpt[i]=0 ;
}
}
La smantique de Dater comporte deux paramtres dentre, en loccurrence les deux vecteurs horloges
transports par les agents participant la rencontre.
Questions
6. Donner sous forme dun triplet de Hoare, la smantique de Dater : H
i
.cpt = h H
i
.Dater(T1, T2). . .
et programmer lopration Dater dans la classe Horloge.
Rponse La date de la rencontre est un vecteur ayant pour lments le maximum de chaque vecteur
et du vecteur courant du site sauf pour llment i qui comptabilise la nouvelle rencontre partir de
la valeur courante de llment i de lhorloge locale.
6
H
i
.cpt = h
H
i
.Dater(T1, T2)
(k ,= i : H
i
.cpt[k] = max(h[k], T1[k], T2[k])) H
i
.cpt[i] = h[i] + 1
Lopration Dater est donc :
public int[] Dater( int T1[], int T2[] ) {
for (int i = 0; i<cpt.length; i++) cpt[i]=max(cpt[i],T1[i],T2[i]) ;
cpt[loc]++ ;
int[] res = new int[cpt.length]; System.arraycopy(cpt,0,res,0,cpt.length);
return res ;
}
7. Dcorer la gure avec les dates aectes aux rencontres en utilisant la feuille fournie en annexe.
Rponse Les dates obtenues sont :
6. On a toujours pour une rencontre sur le site i : H
i
.cpt[i] T1[i] H
i
.cpt[i] T2[i].
[0,0,1,0]
B
C
D
B
D
A
C
(C,D)
S0
S1
S2
S3
A (A,B)
(A,D)
[2,2,2,1]
[1,1,1,1]
(A,C)
[1,1,2,1]
[1,1,1,0]
(A,C)
(B,C)[1,0,1,0] [2,1,2,1]
(A,C)
Trace dans les agents
Cette fois-ci, chaque agent a transporte une horloge vectorielle locale H
a
(horloges embarques dans les
agents). Chaque horloge locale est initialise zro : a Agents : i 1..M : H
a
[i] = 0. Une date est
donc reprsente par un vecteur de dimension M o M est le nombre dagents
7
. Par contre, les sites nont
plus dhorloges locales. On doit donc trouver une implantation dirente de lopration Dater. On suppose
que chaque agent fournit en paramtre lopration Dater son indice et son vecteur horloge local. La classe
Datation dnit la nouvelle opration Dater :
class Datation {
// Datation dune rencontre
static public int[] Dater(int a, int Ha[], int b, int Hb[]) { ... }
}
On veut que la smantique dune date T aecte une rencontre entre un agent a et un agent b soit la
suivante :
invariant (k ,= a, b : T[k] = Card(R
k
)) T[a] = Card(R
a
) + 1 T[b] = Card(R
b
) + 1
dans lequel un ensemble R
x
contient tous les vnements de rencontre auxquels lagent x a particip et qui
prcdent causalement la rencontre date T. titre dexemple, la date T aecte la rencontre (A, C) sur
le site S
1
devrait tre le vecteur T = (2, 1, 3, 0).
Questions
8. En dsignant, dans la postcondition, le vecteur date rsultat par T
r
, donner sous forme dun triplet de
Hoare, la smantique de Dater :
H
a
= h
a
H
b
= h
b
Datation.Dater(a, Ha, b, Hb). . .
et programmer lopration Dater dans la classe Datation.
Rponse La solution consiste prendre une nouvelle fois le maximum des lments de chaque vecteur
et incrmenter de un les deux lments concernant les agents de la rencontre :
H
a
= h
a
H
b
= h
b
Datation.Dater(a, Ha, b, Hb)

i ,= a, b : T
r
[i] = max(h
a
[i], h
b
[i]) T
r
[a] = h
a
[a] + 1 T
r
[b] = h
b
[b] + 1
Lopration Dater correspondante est la suivante
8
:
7. On suppose que le nombre maximum dagents est connu pour simplier et conserver des vecteurs.
8. On remarque que, comme pour lopration Dater prcdente, on a : k : Ha[a] H
k
[a] H
b
[b] H
k
[b]
static public int[] Dater(int a, int Ha[], int b, int Hb[] ) {
int[] res = new int[Ha.length];
for (int i = 0; i<Ha.length; i++) res[i]=max(Ha[i],Hb[i]) ;
Ha[a]++ ; Hb[b]++ ;
return res ;
}
9. Montrer que lon a linvariant :
invariant T : (
x=M
x=1
T[x])/2 = nr
T
+ 1
dans lequel le terme nr
T
est gal au nombre total de rencontres (quel que soit les participants) qui
prcdent causalement la rencontre date par T.
Pour cela, montrer que si le prcidat invariant est vrai avant lexcution dune opration Dater, il est
encore vrai prs lexcution de lopration.
Rponse Daprs la smantique de lopration Dater, on a, puisque les lments H
a
[a] et H
b
[b] sont
maximaux :
x=M
x=1
T[x] =
x=M
x=1
max(H
a
[x], H
b
[x]) + 2
Il reste donc prouver que :
2 nr
T
=
x=M
x=1
max(H
a
[x], H
b
[x])
Pour les lments H
a
[a] et H
b
[b], nous avons vu que :
max(H
a
[a], H
b
[a]) = H
a
[a] et max(H
b
[b], H
a
[b]) = H
b
[b]
Ces compteurs comptabilisent donc le nombre de rencontres de lagent A (resp. B) avec nimporte quel
autre agent, rencontres causalement antrieures la rencontre courante.
Les lments max(H
a
[x], H
b
[x]), x ,= a, b enregistrent les rencontres de lagent X perues par les agents
A ou B. Supposons que lagent A a enregistr H
a
[x] rencontres de X et lagent B a enregistr H
b
[x],
avec par exemple H
a
[x] < H
b
[x].
Puisque TOUTES les rencontres successives de lagent X avec les autres sont causalement lies, cela
signie simplement que lagent B a rencontr X aprs lagent A et que les rencontres de X avec A sont
donc toutes dj comptabilises. En tout tat de cause, il sut donc de prendre le maximum des deux
lments pour capter exactement le nombre de rencontres de lagent X qui prcdent cette rencontre
entre A et B.
10. Dcorer la gure avec les dates aectes aux rencontres en utilisant la feuille fournie en annexe.
Rponse Les dates de rencontre obtenues avec des horloges dans les agents sont :
[5,2,5,2]
B
C
D
B
D
A
C
(A,C)
(A,D)
(C,D)
S0
S1
S2
S3
A (B,C) (A,B)
(A,C)
(A,C)
[2,1,3,0]
[1,0,1,0]
[1,1,2,0]
[2,1,4,1]
[3,1,5,1]
[4,2,5,1]
A.6 Datation causale et simulation rpartie
A.6.1 Causalit et horloges de Mattern (10 points)
Figure A.15 Diagramme vnementiel dune excution rpartie
Le diagramme de la gure A.15 reprsente le dbut dune excution rpartie. Les premiers vnements
sont dats laide du mcanisme dhorloge de Mattern qui associe tout vnement x un vecteur horloge
H
x
. On note x y la relation de prcdence causale et H
x
< H
y
la relation dordre entre vecteurs horloges.
1. Complter le diagramme en aectant leur vecteur horloge (leur date) aux vnements non dats.
2. Trouver un plus court et un plus long chemin causal menant de lvnement e
1
lvnement r
5
.
3. Montrer que la somme des lments dun vecteur H
x
associ un vnement x fournit une borne
suprieure au plus long chemin causal possible conduisant cet vnement partir du dbut du calcul.
4. Donner la condition ncessaire et susante qui doit tre vrie par les vecteurs horloges pour quun
vnement z soit sur un chemin causal allant dun vnement x un vnement y.
5. En supposant connus lensemble des vnements et leurs vecteurs horloges, dduire un algorithme pour
trouver tous les chemins causaux entre un couple donn dvnements (x, y).
A.6.2 Simulation parallle du trac arien (10 points)
On considre la simulation du trac arien entre des aroports. Chaque aroport est simul par un
simulateur particulier qui peut donc sexcuter en parallle avec les simulateurs des autres aroports et
communiquer par messages avec eux. On suppose que les interactions entre les aroports sont rduites aux
vols des avions modliss, dcrits par deux vnements dats dans un temps global commun, en loccurrence,
lvnement de dcollage dun aroport et lvnement datterrissage dans un autre (ou le mme) aroport.
Chaque simulateur progresse dans sa simulation en engendrant des vnements de dcollage et en enre-
gistrant des vnements datterrissage. Une horloge locale chaque simulateur indique la date du dernier
vnement trait. Un simulateur daroport contrle ses envols locaux et calcule une date datterrissage future
de chaque vol : plus prcisment, lorsquun simulateur engendre un vnement de dcollage, il calcule aussi
la date de lvnement datterrissage correspondant et il envoie un message contenant les informations rela-
tives cet vnement (notamment sa date) au simulateur de laroport sur lequel lavion concern atterrira
(cest--dire au simulateur devant traiter lvnement datterrissage).
La gure A.16 reprsente la simulation de trois aroports avec 6 vols (V
1
, . . . , V
6
) et les paires dvnements
de dcollage et atterrissage correspondants.
Excution de la simulation La simulation est dcoupe en pas successifs excuts en parallle par chaque
simulateur. Un nouveau pas de simulation i + 1 ne peut commencer que lorsque tous les simulateurs ont
Figure A.16 Diagramme de simulation du trac arien entre 3 aroports
termin le pas courant i de simulation. Le problme consiste trouver la dure de ces pas de simulation, pour
chacun des simulateurs, de faon garantir une simulation globale cohrente dans laquelle chaque simulateur
traite les vnements dans leur ordre croissant de datation de faon sre sans retour arrire.
Par exemple, si le simulateur (de laroport) A
1
sexcute en parallle avec le simulateur A
0
, il ne faut
pas que ce simulateur A
1
fasse voluer la simulation de cet aroport au-del de la date de latterrissage a
1
avant quil nait eu connaissance de cet vnement : autrement-dit, le simulateur A
0
doit avoir auparavant
engendr lvnement de dcollage d
1
et lvnement datterrissage a
1
, puis envoy le message concernant
latterrissage a
1
et ce message doit tre parvenu au simulateur A
1
. En eet, sinon, le simulateur A
1
aurait
connaissance de lvnement a
1
trop tard et devrait revenir en arrire dans sa simulation.
6. Expliquer pourquoi lensemble des vnements (d
v
, a
v
) dune simulation est assimilable une excution
rpartie modlise de faon vnementielle ;
7. En vous basant sur le diagramme de la gure ??, prcisez, partant de linstant initial, jusqu quel
vnement limite inclus, de leur simulation, chacun des simulateurs (A
0
, A
1
, A
2
) peut sexcuter en
parallle avec les autres sans risquer doublier certains vnements.
8. En supposant que chaque simulateur sest excut jusqu ces points limites, donner de faon similaire
le prochain pas excutable (deuxime pas) par chaque simulateur.
9. Dans les deux pas de simulation des questions prcdentes, vrier que tout ensemble dvnements
i
contenant les vnements traits durant le i-ime pas de simulation parallle vrie la proprit :
i : (d
v
, a
v
) : d
v

i
a
v
/
i
10. On suppose, maintenant, que lon connat la dure minimale m dun vol, quel que soit laroport de
dcollage. Montrer que lon peut en dduire une dure de pas de simulation xe et commune tous
les simulateurs garantissant des pas de simulation vriant la proprit prcdente et donc assurant
une simulation parallle sans risque de retour arrire.
Bibliographie
[1] J.C.M. Baeten and W.P. Weijland. Process Algebra, volume 18. Cambridge Tracts in Theoritical
Computer Science, Cambridge University Press, 1990.
[2] Michel Bantre and Peter A. Lee, editors. Hardware and Software Architectures for Fault Tolerance,
volume 774 of Lecture Notes in Computer Science. Springer-Verlag, 1994.
[3] Kenneth P. Birman. The process group approach to reliable distributed computing. Communications
of the ACM, 36(12) :3753, December 1993.
[4] Kenneth P. Birman. Building secure and reliable network applications. Manning, 1996.
[5] Kenneth P. Birman, Robert Cooper, T. Joseph, Keith Marzullo, , Messac Makpangou, K. Kane, Frank
Schmuck, and Mark Wood. The ISIS System Manual, Version 2.1. Cornell University, 2.1 edition,
September 1990.
[6] Kenneth P. Birman and Bradford Glade. Consistent failure reporting in reliable communications sys-
tems. Technical Report 93-1349, Cornell University, May 1993.
[7] Kenneth P. Birman and Robbert van Renesse, editors. Reliable Distributed Computing with the Isis
Toolkit. IEEE Computer Society Press, 1994.
[8] Jerszy Brzezinski, Jean-Michel Hlary, Michel Raynal, and Mukesh Singhal. Deadlock models and a
general algorithm for distributed deadlock detection. Journal of Parallel and Distributed Computing,
31 :112125, 1995.
[9] T.D. Chandra, V Hadzilacos, and S. Toueg. The weakest failure detector for solving concensus. Journal
of ACM, 43(4) :685722, 1996.
[10] Edsger W. Dijkstra and Carel S. Scholten. Termination detection for diusing computations. Informa-
tion Processing Letters, 11(4) :14, 1980.
[11] E.W.D. Dijkstra and C.S. Scholten. Termination detection for diusing computations. Information
Processing Letters, 11(4) :14, 1980.
[12] M. Fischer, N. Lynch, and M Paterson. Impossibility of distributed consensus with one faulty process.
Journal of ACM, 32(2) :374382, April 1985.
[13] Michael J. Fischer, Nancy A. Lynch, and Michael Merritt. Easy impossibility proofs for distributed
consensus problems. Distributed Computing, 1(1) :2639, January 1986.
[14] C. A. R. Hoare. Communicating Sequential Processes. Prentice-Hall International, 1984.
[15] D. LeVerrand. Le Langage Ada : Manuel dvaluation. Dunod Informatique, 1982.
[16] Mesaac Makpangou and Kenneth P. Birman. Designing application software in wide area network
settings. Technical Report 90-1165, Cornell University, October 1990.
[17] F. Mattern. Algorithms for distributed termination detection. Distributed Computing, 2 :161175, 1987.
[18] F. Mattern. Virtual time and global states of distributed systems. In Proceedings of the International
Conference on Parallel and Distributed Computing, pages 215226. North-Holland Inc., 1988.
[19] R. Milner. A Calculus of Communicating Systems, volume 92 of Lecture Notes in Computer Science.
Springer Verlag, 1980.
105
[20] M. Nami and M. Trehel. Un algorithme distribu dexclusion mutuelle en log(n). Technique et Science
Informatiques, 6(2) :141150, 1987.
[21] B.J. Nelson. Remote Procedure Call. PhD thesis, DCS Carnegie Mellon University, 1981.
[22] M. Raynal. Dtection rpartie de la terminaison. In Synchronisation et tat global dans les systmes
rpartis, pages 157172. Editions Eyrolles, 1992.
[23] M. Raynal. Synchronisation et tat global dans les systmes rpartis. Editions Eyrolles, 1992.
[24] Michel Raynal. Algorithmes Distribus et Protocoles. Eyrolles, 1985.
[25] Michel Raynal. Gestion des Donnes Rparties : Problmes et Protocoles. Collection Direction tudes-
Recherches EDF. Edition Eyrolles, 1992.
[26] Robbert van Renesse, Kenneth P. Birman, Roy Friedman, Mark Hayden, and David A. Karr. A frame-
work for protocol composition in Horus. In 14th Symposium on Principles of Distributed Computing,
pages 8089. ACM, August 1995.
[27] Robbert van Renesse, Kenneth P. Birman, Mark Hayden, Alexey Vaysburd, and David Karr. Building
adaptative systems using Ensemble. Technical Report 97-1638, Cornell University, 1997.
[28] Robbert van Renesse, Kenneth P. Birman, and Silvano Maeis. Horus : A exible group communications
system. Communications of the ACM, 39(4) :7683, April 1996.
[29] Aleta Ricciardi, Andr Schiper, and Kenneth P. Birman. Understanding partitions and the no partition
assumption. In 4th Workshop on Future Trends Of Distributed Computing Systems, pages 354360,
Lisboa, Portugal, September 1993. IEEE.
[30] A. Schiper. Early concensus in an asynchronous system with weak failure detector. Distributed Com-
puting, 10(3) :149157, 1997.
[31] Gerard Tel and Friedmann Mattern. The derivation of distributed termination detection algorithms from
garbage collection schemes. ACM Transactions on Programming Languages and Systems, 15(1) :135,
jan 1993.
[32] H. Zimmermann, J-S. Banino, A. Caristan, M. Guillemont, and G. Morisset. Basic concepts for the
support of distributed systems : the chorus approach. In IEEE, editor, 2nd international conference on
distributed computing systems, pages 6066, April 1981.

Livre SR

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Livre SR

Încărcat de

Drepturi de autor:

Formate disponibile

Prcis de rpartition

Dpartement Informatique et Mathmatiques appliques

) issu dun mme processus, tel que e prcde e

est potentiellement la consquence de e. Un intrt de lordre

pour le distinguer du cas

date(e) < date(e

. Cest ce que les horloges

3. Montrer sur un exemple, que le mcanisme prcdent nassure pas la rciproque :

4. Montrer que les horloges de Mattern assurent :

seront retards puisque les vecteurs associs ces messages

Le chronogramme de la gure (4.8) montre lvolution du calcul sur un exemple simple.

si P attend un message issu de P

. On remarquera que cette interprtation implique de

est encore venir alors que dans la ralit lvnement r

a eu lieu avant e. Ceci na

vriant la proprit suivante : e

ayant lieu dans le mme processus i et tels que e prcde causalement e

, sont dats par lhorloge H

4. On appelle chemin causal C(e

vriant la proprit suivante : e

dat par le vecteur h

ayant lieu dans deux processus distincts si et seulement si il existe

. Autrement dit, il existe au moins une

]. titre dexemple, dans le chronogramme de

Datation.Dater(a, Ha, b, Hb)

S-ar putea să vă placă și