Variété de la cohérence dans les systèmes...

HABILITATION À DIRIGER LES RECHERCHES

de l'Institut National Polytechnique de Toulouse

Spécialité : informatique

Philippe Quéinnec

Université de Toulouse - IRIT / INPT

Variété de la cohérence

dans les systèmes répartis

Soutenue le 20 mai 2011 devant le jury composé de :

Dominique Méry Professeur Université Henri Poincaré Nancy 1 rapporteur

Olivier Roux Professeur École Centrale de Nantes rapporteur

André Schiper Professeur École Polytechnique Fédérale de Lausanne rapporteur

Mamoun Filali Chargé de recherche du CNRS examinateur

François Vernadat Professeur INSA de Toulouse examinateur

Gérard Padiou Professeur Institut National Polytechnique de Toulouse correspondant INPT

Cause mutation aède vend fonds. Vieillesformes, odes, ballades, lais, distiques, lots devers dépareillés (dont certains blancs), rimes

en vrac. Ne se détaille pas.

Pierre Bazantay499 Annonces (petites)

annonce n�354

Le jeu de la science est en principe sans �n. Celui-là se retire du jeuqui décide un jour que les énoncés scienti�ques ne requièrent pas de test

ultérieur et peuvent être considérés comme dé�nitivement véri�és.

Karl R. PopperLa logique de la découverte scienti�que

chapitre II, � Le problème d'une théorie de la méthode scienti�que �

i

Avant-propos

Ce mémoire est constitué de deux parties. La première partie est intitulée � Synthèse desactivités �. Elle contient un curriculum vitae général, tant d'un point de vue enseignement qued'un point de vue activités administratives, et une présentation sommaire de mes travaux derecherche.

La deuxième partie est un exposé scienti�que détaillé de mes travaux de recherche ayant portésur les notions de cohérences dans les systèmes répartis. Les points présentés sont :

� cohérence de données multimédias : comment di�user un ensemble de �ux multimédiaspour que, sur le récepteur �nal, les �ux soient correctement coordonnés.

� conservation des dépendances : quand un ensemble de données sont indépendamment dé-rivées à partir d'une même donnée source, cet ensemble doit pouvoir être reconstruit enréférence à la même valeur source, alors même que les données dérivées suivent des cheminsde transmission indépendants.

� cohérence temporelle : comment introduire des contraintes temporelles dans une descriptionde type �ots de données, pour obtenir des propriétés de cohérence globale à l'ensemble d'unsystème.

iii

Remerciements

Je remercie les rapporteurs de ce mémoire, Dominique Méry, professeur à l'université HenriPoincaré de Nancy, Olivier Roux, professeur à l'École Centrale de Nantes, et André Schiper,professeur à l'École Polytechnique Fédérale de Lausanne, pour leur lecture attentive du manus-crit et pour les commentaires qui en découlent. Je remercie aussi Mamoun Filali, chargé derecherche du CNRS, et François Vernadat, professeur à l'INSA de Toulouse. d'avoir acceptéd'être examinateurs de ce travail.

J'adresse mes plus vifs remerciements à Gérard Padiou, professeur à l'INPT, correspondantINPT de cette HDR, autrefois directeur de ma thèse et aujourd'hui collègue mais toujours direc-teur (du département). Je le remercie aussi pour ses encouragements discrets mais permanents,ainsi que pour son intérêt aux directions les plus farfelues que je prenais.

La présence dans mon jury de Mamoun Filali était une évidence, étant un axiome de mestravaux de recherche : ceux-ci n'existeraient pas, ou sous une forme bien plus quelconques, sansla rigueur et l'originalité de pensée que m'a montrées Mamoun tout au long des années où nousnous sommes côtoyés. C'est aussi de lui que je tiens la nécessité de démontrer toute évidence etque 1 + 1 n'égale 2 que sous certaines conditions 1.

Je n'oublie pas la part qui revient aux thésards avec qui j'ai collaboré. Par leurs idées et leursquestionnements, leur apport est indéniable et je mesure la chance que j'ai eu de travailler aveceux. Je remercie chaleureusement Michel Charpentier, Romulus Grigora³, Cezar Ple³ca,Tanguy Le Berre, Nadège Pontisso.

Un mot de remerciement aussi pour les collègues de l'équipe et du laboratoire qui m'ontsupporté 2 toutes ces années. En premier lieu, Philippe Mauran, qui m'a appris la procrastina-tion (et en contre-partie, l'anticipation), ainsi qu'une analyse critique de mes connaissances ensystèmes opératoires et distribués ; Marc Pantel dont la présence (ou l'absence) m'a accompa-gné dans ma vision du métier d'enseignant-chercheur ; Aurélie Hurault pour sa disponibilitéen période de doute ; Xavier Thirioux pour remettre sans cesse en cause ma prétention demaîtriser un sujet théorique ; Xavier Crégut pour son calme permanent ; Romulus Grigora³et Vincent Charvillat avec qui j'ai compris que le multimédia était bien plus qu'un problèmed'ordonnancement ou de performance.

En�n, mes remerciements personnels relèvent du domaine privé et n'ont pas leur place dansce document public.

1. Par exemple, se placer dans le monoïde (Nat ,+, 0).2. À tous les sens du mot.

v

Table des matières

I Synthèse des activités 1

1 Curriculum vitæ 31.1 En bref . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1.1 Coordonnées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.1.2 Diplômes et parcours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Activités d'enseignement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2.1 Responsabilité d'enseignements . . . . . . . . . . . . . . . . . . . . . . . . 41.2.2 Participation à d'autres enseignements . . . . . . . . . . . . . . . . . . . . 5

1.3 Activités collectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.3.1 Formation par apprentissage . . . . . . . . . . . . . . . . . . . . . . . . . 61.3.2 Jurys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.3.3 Conseils et commissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.3.4 Divers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.4 Activités de recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.4.1 Encadrements de thèses . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.4.2 Collaborations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.4.3 Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Synthèse des activités de recherche 132.1 Équipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2 La cohérence dans les systèmes répartis . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.1 Cohérence mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.2 État global cohérent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2.3 Réplication de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2.3.1 Indicateurs (hints) . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2.3.2 Caches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.2.3.3 Copies multiples . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.2.3.4 Le compromis CAP . . . . . . . . . . . . . . . . . . . . . . . . . 192.2.3.5 Réplication optimiste . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2.4 Base de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.3 Nos contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.3.1 Approches spéci�ques à la cohérence . . . . . . . . . . . . . . . . . . . . . 212.3.2 Aspects formels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.4 Quelques autres contributions liées à la répartition . . . . . . . . . . . . . . . . . 222.4.1 Réseaux ad hoc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.4.2 Mobilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.4.2.1 Formalisation de la mobilité . . . . . . . . . . . . . . . . . . . . 25

vii

2.4.2.2 Reconstruction d'une exécution mobile . . . . . . . . . . . . . . 262.4.3 Simulation parallèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

II Données, répartition et cohérence 29

3 Introduction 31

4 Flux multimédias coordonnés 334.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.2 Cohérence dans les systèmes multimédias répartis . . . . . . . . . . . . . . . . . . 33

4.2.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.2.2 Cohérence et synchronisation usuelles . . . . . . . . . . . . . . . . . . . . 354.2.3 Synchronisation de groupe . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.2.3.1 Approches basées sur des horloges synchronisées . . . . . . . . . 354.2.3.2 Approches basées sur la connaissance des délais réseau . . . . . 364.2.3.3 Approches basées sur le temps virtuel . . . . . . . . . . . . . . . 37

4.2.4 Spéci�cation des relations temporelles . . . . . . . . . . . . . . . . . . . . 374.2.4.1 Temps linéaire/non linéaire/à ordre partiel . . . . . . . . . . . . 384.2.4.2 Spéci�cation à base d'instants . . . . . . . . . . . . . . . . . . . 394.2.4.3 Spéci�cation à base d'intervalles . . . . . . . . . . . . . . . . . . 394.2.4.4 Spéci�cation à base d'opérateurs dédiés . . . . . . . . . . . . . . 404.2.4.5 Spéci�cation à base d'automates . . . . . . . . . . . . . . . . . . 40

4.3 Flux et causalité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.3.1 Dé�lement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.3.2 Relations causales entre dé�lements . . . . . . . . . . . . . . . . . . . . . 41

4.3.2.1 Relations de précédence . . . . . . . . . . . . . . . . . . . . . . . 424.3.2.2 Propriétés entre relations . . . . . . . . . . . . . . . . . . . . . . 44

4.3.3 Inventaire exhaustif des relations . . . . . . . . . . . . . . . . . . . . . . . 454.3.3.1 Les relations de précédence . . . . . . . . . . . . . . . . . . . . . 454.3.3.2 Propriétés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.3.3.3 Ordres et pré-ordres . . . . . . . . . . . . . . . . . . . . . . . . . 474.3.3.4 Retour à l'ordre . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.3.4 Ensemble de dé�lements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.3.5 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.3.5.1 Dynamicité des intervalles . . . . . . . . . . . . . . . . . . . . . 504.3.5.2 Événement d'annulation . . . . . . . . . . . . . . . . . . . . . . . 50

4.4 Travaux similaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.4.1 Lamport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.4.2 Kshemkalyani . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.5 Communications multimodales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.5.1 Approches existantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.5.1.1 Protocoles ordonnés . . . . . . . . . . . . . . . . . . . . . . . . . 554.5.1.2 Adaptations des protocoles causaux . . . . . . . . . . . . . . . . 57

4.5.2 Délivrance multimodale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.5.3 Mise en ÷uvre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

viii

5 Association cohérente de données 635.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635.2 Dé�nition informelle de la cohérence . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.2.1 Cohérence stricte des données . . . . . . . . . . . . . . . . . . . . . . . . . 645.2.2 Cohérence relâchée des données . . . . . . . . . . . . . . . . . . . . . . . . 66

5.3 Cohérence dans les bases de données . . . . . . . . . . . . . . . . . . . . . . . . . 675.3.1 Cohérence temporelle individuelle . . . . . . . . . . . . . . . . . . . . . . 675.3.2 Cohérence mutuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.4 Graphe et fuseaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705.4.1 Chemins et chemins séparés . . . . . . . . . . . . . . . . . . . . . . . . . . 705.4.2 Fuseaux : con�gurations problématiques . . . . . . . . . . . . . . . . . . . 705.4.3 Fuseaux imbriqués, fuseau principal . . . . . . . . . . . . . . . . . . . . . 72

5.5 Formalisation de la cohérence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735.5.1 Relation d'in�uence directe . . . . . . . . . . . . . . . . . . . . . . . . . . 735.5.2 Relation d'in�uence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.5.3 Passé d'in�uence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.5.4 Cohérence stricte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.5.5 Cohérence relâchée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.5.6 In�uence entre données . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.6 Codage de la relation d'in�uence . . . . . . . . . . . . . . . . . . . . . . . . . . . 765.6.1 Marquage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765.6.2 Estampille . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765.6.3 Composants marqueurs et contrôleurs . . . . . . . . . . . . . . . . . . . . 795.6.4 Élimination des marquages inutiles . . . . . . . . . . . . . . . . . . . . . . 795.6.5 Cohérence relâchée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5.7 Formalisation en TLA+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805.7.1 Les modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805.7.2 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

5.8 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815.8.1 Systèmes monopériodiques . . . . . . . . . . . . . . . . . . . . . . . . . . 83

5.8.1.1 Modèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835.8.1.2 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

5.8.2 Systèmes multipériodiques . . . . . . . . . . . . . . . . . . . . . . . . . . . 835.8.2.1 Modèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845.8.2.2 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845.8.2.3 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

5.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

6 Flots de données à contraintes temporelles 896.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 896.2 Outils pour la spéci�cation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

6.2.1 Système de transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906.2.2 La relation d'observation . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

6.2.2.1 Dé�nition de l'observation . . . . . . . . . . . . . . . . . . . . . 906.2.2.2 Sémantique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916.2.2.3 L'observation comme élément de modélisation . . . . . . . . . . 926.2.2.4 Architecture d'un système . . . . . . . . . . . . . . . . . . . . . 926.2.2.5 Chemins de propagation . . . . . . . . . . . . . . . . . . . . . . . 936.2.2.6 Horloges équivalentes . . . . . . . . . . . . . . . . . . . . . . . . 93

ix

6.2.3 Le temps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 946.2.4 Pro�l temporel d'une variable . . . . . . . . . . . . . . . . . . . . . . . . . 956.2.5 Dichotomie état-transition . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

6.3 Spéci�cation temporelle par l'observation . . . . . . . . . . . . . . . . . . . . . . 966.3.1 Comportement temporel d'une variable . . . . . . . . . . . . . . . . . . . 97

6.3.1.1 Sporadicité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 976.3.1.2 Périodicité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

6.3.2 Comportement temporel d'un chemin de propagation . . . . . . . . . . . 976.3.2.1 Forme générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 986.3.2.2 Les prédicats temporels . . . . . . . . . . . . . . . . . . . . . . . 98

6.4 Véri�cation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1016.4.1 Régime initial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

6.4.1.1 Dé�nition du régime initial . . . . . . . . . . . . . . . . . . . . . 1026.4.1.2 Conditions su�santes à la sortie du régime initial . . . . . . . . 1026.4.1.3 Calcul du temps maximal de sortie . . . . . . . . . . . . . . . . . 103

6.4.2 Véri�cation de la satis�abilité . . . . . . . . . . . . . . . . . . . . . . . . . 1046.4.2.1 Système de transitions équivalent . . . . . . . . . . . . . . . . . 1046.4.2.2 Système �ni équivalent . . . . . . . . . . . . . . . . . . . . . . . 104

6.5 Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1046.5.1 Régulateur de vitesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1046.5.2 Spéci�cation de l'architecture . . . . . . . . . . . . . . . . . . . . . . . . . 1056.5.3 Spéci�cation des contraintes temporelles . . . . . . . . . . . . . . . . . . . 1056.5.4 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1066.5.5 Commentaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

6.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

7 Conclusion et perspectives 109

Bibliographie 113

III Annexes 125

A Groupes maximaux dans les réseaux ad hoc � modèles TLA+ 127A.1 L'algorithme de construction de groupes . . . . . . . . . . . . . . . . . . . . . . . 127A.2 Modélisation d'un réseau asynchrone non �able . . . . . . . . . . . . . . . . . . . 131A.3 Modélisation d'un réseau synchrone avec écrasement . . . . . . . . . . . . . . . . 132

B Association cohérente de données � modèles TLA+ 135B.1 Module commun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135B.2 Module passé d'in�uence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135B.3 Module d'estampillage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136B.4 Modules de modélisation d'un calcul . . . . . . . . . . . . . . . . . . . . . . . . . 137

B.4.1 Module calcul asynchrone . . . . . . . . . . . . . . . . . . . . . . . . . . . 137B.4.2 Module calcul synchrone . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

B.5 Module de véri�cation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

x

C Algorithmes non bloquants � modèles PlusCal et TLA+ 141C.1 Splitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

C.1.1 Dé�nition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141C.1.2 Modèle plusCal/TLA+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

C.2 Liste chaînée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144C.2.1 Dé�nition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144C.2.2 Modèle plusCal/TLA+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

xi

Table des �gures

2.1 Treillis des modèles de cohérence � d'après [SN04] . . . . . . . . . . . . . . . . . 152.2 Partitions en cliques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.3 Phases de l'algorithme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.4 Automate d'état d'un site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.5 Voisinages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1 Incohérence de perception des �ux . . . . . . . . . . . . . . . . . . . . . . . . . . 344.2 Flow Synchronisation Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.3 Temps non linéaire sans point de branchement . . . . . . . . . . . . . . . . . . . 384.4 Algèbre d'Allen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.5 Causalité et dé�lements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.6 Les relations entre dé�lements avec dépendance initiale . . . . . . . . . . . . . . . 434.7 Hiérarchie des relations de précédence avec précédence initiale . . . . . . . . . . . 444.8 Les relations entre dé�lements sans dépendance initiale . . . . . . . . . . . . . . . 464.9 Le demi-treillis des relations de précédence . . . . . . . . . . . . . . . . . . . . . 484.10 Arrivée tardive d'un récepteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.11 Flux et annulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.12 Hiérarchie des relations R1, R2, R3, R4 . . . . . . . . . . . . . . . . . . . . . . . 534.13 Intervalles liés par ⇀| et →| , distincts pour Kshemkalyani . . . . . . . . . . . . . . 544.14 Retard de délivrance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.15 Délivrance �fo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.16 Délivrance causalement ordonnée . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.17 Délivrance totalement ordonnée . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.18 Ordre total non causal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.19 Communication multimodale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.20 Interblocage par l'approche �les d'attente . . . . . . . . . . . . . . . . . . . . . . 604.21 Architecture d'une pile JGroups . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.22 Gigue vs cohérence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.1 Type de con�guration étudiée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645.2 Calcul de 2x + 3(x + 1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655.3 Système présentant un problème d'association de données . . . . . . . . . . . . . 655.4 Exécution cohérente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.5 Exécution incohérente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.6 Exemple de chemins non séparés . . . . . . . . . . . . . . . . . . . . . . . . . . . 715.7 Exemple de fuseau complexe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725.8 Exemple de fuseaux imbriqués . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725.9 Construction d'estampilles : détection d'exécution incohérente . . . . . . . . . . . 78

xiii

5.10 Système pouvant générer des pertes de données . . . . . . . . . . . . . . . . . . . 86

6.1 Relation d'observation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906.2 Multiplicité des chemins entre deux variables . . . . . . . . . . . . . . . . . . . . 936.3 Équivalence des horloges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 946.4 Pro�l temporel x d'une variable x . . . . . . . . . . . . . . . . . . . . . . . . . . 956.5 Sporadicité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 976.6 Le prédicat de lag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 996.7 Le prédicat de latence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 996.8 Le prédicat de décalage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1006.9 Le prédicat de fraîcheur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1006.10 Le prédicat de pérennité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1016.11 Le prédicat de stabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1016.12 Graphe sans/avec entrées indépendantes . . . . . . . . . . . . . . . . . . . . . . . 1036.13 Architecture du régulateur de vitesse . . . . . . . . . . . . . . . . . . . . . . . . . 1056.14 Graphe de propagation du régulateur de vitesse . . . . . . . . . . . . . . . . . . . 105

xiv

Première partie

Synthèse des activités

1

Chapitre 1

Curriculum vitæ

1.1 En bref

1.1.1 Coordonnées

Philippe QuéinnecIRIT / ENSEEIHT2 rue Camichel BP 7122F-31071 Toulouse cedex 7téléphone : (+33) (0)[email protected]

1.1.2 Diplômes et parcours

juin 1989 Diplôme d'ingénieur en Informatique et Mathématiques Appliquéesde l'ENSEEIHT 1

DEA en Informatique de l'INPT 2

oct. 1990 � mars 1994 Doctorat en Informatique de l'INPTTechniques de réplication de données pour les systèmes répartis àgrande échelle.Thèse e�ectuée au Centre d'Études de la Navigation AérienneDir. de recherche : Gérard Padiou

1994 � 1996 Attaché temporaire d'enseignement et de recherche à l'ENSEEIHTsept. 1996 Maître de conférences à l'ENSEEIHT/INPT

Équipe de recherche : Sûreté de développement des logiciels del'IRIT 3

2004 Équipe de recherche : Assistance à la Certi�cation d'ApplicationsDistribuées et Embarquées (ACADIE) de l'IRIT

1. À l'époque, École Nationale Supérieure d'Électrotechnique, d'Électronique, d'Informatique et d'Hydrau-lique de Toulouse, actuellement École Nationale Supérieure d'Électrotechnique, d'Électronique, d'Informatique,d'Hydraulique et de Télécommunication de Toulouse.

2. Institut National Polytechnique de Toulouse.3. Institut de Recherche en Informatique de Toulouse.

3

1.2 - Activités d'enseignement

1.2 Activités d'enseignement

Depuis mon recrutement en 1996, j'e�ectue ma charge de 192h d'enseignement majoritai-rement en deuxième année du cycle ingénieur du département informatique et mathématiquesappliquées (DIMA) de l'ENSEEIHT, mais j'interviens aussi dans la formation par apprentissageInformatique et réseaux, ainsi que plus ponctuellement en troisième année ingénieur et mastère,au département télécommunications et réseaux (TR) de l'ENSEEIHT, et à l'ENAC 4.

Mes enseignements sont principalement centrés autour de la thématique des systèmes d'ex-ploitations et des systèmes répartis. J'interviens également dans le domaine de la théorie deslangages et des méthodes formelles. Seuls les enseignements signi�catifs sont évoqués dans lasuite, le plaisir de découvrir de nouveaux sujets me conduisant régulièrement à intervenir enassistance (TD ou TP) dans de nouvelles matières.

1.2.1 Responsabilité d'enseignements

Je suis responsable des enseignements suivants. À ce titre, j'ai rédigé les supports de cours etTD et développé les TP. Je réalise les séances de cours ainsi qu'une partie des TD et TP, et jecoordonne l'activité des autres intervenants de TD et TP.

Systèmes concurrents module de 30h (18h cours, 5h TD, 7h TP, 2e année cycle ingénieurInformatique de l'ENSEEIHT) et module de 26h (10h cours, 7h TD, 9h TP, mastère Infor-matique).

L'objectif de ce module est d'étudier les concepts de la programmation concurrente prin-cipalement dans un contexte centralisé. Dans un premier temps, le problème de la syn-chronisation des processus est étudié. La notion d'activité ou thread est décrite pour gérerle parallélisme à grain �n. Les schémas génériques de coopération ou concurrence (ex-clusion mutuelle, producteur-consommateur, client-serveur, lecteurs-rédacteurs, allocateur,etc) sont exposés et résolus à l'aide des mécanismes classiques de synchronisation (séma-phores, moniteurs, rendez-vous). En�n, la notion de transaction est étudiée en particuliersous l'aspect sérialisation, et des mécanismes plus innovants (mémoire transactionnelle,synchronisation non bloquante) sont introduits.

Systèmes centralisés module de 30h (1re année cycle ingénieur par apprentissage Informatiqueet réseaux de l'ENSEEIHT)

Le cours présente les concepts fondamentaux des systèmes d'exploitation : processus et �-chiers, mémoire virtuelle, gestion des entrées/sorties ainsi que les principes de base de struc-turation : structure en couches, notion de machine virtuelle, noyau (superviseur), langagede script, contrôle des usagers, allocation des ressources, ordonnancement des processus.

La première partie est consacrée à la compréhension du fonctionnement d'un système d'ex-ploitation particulier via ses deux interfaces : d'une part son langage de commande etd'autre part ses primitives noyau. La deuxième partie est consacrée à l'implantation deportions d'un mini système d'exploitation (processus, ordonnanceur, mémoire virtuelle. . . ).

Systèmes de transitions module de 30h (2e année cycle ingénieur par apprentissage Informa-tique et réseaux de l'ENSEEIHT)

Le problème de la modélisation, spéci�cation et validation de systèmes, en particulierconcurrents, est étudié. Les systèmes de transitions sont utilisés comme outil de base demodélisation. Les logiques temporelles CTL et LTL permettent de spéci�er les propriétésde sûreté, vivacité et équité de tels systèmes. Dans ce cadre, l'environnement TLA+ est

4. École Nationale de l'Aviation Civile.

4

Chapitre 1 - Curriculum vitæ

mis en ÷uvre. En�n, les techniques de véri�cation des propriétés temporelles sont abordéesd'une part par véri�cation de modèle (model-checking) et d'autre part, par preuve.

Théorie des automates module de 16h (12h cours, 4h TD, 1re année cycle ingénieur Télécom-munications et Réseaux de l'ENSEEIHT)

Notion sur les langages en informatique. Dé�nition des automates à états �nis. Utilisationpour la modélisation de systèmes. Non déterminisme, déterminisation, minimisation. Rela-tion avec les expressions régulières. Extensions : automates à compteurs, automates à piles,transducteurs. . .

Théorie des langages module de 16h de cours à l'ENAC 5, cycle ingénieur 1re année, de 1996à 2008.

� Automates à états �nis et langages rationnels : automates, langages rationnels, non dé-terminisme, déterminisation, minimisation, langage des expressions régulières, théorèmed'Arden, expression régulière associée à un automate �ni, dérivée, automate associé àune expression régulière.

� Grammaires : dérivations, langages contextuels et algébriques, ambiguïté, réduction desgrammaires, formes standard. Langages algébriques, relations avec les langages réguliers.Automates à pile : dé�nitions, équivalence avec les langages algébriques.

� Machine de Turing : dé�nition, fonctions calculables, indécidabilité de l'arrêt, introduc-tion à la calculabilité.

1.2.2 Participation à d'autres enseignements

Sans être exhaustif, j'ai aussi eu une participation active (rédaction de sujets de TD, mise aupoint de TP) dans les enseignements suivants :

Compilation Intitulé � traduction des langages �, ce module présente les outils théoriqueset pratiques nécessaires à la réalisation d'un compilateur : analyse lexicale, grammairesattribuées, analyse syntaxique descendante, table des symboles, contrôle de type, gestionde la mémoire, génération de code.

J'ai e�ectué pendant plusieurs années les TD et les TP de cet enseignement, et mon apporta principalement consisté en la mise au point de divers TP (squelette du compilateur,développement des solutions intermédiaires).

Intergiciels Les intergiciels sont les logiciels se situant entre le système d'exploitation et les ap-plications, permettant de faciliter la construction des applications centralisées ou réparties.Ce cours présente les intergiciels permettant la construction d'applications selon diversschémas : communication par message, par �ots (streams), par appel de procédure, parmémoire répartie. . .

Mon activité a consisté à participer à la dé�nition du contenu et à développer les travauxpratiques, qui représentent la moitié du volume horaire (7 à 10 séances, selon la formationoù a lieu ce cours).

Système pour le multimédia Ce cours avait pour but de présenter les besoins en système dumultimédia, à la fois dans un contexte centralisé et réparti.

5. École Nationale de l'Aviation Civile.

5

1.4 - Activités collectives

1.3 Activités collectives

1.3.1 Formation par apprentissage

En 2008 et 2009, j'ai activement participé au montage de la �lière par apprentissage del'ENSEEIHT, diplôme d'ingénieur � informatique et réseau � (un an de montage, à raison de3 à 4 réunions par mois, plus recherche d'information et mise en place de la maquette de laformation). Cette formation a ouvert en septembre 2009, et outre les enseignements que j'ye�ectue, je suis chaque année tuteur d'un apprenti.

1.3.2 Jurys

Je participe (ou j'ai participé) :

� aux jurys d'admission sur titres en formation ingénieur de l'ENSEEIHT, département In-formatique et mathématiques appliquées ;

� aux oraux et jurys d'admission de la formation ingénieur par apprentissage Informatiqueet réseaux de l'ENSEEIHT ;

� aux jurys de passage des élèves ingénieurs de 1re et 2e année en année supérieure ;� des jurys de diplôme de l'ENSEEIHT, département Informatique et mathématiques appli-quées (diplômes d'ingénieur et mastère).

1.3.3 Conseils et commissions

� Élu à la commission de spécialistes INPT 27e de 2002 à 2009, et depuis 2009, membre duvivier interne (qui remplace les commissions de spécialistes à l'INPT)

� Membre des comités d'audition pour les recrutements de maîtres de conférences en 2002 et2003.

� Membre du comité de sélection pour le recrutement de maître de conférences en 2009.� Élu au Conseil d'École de l'ENSEEIHT de 2001 à 2007.� Membre de la commission interdisciplinaire pour l'avancement local des enseignants-cher-cheurs de l'INPT depuis 2008.

� Élu au Conseil de la formation par apprentissage Informatique et réseaux.

1.3.4 Divers

� Membre du conseil pédagogique de réforme du département DIMA 6 en 2005 et 2009, pourla refonte des enseignements de la �lière ingénieur.

� Membre de la commission � matériel � du département DIMA pour le renouvellement duparc informatique en 2008 (budget 300 ke).

� Représentant bibliothèque ENSEEIHT du département DIMA.� Membre du comité d'organisation de l'International Symposium on Distributed ComputingDISC 2002, et de ses workshops satellites POMC et GETCO, accueillis à l'ENSEEIHT.

� Prime d'Excellence 7 Scienti�que depuis septembre 2009.

6. Département informatique et mathématiques appliquées de l'ENSEEIHT.7. Sic.

6


1.4 Activités de recherche

Suite à mon recrutement, j'ai e�ectué mes activités de recherche à l'IRIT dans l'équipe Sûretéde développement des logiciels, groupe � Modélisation et validation des algorithmes répartis �,dirigé par Gérard Padiou. L'équipe a ensuite évolué pour devenir l'équipe ACADIE Assistanceà la Certi�cation d'Applications Distribuées et Embarquées, regroupant des personnels à la foisde l'INPT/ENSEEIHT et de l'Université Toulouse 3 (Université Paul Sabatier), et dirigée depuissa création par Mamoun Filali.

1.4.1 Encadrements de thèses

Les thèses que j'ai encadrées l'ont été sous la supervision du professeur Gérard Padiou,directeur du département Informatique et Mathématiques Appliquées de l'ENSEEIHT de 2006à 2010.

Romulus Grigora³ : �nancement sur contrat, 03/2000 � 12/2003Encadrement : 60%, sous la responsabilité de G. Padiou (40%).Origine : Universitatea Politehnica din Bucure³ti (Université polytechnique de Bucarest,Roumanie)

Intitulé : � Supervision de �ux dans les contenus hypermédia. Optimisation de politiquesde préchargement et ordonnancement causal. �

Publications : [GMPQ03, PGQP05a, PGQP05b, PGQP05c]Situation actuelle : maître de conférences à l'INPT/ENSEEIHT

Christophe Cubat dit Cros : �nancement MENRT, 10/2001 � 02/12/2005Encadrement : 33%, avec G. Padiou (66%).Origine : maîtrise à l'université de Pau et des Pays de l'Adour puis DEA à l'IRIT.Intitulé : � Agents mobiles coopérants pour les environnements dynamiques. �

Cezar Ple³ca : co-�nancement IRIT/Roumanie 03/2004 � 21/06/2007.Encadrement : 33%, en collaboration avec R. Grigora³ (66%), sous la responsabilité deV. Charvillat et de G. Padiou.Les travaux de C. Ple³ca ont suivi deux axes : d'une part la continuation des travauxde thèse de R. Grigora³ sur la coordination causale de �ux répartis ; d'autre part,l'adaptation de contenu, encadré par R. Grigora³ et V. Charvillat.

Origine : diplôme d'ingénieur de l'Academia Tehnica Militara, Bucarest, Roumanie puisDEA à l'IRIT.

Intitulé : � Supervision de contenus multimédia : adaptation de contenu, politiques opti-males de préchargement et coordination causale de �ux. �

Publications : [PGQP05a, PGQP05b, PGQP05c, PGQ+06] (sur l'axe que j'ai co-encadré)Situation actuelle : en poste à l'Academia Tehnica Militara, Bucarest.

Tanguy Le Berre : �nancement MENRT, 09/2006 � 03/2010Encadrement : 90%, sous la responsabilité de G. Padiou (10%).Origine : diplôme d'ingénieur à l'ENSTB (école nationale supérieure des télécommunica-tions de Bretagne) puis master à l'IRIT.

Intitulé : � Spéci�cation formelle de systèmes temps réel répartis par une approche �otsde données à contraintes temporelles. �

Publications : [LB07, LBQP08, LBMPQ08, LBPQ09, LBMPQ09a, LBMPQ09b]Situation actuelle : ingénieur d'études chez Silicom.

Nadège Pontisso : co-�nancement CNES 8 / Thales Alenia Space, 11/2006 � 12/2009

8. Centre National d'Études Spatiales.

7

1.4 - Activités de recherche

Encadrement : 90%, sous la responsabilité de G. Padiou (10%).Origine : INSA de Toulouse.Intitulé : � Association cohérente de données dans les systèmes temps réel à base de com-posants � Application aux logiciels spatiaux. �

Publications : [PPQ08a, PPQ08b, PQPV09, PQP09, PQP10, PQP11]Situation actuelle : ingénieure pour Amadeus.

1.4.2 Collaborations

CNES collaboration en 2007 avec le CNES et SpaceBel pour mener une étude sur la séparabilitédans les systèmes répartis. Les travaux ont donné lieu à trois publications (pour ma part :[MPQ07, MPQD09]) et un prototype développé par SpaceBel.

Université du New Hampshire Séjour, à l'été 2005, à l'University of New Hampshire, USApour travailler avec Michel Charpentier. Publication liée à ce séjour : [CPQ05].

ACI CNRS CORSS En 2003�2004, l'ACI CORSS (Composition et Ra�nement de Sys-tèmes), e�ectuée en collaboration avec l'équipe ARLES de l'INRIA, s'est intéressée à la forma-lisation de protocoles dans les réseaux ad hoc. En particulier, nous avons étudié un algorithmede construction de groupes dans de tels réseaux. L'algorithme, développé par l'équipe ARLES,a été spéci�é et formalisé en TLA+[FIM+05].

Avant-projet FéRIA 9 Responsable de l'avant-projet � Flux multimédias coordonnés � en2003�2004, en collaboration avec Jean Fanchon (LAAS 10�CNRS), dans le cadre des travauxsur la cohérence pour le multimédia [PGQ+06].

BQR inter-INP Formalisation du Développement de Logiciel En 1997�1998 un pro-jet BQR (Bonus Qualité Recherche) regroupant les trois instituts nationaux polytechniques deGrenoble (laboratoire LSR), Nancy (laboratoire LORIA) et Toulouse (laboratoire IRIT), et in-titulé Formalisation du Développement de Logiciel a permis de comparer di�érentes approchesformelles à travers la résolution d'un problème commun, et a conduit au développement d'un kitd'évaluation des méthodes formelles. Le problème étudié était posé sous la forme d'un cahier descharges informel pour un système de contrôle d'accès.

Pour ma part, j'ai dé�ni la spéci�cation générale du contrôle d'accès (le système) et la spéci-�cation du bon comportement des usagers (l'environnement). Ces spéci�cations ont été réaliséesen logique temporelle linéaire et ont servi de base pour la comparaison entre les di�érents for-malismes. J'ai aussi activement participé au développement de notre solution dans le formalismeUnity. En�n, j'ai développé un simulateur d'environnement fournissant une interface pour pi-loter le contrôleur d'accès. J'ai aussi été amené, lors de ces rencontres, à présenter aux autreschercheurs les di�cultés de la formalisation des systèmes répartis et notamment les notions re-latives à la causalité, ainsi que notre solution [FPQ98].

9. Fédération de recherche en informatique et automatique, regroupant les trois principaux laboratoires tou-lousains en STIC : IRIT, LAAS, ONERA/CERT.10. Laboratoire d'Analyse et d'Architecture des Systèmes.

8


1.4.3 Publications

Thèse

[1] Philippe Quéinnec. Techniques de réplication de données pour les systèmes répartis à grandeéchelle. Thèse de doctorat, Institut National Polytechnique de Toulouse, avril 1994.

Revues internationales avec comité de lecture

[2] Michel Charpentier, Mamoun Filali, Philippe Mauran, Gérard Padiou, et Philippe Quéin-nec. The observation : An abstract communication mechanism. Parallel Processing Letters,9(3) :437�450, septembre 1999.

[3] Tanguy Le Berre, Philippe Mauran, Gérard Padiou, et Philippe Quéinnec. Real timebehavior of data in distributed embedded systems. Scalable Computing : Practice andExperience, 10(3) :229�239, septembre 2009.

[4] Nadège Pontisso, Philippe Quéinnec, et Gérard Padiou. Analysis of distributed multi-periodic systems to achieve consistent data matching. Concurrency and Computation :Practice and Experience, A paraître 2011.

Revues nationales avec comité de lecture

[5] Philippe Quéinnec et Gérard Padiou. Di�usion hiérarchisée �able pour une mémoire ré-pliquée à grande échelle. Revue Électronique sur les Réseaux et l'Informatique Répartie, 2,octobre 1995.

[6] Gérard Padiou, Mamoun Filali, et Philippe Quéinnec. Les modèles d'exécution répartie.Calculateurs Parallèles, Systèmes Répartis et Réseaux, 10(5) :477�492, 1998.

Conférences internationales avec comité de lecture

[7] Philippe Quéinnec et Gérard Padiou. Flight plan management in a distributed air tra�ccontrol system. In Int'l Symposium on Autonomous Decentralized Systems, pages 323�329,mars 1993.

[8] Philippe Quéinnec et Gérard Padiou. Unity as a tool for design and validation of a datareplication system. In 9th Int'l Conf. on Systems Engineering, juillet 1993.

[9] Philippe Quéinnec et Gérard Padiou. Derivation of fault tolerance properties of distributedalgorithms. In 13th ACM Symposium on Principles of Distributed Computing, short paper,août 1994.

[10] Philippe Quéinnec et Gérard Padiou. Design of a highly available replicated memory. InEuropean Research Seminar on Advances in Distributed Systems, avril 1995.

[11] Michel Charpentier, Mamoun Filali, Philippe Mauran, Gérard Padiou, et Philippe Quéin-nec. Abstracting communication to reason about distributed algorithms. In Özalp Babao§luet Keith Marzullo, éditeurs, 10th Int'l Workshop on Distributed Algorithms (WDAG'96),volume 1151 of Lecture Notes in Computer Science, pages 89�104. Springer-Verlag, octobre1996.

9


[12] Michel Charpentier, Mamoun Filali, Philippe Mauran, Gérard Padiou, et Philippe Quéin-nec. Tailoring Unity to distributed program design. In José Rolim et al., éditeurs, Int'lWorkshop on Formal Methods for Parallel Programming : Theory and Applications (FMPP-TA'98), volume 1388 of Lecture Notes in Computer Science, pages 820�832. Springer-Verlag, avril 1998.

[13] Michel Charpentier, Mamoun Filali, Philippe Mauran, Gérard Padiou, et Philippe Quéin-nec. Modelling and verifying mobility : A case study. In 3rd Int'l Conf. On Principles OfDIstributed Systems, special issue of Studia Informatica, pages 151�166, octobre 1999.

[14] Mamoun Filali, Philippe Mauran, Gérard Padiou, Philippe Quéinnec, et Xavier Thirioux.Re�nement based validation of an algorithm for detecting distributed termination. In JoséRolim et al., éditeurs, Int'l Workshop on Formal Methods for Parallel Programming : Theoryand Applications (FMPPTA2000), volume 1800 of Lecture Notes in Computer Science.Springer-Verlag, mai 2000.

[15] Philippe Quéinnec, Mamoun Filali, Philippe Mauran, et Gérard Padiou. Describing mobilecomputations with path vectors. In 4th Int'l Conf. On Principles Of DIstributed Systems,special issue of Studia Informatica Universalis, pages 221�234, décembre 2000.

[16] Mamoun Filali, Philippe Mauran, Gérard Padiou, et Philippe Quéinnec. The reconstructionof a mobile agent computation and its validation. In Int'l Workshop on Formal Methodsfor Parallel Programming : Theory and Applications (FMPPTA2003). IEEE, avril 2003.

[17] Mamoun Filali, Philippe Mauran, Gérard Padiou, et Philippe Quéinnec. Set based trees forthe validation of a di�using computation reconstruction algorithm. In 2nd Int'l Workshopon Re�nement of Critical Systems : Methods, Tools and Developments (RCS'03), juin 2003.

[18] Cezar Ple³ca, Romulus Grigora³, Philippe Quéinnec, et Gérard Padiou. Adaptive multi-modal communication for multimedia. In 11th Euromedia, pages 183�189, avril 2005.

[19] Cezar Ple³ca, Romulus Grigora³, Philippe Quéinnec, et Gérard Padiou. A �exible commu-nication toolkit for synchronous groupware. In Int'l Conf. on Multimedia CommunicationsSystems ICMCS05, pages 216�221, août 2005.

[20] Michel Charpentier, Gérard Padiou, et Philippe Quéinnec. Cooperative mobile agentsto gather global information. In 4th IEEE Int'l Symposium on Network Computing andApplications (NCA05), pages 271�274, juillet 2005.

[21] Mamoun Filali, Valérie Issarny, Philippe Mauran, Gérard Padiou, et Philippe Quéinnec.Maximal group membership in ad hoc networks. In 6th Int'l Conf. on Parallel Processingand Applied Mathematics, volume 3911 of Lecture Notes in Computer Science, pages 51�58.Springer-Verlag, septembre 2005.

[22] Cezar Ple³ca, Romulus Grigora³, Philippe Quéinnec, et Gérard Padiou. Streaming withcausality : A practical approach. In ACM Multimedia, pages 283�286, novembre 2005.

[23] Cezar Ple³ca, Romulus Grigora³, Philippe Quéinnec, Gérard Padiou, et Jean Fanchon.A coordination-level middleware for supporting �exible consistency in CSCW. In 14thEuromicro Conf. on Parallel, Distributed and Network-based Processing, pages 316�321.IEEE, février 2006.

[24] Philippe Mauran, Gérard Padiou, et Philippe Quéinnec. Separability to help parallel si-mulation of distributed computations. In 11th Int'l Conf. On Principles Of DIstributedSystems, volume 4878 of Lecture Notes in Computer Science, pages 358�371. Springer-Verlag, décembre 2007.

[25] Tanguy Le Berre, Philippe Quéinnec, et Gérard Padiou. Ensuring timed validity of distri-buted real time data. In 4th European Congress on Embedded Real Time Software (ERTS2008), janvier 2008.

10


[26] Tanguy Le Berre, Philippe Mauran, Gérard Padiou, et Philippe Quéinnec. Real timebehavior of data in distributed embedded systems. In Int'l Workshop on Real Time Software(RTS'08), pages 569�575. Polish Information Processing Society, octobre 2008.

[27] Nadège Pontisso, Philippe Quéinnec, Gérard Padiou, et Guillaume Véran. Data consistencyin a component based space system. In DASIA09 DAta Systems In Aerospace, pages 277�280. International Space System Engineering Conference, mai 2009.

[28] Philippe Mauran, Gérard Padiou, Philippe Quéinnec, et Bernard Delatte. Using separabi-lity to enable time-consistent distributed space simulation. In DASIA09 DAta Systems InAerospace, pages 281�284. International Space System Engineering Conference, mai 2009.

[29] Nadège Pontisso, Philippe Quéinnec, et Gérard Padiou. Temporal data matching in com-ponent based real time systems. In IEEE Symposium on Industrial Embedded SystemsSIES2009, pages 62�65, juillet 2009.

[30] Tanguy Le Berre, Philippe Mauran, Gérard Padiou, et Philippe Quéinnec. A data orientedapproach for real-time systems. In 17th Int'l Conf. on Real-Time and Network SystemsRTNS09, pages 147�158, octobre 2009.

[31] Nadège Pontisso, Philippe Quéinnec, et Gérard Padiou. Analysis of distributed multi-periodic systems to achieve consistent data matching. In 10th Annual Int'l Conf. on NewTechnologies of Distributed Systems NOTERE 2010, pages 81�88, mai 2010.

Conférence invitée

[32] Philippe Quéinnec. Un modèle d'exécution répartie tolérant aux fautes : Isis, Horus. 3e

École d'Informatique des Systèmes Parallèles et Répartis (ISYPAR 98), mars 1998. 14pages.

Conférences nationales avec comité de lecture

[33] Philippe Quéinnec. Étude d'un système de réplication en cohérence faible pour des donnéessoumises au temps. In Journées des Jeunes Chercheurs en Systèmes Informatiques Répartis,pages 75�80, avril 1993.

[34] Philippe Quéinnec, Gérard Padiou, et Philippe Papaïx. Un serveur mémoire réparti. InActes des Journées Parallélisme de l'IRIT, pages 11�12, avril 1994.

[35] Mamoun Filali, Gérard Padiou, et Philippe Quéinnec. Développement d'une spéci�cationformelle en Unity � analyse d'un système de contrôle d'accès. In Approches Formelles dansl'Assistance au Développement de Logiciels (AFADL98), pages 109�120, Poitiers, septembre1998.

[36] Mamoun Filali, Gérard Padiou, et Philippe Quéinnec. Contrôle d'agents mobiles. In For-malisation des Activités Concurrentes FAC'2000, mai 2000.

[37] Mamoun Filali, Philippe Mauran, Gérard Padiou, et Philippe Quéinnec. Rejeu d'un calculd'agents mobiles. In Formalisation des Activités Concurrentes FAC'2002, mars 2002.

[38] Romulus Grigora³, Philippe Mauran, Gérard Padiou, et Philippe Quéinnec. Ordonnan-cement causal de �ux répartis multimédias. In Formalisation des Activités ConcurrentesFAC'2003, mars 2003.

[39] Gérard Padiou, Philippe Quéinnec, Philippe Mauran, et Christophe Cubat. Composantsmobiles fondés sur des agents mobiles coopérants. In Journées Composants de l'ASF, pages80�86, avril 2005.

11


[40] Nadège Pontisso, Gérard Padiou, et Philippe Quéinnec. Cohérence temporelle des calculsrépartis embarqués. In Formalisation des Activités Concurrentes FAC'2008, avril 2008.

[41] Nadège Pontisso, Gérard Padiou, et Philippe Quéinnec. Real time data consistency incomponent based embedded systems. In 8th int'l conf. on New technologies in distributedsystems � session Consistency, juin 2008.

[42] Tanguy Le Berre, Gérard Padiou, et Philippe Quéinnec. Étude du comportement temporelde données réparties. In Formalisation des Activités Concurrentes FAC'2009, avril 2009.

12

Chapitre 2

Synthèse des activités de recherche

2.1 Équipe

Aucun des sujets détaillés dans la suite n'a été mené en isolation et tous sont le fruit d'untravail coopératif au sein de l'équipe, ce qui se re�ète dans les publications. Il m'est impossiblede séparer les idées qui me sont propres, qui proviennent de discussions, ou que j'ai empruntées.Je suis donc redevable aux personnes suivantes :

� les membres permanents, Mamoun Filali, Philippe Mauran, Gérard Padiou ;� les membres non permanents, Michel Charpentier de 1994 à 1998 et plus occasionnel-lement depuis, Romulus Grigora³ depuis 2000 1, Cezar Ple³ca de 2004 à 2007, TanguyLe Berre de 2005 à 2010, Nadège Pontisso de 2006 à 2009.

2.2 La cohérence dans les systèmes répartis

Dans cette section, nous présentons sommairement quelques domaines où la cohérence inter-vient, plus pour mémoire que comme références. Nous présenterons dans la section suivante noscontributions au problème de la cohérence dans de nouveaux domaines, et sous des hypothèsesdistinctes de celles usuellement retenues.

La cohérence dans les systèmes répartis recouvre plusieurs sujets. On trouve tout d'abord lagénéralisation des travaux sur la mémoire partagée en contexte multiprocesseurs : à une certaineéchelle, un environnement multiprocesseur peut (et doit ?) être traité comme un système réparti,et les protocoles de cohérence mémoire ont été adaptés dans ce contexte. Un sujet récurrent dansles systèmes répartis concerne la construction d'un état global cohérent avec une exécution ; il nes'agit pas là d'imposer une forme de cohérence mais de capter celle-ci. La réplication de donnéesconsistant à placer une même information en de multiples lieux a donné lieu à la dé�nition dedi�érentes formes de cohérence et a surtout fait apparaître diverses formes de di�usion et decoordination. En�n, dans un domaine initialement bien distinct, les bases de données sont, paressence, un secteur où la cohérence est un sujet fondamental.

2.2.1 Cohérence mémoire

La notion de cohérence mémoire est issue des architectures multiprocesseurs à accès unique(type bus) et mémoire commune. En 1979 [Lam79], Lamport montre que l'exécution parallèle

1. Actuellement permanent de l'équipe VORTEX.

13

2.2 - La cohérence dans les systèmes répartis

d'un programme n'est pas nécessairement identique à une exécution séquentielle, et il dé�nit lacohérence séquentielle comme une propriété de l'architecture du système qui doit garantir que lerésultat de toute exécution est le même que si :

1. les opérations de tous les processeurs sont exécutées en ordre séquentiel (FIFO) ;

2. les opérations d'un processeur donné apparaissent dans cette séquence dans l'ordre où ilsont eu lieu sur le processeur.

Ces deux propriétés garantissent le respect de l'ordre individuel de chaque processeur, etl'équivalence avec une exécution séquentielle monoprocesseur. En particulier, cela impose quetoute opération sur la mémoire apparaisse comme atomique vis-à-vis des autres opérations [AG96].Très vite, des architectures matérielles n'ont pas respecté la cohérence séquentielle, que ce soitpar l'introduction de caches, le ré-ordonnancement d'instructions au sein du processeur ou lasuperposition (overlapping) des opérations.

Ainsi le simple programme 〈x ← 1; y ← 2〉‖〈z ← x ;w ← y〉, où toutes les variables sontinitialement nulles, peut terminer avec z = 0 ∧ w = 2, donc sans respecter l'ordre causal dupremier processus. Il su�t de considérer un biprocesseur avec cache write-through et sans invali-dation. Si initialement le second processeur démarre l'exécution avec x dans son cache mais pasy , l'exécution intégrale du premier processus met à jour la mémoire mais n'invalide pas le cachedu second processeur, lequel y trouve alors l'ancienne valeur de x , mais va chercher la nouvellevaleur de y en mémoire.

Le ré-ordonnancement des opérations existe aussi quand un processeur considère que deuxinstructions sont indépendantes, et donc en particulier lors de deux écritures sur des adressesmémoires distinctes, ou lors d'une lecture et d'une écriture sur de telles adresses. L'ajout d'unecellule à une liste (écriture du contenu puis écriture du pointeur de chaînage) peut parfaitementêtre perçu en sens inverse sur un autre processeur, si les écritures sur le processeur à l'origine dela mise à jour sont réordonnées : le second processeur suit alors le pointeur de chaînage (mis àjour) pour aboutir sur une cellule pas encore écrite.

La superposition d'instructions se présente quand on cesse de considérer qu'un accès mémoireest atomique et qu'un processeur exécute en parallèle une seconde instruction en attendant laterminaison de la première. Par exemple, une lecture d'une case mémoire non présente en cacheinduit un fort délai que le processeur peut mettre à pro�t pour exécuter les instructions suivantes,tant qu'elles ne sont pas con�ictuelles vis-à-vis des accès mémoire.

Pour toutes ces raisons, d'innombrables formes de cohérence mémoire ont été dé�nies. L'ob-jectif peut être soit de décrire le comportement d'une machine multiprocesseurs, soit inversementde dé�nir le modèle mémoire nécessaire à la correction d'un code. Ces travaux ont ensuite étéadaptés aux machines virtuelles (cohérence mémoire de la JVM par exemple) et aux architecturesréparties.

On notera l'important travail de Steinke et Nutt [SN04] pour formaliser et uni�er la descrip-tion de ces diverses formes de cohérence, qu'ils résument par une imposante �gure (présentée demanière simpli�ée dans la �gure 2.1), où l'on retrouve les cohérences usuelles plus d'autres plusinhabituelles :

Local chaque processeur voit ses opérations dans l'ordre où il les a faites, mais il n'y a pasde contraintes sur la perception des écritures venant des autres processeurs, et chaqueprocesseur peut percevoir des ordres di�érents. Il n'y a donc pas de contrainte de cohérenceà proprement parler.

Slow une lecture d'une case mémoire doit retourner une valeur précédemment écrite, et au-cune valeur antérieurement écrite par le même processeur que celui qui a écrit la valeurlue ne doit ensuite apparaître (non retour en arrière). Les écritures locales sont perçues

14

Chapitre 2 - Synthèse des activités de recherche

Linearizability

Sequential

Processor Causal

PRAM Cache

Slow

Local

Figure 2.1 � Treillis des modèles de cohérence � d'après [SN04]

immédiatement. La cohérence slow est plus faible que PRAM et cache, et est la plus faiblecontrainte de cohérence.

Cache toutes les écritures sur une même case mémoire sont e�ectuées selon un ordre séquentiel.La cohérence cache n'impose aucune contrainte entre écritures ou lectures sur des casesdistinctes ;

PRAM (pipelined RAM) les écritures e�ectuées par un processeur sont vues par tous les autresprocesseurs dans l'ordre où elles ont été e�ectuées, mais des écritures venant de processeursdi�érents peuvent être vues dans un ordre di�érent selon les processeurs ;

Processor PRAM + cache ;

Causal toutes les opérations d'un processeur plus toutes les écritures qu'il perçoit se produisentdans un ordre total compatible avec la causalité.

Sequential le résultat d'une exécution est le même que si l'ensemble des opérations de tous lesprocesseurs avaient été exécutées dans un certain ordre séquentiel, en respectant l'ordrelocal des séquences de chacun des processeurs ;

Linearizability les opérations ont une durée. L'exécution doit être cohérente séquentiellementet l'ordre total de la séquence équivalente doit correspondre à un ordre où toutes les opéra-tions sont considérées comme atomiques (instantanées) à un point du temps e�ectif entreleur début et leur �n. En particulier, deux opérations qui ne se chevauchent pas temporel-lement ne peuvent pas être réordonnées, alors même qu'il n'y aurait aucune dépendanceentre elles.

L'intérêt des travaux de Steinke et Nutt est en outre de montrer que toutes ces formes decohérence découlent de l'utilisation ou non de quatre propriétés de base :

� Global Process Order (GPO) : toutes les opérations d'un processus sont vues partout dansl'ordre où elles ont été e�ectuées ;

15


� Global Data Order (GDO) : pour toute variable, il existe (au moins) un ordre total desopérations que tous les processus acceptent comme un ordre possible de la réalité ;

� Global Write-read-write Order (GWO) : respect de la causalité (plus précisément, ce quimanque à GPO, qui assure l'ordre local, pour être la causalité) ;

� Global Anti-Order (GAO) : GDO + toute lecture doit lire la plus récente écriture dansl'ordre total accepté comme possible.

On note que toutes les dé�nitions de cohérence mémoire se situent dans un modèle mémoire,avec des variables (des cases mémoires) et deux opérations de lecture et d'écriture. Seule lacohérence causale s'inspire du modèle message mais reste néanmoins énoncée dans le modèlemémoire. Une di�érence notable est l'idempotence des écritures (w(x );w(x ) ≡ w(x )), ainsi quel'absence de distinction réception/délivrance, usuelle dans les modèles à base de messages.

L'autre point intéressant est la dichotomie variables/processus : l'ordre à respecter pour lesopérations issues d'un processus donné peut être distinct de celui pour les opérations portantsur une variable donnée. Par exemple, en cohérence PRAM, l'exécution doit respecter l'ordre desopérations, indépendamment des variables, provenant d'un même processus (GPO), mais peutne pas respecter la causalité (¬GWO) sur des opérations portant sur la même variable maise�ectuées par des processus di�érents.

2.2.2 État global cohérent

Dans un calcul réparti classiquement décrit avec événements internes, d'émission et de récep-tion (cf page 41), on peut s'intéresser à capturer un état global qui représente un état possibledu calcul [Ray92b]. Un état contient la situation de chaque processus (les événements qui ont eulieu sur ce processus) et le contenu des canaux de communication. Un état est donc un couple(ensemble d'événements, contenu des canaux). On dit qu'un état global est cohérent si :

� pour chaque processus, si un événement est inclus dans l'état, tous les événements prédé-cesseurs sur ce site sont aussi inclus ;

� si l'événement d'émission d'un message est inclus, alors soit l'événement de réception corres-pondant est inclus, soit un canal contient ce message ; et inversement pour tout événementde réception ou tout message contenu dans un canal, l'événement d'émission correspondantest inclus.

On utilise aussi la notion de coupure cohérente, qui est l'enveloppe supérieure d'un état globalcohérent.

La dé�nition précédente, via la notion de prédécesseur et le couplage émission-réception, esten fait directement liée à la relation de précédence causale ≺ (cf page 41) : un état global estcohérent s'il forme un ensemble fermé inférieurement (lower set ou downset) pour la relationd'ordre partiel ≺, c'est-à-dire qu'un état E est cohérent ssi :

∀e, e ′ : e ∈ E ∧ e ′ ≺ e ⇒ e ′ ∈ E

On pourrait donc imaginer dé�nir des états globaux cohérents pour d'autres relations d'ordrepartiel.

Le but d'un algorithme de capture d'un état global cohérent correspondant à un ensembleélémentaire E d'événements (pas nécessairement cohérents, ni nécessairement couvrant tous lesprocessus) revient à déterminer le plus petit ensemble fermé inférieurement contenant E : ↓ E .Il est important de noter qu'un état global cohérent n'est pas nécessairement un état réel del'exécution, tel qu'il serait observé de manière instantanée sur tous les sites : simplement il auraitpu se produire. En construisant l'ensemble des états globaux cohérents, on obtient un treillis dontles chemins ordonnés forment les exécutions possibles du système. L'exécution réelle est l'uned'entre elles, sans qu'il soit possible de déterminer laquelle sauf à observer de manière instantanée

16


l'ensemble des processus. De manière réaliste pour un système informatique, l'observateur estsupposé être dans le même modèle que le système observé.

La construction d'un état global vise en général à déterminer si le calcul véri�e une propriétédonnée. Des approches généralistes [CM91] construisent le treillis des états globaux cohérents,déterminant ainsi toutes les exécutions possibles. Ces approches permettent de véri�er des pro-priétés de type possibly(φ) (la propriété φ est vraie dans au moins un état global) et de�nitely(φ)(quelque soit le chemin depuis un état global initial à un état global �nal, la propriété φ est vraiedans un état global de ce chemin), avec φ un prédicat d'état arbitraire. À l'opposé, on trouvedes algorithmes spéci�ques visant à détecter des classes particulières de propriétés. Par exemplel'algorithme de Chandy et Lamport [CL85] permet de détecter des propriétés stables (terminai-son, interblocage. . . ) sans construire explicitement les exécutions, et l'algorithme de Marzullo etSabel [MS94] concerne des propriétés localement stables (propriétés stables isolément sur chaqueprocessus). On peut aussi restreindre φ, par exemple à des conjonctions de prédicats locaux àchaque processus ou à des prédicats linéaires [CG98, CBDGF95].

Cette notion d'état global cohérent est donc une notion d'observation de l'exécution d'unsystème réparti, et ne vise pas à introduire des contraintes dans cette exécution.

2.2.3 Réplication de données

La réplication des données consiste à placer plusieurs exemplaires d'une même donnée surplusieurs sites [Ray92a]. L'objectif est d'améliorer les performances en rapprochant les donnéesdes processus les utilisant et d'augmenter la disponibilité par une meilleure tolérance aux fautescomme l'arrêt d'un site.

La granularité de la réplication s'échelonne depuis les variables d'un programme en passantpar les enregistrements de bases de données jusqu'à des �chiers complets ou même des disques.Une notion de type est associée à chaque donnée. Ce type décrit la sémantique de la donnéeet les opérateurs qui s'y appliquent. Les méthodes de réplication peuvent être ajustées pours'adapter aux propriétés du type. Dans une approche objet, di�érentes stratégies de réplicationpeuvent être imaginées pour chaque classe. Une stratégie de réplication doit assurer un ensemblede contraintes de cohérence qui ont pour but de masquer la réplication vis-à-vis des utilisateursde la donnée. Ce masquage ou transparence de la réplication doit maintenir la sémantique del'entité initiale.

2.2.3.1 Indicateurs (hints)

La contrainte de cohérence peut être a�aiblie suivant les applications, ou, en d'autres termes,suivant la sémantique de la donnée. Par exemple, des algorithmes distribués tels que le rou-tage dynamique utilisent souvent des indicateurs (hints) qui fournissent une information plus oumoins exacte à propos de la localisation d'un serveur [Ray87, CD88, Nee89]. Cette informationreprésente une connaissance locale qui peut être invalide mais utile. Elle fournit un moyen deretrouver l'information exacte après plusieurs étapes intermédiaires. Des indicateurs relatifs à lamême donnée logique peuvent être vus comme des copies. Cependant, il n'existe pas de cohérenceentre eux. Leur protocole de mise à jour est complètement lié à leur sémantique. La propriétéprincipale d'un indicateur est que soit il possède la bonne valeur, soit il n'est plus à jour, auquelcas on détecte immédiatement son invalidité en essayant de l'utiliser, et on utilise alors une autreméthode (plus lente) pour obtenir la valeur à jour.

17


2.2.3.2 Caches

La cohérence au sein des caches mémoire a été abordée à la section 2.2.1. Les méthodes decaches sont aussi adaptées aux systèmes répartis, d'autant plus que l'écart de temps entre unaccès local et un accès distant est important. Dans ce cas, la granularité des données s'étendde la taille des blocs de �chiers, des pages de mémoire virtuelle ou des enregistrements de basesde données, à des �chiers complets comme dans l'Andrew File System [LS90]. Les échanges demessages entre le client local et le serveur distant sont ainsi réduits et l'accès local est beaucoupplus rapide. Cependant, un cache n'augmente pas la �abilité des données, étant donné qu'iln'existe toujours qu'une seule copie principale sur un unique serveur. La défaillance de ce n÷udentraîne une perte des données si une procédure complémentaire de récupération d'erreurs n'apas été prévue.

Les mises à jour soulèvent le problème de la cohérence. Elles doivent être propagées depuis lecache vers le serveur et les copies de la donnée dans les autres caches doivent être mises à jour ouinvalidées. Dans le cas réparti, plusieurs techniques de gestion de cache avec tolérance aux fautesont été conçues tels les leases 2[GC89] ou les mémoires stables [BB91]. Quand un client obtientune donnée dans son cache, il obtient un bail temporaire d'une durée �xée qui lui assure un accèsexclusif en écriture. Tant que le bail n'est pas écoulé, il est donc sûr que la donnée reste valide,sans qu'il soit nécessaire de s'en assurer auprès du serveur. Si le serveur reçoit une demande demodi�cation de la donnée, il doit soit attendre la �n de bail, soit demander au client de le luirendre. Ainsi, en cas de perte de message ou d'arrêt de machine, un bail est tout de même expiréà la �n de sa durée de validité. Cette technique de bail est donc bien adaptée pour des �chiersoù le partage est faible, et dans un environnement où des pertes de messages ou des arrêts demachines peuvent se produire. Il nécessite cependant des horloges synchronisées.

2.2.3.3 Copies multiples

Dans ce dernier type de technique de réplication, les copies sont gérées de manière symétrique.La transparence de la réplication nécessite que les usagers ne voient que la version la plus récented'une donnée logique quelle que soit la copie accédée. Cette propriété est appelée sérialité.

De nombreux algorithmes ont été conçus pour obtenir cette sémantique en dépit des dé-faillances des n÷uds ou du réseau de communication (y compris la partition du réseau).

Un premier algorithme est le vote pondéré (Weighted Voting) [Gif79]. Chaque copie possèdeun nombre de votes. Un quorum de lecture r (respectivement un quorum d'écriture w) doit êtreobtenu pour exécuter une lecture (resp. une écriture) en accédant à un nombre su�sant de copies(sans accéder nécessairement à toutes les copies). La règle principale est que la somme (r + w)doit être plus grande que le nombre total de votes de l'ensemble des copies. De cette manière, laversion la plus à jour appartient toujours à l'ensemble des copies ayant participé au quorum delecture. Cependant, il faut conserver un numéro de version pour détecter la bonne copie. Un faiblequorum de lecture augmente la disponibilité en lecture, mais aussi la taille du quorum d'écriture,ce qui décroît la disponibilité en écriture. De plus, il peut être nécessaire de lire plusieurs copiespour exécuter une lecture logique. C'est le principal défaut de cet algorithme. Des ra�nementssont introduits avec des fantômes (ghosts) pour obtenir une meilleure disponibilité [RT88].

Les algorithmes de copies disponibles (Available Copies [BG84]) ou de régénération [PNP88]ne nécessitent qu'une seule copie pour exécuter une lecture. Par contre, toutes les copies dis-ponibles doivent être modi�ées lors d'une écriture. Des mises à jour con�ictuelles peuvent seproduire lors d'une partition de réseau.

En fait, ces méthodes adoptent des stratégies di�érentes pour la tolérance aux fautes. Quand

2. lease signi�e bail en Français.

18


une copie devient inaccessible, un substitut est créé ou les votes sont réassignés [BGMS86]. Lesalgorithmes di�èrent sur la nature de ce nouveau représentant :

� avec les fantômes [RT88], le nouveau représentant ne contient que le droit de vote ;� avec les témoins (witnesses) [Pâ86, LP91, SPL92], le numéro de version est aussi conservé ;� avec la régénération [PNP88], une nouvelle copie complète est créée.Le cache de données peut être combiné avec de vraies copies. Une copie dans un cache ne

possède pas de vote mais peut être incluse dans n'importe quel quorum. La validité de la copiedu cache est véri�ée dans la mesure où la copie participe à l'obtention du quorum.

Quel que soit l'algorithme utilisé, des études [NA87] ont montré qu'on n'obtenait guère d'ac-croissement de la disponibilité avec plus de deux copies à partir du moment où le temps moyende réparation est faible par rapport au temps moyen entre défaillances.

Le mécanisme de vote précédemment présenté n'est pas le seul existant pour dé�nir des quo-rums. Il existe d'autres méthodes fondées sur une structuration logique des sites qui permettentde réduire le nombre de participants nécessaires à l'obtention d'un quorum, et donc d'améliorerles performances [NMR91].

2.2.3.4 Le compromis CAP

En 1999, Eric Brewer a formulé la conjecture CAP [FB99, Bre00] ultérieurement démontréedans [GL02] 3 qui dit qu'il est impossible d'avoir simultanément :

� la cohérence : tous les sites voient la même valeur pour une même donnée répliquée ;� la disponibilité (availability) : une panne n'empêche pas les sites survivants de fonctionner ;� la tolérance au partitionnement : le système continue à fonctionner même quand un sous-ensemble des sites est déconnecté (ce qui est équivalent à tolérer la perte d'un nombrearbitraire de messages).

Le choix d'abandonner la disponibilité (le système se bloque en cas de faute) ou la toléranceau partitionnement (supposé ne jamais se produire) pour garantir la cohérence est plutôt faitdans le domaine des bases de données, étudiées à la section suivante. Les solutions optimistesconsistent à réduire la contrainte de cohérence pour une meilleure résistance du système.

2.2.3.5 Réplication optimiste

Une large synthèse de la réplication optimiste a été publiée par Saito et Shapiro [SS05]. Leprincipe de la réplication optimiste est d'autoriser l'accès à un réplica sans synchronisation apriori avec les autres réplicas. Les modi�cations sont propagées en arrière plan et les con�its,supposés peu nombreux, sont résolus quand ils sont détectés. À l'opposé, la réplication pessimistegarantit l'absence de con�its par des mécanismes de prévention. La réplication optimiste relâchedonc la cohérence au pro�t de la disponibilité globale. C'est une solution particulièrement inté-ressante dans des environnements fortement dynamiques de type réseau mobile ou réseau ad hoc,dans des réseaux peu �ables (de nouveau les réseaux mobiles mais aussi le classique Internet),ou dans des environnements de très grande taille où le nombre de réplicas rend inadapté lessystèmes pessimistes qui nécessitent une coordination de tous les intervenants. Le défaut est bienévidemment le risque de divergence entre les réplicas ou de con�its irréconciliables entre opéra-tions concurrentes : Where a pessimistic algorithm waits, an optimistic one speculates [SS05, p.44].

De nombreuses approches existent et nécessitent de faire des choix adaptés au système consi-déré :

3. La preuve est similaire à la preuve sur l'impossibilité du consensus en distribué en présence de panne[FLP85].

19


� Peut-il y avoir plusieurs écrivains ? Ou inversement existe-t-il une unique copie maître surlaquelle ont lieu les modi�cations qui sont ensuite propagées aux autres réplicas ? La so-lution à base d'une unique copie maître traite les autres réplicas comme des caches. Vul'absence de modi�cation concurrente, les con�its sont inexistants. Par contre sa disponi-bilité est faible et ses performances médiocres si le taux de modi�cation est élevé.

� Que transfère-t-on entre réplicas : la valeur (l'état) ou l'opération de modi�cation ? Letransfert d'état restreint les opérations à celles de lecture et d'écriture globale de l'objet maisne suppose aucune connaissance sémantique sur celui-ci. La connaissance du plus récentétat su�t à dé�nir la valeur de l'objet, alors que dans le cas de transfert des opérations, ilfaut connaître l'histoire des opérations pour déterminer la valeur actuelle. Si les objets sontde grande taille mais les modi�cations généralement ponctuelles (par exemple un tableurdont on ne modi�e que quelques cellules à la fois), le transfert de l'opération est beaucoupplus économique et peut en outre simpli�er la détection de con�its et en réduire le nombre(sur le tableur, la connaissance des cellules modi�ées permet de savoir s'il y a con�it entredeux modi�cations, et si les cellules sont distinctes, l'ordre d'application des opérations n'apas d'importance).

� L'ordonnancement, que ce soit des états ou des opérations, est-il purement syntaxique oupeut-il exploiter la sémantique ? L'ordonnancement syntaxique n'utilise que les informationsportant sur la date (logique ou temps réel) de la modi�cation, le ou les objet(s) concerné(s),et le site à l'origine. Il peut s'appliquer à tout type de système, sans connaissance a priori desopérations. L'ordonnancement sémantique utilise des propriétés sur les opérations, commela commutativité ou l'idempotence, pour réordonner des opérations. Il présente en outrel'intérêt de réduire les con�its.

� La gestion des con�its : sont-ils ignorés, ou détectés et réparés ? Comme pour l'ordonnan-cement, la détection peut utiliser la sémantique des modi�cations pour a�ner la détectionet la correction. Sinon, seule la date et l'origine permet de détecter et de décider ou pas derejeter une opération, le système n'ayant aucune connaissance sur la manière de fusionnerdes modi�cations.

� Comment sont di�usées les mises-à-jour ? Si la topologie du réseau est �xe et connue, onpeut construire des algorithmes de di�usion à la fois performants (en temps de di�usion)et économiques (en nombre de communications), par exemple par la construction d'arbrede recouvrement ou d'une topologie en étoile. Mais cette approche est peu compatible avecdes systèmes de grande taille (où il y a nécessairement toujours des portions en panneou inaccessibles) ou fortement dynamiques (réseaux mobiles par exemple, dont la topolo-gie variable permet di�cilement de maintenir une structure globale). À l'opposé de cetteapproche quasi-statique, on trouve des algorithmes de type probabiliste, comme l'anti-entropie, ou épidémique, comme la rumeur [DGH+87], dont la modélisation mathématiquepermet de décrire précisément la convergence et le taux de couverture [Fra80].

� Et en�n, quelle cohérence est garantie ? On retrouve les cohérences présentées pour lescaches, notamment la linéarisabilité comme cohérence la plus forte, jusqu'à des cohérencestrès faibles comme la cohérence éventuelle qui dit que, si toute modi�cation cesse, tous lesréplicas �niront un jour par posséder les mêmes valeurs.

2.2.4 Base de données

Contrairement aux caches ou données répliquées où la cohérence concerne un ensemble deréplicas de la même donnée, la cohérence dans une base de données s'occupe d'un ensemble dedonnées distinctes, liées soit implicitement par des contraintes d'intégrité mutuelle, soit explici-tement par les traitements qui leur sont appliqués. La notion de transaction a été dé�nie pour

20


décrire un traitement qui, atomiquement, fait passer d'un état cohérent à un nouvel état cohé-rent. L'objectif du contrôle de concurrence est de faire en sorte que cette atomicité soit en faitvirtuelle, c'est-à-dire que tout se passe comme si chaque transaction était exécutée en isolationet instantanément, alors qu'en réalité, le plus grand parallélisme et le moins de blocage possiblesont recherchés. Par cette atomicité, une transaction est aussi une unité de défaillance : commeon ne peut pas observer d'état intermédiaire, une transaction est exécutée totalement ou pas dutout.

Sans information sur la sémantique des transactions, on ramène la notion d'atomicité à celled'exécution sérialisable : l'exécution parallèle d'un ensemble de transactions est sérialisable si lerésultat est identique à celui obtenu par un ordonnancement séquentiel des transactions.

La notion de graphe de dépendance permet de répondre à la question de savoir si une exécutionest sérialisable. Les sommets du graphe sont les transactions, et les arcs orientés indiquent lesrelations de dépendance entre deux transactions dans l'exécution considérée. Il y a un arc d'unetransaction T1 vers une transaction T2 si une opération de T1 précède et est en con�it avec uneopération de T2. Il y a alors équivalence entre exécution sérialisable et absence de cycle dans legraphe de dépendance [Pap79].

Comme pour la réplication, on trouve deux familles d'algorithmes de contrôle de concurrence,mais toutes deux garantissent la même qualité de cohérence :

� contrôle pessimiste ou continu ou préventif : on garantit l'absence d'apparition de cycledans le graphe de dépendance au fur et à mesure de l'exécution des transactions. Cela peutse faire en utilisant explicitement le graphe, ou via des méthodes qui imposent un ordresur les transactions garantissant l'absence de cycle : estampillage, verrouillage. . .

� contrôle optimiste ou de certi�cation : le contrôle n'est fait qu'à la terminaison de chaquetransaction, en validant celle-ci ou en l'annulant si nécessaire.

La notion d'annulation d'un traitement en cours fait apparaître dans les bases de donnéesun problème supplémentaire : comment réaliser la sauvegarde ou la restauration de l'état desdonnées pour qu'un traitement sans e�et soit vu sans e�et. De multiples méthodes ont étéproposées [CMSW93] :

� sauvegarde de la valeur : avant toute écriture, la valeur courante est sauvegardée dans unjournal pour pouvoir être restaurée en cas d'annulation ;

� sauvegarde de l'opération : avant toute opération de modi�cation, l'opération inverse estsauvegardée pour pouvoir être appliquée et retrouver l'état initial ;

� liste d'intentions : les écritures à faire sont conservées en mémoire et ne sont réalisées qu'àla validation e�ective de la transaction ;

� shadow copies : une copie est créée à la première écriture par la transaction, et cette copieremplacera la valeur d'origine à la validation, ou sera éliminée en cas d'annulation.

2.3 Nos contributions

2.3.1 Approches spéci�ques à la cohérence

Dans le cadre multimédia, nous nous sommes intéressé à la dé�nition de la cohérence et auxprotocoles nécessaires à la préservation de relations entre des données non ponctuelles. Classi-quement, un modèle pour les systèmes répartis est constitué d'événements liés par une relationde précédence causale. Nos études se sont situées dans le cas où ces événements ne sont plus ato-miques mais où ils ont une durée. L'approche classique dans le cas d'objets non atomiques, quece soit pour la cohérence causale dans les caches ou pour les transactions, consiste à considérerune exécution linéarisée équivalente, ce qui revient à rendre atomiques les objets non élémen-taires. À l'opposé, nous avons dé�ni des relations de précédence prenant en compte la structure

21

2.4 - Quelques autres contributions liées à la répartition

complexe des objets (ici des �ux multimédias), et nous avons étudié comment les préserver lorsde la transmission des �ux dans un système réparti. Ce sujet est développé au chapitre 4.

Un deuxième sujet a été la cohérence mutuelle d'un ensemble de données. Notre approches'est fortement distinguée de l'approche transactionnelle car l'objectif n'était pas de dé�nir etd'implanter des traitements conservant la cohérence globale du système (ce qui est l'approchetransaction), mais de fournir aux traitements un ensemble cohérent d'entrées. Dans un systèmeréactif, les traitements sont activés indépendamment (ou pas) des entrées, notre objectif est alorsde proposer un ensemble de valeurs qui forment un ensemble cohérent vis-à-vis de leurs origines.Outre ce changement de point de vue (traitements vs valeurs), nous avons particulièrement étudiéla mise en ÷uvre dans des systèmes temps réel. Ce sujet est présenté au chapitre 5.

Le dernier point présenté dans ce mémoire concerne la cohérence temporelle d'une chaîne detraitements et de transmissions d'information. La question est de déterminer comment spéci�erune telle chaîne et comment l'étudier, par exemple pour en déterminer la faisabilité, ce qui aconduit à dé�nir un système comme un ensemble de �ots de données à contraintes temporelles.Ces travaux sont développés au chapitre 6.

2.3.2 Aspects formels

Un second point sous-jacent à toutes nos études a été la volonté de formaliser tous les conceptsintroduits, de manière à lever toute ambiguïté de dé�nitions et à pouvoir raisonner rigoureuse-ment et éventuellement automatiquement dessus.

Ainsi, les travaux sur les �ux coordonnés (chapitre 4) et la cohérence mutuelle (chapitre 5)ont introduit des relations de précédence (ordre, ordre partiel, pré-ordre, . . . ) permettant dedé�nir précisément les notions de précédence et de cohérence que nous présentons.

Les systèmes de transitions sont par ailleurs le support du chapitre sur les �ots de donnéesà contraintes temporelles (chapitre 6) : la spéci�cation formelle d'un système s'exprime dans cecadre, et des travaux d'automatisation de la véri�cation ont été menés en se ramenant à dessystèmes de transitions classiques, exprimés en TLA+ et Spin. TLA+ a aussi servi de forma-lisme pour la description de la relation à la base de la cohérence mutuelle et pour son codage(chapitre 5).

2.4 Quelques autres contributions liées à la répartition

Nous présentons sommairement ici quelques contributions qui se situent en périphérie ducadre de ce mémoire : le domaine d'application reste néanmoins les systèmes répartis et l'approcheformelle est toujours présente.

2.4.1 Réseaux ad hoc

Ces travaux, e�ectués en collaboration avec l'équipe ARLES de l'INRIA, visaient à formaliseret démontrer un algorithme de constitution de groupes dans des réseaux ad hoc. Un tel algorithmea pour rôle de déterminer un sous-ensemble de sites tel que tous sachent qu'ils sont dans le groupeet quels sont les autres membres. Cette notion de groupe est à la base de la di�usion �able etdes mécanismes de tolérance aux fautes. Ce sujet a été principalement étudié dans les années1990 pour les réseaux locaux (Birman avec Isis [Bir91] étant un des avocats de cette approche,mais de nombreux autres systèmes sont apparus dans ces années-là [KT91, Cri91, Cri96, RBM96,MMSA+96, CKV01]), et ce ne sont pas les résultats théoriques d'impossibilité [CHTCB96] quien ont limité l'intérêt pratique. Le contexte des réseaux ad hoc est su�samment di�érent pourmériter des algorithmes spéci�ques :

22


Figure 2.2 � Partitions en cliques

� tout site peut apparaître ou disparaître à tout moment, et il semble peu envisageabled'utiliser des algorithmes asymétriques de type un maître élu coordonnant les autres sites ;

� la taille du réseau et sa permanente évolution rendent caduque la notion d'état global,trop incertain, peu signi�catif, et complexe à dé�nir ; en particulier la structure précise duréseau est et reste une inconnue ;

� le passage à l'échelle est essentiel : que ce soit par la taille du système lui-même, ou la tailledes changements de con�guration (disparition soudaine de tout une partie des sites) ;

� les travaux classiques s'appuyaient sur de la communication point-à-point, ou éventuelle-ment sur de la di�usion globale dans le cas de petits réseaux locaux. Dans le cas des réseauxad hoc, la communication naturelle est la di�usion locale sur un périmètre physique dé-pendant principalement de l'émetteur : l'émetteur n'indique pas de destinataire et seul unsous-ensemble du réseau reçoit ses messages ;

� les groupes ne sont pas dé�nis a priori mais apparaissent à la volée, de manière ad hoc, enfonction des besoins applicatifs et de l'entourage ;

� en�n, les contraintes de gestion de ressources, en particulier d'énergie, sont à prendre encompte.

À partir d'un algorithme mis au point par l'équipe ARLES [BIL04, LSSI05], nous avonsformellement développé un algorithme de construction de groupes pour les réseaux ad hoc, quiconstruit des groupes maximaux. L'algorithme fonctionne par une succession de phases où dessites singletons explorent leur environnement pour trouver d'autres singletons ou d'autres sitesdéjà groupés, de manière à se joindre à eux.

Du fait du type de communication, un groupe doit nécessairement former une clique, c'est-à-dire un sous-graphe complet : tout site doit communiquer directement avec tout autre site dugroupe. La notion de groupe maximal est ici que le réseau se trouve �nalement partitionné en unensemble de cliques qui ne peuvent plus être fusionnées pour réduire le nombre de groupe. Celane signi�e pas que le nombre de groupes constitués est minimal. Par exemple sur la �gure 2.2,les deux partitions sont valides et maximales, vu qu'il est impossible de fusionner des groupesdans aucune d'elles.

L'algorithme fonctionne en une succession de phases de durée �xée (cf �gures 2.3 et 2.4).La phase de découverte permet à chaque site de découvrir ses voisins : un site qui reçoit unmessage découverte répond à son tour par un message découverte avec son identité. Puis le sitedi�use un message de jonction avec ses voisins : un site connaît donc �nalement tous ses voisinsà distance 2 (cf �gure 2.5). Selon cette connaissance, le site décide alors de former un groupeet di�use le groupe qu'il a ainsi constitué, ou d'attendre de recevoir une proposition (messageinclusion).

L'algorithme a été intégralement formalisé en TLA+ (cf annexe A.1) et véri�é pour des petitsréseaux par le véri�cateur de modèle TLC. Plusieurs modèles de la communication ont été utilisés,depuis un réseau totalement asynchrone et avec perte (présenté en A.2) à un réseau synchronesans mémoire (présenté en A.3) en passant par un réseau ordonné et �able. Bien évidemment,plus le modèle du réseau est contraint, plus l'espace d'état est réduit et le véri�cateur de modèleparvient à explorer des réseaux de taille un peu plus grande.

23


Découverte (singleton)

Dissolution (groupé)Expiration de T (groupé)

Découverte

Découverte

Jonction

Jonction Inclusion

Exclusion

Inclusion

T1 T2 T3 Tgroupéconstitutiondécouverte expectatif

Figure 2.3 � Phases de l'algorithme

?découverte;!découverte

(!inclusion)*T2;

(T \/ ?dissolution);!découverte

T2(!inclusion)* T2

!inclusion

Constitution

Constitution−in

Groupé Singleton

Découverte

!découverte

?jonction

?découverte

?inclusion

T1; !jonction

?jonction

?inclusion

T3

?inclusion

?jonction

Expectatif

Figure 2.4 � Automate d'état d'un site

24


15

7

9

12

5

8

3 6

11

1310

2

Figure 2.5 � Voisinages

La description d'origine de l'algorithme était en français et en pseudo-code. La modélisationTLA+ a mis en évidence des oublis (situations non prévues), un bug (mauvais comportement se-lon le choix des délais de garde) et des approximations et incertitudes provenant de la descriptionen langue naturelle. Il a été possible de montrer la correction (un site est dans un seul groupe etchaque groupe est un sous-graphe complet), la convergence (chaque site est �nalement dans ungroupe), la stabilité (en absence de changement dans les liens de communication, les groupes nechangent pas) et l'optimalité (il est impossible de fusionner les groupes construits). Les résultatssont publiés dans [FIM+05].

2.4.2 Mobilité

Plusieurs études en marge de nos travaux ont été menées dans le cadre des agents mobiles.

2.4.2.1 Formalisation de la mobilité

Tout d'abord, nous avons cherché comment exprimer, le plus simplement possible, les caracté-ristiques essentielles de la migration ou de la mobilité [CFM+99a]. Ce travail a été e�ectué dansle formalisme Unity [CM88] mais s'applique à tout formalisme de systèmes de transitions décritspar des variables et des actions. Le principe élémentaire consiste à attacher à chaque variable unelocalisation. Une migration est alors un changement de cette localisation. La migration ne pou-vant pas être considérée comme instantanée, une variable peut n'être temporairement sur aucunsite. Un mapping (placement) d'une action est possible si elle ne référence que des variables d'unmême site. Auquel cas, elle pourra être trivialement traduite en code exécutable.

Aussi simple que soit cette formalisation de la mobilité, elle s'est avérée pour autant su�santepour décrire des algorithmes simples, comme l'exclusion mutuelle à base d'un jeton mobile, oucomplexes, comme l'algorithme de Naimi-Trehel [NTA96].

25


2.4.2.2 Reconstruction d'une exécution mobile

Nous nous sommes aussi intéressés à la reconstruction d'un calcul mobile di�usant. Tradition-nellement, un calcul réparti est considéré comme constitué d'un ensemble de sites qui s'échangentdes messages, et l'on connaît bien le codage nécessaire à la reconstruction d'une exécution dansce contexte (vecteurs d'horloges notamment). Dans un calcul mobile, le �ot de contrôle n'estpas formé par les sites, mais par les agents quand ils migrent. Le �ot de contrôle suit ainsi lesmigrations, alors que les sites ne servent que de support à l'information pérenne. Une formeparticulière de calcul est le calcul initié par un agent avec scission pour créer de nouveaux agentsd'exploration. Cela forme un calcul di�usant, où le graphe correspondant véri�e que tout n÷uda au plus deux prédécesseurs, et s'il en a deux, un et un seul prédécesseur est sur le même site.

Un tel calcul s'abstrait en trois opérations :� End : l'agent mobile se termine ; cela correspond à une feuille de l'arbre ;� Split : l'agent mobile se scinde en plusieurs nouveaux agents, qui partent vers plusieursautres sites ;

� Follow : l'agent mobile part sur un autre site.Nous avons proposé les vecteurs de chemins pour coder un tel calcul [QFMP00, FMPQ03a,

FMPQ03b]. Ce codage présente plusieurs propriétés intéressantes :� il n'est pas plus coûteux que le codage classique de la causalité par vecteurs d'horloges, etsa complexité en taille est liée au nombre de sites, pas à la longueur du calcul ;

� il permet de reconstruire l'intégralité du calcul di�usant, uniquement à partir de l'informa-tion contenue dans les feuilles. Cela signi�e qu'il su�t de collecter celles-ci pour reconstruirel'intégralité des n÷uds internes ;

� il permet de construire simplement un algorithme de détection de terminaison du calcul,toujours uniquement en collectant les feuilles. Cela signi�e qu'il su�t qu'un agent se ter-minant transmette à un site collecteur le vecteur de chemins qu'il transporte.

2.4.3 Simulation parallèle

Une collaboration avec le CNES et SpaceBel a conduit à étudier la simulation parallèle desystèmes spatiaux [MPQ07, MPQD09].

Dans la simulation de systèmes physiquement distribués, on cherche à exploiter les particula-rités du modèle d'exécution répartie des systèmes de façon, d'une part, à garantir une simulationcorrecte et déterministe des systèmes réels et, d'autre part, à optimiser l'exécution de ces simu-lations. L'optimisation des simulations repose sur deux approches :

� soit par parallélisation des simulations : la simulation de plusieurs sous-systèmes peut êtreréalisée en parallèle comme dans le système réel ;

� soit par allongement des pas de simulation de chaque système. Ceci diminue les commuta-tions de sous-systèmes simulés, optimisant ainsi les temps d'exécution des simulations.

L'hypothèse de séparabilité physique indique qu'il n'y a pas d'événements simultanés vis-à-visde la simulation entre certains composants du système global. Ceci signi�e que les composantsou sous-systèmes peuvent évoluer par étapes de simulation de façon autonome et déterministe.Ces conditions reviennent en fait à assurer que lorsqu'une étape de simulation d'un sous-système�xé S débute, on connaît l'ensemble des événements issus des autres sous-systèmes qui arriverontdurant cette étape. On assure ainsi qu'aucun événement à prendre en compte ne sera oubliédurant l'exécution de l'étape, oubli qui contraindrait à recommencer une étape de simulation(backtracking). Un cas particulier assurant cette condition est qu'aucun événement provenantdes autres sous-systèmes ne parvienne au sous-système S durant le déroulement de l'étape.

Les sous-systèmes interagissent par émission d'événements (ou de messages, ce qui est ana-logue pour la simulation). De telles interactions impliquent un délai entre l'événement d'émission

26


du signal ou message par le composant émetteur et celui de réception (de perception) du signal oumessage par le composant récepteur. Ce type de délai constitue un élément fondamental dans lecalcul des intervalles qui permettront de découper la simulation en étapes. Un second paramètreimportant est la fréquence des interactions entre sous-systèmes. Celle-ci peut être exploitée pourdéterminer, dans des cas particuliers, les intervalles les plus longs possibles � d'autonomie � dechaque sous-système.

L'exécution de la simulation est décomposée en étapes éventuellement parallèles qui serontactivées et contrôlées par un ordonnanceur. Une étape consiste en un pas de simulation exécutépar un sous-système particulier (cas d'un ordonnancement séquentiel) ou un ensemble de sous-systèmes en parallèle (cas d'un ordonnancement parallèle). Dans le cas d'une simulation parallèle,l'ordonnanceur apparaît alors comme un synchroniseur qui doit attendre la �n de chaque étape :la terminaison d'une étape correspond en e�et à la terminaison de tous les pas de simulation dechaque sous-système.

Dans un tel schéma de simulation, la séparabilité assure que tous les messages qui devrontêtre traités par les sous-systèmes actifs lors d'une étape, sont disponibles dès le début de cetteétape ou, ce qui revient au même, ont été émis lors d'une étape précédente garantissant ainsi lacohérence et le déterminisme de la simulation sans nécessiter de retour arrière.

Une simulation optimale repose sur un compromis dépendant essentiellement du coût decommutation d'un pas de simulation d'un sous-système à un autre sous-système. En e�et, uneexécution par étapes séquentielles permet d'obtenir des pas de durée plus longue au prix de laperte du parallélisme. Inversement, l'exécution d'étapes parallèles contraint des pas de simulationplus courts et donc des commutations et synchronisations d'étape plus fréquentes. Di�érentscas de con�guration ont été étudiés (communication par mémoire partagée, communication parmessages avec délais connus, communication par messages à fréquence connue. . . ) de manière àdéterminer les paramètres optimaux, à la fois de degré de parallélisme et de longueur de pas.

Cette étude ne doit pas être confondue avec l'exécution optimale d'une simulation par pa-rallélisation et/ou répartition en composants utilisant une infrastructure de simulation de typeHLA. En e�et, dans ce cas, l'optimisation de la simulation ne prend pas en compte les propriétéstemporelles particulières des composants. La parallélisation de l'exécution de la simulation re-pose dans ce cas sur l'algorithme de publication d'événements datés issus de chaque composanta�n que chaque composant puisse s'exécuter au plus tôt et en parallèle avec les composants quiinteragissent avec lui.

27

Deuxième partie

Données, répartition et cohérence

29

Chapitre 3

Introduction

Cette partie contient trois chapitres (outre celui-ci et la conclusion) qui présentent en détailmes principaux thèmes de recherche sur les dernières années. Tous les thèmes évoqués dans lasynthèse de mes activités de recherche (chapitre 2) ne sont pas développés.

31

Chapitre 4

Flux multimédias coordonnés

4.1 Introduction

Les travaux présentés dans ce chapitre découlent des thèses de Romulus Grigora³ [Gri03]et Cezar Ple³ca [Ple07], à l'encadrement desquelles j'ai participé. Ces thèses portaient surl'adaptation de contenus multimédias et les politiques de préchargement de �ux (partie enca-drée par Vincent Charvillat) et sur l'introduction de la causalité dans les dépendances entre�ux, sujet présenté ici. Sur ce domaine, ces travaux ont notamment donné lieu aux publicationssuivantes : [PGQP05a, PGQP05b, PGQP05c, PGQ+06].

La problématique abordée concerne la cohérence de présentation d'un ensemble de �ux mul-timédias, di�usés vers un ensemble de participants depuis un ensemble de sources, et tels quel'existence de certains �ux découle de la réception d'autres �ux. L'idée est que, quand certains�ux dépendent causalement d'autres �ux, leur présentation à l'usager doit aussi respecter cesdépendances. Dans ce chapitre, nous développons d'abord la problématique, la notion de syn-chronisation de groupe qui la sous-tend, et les manières existantes de décrire les relations entre�ux. Nous présentons ensuite les principes que nous avons dé�nis pour lier �ux et causalité,et en particulier une taxinomie des relations entre �ux. Nous montrons en�n comment la cau-salité entre �ux peut être mise en ÷uvre e�cacement en s'appuyant sur des communicationsmultimodales.

4.2 Cohérence dans les systèmes multimédias répartis

4.2.1 Problématique

Un système multimédia réparti échange des données de nature et d'origine diverses, certainesdiscrètes, d'autres continues. La spéci�cité d'un tel système réside dans les données continues,qui peuvent provenir de la numérisation d'une source ou d'une construction synthétisée à partirde données discrètes. Ces données continues sont des �ux multimédias, qui, d'un point de vueinformatique, sont constituées de données discrètes présentées de manière contiguë dans le temps.Pour un utilisateur, la perception d'un tel �ux est donc équivalente à une perception continue,à condition que la qualité de service soit su�sante. Cette qualité de service est à la fois liée àla continuité du �ux lui-même, mais aussi à la synchronisation nécessaire entre di�érents �uxformant un ensemble cohérent.

Dans un système réparti, un �ux est transmis sous la forme d'une séquence de messagesd'un émetteur vers un ou plusieurs destinataires. Un �ux n'est donc pas une entité élémentaire,

33

4.2 - Cohérence dans les systèmes multimédias répartis

P1

P2

P3

P4

audio.b audio.e

video.b video.e

audio

video

video

video

audio

audio

Figure 4.1 � Incohérence de perception des �ux

atomique, et nous introduisons dans la suite la notion de dé�lement pour traduire la globalitéde l'émission ou de la réception d'un �ux (ou d'un morceau de �ux).

Tout comme dans un système réparti où l'on manipule des messages, la communication deplusieurs �ux pose des problèmes d'ordonnancement de la délivrance des �ux. L'objectif estd'obtenir une présentation cohérente de l'ensemble des �ux présentés à l'utilisateur. Considéronsl'exemple de la �gure 4.1, dans lequel un utilisateur P1 génère un �ux vidéo qui est di�usé auxtrois autres participants. À la réception de ce �ux vidéo, l'utilisateur P2 génère un commentaireaudio sur les images de ce �ux, et ce commentaire est di�usé aux autres participants. On peutdonc dire que le �ux vidéo est la cause du �ux audio. Il faut donc que le �ux vidéo soit vu par tousles participants avant le �ux audio. L'exécution de la �gure 4.1 présente plusieurs incohérences :

� Pour le participant P4, le �ux audio démarre avant le �ux vidéo, alors que c'est l'inversepour le participant P3. Si l'on cherche à être cohérent avec l'émission, vu que P2 engendrele �ux audio après le début de la réception du �ux vidéo, il faudrait que le démarrage du�ux audio soit perçu après le démarrage du �ux vidéo, comme sur P3.

� Le participant P2 termine son émission audio avant la �n de sa réception du �ux vidéo.Mais sur P3, le �ux audio se termine après le �ux vidéo.

Traditionnellement, les solutions apportées sont :

� applicatives : le �ux audio est augmenté des numéros d'image du �ux vidéo, et la délivranceassure la synchronisation. Cette solution est bien adaptée au cas où les deux �ux ont lamême source (cas d'un �lm accompagné de sa bande sonore). Dans le cas où les �ux ontdes origines distinctes (par exemple un serveur vidéo + un serveur audio), il est nécessaired'avoir enrichi hors ligne le �ux audio.

� ad-hoc : une solution spéci�que est par exemple présentée dans [STT02]. Elle utilise desdoubles vecteurs pour capturer la causalité entre deux �ux.

Nous allons ici reposer le problème dans le cas général et proposer une modélisation desrelations entre �ux exclusivement à partir de la notion de causalité. Cette simpli�cation vapermettre de dé�nir les relations causales possibles entre �ux et d'utiliser ensuite les techniquesstandard (vecteurs et matrices d'horloges, piggybacking) pour détecter les incohérences causales.Le cadre applicatif est celui des applications multimédias interactives réparties, où les interactionsentre �ux ne sont pas connues a priori.

34

Chapitre 4 - Flux multimédias coordonnés

4.2.2 Cohérence et synchronisation usuelles

Les �ux multimédias nécessitent di�érents besoins de synchronisation ou de coordination :� Synchronisation intra-�ux : liée à l'ordre et la fréquence de présentation des unités d'un�ux. C'est par exemple ce qui est nécessaire pour assurer qu'un �ux audio est correctementperçu par l'utilisateur, en évitant rupture de son ou variation de vitesse.

� Synchronisation inter-�ux : liée à la dépendance entre unités appartenant à des �ux di�é-rents. C'est par exemple la synchronisation audio-vidéo d'un �lm qui doit assurer que lesparoles sont synchrones avec le mouvement correspondant des lèvres.

� Synchronisation de groupe : liée au fait qu'un ensemble d'utilisateurs perçoivent la mêmeprésentation, ou tout au moins des présentations cohérentes. Ce type de synchronisationest particulièrement nécessaire dans les applications de travail coopératif.

Notons que le vocabulaire n'est pas parfaitement �xé : dans le troisième cas, on parle souventplutôt de coordination, et les auteurs de culture � système réparti � parle de cohérence.

Les synchronisations intra-�ux et inter-�ux prédé�nies ont été largement traitées et ne sontpas le sujet des travaux ici présentés. On se reportera par exemple à [BS96, IT00] pour unesynthèse des résultats. Bien que des travaux existent sur la synchronisation de groupe [EPD94,AY96, JK03, ITT97, ITTI03], ceux-ci sont moins nombreux et s'intéressent souvent plus à ladi�usion d'un ensemble de �ux prédé�nis (type d'interactions Single Source Multicast) qu'auxéchanges mettant en jeu un ensemble d'utilisateurs (type Any Source Multicast).

4.2.3 Synchronisation de groupe

La coordination de groupe est un sujet connu dans les systèmes répartis (Isis [BR94],Amoeba [KT91], Totem [MMSA+96] et bien d'autres [Cri96, Sch06]). De même la synchronisationintra/inter-�ux a été longuement étudiée dans les contextes multimédias, mais la synchronisationde groupe dans des applications multimédias est un sujet moins développé. Nous présentons toutd'abord des approches basées sur l'existence d'une horloge globale, puis des approches basées surla connaissance des caractéristiques réseau.

4.2.3.1 Approches basées sur des horloges synchronisées

En présence d'une horloge globale, un mécanisme simple peut être mis en ÷uvre pour coor-donner un ensemble de �ux di�usés vers un ensemble de participants : toutes les sources de �uxcommencent à envoyer les messages du �ux à la même date, et tous les récepteurs commencentla présentation à la même date. Ainsi, une parfaite synchronisation de groupe est obtenue. Plusprécisément, on considère que les sources se mettent d'accord sur une date de départ t0, date àlaquelle elles commencent à envoyer des messages. Ainsi, un élément e d'un �ux est émis à ladate t0 + TS (e), où TS (e) est l'estampille temporelle associée à l'élément e dans son �ux. Ausein d'un groupe G de récepteurs, la présentation des �ux débute à t0 + ∆G . L'élément e estalors présenté à l'instant t0 + ∆G + TS (e), chez tous les récepteurs. Il est donc important quele paramètre ∆G soit su�samment grand pour que les premiers éléments de chaque �ux soientarrivés à tous les récepteurs du groupe avant t0 + ∆G . Les éléments arrivés avant t0 + ∆G sontmémorisés dans un tampon a�n de rendre égaux les délais de transfert des di�érents �ux, etd'éventuelles �uctuations réseaux sont lissées par ce paramètre ∆G .

Si l'on connaît a priori les conditions réseau les plus défavorables, la valeur de ∆G peut être�xée en début de session. À l'inverse, l'on peut souhaiter adapter ce paramètre dynamiquementen fonction des conditions. De telles méthodes adaptatives cherchent à trouver un bon compromisentre le taux de perte (messages trop tardifs, donc inversement corrélé avec ∆G) et délai de bouten bout (directement lié à ∆G).

35


message decontrôle

message dedescription

message demise à jour

Initiateur Source Destination

Figure 4.2 � Flow Synchronisation Protocol

Un exemple de système implantant ce protocole est Flow Synchronization Protocol [EPD94].Il prévoit plusieurs con�gurations de communication : un-vers-plusieurs, plusieurs-vers-un etplusieurs-vers-plusieurs (one-to-many, many-to-one, many-to-many). L'existence de l'horlogeglobale permet d'assurer le même délai de bout en bout pour tous les destinataires réunis dansun même groupe. Le protocole distingue trois types de participants : l'initiateur, les sources etles destinations (cf �gure 4.2). L'initiateur envoie des messages de contrôle vers les sources et lesdestinations pour initialiser les paramètres de la session (le temps de référence t0, le délai initialde bout en bout ∆G), mais aussi pour les changer en cours de session. Chaque source transmetaux destinations des messages qui décrivent les caractéristiques des �ux émis, puis sur l'indica-tion de l'initiateur le contenu lui-même des �ux. Les destinations sont regroupées en groupes desynchronisation en fonction des �ux reçus. Dans un groupe de synchronisation, les destinationséchangent régulièrement des messages de manière à ajuster le délai de synchronisation ∆G .

4.2.3.2 Approches basées sur la connaissance des délais réseau

En absence d'horloges synchronisées fournissant directement un temps global, il est possibled'utiliser des informations sur le réseau pour coordonner les �ux. Ainsi Akyildiz et Yen présententdans [AY96] des protocoles de synchronisation de groupe pour di�érents cas un-vers-plusieurs,plusieurs-vers-un et plusieurs-vers-plusieurs. La connaissance a priori de la distribution des délaisde bout en bout ou de la distribution des dérives des horloges n'est pas nécessaire mais il faut parcontre connaître la borne supérieure des délais de bout en bout. Leurs protocoles fonctionnenten utilisant des phases de négociation pour ajuster au mieux les paramètres. Des simulationsavec un seul �ux leur permettent d'évaluer les valeurs minimales, moyennes et maximales desdésynchronisations et montrent dans quels cas leurs protocoles sont adéquats.

36


Dans [Ben00], l'auteur propose un schéma de synchronisation de groupe qui ne repose passur des horloges synchronisées. Les latences réseau maximales sont ici aussi supposées connues.Un unique site source gère les informations de contrôle et les di�use vers toutes les destinations.L'auteur montre l'e�cacité de cette méthode à travers des simulations. Néanmoins, la structuretemporelle interne des �ux n'est pas prise en compte.

4.2.3.3 Approches basées sur le temps virtuel

Ishibashi et Tasaka proposent dans [ITT97] trois schémas de synchronisation de groupe baséssur un algorithme utilisant le concept de virtual-time rendering (VTR) [IT95], qui est applicabledans des contextes réseau dont on ne connaît pas les délais maximaux. Il utilise des horlogeslocales synchronisées et ajuste dynamiquement la date de présentation (rendering-time) d'unélément en fonction des conditions réseau. Bien que les travaux aient originellement été faitspour des �ux et scénarios prédé�nis (stored media), des adaptations ont été apportées pourprendre en compte la non-connaissance de toutes les caractéristiques des �ux (live media), et lemélange de �ux enregistrés et en direct [ITM00]. Les schémas étudiés sont :

� Master-Slave Destination Scheme. Les destinations sont classi�ées en une destination maîtreet des destinations esclaves. Les destinations esclaves ajustent leur temps de présentationdes éléments conformément à la destination maître. Ce schéma est dissymétrique et favorisel'une des destinations, les autres devant s'adapter à son rythme et à son décalage, quitteà se désynchroniser ou à fournir une médiocre qualité de présentation. Simple à mettre àen ÷uvre, il ne convient qu'à des applications où il existe naturellement une destinationprivilégiée vis-à-vis des autres. Par exemple dans une vidéo-conférence, le site du présidentde la séance peut être choisi en tant que destination maître.

� Synchronization Maestro Scheme. Un agent de synchronisation appelé maestro collecte lestemps de présentation de toutes les destinations et di�use une information de contrôle pourarbitrer le temps de présentation à chaque destination. Comme le schéma maître-esclave,ce schéma est un mécanisme de contrôle centralisé mais il gère d'une manière équitabletoutes les destinations. Dans ces deux schémas, si le maître ou le maestro ne peuvent pascommuniquer avec les autres sites ou cessent de fonctionner, aucune autre destination n'estcapable de prendre en charge la transmission des informations de contrôle et la gestion dela synchronisation.

� Distributed Control Scheme. Ce schéma a été proposé pour améliorer la faiblesse des deuxapproches centralisées. Dans [NT03], les auteurs montrent les résultats d'une série de simu-lations qui permettent de comparer les trois schémas, en termes de QoS au niveau applicatif.Sans surprise, les simulations montrent que le meilleur schéma dépend des con�gurationsréseau et du niveau de désynchronisation toléré.

4.2.4 Spéci�cation des relations temporelles

La description de la synchronisation entre plusieurs �ux s'appuie sur un modèle temporelqui permet de caractériser les �ux et leurs relations. Quand on considère un temps linéaire(i.e. où le temps est représenté par un ensemble support muni d'un ordre total), ce modèletemporel [Haj96] peut être fondé sur des instants (instant algebra ou point algebra [KL91]) oudes intervalles (interval algebra [All83]). En e�et un �ux (ou un morceau de �ux) multimédia estessentiellement dé�ni par son instant de début, sa durée de présentation et son instant de �n,sachant que l'une des trois informations est redondante. Selon que l'on s'attache à une descriptiondes �ux à partir des instants de début et de �n, ou au contraire à partir de la durée, les relationsexprimables entre �ux ne seront pas les mêmes.

37


Figure 4.3 � Temps non linéaire sans point de branchement

4.2.4.1 Temps linéaire/non linéaire/à ordre partiel

Temps linéaire. La modélisation du temps est dite linéaire si le temps est représenté par :� un ensemble support T ;� une relation d'ordre totale sur ce domaine, notée ≤. La relation stricte correspondante estnotée < : x < y

∆= x ≤ y ∧ x 6= y .

Selon les besoins, le domaine support peut être :� borné supérieurement (i.e. tel que ∃M : ∀t ∈ T : t ≤ M ), selon que l'on s'intéresse à desexécutions nécessairement �nies ou au contraire à des exécutions in�nies ;

� borné inférieurement (i.e. tel que ∃m : ∀t ∈ T : m ≤ t), selon que l'on considère qu'il existeun début ou pas ;

� dense (i.e. tel que ∀x , y ∈ T : x < y ⇒ ∃z ∈ T : x < z < y), si l'on souhaite pouvoirdécomposer tout intervalle non singleton ;

� continu ou discret, selon le réalisme de la modélisation.Le temps linéaire modélise bien la perception naturelle du temps réel, totalement ordonné.

Temps non linéaire et arborescent. La modélisation du temps est dite non linéaire si letemps est représenté par :

� un ensemble support T ;� une relation d'ordre partielle sur ce domaine, notée ≤. La relation est partielle s'il existet , t ′ ∈ T : ¬(t ≤ t ′ ∨ t ′ ≤ t), c'est-à-dire qu'il existe des éléments non comparables. Larelation stricte correspondante est notée <.

Les travaux théoriques de modélisation du temps [Haj96, Haj99] se sont concentrés sur lesordres linéaires à gauche (left linearity ou backward linearity, i.e. tel que ∀t , t ′ ∈ T : (∃t ′′ : t ≤t ′′ ∧ t ′ ≤ t ′′)⇒ t ≤ t ′ ∨ t ′ ≤ t .

Il est nécessaire d'y ajouter des axiomes pour imposer des points de branchement (branchingpoints), conforme à l'intuition du temps arborescent, par exemple qui interdit l'existence debranches non connectées à un pré�xe (un � trou � dans le graphe du temps). La �gure 4.3présente des cas de temps non linéaire sans � trou � mais cependant sans point de branchement.Dans les deux cas, les points noirs sont des valeurs du temps T et le rond blanc n'est pas unevaleur. Dans le premier cas, le temps est dense jusqu'à ce qu'il se branche et devient discretensuite ; dans le deuxième cas, le temps est discret, et bien que t1 < t3, t1 < t4, t2 < t3, t2 < t4, iln'y a pas de point de branchement. Le temps arborescent est par exemple le temps de CTL. Ilpermet de modéliser des futurs possibles ou spéculatifs.

Temps à ordre partiel. C'est un cas particulier du temps non linéaire, adapté aux systèmesrépartis, dans lesquels on ne suppose pas l'existence d'une horloge commune. L'ordre est unordre partiel, découlant de l'exécution, et généralement compatible (dérivé ou identique) à lacausalité. Par contre, cet ordre n'est pas linéaire à gauche et les résultats classiques sur le temps

38


equals equalsB BA A

before BA A B after

A contains B B during A

started by B BA starts A

A B B A overlapped byoverlaps

A

A B

B

AB

AB

AB

A B

AB

A Bmeets B met by A

A A finishesBBfinished by

Figure 4.4 � Algèbre d'Allen

arborescent ne s'appliquent pas. C'est sur cette modélisation que nous développons nos travauxet elle sera approfondie section 4.3.

4.2.4.2 Spéci�cation à base d'instants

Dans les relations à base d'instants (algèbre d'instants / Point algebra), les unités temporellesconsidérées sont des points sur la ligne des temps. En particulier pour les �ux, on considère lesinstants de début et de �n de ces �ux. Étant donné deux instants, il existe trois relations possibles :la précédence stricte <, l'égalité = et la succession stricte >. Cet ensemble B = {<,>,=} formeles relations primitives de l'algèbre d'instants.

L'ensemble des relations composées est construit à partir des disjonctions des relations primi-tives. Il existe donc huit relations composées qui sont {∅, <,≤,=,≥, >, 6=,∀}, où ∅ est l'absencede relation et ∀ est la disjonction contenant toutes les relations primitives.

En fait, compte tenu de l'incertitude sur les �ux et de la tolérance nécessaire pour les légères�uctuations des instants de début des éléments et de leur durée, il a été montré [LSS96] que lesquatre relations {<,>,=,∀} sont les seules utiles pour la spéci�cation de scénarios multimédias.

4.2.4.3 Spéci�cation à base d'intervalles

Dans les relations à base d'intervalles (Interval algebra), les unités temporelles sont des inter-valles ayant un début, une durée et une �n. Étant donné deux intervalles, il existe treize relationspossibles : six relations de base (before, contains, started by, �nished by, overlaps, meets), leurs

39


inverses, et la relation d'égalité [All83]. Ces relations sont illustrées �gure 4.4. Ces relationspeuvent aussi être vues en deux classes, celles qui traduisent la séquentialité (before, meets) etcelles qui traduisent le parallélisme (contains, started by, �nished by, overlaps, equals).

Les relations d'Allen ont été couramment utilisées pour décrire des scénarios multimédias,par exemple [LG93, LSI96, JLR98], mais supposent toujours l'existence d'un temps global surlequel sont dé�nis les intervalles.

4.2.4.4 Spéci�cation à base d'opérateurs dédiés

Considérant la di�culté de décrire avec les relations d'Allen des scénarios classiques liant des�ux multimédias, des auteurs ont proposé des opérateurs ad-hoc [KD96, RJMB93, W3C08]. Lesopérateurs sont par exemple :

seq(A,B) : séquence de l'intervalle A suivi de B ;

par-min(A,B) : A et B démarrent en même temps et leur composition se termine dès que lepremier d'entre eux se termine ;

par-max(A,B) : A et B démarrent en même temps et leur composition se termine quand lesdeux sont terminés ;

par-master(A,B) : A et B démarrent en même temps et la terminaison de A provoque laterminaison de la composition.

Ces opérateurs sont dé�nis sur un temps global et sont plutôt adaptés à la description descénarios prédé�nis, bien qu'il soit possible de prendre en compte des aspects interactifs. Ainsil'opérateur par-master peut être utilisé avec un �ux logique qui cesse quand l'utilisateur cliqueun bouton, interrompant ainsi le �ux contrôlé. La structure strictement hiérarchique d'un telscénario est par contre insu�sante pour décrire des scénarios arbitraires, ce qui a conduit àrajouter des arcs de synchronisation [RJMB93] qui cassent la structure d'arbre. Cette adaptationest néanmoins insu�sante pour contrôler des applications totalement interactives, où il n'existeaucun scénario, même grossier, prédé�ni.

4.2.4.5 Spéci�cation à base d'automates

Les réseaux de Petri sont couramment utilisés pour spéci�er de l'ordonnancement et de lacoordination. Dans le domaine du multimédia, on utilise les extensions temps réel. Ainsi a étédé�ni le modèle TSPN Time Stream Petri Nets [DS94] qui permet de formaliser les contraintesde synchronisation intra et inter-média. Une extension hiérarchique HTSPN Hierarchical TimeStream Petri Nets [SDLSS96] a été développée pour décrire, en plus de la synchronisation tem-porelle, la synchronisation logique. Ce modèle opératoire représente les liens hypermédias sousforme de places composites contenant un TSPN et qui ne sont examinées à l'exécution que si lelien est suivi.

Bien d'autres modèles, inspirés des travaux sur les systèmes répartis et/ou temps réel, ont étéproposés pour la description de système multimédia [BBCB97, HM96], par exemple à partir desautomates à états �nis ou des automates temporisés. Le point commun de ces modèles est que leurobjectif est de décrire un scénario (ou un ensemble prédé�ni de scénarios) dans lequel l'utilisateurn'a que quelques possibilités d'interaction (point d'arrêt prédé�ni par exemple). Ces scénariosune fois dé�nis et décrits, on utilise le modèle lui-même comme contrôleur de l'exécution. Àl'opposé, notre objectif est de ne pas supposer de scénarios et de capturer les interactions entre�ux pour en garantir le respect sur tous les sites où ils sont di�usés.

40


Communication parmessages �uxévénement ↔ dé�lement ou run

évt d'émission ↔ dé�lement sourceévt de réception ↔ dé�lement destination

point ↔ segment

Table 4.1 � Analogie entre message et �ux

4.3 Flux et causalité

Un calcul réparti est classiquement décrit dans le modèle événementiel avec événements in-ternes, événements d'envoi de message, événements de réception de message, auxquels s'ajoutela relation de causalité ≺ qui en découle :

� pour tout couple d'événements (e, e ′) issus d'un même processus, tel que e précède e ′ dansla suite associée au processus, la relation e ≺ e ′ est véri�ée ;

� lorsque deux processus échangent un message m, les événements d'envoi e(m) et de récep-tion r(m) sont liés : l'envoi e est la cause de la réception r , donc pour tout message m :e(m) ≺ r(m).

� la relation de causalité est transitive

∀e, e ′, e ′′ : e ≺ e ′ ∧ e ′ ≺ e ′′ ⇒ e ≺ e ′′

Nous proposons ici un modèle inspiré des intervalles pour capturer la notion de �ux.

4.3.1 Dé�lement

Un �ux S est dé�ni par son contenu C (S ), et par les dé�lements du �ux sur le site d'émissionet sur les sites de réception de la di�usion. La notion de dé�lement r (stream run) est uneoccurrence du �ux S sur un site en émission ou en réception. À un dé�lement r , on associe :

� un événement de début r .b,� un événement de �n r .e,� un intervalle r dé�ni par les deux événements précédents r = [r .b, r .e].Le tableau 4.1 présente les correspondances entre la modélisation d'un calcul réparti fondé

sur la communication par messages et celle fondée sur la communication par �ux. La notion dedé�lement apparaît comme l'entité servant d'opérande aux relations causales qui seront dé�niesentre les �ux de façon similaire à la notion d'événement servant d'opérande pour la relation decausalité entre messages.

4.3.2 Relations causales entre dé�lements

Concernant les événements liés aux dé�lements, on retrouve la causalité entre événements descalculs répartis. Par exemple, les événements de début et de �n d'un dé�lement sont causalementordonnés :

∀r ∈ dé�lements : r .b ≺ r .e

Sur la �gure 4.5, il existe par exemple une relation de causalité entre les événements d'émissionde début (respectivement de �n) des dé�lements r1 et r2 :

r1.b ≺ r2.b ∧ r1.e ≺ r2.e

41

4.3 - Flux et causalité

r2.er2.b r2

r1r1.b r1.e

P1

P2

P3

Figure 4.5 � Causalité et dé�lements

Précédence Notation Dé�nitioninitiale ⇀ r1 ⇀ r2

∆= r1.b ≺ r2.b

couvrante initiale ⇀| r1 ⇀| r2∆= r1 ⇀ r2 ∧ r2.b ≺ r1.e

inclusive →| r1 →| r2∆= r1 ⇀ r2 ∧ r2.e ≺ r1.e

faible → r1 → r2∆= r1 ⇀ r2 ∧ r1.e ≺ r2.e

forte |→ r1 |→ r2∆= r1 ⇀ r2 ∧ r1.e ≺ r2.b

couvrante →| r1 →| r2∆= r1 ⇀| r2 ∧ r1 → r2

Table 4.2 � Dé�nition des relations avec dépendance initiale

Des relations de type causal peuvent être dé�nies entre les �ux à partir de la causalité exis-tant entre les di�érents dé�lements qui composent les �ux. Plus précisément, une relation deprécédence causale entre dé�lements existe si et seulement s'il existe une relation causale entreleurs événements de début et/ou de �n.

4.3.2.1 Relations de précédence

La �gure 4.6 schématise toutes les di�érentes relations de précédence entre deux dé�lementspour lesquels il existe une relation entre les deux événements de début. Les deux traits horizontauxreprésentent la progression sur les sites. Une �èche représente un lien causal entre événements(dans le modèle événementiel). Ce lien peut être soit direct, soit induit par un chemin causal.Les �èches en tiret sont les liens causaux minimaux nécessaires à l'existence de la relation dedépendance, les �èches en pointillé sont les liens déduits de ces liens minimaux. Avec uniquementles traits continus et en tiret, on a le diagramme de Hasse de chacune des relations de précédence.

Contrairement à ce qui se fait avec les événements, nous ne cherchons pas à obtenir un ordrepartiel, mais un ensemble de relations de précédence. La relation minimale, notée⇀, impose queles événements de début soient causalement liés :

r1 ⇀ r2∆= r1.b ≺ r2.b

Cette précédence initiale est incluse dans toutes les autres précédences de la �gure 4.6. Cesprécédences correspondent aux di�érentes possibilités de relations causales entre l'événement dedébut du dé�lement r2 et les événements de �n des dé�lements r1 et r2. Le tableau 4.2 donne ladé�nition de ces six relations causales.

Intuitivement, les relations aRb (a et b étant des dé�lements) ont la signi�cation suivante :� précédence initiale (initial precedence ⇀) : le dé�lement a commence avant b, rien d'autren'est connu sur la suite ;

42


r1.b r1.e

r2.b r2.e

r1.b r1.e

r2.er2.b

r1.b

r2.b

r1.b r1.e

r2.b r2.e

r1.e

r2.e

r1.b r1.e

r2.b r2.e

r1.e

r2.b r2.e

Précédence couvrante →|Précédence forte |→

Précédence inclusive →| Précédence faible →

Précédence couvrante initiale ⇀|mid-starting

inclusive weak

strong overlapping

initialPrécédence initiale ⇀

r1.b

Figure 4.6 � Les relations entre dé�lements avec dépendance initiale

43


couv. initiale ⇀|

forte |→

faible →

inclusive →|couvrante →|

initiale ⇀

Figure 4.7 � Hiérarchie des relations de précédence avec précédence initiale

� précédence couvrante initiale (mid-starting precedence ⇀|) : le dé�lement b commence pen-dant a (après le début et avant la �n de a) ;

� précédence faible (weak precedence →) : a est toujours un peu en avance sur b ;� précédence inclusive (inclusive precedence →| ) : b est inclus dans a ;� précédence forte (strong precedence |→) : a est intégralement avant b ;� précédence couvrante (overlapping precedence →|) : a est partiellement avant b et ils serecouvrent partiellement.

La �gure 4.5 illustre la précédence faible entre deux dé�lements r1 et r2. On remarque qu'unprotocole de di�usion ordonnée qui conserverait les relations de précédence doit garantir queles dé�lements de réception sont ordonnés en fonction des dé�lements d'émission. Cela signi�eque sur P3 le début de la délivrance du �ux correspondant au dé�lement d'émission r2 doitcommencer après le début de la délivrance du �ux correspondant au dé�lement d'émission r1, etla �n de la délivrance du �ux correspondant à r2 doit avoir lieu après la �n de délivrance du �uxcorrespondant à r1.

Comme toutes les relations dé�nies contiennent au moins la précédence initiale, toutes lesrelations possibles entre deux dé�lements ne sont pas dé�nies. Par exemple, nous n'avons pasici de relation pour deux dé�lements tels que r1.b ‖ r2.b et r1.b ≺ r2.e (la �n de r2 est causa-lement dépendante du début de r1, sans que leurs débuts ne soient liés). Nous pensons que detelles relations ne sont pas signi�catives pour des applications multimédias réparties. Néanmoins,dans un soucis d'exhaustivité, nous présentons la liste de toutes les relations possibles dans lasection 4.3.3.

4.3.2.2 Propriétés entre relations

Certaines relations sont liées par une implication. Par exemple, et par dé�nition, la précédenceinclusive implique la précédence couvrante initiale :

r1 →| r2 ⇒ r1 ⇀| r2

La �gure 4.7 présente la synthèse de ces implications.Le tableau 4.3 contient les compositions entre les six relations principales. Pour un couple de

relations (sR1s ′, s ′R2s ′′), le tableau spéci�e la relation sRs ′′. Les relations de précédence impli-quant toutes la précédence initiale⇀ et celle-ci étant transitive, on trouve au moins cette relation⇀ par composition de tout couple de relations. Par conséquent, les cases blanches contiennentimplicitement la relation ⇀.

Par exemple, nous avons les relations suivantes :

r1 → r2 ∧ r2 |→ r3 ⇒ r1 |→ r3

44


R1\R2 ⇀ ⇀| →| → |→ →|

⇀ ⇀

⇀| ⇀

→| ⇀| →| ⇀|

→ → |→ →

|→ |→ |→ |→ |→ |→ |→

→| → |→ →

Table 4.3 � Composition des six principales relations de précédences

r1 →| r2 ∧ r2 ⇀| r3 ⇒ r1 ⇀| r3

Remarquons :� les relations de précédence faible, forte et couvrante (trois dernières lignes et colonnes dutableau) constituent un triplet de relations closes par transitivité. Il en est de même pourle couple de précédence faible et forte (→, |→) ;

� les relations de précédence couvrante initiale (⇀|) et couvrante (→|) ne sont pas transitives.� quand deux dé�lements ont pour support le même site, il existe nécessairement une relationde précédence inclusive ou forte ou couvrante.

4.3.3 Inventaire exhaustif des relations

4.3.3.1 Les relations de précédence

A�n d'être exhaustif, en plus des six relations présentées auparavant, la �gure 4.8 donne ladé�nition des relations sans dépendance initiale. Cet inventaire est surtout intéressant du pointde vue théorique, car, en pratique, les relations sans précédence initiale ne sont pas signi�cativespour les applications multimédias.

Les relations possibles (tableau 4.4) entre deux dé�lements sont au nombre de dix plus laconcurrence, l'égalité, et neufs inverses (la croisée étant son propre inverse) :

� six relations avec précédence entre les événements de début des deux dé�lements (initiale,couvrante initiale, inclusive, faible, forte, couvrante) ;

� quatre relations sans information de précédence entre événements de début (élémentaire,�nale, croisée, couvrante �nale) ;

� quatre relations sans information de précédence entre événements de �n (initiale, couvranteinitiale, élémentaire, croisée) ;

� quatre relations avec précédence entre débuts et précédence entre �ns (inclusive, faible,forte, couvrante) ;

� trois relations dites linéaires (forte, inclusive, couvrante) où les quatre événements sonttotalement ordonnés (pas d'événement concurrent). Elles correspondent aux trois relationsque peuvent avoir deux intervalles (sans début ni �n communs) en temps linéaire (relationsd'Allen before, contains, overlaps) ;

45


r1.b r1.e

r2.b r2.e

Précédence élémentaire ⇁

r1.b

r2.b

r1.e

r2.ePrécédence �nale ⇁|

r1.b r1.e

r2.b r2.e

r1.b r1.e

r2.b r2.e

Précédence croisée ⇁| Précédence couvrante �nale |⇁

elementary

mid-ending

�nal

crossed

Figure 4.8 � Les relations entre dé�lements sans dépendance initiale

r1.b ≺ r2.b r2.b ≺ r1.e r1.e ≺ r2.e couvrante→|r2.b ≺ r1.e r1.e ‖ r2.e couvrante initiale⇀|r2.b ≺ r1.e r1.e � r2.e inclusive→|r2.b ‖ r1.e r1.e ≺ r2.e faible→r2.b ‖ r1.e r1.e ‖ r2.e initiale⇀r2.b ‖ r1.e r1.e � r2.e impossibler2.b � r1.e (r1.e ≺ r2.e) forte |→

r1.b ‖ r2.b r2.b ≺ r1.e r1.e ≺ r2.e couv. �nale |⇁et r2.b ≺ r1.e r1.e ‖ r2.e croisée⇁|

r1.b ≺ r2.e r2.b ≺ r1.e r1.e � r2.e couv. �nale inverse |⇁−1r2.b ‖ r1.e r1.e ≺ r2.e �nale⇁|r2.b ‖ r1.e r1.e ‖ r2.e élémentaire⇁r2.b ‖ r1.e r2.e ≺ r1.e impossibler2.b � r1.e impossible

r1.b ‖ r2.b r2.b ≺ r1.e r1.e ≺ r2.e impossibleet r2.b ≺ r1.e r1.e ‖ r2.e élémentaire inverse⇁−1

r1.b ‖ r2.e r2.b ≺ r1.e r1.e � r2.e �nale inverse⇁|−1r2.b ‖ r1.e r1.e ≺ r2.e impossibler2.b ‖ r1.e r1.e ‖ r2.e concurrente ‖r2.b ‖ r1.e r1.e � r2.e impossibler2.b � r1.e impossible

r1.b ‖ r2.bet impossible

r1.b � r2.er1.b � r2.b inverse du cas 1

Table 4.4 � Dé�nition de toutes les relations entre deux dé�lements

46


r1.b ≺ r2.b, r2.b R1 r1.e, r1.e R2 r2.ePPPPPPPPR1

R2 ≺ ‖ �

≺ →| ⇀| →|

‖ → ⇀ impos.

� |→ impos. impos.

Table 4.5 � Véri�cation des relations avec dépendance initiale

r1.b ‖ r2.b, r1.b ≺ r2.e, r2.b R1 r1.e, r1.e R2 r2.ePPPPPPPPR1

R2 ≺ ‖ �

≺ |⇁ ⇁| |⇁−1

‖ ⇁| ⇁ impos.

� impos. impos. impos.

Table 4.6 � Véri�cation des relations sans dépendance initiale

� les six relations avec dépendance initiale contiennent toutes la précédence initiale. Les dixrelations contiennent toutes ⇁.

� L'égalité, la concurrence, et la précédence croisée ⇁| sont leur propre inverse. Les neufautres relations possèdent un inverse en inversant le rôle de r1 et r2.

Les tableaux 4.4, 4.5 et 4.6 permettent de s'assurer du caractère exhaustif de la liste derelations.

4.3.3.2 Propriétés

Le tableau 4.7 contient les compositions entre toutes les relations possibles, et la �gure 4.9représente le demi-treillis des relations de précédence.

4.3.3.3 Ordres et pré-ordres

Les relations suivantes sont :

� des ordres (ré�exive, transitive, antisymétrique) : précédence inclusive →| , forte |→, faible→, couvrante →| ;

� des pré-ordres (ré�exive, transitive) : précédence initiale ⇀, �nale ⇁| ;� non transitives : couvrante initiale ⇀|, élémentaire ⇁, croisée ⇁| , couvrante �nale |⇁.

47


r1\r2 ⇀ ⇀| →| → |→ →| ⇁ ⇁| ⇁| |⇁

⇀ ⇀ ⇀ ⇀ ⇀ ⇀ ⇀ ⇁ ⇁ ⇁ ⇁

⇀| ⇀ ⇀ ⇀ ⇀ ⇀ ⇀ ⇁ ⇁ ⇁ ⇁

→| ⇀ ⇀| →| ⇀ ⇀ ⇀| ⇁ ⇁ ⇁| ⇁|

→ ⇀ ⇀ ⇀ → |→ → ⇁ ⇁| ⇁ ⇁|

|→ |→ |→ |→ |→ |→ |→ ⇁| ⇁| ⇁| ⇁|

→| ⇀ ⇀ ⇀ → |→ → ⇁ ⇁| ⇁ ⇁|

⇁ ‖ ‖ ‖ ⇁ ⇀ ⇁ ‖ ⇁ ‖ ⇁

⇁| ‖ ‖ ‖ ⇁| |→ ⇁| ‖ ⇁| ‖ ⇁|

⇁| ‖ ‖ ‖ ⇁ ⇀ ⇁ ‖ ⇁ ‖ ⇁

|⇁ ‖ ‖ ‖ ⇁| |→ ⇁| ‖ ⇁| ‖ ⇁|

Table 4.7 � Composition des relations de précédence

�nale ⇁| croisée ⇁| initiale ⇀

couv. �nale |⇁ couv. initiale ⇀| faible

forte |→

faible →

inclusive →|couvrante →|

initiale

élémentaire ⇁

Note : il manque les inverses :� inclusive →| contient |⇁−1 (symétrique de couv. �nale), et indirectement ⇁|−1 et ⇁−1)� croisée ⇁| contient ⇁−1

� . . .

Figure 4.9 � Le demi-treillis des relations de précédence

48


4.3.3.4 Retour à l'ordre

À l'exclusion des trois relations linéaires, nos relations de précédence ne peuvent pas êtretraduites dans l'algèbre des intervalles d'Allen 1.

Par contre, il est possible de linéariser le temps, c'est-à-dire d'imposer un ordre total entreévénements. C'est ce que réalise l'ordre total dé�ni par les horloges de Lamport, compatible avecl'ordre partiel du temps causal, où les deux relations entre événements (≺, ‖) se ramènent a uneseule (<).

Dans ce cas, nous pouvons utiliser les opérateurs relationnels de l'algèbre des intervalles d'Al-len pour le temps linéaire. Pour simpli�er le tableau, et comme les événements sont atomiques,nous considérons qu'il est impossible que deux intervalles démarrent ou �nissent sur le mêmeévénement. Nous obtenons alors les correspondances suivantes :

initiale ⇀ ≡ {before, contains, overlaps}couv. initiale ⇀| ≡ {contains, overlaps}inclusive →| ≡ {contains}faible → ≡ {before, overlaps}forte |→ ≡ {before}couvrante →| ≡ {overlaps}élémentaire ⇁ ≡ {before, contains, during, overlaps, overlapped by}�nale ⇁| ≡ {before, contains, overlaps, overlapped by}croisée ⇁| ≡ {during, contains, overlaps, overlapped by}couv. �nale |⇁ ≡ {during, overlaps}concurrente ‖ ≡ no info = {before, after, contains, during, overlaps, overlapped by}

Relations strictes. Il est possible de donner une version stricte des relations de précédence,où l'absence d'information de précédence entre deux événements est remplacée par la concurrence‖. Par exemple,

r1 ⇁| ∗ r2∆= r1.b ≺ r2.e ∧ r2.b ≺ r1.e ∧ r1.b ‖ r2.b ∧ r1.e ‖ r2.e

Les relations strictes sont exclusives, et les neufs relations strictes plus leur inverse, la croisée,l'égalité et la concurrence stricte forment l'ensemble des vingt-une relations possibles entre deuxdé�lements.

4.3.4 Ensemble de dé�lements

Soit E l'ensemble des événements.On dé�nit la causalité entre deux ensembles d'événements par (tout élément de G1 précède

ou est concurrent avec tout élément de G2 et il existe un élément strictement précédent) :

∀G1,G2 ∈ P(E) :: G1 ≺ G2∆= ∀e1 ∈ G1, e2 ∈ G2 :: ¬(e2 ≺ e1)∧ ∃e1 ∈ G1, e2 ∈ G2 :: e1 ≺ e2

Cette relation est un ordre partiel qui se ramène à la causalité classique des événements si onconsidère les singletons.

Soient R1 et R2 deux ensembles de dé�lements (un ensemble de dé�lements peut être vucomme une exécution d'une application multi-�ux). Soit Bi (resp. Ei) l'ensemble des événementsde début (resp. �n) des dé�lements de Ri . En considérant les relations causales entre B1, B2, E1

et E2, on dé�nit les relations entre R1 et R2.

1. Les intervalles en temps dit non linéaire sont une entité di�érente de nos intervalles : il n'est pas possible,par exemple, de décrire la précédence initiale ⇀.

49


I2

I2a I2b

I1

Récepteur 2

Récepteur 1

Émetteur

Figure 4.10 � Arrivée tardive d'un récepteur

On obtient alors les mêmes combinaisons que pour les événements de début/�n de deuxdé�lements, et donc exactement les mêmes onze relations, qui portent maintenant sur deuxensembles de dé�lements et non plus sur deux dé�lements.

4.3.5 Limitations

4.3.5.1 Dynamicité des intervalles

La représentation d'un �ux par des intervalles associés à des dé�lements permet de décrireet de raisonner sur les relations causales entre les �ux. Pour autant, ce modèle peut être tropgrossier pour certaines applications multimédias. Par exemple, si l'on considère un �ux de longuedurée, comme un �lm, et que l'on utilise un unique intervalle pour décrire sa présentation, lesrelations de précédence causale deviennent trop éloignées de la réalité temporelle. Par exemple, lefait que le début d'un �lm recouvre partiellement la �n d'un autre est imparfait. Se recouvrent-ilsd'une minute ou d'une heure ?

Par ailleurs, la représentation d'un �ux par un unique intervalle ne permet pas de prendreen compte des aspects dynamiques, comme des participants qui arriveraient ou partiraient encours de di�usion d'un �lm. Considérons l'exemple de la �gure 4.10. Un récepteur en retardse joint à une di�usion d'un �ux. Comme il est di�cile d'énoncer précisément la relation entreI 1 et I 2 (I 1 correspond à un su�xe de l'intervalle auquel correspond I 2), il peut être utile dedécouper l'intervalle I 2 en deux, de manière à ce que I 1 et I 2b correspondent exactement aumême intervalle chez l'émetteur.

4.3.5.2 Événement d'annulation

L'événement d'annulation est un événement important dans les systèmes coopératifs. Consi-dérons une session de travail coopératif à trois participants (�gure 4.11). Le participant P1 émetun �ux (dé�lement d'émission r1) qui peut être interrompu à tout moment par n'importe quelparticipant. Cette interruption (événement d'annulation c) doit être prise en compte par chaquesite car il se traduit par la terminaison d'un dé�lement (ici, les dé�lements de réception r2 et r3).

Vis-à-vis de la causalité, l'événement c est causalement dépendant du début du dé�lementd'émission : r1.b ≺ c. Si l'annulation survient sur le site d'émission P1, l'événement d'annulationdevient l'événement de �n du dé�lement et est traité ainsi. Par contre, si l'annulation a lieu surun site récepteur comme présenté sur la �gure 4.11, il n'y a pas, a priori, de relation causaleentre l'événement d'annulation et l'événement de �n du dé�lement d'émission. En fait, nousavons r2.b ≺ c et donc r1.b ≺ c et c ≺ r2.e mais il n'y a pas de lien causal entre c et r1.e.

50


r1.b r1.e c1

r2.b r2.e

CANCEL

P1

r3.b r3.e

P2

P3

c2

c3?

Figure 4.11 � Flux et annulation

Il est donc impossible d'imposer une relation entre c3, événement de réception correspondant àl'émission de l'annulation c, et r3.e, événement de réception correspondant à la �n de l'émissiondu dé�lement r1.

Pour ce type d'événement d'annulation, il est nécessaire de dé�nir un nouveau type de re-lation. Par exemple ici, on note que c a lieu pendant r2 (soit c ∈ r2) et le fait que c soit uneannulation impose que l'on obtienne c1 ∈ r1 et c3 ∈ r3. Une di�usion cohérente est nécessairepour assurer que cette propriété soit véri�ée sur tous les dé�lements, qu'ils soient en émissionou réception, mais une di�usion simplement causale est insu�sante comme montré dans le pa-ragraphe précédent : une di�usion d'ordre total est nécessaire. Un tel protocole est coûteux etinduit en général une latence considérable, y compris sur le site à l'origine de la di�usion, ce quile rend inadapté aux applications interactives. Les solutions possibles sont :

� Quand un site génère un événement d'annulation, celui-ci est transmis au site émetteurdu dé�lement annulé. C'est ce site qui suspend la di�usion du dé�lement. Tous les sitesvoient donc la même �n du dé�lement, mais la prise en compte de l'annulation n'est pasinstantanée.

� Retarder � légèrement � la délivrance locale du dé�lement, avec un retard su�sammentpetit pour ne pas gêner l'interactivité, mais su�samment grand pour que le message d'an-nulation ait le temps de parvenir à tous les sites [Mau00, MVHE04].

� Synchroniser l'avancement des sites : les sites disposent d'une horloge synchronisée et unmessage est estampillé avec cette horloge. Un message est délivré localement uniquementsi son estampille est égale à l'horloge de réception de tous les autres sites. Quand tous lessites ont délivré tous les messages d'une date donnée, leurs horloges avancent à la datesuivante. En prenant ∆ comme incrément des horloges, l'ordre entre deux événements estindé�ni s'ils sont produits dans un intervalle plus petit que ∆. Il s'agit donc d'un ordremoins fort que l'ordre total. Par contre, cette solution nécessite une synchronisation deshorloges et impose un avancement synchronisé des sites. Cette solution est souvent utiliséedans les systèmes de simulation distribués (par exemple dans DIS - Distributed InteractiveSimulation).

51

4.4 - Travaux similaires

4.4 Travaux similaires

4.4.1 Lamport

Dans [Lam86a, Lam86b], Lamport s'intéresse à donner un formalisme pour décrire des exé-cutions réparties. Pour cela, il introduit deux relations de précédence −−−→ et −−→ qui portentsur un ensemble d'événements. Intuitivement A−−−→B est une précédence forte qui dit que tousles événements de A précèdent tous les événements de B , et A−−→B est une précédence faiblequi dit qu'au moins un élément de A précède au moins un élément de B . Les deux relations −−−→et −−→ sont dé�nies dans un cadre formel général et doivent véri�er les cinq axiomes suivants :

A1. La relation −−−→ est un ordre partiel non ré�exif ;A2. si A−−−→B alors A−−→B et B−6−→ A ;A3. si A−−−→B −−→C ou A−−→B −−−→C alors A−−→C ;A4. si A−−−→B −−→C −−−→D alors A−−−→D ;A5. pour tout A, l'ensemble des B tels que A 6−−−→B est �ni.

L'axiome A5 est là pour garantir qu'une exécution débute en un point, et ne s'étend pas à l'in�nidans le passé. Les autres axiomes traduisent l'intuition des précédences faible et forte.

Le modèle classique d'un tel système est un modèle événementiel où une exécution est unensemble d'événements muni d'une relation d'ordre partiel ≺, et où les relations −−−→ et −−→qui portent sur un ensemble d'événements sont dé�nies par :

A−−−→B∆= ∀a ∈ A : ∀b ∈ B : a ≺ b

A−−→B∆= ∃a ∈ A : ∃b ∈ B : a ≺ b ∨ a = b

Les ensembles � intéressants � d'événements que l'on peut considérer sont :� Les ensembles correspondant à des coupures, constitués par N événements pris sur chacundes N processus ;

� Les ensembles correspondant à des intervalles linéaires, c'est-à-dire un ensemble S d'événe-ments tous pris sur le même processus, donc totalement ordonnés, et tels que ∀e : min(S ) ≺e ≺ max(S )⇒ e ∈ S .

L'objectif de Lamport n'est pas de classi�er toutes les formes possibles de précédence, maissimplement les deux qui lui sont nécessaires ensuite pour raisonner sur des algorithmes concur-rents à base d'opérations non atomiques de lecture ou d'écriture. Il lui su�t donc de savoir siune opération a nécessairement in�uencé une autre opération (−−−→), ou si une opération peutavoir in�uencé une autre opération (−−→).

Dans une vision similaire à ce que nous avons présenté, où nous nous intéressons aux rela-tions entre intervalles linéaires de deux sites (éventuellement) distincts, la relation de précédence−−−→ de Lamport correspond à notre précédence forte |→, et la relation de précédence −−→ yrajoute les neufs autres (plus leurs inverses), c'est-à-dire à toutes les précédences possibles saufla concurrence ‖.

4.4.2 Kshemkalyani

S'appuyant sur les travaux de Lamport, Kshemkalyani [Ksh96] montre que les deux relations−−−→ et −−→ sont su�santes pour décrire les interactions possibles entre un intervalle linéaireet un point, mais sont insu�santes pour décrire les interactions entre deux intervalles linéaires.Il s'intéresse en outre aussi bien aux intervalles denses (i.e. tel que ∀x , y ∈ I : x < y ⇒ ∃z ∈ I :x < z < y) que non denses.

Repartant du cadre formel général, Kshemkalyani dé�nit quatre relations de causalité entre

52


R2 R3

R1

R4

Figure 4.12 � Hiérarchie des relations R1, R2, R3, R4

ensemble d'événements :

R1 R1(A,B)∆= ∀a ∈ A : ∀b ∈ B : a ≺ b

R2 R2(A,B)∆= ∀a ∈ A : ∃b ∈ B : a ≺ b

R3 R3(A,B)∆= ∃a ∈ A : ∀b ∈ B : a ≺ b

R4 R4(A,B)∆= ∃a ∈ A : ∃b ∈ B : a ≺ b

� La relation R1 correspond à la relation −−−→ de Lamport : tous les éléments de A précèdenttous les éléments de B . L'ensemble B commence après l'ensemble A.

� La relation R2 dit que tout élément de A précède au moins un élément de B . L'interpré-tation est que l'ensemble B �nit après avoir eu connaissance de l'intégralité de A. Noterque dans le cas où A est totalement ordonné, cela signi�e aussi qu'il existe un élément deB que tous les éléments de A précédent.

� La relation R3 dit qu'au moins un élément de A précède tous les éléments de B . L'inter-prétation est qu'un événement de A contrôle intégralement l'ensemble B.

� En�n la relation R4 est la relation −−→ de Lamport, indiquant simplement l'existence dedeux événements causalement liés.

Ces quatre relations forment une hiérarchie, cf �gure 4.12.À ces quatre relations de causalité, Kshemkalyani ajoute deux relations de couplage :

S1 S1(A,B)∆= ∃a ∈ A : ∀b ∈ B : a 6= b ∧ a 6≺ b ∧ b 6≺ a

S2 S2(A,B)∆= ∃a1, a2 ∈ A : ∃b ∈ B : a1 ≺ b ≺ a2

� La relation S1 est une relation d'indépendance qui indique l'existence d'un élément de Aqui n'a in�uencé aucun élément de B et qui n'a été in�uencé par aucun événement de B .Un exemple d'utilisation de S1 est la description d'une communication asynchrone, où Ae�ectue une communication non bloquante vers B puis e�ectue un calcul et se termineavant un retour de B .

� La relation S2 est le complément, traduisant l'existence d'un aller-retour entre A et B etpermet de modéliser l'équivalent d'un appel procédural de A vers B .

À partir de ces six relations de précédence, Kshemkalyani construit 29 interactions possiblesentre deux intervalles linéaires denses, à savoir 13 relations plus leurs inverses, et 3 relationsinverses d'elles-mêmes. Ce résultat est à comparer avec nos 21 relations (9 relations plus leurssymétriques et trois relations inverses d'elles-mêmes). La di�érence provient de ce que nous avonsdé�ni les relations uniquement à partir des bornes des intervalles alors que Kshemkalyani consi-dère l'ensemble des événements de l'intervalle. Par exemple, dans les deux premières exécutions

53

4.5 - Communications multimodales

r1.b

r2.b r2.e

r1.e r1.b

r2.b r2.e

r1.e r1.b

r2.b r2.e

r1.e

IS / couv. initiale IT / couv. initiale IU / inclusive

Figure 4.13 � Intervalles liés par ⇀| et →| , distincts pour Kshemkalyani

de la �gure 4.13, les intervalles sont chez nous reliés par la même relation de précédence cou-vrante initiale ⇀|, sans distinguer le fait que le lien entre r2.b et r1.e est directement sur cesévénements ou sur un successeur/un antécédent. Il s'agit par contre de deux interactions dis-tinctes pour Kshemkalyani (IS et IT dans sa nomenclature). Quand le lien de causalité atteintla �n de l'intervalle, nous obtenons une nouvelle relation, nommée précédence inclusive →| cheznous, IU chez Kshemkalyani.

L'intérêt des travaux de Kshemkalyani est de formuler un cadre dans lequel il énonce les re-lations possibles entre intervalle linéaire et point, entre deux intervalles linéaires denses, et entredeux intervalles linéaires non denses. Son cadre est générique et on peut imaginer l'instancieravec une autre relation de base que la causalité entre événements. Il se rapproche en ce sensdes travaux théoriques sur le temps et ses interactions [Haj96]. Ultérieurement, Kshemkalyania utilisé ses relations pour décrire et détecter des prédicats globaux de type possibly(φ) et de-�nitely(φ) [Ksh03, CK03]. Ses travaux sont plus généralistes que les nôtres, mais la complexitéaccrue des relations et de leur véri�cation nous fait juger que nos six relations avec précédenceinitiale sont adéquates pour dé�nir les relations utiles dans le cas où l'on s'intéresse à la cohérencemulti-�ux multimédias.

4.5 Communications multimodales

Cette section aborde le problème de l'implantation d'un système de di�usion de �ux respec-tant nos relations de dépendances. Comme ces relations de dépendance sont dé�nies par rapportà la causalité, une première approche pour les implanter consisterait à utiliser la di�usion cau-sale classique pour tous les messages des �ux di�usés dans la session. Une telle démarche s'avèretrop coûteuse, en particulier en termes de latence. Le retard de réception d'un message entraînele retard de délivrance de tous les messages qui lui sont causalement liés. Plusieurs approchesexistent pour contourner ce problème. Nous présentons ici une autre approche, quali�ée de mul-timodale, où la cohérence causale n'est assurée qu'entre certains points du �ux, une di�usionsimplement �fo étant utilisée pour le reste. Combinée avec une approche relaxée de la causalité,nous obtenons une di�usion ∆−multimodale qui o�re un bon compromis entre latence, gigue etcohérence.

Un point important est commun à tous les protocoles ordonnés : il est nécessaire de distinguerréception et délivrance : en e�et, si un site reçoit des messages dans le désordre (plus exactementdans un ordre non compatible avec l'ordre dé�ni pour ce protocole), le protocole doit retarderla délivrance (c'est-à-dire la mise à disposition de l'application) des messages en avance. Parexemple sur la �gure 4.14, le message m ′ di�usé par B arrive rapidement sur C mais comme ilest causalement lié au message m, il ne peut pas être délivré avant lui si le protocole respectela causalité. Ce cas de retard se présente quand l'inégalité triangulaire est violée : le temps detransmission A→ B + B → C est plus petit que celui A→ C .

54


A

B

C

m m'

Figure 4.14 � Retard de délivrance

KO OK

m1 m2 m1 m2

P2

P1

Figure 4.15 � Délivrance �fo

4.5.1 Approches existantes

4.5.1.1 Protocoles ordonnés

Dans les systèmes distribués, les principaux protocoles ordonnés utilisés sont ceux qui res-pectent l'ordre �fo, causal ou total.

Ordre �fo. La délivrance est �fo si les messages d'un émetteur donné sont délivrés en respec-tant l'ordre d'émission (�gure 4.15) :

∀p, q : ∀m,m ′ : send(p,m) ≺ send(p,m ′) ∧ e3 = deliver(q ,m) ∧ e4 = deliver(q ,m ′)⇒ e3 ≺ e4

où e3 et e4 sont les événements de délivrance des messages m et m ′ sur le site q . Comme lesémissions ont lieu sur le même site, l'ordre considéré est en fait le temps absolu de ce site (etsimilairement pour e3/e4)

Le protocole est quali�é de �fo �able si tout message émis est délivré, en respectant l'ordre�fo d'émission :

∀p, q : ∀m,m ′ : send(p,m) ≺ send(p,m ′)⇒ deliver(q ,m) ≺ deliver(q ,m ′)

KO OK

mc1

c2c2

mc1

P2

G1

G2

P1

Figure 4.16 � Délivrance causalement ordonnée

55


KO OK

P1

P2

G1

G2

a1

a2

a1

a2

Figure 4.17 � Délivrance totalement ordonnée

Ordre causal. La délivrance est causale si deux messages causalement liés sont délivrés enrespectant l'ordre de causalité (�gure 4.16) :

∀p, p′, q : ∀m,m ′ : send(p,m) ≺ send(p′,m ′)∧e3 = deliver(q ,m)∧e4 = deliver(q ,m ′)⇒ e3 ≺ e4

La di�érence avec le �fo est qu'ici, les événements d'émission n'ont pas nécessairement lieu surle même site.

Le protocole est causal �able si tout message émis est délivré, en respectant l'ordre causald'émission :

∀p, p′, q : ∀m,m ′ : send(p,m) ≺ send(p′,m ′)⇒ deliver(q ,m) ≺ deliver(q ,m ′)

La primitive CBCAST (Causal Broadcast) d'Isis [MCWB91, Bir93] a probablement été lapremière implantation d'un service �able d'ordre causal. Il existe d'autres systèmes de coordina-tion fournissant ce service, comme Transis [ADKM92], Horus [RBM96], Totem [MMSA+96]. . .

Ordre total. La délivrance est totale si deux messages donnés sont délivrés dans le mêmeordre sur tous les sites destinataires (�gure 4.17). On suppose donc l'existence d'une fonction odé�nissant un ordre total sur les messages et la délivrance �able doit alors véri�er :

∀p, p′, q : ∀m,m ′ : send(p,m) ∧ send(p′,m ′) ∧ o(m) < o(m ′)⇒ deliver(q ,m) ≺ deliver(q ,m ′)

Cet ordre total peut être compatible avec la causalité (i.e. tel que send(p,m) ≺ send(p′,m ′)⇒o(m) < o(m ′)), mais pas nécessairement. Par exemple quand l'ordre total est obtenu par un siteséquenceur qui estampille les messages selon leur ordre d'arrivée chez lui, sans prendre en comptela causalité, l'ordre total ainsi implanté ne respecte a priori pas la causalité. Sur la �gure 4.18, lesite A demande au site central de di�user un message totalement ordonné (message de requêtem avec la liste des destinataires et le contenu applicatif), puis envoie un message m ′ à B . Lesite B demande à son tour la di�usion d'un message totalement ordonné (requête dans m ′′). Il setrouve que ce message m ′′ arrive avant m sur le site central, et que celui-ci attribue à la réceptionun numéro �xant l'ordre total. Le contenu applicatif de m ′′ est envoyé aux destinataires avec lenuméro n, et le contenu de m, causalement précédent, avec le numéro n + 1.

Implantation Nous donnons ci-dessous les grandes lignes des algorithmes capturant et resti-tuant les dépendances causales.

� par surcharge (piggybacking) : chaque message applicatif est surchargé avec les messagesqui le précèdent causalement [SM94]. À la réception d'un message, le protocole e�ectuel'ordonnancement de tous les messages applicatifs reçus et délivre les messages en retarden fonction de l'ordre causal, avant de délivrer le message courant. De plus, le protocole

56


A

B

séquenceur

m m'

m"

n n+1

Figure 4.18 � Ordre total non causal

est amené à rejeter des messages arrivés en retard (dupliqués) et à supprimer des messagescontenus dans les messages surchargés lorsque ces derniers deviennent inutiles. Le principalinconvénient de cette approche est l'accroissement de la taille des messages.

� à l'aide de vecteurs [Mat89, BSS91] ou matrices [RST91] d'horloges : ces mécanismes four-nissent des systèmes de datation qui capturent la causalité. La relation causale peut êtrecapturée avec précision par les horloges vectorielles. Des protocoles de di�usion causale surdes groupes fermés peuvent être implantés à l'aide de vecteurs d'horloges. Néanmoins, l'im-plantation de protocoles causaux point à point ou sur des groupes ouverts nécessitent l'uti-lisation de matrices d'horloges. Plusieurs techniques ont été proposées pour borner la taillede l'information à conserver dans les vecteurs : messages d'acquittement [Bal98], conserva-tion uniquement des prédécesseurs immédiats, ce qui revient à construire le diagramme deHasse équivalent à la causalité [EHR02], réduction des événements signi�catifs [HRMB03],décomposition en phases [MT98], réduction de la précision de la causalité par horlogesplausibles [TRA99]. . .

L'ordre total n'a pas été utilisé dans nos travaux, et nous ne présentons ici que quelques pistessur son implantation. On trouvera plus d'informations dans les synthèses [WS95, DSU04]. Lesprotocoles à ordre total sont souvent basés sur un séquenceur qui sert à déterminer l'ordre total(obtention d'un numéro unique). Ce séquenceur peut soit uniquement servir à déterminer l'ordre,chaque site émetteur assurant ensuite lui-même la di�usion des messages, soit directement assurercet envoi. Le séquenceur peut être un site �xe [CM84], connu de tous, ou implicitement dé�ni parexemple au moyen d'un jeton circulant [RM89, BSS91, AMMS+95], ce qui permet une meilleurerégulation de la charge. Dans les deux cas, le point unique (site ou jeton) nécessite des mécanismesde tolérance aux fautes (réplication du séquenceur avec protocole de coordination [KTFB89],ou élection d'un nouveau séquenceur en cas d'arrêt [CDK01, p. 431�436], ou recréation d'unjeton [RM89]). Il existe cependant aussi des versions où l'ensemble des destinataires s'accordentcollectivement sur l'ordre de délivrance (par exemple [BJ87] ou [GS97]).

4.5.1.2 Adaptations des protocoles causaux

Du fait du réordonnancement des messages, les protocoles causaux engendrent des latencesvariables et surtout non bornées (message perdu par exemple). La variabilité des latences (lagigue) est un aspect sensible dans les applications multimédias et doit être prise en comptedans une délivrance causale adaptée. Le deuxième point faible est lié à la surcharge de la bandepassante due à la taille de l'information de contrôle causale (par exemple horloges vectorielles oumatricielles) [BSS91]. Plusieurs directions ont été suivies pour réduire les coûts des protocolescausaux.

57


Réduction des délais. Pour réduire les délais, [RS97] introduit le concept de causalité suf-�sante/partielle (su�cient causal ordering/partial causal ordering) en divisant les événementsen deux classes : causally supportive (pouvant induire la causalité) et non causally supportive(n'entraînant pas la causalité). L'idée consiste à imposer la causalité juste parmi certains événe-ments, spéci�és par le niveau applicatif. La possibilité de rompre les dépendances causales entrecertains �ux d'événements non corrélés o�re une meilleure solution en termes de délais réseauainsi que de changement d'échelle. Une approche originale, nommée adaptive message schedulingest décrite dans [HYC04]. Elle consiste à plani�er les latences chez l'émetteur a�n d'alléger ledésordre possible (et donc, la tâche et le délai d'ordonnancement) chez les récepteurs.

Réduction de la bande passante. Pour réduire les besoins en bande passante, [PBS89]utilise un graphe de contexte (context graph), graphe acyclique représentant la causalité entremessages : les n÷uds sont les messages et les arcs les dépendances causales. En utilisant latransitivité de la relation de précédence causale, le but est de trouver le graphe réduit pouvantreprésenter la causalité uniquement via les dépendances immédiates entre deux n÷uds successifs,c'est-à-dire le diagramme de Hasse de l'ordre partiel issu de la causalité. De même, [PRS97]utilise la � relation de dépendance immédiate � (immediate dependency relation) pour réduirel'information de contrôle : un message transporte seulement les dépendances causales vis-à-vis des messages dont il dépend directement. Toujours dans le but de réduire les informationstransportées, [KS98] présente un protocole qui n'attache à chaque message que l'information decontrôle concernant les messages pas encore délivrés ou pour lesquels il n'existe pas encore lagarantie d'être délivrés de manière causale. En s'appuyant sur les horloges vectorielles, [BSS91]propose une compression des vecteurs de causalité en envoyant seulement les positions dont lesvaleurs ont changé depuis la dernière di�usion de l'émetteur.

Con�nement des dépendances. En�n, d'autres travaux utilisent des informations complé-mentaires, comme la topologie du réseau pour dé�nir des régions causales qui con�nent les dépen-dances causales [RV95], la connaissance d'une structure hiérarchique des groupes [BBFR99]. . .

Applications multimédias. Plus spéci�quement vis-à-vis des applications multimédias, la∆-causalité a été imaginée pour garantir une latence maximale introduite par le retard de déli-vrance. Ceci est particulièrement intéressant pour les applications multimédias coopératives oùun message peut cesser d'être signi�catif après un trop long délai (durée de vie limitée). La∆-causalité [Yav92, BMR96] est une restriction du principe de causalité, dans laquelle on consi-dère qu'un message devient inutile s'il arrive à destination après un délai d'expiration ∆. Plusprécisément :

� un message émis à t est délivré avant t + ∆ ou rejeté (arrivé trop tard) ou perdu ;� la délivrance respecte l'ordre causal : pour tous messages m et m ′ reçus sur un site s avantleur date d'expiration et tels que leurs événements d'émission sont causalement liés, le sites doit délivrer m et m ′ dans le bon ordre.

On peut noter que la ∆-causalité se réduit à la dé�nition classique de la causalité si les com-munications sont �ables et ∆ est supérieur au délai de transmission de n'importe quel message.

La mise en ÷uvre de la ∆-causalité nécessite l'utilisation d'un mécanisme de synchronisationd'horloges, pour lequel il existe de nombreux protocoles peu coûteux. La dérive qu'il est possibled'obtenir est petite (de l'ordre de quelques millisecondes) par rapport à la valeur de ∆, qui estde l'ordre, pour des applications multimédias, de quelques centaines de millisecondes.

Par ailleurs, ∆ peut être vu comme un paramètre d'adaptation, que l'on ajuste en fonction dunombre de messages rejetés et de l'interactivité souhaitée [IT03] : ∆ est graduellement augmenté

58


m m"

m' m"

m' m"

m

m'

m"

Figure 4.19 � Communication multimodale

si les conditions réseau se dégradent pour réduire le nombre de messages rejetés (car arrivés troptard). Au contraire, en cas d'amélioration, ∆ est baissé permettant ainsi une meilleure réactivité.

4.5.2 Délivrance multimodale

Fanchon et al. dé�nissent dans [FDP04] un calcul avec communication multi-canaux sup-portant plusieurs ordres de délivrance. Les auteurs considèrent un ensemble de participants quiéchangent des messages à travers un canal de communication abstrait, composé de plusieurs ca-naux élémentaires. Un canal élémentaire est une abstraction correspondant à un sous-ensemblede messages échangés par un sous-ensemble de participants connectés à ce canal (les membres).Les messages échangés sur un canal élémentaire sont délivrés chez tous les membres en respectantun ordre de délivrance spéci�que (par exemple �fo, causal ou total) au canal.

Sur la �gure 4.19, nous avons deux émetteurs P1 et P2 qui émettent via trois canaux élémen-taires à deux destinataires. Via le canal C1 le message m est lié �fo à m ′′, tandis que m ′ est lié àm ′′ causalement via C2 et totalement via C3. Par contre m et m ′ qui ont même émetteur P1 etdestinataire P3 ne sont pas liés. Notons que vu que P4 reçoit les mêmes messages via C2 causalet C3 total, il est nécessaire que l'ordre total soit compatible avec la causalité. Bien évidemment,une implantation � réussie � de la communication multimodale ne transmettra physiquementchaque message qu'une seule fois, indépendamment du nombre de canaux élémentaires sur lequelil est émis.

Dans le cadre des applications multimédias coopératives, nous avons vu le besoin de trans-mettre causalement les messages pour assurer les relations de dépendance, mais nous souhaitonséviter le coût d'une communication intégralement causale. Comme nos relations de dépendancesont dé�nies par rapport au début et �n de dé�lement, on peut envisager d'envoyer l'intégralitédes messages sur un canal �fo, et un sous-ensemble de ces messages (correspondant au début et�n du dé�lement) sur un canal causal.

Plus généralement, nous pouvons relâcher la causalité entre les �ux, en n'assurant la cohérencequ'en certains points des �ux (points causaux). Tous les messages sont émis en �fo et certainsen causal. Dans une application coopérative, on peut aussi avoir besoin de di�érentes qualitésde services, selon la nature des �ux et des interactions. Ainsi un �ux de type textuel (chat)nécessite d'être �able et peut exiger un ordre de délivrance total (ou au minimum causal). À

59


A

B

C fifo causal

Canal multimodalsur C

tête

Figure 4.20 � Interblocage par l'approche �les d'attente

l'opposé un �ux vidéo peut être délivré de manière plus �exible et supporte même des pertes :par exemple, pour un �ux MPEG, on peut imposer que les images I soient délivrées de manière�able et �fo, tandis que, au sein d'un GOP (Group of Pictures), les images P et B pourraientêtre délivrées dans un ordre partiel, sans contraintes strictes de �abilité (par exemple un tauxde perte contrôlé).

4.5.3 Mise en ÷uvre

Dans sa thèse, Cezar Ple³ca a étudié la di�culté d'une implantation performante mixantcanaux causaux et �fo. Ainsi, alors même que l'ordre causal est une extension de l'ordre �fo, uneapproche intuitive basée sur des �les d'attente propres à chaque canal élémentaire ne fonctionnepas.

Considérons, par exemple, deux messages m1 et m2 envoyés chacun sur deux canaux, �fo etcausal, comme illustré sur la �gure 4.20. Sur le site C , le protocole �fo range les messages m2

et m1 dans leur ordre d'arrivée, vu qu'ils sont indépendants. Au contraire, le protocole causalattend l'arrivée de m1 pour pouvoir délivrer m2. Nous nous retrouvons alors avec la compositiondes �les d'attente présentée dans la �gure, où m1 est en tête de la �le causale mais n'est pas entête de la �le �fo, et inversement pour m2. Ceci est une situation classique d'interblocage. Ceciprovient du fait que chaque canal élémentaire crée, par l'intermédiaire de sa �le, un ordre totalqui est une extension de l'ordre qu'il garantit. Dans l'exécution présente, l'extension du canal�fo est un ordre incompatible avec la causalité.

La solution retenue consiste, pour chacun des canaux élémentaires, à conserver uniquementl'ordre qu'il doit respecter, sans y rajouter de contraintes supplémentaires. Les messages sontconservés par le canal selon un graphe qui traduit exactement l'ordre correspondant. Ainsi, uncanal �fo aura autant de branches indépendantes que de sites ; un canal causal aura un graphecorrespondant à l'ordre partiel de la causalité ; un canal total aura une unique branche linéaire.Il s'agit ensuite de faire un tri topologique du graphe fusionné, c'est-à-dire de construire unordre total des n÷uds qui soit compatible avec tous les graphes, ou autrement dit une extensionlinéaire de l'ordre partiel correspondant à l'union des ordres partiels des graphes. Si une telleextension n'existe pas, cela signi�e que les contraintes d'ordre sur les canaux sont incompatiblesentre elles (par exemple un ordre causal + un ordre total non compatible, ou deux ordres totauxincompatibles).

60


Figure 4.21 � Architecture d'une pile JGroups

Cezar Ple³ca a implanté cet algorithme en s'appuyant sur la bibliothèque JGroups [JGr10], quio�re la possibilité de construire facilement des protocoles de di�usion ayant des caractéristiquesdi�érentes en combinant des µprotocoles (�gure 4.21). Ceci a permis d'observer qu'une commu-nication multimodale combinant �fo + causalité permet e�ectivement d'obtenir une cohérencecausale satisfaisante avec des performances pas trop dégradées par rapport à de l'ordonnance-ment �fo pur. En�n, une étude de la communication multimodale combinant �fo + ∆-causalitéa montré qu'elle o�re un bon compromis cohérence/gigue.

Ainsi, on considère une application constituée d'un �ux vidéo, issu d'un premier site, etd'un �ux audio commentant ce �ux vidéo et issu d'un deuxième site. Ces �ux sont di�usésdepuis chacun de leur site d'origine vers un ensemble de spectateurs. Il est important que le �uxaudio soit (relativement) causal avec le �ux vidéo, c'est-à-dire que le commentaire audio suiveles images qu'il décrit. En particulier, pour une perception agréable des spectateurs, il ne doitjamais précéder ces images (inversion de causalité). Par ailleurs, on sait que les �ux audio etvidéo ont des caractéristiques de perception bien di�érentes : l'oreille humaine est très sensibleà la gigue, l'÷il beaucoup moins.

Étudions les di�érentes possibilités de di�usion (�gure 4.22). Fifo est un protocole point-à-point qui ne gère pas la cohérence causale entre �ux provenant de sources di�érentes ; parconséquent, les �uctuations du réseau sur le chemin du �ux vidéo n'a�ectent nullement la déli-vrance du �ux audio. Le protocole causal assure une cohérence étroite entre les deux �ux ; parconséquent, chaque changement intervenu dans la délivrance d'un �ux a�ectera la délivrance del'autre, et les variations de latence du �ux vidéo vont aussi perturber la présentation du �ux au-dio. Le protocole ∆-causal o�re la cohérence causale pour tous les messages arrivés au plus tard∆ après leur envoi ; néanmoins, tout comme pour le protocole causal, les variations de latencepour les paquets vidéo arrivés avant leur échéance causale vont induire également une augmen-

61

4.6 - Conclusion

incohérence

Giguecausal

�-causal multimodal

fifo

-multimodal�

Figure 4.22 � Gigue vs cohérence

tation de la gigue dans le �ux audio. Multimodal (�fo+causal) fournit une cohérence plus soupleen essayant de maintenir une gigue faible dans le �ux audio ; il accomplit ce compromis car ilne réagit pas immédiatement aux paquets vidéo tardifs, tolérant ainsi quelques incohérences. ∆-Multimodal (�fo+∆-causal) fonctionne d'une manière similaire à Multimodal pour les messagesarrivant avant leur échéance ∆ mais ne subit pas la latence induite par les gros retards.

4.6 Conclusion

Nous avons présenté dans ce chapitre les études menées autour de la cohérence mutuelle deplusieurs �ux multimédias, et en particulier nous avons développé la cohérence causale quand un�ux est considéré comme la cause d'un autre �ux. Cette étude s'inspire des classiques travauxconduits dans les systèmes répartis autour de la causalité et de la di�usion causale de messages,avec pour objectif de prendre en compte l'aspect non ponctuel d'un �ux. Outre l'étude de lacausalité dans ce cadre non ponctuel, nous avons présenté les travaux menés sur la délivrancemultimodale, bien adaptée à la di�usion de �ux. Les limites aux résultats obtenus découlentdirectement du choix de ne pas se spécialiser dans des techniques propres au multimédia, maisd'utiliser les principes généraux de l'algorithmique répartie, ce qui a permis de réutiliser aisémentrésultats connus et implantations.

62

Chapitre 5

Association cohérente de données

5.1 Introduction

Les travaux présentés dans ce chapitre découlent de la thèse de Nadège Pontisso [Pon09]que j'ai encadrée sous la direction de Gérard Padiou. Cette thèse a été e�ectuée grâce à un co-�nancement de Thales Aliena Space et du Centre National d'Études Spatiales. Ces travaux ontdonné lieu aux publications suivantes : [PPQ08a, PPQ08b, PQPV09, PQP09, PQP10, PQP11].

Nous considérons un cadre général de systèmes distribués (ou tout au moins parallèles), et,pour la mise en ÷uvre, nous étudierons spéci�quement des systèmes embarqués temps réel. Dansce cadre général, nous considérons que le système est constitué de composants relativementindépendants. Un composant utilise des données en entrée pour e�ectuer un calcul ou une actionet produire des sorties. La circulation de l'information forme des liens entre ces composants. Lecontrôle de l'exécution des composants est hors de portée du cadre d'étude, ce qui signi�e qu'uncomposant est activé indépendamment de notre contrôle : ce peut être aussi bien une activationpériodique (directement guidée par le temps) ou événementielle (guidée par des événementsexternes ou internes). Notre interrogation porte sur la cohérence des entrées d'un composant.

Dans un tel système constitué de composants, un composant produit des données vers plu-sieurs destinataires. Ces données sont à leur tour traitées, transformées et transmises vers d'autrescomposants. Ces communications forment un graphe dont les n÷uds sont les composants, et lesarcs sont les liens de communication. Il peut alors se produire que partant d'un n÷ud, nommé lasource, il existe plusieurs chemins indépendants qui conduisent à un même composant, nomméle puits. Ainsi, le puits utilise des données d'entrée qui dépendent directement ou indirectementdu même composant source.

Le problème étudié est de savoir si, lors d'une activation du composant puits, les donnéesqu'il utilise dépendent toutes de la même activation du composant source, ou si, au contraire,les données utilisées proviennent de di�érentes activations de la source. Dans le premier cas,nous disons que le puits réalise une association cohérente de données, ou encore qu'il a uncomportement cohérent.

Par la suite, nous donnerons d'abord une dé�nition informelle de la cohérence s'appuyant surla structure de graphe formée par les composants et leurs communications. Nous présenterons en-suite quelques problèmes similaires et leurs solutions connues. Après une rapide étude des graphesqui nous intéressent, nous formaliserons la cohérence recherchée et nous montrerons comment lacoder. En�n, nous étudierons la mise en ÷uvre dans un contexte temps réel multipériodique.

63

5.2 - Dé�nition informelle de la cohérence

Figure 5.1 � Type de con�guration étudiée

5.2 Dé�nition informelle de la cohérence

Le système est constitué d'un ensemble de composants. Chaque composant exécute ses pasd'exécutions indépendamment des autres. À chaque pas d'exécution d'un composant C , ce com-posant lit ses ports d'entrée, e�ectue un pas d'exécution (une action) et produit des sorties.Un composant dégénéré peut n'avoir pas d'entrées et/ou pas de sorties. Un pas d'exécution estdonc un élément atomique vis-à-vis des entrées/sorties. Les sorties sont transmises à d'autrescomposants, qui pourront les utiliser (ou pas) pour à leur tour produire des données, qui serontpropagées aux suivants. Ainsi les données produites par C parcourent indirectement des cheminsvers d'autres composants. Noter que ce ne sont pas les données elles-mêmes qui sont transmisesinchangées mais des données transformées par chaque composant de la chaîne.

Supposons que ces di�érents chemins se rejoignent sur un même composant C ′. Ce composantutilise des données qui proviennent indirectement du même composant C , et donc qui dépendentdes pas d'exécutions de C . Nous considérons que les données d'entrée de C ′ sont cohérenteslorsqu'elles dépendent de données produites lors du même pas d'exécution de C .

La �gure 5.1 illustre le type de con�guration étudiée :� les chemins reliant C et C ′ sont au minimum au nombre de deux mais il n'existe pas demaximum ;

� les chemins n'ont pas nécessairement le même nombre de composants ;� les composants C et C ′ peuvent être reliés directement ; ainsi C ′ utilise directement desdonnées fournies par C par un ou plusieurs chemins ;

� C peut avoir une ou plusieurs sorties. Il peut donc envoyer une même donnée sur tous leschemins ou des données di�érentes.

Dé�nition 1 (Dépendance entre données) Une donnée b dépend d'une donnée a si a estutilisée par un composant pour calculer b. Cette dépendance est étendue par transitivité : c dépendde a si le calcul de c utilise une donnée b qui elle-même dépend de a.

Dé�nition 2 (Propagation d'une donnée) Une donnée d se propage d'un composant C àC ′ si C produit d et C ′ utilise une donnée dépendant de d.

5.2.1 Cohérence stricte des données

La �gure 5.2 représente un exemple simple d'application de la cohérence. Le système permetde calculer, pour tout x fourni par C1, le résultat de 2x +3(x +1). Des composants indépendants

64

Chapitre 5 - Association cohérente de données

Figure 5.2 � Calcul de 2x + 3(x + 1)

Figure 5.3 � Système présentant un problème d'association de données

se chargent de calculer 2x pour C2 et 3(x + 1) pour C3 et C4. Les résultats qu'ils produisentsont ensuite utilisés par le composant C5 qui en fait l'addition. Nous voyons que pour que lesrésultats de C5 aient un sens, C5 doit utiliser des résultats calculés par C2, C3 et C4 à partirdu même x , c'est-à-dire à partir du même pas d'exécution de C1. Bien évidemment, cet exempleest trivialement résolu dans un modèle pur data-�ow, mais rappelons que nous nous plaçonsdans un modèle libre où chaque composant peut décider, indépendamment de la disponibilitédes données, de faire un pas de calcul, en réutilisant éventuellement d'anciennes entrées si aucunenouvelle n'est disponible.

Dé�nition 3 (Données (strictement) cohérentes) Si un composant C ′ utilise plusieurs don-nées dont les valeurs dépendent de sorties d'un même composant C , alors ces données d'entréede C ′ seront considérées comme strictement cohérentes si elles dépendent de données produitespar le même pas de calcul de C .

Dé�nition 4 (Exécution cohérente, association cohérente) L'exécution d'un composantest cohérente si le composant utilise des données cohérentes pour réaliser son pas de calcul. Nousdisons également que le composant réalise une association cohérente de données. L'exécution d'unsystème est cohérente si tous les composants s'exécutent de façon cohérente.

Les chronogrammes des �gures 5.4 et 5.5 illustrent deux exécutions du système de la �gure 5.3.La première exécution est cohérente, la seconde ne l'est pas. Sur ces �gures, la queue d'une �èchereprésente le moment où une donnée est produite et sa tête représente le moment où cette donnéeest disponible en entrée d'un composant.

Lors de l'exécution illustrée par la �gure 5.4, pendant le pas d'exécution S , C3 utilise ladonnée Xb fournie par C1 et la donnée Yb fournie par C2. Ces données sont calculées en utilisantla même donnée Vb produite par C0 au pas B . Les entrées utilisées par C3 pour le pas Sproviennent du même pas d'exécution de C0. Elles sont donc cohérentes.

65

5.2 - Dé�nition informelle de la cohérence

Figure 5.4 � Exécution cohérente

Figure 5.5 � Exécution incohérente

Au contraire, lors de l'exécution illustrée par la �gure 5.5, pendant le pas d'exécution S , C3

utilise la donnée Xb fournie par C1 et la donnée Ya fournie par C2. Xb est calculée à partir de ladonnée Vb provenant du pas B alors que Ya est calculée à partir de Va provenant du pas A. Lesentrées utilisées par C3 dépendent de pas de calcul di�érents de C0. Elles sont donc considéréescomme incohérentes.

5.2.2 Cohérence relâchée des données

La dé�nition 3 de données cohérentes est relâchée en permettant que les données ne dépendentpas strictement de données produites par le même pas d'exécution de C . Un écart temporel esttolérée entre les dates de début d'exécution de C qui ont produit les données dont dépendent lesdonnées utilisées par C ′. La dé�nition 3 devient :

Dé�nition 5 (Données cohérentes avec une tolérance τ) Si un composant C ′ utilise plu-sieurs données dont les valeurs dépendent de sorties d'un même composant C , alors les donnéesd'entrée de C ′ seront considérées comme cohérentes avec une tolérance τ si l'écart de temps maxi-mal entre les pas de C dont ces données dépendent est égal au plus au temps τ . Nous employonségalement le terme de données cohérentes τ -relâchées.

Nous avons choisi de donner une dé�nition de la cohérence relâchée en termes de temps, carnotre domaine d'application est celui des applications embarquées temps réel. Nous aurions aussibien pu donner une dé�nition en termes de nombre de pas de calcul qui séparent les pas de C quiont produit les sorties dont dépendent les données en entrée de C ′. Notons que l'on compare desécarts de temps entre des pas du même composant : il s'agit donc uniquement du temps qui luiest propre, chaque composant peut disposer d'une horloge, non nécessairement synchronisée aveccelles des autres composants. En�n, la dé�nition est donnée avec une tolérance commune, mais

66


peut être généralisée trivialement à une tolérance spéci�que à chaque couple de composants : surun composant C ′, l'écart maximal entre les pas de C dont dépendent les entrées de C ′ est égalà τCC ′ .

Ce concept de cohérence relâchée peut être utilisé par exemple lorsque le concepteur préfèreque le composant C ′ utilise des données fraîches plutôt que des données strictement cohérentesmais tout en préservant un certain écart de cohérence entre ces données.

Par ailleurs, dans une gestion d'association de données strictement cohérente, il faut que C ′

reçoive sur toutes ses entrées des données dépendant du même pas de C . Si toutes les entréesne composent pas un ensemble cohérent, le composant C ′ peut, au choix du concepteur, nepas exécuter de pas de calcul, ou exécuter un pas incohérent, ou exécuter un pas en utilisant enentrée le dernier ensemble cohérent qu'il avait pu composer lors d'un précédent pas. La cohérencerelâchée apporte la possibilité d'exécuter un pas avec des données plus récentes et une incohérencemaîtrisée.

5.3 Cohérence dans les bases de données

Plus que dans l'univers des systèmes répartis, où l'intérêt s'est porté sur la cohérence d'uneentité répliquée [SS05, Ray92a] ou sur la capture d'un état cohérent d'un calcul réparti [Ray92b],c'est dans le monde des bases de données que l'on trouve des problèmes similaires au nôtre.Comme nous nous placerons ensuite dans un contexte temps réel, nous nous intéressons d'abordà l'introduction de contraintes temporelles pour dé�nir la � qualité � d'une donnée, puis nousprésentons quelques cas où la cohérence entre un ensemble de données a été étudiée.

5.3.1 Cohérence temporelle individuelle

Une base de données quali�ée de temps réel a pour objectif de contenir des informations ayantdes propriétés liées au temps, en particulier un domaine de validité dé�ni non seulement en termesde valeurs mais aussi de dates et de durées, et de réaliser des traitements eux aussi contraintspar le temps. Une telle base de données contient des objets qui sont en général des images dumonde réel, par exemple la position d'un satellite, la vitesse d'un avion, la valeur d'un capteurde mouvement. La validité des valeurs est limitée dans le temps, selon la vitesse d'évolution desobjets réels qu'elles représentent et la précision qu'on leur demande. Le système de gestion de labase de données doit s'assurer que les valeurs restent dans leurs intervalles de validité temporelle.En particulier, lors de la validation d'une transaction (commit), il faut s'assurer que les donnéesutilisées par la transaction sont e�ectivement encore valides. La principale validité rencontrée estla fraîcheur, qui signi�e qu'une donnée a été créée assez récemment et qu'elle n'est pas devenueobsolète. Les principaux travaux se sont concentrés à la fois sur ce seul type de validité temporelle,et sur un seul type de problème, l'ordonnancement d'un ensemble de transactions pour garantircette fraîcheur. Comme on considère la fraîcheur de chaque donnée indépendamment, on parlesouvent aussi de cohérence absolue des données.

Citons quelques exemples de travaux où le temps a été associé au domaine de validité desobjets de la base de données. Dans [XSS+96, XRS+02], la sémantique des variables et leurdomaine temporel de validité sont utilisés pour optimiser l'ordonnancement des transactions.Dans [AF03], des contraintes OCL (UML Object Constraint Language) sont utilisées pour dé�nirle domaine de validité des variables, et une variante de TCTL (Timed Computation Tree Logic)est utilisée pour véri�er le comportement du système et prévenir l'utilisation d'une variablehors de son domaine de validité. Dans [RSD04], les concepts de cohérence dans les bases dedonnées temps réel sont étudiés, en se concentrant spéci�quement sur la gestion de la fraîcheur.L'article présente comment le contrôle de l'ordonnancement des transactions permet de garantir

67

5.3 - Cohérence dans les bases de données

le respect des contraintes de fraîcheur et présente diverses variantes, notamment sur le strictrespect des échéances (hard versus soft). L'article fait ensuite le lien entre fraîcheur (assimilée àde la qualité des données) et qualité de service (voir aussi [KSSA02]) et développe des approchesconnexes (réseaux de capteurs, bases mobiles, services web temps réel). L'essentiel des travauxprésentés cherchent à déterminer un ordonnancement des transactions permettant de garantirune fraîcheur déterminée spéci�que à chaque donnée. L'approche retenue se base souvent sur destransactions périodiques mais quelques variations sont possibles (par exemple, [XHL05, XHLC08]se distinguent en proposant un modèle d'exécution sporadique).

5.3.2 Cohérence mutuelle

Les approches précédentes se concentrent uniquement sur le maintien de la fraîcheur de chaqueobjet pris individuellement sans prendre en compte la fraîcheur mutuelle de plusieurs données.On suppose que si deux objets sont individuellement frais, alors le couple l'est aussi. Mais enréalité cela peut alors aboutir à une vue incohérente du système, car les objets peuvent êtreliés entre eux. Lorsqu'on considère les valeurs provenant d'un ensemble de capteurs, il ne su�tpas que chaque valeur soit récente, il faut souvent aussi qu'elles aient toutes été prises au mêmeinstant, ou au moins sur un intervalle de temps relativement restreint. Il est parfois intéressant desacri�er un peu de fraîcheur pour gagner de la cohérence, par exemple quand le rythme de miseà jour des capteurs n'est pas le même. Et au-delà des capteurs, on rencontre le même problèmeavec les données dérivées de ceux-ci. Il est donc important de préserver la fraîcheur mutuelle desobjets en plus de leur fraîcheur individuelle. La prise en compte des relations entre objets aboutità une notion de cohérence mutuelle.

Dans [SL95], les auteurs étudient la performance d'algorithmes de contrôle de concurrencepour maintenir la cohérence temporelle des données en termes de fraîcheur mais également decohérence mutuelle. Chaque objet du système est daté. Plus précisément, les objets possèdent unâge qui indique depuis quand cet objet est apparu. La dispersion mesure la di�érence entre lesâges de deux objets [SL92]. Les auteurs distinguent les objets images qui sont périodiquementproduits par la sortie de capteurs, et les objets dérivés qui sont calculés à partir de valeurs d'unensemble d'objets. Les objets images sont périodiquement mis à jour à partir d'un objet réel, lapériode devant être su�samment petite par rapport à la sémantique du capteur. Un objet imagea de multiples versions d'images créées à chaque mise à jour et datées. L'âge de la version la plusrécente est toujours nulle en absence de défaillance : les auteurs supposent que les périodes demise à jour sont bien choisies et que la base contient donc toujours au moins une valeur validede chaque capteur. Un objet dérivé est calculé à partir d'un ensemble d'objets qui peuvent êtredes objets images ou des objets dérivés. Il est daté de l'âge de l'objet le plus vieux de l'ensembleutilisé pour le calculer.

Un ensemble d'objets est absolument temporellement cohérent (absolutely temporally consis-tent) si l'âge de tous les objets est inférieur à une borne �xée, dite borne absolue. L'ensemble estrelativement temporellement cohérent (relatively temporally consistent) si la dispersion de tousles couples d'objets est inférieure à une borne �xée, dite borne relative.

Les auteurs évaluent alors l'impact que peuvent avoir sur la cohérence des données di�érentscontrôles de la concurrence (pessimiste et optimiste) et di�érents algorithmes d'ordonnancementpréemptif basé sur les priorités (rate monotonic et earliest deadline �rst). Les transactions sonttoutes périodiques, distribuées uniformément sur un intervalle bornant le rapport entre pluscourte et plus longue périodes. Des simulations sont utilisées pour mesurer le pourcentage detransactions temporellement incohérentes, c'est-à-dire lisant des données absolument ou relative-ment incohérentes. Pour analyser ces résultats, d'autres mesures sont également e�ectuées telles

68


que la dispersion maximale des données, le pourcentage de transactions ratant leur échéance ouavortant, le taux de préemption. . .

L'objectif de ces travaux est donc d'étudier des algorithmes de concurrence et d'ordonnan-cement pour analyser leur impact sur la cohérence. Les auteurs ne cherchent pas à dé�nir uneméthode qui maintient la cohérence quel que soit l'ordonnancement. Le contexte base de don-nées conduit en outre à distinguer entre transactions exclusivement en lecture, exclusivementen écriture (obtention des valeurs des capteurs), ou mixtes. Il est intéressant d'observer la priseen compte de la cohérence mutuelle via la notion de dispersion maximale mais on note deuxdi�érences importantes avec notre cohérence : un objet est daté uniquement à partir de l'âgedes objets utilisés pour le calculer et non par la date à laquelle il a été calculé ; l'informationtemporelle est limitée à l'âge de l'objet le plus vieux utilisé pour le calculer et ne mémorise passon historique de dépendance.

Remarquons également la problématique que pourrait poser des boucles dans les calculsd'objets dérivés. L'âge d'un objet étant celui du plus vieil objet utilisé, si un objet boucle (in-directement) sur lui-même, son âge ne change jamais. Il est par exemple impossible alors deconsidérer la cohérence d'un objet faisant l'addition de ses entrées successives.

Dans [UNR+01], les auteurs s'intéressent à la cohérence mutuelle dans un contexte de cacheweb. Quand un proxy sert de cache pour des éléments de pages web, il est important que l'en-semble des constituants de cette page (textes HTML, images ou vidéos, styles de mise en forme)restent mutuellement cohérents pour présenter à l'utilisateur une copie identique à (une versionde) l'original. La cohérence individuelle est gérée par les algorithmes de cohérence de cache maisceux-ci doivent être enrichis pour prendre en compte la cohérence mutuelle. L'idée des auteursest d'observer le rythme d'évolution de l'original pour déterminer le rythme auquel il faut in-terroger le serveur pour mettre à jour individuellement les réplicas a�n qu'ils ne divergent pastrop, et d'enrichir ensuite cet algorithme pour assurer une cohérence dite faible d'un ensembled'éléments (notion similaire à la dispersion précédemment évoquée). On retrouve donc ici la pro-blématique de la cohérence mutuelle mais l'architecture est simple : un seul proxy sur lequel sepose le problème de cohérence à partir d'un ensemble d'objets sans passé.

Dans [GH06], les auteurs s'intéressent à la propagation des mises à jour, en prenant encompte à la fois le domaine de validité des valeurs, le domaine de validité temporelle des objets,et les dépendances entre les objets. Les travaux sont ancrés dans les calculateurs de contrôle desmoteurs et plus généralement dans les systèmes temps réel embarqués. Les auteurs distinguentdeux fraîcheurs : une fraîcheur � sémantique �, en termes de valeurs, qui dit qu'une valeur passéeest fraîche si elle est assez proche, dans le domaine des valeurs, de la valeur actuelle ; et laclassique fraîcheur temporelle qui utilise l'écart entre la date actuelle et la date de création de lavaleur. Quand un objet est mis à jour, la question se pose de savoir si les données dérivées doiventl'être également, et ainsi de suite déclencher la propagation de calculs. Les auteurs s'intéressent enparticulier aux phénomènes de surcharge où il n'est plus possible d'assurer l'intégralité des calculsde mises à jour et où il est nécessaire d'abandonner certains d'entre eux. Ils distinguent donnéesessentielles et données non essentielles et remplacent éventuellement la fraîcheur temporelle parla fraîcheur sémantique, de manière à supprimer certains calculs jugés non essentiels. L'intérêtde ces travaux pour nous est de montrer la nécessité de considérer la cohérence d'un point devue global et non pas individuel, et que des approches relâchant la cohérence ont leur sens dansun contexte industriel.

En�n dans [JXR06], on retrouve une problématique similaire à celle de [SL95], mettant l'ac-cent sur la cohérence mutuelle : il ne su�t pas que les valeurs issues de capteurs externes soientfraîches pour que ces valeurs forment un ensemble cohérent découlant d'une perception instan-tanée (ou identique à une telle perception) du monde réel. Dans l'article, une donnée est ditedépendante d'une autre s'il est nécessaire que leurs instants de mises à jour soient assez proches

69

5.4 - Graphe et fuseaux

pour donner un aperçu cohérent du système réel qu'elles décrivent. Une transaction qui lit unensemble de données dépendantes doit obtenir un ensemble cohérent pour que son résultat soitsigni�catif. Les auteurs considèrent des transactions périodiques et non préemptives et cherchentà déterminer si un ordonnancement donné de requêtes et de mises à jour maintient la cohérencemutuelle des objets. L'objectif est en particulier de déterminer hors ligne si les paramètres destransactions (périodes, échéances) et l'ordonnancement choisi assurent la cohérence, ainsi quede déterminer une partie de ces paramètres. Notons que la cohérence temporelle ne s'intéresseici qu'à la perception du monde extérieur par l'intermédiaire de la lecture des valeurs issues decapteurs, mais pas à la cohérence des calculs qui en découlent, éventuellement indirectement.

De manière générale, peu de travaux s'intéressent spéci�quement à la cohérence mutuelle d'unpoint de vue temporel. En outre, la grande majorité de ces travaux se concentrent sur l'analysedes choix d'ordonnancement ou de gestion de la concurrence sur la cohérence mutuelle et surles performances qu'on peut en attendre. Nos travaux ont pris la philosophie opposée : nousconsidérons peu de contraintes d'ordonnancement et nous n'en produisons pas. Par contre, nousconsidérons la cohérence mutuelle dans sa globalité, sur un ensemble de chaînes de calcul.

5.4 Graphe et fuseaux

Avant de formaliser la cohérence précédemment introduite, nous donnons d'abord quelquesrésultats sur les graphes. Le système décrit par composants forme un graphe orienté, dans les-quels les composants sont les n÷uds du graphe et les liens de communication entre composants,des arcs orientés. Dans ce graphe, nous identi�ons les con�gurations provoquant des problèmesd'association de données.

5.4.1 Chemins et chemins séparés

Dé�nition 6 (Chemin) Un chemin est une séquence de n÷uds (C1,C2, . . . ,Cn) avec n > 1 où∀i ∈ [1..n − 1], il existe un arc entre Ci et Ci+1.

Lorsqu'il est nécessaire de distinguer les di�érents arcs entre deux n÷uds, les chemins sontnotés : (C1

a1−→ C2 . . .an−1−→ Cn), où les ai sont des étiquettes d'arc.

Dé�nition 7 (Chemin simple) Un chemin simple est un chemin dans lequel tous les n÷udssont distincts. Soit P = (C1,C2, . . . ,Cn) un chemin :

P = (C1,C2, . . . ,Cn) est simple∆= ∀i : ∀j : i 6= j ⇒ Ci 6= Cj

Remarquons qu'un chemin simple ne peut pas comporter de boucle.

Dé�nition 8 (Chemins séparés) Deux chemins simples sont séparés s'ils n'ont aucun n÷uden commun à l'exception de leurs n÷uds initiaux et �naux.

Soit P1 = (C1,C2, . . . ,Cn) et P2 = (C ′1,C′2, . . . ,C

′m) des chemins simples.

P1,P2 sont séparés∆=

(∀i : ∀j : 1 < i < n ∧ 1 < j < m ⇒ Ci 6= C ′j ) ∧ (C1 = C ′1) ∧ (Cn = C ′m)

5.4.2 Fuseaux : con�gurations problématiques

Un problème d'association de données se posent quand un composant C ′ utilise des donnéesprovenant du même composant C , données transitant par di�érents chemins de données. Gra-phiquement, nous trouvons deux composants, C et C ′, reliés par plusieurs chemins. La notionde fuseaux identi�e précisément les con�gurations problématiques.

70


Figure 5.6 � Exemple de chemins non séparés

Dé�nition 9 (Fuseau) Un fuseau entre deux n÷uds est l'ensemble des chemins reliant cesn÷uds tels qu'il existe au moins deux chemins séparés dans cet ensemble.

Dé�nition 10 (Source) La source d'un fuseau est le n÷ud initial des chemins composant cefuseau.

Dé�nition 11 (Puits) Le puits d'un fuseau est le n÷ud �nal des chemins composant ce fuseau.

Un fuseau est exactement la représentation graphique de la con�guration problématique iden-ti�ée dans la section 5.2. En e�et, il établit qu'un composant utilise des données dépendant, viaplusieurs chemins, de données fournies par un même composant initial.

Théorème 1 Un problème d'association de données peut intervenir entre deux composants si etseulement si il existe un fuseau entre eux.

Si un fuseau est présent entre deux composants, cela signi�e que plusieurs chemins séparéslient les deux composants. Des données dépendant de la source parviennent donc au composantpuits via plusieurs chemins pour lesquels rien n'indique que les temps de parcours sont égaux.Un problème de cohérence est donc à gérer sur ces données.

En sens inverse, si un problème de cohérence se pose entre un composant C et C ′ alors celasigni�e qu'il existe au moins deux chemins reliant C à C ′. Parmi ces chemins, au moins deuxchemins sont nécessairement séparés. En e�et, s'ils ne l'étaient pas, cela signi�erait :

� soit qu'il existe un composant C ′′ sur lequel les chemins se regroupent avant d'atteindreC ′. La cohérence des données se poserait alors entre C et C ′′, et non pas C et C ′.

� soit que les chemins partent de C et se séparent uniquement après un composant C ′′. Lacohérence des données se poserait vis-à-vis de C ′′ et non de C .

Un problème d'association de données n'étant à gérer que dans le cas où il existe au moinsdeux chemins séparés reliant C et C ′, il n'existe que lorsqu'un fuseau est présent entre C et C ′.

2

La �gure 5.6 illustre ces con�gurations. Entre C0 et C5, se trouvent bien deux chemins :(C0,C1,C2,C4,C5) et (C0,C1,C3,C4,C5). Ces deux chemins ne sont pas séparés car en plus deleurs n÷uds d'extrémité, ils partagent les composants C1 et C4. Ce n'est pas C0 qui émet desdonnées pour plusieurs composants mais C1, et le problème de cohérence de données ne se posepas en entrée de C5 mais bien sur les entrées de C4 qui regroupe plusieurs chemins provenantde C1. En e�et il existe bien deux chemins séparés entre C1 et C4. Cette présence de fuseau nousindique qu'il faut gérer la cohérence des données sur C4 par rapport à C1.

Notons qu'un système arbitraire peut comporter plusieurs fuseaux. Ces fuseaux peuvent éga-lement être imbriqués entre eux. Ainsi, le puits d'un fuseau peut être la source d'un autre, dessous-chemins d'un fuseau peuvent composer un fuseau, le puits d'un fuseau peut être le compo-sant quelconque d'un autre fuseau. . .

Sur la �gure 5.7, l'ensemble des trois chemins simples {(C1,C2,C4,C6,C7), (C1,C2,C5,C6,C7),(C1,C3,C7)} est un fuseau de source C1 et de puits C7 : cet ensemble contient les deux chemins

71

5.4 - Graphe et fuseaux

Figure 5.7 � Exemple de fuseau complexe

A

B

C

D

F

E

Figure 5.8 � Exemple de fuseaux imbriqués

séparés (C1,C2,C5,C6,C7) et (C1,C3,C7). Notons que cet ensemble contient aussi des cheminsnon séparés. Le problème de cohérence existe à partir du moment où il y a au moins deux cheminsséparés, mais, lors de la mise en ÷uvre des solutions, nous aurons besoin de tous les cheminsentre la source et le puits.

Par ailleurs, ce graphe contient un fuseau imbriqué : l'ensemble {(C2,C4,C6), (C2,C5,C6)}forme également un fuseau de source C2 et de puits C6.

5.4.3 Fuseaux imbriqués, fuseau principal

Un système peut comporter plusieurs fuseaux. Ce qui importe alors est de pouvoir déterminersi un fuseau in�uence le comportement d'un autre. Si les fuseaux ne partagent aucun composant,il est évident que leurs comportements ne vont pas s'in�uencer. Par contre, des di�cultés peuventse présenter dans le cas de fuseaux imbriqués.

Dé�nition 12 (Fuseaux imbriqués) Deux fuseaux F et F ′ sont imbriqués si leurs cheminspartagent au moins un composant :

∃P = (C1,C2, . . . ,Cn) ∈ F ∧ ∃P ′ = (C ′1,C′2, . . . ,C

′m) ∈ F ′ :

∃i : 1 ≤ i ≤ n ∧ ∃j : 1 ≤ j ≤ m : Ci = C ′j

La �gure 5.8 est un exemple de graphe avec deux fuseaux imbriqués, qui partagent ici deuxcomposants dont leurs puits.

Un sous-fuseau est un cas particulier de fuseau imbriqué, où le sous-fuseau est totalementinclus dans le fuseau avec lequel il est imbriqué.

72


Dé�nition 13 (Sous-fuseau) Un fuseau F ′ est un sous-fuseau de F si F ′ est composé de sous-chemins de F :

∀P ′ = (Ci ,Ci+1, . . . ,Cj ) ∈ F ′,∃P = (C1,C2, . . . ,Cn) ∈ F :

1 ≤ i ≤ j ≤ n ∧ ∀x ∈ [i ..j ],Cx ∈ P

Sur la �gure 5.7, le fuseau entre C2 et C6 est un sous-fuseau du fuseau entre C1 et C7.

Dé�nition 14 (Fuseau simple) Un fuseau simple est un fuseau ne contenant pas de sous-fuseau.

Dé�nition 15 (Fuseau principal) Un fuseau principal est un fuseau n'étant pas sous-fuseaud'un autre.

5.5 Formalisation de la cohérence

Nous avons dé�ni informellement ce que nous considérons comme étant une exécution cohé-rente dans la section 5.2. Nous allons dans ce qui suit proposer une dé�nition formelle de cettenotion.

Nous considérons une exécution d'un système réparti modélisée par trois types d'événements :� événements d'émission (notés e)� événements de délivrance (notés d)� événements internes (notés i)Nous notons eC , dC ou iC un événement ayant lieu sur le composant C .Nous notons dC un événement de délivrance correspondant à la délivrance d'un message

venant du composant C . L'événement noté dCC ′ est donc un événement de délivrance ayant lieusur C ′ et correspond à un message envoyé par C .

Les événements internes correspondent aux pas de calculs et sont considérés de durée nulle.À chaque pas d'exécution d'un composant correspond un et un seul événement interne. De plus,au sein d'un pas d'exécution, un composant lit tout d'abord tous les messages liés aux événe-ments de délivrance qui lui sont nécessaires, puis réalise son événement interne et en�n provoqueses événements d'émission. Le déclenchement des divers événements d'émission sur chacun desports de sortie peut être atomique ou étalé dans le temps. Nous considérons indi�éremment dessystèmes dynamiques (dont la con�guration évolue dans le temps) ou statiques.

Comme usuel, nous notons ≺ la relation de précédence temporelle entre événements sur uncomposant.

5.5.1 Relation d'in�uence directe

La relation d'in�uence directe → est dé�nie ainsi :� pour un message m, l'envoi in�ue sur la délivrance :

e(m)→ d(m)

� un événement interne in�ue sur les émissions qui suivent jusqu'à l'événement interne sui-vant : si e et i sont sur le même composant, que e est postérieur à i et qu'il n'existe pasde i ′ entre i et e alors i → e :

iC → eC ssi ∀eC , iC : iC ≺ eC ∧ 6∃i ′C : iC ≺ i ′C ≺ eC

73

5.5 - Formalisation de la cohérence

� la dernière délivrance venant d'un composant in�ue sur les événements internes qui suivent,jusqu'à la prochaine délivrance venant du même composant : si dC

′et i sont sur le même

composant, que i est postérieur à dC′et qu'il n'existe pas de DC ′ entre dC

′et i , alors

dC′ → i :

dC′

C → iC ssi ∀dC′

C , iC : dC′

C ≺ iC ∧ 6∃DC ′

C : dC′

C ≺ DC ′

C ≺ iC

5.5.2 Relation d'in�uence

La relation d'in�uence, notée →∗, est la clôture transitive de → :

a →∗ b ∆= a → b ∨ ∃c : a →∗ c ∧ c →∗ b

Notons que i →∗ i ′ si et seulement si il existe une séquence respectant le motif suivant :i → e1 → d1 → i2 → e2 → d2 → i3 · · · → i ′.

Comparaison avec la relation de causalité La relation d'in�uence est plus forte que larelation de causalité : si a in�uence b alors a précède causalement b. La réciproque n'est pasnécessairement vraie. En particulier, la séquentialité des événements (de délivrance ou d'émission)sur un composant n'est pas une in�uence car seuls les pas de calculs créent une dépendance. Enoutre seul le dernier message reçu depuis un destinataire donné compte.

Notons également qu'un événement interne en in�uence un autre uniquement s'il existe unéchange de message entre eux. Deux événements internes consécutifs se déroulant sur le mêmecomposant ne s'in�uencent pas directement car nous nous intéressons à la circulation de l'infor-mation entre les composants, et non pas au sein d'un composant. Cela signi�e qu'un événementinterne est directement in�uencé par les derniers événements délivrés par d'autres composantsmais pas par le dernier événement interne.

Les événements de délivrance sont conservés jusqu'à ce qu'un événement plus récent soitutilisé et � écrase � le précédent. Nous voyons ici que la relation d'in�uence est plus proche d'unedescription d'un système distribué par un modèle mémoire que par un modèle message : dansnotre modèle les messages sont des ressources réutilisables plus que consommables.

5.5.3 Passé d'in�uence

Le passé d'in�uence d'un événement i est dé�ni comme l'ensemble des événements internesqui in�uent sur i :

passé(i)∆= {i ′ | i ′ →∗ i}

5.5.4 Cohérence stricte

D'après la dé�nition 3, si un composant C ′ utilise plusieurs données dont les valeurs dépendentde sorties d'un même composant C , alors ces données d'entrée de C ′ seront considérées commestrictement cohérentes si elles dépendent de données produites par le même pas de calcul de C .

En termes de relation d'in�uence, les données dont dépend une autre donnée d se traduisentpar le passé d'in�uence de l'événement interne qui a produit d . Nous souhaitons donc que cepassé d'in�uence ne comporte pas des données provenant de di�érents pas d'un même composant.Dans notre modèle, les pas sont modélisés par des événements internes.

Nous notons S |C l'ensemble des événements de l'ensemble S se déroulant sur le composant C .

74


Dé�nition 16 Une exécution est (strictement) cohérente si tout événement interne ne contientdans son passé d'in�uence qu'au plus un événement interne par composant :

∀i : ∀C : card(passé(i)|C}) ≤ 1

Notons que cette propriété peut être utilisée sur des graphes de composants dynamiques. En e�et,nous comparons les événements internes présents dans les passés d'in�uence sans avoir besoin deconnaître l'architecture du système. Celle-ci peut donc évoluer en cours d'exécution.

5.5.5 Cohérence relâchée

La notion de cohérence relâchée dé�nie dans le paragraphe 5.2.2 se formalise également parla relation d'in�uence.

Nous utilisons une datation temps réel pour dater les événements se déroulant durant l'exé-cution du système. La date de l'événement interne i est notée date(i) .

Nous notons ecart(E ) l'écart maximal entre les événements contenus dans E :

ecart(E )∆= max

i1,i2 ∈ E(date(i1)− date(i2))

Dé�nition 17 Une exécution cohérente τ -relâchée est telle que :

∀i : ∀C : ecart(passé(i)|C ) ≤ τ

Une exécution cohérente 0-relâchée est une exécution strictement cohérente. Notons que danscette dé�nition nous comparons des dates d'événements se déroulant sur un même composant.Ainsi, une horloge globale n'est jamais requise.

Dans un système réel, il arrive fréquemment que nous ne souhaitons pas la même tolérancede cohérence sur tous les composants. La dé�nition d'une exécution cohérente sera alors telle quechaque composant respecte sa tolérance �xée, et ce vis-à-vis de chaque autre composant dont ildépend. Si nous notons τCC ′ la tolérance de cohérence entre les sorties d'un composant C et lesentrées d'un composant C ′, nous avons alors la dé�nition suivante d'une exécution cohérente τ -relâchée :

∀C ′ : ∀iC ′ : ∀C : ecart(passé(iC ′)|C ) ≤ τCC ′

5.5.6 In�uence entre données

Dans le paragraphe 5.5.2, la relation d'in�uence est dé�nie entre événements. Il est parfoisplus aisé de se placer dans un modèle orienté données.

Dé�nition 18 (In�uence entre données) Une donnée d produite par un pas d'exécution Sin�uence une donnée d ′ produite par un pas d'exécution S ′ si l'événement interne modélisant lepas S in�uence l'événement interne modélisant le pas S ′.

En d'autres termes, d in�uence d ′ si d est directement utilisée pour calculer d ′ ou si unedonnée dépendant de d est utilisée pour calculer d ′. Voir la dé�nition 1 de la dépendance duparagraphe 5.2.

Nous dirons également qu'un pas S in�uence une donnée d ′ si une donnée produite lors dupas S in�uence la donnée d ′.

75

5.6 - Codage de la relation d'in�uence

5.6 Codage de la relation d'in�uence

A�n de contrôler la cohérence d'une exécution telle qu'elle est dé�nie dans le paragraphe 5.5,il faut que chaque composant soit capable de connaître le passé d'in�uence de ses événementsinternes. S'il a accès à ce passé, le composant peut alors véri�er si son exécution est cohérente.Une solution pour que chaque composant puisse connaître le passé d'in�uence d'un événementest que l'événement lui-même transporte cette information. Pour cela, une estampille est attachéeà chaque événement.

5.6.1 Marquage

Dé�nition 19 Un marquage est un couple 〈Composant , valeur〉 où les valeurs sont choisiesparmi n'importe quel ensemble in�ni.

L'ensemble des valeurs n'a pas besoin d'être ordonné. Cependant, une implantation simpleutilise un compteur croissant pour générer des valeurs distinctes successives : chaque composantpossède une horloge logique H (C ) qui marque les événements internes produits par le composant.Cette horloge compte le nombre de pas d'exécution réalisés par un composant. Ainsi, chaquemarquage correspond à un événement interne d'un composant. À chaque marquage, noté Mi ,correspond un unique événement interne i et réciproquement.

5.6.2 Estampille

Dé�nition 20 Une estampille est un ensemble de marquages. Elle code le passé d'in�uence d'unévénement. L'estampille portée par l'événement a est notée Ea .

Dé�nition 21 L'ensemble Input(iC ) contient les événements de délivrance utilisés pour réaliserun événement interne :

Input(ic)∆= {dc

′

c : (dc′

c ≺ ic ∧ 6∃Dc′

c : dc′

c ≺ Dc′

c ≺ ic)}

Règles d'estampillage� Un événement de délivrance d a pour estampille l'estampille de l'émission correspondante :

Ed(m) = Ee(m)

� Un événement d'émission e a pour estampille l'estampille du plus récent événement internequi le précède.

Ee = Ei tq i ≺ e ∧ 6∃i ′ : i ≺ i ′ ≺ e

� Un événement interne i d'un composant C a pour estampille l'ensemble des estampillesdes événements de délivrance qu'il utilise à ce pas de calcul auquel il ajoute son propremarquage :

Ei =⋃

d ∈ Input(i)

Ed ∪ {〈C ,H (C )〉}

et H (C ) est incrémentée.

Lemme 1 (Estampilles et marquages)

Ei = {Mi} ∪ {Mj | j →∗ i} où i est un événement interne

Noter que vu les règles d'estampillage, on peut prendre indi�éremment dans le passé de iaussi bien tous les types d'événements que seuls les événements internes.

76


Preuve Nous notons :

i17→ i ′

∆= ∃e, d : i → e → d → i ′ où i et i ′ sont des événements internes

in7→ i ′

∆= ∃i ′′ : i

17→ i ′′ ∧ i ′′ n−17→ i ′

Par les règles d'estampillages :

Ei = {Mi} ∪⋃

j | j 17→i

Ej

= {Mi} ∪⋃

j | j 17→i

({Mj} ∪

⋃k | k 17→j

Ek)

= {Mi} ∪⋃

j | j 17→i

{Mj} ∪⋃

j | j 17→i

⋃k | k 17→j

Ek

= {Mi} ∪⋃

j | j 17→i

{Mj} ∪⋃

k | k 27→i

Ek

= {Mi} ∪⋃

j | j 17→i

{Mj} ∪⋃

k | k 27→i

({Mk} ∪

⋃l | l 17→k

El)

= {Mi} ∪⋃

j | j 17→i

{Mj} ∪⋃

k | k 27→i

{Mk} ∪⋃

l | l 37→i

El

= {Mi} ∪⋃

1≤y≤n

⋃j |j y7→i

{Mj} ∪⋃

j | jn+17→ i

Ej

Toutes les chaînes 7→ sont bornées (existence d'un événement initial)

= {Mi} ∪⋃y≥1

⋃j |j y7→i

{Mj}

= {Mi} ∪ {Mj | j →∗ i}2

Théorème 2 L'estampillage est un codage de l'in�uence :

i →∗ i ′ ⇔ Ei ⊂ Ei′ pour i , i ′ événements internes

Preuve L'implication directe est déduite des règles d'estampillage et de la transitivité de→∗ :

Si i → e → d → i ′, alors par les règles d'estampillage :⇒ Ei′ = {Mi′} ∪ Ei ∪X

Mi′ est unique et provient seulement de i ′.Comme i ′ 6→∗ i ∧ i 6= i ′,Mi′ /∈ Ei

⇒ Ei Ei′

En utilisant la transitivité de →∗ :i →∗ i ′ ⇔ i → . . .→ i ′ ⇒ Ei Ei′

L'implication inverse provient des règles d'estampillage et du lemme 1 :

Ei Ei′ ⇒ Mi ∈ Ei′ (lemme 1)⇔ Mi ∈ {Mi′} ∪ {Mj | j →∗ i ′} (lemme 1)Un marquage est unique et i 6= i ′ ⇒ Mi 6= Mi′

⇔ Mi ∈ {Mj | j →∗ i ′}⇒ ∃j : Mi = Mj ∧ j →∗ i ′Un marquage est unique :⇔ i →∗ i ′

77

5.6 - Codage de la relation d'in�uence

Figure 5.9 � Construction d'estampilles : détection d'exécution incohérente

2

Théorème 3 Nous notons Ea |C, l'ensemble des marquages contenu dans Ea qui sont généréspar un composant C . Une exécution est cohérente si et seulement si il n'existe pas plusieursmarquages provenant d'un même composant dans l'estampille de tout événement interne.

Exécution cohérente = ∀i : ∀C : card(Ei |C ) ≤ 1

PreuveEi = {Mi′ | i ′ →∗ i} ∪ {Mi}

= {Mi′ | i ′ →∗ i ∨ i ′ = i}= {Mi′ | i ′ ∈ passé(i)}

Deux événements distincts ne peuvent pas générer le même marquage, donc le nombre de mar-quages et le nombre d'événements sont égaux :

card({Mi′ | i ′ ∈ passé(i)}|C ) = card(passé(i)|C )(avec une restriction sur C ou non), et donc

card(Ei |C ) = card(passé(i)|C )

Cette condition est équivalente à la condition de cohérence dé�nie au paragraphe 5.5.2

La �gure 5.9 retrace l'exécution incohérente de la �gure 5.5. Nous suivons les événements sedéroulant sur chaque composant du système avec leurs estampilles correspondantes. Nous consta-tons que l'estampille du dernier événement interne de C3 contient deux marquages di�érents deC0. Nous détectons ainsi que les messages utilisés par cet événement interne sont in�uencés pardeux pas d'exécution di�érents de C0. L'exécution est donc incohérente.

Comparaison avec d'autres types d'encodage Notre travail est dans le même esprit queles travaux classiques de Lamport [Lam78] et Mattern [Mat89] encodant la relation de causalité

78


dans un système distribué. Cependant, notre relation d'in�uence étant di�érente de la relationde causalité habituelle, nous utilisons un codage di�érent. L'horloge locale ne se comporte pascomme une horloge de Lamport (l'horloge n'est pas mise à jour en utilisant les estampilles desmessages) et les estampilles associées aux messages ne sont pas des vecteurs d'horloge de Fidge-Mattern. Nous utilisons un ensemble, non pas pour optimiser le codage d'un vecteur creux, maisparce que nous pouvons avoir plus d'un marquage provenant d'un même composant. Cependant,notons que lors d'une exécution strictement cohérente, il n'y aura jamais plus d'un marquagepar composant et un vecteur pourrait alors être utilisé à la place d'un ensemble (ceci n'est plusvrai dans le cas de la cohérence relâchée).

5.6.3 Composants marqueurs et contrôleurs

A�n de réduire le nombre de marquages utilisés dans le système, nous identi�ons les compo-sants qui doivent produire des marquages. Nous identi�ons également les composants sur lesquelsun contrôle de cohérence devra être réalisé.

Nous avons vu dans le paragraphe 5.4.2, qu'un problème d'association de données peut inter-venir entre deux composants si et seulement si il existe un fuseau entre eux. Ainsi, un contrôle decohérence de données doit être réalisé sur chaque puits par rapport aux marquages de la sourcedu fuseau. Nous pouvons donc réduire le nombre de marquages en ne produisant des marquagesque pour les sources de fuseau.

Propriété 1 Chaque source de fuseau est un composant marqueur et chaque puits est un com-posant contrôleur.

Théorème 4 Les estampilles restreintes aux marquages issus des sources sont le codage minimalnécessaire et su�sant à la délivrance d'un ensemble cohérent de valeurs.

Nous avons vu que les estampilles codaient l'in�uence (théorème 2) et qu'une exécutionétait cohérente s'il n'y avait qu'au plus un marquage par composant (théorème 3). Comme lescomposants non sources ne peuvent introduire qu'un seul marquage, il n'est pas nécessaire deles inclure dans les estampilles et il su�t donc de ne transmettre que les marquages issus dessources.

Inversement, on sait que la présence d'un fuseau est synonyme d'incohérence potentielle (théo-rème 1). Il existe donc au moins deux chemins entre la source et le puits. Sans hypothèses sup-plémentaires, le délai entre ces deux chemins est non borné (système asynchrone), il est doncnécessaire de distinguer des pas de la source arbitrairement éloignés, donc un codage isomorpheaux entiers. La dé�nition de la cohérence est liée à chaque composant (en pratique à chaquesource), il est donc nécessaire de distinguer les pas de chacune des sources. Le codage des estam-pilles par marquage est donc minimal.

2

Nous voyons ici que le problème de la délivrance cohérente est nettement distinct du problèmede la délivrance causale. Alors même que l'in�uence et le codage de celle-ci se rapproche de lacausalité et de son codage, la délivrance cohérente est directement soluble avec le codage del'in�uence, alors que la délivrance causale n'est pas soluble simplement avec le codage de larelation de causalité, sauf dans le cas particulier de la di�usion complète sur un ensemble fermé(cf section 4.5.1.1).

5.6.4 Élimination des marquages inutiles

Nous pouvons également optimiser la propagation des marquages lorsqu'un marquage n'estplus utile. En e�et, il n'est pas nécessaire de propager le marquage d'un composant C dans les

79

5.7 - Formalisation en TLA+

estampilles des données si aucun contrôle de cohérence sur ce marquage n'est e�ectué au-delà. Lemarquage de C n'est utile que pour les puits de fuseaux de source C . Il est donc possible que lepuits de ce fuseau ne propage pas les marquages de C dans l'estampille de ses sorties. Attentiontoutefois à la présence de fuseaux imbriqués pouvant impliquer qu'un composant soit sourcede plusieurs fuseaux : dans ce cas, le marquage ne doit être supprimé qu'après le dernier puitstraversé par des données correspondant à cette source. Il s'agit des puits des fuseaux principauxde source C .

5.6.5 Cohérence relâchée

Dans le cas de la cohérence relâchée, l'identi�cation de la compatibilité entre deux données nese fait pas sur l'égalité du pas d'exécution dont elles dépendent mais sur l'écart temporel maximalentre ces pas d'exécution. Dans le marquage servant à identi�er un pas, nous remplaçons la valeurarbitraire (qui servait à véri�er l'identité) par une datation temps réel :

Dé�nition 22 (Marquage temps réel) Un marquage est un couple 〈Composant , valeur〉 oùles valeurs représentent le temps.

La représentation du temps doit utiliser une granularité su�sante pour distinguer deux pasd'exécution, ainsi que par rapport à l'écart τ retenu pour la cohérence relâchée.

La dé�nition d'estampille ne change pas : une estampille est un ensemble de marquages, quistocke le passé d'in�uence d'un événement.

Nous ne changeons pas non plus les règles d'estampillage, et, sous réserve que les valeursdes marquages ne soient pas réutilisées (c'est nécessairement le cas avec une datation tempsréel de granularité plus �ne que la durée des pas d'exécution), l'estampillage reste un codage del'in�uence.

L'écart maximal entre les marquages d'une estampille est :

écart(E ) = maxMi ,Mi′ ∈ E

(d1 − d2 tq Mi = 〈 , d1〉,Mi′ = 〈 , d2〉)

La cohérence relâchée est alors véri�ée par une exécution si

Exécution cohérente relâchée = ∀i : ∀C : écart(Ei |C ) ≤ τ

Notons que toutes les comparaisons de marquage, et donc de temps, se font vis-à-vis du mêmecomposant. Il n'est donc pas nécessaire que les horloges de datation des di�érents composantssoient synchronisées.

5.7 Formalisation en TLA+

Nous avons formalisé en TLA+ [Lam94, Lam03] la cohérence en termes de passé d'in�uenceet en termes d'estampille, de manière à véri�er l'équivalence entre les deux. Cette formalisationest basée sur cinq modules, présentés dans l'annexe B.

5.7.1 Les modules

Le module Common contient les concepts communs aux autres modules, à savoir sites etévénements, et deux fonctions auxiliaires.

Le module In�uence gère le passé d'in�uence ; il stocke le dernier message reçu depuis chaquesite (variable irecus) et le passé d'in�uence de chaque événement interne (variable in�uence).

80


Le module Estampillage applique les règles d'estampillages ; une estampille est un ensemblede marquages ; on conserve la dernière estampille reçue depuis chaque site (variable erecus), eton calcule le passé d'in�uence de chaque événement interne (variable estampille) en utilisantl'horloge locale à chaque site (variable horloge).

Les modules Calcul* contiennent la formalisation d'un calcul réparti ; un pas du calcul peutêtre un envoi de message contenant une charge utile (action envoyer), une réception de message(action recevoir), un événement interne (action internal). Trois formalisations sont dispo-nibles :

� CalculASync : calcul asynchrone. Les pas d'envoi, réception ou d'événement interne sontindépendants ; la communication est �able mais non ordonnée (pas nécessairement �fo).Le calcul débute sur un seul site et les autres sites deviennent actifs sur réception d'unmessage. Ce calcul est le plus général et englobe les deux autres.

� CalculFifo : calcul asynchrone (envoi/réception/événement interne indépendant) mais aveccommunication globalement �fo (ce qui est plus strict qu'une communication �fo par coupleémetteur/destinataire). Comme précédemment, le calcul débute sur un seul site et les autressites deviennent actifs sur réception d'un message.Ce calcul est intermédiaire entre le calcul asynchrone et le calcul synchrone : les sitessont asynchrones mais la communication est globalement ordonnée. Il présente surtout unintérêt dans la maîtrise de la complexité du calcul asynchrone, réduisant considérablementl'espace d'états de la partie communication. Son intérêt reste cependant limité et il n'estpas plus détaillé dans la suite.

� CalculSync : calcul synchrone :� un site qui émet ne peut rien faire d'autre tant que le message n'a pas été délivré ;� un site pour lequel il existe un message à sa destination ne peut rien faire d'autre que lerecevoir ;

� une seule communication peut avoir lieu simultanément ;� par contre, un site non concerné par la communication peut faire un (ou des) pas internes.Comme précédemment, le calcul débute sur un seul site et les autres sites deviennent actifssur réception d'un message.

Le module Verif véri�e que l'estampillage est un codage exact de l'in�uence (propriété tem-porelle 2EstampilleEgaleIn�uence). On fait évoluer en parallèle in�uence et estampillage, et onvéri�e que la propriété � être in�uencé par � est équivalente à l'inclusion des estampilles.

5.7.2 Résultats

La véri�cation des propriétés 2TypeInvariant et 2EstampilleEgaleIn�uence a été e�ectuéepar le véri�cateur de modèles (model checker) TLC, donc nécessairement dans un monde �ni 1.Dans le cas de notre système non borné, cette validation devient donc plus empirique que rigou-reuse. La propriété d'équivalence a été véri�ée avec les calculs synchrone (table 5.1) et asynchrone(table 5.2), sous les contraintes indiquées dans les tableaux. L'indicateur † indique que l'explora-tion des états n'a pas été exhaustive (interruption après plusieurs heures d'exploration) et permetde juger des limites de l'approche.

5.8 Application

Les dé�nitions et résultats précédents ont été appliqués dans le contexte de systèmes tempsréel. Deux études ont eu lieu : tout d'abord les systèmes monopériodiques, où tous les composants

1. Et pratiquement, un petit monde �ni. . .

81

5.8 - Application

Contraintes Résultatsnb de sites nb maximal nb maximal de profondeur du nb d'états

d'évts internes messages en transit graphe d'états distincts explorés3 11 * 15 15153 21 * 25 99304 11 * 17 174204 21 * 27 2134405 11 * 19 1998655 21 * 29 45857306 11 * 21 22912506 21 * 31 985044007 11 * 23 262497557 21 * 33 481144309 †

(Le nombre de message en transit est nécessairement au plus 1)

Table 5.1 � Équivalence passé d'in�uence - estampillage pour le calcul synchrone

Contraintes Résultatsnb de sites nb maximal nb maximal de profondeur du nb d'états

d'évts internes messages en transit graphe d'états distincts explorés3 11 3 17 2897833 11 4 18 12770443 21 4 28 1178421583 11 5 19 42585944 11 3 19 83993354 21 3 29 379607569 †4 11 4 20 598560374 11 5 21 3228958695 11 3 21 179292981

Table 5.2 � Équivalence passé d'in�uence - estampillage pour le calcul asynchrone

82


partagent la même période (ou, sans di�culté, toutes les périodes des composants sont multiplesd'une même horloge de base), d'autre part les systèmes multipériodiques où chaque composantest périodique mais indépendant des autres.

5.8.1 Systèmes monopériodiques

5.8.1.1 Modèle

Le modèle retenu est proche de celui de Giotto [HHK03]. Les systèmes monopériodiques sontdes systèmes synchrones, où tous les composants partagent la même horloge. À l'intérieur d'unepériode, nous ne faisons pas d'hypothèse sur la durée des pas de calcul des composants et nous neconnaissons pas leur ordonnancement. Nous imposons cependant que tous les composants aientterminé leur pas de calcul à la �n de leur période.

Chaque composant peut avoir plusieurs entrées et plusieurs sorties. Toutes les entrées d'uncomposant sont lues simultanément au début de son pas de calcul, ses données de sorties sontémises simultanément à la �n de son pas de calcul. Il n'y a donc pas de communication entrecomposants au cours d'une période. Un composant ne peut disposer d'une donnée que si cettedonnée a été produite par un autre composant au plus tard à la période précédente.

L'étude menée a supposé que tous les composants débutent leurs périodes simultanémentmais il a aussi été montré qu'un déphasage �xe était facilement intégrable aux résultats.

5.8.1.2 Résultats

Les résultats obtenus sont détaillés dans le mémoire de thèse de N. Pontisso [Pon09]. Gros-sièrement, une analyse du graphe de composants, qui ne doit pas présenter de cycles, permet dedéterminer statiquement la longueur des �les d'attente en entrée de chaque port des composantspuits. Ces �les servent à régulariser la longueur des di�érents chemins qui relient une source àun puits.

La di�culté de l'analyse réside dans la détermination des plus petites �les nécessaires dansle cas de fuseaux imbriqués. L'étude a montré qu'une analyse peu coûteuse considérant indépen-damment chaque fuseau principal (fuseau qui n'est pas inclus dans un autre fuseau) permet detrouver ces �les minimales dans les cas favorables. Par contre en cas d'imbrication de fuseauxprincipaux (deux fuseaux dont aucun n'est totalement inclus dans l'autre), l'étude aboutit à uneapproche globale non optimale.

5.8.2 Systèmes multipériodiques

L'objectif de l'analyse dans le cas de systèmes multipériodiques est autant d'identi�er lesproblèmes de cohérence que de fournir les outils pour les résoudre. L'idée est que cette analysesurvient tôt dans le processus de développement. En particulier, elle peut être e�ectuée sans quel'ordonnancement ou le type d'ordonnanceur utilisé ne soient connus. Le modèle retenu est lâcheet ne contient que le nombre minimal de paramètres nécessaires pour permettre de résoudre leproblème d'association de données sans restreindre trop fortement le type de système sur lequella méthode peut être appliquée.

Les résultats obtenus sont d'une part la détection du risque d'incohérence, et d'autre partune solution à base de �les d'attente de taille bornée. Si cette taille est acceptable compte tenudes contraintes matérielles, on peut alors considérer que le problème de cohérence est résolu ;sinon cela signi�e qu'il faut repenser l'architecture du système, d'où l'importance d'une analyseprécoce.

83

5.8 - Application

5.8.2.1 Modèle

Modèle d'exécution. Les systèmes étudiés sont dirigés par le temps et sont composés decomposants périodiques, dont les périodes sont indépendantes et peuvent donc être di�érentes. Unpas d'exécution d'un composant peut être instantané ou durer jusqu'à la totalité d'une période.Durant deux périodes consécutives, les pas d'exécution peuvent avoir des durées di�érentes. Leurdate de début d'exécution peut aussi être di�érente par rapport à la date de début de leur période.

Durant un pas d'exécution, un composant lit une fois chacun de ses ports d'entrée, ensuiteil réalise son exécution et pour �nir il écrit une fois sur chacun de ses ports de sortie. Si nousconsidérons un modèle à messages, un composant reçoit exactement un message sur chaque portd'entrée et envoie exactement un message sur chaque port de sortie. La lecture des di�érentsports ne se fait pas forcément simultanément, de même pour les écritures. Un composant doit�nir son exécution avant la �n de sa période. Il ne peut émettre des données avant de s'êtreexécuté pendant son temps d'exécution minimal, mais ce temps peut être nul, modélisant uncomposant instantané. Un pas peut être découpé en morceaux, par un ordonnanceur préemptifpar exemple.

La cohérence est gérée par rapport à chaque composant à travers les marquages et les estam-pilles et nous n'utilisons pas directement d'horloge globale. Cependant, nous avons tout de mêmebesoin que les composants partagent la même unité de temps. A�n de calculer les propriétés dessystèmes étudiés, nous calculons des temps globaux. Si le système ne dispose pas d'une horlogeglobale, il est donc nécessaire qu'il dispose d'un mécanisme de synchronisation ou de recalaged'horloges.

Modèle de communication. Nous supposons que les communications sont FIFO, �ables eten temps borné. Les bornes minimales et maximales des temps de communication entre chaquecouple de composants sont connues. La borne minimale peut être nulle, modélisant une mémoirenon transactionnelle. Un temps de communication non nul permet par contre de modéliser unréseau de communication à base de messages. La borne supérieure des temps de communicationest naturelle dans un contexte temps réel, par exemple lorsque les communications sont réaliséespar un bus synchrone ou à qualité de service garantie.

5.8.2.2 Résultats

Résumé. Les résultats sont de plusieurs ordres. Tout d'abord il a été montré que ce modèleest plus souple que le modèle monopériodique et qu'il ne su�t pas de simplement rallonger leschemins les plus rapides par des �les ou des composants retardateurs pour obtenir la cohérence :les estampilles sont nécessaires. Pour autant, il a été montré que, connaissant les périodes descomposants et les bornes supérieures des délais de communication, on pouvait déterminer lataille maximale des �les d'attente nécessaires en entrée des puits. Il est en e�et possible dedéterminer au bout de combien de temps une donnée en entrée devient inutile, c'est-à-dire qu'ilne sera plus jamais possible de l'apparier avec des données en entrée sur les autres ports pourformer un ensemble cohérent. En�n la mise en ÷uvre de la cohérence relâchée au moyen de �les�ltrantes (ne gardant qu'une valeur sur N , N étant un paramètre lié à la tolérance de cohérence)a aussi été étudiée, permettant d'obtenir des �les de taille bien plus faible. Ces résultats et leursdémonstrations sont détaillés dans [Pon09].

Taille des �les. Soit les paramètres du système détaillés tableau 5.3, et soit un fuseau entre Cαet Cβ constitué de deux chemins PA et PB . On détermine les temps de propagation minimal et

84


TC période du composant C .eC temps d'exécution minimale du composant C . Peut être nul.∆CC ′ délai maximal de communication entre C et C ′.δCC ′ délai minimal de communication entre C et C ′. Peut être nul.

Table 5.3 � Paramètres du système

maximal sur un chemin P = (C1,C2,C3, . . . ,Cn) :

tmax (P) =

n−1∑i=1

[2TCi+ ∆CiCi+1 ]

tmin(P) =

n−1∑i=1

[eCi+ δCiCi+1

]

En supposant que tmax (PA) ≥ tmin(PB ), alors la taille de �le nécessaire est (où C ′m−1 estl'avant dernier composant du chemin PB ) :

N =

⌊ tmax (PA)− tmin(PB ) + 2TCβ− eCβ

− eC ′m−1

TC ′m−1

⌋+ 2

Ce résultat se généralise facilement aux fuseaux de plus de deux chemins.Pour la cohérence τ -relâchée, on détermine le taux de �ltrage de la �le : une donnée sur R

est conservée ; et on détermine la taille N de �le nécessaire :

R ≤ max(1,2τ − tmax (PB ) + tmin(PB ) + ∆C ′

m−1Cβ− δC ′

m−1Cβ

TC ′m−1

+ 1)

N =

⌈ tmax (PA)− τ − tmin(PB )− eC ′m−1

+ (R + 1)TC ′m−1

+ 2TCβ− eCβ

RTC ′m−1

⌉

5.8.2.3 Limitations

Le dernier sujet abordé est celui de la vivacité, c'est-à-dire de la capacité par un puits àconstruire de nouveaux ensembles cohérents de données.

Perte de données. Du fait du rapport des périodes et de la relative liberté d'exécution laisséeau système, certains composants agissent comme des �ltres en ne transmettant pas toutes lesdonnées qu'ils reçoivent. Par exemple, si C1 est un composant de période T et qu'il communiqueavec un composant C2 de période 2T , C2 n'utilisera en moyenne qu'une donnée sur deux fourniepar C1. C2 agit alors comme un �ltre pour les données de C1. Ce faisant, il casse les chaînesd'in�uence et un puits ultérieur ne recevra pas sur toutes ses entrées des données in�uencées partous les pas de la source. Il n'est alors pas garanti que le puits soit capable de construire desensembles cohérents à partir de ses entrées.

Prenons le fuseau entre C1 et C4 de la �gure 5.10 composé des chemins P1 = (C1,C2,C4) etP2 = (C1,C3,C4) tel que C1 est de période T et C2 et C3 sont de période 2T . Les composantsC2 et C3 ne laissent passer en moyenne qu'une donnée sur deux émises par C1. Supposons que lescomposants C1, C2 et C3 ont un rythme d'exécution régulier, c'est-à-dire que chaque composant

85

5.9 - Conclusion

Figure 5.10 � Système pouvant générer des pertes de données

a un temps d'exécution �xe et une date de début d'exécution �xe elle aussi par rapport audébut d'une période. Avec cette exécution régulière, C2 et C3 lisent exactement une donnée surdeux consécutives produites par C1. C2 et C3 peuvent être déphasés de telle manière qu'ils nelisent jamais la même donnée émise par C1. Quand les données portent des estampilles, nousobtenons que les données propagées de C1 à C4 via le chemin P1 portent des marquages de C1

de valeurs paires alors que celles propagées via P2 portent des valeurs impaires (ou l'inverse).Le composant C4 ne pourra alors jamais construire d'ensemble de données strictement cohérentcar il n'aura jamais à sa disposition des données avec le même marquage sur C1 sur ses deuxentrées. L'utilisation de �les d'attente ne changerait rien. Par contre, il su�t de tolérer un écartde 1 pour qu'à chaque pas, C4 construise un nouvel ensemble.

La thèse de N. Pontisso présente comme résultat intéressant la tolérance minimale nécessairepour garantir la vivacité de l'association sur un puits, connaissant uniquement les périodes etdélais de communication, mais sans information sur l'ordonnancement des pas des composants.

Fuseaux imbriqués. De part le critère de cohérence pour l'association des données, un puitsagit aussi comme un �ltre, en ne laissant passer qu'un sous-ensemble de ses données en entrée(celles qui forment un ensemble cohérent). Par ailleurs l'existence de plusieurs fuseaux imbriquéspeut rendre impossible la réalisation de la cohérence : la construction d'un ensemble cohérent pourl'un des fuseaux conduisant à un ensemble incohérent sur l'autre et inversement. N. Pontissoa donné une classi�cation des types d'imbrication possible pour deux fuseaux, qui, selon lescas, n'induisent pas de nouvelles contraintes, ou au contraire peuvent interdire la constructiond'ensembles cohérents.

5.9 Conclusion

Ce chapitre a développé une notion de cohérence peu traitée : la cohérence mutuelle d'unensemble de données. Cette notion apparaît usuellement dans le contexte des bases de données,où les transactions maintiennent la cohérence de la base dans sa globalité. L'originalité de notrecohérence provient de ce qu'elle est dé�nie vis-à-vis des dépendances introduites par les calculset les communications : un ensemble de valeurs n'est pas cohérent dans l'absolu, il est cohérentvis-à-vis d'un pas d'un composant. Cette cohérence a pu être aisément formalisée et un codagesimple et performant permet de la contrôler. Des résultats supplémentaires ont été présentés dansun contexte temps réel, où il a été montré comment borner les �les nécessaires à la réalisationde la cohérence.

Une autre originalité de notre approche a été de se situer dans un cadre général d'exécutionrépartie, sans contrainte sur le comportement des composants (déclenchement d'un calcul parexemple). Pour autant l'association cohérente est fortement lié à l'enchaînement des pas et à

86


la circulation de l'information dans le système. Une étude intéressante serait donc le lien avecl'ordonnancement des composants.

D'une part, on peut se demander si la connaissance plus précise de l'ordonnancement ne per-mettrait pas de limiter la quantité d'information nécessaire au codage et de réduire la taille des�les d'attente de délivrance des messages. Un premier cas extrême a été étudié, où tous les com-posants partagent une période commune, montrant que l'on pouvait alors se passer totalementde l'estampillage des messages. Entre ce cas et le cas où les composants ont des périodes indé-pendantes ainsi que des dates de déclenchement et des durées d'exécution variables (cas généralétudié), on peut imaginer que certains comportements réguliers peuvent simpli�er la gestion des�les ou réduire leur taille. Par exemple, nous savons que si la phase (décalage par rapport à lapériode) des pas d'exécution des composants est nulle, ce qui revient à dire que pour chaque pasde chaque composant, toutes les lectures ont lieu au début de la période, alors la longueur des�les peut être divisée par deux.

D'autre part, l'approche présentée véri�e qu'un ensemble de données reçues est cohérent etne délivre que de tels ensembles. Cette délivrance � subit � l'exécution mais ne l'in�ue pas. Unequestion intéressante est alors de savoir si on ne peut pas engendrer des informations pour l'or-donnanceur, permettant d'éliminer des exécutions pathologiques. Ainsi dans l'exemple présenté�gure 5.10, c'est la régularité de l'opposition des déclenchements des pas qui cause l'impossibi-lité de la cohérence stricte. Ce lien entre cohérence et ordonnanceur reste actuellement un sujetd'étude.

87

Chapitre 6

Flots de données à contraintes

temporelles

6.1 Introduction

Les travaux présentés dans ce chapitre découlent de la thèse de Tanguy Le Berre [LB10]que j'ai encadrée sous la direction de Gérard Padiou. Ces travaux ont donné lieu aux publicationssuivantes : [LB07, LBQP08, LBMPQ08, LBPQ09, LBMPQ09a, LBMPQ09b].

Les travaux menés avaient deux objectifs :

� étudier comment décrire formellement un système temps réel décrit par �ots de données ;� étudier les véri�cations formelles possibles.

Pour le premier point, nous avons utilisé la relation d'observation qui permet de lier deux�ots de données, l'un étant vu comme un passé partiel de l'autre. L'observation permet dedécrire l'architecture du système en termes de variables et de circulation de l'information entreces variables. À ces variables et aux �ots de données qui découlent de cette architecture, nousattachons des contraintes temporelles, assimilables à de la latence, du retard, etc. L'observationest en fait un opérateur de cohérence entre deux variables, et les contraintes temporelles exprimentla qualité de cette cohérence.

Pour le deuxième point, le problème du régime initial a tout d'abord été mis en évidence :toutes les contraintes temporelles ne peuvent pas nécessairement être respectées dans les étatsinitiaux et les premières transitions du système. En considérant de manière globale le régimeinitial comme une exception au bon comportement, il a été montré sous quelles conditions onpouvait garantir la sortie du régime initial et au bout de combien de temps au pire le systèmel'avait quitté. La question de la satis�abilité d'une spéci�cation, exprimée comme un ensembled'observations augmentées de contraintes temporelles, a ensuite été étudiée, sous la forme d'uneéquivalence avec un système de transitions non borné, puis d'une équivalence avec un système�ni.

Dans cette présentation sommaire, nous ne donnons que le minimum nécessaire pour com-prendre les travaux et leur intérêt. Les preuves et les notions manquantes sont détaillées dans[Cha97, CFM+99b] pour l'observation et dans [LB10] pour les aspects temps réel. Le plan duchapitre est le suivant : nous donnons tout d'abord les outils nécessaires à la spéci�cation del'architecture du système (observation, chemin de propagation. . . ) ; puis nous introduisons lescontraintes temporelles qui permettent de décrire les caractéristiques temps réel de la spéci�ca-

89

6.2 - Outils pour la spéci�cation

0 0 0 5 5 2 2 2 1 3 3 6 6 6 6 7 4 4 8

0 0 0 5 2 3 3 6 6 4 40 5 5 2 3 3 6 4

e

`e

Figure 6.1 � Relation d'observation

tion ; une section présente les travaux menés autour de la véri�cation (régime initial et régimenominal) ; en�n un petit exemple vient illustrer l'ensemble.

6.2 Outils pour la spéci�cation

6.2.1 Système de transitions

En représentation symbolique, un système de transitions S est un triplet (V ,→,Σ0), où V estun ensemble �ni de variables, un état est une valuation des variables, → une relation entre deuxétats, Σ0 un ensemble d'états distingués dits états initiaux (généralement décrit par un prédicatportant sur les variables). Dans la suite, on ne considère que des systèmes avec bégaiementc'est-à-dire tel que → est ré�exive (∀σi : σi → σi).

Une exécution est une séquence in�nie σ = σO → σ1 → . . . σi → σi+1 . . . où σ0 ∈ Σ0 et∀i : (σi , σi+1) ∈ →.

La sémantique JSKST d'un système de transitions est l'ensemble des exécutions de ce système.Un prédicat temporel est un prédicat sur les exécutions. On note σ |= P si la propriété P

est véri�ée par l'exécution σ, et S |= P si la propriété P est véri�ée par toutes les exécutionsdu système S . En général, un prédicat temporel est décrit en logique temporelle linéaire (nondétaillée ici). Une expression est une formule sur les variables ; on note e.σi la valeur d'uneexpression e dans l'état σi , et e.σ la séquence de valeurs de e pendant l'exécution σ.

6.2.2 La relation d'observation

6.2.2.1 Dé�nition de l'observation

Informellement, ‘e ≺· e si ‘e et e sont deux expressions et ‘e prend ses valeurs dans le passéde e, en respectant l'ordre chronologique, mais sans nécessairement prendre toutes les valeursde e (cf �gure 6.1). L'expression e est la source et ‘e est l'image. L'observation sert à modéliserun retard dû aussi bien à une communication qu'à un calcul. L'observation a été étudiée dans[Cha97, CFM+99b] et nous n'en donnons ici que les propriétés essentielles pour la suite.

Dé�nition en termes d'états Il s'agit d'une dé�nition naturelle qui lie l'état courant del'image avec un état du passé, en respectant les contraintes de chronologie et de vivacité qui sontobtenues via la notion d'horloge.

Dé�nition 23 (Horloge) Soit un ensemble D muni d'un ordre total ≤. Une horloge c est unefonction de [D → D] telle que :

� elle ne dépasse pas son argument : ∀t ∈ D : c(t) ≤ t

90

Chapitre 6 - Flots de données à contraintes temporelles

� elle est monotone et croissante : ∀t1, t2 ∈ D : t1 < t2 ⇒ c(t1) ≤ c(t2)� elle est vivace : ∀t1 ∈ D : ∃t2 ∈ D : c(t2) 6= c(t1)

On note C(D) l'ensemble des horloges dé�nies sur D.

Dé�nition 24 (Observation) Soit deux expressions ‘e et e et une exécution σ. L'expression ‘eest une observation de e si :

σ |= ‘e ≺· e ∆= ∃c ∈ C(N) : ∀i ∈ N : ‘e.σi = e.σc(i)

On note aussi S |= ‘e ≺· e (ou simplement ‘e ≺· e si le système est évident par le contexte) si∀σ ∈ JSKST : σ |= ‘e ≺· e.

Dé�nition purement logique Il est possible de donner une dé�nition purement logique del'observation pour un système S (implicite dans la suite de ce paragraphe). Celle-ci se révèlenéanmoins moins pratique que la précédente, en particulier parce qu'on perd la dé�nition vis-à-vis d'une exécution et la � visibilité � des horloges, qui nous seront utiles quand nous spéci�eronsdes contraintes temporelles que l'observation devra véri�er.

Dé�nition 25 (histoire) Une variable h est une histoire de e si h est une séquence croissantedont la tête est toujours la valeur courante de e :

histoire(h, e)∆= 2[tail(h ′) = h ∧ head(h) = e]〈h,e〉

Note : la notation TLA [a]b signi�e a ∨ b′ = b (bégaiement possible sur les variables de b).

Dé�nition 26 (pré�xe avec perte) i est une séquence extraite de s et ancrée sur la queue (lavaleur initiale) :

i v∗ s ∆= ∨ s 6= 〈〉 ∧ i = s∨ head(i) = head(s) ∧ tail(i) v∗ tail(s)∨ i v∗ tail(s)

Dé�nition 27 (Observation)

‘e ≺· e ∆= ∧ ∃∃∃∃∃∃ h, ‘h : histoire(h, e) ∧ histoire(‘h, ‘e) ∧2(‘h v∗ h)∧ ∀v : 32(‘e = v)⇒ 23(e = v)

L'opérateur ∃∃∃∃∃∃ est un quanti�cateur temporel existentiel, qui permet de masquer les variablesd'histoire h et ‘h. Le premier conjugué est la sûreté (‘e prend des valeurs dans le passé de e) etle deuxième est la vivacité (ou ‘e n'est jamais stable, ou ‘e est �nalement stable et sa valeur estprise in�niment souvent par e). On peut observer que la formule de la vivacité est analogue àcelle de l'équité faible, ce qui traduit bien que l'observation ne doit pas rester constante si ellepeut in�niment souvent changer.

6.2.2.2 Sémantique

Dé�nition 28 (Sémantique opérationnelle) La sémantique JObsKO d'un ensemble d'obser-vations est dé�nie par :

J∅KO∆= Σ

JObs ∪ {a ≺· b}KO∆= JObsKO ∩ {σ|σ |= a ≺· b}

où Σ est l'ensemble de toutes les exécutions in�nies.La sémantique d'un système de transitions S étendu par un ensemble de relations d'observa-

tion Obs est :J(S ,Obs)K ∆

= JSKST ∩ JObsKO

91


La relation d'observation n'introduit pas de nouveaux états dans une exécution mais lacontraint. La sémantique d'un système étendu est donc la sémantique du système de transitionscontrainte par les relations d'observations. En pratique, le système de transitions n'imposeraaucune contrainte sur l'évolution des variables images (partie gauche d'une observation), dontl'évolution sera exclusivement dé�nie par les observations.

6.2.2.3 L'observation comme élément de modélisation

L'observation est un outil de modélisation versatile. Naturellement, on peut voir l'observationcomme une abstraction de la communication. En écrivant ‘x ≺· x , nous décrivons un lien entre‘x et x . L'ensemble des relations d'observation forme alors la topologie d'interaction entre lescomposants du système. Par contre, l'observation est un opérateur abstrait qui ne spéci�e pas lemoyen de l'interaction : ce peut aussi bien être de la mémoire partagée (et en particulier, l'iden-tité est une relation d'observation) que des messages asynchrones et/ou non �ables. En outre,par rapport à un modèle de communication à base de messages, l'observation ne conserve quel'aspect communication en éliminant l'aspect synchronisation généralement associé aux opéra-teurs de manipulation de messages (réception bloquante par exemple) et l'aspect consommationdes messages (un message n'est délivré qu'une fois, contrairement à une valeur dans une casemémoire qui est lisible in�niment souvent tant qu'elle ne change pas).

Par ailleurs, l'observation peut modéliser un calcul prenant du temps. Dans un systèmede transitions, une transition est instantanée et x ′ = f (. . .) modélise que le calcul de f (. . .)s'e�ectue en une transition et que le résultat est disponible dans x dans l'état suivant. Enécrivant ‘x ≺· f (. . .), nous modélisons le fait que le calcul prend un temps arbitraire, indé�ni, etque, un jour, le résultat sera disponible dans ‘x . Ici aussi, les contraintes temporelles que nousintroduisons ultérieurement o�rent une modélisation plus précise de cette idée de temps de calcul,sans pour autant basculer dans une description détaillée et explicite du calcul lui-même.

Plus généralement, l'observation est un opérateur de cohérence, réalisant une réplication encohérence faible : dans ‘x ≺· x , on peut considérer que l'image ‘x est un réplica de x . Le peu decontrainte sur la réplication (si ce n'est de ne pas anticiper les valeurs futures et de respecter lachronologie) modélise une cohérence arbitraire, allant de l'identité au retard croissant, en passantpar des retards bornés. Cette cohérence faible est assimilable à la slow consistency (cf page 14)dans le domaine de la cohérence mémoire. La suite de nos travaux a justement consisté à �ltrerles valeurs observées et à contraindre temporellement ce retard (voir section 6.3.2).

6.2.2.4 Architecture d'un système

Dans la suite, nous restreignons les systèmes considérés : les variables contraintes par uneobservation ne peuvent pas être aussi contraintes par la relation de transitions du système sup-port, et nous imposons que la partie gauche d'une observation soit une variable et non pas uneexpression quelconque (par contre, il n'y a aucune contrainte sur la partie droite).

Dé�nition 29 (Système bien formé) Un système (S ,Obs) est bien formé si :� S est un système de transitions ;� Obs est un ensemble d'observations dont les expressions sont écrites avec les variables de S ;� toutes les observations sont de la forme v ≺· f (X ) où v est une variable, X un vecteur devariables et f une fonction quelconque ;

� une variable ne peut être image que d'au plus une observation ;� si une variable v est image d'une observation, alors v est constant dans JSKST .

On note Var(Obs) l'ensemble des variables utilisées pour dé�nir les relations d'observationde Obs, que ce soit côté source ou côté image.

92


Figure 6.2 � Multiplicité des chemins entre deux variables

6.2.2.5 Chemins de propagation

Proposition 1 Un ensemble d'observations Obs forme un graphe orienté :� les variables Var(Obs) sont les n÷uds du graphe ;� un arc x → y d'un n÷ud x vers un n÷ud y existe ssi :∃X : x ∈ X ∧ ∃f : (y ≺· f (X )) ∈ Obs

Dans un tel graphe, deux variables peuvent être liées par plusieurs chemins. Considérons parexemple les observations suivantes représentées �gure 6.2 :

‘x ≺· x , “x ≺· x , y1≺· f1(‘x ), y2≺· f2(“x ), ‘y1≺· y1, ‘y2≺· y2, z ≺· g(‘y1, ‘y2)

Ces observations peuvent représenter des communications de x à deux sites di�érents utilisantces valeurs pour calculer les valeurs de y1 et y2. Ces valeurs sont elles-mêmes communiquées àun autre site et utilisées pour calculer z . Il y a donc deux chemins liant x à z . Le décalage lelong de ces deux chemins n'est pas nécessairement le même, par exemple si les propriétés descommunications mises en ÷uvre di�èrent.

Dé�nition 30 (Chemin de propagation) Étant donné un ensemble de relations d'observa-tion Obs, un chemin de propagation est une séquence de variables [x0, x1, . . . , xn ] de Var(Obs)telle que :

∀i ∈ 0..n − 1,∃Xi : xi ∈ Xi ∧ ∃f : (xi+1≺· f (Xi)) ∈ Obs

Ou de manière équivalente, pour chaque i ∈ 0..n − 1, il existe un arc de xi vers xi+1 dans legraphe dé�ni par Obs. x0 est la source du chemin et xn est l'image du chemin.

6.2.2.6 Horloges équivalentes

Pour une exécution et une observation donnée, il existe en général plusieurs horloges équi-valentes, c'est-à-dire qui permettent d'obtenir la même séquence de valeurs de l'image pour uneséquence donnée de la source. Sur la �gure 6.3, la valeur de l'image en σi est celle de la sourceen σc(i), mais toute autre valeur de l'horloge entre l'apparition de la valeur blanche et le numérode l'état courant i aurait donné le même résultat.

Dé�nition 31 (Horloges d'une observation) Soit une observation a ≺· b. Alors pour uneexécution σ, C(a ≺· b).σ est l'ensemble des horloges équivalentes :

C(a ≺· b).σ∆= {c ∈ C(N) | ∀i ∈ N : a.σi = b.σc(i)}

93


x

yσi

σc(i)

Figure 6.3 � Équivalence des horloges

Dé�nition 32 (Horloges d'un chemin) Soit un chemin de propagation [x0, x1, . . . , xn ] dé�nisur un ensemble d'observations Obs, soit σ une exécution. L'ensemble des horloges qui caracté-risent ce chemin pour cette exécution est noté C([x0, x1, . . . , xn ]) et est dé�ni par :

C([x0, x1, . . . , xn ]).σ∆=c ∈ C(N)

∣∣∣∣∣∣∃c1, c2, . . . , cn ∈ C(N) : ∀k ∈ [1..n] : ∃fk ,Xk−1 :

(xk ≺· fk (Xk−1)) ∈ Obs ∧ xk−1 ∈ Xk−1 ∧ ck ∈ C(xk ≺· fk (Xk−1)).σ∧ c = c1 ◦ c2 ◦ . . . ◦ cn

6.2.3 Le temps

A�n d'intégrer le temps dans les spéci�cations de systèmes, nous introduisons une référenceexplicite au temps. Comme Abadi-Lamport [AL94], le temps est une variable T croissante etnon bornée, prenant valeur dans un ensemble in�ni muni d'une relation d'ordre total. Notonsque comme l'on travaille sur des exécutions du système comme séquences d'états, cela discrétisenécessairement les valeurs de T auxquelles on s'intéresse. En pratique l'ensemble des valeursde T utilisé pour la validation est N. La question du choix entre temps dense et temps discretest un sujet récurrent, discuté par exemple dans [FMMR10, LSV96, Mag07].

Dé�nition 33 (Variable temps) L'évolution du temps est dé�nie par une variable T telle quepour toute exécution σ :

� T est entière : ∀i ∈ N : T .σi ∈ N� T est croissante : ∀i ∈ N : T .σi ≤ T .σi+1

� T est initialisée à 0 : T .σ0 = 0� T est non bornée : ∀n ∈ N,∃i ∈ N : T .σi ≥ n

L'unité de temps n'est pas dé�nie a priori. Cependant, nous souhaitons que deux états dis-tincts ne puissent pas être datés identiquement : l'échelle de temps utilisée doit être su�sammentprécise pour distinguer tous les états du système. Cela signi�e que chaque pas de calcul et doncmodi�cation de l'état du système implique l'écoulement du temps et une évolution de T . Infor-mellement, la variable T bouge plus souvent que toute autre variable.

Dé�nition 34 (Séparabilité) Une exécution σ est dite séparable si l'identité du temps dansdeux états implique l'identité de ces états :

σ est séparable∆= ∀i , j : T .σi = T .σj ⇒ σi = σj

Comme le temps est croissant, nous pouvons utiliser une dé�nition équivalente en termesd'états consécutifs : ∀i : T .σi = T .σi+1 ⇒ σi = σi+1. Par la suite, nous ne considérons que desexécutions séparables ce qui permet de dater chaque transition du système.

94


x.σ

T.σ1 ...

x.σ1

T.σi ...T.σj ...

T.σk

x.σi

x.σj

x.σk

T.σj-1

T.σk-1T.σi-1

Figure 6.4 � Pro�l temporel x d'une variable x

6.2.4 Pro�l temporel d'une variable

Le pro�l temporel d'une variable décrit les instants où elle change de valeur.

Dé�nition 35 (Pro�l temporel) Soit une exécution séparée σ et une variable x . Les valeursdu pro�l temporel x de x sont dé�nies par :

∀i ∈ N : x .σi , T .σmin{j |∀k ∈ [j ..i]: x .σi=x .σk}

Dans chaque état, la valeur du pro�l temporel est dé�nie par le précédent instant de change-ment de valeur de x , c'est-à-dire par la valeur de la variable T dans l'état où la valeur actuelleest apparue et a, depuis, été gardée en continu. La valeur de x donne le plus récent instant où lavaleur de x a été modi�ée. Par dé�nition, pour toute variable x , x est initialisée à 0.

Un exemple de l'évolution d'une telle variable x est présenté �gure 6.4. Les valeurs de x sontdonnées selon les valeurs successives de T . Lorsqu'il y a une mise à jour et un changement dela valeur de x (par exemple à l'instant T .σi), la valeur de x est égale à celle de T . Dans lesautres états (par exemple jusqu'à T .σj−1), la valeur de x est inchangée et est identique à celle àl'instant précédent.

On montre facilement que l'égalité des pro�ls implique l'égalité des valeurs. L'inverse estévidemment faux, par exemple si une variable alterne entre deux valeurs.

Proposition 2 Soit une variable x et une exécution séparée σ alors on a :

∀i , j ∈ N : x .σi = x .σj ⇒ x .σi = x .σj

95

6.3 - Spéci�cation temporelle par l'observation

Dé�nition 36 (Durée de vie) Soit une exécution séparée σ et une variable x . La durée devie dx de la variable x est dé�nie par :

∀i ∈ N : dx .σi ,{

+∞ si ∀k ≥ i : x .σk = x .σiT .σmin{j |j≥i ∧ x .σi 6=x .σj} − x .σi sinon

Informellement, la durée de vie est la durée pendant laquelle une valeur est conservée. Plusexactement, la durée de vie de la valeur courante est l'écart entre sa date d'apparition et sa datede disparition, ou l'in�ni si elle est dé�nitivement stable.

6.2.5 Dichotomie état-transition

La dichotomie entre état (valeur) et transition (action) est une di�culté courante quand ils'agit de spéci�er un énoncé ou de décrire une solution. Par exemple un prédicat de logiquetemporelle s'énonce sur des états mais la possibilité de parler à la fois de l'état courant et del'état suivant (opérateur © en LTL ou ′ en TLA) permet aussi d'exprimer des propriétés sur lestransitions.

L'observation est un opérateur qui porte exclusivement sur les valeurs. Le pro�l temporelpermet de capturer les changements de valeurs et nous sert pour faire le lien entre valeurs ettransitions. Une approche plus précise nécessite d'introduire une notion d'occurrence [LB10,p. 53-58] qui permet de rendre visible une transition qui ne change pas les valeurs, ce qui semblenécessaire quand on introduit le temps réel. Par exemple si l'on considère la fonction f (x ) = b x2 c(partie entière de x

2 ) et un �ux de valeurs entières, deux valeurs distinctes de l'entrée peuventdonner la même valeur en sortie. Tant que l'on raisonne uniquement sur des propriétés de logiquetemporelle (invariant, leads-to. . . ), cela n'a pas d'importance. Si l'on souhaite pouvoir borner unepropriété comme le temps de réponse (le temps de calcul ici), il est nécessaire de distinguer lessorties consécutives, même si elles ont la même valeur. Il en est de même si l'on veut savoir si unedécision (une sortie) a été prise en fonction d'une valeur d'entrée récente ou pas : la validité dela sortie ne dépend pas que de la valeur de l'entrée, mais aussi des événements de mise à jour decette valeur, même si elle ne change pas de valeur. Pour simpli�er l'exposé, nous avons omis cettenotion d'occurrence qui alourdit tous les énoncés. Informellement, il su�t de remplacer partoutla valeur d'une expression e.σi par un couple 〈e.σi , occe .σi〉, où occe est une variable croissantechangeant au moins à chaque changement de valeur de e, permettant ainsi de distinguer plusieursoccurrences de la même valeur de e.

Dans la suite, les contraintes temporelles que nous introduisons portent pour certaines surles états (par exemple décalage/shift), pour d'autres sur les transitions (par exemple lag), etcertaines en�n réalisent le lien état/transition (par exemple latence).

6.3 Spéci�cation temporelle par l'observation

Les variables et les relations d'observation nous donnent l'architecture d'un système. Nousallons maintenant montrer comment y ajouter les contraintes temporelles. Ces contraintes portentsur deux entités : les variables elles-mêmes, et les chemins de propagation qui les relient. A priori,mais rien ne l'oblige, les contraintes temporelles sur les variables ne sont appliquées qu'à desvariables exclusivement sources, ce qu'on peut considérer comme les entrées externes du système.Les contraintes temporelles sur les chemins de propagation sont là pour décrire le comportementinterne du système.

96


x

Figure 6.5 � Sporadicité

6.3.1 Comportement temporel d'une variable

Les prédicats temporels sur les variables ont volontairement été limités à l'essentiel, justece qui était nécessaire pour décrire des variables changeant � assez souvent �. En e�et, aussicontraints que soient les chemins, aucune analyse du système ne serait faisable si les sourcesavaient un comportement totalement indé�ni.

6.3.1.1 Sporadicité

La durée entre deux mises à jour est au minimum de δ et au maximum de ∆ (cf �gure 6.5).La borne δ vaut 0 si le temps minimum entre deux mises à jour peut être nul, et ∆ vaut +∞ s'iln'y a pas de maximum.

Dé�nition 37 (Sporadicité) Soit une exécution séparée σ et une variable x . Le comportementde x lors de cette exécution est sporadique de paramètres δ,∆, où δ ∈ N et ∆ ∈ N ∪ {+∞}, si :

σ |= x {Sporadic(δ,∆)} ∆= ∀i ∈ N : dx .σi ∈ [δ..∆]

6.3.1.2 Périodicité

Une variable x est périodique si ses instants de mise à jour sont situés autour des instantsn ∗P à la gigue près. Il est inutile d'introduire une phase qui ne concerne que le premier instant,ce qui est traité plus généralement par la problématique du régime initial (section 6.4.1).

Dé�nition 38 (Périodicité) Soit une exécution séparée σ et une variable x . Le comportementde x lors de cette exécution est périodique de période P et de gigue J si on a :

σ |= x {Periodic(P , J )} ∆=

∃δ = 〈δi |i ∈ N∗ ∧ δi ∈ [−J ..J ] ∧ δ0 = 0〉 : {x .σi |i ∈ N} = {n ∗ P + δn |n ∈ N}

6.3.2 Comportement temporel d'un chemin de propagation

Les prédicats temporels d'un chemin de propagation contraignent celui-ci à évoluer dans uncadre temporel dé�ni. Plus précisément, ces prédicats lient les évolutions de l'image d'un cheminà la source. Nous introduisons six prédicats qui permettent de décrire di�érentes contraintes, quinous ont semblé su�samment expressives sans chercher à l'exhaustivité.

Les prédicats sont dé�nis grâce au décalage logique introduit par un chemin et aux di�érentesvariables temporelles introduites précédemment, notamment le pro�l temporel de la source et del'image. Ils sont construits en donnant des bornes sur la di�érence entre deux instants qui sont,selon le prédicat, le pro�l temporel de la source, celui de l'image, la variable T à l'instant présentet la variable T à l'instant désigné par l'horloge du chemin.

Informellement les six prédicats sont :

97


� lag 1 : borne l'écart entre l'instant d'apparition de la valeur actuelle de l'image et l'instantd'apparition de cette valeur à la source ;

� latence (latency) : borne l'écart entre l'instant actuel et l'instant d'apparition de la valeurde la source utilisée pour dé�nir la valeur actuelle de l'image ;

� décalage (shift) : borne l'écart entre l'instant actuel et l'instant observé ;� fraîcheur (freshness) : restreint les instants observés aux instants où une valeur de la sourceest adéquatement fraîche (assez mais pas trop récemment apparue) ;

� pérennité (�tness) : restreint les instants observés aux instants où une valeur de la sourceest adéquatement pérenne (proximité d'une prochaine mise à jour) ;

� stabilité (stability) : �ltre les valeurs de la source selon leur durée de conservation, enéliminant les valeurs conservées un temps trop faible ou trop important.

6.3.2.1 Forme générale

Dé�nition 39 (Propriétés temps réel d'un chemin) Un chemin de propagation P est pa-ramétré par un ensemble de prédicats {Predicate1(δ1,∆1), . . . ,Predicaten(δn ,∆n)} si :

σ |= P {Predicate1(δ1,∆1), . . . ,Predicaten(δn ,∆n)} ∆=

∃c ∈ C(P).σ, ∀i ∈ N :

Predicate1(P , c, δ1,∆1).σi∧ . . . ∧

Predicaten(P , c, δn ,∆n).σi

où

∀i ∈ [1..n] : Predicatei ∈ {Lag ,Latency ,Shift ,Freshness,Fitness,Stability}

6.3.2.2 Les prédicats temporels

La dé�nition de chacun des prédicats est illustrée par une �gure représentant un chemin depropagation d'une variable source x vers une variable image y . Le temps s'écoule de gauche àdroite, une ligne représente l'évolution des valeurs prises par une variable au cours du tempset chaque zone de couleur correspond à une valeur de cette variable. Si dans un état la valeurde y est représentée de couleur blanche, cela signi�e qu'elle est construite à partir de la valeurde la source représentée de la même couleur blanche. La �èche noire représente l'horloge del'observation.

Dé�nition 40 (Lag) Pour une exécution σ, le prédicat de lag pour un état σi et pour un cheminP d'une variable x vers une variable y est dé�ni par :

Lag(P , c, δ,∆).σi∆= δ ≤ y .σi − x .σc(i) < ∆

où δ ∈ N et ∆ ∈ N ∪ {+∞} et δ < ∆.

Le lag borne l'écart entre l'instant d'apparition de la valeur actuelle de l'image et l'instantd'apparition de cette valeur à la source. Ce prédicat est illustré �gure 6.6. La �èche représente letemps écoulé entre le moment d'apparition d'une nouvelle valeur de x et le moment d'apparitiond'une nouvelle valeur de y issue de cette valeur. Il s'agit donc du temps écoulé pour que la miseà jour de x se répercute en une mise à jour de y . Le lag borne ce temps, les lignes pointilléesreprésentent les di�érentes pentes possibles et indiquent les instants où une mise à jour de y peutet doit se faire avec cette valeur de x .

1. Il s'agit du retard sur la mise à jour mais ce terme de retard portant à confusion, nous avons préféré ne pastraduire lag.

98


x

yδ Δ

Figure 6.6 � Le prédicat de lag

x

yδ Δ

Figure 6.7 � Le prédicat de latence

Dé�nition 41 (Latence) Pour une exécution σ, le prédicat de latence pour un état σi et pourun chemin P d'une variable x vers une variable y est dé�ni par :

Latency(P , c, δ,∆).σi∆= δ ≤ T .σi − x .σc(i) < ∆

où δ ∈ N et ∆ ∈ N ∪ {+∞}.

La latence borne le temps écoulé entre l'instant actuel et l'instant d'apparition de la valeurde x utilisée pour dé�nir la valeur actuelle de y . Le prédicat est illustré �gure 6.7. La �ècheindique le décalage entre l'instant de mise à jour de x et l'instant actuel. C'est donc le tempsécoulé depuis l'apparition de cette valeur de x dans le système. Pour la variable y , cette valeurde x peut uniquement être utilisée tant que cette pente est située entre les lignes pointillées.Par rapport à la latence, le lag indique uniquement quand une mise à jour avec une valeur estpossible mais ne dit pas combien de temps une valeur peut être conservée et quand devra avoirlieu la prochaine mise à jour.

Dé�nition 42 (Décalage) Pour une exécution σ, le prédicat de décalage pour un état σi etpour un chemin P d'une variable x vers une variable y est dé�ni par :

Shift(P , c, δ,∆).σi∆= δ ≤ T .σi − T .σc(i) < ∆

où δ ∈ N et ∆ ∈ N ∪ {+∞} et δ < ∆.

La di�érence i − c(i) représente le décalage logique introduit le long d'un chemin de propa-gation. Le prédicat de décalage borne le décalage temporel associé à ce décalage logique. Il s'agitd'une borne sur le temps écoulé entre l'instant actuel et l'instant observé, moment où x possédait

99


x

yδΔ

Figure 6.8 � Le prédicat de décalage

x

y

δΔ

Figure 6.9 � Le prédicat de fraîcheur

la valeur utilisée pour dé�nir la valeur actuelle de y . Cette propriété est indépendante des événe-ments de mise à jour et s'appuie directement sur le mécanisme des horloges des observations. Surla �gure 6.8, la �èche donne l'instant pointé par l'horloge du chemin de propagation. La pentede cette �èche doit être située entre les lignes pointillées représentant les bornes du prédicat dedécalage.

Dé�nition 43 (Fraîcheur) Pour une exécution σ, le prédicat de fraîcheur pour un état σi etpour un chemin P d'une variable x vers une variable y est dé�ni par :

Freshness(P , c, δ,∆).σi∆= δ ≤ T .σc(i) − x .σc(i) < ∆

où δ ∈ N et ∆ ∈ N ∪ {+∞} et δ < ∆.

Cette propriété restreint les instants que peut pointer l'horloge du chemin aux instants oùune valeur de x est su�samment fraîche (mais pas trop) en bornant le temps écoulé entrel'apparition de cette valeur et l'état pointé par l'horloge du chemin. Sur la �gure 6.9, et commepour la �gure 6.8, la �èche donne l'instant pointé par l'horloge du chemin de propagation. Onne s'intéresse pas à la pente de cette �èche mais aux propriétés de l'instant pointé.

Dé�nition 44 (Pérennité) Pour une exécution σ, le prédicat de pérennité pour un état σi etpour un chemin P d'une variable x vers une variable y est dé�ni par :

Fitness(P , c, δ,∆).σi∆= δ < x .σc(i) + dx .σc(i) − T .σc(i) ≤ ∆

où δ ∈ N et ∆ ∈ N ∪ {+∞} et δ < ∆.

100


x

y

δΔ

Figure 6.10 � Le prédicat de pérennité

x

y

δΔ

Figure 6.11 � Le prédicat de stabilité

Cette propriété est similaire à la fraîcheur et est illustrée de manière semblable �gure 6.10.La restriction des états visés par les horloges du chemin est dé�nie par rapport à la proximitéd'une prochaine mise à jour de x dans l'état pointé par l'horloge.

Dé�nition 45 (Stabilité) Pour une exécution σ, le prédicat de stabilité pour un état σi et pourun chemin P d'une variable x vers une variable y est dé�ni par :

Stability(P , c, δ,∆).σi∆= δ ≤ dx .σc(i) < ∆

où δ ∈ N et ∆ ∈ N ∪ {+∞} et δ < ∆.

On considère la durée pendant laquelle la valeur de x dure et on �ltre les valeurs de la sourceselon leur durée de conservation, en éliminant les valeurs conservées un temps trop faible ouau contraire conservées un temps trop important. Ce prédicat est illustré �gure 6.11. La �èchereprésente l'état observé, il correspond bien à une valeur dont la durée est comprise entre δ et ∆.

6.4 Véri�cation

6.4.1 Régime initial

Certaines propriétés sont impossibles à satisfaire dans les premiers états du système. Consi-dérons par exemple un chemin P entre deux variables x et y et la propriété suivante :

P {Shift(2, 5)}

101

6.4 - Véri�cation

Pour une exécution σ véri�ant cette propriété, il doit exister une horloge c du chemin P tel qu'entout état i :

2 ≤ T .σi − T .σc(i) < 5

Vu que ∀i : c(i) ≤ i , ce prédicat ne peut pas être satisfait tant que T n'est pas au moins égalà 2 : il est nécessairement non satis�able dans l'état initial et dans le(s) état(s) où T égale 1.Il en est ainsi pour les propriétés de latence, de lag, de fraîcheur ou de décalage qui ne sontjamais satis�ables en l'état initial et dans un pré�xe �ni dès lors qu'un minimum autre que 0 lescaractérise.

Un problème similaire existe pour les propriétés temporelles des variables (sporadicité etpériodicité). Par dé�nition le pro�l temporel d'une variable est nul initialement (x .σ0 = 0). Cecirevient à imposer une phase nulle aux propriétés. Par exemple si on a x {Sporadic(3, 5)}, il estimpossible de mettre à jour x une première fois aux dates 1 ou 2, avant de respecter le délai de3 à 5 imposé par la sporadicité.

6.4.1.1 Dé�nition du régime initial

Plutôt que d'ajouter un paramètre spéci�que à chacune des propriétés (par exemple la phasepour la périodicité, ou un délai de grâce pour la propriété Shift), une approche globale a étéconsidérée : on dé�nit le régime initial comme une exception pendant lequel aucune propriététemporelle n'a à être respectée. Nous donnons des bornes sur le temps de sortie du régime initialdé�nies en accord avec la sémantique des propriétés et nous avons montré que, sous certaineshypothèses, il était possible de déterminer ce temps maximal de sortie de ce régime initial.

Dé�nition 46 (Régime initial) Le régime initial des di�érents éléments d'un système est dé-�ni par :

� une variable x est dans le régime initial tant qu'elle n'a pas été mise à jour ;� un chemin P d'une variable x vers une variable y est dans le régime initial tant que l'imagey n'a pas été mise à jour avec une valeur sortie du régime initial de x ;

� un système est dans le régime initial tant qu'il existe une variable ou un chemin dans lerégime initial.

Les questions à résoudre sont d'une part l'existence d'un temps borné de sortie du régimeinitial, et d'autre part le calcul de ce temps.

6.4.1.2 Conditions su�santes à la sortie du régime initial

La sortie du régime initial n'est pas certaine. Par exemple si une variable non image d'obser-vations n'est aucunement contrainte, elle peut ne jamais changer. Les conditions portent sur lesentrées du système (variables non images d'une observation), sur les chemins de propagation eten�n sur la structure du graphe des observations.

Théorème 5 (Sortie du régime initial) Le système est assuré de sortir du régime initial siles conditions suivantes sont remplies :

1. Entrées du système : la durée avant la première mise à jour est bornée :� entrée sporadique avec une borne supérieure ;� ou entrée périodique.

2. Chemins de propagation : le temps de propagation est borné :� propriété de décalage (Shift) avec une borne supérieure ;� ou propriété de latence (Latency) avec une borne supérieure ;

3. Le graphe des observations est à entrées indépendantes.

102


x

z

y

(a) Graphe sans entrées indépendantes

x

z

y

t

(b) Graphe à entrées indépendantes

Figure 6.12 � Graphe sans/avec entrées indépendantes

Entrées du système Les variables non images d'une observation doivent être contraintes àprendre une valeur, sous peine de rester éternellement dans l'état et le régime initial. Il su�t deleur adjoindre une propriété de périodicité ou de sporadicité avec une borne supérieure.

Chemins de propagation Un chemin de propagation doit être contraint à propager les valeursjusqu'à son terme, sous peine d'empêcher certaines images de changer de valeur. Pour cela, ilfaut que chaque chemin de propagation soit contraint par un décalage (shift) ou une latence avecborne supérieure. La contrainte de latence peut être énoncée directement sur le chemin, ou surun sur-chemin contenant ce chemin, car elle s'impose alors à tous les sous-chemins.

Graphe à entrées indépendantes Considérons le site bouclé avec les trois observationsz ≺· y , y ≺· x , x ≺· z (�gure 6.12(a)). Le graphe correspondant ne présente aucun point d'entréeet un tel système ne peut jamais quitter le régime initial. Par contre si on remplace la premièreobservation par z ≺· f (y , t) (�gure 6.12(b)), ce système �nit par quitter le régime initial : t �nirapar le quitter s'il est sporadique ou périodique, z prendra alors une valeur (mais n'est pas encoredé�nitivement sorti du régime initial car toutes ses entrées ne le sont pas encore), d'où x quittele régime initial, suivi de y et en�n z est calculé avec toutes ses sources sorties du régime initial.Toutes les variables et tous les chemins sont alors sortis du régime initial, et le système aussi.

Dé�nition 47 (Graphe à entrées indépendantes) Soit un graphe orienté G = (S ,A). Cegraphe est à entrées indépendantes si :

∀s ∈ S ,∃s ′ ∈ S : s ′ →∗ s ∧ prec(s ′) = ∅

La notation →∗ indique la présence d'un chemin entre deux sommets. prec(s) est l'ensembledes prédécesseurs immédiats d'un sommet s, c'est-à-dire l'ensemble des sommets pour lesquels ilexiste un arc vers s.

Dans [LB10, p. 92�93], on trouve une dé�nition équivalente en termes de l'inexistence decomposantes fortement connexes terminales du graphe inversé.

6.4.1.3 Calcul du temps maximal de sortie

Dans [LB10, chap. 5], on trouve la manière de calculer le temps de sortie maximal. Informel-lement, cela consiste à partir du graphe des observations, à annoter les entrées avec les périodeset les bornes supérieures de sporadicité, et les arcs d'observations avec les bornes supérieuresdes latences et décalages, à enrichir le graphe avec les arcs déduits pour les sous-chemins, et àdéterminer en�n le plus long chemin dans ce graphe.

103

6.5 - Exemple

6.4.2 Véri�cation de la satis�abilité

La méthodologie de véri�cation est conduite en deux étapes : tout d'abord, la spéci�cation entermes d'observations et de contraintes temporelles sur les variables et les chemins de propagationest traduite en un système de transitions explicite, c'est-à-dire qu'une relation de transition estconstruite sous la forme d'une formule TLA+ ; ensuite, dans un soucis d'automatisation de lapreuve, il a été montré dans quels cas il est possible de se ramener à un modèle �ni équivalent.

6.4.2.1 Système de transitions équivalent

La di�culté des énoncés des contraintes temporelles sur les chemins d'observation est qu'ilsfont référence à des états arbitrairement loin dans le passé. À l'opposé, un système de transitionsse dé�nit par la relation entre deux états consécutifs. Le problème a été contourné en utilisantl'outil bien connu des variables histoires (ou variables d'historiques) qui enregistrent le passé. Àpartir de là, il a été possible de reformuler toutes les observations, les contraintes temporellesportant sur les variables et les contraintes temporelles portant sur les chemins en une conjonctionde prédicats portant sur deux états consécutifs, formant ainsi la relation de transition recherchée.

6.4.2.2 Système �ni équivalent

Sous des contraintes identiques à celles du régime initial (cf paragraphe 6.4.1.2), on peutmontrer qu'il su�t d'analyser le système sur un pré�xe �ni, équivalent modulo une durée bienchoisie aux exécutions in�nies. Intuitivement, si les entrées sont sporadiques ou périodiques et sitous les chemins sont bornés supérieurement, on retrouvera des états temporellement équivalents.Or le temps de sortie du régime initial revient déjà à un calcul de la borne supérieure des chemins.Par conséquent, on choisit comme intervalle d'analyse LS le premier entier :

� multiple commun des périodes des variables (pour celles qui sont périodiques) ;� strictement supérieur au temps de sortie du régime initial.

Alors, en prenant en compte le régime initial, il su�t d'analyser le système sur un pré�xe de lon-gueur égale à deux fois cet intervalle d'analyse LS . Les états ultérieurs sont équivalents modulo Lsà ceux ainsi étudiés.

6.5 Exemple

6.5.1 Régulateur de vitesse

On considère un régulateur de vitesse de voiture. Ce système contrôle la vitesse d'un véhiculea�n de la stabiliser à une valeur choisie par le conducteur. De manière simpli�ée, le système estconstitué de quatre composants :

� un capteur de la vitesse courante du véhicule ;� le micromoteur de commande des gaz ;� un calculateur ;� la commande du conducteur.La commande du conducteur est utilisée par celui-ci pour donner la vitesse de croisière du

véhicule. Le calculateur compare cette vitesse avec la vitesse courante mesurée. Il déduit de cettedi�érence la valeur à appliquer à la commande des gaz qui contrôle l'accélération du véhiculeet agit sur sa vitesse. Finalement, un bus de communication permet la communication entre lesdi�érents composants, le capteur de vitesse se trouvant par exemple sur une des roues du véhiculeet la commande des gaz au sein du moteur.

L'architecture du système est donnée �gure 6.13. Les variables sont :

104


Systèmede contrôle

Capteur de vitesse

Commandeconducteur

Commandede gaz

choix

vitesse

gaz

= bus de communication

`gaz

`vitesse

`choix

Figure 6.13 � Architecture du régulateur de vitesse

vitesse

choix `choix

`vitesse

gaz `gaz

Figure 6.14 � Graphe de propagation du régulateur de vitesse

� vitesse : la vitesse courante du véhicule ;� choix : le choix conducteur de la vitesse de croisière du véhicule ;� gaz : la valeur à appliquer à la commande des gaz ;� ‘vitesse, ‘choix , ‘gaz : les valeurs transmises par le bus de communication.

6.5.2 Spéci�cation de l'architecture

La spéci�cation correspondante est :� communications :

‘vitesse ≺· vitesse‘choix ≺· choix

‘gaz ≺· gaz

� calculgaz ≺· calc(‘vitesse, ‘choix )

Le graphe de propagation correspondant est donné �gure 6.14.

6.5.3 Spéci�cation des contraintes temporelles

Les contraintes temporelles suivantes s'appliquent :� la variable vitesse est soumise à un prédicat de sporadicité avec :� une borne inférieure donnant le temps minimum pour pouvoir calculer une valeur correctede cette valeur ;

� une borne supérieure pour que la valeur de cette vitesse soit mise à jour su�sammentsouvent pour rester cohérente avec l'évolution de la vitesse réelle du véhicule ;

105

6.5 - Exemple

� la variable choix est soumise à un prédicat de sporadicité avec une borne inférieure, repré-sentant le temps minimum entre deux modi�cations de la vitesse par le conducteur ;

� les chemins représentant une communication, c'est-à-dire les chemins [vitesse, ‘vitesse],[choix , ‘choix ] et [gaz , ‘gaz ], ont une propriété de lag avec une borne inférieure. Cette pro-priété modélise un temps de communication minimal : lorsque la source du chemin est miseà jour, il n'est pas possible que la nouvelle valeur soit disponible pour une mise à jour del'image avant qu'une durée au moins égale à cette borne ne se soit écoulée ;

� les chemins représentant un calcul, [‘vitesse, gaz ] et [‘choix , gaz ] , possèdent une propriétéde lag avec une borne inférieure. Cette propriété modélise le temps de calcul minimal,c'est-à-dire le temps minimal pour qu'une nouvelle valeur de l'image apparaisse suite à unenouvelle valeur d'une des sources ;

� le chemin [vitesse, ‘vitesse, gaz , ‘gaz ] possède une propriété de latence avec une borne supé-rieure. Une occurrence de vitesse est pertinente au moment de son apparition, moment oùelle re�ète la vitesse courante du véhicule. On veut limiter le temps écoulé entre l'apparitionde cette occurrence et les instants où elle est utilisée pour dé�nir la valeur de ‘gaz ;

� le chemin [choix , ‘choix , gaz , ‘gaz ] possède une propriété de décalage avec une borne su-périeure. Une valeur de choix est pertinente tant que le conducteur ne l'a pas modi�ée.La propriété de décalage permet de borner le temps entre les instants où cette valeur estconservée et les instants où elle est utilisée pour dé�nir l'accélération du véhicule.

On obtient alors la spéci�cation suivante :� comportement des variables

vitesse {Sporadic(δ1,∆1)}choix {Sporadic(δ2,+∞)}

� communications[vitesse, ‘vitesse] {Lag(δ3,+∞)}[choix , ‘choix ] {Lag(δ3,+∞)}

[gaz , ‘gaz ] {Lag(δ3,+∞)}� calculs

[‘vitesse, gaz ] {Lag(δ4,+∞)}[‘choix , gaz ] {Lag(δ4,+∞)}

� chemins de bout en bout

[vitesse, ‘vitesse, gaz , ‘gaz ] {Latency(0,∆5)}[choix , ‘choix , gaz , ‘gaz ] {Shift(0,∆6)}

6.5.4 Analyse

On peut montrer que cette spéci�cation peut ne jamais sortir du régime initial. En e�etle chemin [choix , ‘choix , gaz ] n'est contraint par aucun prédicat de décalage ou de latence, quece soit directement ou via un sur-chemin. De plus la variable choix n'est pas l'image d'uneobservation et n'est soumise à aucune contrainte de mise à jour (ni périodique, ni sporadiquesupérieurement). Informellement, cela signi�e que le temps d'intervention du conducteur étantnon borné, le système global ne peut garantir aucune contrainte temporelle. Il su�t en faitd'imposer une borne de sporadicité supérieure à choix pour résoudre le problème :

choix {Sporadic(δ2,∆2)}

On peut ensuite déduire que :

[choix , ‘choix , gaz , ‘gaz ] {Latency(0,∆2 + ∆6)}

106


comportement des variables vitesse {Sporadic(3, 3)}choix {Sporadic(1, 4)}

communications [vitesse, ‘vitesse] {Lag(1,+∞)}[choix , ‘choix ] {Lag(1,+∞)}

[gaz , ‘gaz ] {Lag(1,+∞)}calculs [‘vitesse, gaz ] {Lag(1,+∞)}

[‘choix , gaz ] {Lag(1,+∞)}chemins de bout en bout [vitesse, ‘vitesse, gaz , ‘gaz ] {Latency(0, 6)}

[choix , ‘choix , gaz , ‘gaz ] {Shift(0, 4)}

Table 6.1 � Spéci�cation satis�able

ce qui nous donne une propriété de latence pour un sur-chemin de [choix , ‘choix , gaz ]. Le grapheétant trivialement à entrées indépendantes, il est certain que le système quittera le régime initialen temps borné. Le calcul détaillé dans [LB10, p. 168�169] donne pour cette borne :

∆S = max(∆1 + ∆5, 2 ∗∆2 + ∆6)

Cette spéci�cation a été étudiée avec di�érentes valeurs pour les paramètres. Ainsi on a pupar exemple véri�er que la spéci�cation de la table 6.1 est satis�able avec une période d'analysede 12.

6.5.5 Commentaires

Cet exemple simple et d'autres plus élémentaires ont permis de montrer le bien fondé del'approche. Pour autant, plusieurs di�cultés prévisibles sont apparues.

Tout d'abord, après transformation de la spéci�cation initiale, nous obtenons un système detransition �ni. Pour être véri�é, ce système a été soumis à deux véri�cateurs de modèles : TLC(le véri�cateur de TLA+) [Lam03] et Spin [Hol03]. Il faut donc coder le système de transitiondans le langage d'entrée de ces outils. La principale di�culté réside dans les variables histoires.Dans le cas de TLC, le langage est TLA+, et il n'y a pas de di�culté car séquences, nuplets etfonctions font partie du langage. Dans le cas de Spin, le langage est Promela, plus élémentaireet le codage a demandé plus d'e�ort, utilisant les canaux de communication pour représentere�cacement les histoires. La correction du codage reste aussi une question.

Par ailleurs, la véri�cation de la faisabilité d'une spéci�cation se fait en cherchant à invaliderune propriété d'interblocage disant que le temps ne change plus. En e�et, s'il existe une exécutionoù le temps change in�niment souvent, cela signi�e qu'il existe une exécution in�nie qui respectela spéci�cation, et donc que celle-ci est faisable. Sans surprise, la véri�cation par model-checkingbrut atteint rapidement ses limites car le nombre d'états croît rapidement avec la longueur del'intervalle d'analyse. Par ailleurs, en cas de spéci�cation faisable, on obtient une trace invalidantl'interblocage, trace correspondant à une exécution valide. Par contre, en cas de spéci�cationinfaisable, on obtient que toutes les exécutions �nissent par se bloquer, sans aucun moyen desavoir quel(s) paramètre(s) de la spéci�cation est (sont) en cause. Il ne reste alors plus qu'àessayer empiriquement d'autres valeurs. . .

6.6 Conclusion

Cette étude a permis d'étudier la cohérence le long de chemins de propagation de l'infor-mation. L'observation modélise la transmission de l'information et la cohérence est exprimée

107

6.6 - Conclusion

vis-à-vis du temps. L'originalité de l'étude est de montrer qu'il existe plusieurs propriétés inté-ressantes pour spéci�er cette cohérence, outre les classiques fraîcheur et latence, car la cohérencepeut être dé�nie pour di�érents points du calcul et par rapport à di�érents événements : lesévénements de changement de valeur, les (non-)événements de conservation de valeur, la datecourante, la durée entre la date courante et le précédent (ou suivant) changement de valeur. . .

Cette étude est cependant loin d'être terminée et de nombreux sujets restent à étudier. Toutd'abord, la véri�cation est e�ectuée en traduisant la spéci�cation de haut niveau en systèmede transitions puis dans le langage d'entrée d'outils de véri�cation (TLA/TLC et Promela/Spindans notre cas). Cette traduction est actuellement intégralement manuelle, sans di�culté maislaborieuse et génératrice d'erreurs d'inattention. Il serait raisonnable de disposer d'un traduc-teur automatique pour cela. Par ailleurs, une véri�cation à base de SMT (Satis�ability ModuloTheories) a aussi été abordée : les propriétés de cohérence sont exprimées comme des contraintesdiagonales sur les pro�ls temporels des variables et la véri�cation est e�ectuée par un solveurSMT (dans notre cas, Yices [Yic]). Cette approche est balbutiante et les résultats encore di�-cilement exploitables, mais de nouveau une di�culté majeure est la traduction manuelle de laspéci�cation dans les dizaines de contraintes nécessaires à son expression.

Comme toujours lorsqu'une formule d'un formalisme est traduit dans un autre formalisme,le retour des erreurs détectées dans le second formalisme vers l'expression problématique dans lepremier formalisme est un problème di�cile mais indispensable si l'on veut que l'outil quitte lemonde des spécialistes des deux formalismes et de la chaîne de traduction. Les travaux autourde la traduction et véri�cation des DSL (Domain Speci�c Languages) butent sur un problèmeidentique (voir par exemple [DLV08]) et sont peut-être une piste à suivre.

Dans l'état actuel, nous savons véri�er la faisabilité d'une spéci�cation, c'est-à-dire l'existenced'exécutions (et donc d'une implantation) qui la respectent. Mais aucun travail n'a encore étémené sur la génération d'une telle implantation. Vu la manière dont est exprimée la spéci�ca-tion, on peut néanmoins penser que la synthèse de contrôleur [CE82, AAE04] est une réponseadéquate.

108

Chapitre 7

Conclusion et perspectives

Les travaux présentés dans ce mémoire tournent autour de la cohérence dans les systèmesrépartis. De tels systèmes se caractérisent par deux propriétés nuisibles à la cohérence : le pa-rallélisme et l'asynchronisme. Du fait du parallélisme, plusieurs activités peuvent manipuler unensemble commun de données, en détruisant la cohérence interne. Du fait de l'asynchronisme, laperception de l'évolution des données est di�érente selon les sites. Les travaux présentés luttentcontre ces propriétés : le chapitre 5 � Association cohérente de données � s'attaque au paral-lélisme des chemins asynchrones de circulation de l'information pour les resynchroniser sur lesdestinataires communs ; les chapitres 4 � Flux multimédias coordonnés � et 6 � Flots de donnéesà contraintes temporelles � luttent contre l'asynchronisme en introduisant du temps, temps lo-gique (causal) dans le chapitre 4, temps réel dans le chapitre 6. De manière générale, nous noussommes intéressés à des formes de cohérences spéci�ques intégrant plus de sémantique que la plu-part des travaux sur la cohérence. Ainsi que l'écrit Raynal 1, ces travaux ont nécessité d'identi�erla communication et la coordination (l'� accord �) nécessaires à la résolution de l'incohérence.

Par ailleurs, ces travaux ne sont pas purement descriptifs : l'approche est à la fois pratiqueet théorique. Les résultats présentés possèdent une composante appliquée réaliste, tout en s'ap-puyant sur une formalisation raisonnable permettant d'assurer le bien-fondé de l'approche. Selonles cas, cette partie formelle est le c÷ur même du sujet (chapitre 6), se partage à part égale avecla partie applicative (chapitre 5 et section 2.4.1), ou ne représente qu'un aspect plus modeste dusujet (chapitre 4).

Les conclusions des di�érents chapitres ont fait apparaître certaines limites et évolutionspossibles des travaux qui y étaient décrits. Cela forme naturellement des perspectives évidentes.Nous présentons deux autres directions où systèmes concurrents et répartis d'une part, méthodesformelles d'autre part, se rejoignent sur un intérêt commun.

Mémoire transactionnelle. Dans le monde des systèmes à mémoire partagée (machinesmulti-processeurs/multi-c÷urs ou bases de données centralisées), le problème de la cohérencea depuis longtemps été étudié, et di�érentes approches existent : verrous, transactions dans lesbases de données. . . Le concept de mémoire transactionnelle [HM93, ST95] vise à introduirela notion de transaction au niveau du langage de programmation. L'objectif est d'obtenir despropriétés similaires à l'exclusion mutuelle ou au verrouillage, tout en o�rant un meilleur pa-rallélisme, une programmation plus aisée et plus sûre, et une sémantique précise vis-à-vis des

1. [...] The main abstractions that one has to understand and master in order to be able to produce [distributed]software with guaranteed properties [...] are communication abstractions that allow the processes to communicateconsistently, and the consensus agreement abstractions that allows them to cooperate despite failures. [Ray10]

109

7.0 -

défaillances. Même s'ils sont controversés [MMTW10], les avantages d'utiliser la mémoire tran-sactionnelle sont les suivants : elle simpli�e le développement, car le programmeur n'a plus àidenti�er et analyser les sections critiques pour introduire le verrouillage adéquat assurant quel'état partagé reste cohérent ; la détection des con�its est à la charge de la mémoire transac-tionnelle et un faible surcoût est payé en absence de con�it, alors que l'utilisation de verrouspeut introduire de fausses dépendances ; l'interblocage et la famine sont des problèmes connuspour être di�ciles et il est sage de les laisser aux spécialistes. La mémoire transactionnelle peutêtre implantée intégralement en matériel (proposition d'origine d'Herlihy et Moss), purement enlogiciel (de nombreux exemples, dont [HMPJH05, HMPJH08]), ou en hybride, où l'implantationmatérielle bascule en logicielle quand les contraintes matérielles sont dépassées [KCH+06].

Les systèmes embarqués sont un domaine inévitable pour un chercheur toulousain. Les interac-tions entre temps réel et transactions ont été étudiées dans le cadre des données à pro�l temporelet de l'ordonnancement de transactions périodiques [SL95, JXR06], mais ces travaux concernentl'univers des bases de données. La possibilité de mettre en ÷uvre la mémoire transactionnellepour des systèmes embarqués temps réel commence tout juste à être étudiée [MKA09, SBV10].Les implantations actuelles de mémoires transactionnelles forcent des transactions à abandon-ner en cas de con�its ou d'interblocage. Une telle approche semble inutilisable dans un systèmecritique, où l'abandon d'un code essentiel est inacceptable. Pour l'interblocage, on connaît destechniques de prévention (plutôt que la détection suivie d'une correction par abandon) qui pour-raient o�rir des pistes intéressantes. Pour la gestion des con�its, la connaissance assez précise destransactions et des priorités des processus (comme c'est généralement le cas dans les systèmescritiques) doit pouvoir permettre de hiérarchiser et de plani�er le déclenchement des transac-tions. En�n le di�cile problème du livelock conduisant à la famine est pratiquement toujoursignoré dans les mémoires transactionnelles, alors qu'il s'agit d'une question importante dans lessystèmes périodiques.

En�n, l'évolution des architectures multi-core (à mémoire commune) vers des architecturesmany-core (analogue à une grappe à mémoire répartie ou hiérarchisée) soulève la question de lamémoire transactionnelle virtuelle [RHL05], tout comme on a cherché à développer des mémoiresvirtuelles dans les systèmes répartis.

Algorithmique non bloquante Un autre sujet amusant concerne l'algorithmique non blo-quante (wait-free 2). Il s'agit d'algorithmes de synchronisation et de partage de données danslesquels un processus donné n'est jamais empêché de progresser, quelle que soit la progressiondes autres processus [Her91]. La vitesse de progression d'un processus donné est alors indépen-dante des autres processus. Ces algorithmes résolvent des problèmes de synchronisation et decoordination usuellement résolus avec des verrous (verrous d'exclusion mutuelle, ou verrous lec-teurs/rédacteurs) mais l'on sait que la panne d'un processus (par exemple l'arrêt pur et simple)possédant des verrous bloque dé�nitivement la progression des autres processus, sauf à adjoindrede complexes mécanismes de reprise sur défaillance. Les algorithmes non bloquants s'appuientsur l'existence d'instructions processeurs aux propriétés bien dé�nies (par exemple, les registres,cases mémoire à lecture et écriture atomiques y compris en multiprocesseurs, ou des opérationsatomiques de lecture et modi�cation de type test-and-set, compare-and-set . . . ). Leur écritureet leur compréhension sont délicates, pour ne pas dire obscures, et les preuves de correction,

2. Trois locutions sont couramment utilisées pour désigner trois concepts proches : non-blocking, wait-free, lock-free, avec un usage �uctuant selon les auteurs et les époques. En général, lock-free est l'absence d'interblocage, c'est-à-dire qu'une sous-partie non défaillante du système continue à progresser malgré les arrêts d'une autre partie ;wait-free est l'absence de famine, c'est-à-dire que toute partie non défaillante du système continue à progressermalgré les arrêts d'une partie défaillante ; non-blocking désigne soit indi�érement l'une et l'autre propriété, soituniquement la première. L'inversion de priorité est parfois aussi mixée à ces dé�nitions.

110

Chapitre 7 - Conclusion et perspectives

décrites manuellement en pseudo langage mathématique, laissent souvent à désirer, ou tout aumoins, ne parviennent pas à convaincre vraiment. En fait, ces algorithmes exhibent un nombreconsidérable d'états accessibles, et pour chaque état, de multiples transitions possibles, alors queles algorithmes auxquels l'informaticien est habituellement confronté sont largement séquentielsavec quelques rares branchements. À notre sens, ces algorithmes nécessitent impérativement unepreuve formelle. Nous avons e�ectué des essais de modélisation en PlusCal [Lam09], langage algo-rithmique abstrait se traduisant en TLA+, et nous avons observé l'explosion du nombre d'états.Ainsi, le splitter (annexe C.1), procédure linéaire dont le chemin le plus long ne contient quedeux tests et trois a�ectations, présente 13 475 976 états distincts quand elle est exécutée concur-remment par 6 processus. Quant à la liste chaînée non bloquante [MS96], exemple d'école pourintroduire la programmation non bloquante, il est di�cile de la véri�er par model-checking pourplus de 4 processus et une �le de taille 3 (annexe C.2). Ceci nous conduit à deux conclusions :d'une part, il est indispensable de fournir une preuve formelle, rigoureuse, pour ces algorithmes ;d'autre part, il est encore peu réaliste de véri�er mécaniquement le code lui-même et il faut doncidenti�er les bonnes abstractions permettant de décrire les schémas utilisés par ces algorithmes.Un dernier point plus intriguant est la possibilité d'utiliser la synchronisation non bloquante dansun contexte critique ou temps réel [ARJ97]. Le point positif est la solidité de ces algorithmes faceaux défaillances et à un environnement agressif ; le point négatif est leur dégradation (linéaireen général mais parfois exponentielle) en cas de contention défavorable : autant ces algorithmesinduisent un très faible surcoût de gestion du parallélisme quand les con�its d'accès sont rares,autant leurs performances se dégradent dans des cas pathologiques et leur WCET (worst-caseexecution time) est très éloigné du cas moyen. On manque actuellement de modélisation satis-faisante pour identi�er ces cas et leurs conditions d'occurrence, et en conséquence on ne sait pasbasculer sur de la synchronisation classique, plus régulière vis-à-vis du temps, si nécessaire.

111

Bibliographie

[AAE04] Paul C. Attie, Anish Arora, and E. Allen Emerson. Synthesis of fault-tolerantconcurrent programs. ACM Transactions on Programming Languages and Sys-tems, 26 :125�185, January 2004.

[ADKM92] Yair Amir, Danny Dolev, Shlomo Kramer, and Dalia Malki. Transis : A communi-cation subsystem for high availability. In 22nd Int'l Symposium on Fault-TolerantComputing, pages 76�84, July 1992.

[AF03] Stuart Anderson and Juliana Küster Filipe. Guaranteeing temporal validity witha real-time logic of knowledge. In 23rd Int'l Conference on Distributed ComputingSystems (ICDCS '03), pages 178�183. IEEE Computer Society, 2003.

[AG96] Sarita V. Adve and Kourosh Gharachorloo. Shared memory consistency models :A tutorial. IEEE Computer, 29 :66�76, 1996.

[AL94] Martín Abadi and Leslie Lamport. An old-fashioned recipe for real time. ACMTransactions on Programming Languages and Systems, 16(5) :1543�1571, 1994.

[All83] James F. Allen. Maintaining knowledge about temporal intervals. Communica-tions of the ACM, 26(11) :832�843, November 1983.

[AMMS+95] Y. Amir, L. E. Moser, P. M. Melliar-Smith, D. A. Agarwal, and P. Ciarfella.The Totem single-ring ordering and membership protocol. ACM Transactions onComputer Systems, 13 :311�342, November 1995.

[ARJ97] James H. Anderson, Srikanth Ramamurthy, and Kevin Je�ay. Real-time com-puting with lock-free shared objects. ACM Transactions on Computer Systems,15 :134�165, May 1997.

[AY96] Ian F. Akyildiz and Wei Yen. Multimedia group synchronization protocols forintegrated services networks. IEEE Journal on Selected Areas in Communications,14(1) :162�173, 1996.

[Bal98] Roberto Baldoni. A positive acknowledgment protocol for causal broadcasting.IEEE Transactions on Computers, 47(12) :1341�1350, December 1998.

[BB91] Jean-Pierre Banâtre and Michel Banâtre. Les systèmes distribués : expérience duprojet GOTHIC. InterEditions, February 1991.

[BBCB97] Gordon Blair, Lynne Blair, Amanda Chetwynd, and Howard Bowman. FormalSpeci�cations of Distributed Multimedia Systems. Taylor & Francis, Inc, 1997.

[BBFR99] Roberto Baldoni, Roberto Beraldi, Roy Friedman, and Robbert van Renesse. Thehierarchical daisy architecture for causal delivery. Distributed Systems Enginee-ring, 6(2) :71�81, 1999.

[Ben00] Abderrahim Benslimane. A multicast synchronization protocol for multiple dis-tributed multimedia streams. In 7th Int'l Conf. on High Performance Computing,pages 469�476, London, UK, 2000. Springer-Verlag.

113

BIBLIOGRAPHIE

[BG84] Philip A. Bernstein and Nathan Goodman. An algorithm for concurrency controland recovery in replicated distributed databases. ACM Transactions on DatabaseSystems, 9(4) :596�615, December 1984.

[BGMS86] Daniel Barbará, Hector Garcia-Molina, and Annemarie Spauster. Policies for dy-namic vote reassignment. In 6th Int'l Conf. on Distributed Computing System,pages 37�43, May 1986.

[BIL04] Malika Boulkenafed, Valerie Issarny, and Jinshan Liu. Group management forin-home ad hoc networks. In ECRTS International Workshop on Real-Time forMultimedia - Special Focus on Real-time Middleware for Consumer Electronics(RTMM), June 2004.

[Bir91] Kenneth P. Birman. The process group approach to reliable distributed computing.Technical Report 91-1216, Cornell University, July 1991.

[Bir93] Kenneth P. Birman. The process group approach to reliable distributed computing.Communications of the ACM, 36(12) :37�53, December 1993.

[BJ87] Kenneth P. Birman and Thomas A. Joseph. Reliable communication in the pre-sence of failures. ACM Transactions on Computer Systems, 5(1) :47�76, January1987.

[BMR96] Roberto Baldoni, Achour Mostéfaoui, and Michel Raynal. Causal delivery of mes-sages with real-time data in unreliable networks. Real-Time Systems, 10(3) :245�262, 1996.

[BR94] Kenneth P. Birman and Robbert van Renesse, editors. Reliable Distributed Com-puting with the Isis Toolkit. IEEE Computer Society Press, 1994.

[Bre00] Eric A. Brewer. Towards robust distributed systems (abstract). In 19th ACMSymposium on Principles of Distributed Computing, (Invited talk), page 7, 2000.

[BS96] Gerold Blakowski and Ralf Steinmetz. A media synchronization survey : Refe-rence model, speci�cation, and case studies. IEEE Journal on Selected Areas inCommunications, 14(1) :5�35, 1996.

[BSS91] Kenneth P. Birman, André Schiper, and Pat Stephenson. Lightweight causal andatomic group multicast. ACM Transactions on Computer Systems, 9(3) :272�314,1991.

[CBDGF95] Bernadette Charron-Bost, Carole Delporte-Gallet, and Hugues Fauconnier. Localand temporal predicates in distributed systems. ACM Transactions on Program-ming Languages and Systems, 17 :157�179, January 1995.

[CD88] George F. Coulouris and Jean Dollimore. Distributed Systems : concepts anddesign. International Computer Science Series. Addison Wesley, 1988.

[CDK01] George Coulouris, Jean Dollimore, and Tim Kindberg. Distributed Systems :concepts and design. Addison Wesley, third edition, 2001.

[CE82] Edmund M. Clarke and E. Allen Emerson. Design and synthesis of synchronizationskeletons using branching-time temporal logic. In Logic of Programs, Workshop,pages 52�71. Springer-Verlag, 1982.

[CFM+99a] Michel Charpentier, Mamoun Filali, Philippe Mauran, Gérard Padiou, and Phi-lippe Quéinnec. Modelling and verifying mobility : A case study. In 3rd Int'l Conf.On Principles Of DIstributed Systems, special issue of Studia Informatica, pages151�166, October 1999.

114

BIBLIOGRAPHIE

[CFM+99b] Michel Charpentier, Mamoun Filali, Philippe Mauran, Gérard Padiou, and Phi-lippe Quéinnec. The observation : An abstract communication mechanism. ParallelProcessing Letters, 9(3) :437�450, September 1999.

[CG98] Craig M. Chase and Vijay K. Garg. Detection of global predicates : techniquesand their limitations. Distributed Computing, 11 :191�201, October 1998.

[Cha97] Michel Charpentier. Assistance à la Répartition de Systèmes Réactifs. Thèse dedoctorat, Institut National Polytechnique de Toulouse, France, November 1997.

[CHTCB96] Tushar Deepak Chandra, Vassos Hadzilacos, Sam Toueg, and Bernadette Charron-Bost. On the impossibility of group membership. In 15th Symposium on Principlesof Distributed Computing, pages 322�330, May 1996.

[CK03] Punit Chandra and Ajay D. Kshemkalyani. Global predicate detection under�ne-grained modalities. In ASIAN 2003, pages 91�109. Springer-Verlag, 2003.

[CKV01] Gregory V. Chockler, Idit Keidar, and Roman Vitenberg. Group communicationspeci�cations : A comprehensive study. ACM Computing Surveys, 33(4) :427�469,December 2001.

[CL85] K. Mani Chandy and Leslie Lamport. Distributed snapshots : Determining globalstates of distributed systems. ACM Transactions on Computer Systems, 3(1) :63�75, February 1985.

[CM84] Jo-Mei Chang and N.F. Maxemchuk. Reliable broadcast protocols. ACM Tran-sactions on Computer Systems, 2(3) :251�275, 1984.

[CM88] K. Mani Chandy and Jayadev Misra. Parallel Program Design : A Foundation.Addison-Wesley, 1988.

[CM91] Robert Cooper and Keith Marzullo. Consistent detection of global predicates.SIGPLAN Notice, 26 :167�174, December 1991.

[CMSW93] Luis-Felipe Cabrera, John McPherson, Peter M. Schwarz, and James C. Wyllie.Implementing atomicity in two systems : Techniques, tradeo�s, and experience.IEEE Transactions on Software Engineering, 19 :950�961, October 1993.

[CPQ05] Michel Charpentier, Gérard Padiou, and Philippe Quéinnec. Cooperative mobileagents to gather global information. In 4th IEEE Int'l Symposium on NetworkComputing and Applications (NCA05), pages 271�274, July 2005.

[Cri91] Flaviu Cristian. Understanding fault-tolerant distributed systems. Communica-tions of the ACM, 34(2) :57�78, February 1991.

[Cri96] Flaviu Cristian. Synchronous and asynchronous group communication. Commu-nications of the ACM, 39(4) :88�97, April 1996.

[DGH+87] Alan Demers, Dan Greene, Carl Hauser, Wes Irish, John Larson, Scott Shender,Howard Sturgis, Dan Swinehart, and Doug Terry. Epidemic algorithms for re-plicated database maintenance. In 6th Symposium on Principles of DistributedComputing, pages 1�12, August 1987.

[DLV08] Juan De Lara and Hans Vangheluwe. Translating model simulators to analysismodels. In 11th Int'l Conf. on Fundamental Approaches to Software Engineering,volume 4961 of Lecture Notes in Computer Science, pages 77�92. Springer-Verlag,2008.

[DS94] Michel Diaz and Patrick Sénac. Time stream petri nets : A model for timedmultimedia information. In Int'l Conf. on Application and Theory of Petri Nets,pages 219�238, 1994.

115

BIBLIOGRAPHIE

[DSU04] Xavier Défago, André Schiper, and Péter Urbán. Total order broadcast and mul-ticast algorithms : Taxonomy and survey. ACM Computing Surveys, 36 :372�421,December 2004.

[EHR02] Anceaume Emmanuelle, Jean-Michel Hélary, and Michel Raynal. Tracking im-mediate predecessors in distributed computations. In 14th ACM symposium onParallel algorithms and architectures, pages 210�219, 2002.

[EPD94] Julio Escobar, Craig Partridge, and Debra Deutsch. Flow synchronization proto-col. IEEE/ACM Transactions on Networking, 2(2) :111�121, 1994.

[FB99] Armando Fox and Eric A. Brewer. Harvest, yield, and scalable tolerant systems.In 7th Workshop on Hot Topics in Operating Systems, pages 174�178, March 1999.

[FDP04] Jean Fanchon, Khalil Drira, and Saul Pomares Hernandez. Abstract channels asconnectors for software components in group communication services. In MexicanInternational Conference on Computer Science, pages 88�95, 2004.

[FIM+05] Mamoun Filali, Valérie Issarny, Philippe Mauran, Gérard Padiou, and PhilippeQuéinnec. Maximal group membership in ad hoc networks. In 6th Int'l Conf.on Parallel Processing and Applied Mathematics, volume 3911 of Lecture Notes inComputer Science, pages 51�58. Springer-Verlag, September 2005.

[FLP85] Michael J. Fischer, Nancy A. Lynch, and Michael S. Paterson. Impossibility ofdistributed consensus with one faulty process. Journal of the ACM, 32(2) :374�382,April 1985.

[FMMR10] Carlo A. Furia, Dino Mandrioli, Angelo Morzenti, and Matteo Rossi. Modelingtime in computing : A taxonomy and a comparative survey. ACM ComputingSurveys, 42 :6 :1�6 :59, March 2010.

[FMPQ03a] Mamoun Filali, Philippe Mauran, Gérard Padiou, and Philippe Quéinnec. Thereconstruction of a mobile agent computation and its validation. In Int'l Work-shop on Formal Methods for Parallel Programming : Theory and Applications(FMPPTA2003). IEEE, April 2003.

[FMPQ03b] Mamoun Filali, Philippe Mauran, Gérard Padiou, and Philippe Quéinnec. Setbased trees for the validation of a di�using computation reconstruction algorithm.In 2nd Int'l Workshop on Re�nement of Critical Systems : Methods, Tools andDevelopments (RCS'03), June 2003.

[FPQ98] Mamoun Filali, Gérard Padiou, and Philippe Quéinnec. Développement d'unespéci�cation formelle en Unity � analyse d'un système de contrôle d'accès. In Ap-proches Formelles dans l'Assistance au Développement de Logiciels (AFADL98),pages 109�120, Poitiers, September 1998.

[Fra80] James C. Frauenthal. Mathematical Modeling in Epidemiology. Springer-Verlag,1980.

[GC89] Cary G. Gray and David R. Cheriton. Leases : An e�cient fault-tolerant me-chanism for distributed �le cache consistency. ACM SIGOPS Operating SystemsReview, 23(5) :202�210, December 1989.

[GH06] Thomas Gustafsson and Jörgen Hansson. Data freshness and overload handlingin embedded systems. In 12th IEEE Int'l Conf. on Embedded and Real-TimeComputing Systems and Applications (RTCSA), pages 173�182. IEEE ComputerSociety, 2006.

[Gif79] David K. Gi�ord. Weighted voting for replicated data. In 7th Symposium onOperating System Principles, pages 150�162, December 1979.

116

BIBLIOGRAPHIE

[GL02] Seth Gilbert and Nancy Lynch. Brewer's conjecture and the feasibility ofconsistent, available, partition-tolerant web services. SIGACT News, 33 :51�59,June 2002.

[GMPQ03] Romulus Grigora³, Philippe Mauran, Gérard Padiou, and Philippe Quéinnec. Or-donnancement causal de �ux répartis multimédias. In Formalisation des ActivitésConcurrentes FAC'2003, March 2003.

[Gri03] Romulus Grigora³. Supervision de �ux pour les contenus hypermédia : optimisationde politiques de préchargement et ordonnancement causal. PhD thesis, Institutnational polytechnique de Toulouse, December 2003.

[GS97] Richard Guerraoui and André Schiper. Total order multicast to multiple groups.In 17th Int'l Conf. on Distributed Computing Systems, pages 578�585, May 1997.

[Haj96] Elzbieta Hajnicz. Time Structures. Number 1047 in Lecture Notes in Arti�cialIntelligence. Springer-Verlag, 1996.

[Haj99] Elzbieta Hajnicz. Some considerations on branching areas of time. Journal ofLogic, Language and Information, 8(1) :17�43, January 1999.

[Her91] Maurice Herlihy. Wait-free synchronization. ACM Transactions on ProgrammingLanguages and Systems, 13 :124�149, January 1991.

[HHK03] Thomas A. Henzinger, Benjamin Horowitz, and Christoph M. Kirsch. Giotto :a time-triggered language for embedded programming. Proceedings of the IEEE,91(1) :84�99, 2003.

[HM93] Maurice Herlihy and J. Eliot B. Moss. Transactional memory : architectural sup-port for lock-free data structures. ACM SIGARCH Computer Architecture News,21 :289�300, May 1993.

[HM96] Constance Heitmeyer and Dino Mandrioli, editors. Formal Methods for Real-TimeComputing. Trends in Software. Wiley, 1996.

[HMPJH05] Tim Harris, Simon Marlow, Simon Peyton Jones, and Maurice Herlihy. Compo-sable memory transactions. In 10th ACM SIGPLAN symposium on Principles andPractice of Parallel Programming, PPoPP '05, pages 48�60, 2005.

[HMPJH08] Tim Harris, Simon Marlow, Simon Peyton Jones, and Maurice Herlihy. Compo-sable memory transactions. Communications of the ACM, 51 :91�100, August2008.

[Hol03] Gerard Holzmann. The Spin Model Checker : Primer and Reference Manual.Addison-Wesley, 2003.

[HRMB03] Jean-Michel Hélary, Michel Raynal, Giovanna Melideo, and Roberto Baldoni. Ef-�cient causality-tracking timestamping. IEEE Transactions on Knowledge andData Engineering, 15(5) :1239�1250, September 2003.

[HYC04] Ting-Chao Hou, Chorng-Horng Yang, and Kim-Joan Chen. Adaptive messagescheduling for supporting causal ordering in wide-area group communications.Journal of Systems and Software, 72(3) :321�333, 2004.

[IT95] Yutaka Ishibashi and Shuji Tasaka. A synchronization mechanism for continuousmedia in multimedia communications. In Fourteenth Annual Joint Conferenceof the IEEE Computer and Communications Societies INFOCOM'95, volume 3,pages 1010�1019, April 1995.

[IT00] Yutaka Ishibashi and Shuji Tasaka. A comparative survey of sychronization al-gorithms for continuous media in network environments. In IEEE Conference onLocal Computer Networks, pages 337�348, 2000.

117

BIBLIOGRAPHIE

[IT03] Yutaka Ishibashi and Shuji Tasaka. Causality and media synchronization controlfor networked multimedia games : centralized versus distributed. In 2nd Workshopon Network and System Support for Games, pages 42�51, May 2003.

[ITM00] Yutaka Ishibashi, Shuji Tasaka, and Hiromasa Miyamoto. Joint synchronizationbetween live and stored media in multicast communications. In 25th Annual IEEEConference on Local Computer Networks, pages 330�336, 2000.

[ITT97] Yutaka Ishibashi, Akihiro Tsuji, and Shuji Tasaka. A group synchronization me-chanism for stored media in multicast communications. In INFOCOM, pages692�700, 1997.

[ITTI03] Yutaka Ishibashi, Kiyoshi Tomaru, Shuji Tasaka, and Katsunori Inazumi. Groupsynchronization in networked virtual environments. In IEEE Int'l Conf. on Com-munications ICC'03, volume 2, pages 885 � 890 vol.2, May 2003.

[JGr10] The JGroups projet. http://www.jgroups.org, 2002�2010.

[JK03] Jinyong Jo and JongWon Kim. Evaluation on the performance of adaptive playoutfor the multicast streaming of stored media. In IEEE Int'l Conf. on Communica-tions ICC'03, volume 1, pages 542�546, May 2003.

[JLR98] Muriel Jourdan, Nabil Layaïda, and Cécile Roisin. Handbook of Internet andMultimedia Systems and Applications, part 1 : Tools and Standards, chapter Asurvey on authoring techniques for temporal scenarios of multimedia documents,pages 469�490. CRC Press, April 1998.

[JXR06] Abhay Kumar Jha, Ming Xiong, and Krithi Ramamritham. Mutual consistency inreal-time databases. In 27th IEEE Real-Time Systems Symposium, pages 335�343,2006.

[KCH+06] Sanjeev Kumar, Michael Chu, Christopher J. Hughes, Partha Kundu, and AnthonyNguyen. Hybrid transactional memory. In 11th ACM SIGPLAN symposium onPrinciples and practice of parallel programming, PPoPP '06, pages 209�220, 2006.

[KD96] Chérif Keramane and Andrzej Duda. Interval expressions-a functional model forinteractive dynamic multimedia presentations. In Third IEEE Int'l Conf. on Mul-timedia Computing and Systems, pages 283�286, June 1996.

[KL91] Henry A. Kautz and Peter B. Ladkin. Integrating metric and qualitative temporalreasoning. In Ninth National Conference on Arti�cial Intelligence (AAAI-91),pages 241�246, 1991.

[KS98] Ajay D. Kshemkalyani and Mukesh Singhal. Necessary and su�cient conditionson information for causal message ordering and their optimal implementation.Distributed Computing, 11(2) :91�111, 1998.

[Ksh96] Ajay D. Kshemkalyani. Temporal interactions of intervals in distributed systems.Journal of Computer and System Sciences, 52 :287�298, 1996.

[Ksh03] Ajay D. Kshemkalyani. A �ne-grained modality classi�cation for global predicates.IEEE Transactions on Parallel and Distributed Systems, 14(8) :807�816, August2003.

[KSSA02] Kyoung-Don Kang, Sang Hyuk Son, John A. Stankovic, and Tarek F. Abdelza-her. A QoS-sensitive approach for timeliness and freshness guarantees in real-timedatabases. In 14th Euromicro Conference on Real-Time Systems, pages 203�212,2002.

118

BIBLIOGRAPHIE

[KT91] Frans Kaashoek and Andrew S. Tanenbaum. Group communication in the Amoebadistributed operating system. In 11th Int'l Conf. on Distributed Computing Sys-tem, pages 222�230, May 1991.

[KTFB89] Frans Kaashoek, Andrew S. Tanenbaum, Susan Flynn Hummel, and Henri E.Bal. An e�cient reliable broadcast protocol. Operating Systems Review, 23 :5�19,October 1989.

[Lam78] Leslie Lamport. Time, clocks and the ordering of events in a distributed system.Communications of the ACM, 21(7) :558�565, July 1978.

[Lam79] Leslie Lamport. How to make a multiprocessor computer that correctly executesmultiprocess programs. IEEE Transactions on Computers, C-28(9) :690�691, Sep-tember 1979.

[Lam86a] Leslie Lamport. On interprocess communication. i. basic formalism. DistributedComputing, 1 :77�85, 1986.

[Lam86b] Leslie Lamport. On interprocess communication. ii. algorithms. Distributed Com-puting, 1 :86�101, 1986.

[Lam94] Leslie Lamport. The temporal logic of actions. ACM Transactions on Program-ming Languages and Systems, 16(3) :872�923, May 1994.

[Lam03] Leslie Lamport. Specifying Systems. Addison Wesley, 2003.

[Lam09] Leslie Lamport. The PlusCal algorithm language. In 6th Int'l Colloquium onTheoretical Aspects of Computing, ICTAC '09, pages 36�60. Springer-Verlag, 2009.

[LB07] Tanguy Le Berre. Contraintes temporelles sur les données dans les systèmes tempsréel distribués. In École d'été Temps Réel 2007, September 2007.

[LB10] Tanguy Le Berre. Spéci�cation formelle de systèmes temps réel répartis par uneapproche �ots de données à contraintes temporelles. PhD thesis, Université deToulouse, 23 mars 2010.

[LBMPQ08] Tanguy Le Berre, Philippe Mauran, Gérard Padiou, and Philippe Quéinnec. Realtime behavior of data in distributed embedded systems. In Int'l Workshop on RealTime Software (RTS'08), pages 569�575. Polish Information Processing Society,October 2008.

[LBMPQ09a] Tanguy Le Berre, Philippe Mauran, Gérard Padiou, and Philippe Quéinnec. Adata oriented approach for real-time systems. In 17th Int'l Conf. on Real-Timeand Network Systems RTNS09, pages 147�158, October 2009.

[LBMPQ09b] Tanguy Le Berre, Philippe Mauran, Gérard Padiou, and Philippe Quéinnec. Realtime behavior of data in distributed embedded systems. Scalable Computing :Practice and Experience, 10(3) :229�239, September 2009.

[LBPQ09] Tanguy Le Berre, Gérard Padiou, and Philippe Quéinnec. Étude du comporte-ment temporel de données réparties. In Formalisation des Activités ConcurrentesFAC'2009, April 2009.

[LBQP08] Tanguy Le Berre, Philippe Quéinnec, and Gérard Padiou. Ensuring timed validityof distributed real time data. In 4th European Congress on Embedded Real TimeSoftware (ERTS 2008), January 2008.

[LG93] Thomas D.C. Little and Arif Ghafoor. Interval-based conceptual models for time-dependent multimedia data. IEEE Transactions on Knowledge and Data Engi-neering, 5(4) :551�563, August 1993.

119

BIBLIOGRAPHIE

[LP91] Darrell D.E. Long and Jehan-François Pâris. Voting with regenerable volatilewitnesses. In Int'l Conf. on Data Engineering, pages 112�121, April 1991.

[LS90] Eliezer Levy and Abraham Siberschatz. Distributed �le systems : Concepts andexamples. ACM Computing Surveys, 22(4) :321�374, December 1990.

[LSI96] Nabil Layaïda and Loay Sabry-Ismaïl. Madeus : un modèle de document mul-timédia structuré. Techniques et Sciences de l'Informatique, 15(9) :1227�1257,1996.

[LSS96] Minglu Li, Yongqiang Sun, and Huanye Sheng. Temporal representation for mul-timedia systems. In Third Int'l Workshop on Temporal Representation and Rea-soning TIME '96, pages 204�210, May 1996.

[LSSI05] Jinshan Liu, Daniele Sacchetti, Françoise Sailhan, and Valérie Issarny. Groupmanagement for mobile ad hoc networks : design, implementation and experiment.In 6th international conference on Mobile data management, pages 192�199. ACM,May 2005.

[LSV96] Edward A. Lee and Alberto Sangiovanni-Vincentelli. Comparing models of compu-tation. In IEEE/ACM international conference on Computer-aided design, pages234�241. IEEE Computer Society, 1996.

[MA95] Mark Moir and James H. Anderson. Wait-free algorithms for fast, long-livedrenaming. Science of Computer Programming, 25 :1�39, 1995.

[Mag07] Morgan Magnin. Réseaux de Petri à chronomètres : temps dense et temps discret.PhD thesis, École Centrale de Nantes, France, December 2007.

[Mat89] Friedemann Mattern. Virtual time and global state in distributed systems. InM. Cosnard, Y. Robert, P. Quinton, and M. Raynal, editors, Int'l Workshop onParallel and Distributed Algorithms, pages 215�226. Elsevier Science Publishers,1989.

[Mau00] Martin Mauve. Consistency in replicated continuous interactive media. In CSCW'00 : Proceedings of the 2000 ACM conference on Computer supported cooperativework, pages 181�190. ACM, 2000.

[MCWB91] Keith Marzullo, Robert Cooper, Mark Wood, and Kenneth P. Birman. Tools fordistributed application management. IEEE Computer, 24(8) :42�51, August 1991.

[MKA09] Jennifer Mankin, David Kaeli, and John Ardini. Software transactional memoryfor multicore embedded systems. ACM SIGPLAN Notices, 44 :90�98, June 2009.

[MMSA+96] L. E. Moser, P. M. Melliar-Smith, D. A. Agarwal, R. K. Budhia, and C. A. Lingley-Papadopoulos. Totem : A fault-tolerant multicast group communication system.Communications of the ACM, 39(4) :54�63, April 1996.

[MMTW10] Paul E. McKenney, Maged M. Michael, Josh Triplett, and Jonathan Walpole.Why the grass may not be greener on the other side : a comparison of lockingvs. transactional memory. ACM SIGOPS Operating Systems Review, 44 :93�101,August 2010.

[MPQ07] Philippe Mauran, Gérard Padiou, and Philippe Quéinnec. Separability to helpparallel simulation of distributed computations. In 11th Int'l Conf. On PrinciplesOf DIstributed Systems, volume 4878 of Lecture Notes in Computer Science, pages358�371. Springer-Verlag, December 2007.

[MPQD09] Philippe Mauran, Gérard Padiou, Philippe Quéinnec, and Bernard Delatte. Usingseparability to enable time-consistent distributed space simulation. In DASIA09

120

BIBLIOGRAPHIE

DAta Systems In Aerospace, pages 281�284. International Space System Enginee-ring Conference, May 2009.

[MS94] Keith Marzullo and Laura S. Sabel. E�cient detection of a class of stable proper-ties. Distributed Computing, 8(2) :81�91, October 1994.

[MS96] Maged M. Michael and Michael L. Scott. Simple, fast, and practical non-blockingand blocking concurrent queue algorithms. In 15th ACM symposium on Principlesof Distributed Computing PODC'96, pages 267�275, 1996.

[MT98] Achour Mostefaoui and Oliver Theel. Shrinking timestamp sizes of event orderingprotocols. In Int'l Conf. on Parallel and Distributed Systems, pages 193�200,December 1998.

[MVHE04] Martin Mauve, Jürgen Vogel, Volker Hilt, and Wolfgang E�elsberg. Local-lag andtimewarp : providing consistency for replicated continuous applications. IEEETransactions on Multimedia, 6(1) :47�57, February 2004.

[NA87] Jerre D. Noe and Agnes Andreassian. E�ectiveness of replication in distributedcomputer networks. In 7th Int'l Conf. on Distributed Computing System, pages508�513, September 1987.

[Nee89] Roger M. Needham. Naming. In Sape J. Mullender, editor, Distributed Systems,pages 89�101. ACM Press Frontier Series, �rst edition, 1989.

[NMR91] Mitchell L. Neilsen, Masaaki Mizuno, and Michel Raynal. A general method tode�ne quorums. Technical Report 1529, INRIA and Kansas State University,September 1991.

[NT03] Toshiro Nunome and Shuji Tasaka. An application-level QoS comparison of inter-destination synchronization schemes for continuous media multicasting. In IEEEGlobal Telecommunications Conference GLOBECOM '03, volume 7, pages 3602�3608, December 2003.

[NTA96] Mohamed Naimi, Michel Trehel, and André Arnold. A log(N) distributed mutualexclusion algorithm based on path reversal. Journal of Parallel and DistributedComputing, 34(1) :1�13, April 1996.

[Pap79] Christos H. Papadimitriou. The serializability of concurrent database updates.Journal of the ACM, 26 :631�653, October 1979.

[PBS89] Larry L. Peterson, Nick C. Buchholz, and Richard D. Schlichting. Preserving andusing context information in interprocess communication. ACM Transactions onComputer Systems, 7(3) :217�246, 1989.

[PGQ+06] Cezar Ple³ca, Romulus Grigora³, Philippe Quéinnec, Gérard Padiou, and JeanFanchon. A coordination-level middleware for supporting �exible consistency inCSCW. In 14th Euromicro Conf. on Parallel, Distributed and Network-based Pro-cessing, pages 316�321. IEEE, February 2006.

[PGQP05a] Cezar Ple³ca, Romulus Grigora³, Philippe Quéinnec, and Gérard Padiou. Adaptivemultimodal communication for multimedia. In 11th Euromedia, pages 183�189,April 2005.

[PGQP05b] Cezar Ple³ca, Romulus Grigora³, Philippe Quéinnec, and Gérard Padiou. A �exiblecommunication toolkit for synchronous groupware. In Int'l Conf. on MultimediaCommunications Systems ICMCS05, pages 216�221, August 2005.

[PGQP05c] Cezar Ple³ca, Romulus Grigora³, Philippe Quéinnec, and Gérard Padiou. Strea-ming with causality : A practical approach. In ACM Multimedia, pages 283�286,November 2005.

121

BIBLIOGRAPHIE

[Ple07] Cezar Ple³ca. Supervision de contenus multimédia : adaptation de contenu, po-litiques optimales de préchargement et coordination causale de �ux. PhD thesis,Institut national polytechnique de Toulouse, June 2007.

[PNP88] Calton Pu, Jerre D. Noe, and Andrew Proudfoot. Regeneration of replicatedobjects : a technique and its Eden implementation. IEEE Transactions on SoftwareEngineering, 14(7) :936�945, July 1988.

[Pon09] Nadège Pontisso. Association cohérente de données dans les systèmes temps réelà base de composants � Application aux logiciels spatiaux. PhD thesis, Universitéde Toulouse, 16 décembre 2009.

[PPQ08a] Nadège Pontisso, Gérard Padiou, and Philippe Quéinnec. Cohérence tempo-relle des calculs répartis embarqués. In Formalisation des Activités ConcurrentesFAC'2008, April 2008.

[PPQ08b] Nadège Pontisso, Gérard Padiou, and Philippe Quéinnec. Real time data consis-tency in component based embedded systems. In 8th int'l conf. on New technolo-gies in distributed systems � session Consistency, June 2008.

[PQP09] Nadège Pontisso, Philippe Quéinnec, and Gérard Padiou. Temporal data mat-ching in component based real time systems. In IEEE Symposium on IndustrialEmbedded Systems SIES2009, pages 62�65, July 2009.

[PQP10] Nadège Pontisso, Philippe Quéinnec, and Gérard Padiou. Analysis of distributedmulti-periodic systems to achieve consistent data matching. In 10th Annual Int'lConf. on New Technologies of Distributed Systems NOTERE 2010, pages 81�88,May 2010.

[PQP11] Nadège Pontisso, Philippe Quéinnec, and Gérard Padiou. Analysis of distributedmulti-periodic systems to achieve consistent data matching. Concurrency andComputation : Practice and Experience, A paraître 2011.

[PQPV09] Nadège Pontisso, Philippe Quéinnec, Gérard Padiou, and Guillaume Véran. Dataconsistency in a component based space system. In DASIA09 DAta Systems InAerospace, pages 277�280. International Space System Engineering Conference,May 2009.

[PRS97] Ravi Prakash, Michel Raynal, and Mukesh Singhal. An adaptive causal orde-ring algorithm suited to mobile computing environments. Journal of Parallel andDistributed Computing, 41(2) :190�204, 1997.

[Pâ86] Jehan-François Pâris. Voting with witnesses : A consistency scheme for replicated�les. In 6th Int'l Conf. on Distributed Computing System, pages 606�612, May1986.

[QFMP00] Philippe Quéinnec, Mamoun Filali, Philippe Mauran, and Gérard Padiou. Descri-bing mobile computations with path vectors. In 4th Int'l Conf. On Principles OfDIstributed Systems, special issue of Studia Informatica Universalis, pages 221�234, December 2000.

[Qué10] Philippe Quéinnec. À la découverte des 5000 occidentaux du Pamir. Revue Pyré-néenne, 130 :21�25, June 2010.

[Ray87] Michel Raynal. Systèmes Répartis & Réseaux, concepts outils & algorithmes. Edi-tion Eyrolles, 1987.

[Ray92a] Michel Raynal. Gestion des Données Réparties : Problèmes et Protocoles. Collec-tion Direction Études-Recherches EDF. Edition Eyrolles, 1992.

122

BIBLIOGRAPHIE

[Ray92b] Michel Raynal. Synchronisation et État Global dans les Systèmes Répartis. Col-lection Direction Études-Recherches EDF. Edition Eyrolles, 1992.

[Ray10] Michel Raynal. Communication and Agreement Abstractions for Fault-tolerantAsynchronous Distributed Systems. Synthesis Lectures on Distributed ComputingTheory. Morgan and Claypool Publishers, 2010.

[RBM96] Robbert van Renesse, Kenneth P. Birman, and Silvano Ma�eis. Horus : A �exiblegroup communications system. Communications of the ACM, 39(4) :76�83, April1996.

[RHL05] Ravi Rajwar, Maurice Herlihy, and Konrad Lai. Virtualizing transactional me-mory. SIGARCH Computer Architecture News, 33 :494�505, May 2005.

[RJMB93] Guido van Rossum, Jack Jansen, K. Sjoerd Mullender, and Dick C. A. Bulter-man. Cmifed : a presentation environment for portable hypermedia documents.In MULTIMEDIA '93 : �rst ACM int'l conf. on Multimedia, pages 183�188, 1993.

[RM89] B. Rajagopalan and Philip K. McKinley. A token-based protocol for reliable, orde-red multicast communication. In 8th Symposium on Reliable Distributed Systems,pages 84�93, October 1989.

[RS97] David J. Roberts and Paul M. Sharkey. Minimising the latency induced by consis-tency control, within a large scale multi-user distributed virtual reality system. InIEEE Int'l Conf. on Systems, Man, and Cybernetics, volume 5, pages 4492�4497,October 1997.

[RSD04] Krithi Ramamritham, Sang H. Son, and Lisa Cingiser DiPippo. Real-time data-bases and data services. Real-Time Systems, 28(2-3) :179�215, 2004.

[RST91] Michel Raynal, André Schiper, and Sam Toueg. The causal ordering abstractionand a simple way to implement it. Information Processing Letters, 39 :343�350,October 1991.

[RT88] Robbert van Renesse and Andrew S. Tanenbaum. Voting with ghosts. In 8th Int'lConf. on Distributed Computing System, pages 456�461, June 1988.

[RV95] Luís Rodrigues and Paulo Veríssimo. Causal separators for large-scale multicastcommunication. In Int'l Conf. on Distributed Computing System, pages 83�91,1995.

[SBV10] Martin Schoeberl, Florian Brandner, and Jan Vitek. RTTM : real-time transactio-nal memory. In ACM Symposium on Applied Computing, SAC '10, pages 326�333,2010.

[Sch06] André Schiper. Dynamic group communication. Distributed Computing,18(5) :359�374, 2006.

[SDLSS96] Patrick Sénac, Michel Diaz, Alain Léger, and Pierre de Saqui-Sannes. Modelinglogical and temporal synchronization in hypermedia systems. IEEE Journal onSelected Areas in Communications, 14(1) :84�103, January 1996.

[SL92] Xiaohui Song and Jane W.S. Liu. How well can data temporal consistency bemaintained ? In IEEE Symposium on Computer-Aided Control System Design,pages 275�284, March 1992.

[SL95] Xiaohui Song and Jane W.S. Liu. Maintaining temporal consistency : Pessimisticvs. optimitic concurrency control. IEEE Transactions on Knowledge and DataEngineering, 7(5) :786�796, 1995.

123

BIBLIOGRAPHIE

[SM94] Reinhard Schwarz and Friedemann Mattern. Detecting causal relationships indistributed computations : In search of the holy grail. Distributed Computing,7(3) :149�174, June 1994.

[SN04] Robert C. Steinke and Gary J. Nutt. A uni�ed theory of shared memory consis-tency. Journal of the ACM, 51 :800�849, September 2004.

[SPL92] Perry K. Sloope, Jehan-François Pâris, and Darrell D.E. Long. A simulation studyof replication control protocols using volatile witnesses. In 25th Annual SimulationSymposium, pages 108�117, April 1992.

[SS05] Yasushi Saito and Marc Shapiro. Optimistic replication. ACM Computing Surveys,37(1) :42�81, March 2005.

[ST95] Nir Shavit and Dan Touitou. Software transactional memory. In 14th ACM sym-posium on Principles of Distributed Computing, PODC '95, pages 204�213, 1995.

[STT02] Kenichi Shimamura, Katsuya Tanaka, and Makoto Takizawa. Causally ordereddelivery of multimedia objects. Computer Communications, 25(5) :437�444, March2002.

[TRA99] Francisco J. Torres-Rojas and Mustaque Ahamad. Plausible clocks : constantsize logical clocks for distributed systems. Distributed Computing, 12 :179�195,September 1999.

[UNR+01] Bhuvan Urgaonkar, Anoop George Ninan, Mohammad Salimullah Raunak, Pra-shant Shenoy, and Krithi Ramamritham. Maintaining mutual consistency for ca-ched web objects. In 21st International Conference on Distributed ComputingSystems, pages 371�380. IEEE Computer Society, 2001.

[W3C08] W3C Recommendation. Synchronized Multimedia Integration Language (SMIL3.0), 2008.

[WS95] Uwe Wilhelm and André Schiper. A hierarchy of totally ordered multicasts. In14th Symposium on Reliable Distributed Systems, pages 106�17, September 1995.

[XHL05] Ming Xiong, Song Han, and Kam-Yiu Lam. A deferrable scheduling algorithmfor real-time transactions maintaining data freshness. In 26th IEEE Real-TimeSystems Symposium, pages 27�37. IEEE Computer Society, 2005.

[XHLC08] Ming Xiong, Song Han, Kam-Yiu Lam, and Deji Chen. Deferrable scheduling formaintaining real-time data freshness : Algorithms, analysis, and results. Compu-ters, IEEE Transactions on, 57(7) :952�964, July 2008.

[XRS+02] Ming Xiong, Krithi Ramamritham, John A. Stankovic, Don Towsley, and Rajen-dran Sivasankaran. Scheduling transactions with temporal constraints : Exploi-ting data semantics. IEEE Transactions on Knowledge and Data Engineering,14(5) :1155�1166, September 2002.

[XSS+96] Ming Xiong, Rajendran Sivasankaran, John A. Stankovic, Krithi Ramamritham,and Don Towsley. Scheduling transactions with temporal constraints : Exploitingdata semantics. In 17th IEEE Real-Time Systems Symposium, pages 240�253,1996.

[Yav92] Rajendra Yavatkar. MCP : A protocol for coordination and temporal synchro-nization in multimedia collaborative applications. In Int'l Conf. on DistributedComputing System, pages 606�613, 1992.

[Yic] Yices : An SMT solver. http://yices.csl.sri.com/.

124

Troisième partie

Annexes

125

Annexe A

Groupes maximaux dans les réseaux

ad hoc � modèles TLA+

A.1 L'algorithme de construction de groupes

module Algo

constant Proc

Message∆=

[type : {�D�}, emetteur : Proc] ∪[type : {�J�}, emetteur : Proc, voisinage : subset Proc] ∪[type : {�I�}, emetteur : Proc, vue : subset Proc]

variables

pour chaque siteetat ,voisins,supporters,voisinages,vueInstallee,les messages en transit

net

netw∆= instance reseauAsync with Id ← Proc, Message ← Message, network ← net

Etat∆= {�singleton�, �decouverte� , �constitution� , �expectatif� , �groupe�}

TypeInvariant∆=

∧ netw !TypeInvariant∧ etat ∈ [Proc → Etat ]∧ voisins ∈ [Proc → subset Proc]∧ supporters ∈ [Proc → subset Proc]∧ vueInstallee ∈ [Proc → subset Proc]∧ voisinages ∈ [Proc → [Proc → subset Proc]]∧ domain voisinages = Proc

∧ ∀ p ∈ Proc : domain voisinages[p] ⊆ Proc

∧ ∀ p ∈ Proc : ∀ q ∈ domain voisinages[p] : voisinages[p][q ] ⊆ Proc

Invariant

127

L'algorithme de construction de groupes

Coherence∆=

la vue n'existe que dans l ′état groupé

∧ ∀ p ∈ Proc : (etat [p] = �groupe�) ≡ (vueInstallee[p] 6= {})un site ne peut être supporter que s'il a été découvert

∧ ∀ p ∈ Proc : supporters[p] ⊆ voisins[p]lien voisinages - supporters

∧ ∀ p, q ∈ Proc : (voisinages[p][q ] 6= {}) ≡ (q ∈ supporters[p])la vue est un sous-ensemble des voisins

∧ ∀ p ∈ Proc : vueInstallee[p] ⊆ voisins[p]

except(f , e, i)∆= [e1 ∈ domain (f ) ∪ {e} 7→ if e1 = e then i else f [e1]]

Init∆=∧ netw !Init∧ etat = [p ∈ Proc 7→ �singleton�]∧ voisins = [p ∈ Proc 7→ {}]∧ supporters = [p ∈ Proc 7→ {}]∧ voisinages = [p ∈ Proc 7→ [q ∈ Proc 7→ {}]]∧ vueInstallee = [p ∈ Proc 7→ {}]

état Singleton

SingletonDecouverte(p, m)∆= Réception d'un message découverte.

∧ etat [p] = �singleton�∧m.type = �D�∧ netw !Etape(p, m, Proc, [type 7→ �D�, emetteur 7→ p])∧ etat ′ = [etat except ![p] = �decouverte� ]∧ voisins ′ = [voisins except ![p] = {p, m.emetteur}]∧ voisinages ′ = [voisinages except ![p] = [q ∈ Proc 7→ {}]]∧ supporters ′ = [supporters except ![p] = {}]∧ unchanged 〈vueInstallee〉

SingletonIgnore(p, m)∆= message ignoré

∧ etat [p] = �singleton�∧m.type ∈ {�J�, �I�}∧ netw !Recevoir(p, m)∧ unchanged 〈etat , voisins, supporters, voisinages, vueInstallee〉

SingletonExpiration(p)∆= émission périodique de message découverte

∧ etat [p] = �singleton�∧ netw !Di�user(p, [type 7→ �D�, emetteur 7→ p])∧ unchanged 〈etat , voisins, supporters, voisinages, vueInstallee〉

état Découverte

local jonctionInutile(p, m)∆= message Jonction inutilisé

∧m.emetteur /∈ voisins[p]∧ unchanged 〈voisinages, supporters〉

local jonctionAccepte(p, m)∆= message Jonction accepté

∧m.emetteur ∈ voisins[p]∧ voisinages ′ = [voisinages except ![p] = [@ except ![m.emetteur ] = m.voisinage]]∧ supporters ′ = [supporters except ![p] = @ ∪ {m.emetteur}]

DecouverteDecouverte(p, m)∆= réception d'un message découverte

∧ etat [p] = �decouverte�

128

Annexe A - Groupes maximaux dans les réseaux ad hoc � modèles TLA+

∧m.type = �D�∧ netw !Recevoir(p, m)∧ voisins ′ = [voisins except ![p] = @ ∪ {m.emetteur}]∧ unchanged 〈etat , voisinages, supporters, vueInstallee〉

DecouverteJonction(p, m)∆= réception d'un message Jonction

∧ etat [p] = �decouverte�∧m.type = �J�∧ netw !Recevoir(p, m)∧ jonctionInutile(p, m) ∨ jonctionAccepte(p, m)∧ unchanged 〈etat , voisins, vueInstallee〉

DecouverteIgnore(p, m)∆= message ignoré

∧ etat [p] = �decouverte�∧m.type = �I�∧ netw !Recevoir(p, m)∧ unchanged 〈etat , voisins, supporters, voisinages, vueInstallee〉

DecouverteExpiration(p)∆= expiration de l ′état Découverte

∧ etat [p] = �decouverte�∧ ∃ l ∈ Proc :∧ l ∈ voisins[p]∧ let m

∆= [type 7→ �J�, emetteur 7→ p, voisinage 7→ voisins[p]]

in if l = p then

∧ jonctionAccepte(p, m)∧ unchanged 〈net〉

else

∧ netw !Emettre(p, l , m)∧ unchanged 〈voisinages, supporters〉

∧ etat ′ = [etat except ![p] = �constitution�]∧ unchanged 〈voisins, vueInstallee〉

état Constitution

local inclusionInutile(p, m)∆= message Inclusion inutilisé

∧m.type = �I�∧ p /∈ m.vue∧ unchanged 〈etat , vueInstallee〉

local inclusionAcceptee(p, m)∆= message Inclusion accepté

∧m.type = �I�∧ p ∈ m.vue∧ vueInstallee ′ = [vueInstallee except ![p] = m.vue]∧ etat ′ = [etat except ![p] = �groupe� ]

local inclusionRejetee(p, m)∆= message Inclusion rejeté

∧m.type = �I�∧ p ∈ m.vue∧ unchanged 〈etat , vueInstallee〉

ConstitutionJonction(p, m)∆= réception d'un message Jonction

∧ etat [p] = �constitution�∧m.type = �J�∧ netw !Recevoir(p, m)∧ jonctionInutile(p, m) ∨ jonctionAccepte(p, m)∧ unchanged 〈etat , voisins, vueInstallee〉

129

L'algorithme de construction de groupes

ConstitutionInclusion(p, m)∆= réception d'un message Inclusion

∧ etat [p] = �constitution�∧m.type = �I�∧ netw !Recevoir(p, m)∧ inclusionInutile(p, m) ∨ inclusionAcceptee(p, m) ∨ inclusionRejetee(p, m)∧ unchanged 〈voisins, voisinages, supporters〉

ConstitutionIgnore(p, m)∆= message ignoré

∧ etat [p] = �constitution�∧m.type = �D�∧ netw !Recevoir(p, m)∧ unchanged 〈etat , voisins, supporters, voisinages, vueInstallee〉

ConstitutionExpiration(p)∆= expiration de l ′état Constitution

∧ etat [p] = �constitution�∧ ∃ v ∈ subset Proc :

La vue est un sous-ensemble des supporters, et le site qui calcule doit être dedans.∧ v ⊆ (supporters[p] ∪ {p})∧ (v 6= {}) ≡ (p ∈ v)∧ if v 6= {} then∧ netw !Di�user(p, [type 7→ �I�, emetteur 7→ p, vue 7→ v ])∧ vueInstallee ′ = [vueInstallee except ![p] = v ]∧ etat ′ = [etat except ![p] = �groupe� ]∧ unchanged 〈voisins, voisinages, supporters〉

else

∧ etat ′ = [etat except ![p] = �expectatif� ]∧ unchanged 〈voisins, voisinages, supporters, vueInstallee, net〉

état Expectatif

ExpectatifInclusion(p, m)∆= réception message Inclusion

∧ etat [p] = �expectatif�∧m.type = �I�∧ netw !Recevoir(p, m)∧ inclusionInutile(p, m) ∨ inclusionAcceptee(p, m) ∨ inclusionRejetee(p, m)∧ unchanged 〈voisins, voisinages, supporters〉

ExpectatifIgnore(p, m)∆= message ignoré

∧ etat [p] = �expectatif�∧m.type ∈ {�D�, �J�}∧ netw !Recevoir(p, m)∧ unchanged 〈etat , voisins, supporters, voisinages, vueInstallee〉

ExpectatifExpiration(p)∆= expiration de l ′état Expectatif

∧ etat [p] = �expectatif�∧ etat ′ = [etat except ![p] = �singleton�]∧ unchanged 〈voisins, voisinages, supporters, vueInstallee, net〉

état Groupé

GroupeInclusion(p, m)∆= réception message Inclusion

∧ etat [p] = �groupe�∧m.type = �I�∧ netw !Recevoir(p, m)∧ inclusionInutile(p, m) ∨ inclusionAcceptee(p, m) ∨ inclusionRejetee(p, m)∧ unchanged 〈etat , voisins, voisinages, supporters〉

130


GroupeIgnore(p, m)∆= message ignoré

∧ etat [p] = �groupe�∧m.type ∈ {�D�, �J�}∧ netw !Recevoir(p, m)∧ unchanged 〈etat , voisins, supporters, voisinages, vueInstallee〉

GroupeExpiration(p)∆= expiration de groupé

∧ etat [p] = �groupe�∧ netw !Di�user(p, [type 7→ �D�, emetteur 7→ p])∧ etat ′ = [etat except ![p] = �decouverte� ]∧ voisins ′ = [voisins except ![p] = {p}]∧ voisinages ′ = [voisinages except ![p] = [q ∈ Proc 7→ {}]]∧ supporters ′ = [supporters except ![p] = {}]∧ vueInstallee ′ = [vueInstallee except ![p] = {}]

Next∆=∨ netw !NextAvecPerte∧ unchanged 〈etat , voisins, voisinages, supporters, vueInstallee〉∨ ∃ p ∈ Proc : ∃m ∈ Message : SingletonDecouverte(p, m)∨ ∃ p ∈ Proc : ∃m ∈ Message : SingletonIgnore(p, m)∨ ∃ p ∈ Proc : SingletonExpiration(p)∨ ∃ p ∈ Proc : ∃m ∈ Message : DecouverteDecouverte(p, m)∨ ∃ p ∈ Proc : ∃m ∈ Message : DecouverteJonction(p, m)∨ ∃ p ∈ Proc : ∃m ∈ Message : DecouverteIgnore(p, m)∨ ∃ p ∈ Proc : DecouverteExpiration(p)∨ ∃ p ∈ Proc : ∃m ∈ Message : ConstitutionJonction(p, m)∨ ∃ p ∈ Proc : ∃m ∈ Message : ConstitutionInclusion(p, m)∨ ∃ p ∈ Proc : ∃m ∈ Message : ConstitutionIgnore(p, m)∨ ∃ p ∈ Proc : ConstitutionExpiration(p)∨ ∃ p ∈ Proc : ∃m ∈ Message : ExpectatifInclusion(p, m)∨ ∃ p ∈ Proc : ∃m ∈ Message : ExpectatifIgnore(p, m)∨ ∃ p ∈ Proc : ExpectatifExpiration(p)∨ ∃ p ∈ Proc : ∃m ∈ Message : GroupeInclusion(p, m)∨ ∃ p ∈ Proc : ∃m ∈ Message : GroupeIgnore(p, m)∨ ∃ p ∈ Proc : GroupeExpiration(p)

Spec∆=∧ Init∧ 2[Next ]〈etat, voisins, voisinages, supporters, vueInstallee,net〉

A.2 Modélisation d'un réseau asynchrone non �able

module reseauAsync

Réseau asynchrone avec ou sans pertes.

extends Naturals, Bags

constant Id ,Message

variables

network

131

Modélisation d'un réseau synchrone avec écrasement

TypeInvariant∆=

∧ IsABag(network)∧ domain (network) ⊆ Id ×Message

Init∆=

network = EmptyBag

Émission vers un ensemble de sites.

local Transmission(id , S , m)∆=

network ′ = network ⊕ SetToBag(S × {m})

Émission point-à-point vers un site (pas soi-même).

Emettre(id , dest , m)∆= Transmission(id , {dest} \ {id}, m)

Émission en di�usion vers tous les sites (sauf soi-même).

Di�user(id , m)∆= Transmission(id , Id \ {id}, m)

Réception d'un message.

Recevoir(id , m)∆=

∧ BagIn(〈id , m〉, network)∧ network ′ = network SetToBag({〈id , m〉})

Réception d'un message + émission vers un ensemble de destinataires.

Etape(id , mr , S , ms)∆=

∧ BagIn(〈id , mr〉, network)∧ network ′ = network SetToBag({〈id , mr〉})⊕ SetToBag((S \ {id})× {ms})

Y a-t-il des messages en attente pour S ?

IsEmpty(S)∆=

∀ i ∈ S : ∀m ∈ Message : ¬BagIn (〈i , m〉, network)BagToSet(network) ∩ (S ×Message) = {}

NbMessagesEnAttente∆=

BagCardinality(network)

NextAvecPerte∆=

∃ 〈id , m〉 ∈ BagToSet(network) :

∧ network ′ = network SetToBag({〈id , m〉})

NextSansPerte∆= unchanged 〈network〉

A.3 Modélisation d'un réseau synchrone avec écrasement

module reseauValeur

Réseau synchrone de taille 1 avec écrasement.

extends Naturals

constants Id ,

Message

variables

network

132


TypeInvariant∆=

∧ network ∈ (subset Id)×Message

Init∆=network = 〈{}, (choose m ∈ Message : true)〉

Émission vers un ensemble de sites.local Transmission(id , S , m)

∆=

network ′ = 〈S , m〉

Émission point-à-point vers un site (pas soi-même).Emettre(id , dest , m)

∆= Transmission(id , {dest} \ {id}, m)

Émission en di�usion vers tous les sites (sauf soi-même).Di�user(id , m)

∆= Transmission(id , Id \ {id}, m)

Réception d'un message.Recevoir(id , m)

∆=

∧ id ∈ network [1]∧m = network [2]∧ network ′ = [network except ![1] = @ \ {id}]

Réception d'un message + émission vers un ensemble de destinaires.À n'utiliser qu'avec prudence dans cette modélisation.

Etape(id , mr , S , ms)∆=

∧ id ∈ network [1]∧mr = network [2]∧ network ′ = 〈S , ms〉

Y a-t-il des messages en attente pour S ?

IsEmpty(S)∆=

∧ S ∩ network [1] = {}

NbMessagesEnAttente∆=

if network [1] = {} then 0 else 1

NextSansPerte∆= unchanged 〈network〉

NextAvecPerte∆= unchanged 〈network〉

133

Annexe B

Association cohérente de données �

modèles TLA+

B.1 Module commun

module Common

extends Naturals

constant N nb de sites

Site∆= 1 . . N

NoEvent∆= 0 l'absence d'événement interne au départ

Event∆= Nat \ {NoEvent} événements internes

InitEvent∆= 1 l'événement initial

assume NoEvent /∈ Event

assume InitEvent ∈ Event

Codomain(f )∆= {f [x ] : x ∈ domain f }

Extension/modi�cation de la fonction f avec ajout éventuel de l'indice i .C'est la version correcte de [f except ![i ] = v ] pour le cas où i /∈ domain f .

extend(f , i , v)∆= [a ∈ domain f ∪ {i} 7→ if a = i then v else f [a]]

B.2 Module passé d'in�uence

module In�uence

Gestion du passé d 'in�uence. L'In�uence est un ensemble d ′événements.Chaque événement interne possède un passé d 'In�uence mis à jour lors de sa création.

extends Naturals, Common

In�uence∆= subset Event

variables

irecus, ∈ [ Site → Site → Event ∪ {NoEvent} ] � derniers évts internes dont le site dépend

135

Module d'estampillage

in�uence ∈ [ Event → In�uence ] � passé d'in�uence

TypeInvariant∆=

∧ irecus ∈ [Site → [Site → Event ∪ {NoEvent}]]∧ domain in�uence ∈ subset (Event ∪ {NoEvent})∧ Codomain(in�uence) ⊆ subset Event

On démarre avec l ′événement initial sur le site 1Init

∆=

∧ in�uence = [s ∈ {NoEvent , InitEvent} 7→ if s = NoEvent then {} else {InitEvent}]∧ irecus = [from ∈ Site 7→ [to ∈ Site 7→ NoEvent ]]

Charge utile pour l ′événement ev d'envoi d'un message : l ′événement lui-même.load(ev)

∆= ev

envoyer(ev)∆=

∧ unchanged 〈irecus, in�uence〉

Réception d'un contenurecevoir(from, to, l)

∆=

∧ irecus ′ = [irecus except ! [to] = [@ except ! [from] = l ]]∧ unchanged 〈in�uence〉

Événement interne ev sur le site s, avec calcul de l 'in�uence de cet événement : lui-même plus l 'union desin�uences des derniers messages reçus.

internal(s, ev)∆=

∧ s ∈ Site

∧ in�uence ′ = extend(in�uence, ev ,{ev} ∪ union {in�uence[irecus[s][ss]] : ss ∈ Site})

∧ unchanged 〈irecus〉

B.3 Module d'estampillage

module Estampillage

Application des règles d'estampillage.Une Estampille est un ensemble de Marquages. La charge d'un message envoyé est l 'estampille du dernierévénement interne sur ce site. À la réception, on ne garde que le dernier message provenant d'un site donné.L'estampille d'un évt interne est l 'union des estampilles des messages reçus + soi-même.


Marquage∆= [site : Site, val : Nat ]

Estampille∆= subset Marquage

variables

erecus, ∈ [ Site → Site → Estampillage ] � dernière estampille reçuehorloge, ∈ [ Site → Nat ] � horloge de datationestampille ∈ [ Event → Estampille ] � codage de l 'in�uence

TypeInvariant∆=

∧ erecus ∈ [Site → [Site → Estampille]]∧ horloge ∈ [Site → Nat ]∧ domain estampille ∈ subset Event

∧ Codomain(estampille) ∈ subset Estampille

136

Annexe B - Association cohérente de données � modèles TLA+

On démarre avec l ′événement initial sur le site 1Init

∆=

∧ erecus = [from ∈ Site 7→ [to ∈ Site 7→ {}]]∧ horloge = [s ∈ Site 7→ if s = 1 then 1 else 0]∧ estampille = [s ∈ {InitEvent} 7→ {[site 7→ 1, val 7→ horloge[1]]}]

Charge utile pour l ′événement ev d'envoi d'un message : l 'estampille de cet événement.load(ev)

∆= estampille[ev ]

envoyer(ev)∆=

∧ unchanged 〈erecus, estampille, horloge〉

Réception d'un message mrecevoir(from, to, l)

∆=

∧ erecus ′ = [erecus except ![to] = [@ except ![from] = l ]]∧ unchanged 〈horloge, estampille〉

Événement interne ev sur le site s, avec calcul de l 'estampille de cet événement : son marquage unionles estampilles des derniers messages reçus. En outre, l 'horloge est incrémentée.

internal(s, ev)∆=

∧ s ∈ Site

∧ estampille ′ = extend(estampille, ev ,{[site 7→ s, val 7→ horloge[s]]} ∪ union {erecus[s][ss] : ss ∈ Site})

∧ horloge ′ = [horloge except ![s] = @ + 1]∧ unchanged 〈erecus〉

B.4 Modules de modélisation d'un calcul

B.4.1 Module calcul asynchrone

module CalculAsync

Calcul asynchrone (envoi/réception/événement interne indépendant) avec communication �able mais non or-donnée (pas nécessairement �fo).Le calcul débute sur un seul site par InitEvent . Les autres sites deviennent actifs sur réception d'un message.Chaque message transporte une charge utile (ou rien).


constant Load , NoLoad la charge utile des messages

Message∆= [from : Site, to : Site, load : Load ]

NoMessage∆= [from 7→ 0, to 7→ 0, load 7→ NoLoad ]

assume NoMessage /∈ Message

variables

nextevent , ∈ Event � numérotation des événements internesmessages, ∈ subset Message � messages en transitinterne ∈ [ Site → Event ∪ {NoEvent} ] � dernier événement interne

TypeInvariant∆=

∧ nextevent ∈ Event

∧ interne ∈ [Site → Event ∪ {NoEvent}]∧messages ∈ subset Message

137

Modules de modélisation d'un calcul

On démarre avec l ′événement initial sur le site 1 et aucun message en transit.

Init∆=

∧ nextevent = InitEvent + 1∧ interne = [s ∈ Site 7→ if s = 1 then InitEvent else NoEvent ]∧messages = {}

Envoi d'un message du site from vers le site to.

envoyer(from, to, load)∆=

∧ from ∈ Site

∧ to ∈ Site

∧ from 6= to

∧ interne[from] 6= NoEvent

∧messages ′ = messages ∪ {[from 7→ from, to 7→ to, load 7→ load ]}∧ unchanged 〈nextevent , interne〉

Quels sont les messages délivrables parmi ceux en transit : Tous.

messagesDelivrables∆= messages

Réception d'un message parmi ceux délivrables

recevoir(m)∆=

∧m ∈ messagesDelivrables

∧messages ′ = messages \ {m}∧ unchanged 〈nextevent , interne〉

Événement interne sur le site s

internal(s)∆=

∧ s ∈ Site

∧ interne[s] 6= NoEvent

∧ nextevent ′ = nextevent + 1∧ interne ′ = [interne except ![s] = nextevent ]∧ unchanged 〈messages〉

B.4.2 Module calcul synchrone

module CalculSync

Calcul assez synchrone avec communication �able synchrone :- Un site qui émet ne peut rien faire d'autre tant que le message n'a pas été délivré ;- Un site pour lequel il existe un message à sa destination ne peut rien faire d'autre que le recevoir ;- Une seule communication peut avoir lieu simultanément ;- par contre, un site non concerné par la communication peut faire un (ou des) pas internes.Le calcul débute sur un seul site par InitEvent . Les autres sites deviennent actifs sur réception d'un message.Chaque message transporte une charge utile (ou rien).


constant Load , NoLoad la charge utile des messages

Message∆= [from : Site, to : Site, load : Load ]

NoMessage∆= [from 7→ 0, to 7→ 0, load 7→ NoLoad ]

assume NoMessage /∈ Message

variables

nextevent , ∈ Event � numérotation des événements internes

138

Annexe B - Association cohérente de données � modèles TLA+

messages, ∈ Message ∪ {NoMessage} � le message en transitinterne ∈ [ Site → Event ∪ {NoEvent} ] � dernier événement interne

TypeInvariant∆=

∧ nextevent ∈ Event

∧ interne ∈ [Site → Event ∪ {NoEvent}]∧messages ∈ Message ∪ {NoMessage}

On démarre avec l ′événement initial sur le site 1 et aucun message en transit.Init

∆=

∧ nextevent = InitEvent + 1∧ interne = [s ∈ Site 7→ if s = 1 then InitEvent else NoEvent ]∧messages = NoMessage

Envoi d'un message du site from vers le site toenvoyer(from, to, load)

∆=

∧ from ∈ Site

∧ to ∈ Site

∧ from 6= to

∧ interne[from] 6= NoEvent

∧messages = NoMessage

∧messages ′ = [from 7→ from, to 7→ to, load 7→ load ]∧ unchanged 〈nextevent , interne〉

Quels sont les messages délivrables parmi ceux en transit : le seul qu'il y a.messagesDelivrables

∆= if messages 6= NoMessage then {messages} else {}

Réception d'un message parmi ceux délivrablesrecevoir(m)

∆=

∧m = messages

∧messages ′ = NoMessage

∧ unchanged 〈nextevent , interne〉

Événement interne sur le site s, à condition qu'il ne soit pas en train d ′émettre ni de recevoirinternal(s)

∆=

∧ s ∈ Site

∧ interne[s] 6= NoEvent

∧messages = NoMessage ∨messages.from 6= s

∧messages = NoMessage ∨messages.to 6= s

∧ nextevent ′ = nextevent + 1∧ interne ′ = [interne except ![s] = nextevent ]∧ unchanged 〈messages〉

B.5 Module de véri�cation

module Verif

Module de véri�cation que l'estampillage est un codage exact de l'in�uence. On fait évoluer en parallèle in�uenceet estampillage, et on véri�e que la propriété �être in�uencé par� est équivalente à l'inclusion des estampilles.


variables

nextevent , messages, interne,

139

Module de véri�cation

erecus, horloge, estampille,irecus, in�uence

Estampillage∆= instance Estampillage

In�uence∆= instance In�uence

Le calcul générique, avec comme charge utile des messages un couple événement interne précédent l'envoi /estampille correspondante

Calcul∆= instance CalculSync

with Load ← 〈Event , Estampillage!Estampille〉,NoLoad ← 〈NoEvent , {}〉

TypeInvariant∆=

∧ Calcul !TypeInvariant∧ In�uence!TypeInvariant∧ Estampillage!TypeInvariant

EstampilleEgaleIn�uence∆=

∀ e1, e2 ∈ {interne[s] : s ∈ Site} \ {NoEvent} :(e1 ∈ in�uence[e2]) = (estampille[e1] ⊆ estampille[e2])

Init∆=

∧ Calcul !Init∧ In�uence!Init∧ Estampillage!Init

Envoi d'un message du site from vers le site toenvoyer(from, to)

∆=

∧ Calcul !envoyer(from, to, 〈In�uence!load(interne[from]), Estampillage!load(interne[from])〉)∧ In�uence!envoyer(interne[from])∧ Estampillage!envoyer(interne[from])

Réception d'un message parmi ceux délivrablesrecevoir(m)

∆=

∧ Calcul !recevoir(m)∧ In�uence!recevoir(m.from, m.to, m.load [1])∧ Estampillage!recevoir(m.from, m.to, m.load [2])

Événement interne sur le site sinternal(s)

∆=

∧ Calcul !internal(s)∧ In�uence!internal(s, nextevent)∧ Estampillage!internal(s, nextevent)

Next∆=

∨ ∃ f , t ∈ Site : envoyer(f , t)∨ ∃m ∈ Calcul !messagesDelivrables : recevoir(m)∨ ∃ s ∈ Site : internal(s)

Spec∆= Init ∧ 2[Next ]〈nextevent, interne,messages, irecus, in�uence, erecus, horloge, estampille〉

140

Annexe C

Algorithmes non bloquants �

modèles PlusCal et TLA+

Les modèles ont été écrits en PlusCal, langage algorithmique se traduisant en TLA+ [Lam09].

C.1 Splitter

C.1.1 Dé�nition

<= 1 processus

down

stop

<= x−1 processus

right

x processus

<= x−1 processus

(d'après [MA95])� x (indéterminé) processus appellent concurremment (ou pas) le splitter ;� au plus un processus termine avec stop ;� si x = 1, le processus termine avec stop ;� au plus (x − 1) processus terminent avec right ;� au plus (x − 1) processus terminent avec down.

Hypothèses Les variables partagées sont des � Registres � :� Lectures et écritures atomiques� Pas d'interférence due aux caches en multi-processeurs

Implantation non bloquante Deux � registres � partagés : X (init ∀) et Y (init faux)

141

Splitter

Chaque processus a un identi�ant unique idi .

direction(idi)X ← idi ;if Y then diri ← right ;else Y ← true;

if (X = idi) then diri ← stop;else diri ← down; endif

endifreturn diri ;

C.1.2 Modèle plusCal/TLA+

module splitter

Résultats selon le nombre de processusNP = 2 : ok 176 distinct states / depth 15NP = 3 : ok 3444 distinct states / depth 22NP = 4 : ok 59056 distinct states / depth 29NP = 5 : ok 920980 distinct states / depth 36NP = 6 : ok 13475976 distinct states / depth 43NP = 7 : ok 188718572 distinct states / depth 50

extends Naturals, FiniteSets, TLC , Sequences

constant NP nombre de processus

None∆= �none�

Right∆= �right�

Stop∆= �stop�

Down∆= �down�

Directions∆= {None, Right , Stop, Down}

�algorithm splitteralgvariables X ∈ ProcSet ; Y = false ; rval = [ i ∈ ProcSet 7→ None ] ;

procedure splitter() begin spl0 :X := self ;

spl1: if Y thenspl2 : rval [self ] := Right ;

elsespl3 : Y := true ;spl4 : if (X = self ) thenspl5 : rval [self ] := Stop ; elsespl6 : rval [self ] := Down ; end if ;

end if ;spl7: return ;end procedure ;

process Proc ∈ 0 . . NP − 1 beginstart : call splitter() ;end process

end algorithm

BEGIN TRANSLATION

variables X , Y , rval , pc, stack

142

Annexe C - Algorithmes non bloquants � modèles PlusCal et TLA+

vars∆= 〈X , Y , rval , pc, stack〉

ProcSet∆= (0 . . NP − 1)

Init∆= Global variables∧X ∈ ProcSet

∧Y = false

∧ rval = [i ∈ ProcSet 7→ None]∧ stack = [self ∈ ProcSet 7→ 〈〉]∧ pc = [self ∈ ProcSet 7→ case self ∈ 0 . . NP − 1→ �start�]

spl0(self )∆= ∧ pc[self ] = �spl0�

∧X ′ = self

∧ pc′ = [pc except ! [self ] = �spl1�]∧ unchanged 〈Y , rval , stack〉


∧ if Y

then ∧ pc′ = [pc except ! [self ] = �spl2�]else ∧ pc′ = [pc except ! [self ] = �spl3�]

∧ unchanged 〈X , Y , rval , stack〉


∧ rval ′ = [rval except ! [self ] = Right ]∧ pc′ = [pc except ! [self ] = �spl7�]∧ unchanged 〈X , Y , stack〉


∧Y ′ = true

∧ pc′ = [pc except ! [self ] = �spl4�]∧ unchanged 〈X , rval , stack〉


∧ if (X = self )then ∧ pc′ = [pc except ! [self ] = �spl5�]else ∧ pc′ = [pc except ! [self ] = �spl6�]

∧ unchanged 〈X , Y , rval , stack〉


∧ rval ′ = [rval except ! [self ] = Stop]∧ pc′ = [pc except ! [self ] = �spl7�]∧ unchanged 〈X , Y , stack〉


∧ rval ′ = [rval except ! [self ] = Down]∧ pc′ = [pc except ! [self ] = �spl7�]∧ unchanged 〈X , Y , stack〉


∧ pc′ = [pc except ! [self ] = Head(stack [self ]).pc]∧ stack ′ = [stack except ! [self ] = Tail(stack [self ])]∧ unchanged 〈X , Y , rval〉

splitter(self )∆= spl0(self ) ∨ spl1(self ) ∨ spl2(self ) ∨ spl3(self )

∨ spl4(self ) ∨ spl5(self ) ∨ spl6(self ) ∨ spl7(self )

start(self )∆= ∧ pc[self ] = �start�

143

Liste chaînée

∧ stack ′ = [stack except ! [self ] = 〈[procedure 7→ �splitter�,pc 7→ �Done�]〉◦ stack [self ]]

∧ pc′ = [pc except ! [self ] = �spl0�]∧ unchanged 〈X , Y , rval〉

Proc(self )∆= start(self )

Next∆= (∃ self ∈ ProcSet : splitter(self ))

∨ (∃ self ∈ 0 . . NP − 1 : Proc(self ))∨ Disjunct to prevent deadlock on termination

((∀ self ∈ ProcSet : pc[self ] = �Done�) ∧ unchanged vars)

Spec∆= Init ∧ 2[Next ]vars

Termination∆= 3(∀ self ∈ ProcSet : pc[self ] = �Done�)

END TRANSLATION

TypeInvariant∆=

∧X ∈ ProcSet

∧Y ∈ boolean∧ rval ∈ [ProcSet → Directions]

Splittage∆=

∧ Cardinality({i ∈ ProcSet : rval [i ] = Stop}) ≤ 1∧ Cardinality({i ∈ ProcSet : rval [i ] = Down}) < NP

∧ Cardinality({i ∈ ProcSet : rval [i ] = Right}) < NP

Coherence∆=

Splittage

theorem

Spec ⇒ 2TypeInvariant

Spec ⇒ 2Coherence

C.2 Liste chaînée

C.2.1 Dé�nition

(d'après [MS96])

Hypothèses� Lectures et écritures atomiques (� registres �)� Pas d'interférence due aux caches en multi-processeurs� Une instruction atomique évoluée : CAS (compare-and-set) :

boolean CAS(*add, old, new) {

atomically {

if (*add == old ) then

*add = new;

return true;

else

return false;

144


endif

}

}

En�ler non bloquant

N÷ud<T> n = new N÷ud<T>;

n.item = item;

loop

N÷ud<T> lqueue = queue;

N÷ud<T> lsuiv = lqueue.suiv;

if lqueue == queue then -- lqueue et lsuiv cohérents ?

if lsuiv == null then -- queue vraiment dernier ?

if CAS(lqueue.suiv, lsuiv, n) -- essai lien nouveau n÷ud

break; -- succès !

endif

else -- queue n'était pas le dernier n÷ud

CAS(queue, lqueue, lsuiv); -- essai m-à-j queue

endif

endif

endloop

CAS(queue, lqueue, n); -- insertion réussie, essai m-à-j queue

Dé�ler non bloquant

loop

N÷ud<T> ltête = tête; N÷ud<T> lqueue = queue;

N÷ud<T> lsuiv = ltête.suiv;

if ltête == tête then -- lqueue, ltête, lsuiv cohérents ?

if ltête == lqueue then -- file vide ou queue à la traîne ?

if (lsuiv == null) then

return null; -- file vide

endif

CAS(queue, lqueue, lsuiv); -- essai m-à-j queue

else

res = lsuiv.item;

if CAS(tête, ltête, lsuiv) then -- essai m-à-j tête

break; -- succès !

endif

endif

endif

endloop -- sinon (queue ou tête à la traîne) on recommence

return res;

C.2.2 Modèle plusCal/TLA+

module linkedlist

La modélisation est simple mais elle n'est pas performante : elle décrit directement la liste en terme de cellulesmémoire et pointeurs. Algorithmiquement, c'est très proche du code réel.

NP = 1, NC = 4⇒ ok

NP = 2, NC = 2 sans gc ⇒ échec A-B-A : P1 en�ler ⇒ avant enf 9 P2 dé�ler en deux itérations− la première def 5,def 6,def 7 installe correctement queue (coopérativement)− la deuxième def 5,def 8 libère

145

Liste chaînée

P2 en�ler complet, utilise la cellule libérée P1 enf 9 CAS réussit à tort.NP = 2, NC = 4 sans gc ⇒ échec (A-B-A)NP = 3, NC = 3 sans gc ⇒ échec (A-B-A)

NP = 2, NC = 2 avec gc ⇒ ok 2604 distinct states found / depth 62NP = 2, NC = 3 avec gc ⇒ ok 47742 distinct states found / depth 102NP = 2, NC = 4 avec gc ⇒ ok 885854 distinct states / depth 142NP = 2, NC = 5 avec gc ⇒ ok 17893392 distinct states / depth 182

NP = 3, NC = 2 avec gc ⇒ ok 89350 distinct states / depth 75NP = 3, NC = 3 avec gc ⇒ ok 2836462 distinct states / depth 115NP = 3, NC = 4 avec gc ⇒ ok 77530850 distinct states / depth 155NP = 3, NC = 5 avec gc ⇒ interrompu après 24h et 339012966 états distincts

NP = 4, NC = 2 avec gc ⇒ ok 3267096 distinct states / depth 88NP = 4, NC = 3 avec gc ⇒ ok 186389920 distinct states / depth 128NP = 4, NC = 4 avec gc ⇒ plantage de tlc à 323399206 states

extends Naturals, TLC , Sequences

constant NP , nombre de processus

NC nombre de cellules

AdressesValides∆= 1 . . NC

Adresses∆= {0} ∪AdressesValides

CelluleInitiale∆= choose i ∈ AdressesValides : true

�algorithm waitfreealg

variables \ * les variables globales décrivant la liste

queue = CelluleInitiale ; tete = CelluleInitiale ;

memoire = [ i ∈ AdressesValides 7→ 0 ] ;

libre = AdressesValides \ {CelluleInitiale} ; \ * les cellules disponibles

garbage = {} ; \ * ramasse-miette

de�ne \ * la liste sous forme d'une séquence d'adressesLaListe

∆=

let build [addr ∈ Adresses]∆=

if addr = 0 then 〈〉else 〈addr〉 ◦ build [memoire[addr ]]

in build [tete]

\ * la liste sous forme d'un ensemble d'adressesLesElements

∆= let l

∆= LaListe in {l [i ] : i ∈ domain l}

end de�ne

procedure en�ler(nouv) variable lqueue, lsuiv ; begin enf 0 :memoire[nouv ] := 0 ;

enf 1: while true dolqueue := queue ;

enf 2 : lsuiv := memoire[lqueue] ;enf 3 : if (lqueue = queue) thenenf 4 : if (lsuiv = 0) thenenf 5 : if (memoire[lqueue] = lsuiv) then memoire[lqueue] := nouv ; goto enf 9 ;

end if ;else

enf 6 : if (queue = lqueue) then queue := lsuiv ; \ * CAS

146


end if ;end if

end ifend while ;

enf 9 : if (queue = lqueue) thenqueue := nouv ; \ * CAS

end if ; return ;end procedure ;

procedure de�ler() variable lqueue, ltete, lsuiv ; begin def 0 :while true do

def 1 : ltete := tete ;def 2 : lqueue := queue ;def 3 : lsuiv := memoire[ltete] ;def 4: if (ltete = tete) then def 5 : if (ltete = lqueue) then

def 6 : if (lsuiv = 0) then return ; \ * �le videend if ;

def 7 : if (queue = lqueue) then queue := lsuiv ; \ * CASend if ;

elsedef 8 : if (tete = ltete) then \ * CAS

\ * libre := libre ∪ {tete} ; \ * ABA problemgarbage := garbage ∪ {tete} ; tete := lsuiv ; return ;

end if ;end if ;

end if ;end while ; return ; \ * notreached

end procedure ;

process Proc ∈ 0 . . NP − 1 beginml : while true doout : with b ∈ {�de�ler� , �en�ler�} do

if (b = �de�ler�) then call de�ler() ; elsif (libre 6= {}) thenwith nv ∈ libre do libre := libre \ {nv} ; call en�ler(nv) ;end with ;

end if ;end with ;

dogc: if (∀ i ∈ ProcSet : pc[i ] ∈ {�out� , �dogc�}) thenlibre := libre ∪ garbage ; garbage := {} ;

end if ;end while ;

end process

end algorithm

BEGIN TRANSLATION

constant defaultInitValue

variables queue, tete, memoire, libre, garbage, pc, stack

de�ne statement

LaListe∆=

let build [addr ∈ Adresses]∆=

if addr = 0 then 〈〉else 〈addr〉 ◦ build [memoire[addr ]]

in build [tete]

147

Liste chaînée

LesElements∆= let l

∆= LaListein {l [i ] : i ∈ domain l}

variables nouv , lqueue , lsuiv , lqueue, ltete, lsuiv

vars∆= 〈queue, tete, memoire, libre, garbage, pc, stack , nouv , lqueue ,

lsuiv , lqueue, ltete, lsuiv〉

ProcSet∆= (0 . . NP − 1)

Init∆= Global variables∧ queue = CelluleInitiale

∧ tete = CelluleInitiale

∧memoire = [i ∈ AdressesValides 7→ 0]∧ libre = AdressesValides \ {CelluleInitiale}∧ garbage = {}Procedure en�ler∧ nouv = [self ∈ ProcSet 7→ defaultInitValue]∧ lqueue = [self ∈ ProcSet 7→ defaultInitValue]∧ lsuiv = [self ∈ ProcSet 7→ defaultInitValue]Procedure de�ler∧ lqueue = [self ∈ ProcSet 7→ defaultInitValue]∧ ltete = [self ∈ ProcSet 7→ defaultInitValue]∧ lsuiv = [self ∈ ProcSet 7→ defaultInitValue]∧ stack = [self ∈ ProcSet 7→ 〈〉]∧ pc = [self ∈ ProcSet 7→ case self ∈ 0 . . NP − 1→ �ml�]

enf 0(self )∆= ∧ pc[self ] = �enf0�

∧memoire ′ = [memoire except ! [nouv [self ]] = 0]∧ pc′ = [pc except ! [self ] = �enf1�]∧ unchanged 〈queue, tete, libre, garbage, stack , nouv ,

lqueue , lsuiv , lqueue, ltete, lsuiv〉


∧ lqueue ′ = [lqueue except ! [self ] = queue]∧ pc′ = [pc except ! [self ] = �enf2�]∧ unchanged 〈queue, tete, memoire, libre, garbage, stack ,

nouv , lsuiv , lqueue, ltete, lsuiv〉


∧ lsuiv ′ = [lsuiv except ! [self ] = memoire[lqueue [self ]]]∧ pc′ = [pc except ! [self ] = �enf3�]∧ unchanged 〈queue, tete, memoire, libre, garbage, stack ,

nouv , lqueue , lqueue, ltete, lsuiv〉


∧ if (lqueue [self ] = queue)then ∧ pc′ = [pc except ! [self ] = �enf4�]else ∧ pc′ = [pc except ! [self ] = �enf1�]

∧ unchanged 〈queue, tete, memoire, libre, garbage, stack ,nouv , lqueue , lsuiv , lqueue, ltete, lsuiv〉


∧ if (lsuiv [self ] = 0)then ∧ pc′ = [pc except ! [self ] = �enf5�]else ∧ pc′ = [pc except ! [self ] = �enf6�]

∧ unchanged 〈queue, tete, memoire, libre, garbage, stack ,

148


nouv , lqueue , lsuiv , lqueue, ltete, lsuiv〉


∧ if (memoire[lqueue [self ]] = lsuiv [self ])then ∧memoire ′ = [memoire except ! [lqueue [self ]] = nouv [self ]]

∧ pc′ = [pc except ! [self ] = �enf9�]else ∧ pc′ = [pc except ! [self ] = �enf1�]

∧ unchanged memoire

∧ unchanged 〈queue, tete, libre, garbage, stack , nouv ,lqueue , lsuiv , lqueue, ltete, lsuiv〉


∧ if (queue = lqueue [self ])then ∧ queue ′ = lsuiv [self ]else ∧ true

∧ unchanged queue

∧ pc′ = [pc except ! [self ] = �enf1�]∧ unchanged 〈tete, memoire, libre, garbage, stack , nouv ,



∧ if (queue = lqueue [self ])then ∧ queue ′ = nouv [self ]else ∧ true

∧ unchanged queue

∧ pc′ = [pc except ! [self ] = Head(stack [self ]).pc]∧ lqueue ′ = [lqueue except ! [self ] = Head(stack [self ]).lqueue ]∧ lsuiv ′ = [lsuiv except ! [self ] = Head(stack [self ]).lsuiv ]∧ nouv ′ = [nouv except ! [self ] = Head(stack [self ]).nouv ]∧ stack ′ = [stack except ! [self ] = Tail(stack [self ])]∧ unchanged 〈tete, memoire, libre, garbage, lqueue, ltete,

lsuiv〉

en�ler(self )∆= enf 0(self ) ∨ enf 1(self ) ∨ enf 2(self ) ∨ enf 3(self )

∨ enf 4(self ) ∨ enf 5(self ) ∨ enf 6(self ) ∨ enf 9(self )

def 0(self )∆= ∧ pc[self ] = �def0�

∧ pc′ = [pc except ! [self ] = �def1�]∧ unchanged 〈queue, tete, memoire, libre, garbage, stack ,

nouv , lqueue , lsuiv , lqueue, ltete, lsuiv〉


∧ ltete ′ = [ltete except ! [self ] = tete]∧ pc′ = [pc except ! [self ] = �def2�]∧ unchanged 〈queue, tete, memoire, libre, garbage, stack ,

nouv , lqueue , lsuiv , lqueue, lsuiv〉


∧ lqueue ′ = [lqueue except ! [self ] = queue]∧ pc′ = [pc except ! [self ] = �def3�]∧ unchanged 〈queue, tete, memoire, libre, garbage, stack ,

nouv , lqueue , lsuiv , ltete, lsuiv〉


∧ lsuiv ′ = [lsuiv except ! [self ] = memoire[ltete[self ]]]∧ pc′ = [pc except ! [self ] = �def4�]

149

Liste chaînée

∧ unchanged 〈queue, tete, memoire, libre, garbage, stack ,nouv , lqueue , lsuiv , lqueue, ltete〉


∧ if (ltete[self ] = tete)then ∧ pc′ = [pc except ! [self ] = �def5�]else ∧ pc′ = [pc except ! [self ] = �def0�]



∧ if (ltete[self ] = lqueue[self ])then ∧ pc′ = [pc except ! [self ] = �def6�]else ∧ pc′ = [pc except ! [self ] = �def8�]



∧ if (lsuiv [self ] = 0)then ∧ pc′ = [pc except ! [self ] = Head(stack [self ]).pc]

∧ lqueue ′ = [lqueue except! [self ] = Head(stack [self ]).lqueue]

∧ ltete ′ = [ltete except! [self ] = Head(stack [self ]).ltete]

∧ lsuiv ′ = [lsuiv except

! [self ] = Head(stack [self ]).lsuiv ]∧ stack ′ = [stack except

! [self ] = Tail(stack [self ])]else ∧ pc′ = [pc except ! [self ] = �def7�]

∧ unchanged 〈stack , lqueue, ltete, lsuiv〉∧ unchanged 〈queue, tete, memoire, libre, garbage, nouv ,

lqueue , lsuiv 〉


∧ if (queue = lqueue[self ])then ∧ queue ′ = lsuiv [self ]else ∧ true

∧ unchanged queue

∧ pc′ = [pc except ! [self ] = �def0�]∧ unchanged 〈tete, memoire, libre, garbage, stack , nouv ,



∧ if (tete = ltete[self ])then ∧ garbage ′ = garbage ∪ {tete}

∧ tete ′ = lsuiv [self ]∧ pc′ = [pc except ! [self ] = Head(stack [self ]).pc]∧ lqueue ′ = [lqueue except

! [self ] = Head(stack [self ]).lqueue]∧ ltete ′ = [ltete except

! [self ] = Head(stack [self ]).ltete]∧ lsuiv ′ = [lsuiv except

! [self ] = Head(stack [self ]).lsuiv ]∧ stack ′ = [stack except

! [self ] = Tail(stack [self ])]

150


else ∧ pc′ = [pc except ! [self ] = �def0�]∧ unchanged 〈tete, garbage, stack , lqueue, ltete,

lsuiv〉∧ unchanged 〈queue, memoire, libre, nouv , lqueue , lsuiv 〉

de�ler(self )∆= def 0(self ) ∨ def 1(self ) ∨ def 2(self ) ∨ def 3(self )

∨ def 4(self ) ∨ def 5(self ) ∨ def 6(self ) ∨ def 7(self )∨ def 8(self )

ml(self )∆= ∧ pc[self ] = �ml�

∧ pc′ = [pc except ! [self ] = �out�]∧ unchanged 〈queue, tete, memoire, libre, garbage, stack , nouv ,


out(self )∆= ∧ pc[self ] = �out�

∧ ∃ b ∈ {�de�ler�, �en�ler�} :if (b = �de�ler�)

then ∧ stack ′ = [stack except

! [self ] = 〈[procedure 7→ �de�ler�,pc 7→ �dogc�,lqueue 7→ lqueue[self ],ltete 7→ ltete[self ],lsuiv 7→ lsuiv [self ]]〉◦ stack [self ]]

∧ lqueue ′ = [lqueue except! [self ] = defaultInitValue]

∧ ltete ′ = [ltete except! [self ] = defaultInitValue]

∧ lsuiv ′ = [lsuiv except

! [self ] = defaultInitValue]∧ pc′ = [pc except

! [self ] = �def0�]∧ unchanged 〈libre, nouv , lqueue , lsuiv 〉

else ∧ if (libre 6= {})then ∧ ∃nv ∈ libre :

∧ libre ′ = libre \ {nv}∧ ∧ nouv ′ = [nouv except

! [self ] = nv ]∧ stack ′ = [stack except

! [self ] = 〈[procedure 7→ �en�ler�,pc 7→ �dogc�,lqueue 7→ lqueue [self ],lsuiv 7→ lsuiv [self ],nouv 7→ nouv [self ]]〉◦ stack [self ]]

∧ lqueue ′ = [lqueue except

! [self ] = defaultInitValue]∧ lsuiv ′ = [lsuiv except

! [self ] = defaultInitValue]∧ pc′ = [pc except

! [self ] = �enf0�]else ∧ pc′ = [pc except

! [self ] = �dogc�]∧ unchanged 〈libre, stack , nouv ,

151

Liste chaînée

lqueue , lsuiv 〉∧ unchanged 〈lqueue, ltete, lsuiv〉

∧ unchanged 〈queue, tete, memoire, garbage〉

dogc(self )∆= ∧ pc[self ] = �dogc�

∧ if (∀ i ∈ ProcSet : pc[i ] ∈ {�out�, �dogc�})then ∧ libre ′ = libre ∪ garbage

∧ garbage ′ = {}else ∧ true

∧ unchanged 〈libre, garbage〉∧ pc′ = [pc except ! [self ] = �ml�]∧ unchanged 〈queue, tete, memoire, stack , nouv , lqueue ,

lsuiv , lqueue, ltete, lsuiv〉

Proc(self )∆= ml(self ) ∨ out(self ) ∨ dogc(self )

Next∆= (∃ self ∈ ProcSet : en�ler(self ) ∨ de�ler(self ))

∨ (∃ self ∈ 0 . . NP − 1 : Proc(self ))∨ Disjunct to prevent deadlock on termination

((∀ self ∈ ProcSet : pc[self ] = �Done�) ∧ unchanged vars)

Spec∆= Init ∧ 2[Next ]vars

Termination∆= 3(∀ self ∈ ProcSet : pc[self ] = �Done�)

END TRANSLATION

TypeInvariant∆=

∧ queue ∈ AdressesValides

∧ tete ∈ AdressesValides

∧ libre ∈ subset AdressesValides

∧memoire ∈ [AdressesValides → Adresses]

AbsenceDeCycle∆=

let pasDeCycle[addr ∈ Adresses, visites ∈ subset AdressesValides]∆=

if addr = 0 then true

else if addr ∈ visites then false

else pasDeCycle[memoire[addr ], visites ∪ {addr}]in pasDeCycle[tete, {}]

ListeCoherente∆=

∧AbsenceDeCycle∧memoire[queue] = 0∧ (libre ∪ garbage ∪ LesElements) = AdressesValides

Coherence∆=

(∀ i ∈ ProcSet : pc[i ] = �out�)⇒ ListeCoherente

theorem

Spec ⇒ 2TypeInvariant

Spec ⇒ 2Coherence

152

Variété de la cohérence dans les systèmes...

Documents

Transcript of Variété de la cohérence dans les systèmes...