N° ordre: 155-92
Année 1992
THESE
Présentée devant l'Université Claude Bernard-LYON 1
pour l'obtention
du diplôme de DOCTORAT
Spécialité: INFORMATIQUE
., .; {~~,'·:~t~~~,
'\\
"--
"of,,-
'\\
par
/,~'~-~
. >.
/
/
i .:.~
1
-"
,
"J
1
..- \\
Pierre MOUKEU
i~, ~ ) j,:
Conception d'un Système de Mise ~u»-~ii~
Programnles Parallèles,
Mise en Œuvre dans l'Enviromlenlent de
Programmation C_NET.
Soutenance: le 20 Juillet 1992.
\\,!:~1Cld;\\1 ET f,'\\Al>,~:~ _:!.'~:; -
. . ""'(" "'J,,-(A r'''IT C' ':,' ~ -. '. p 1
-
, ~,'";':~ '~' \\~{\\L::'J
:J ....
,-,~ .• ~~.. >;o.V."
:'i. ::, S. -
OUAC·,t\\LCUCO',.J 1
,.~ .:J..~. MOV'; ~S95·, .. ,.. l
JURY
..-: s::us n° .# f1. n. n. .~?o 4) i
4JL..Ul"~1
' ..'.~
--~.~--- ." ....~"--,.,,, ..~..,:, •.. "' --.,.~ -. '"
Rapporteurs:
Luc BOUGE:
Professeur, Ecole Normale Supérieure de Lyon
Claude JARD:
Chargé de recherche, Université de Rennes
Rudy LAUWEREINS:
Chargé de recherche, Université de Leuven
Michel TREHEL:
Professeur, Université de Besançon
Membres:
Jean-Marc ADAMO:
Professeur, Université de Lyon 1
Dominique DUVAL:
Responsable Système, TELMAT Informatique
Président:
Michel TREHEL:
Professeur, Université de Besançon

---

A Léa-Flore KANGA qui a été très patiente.
A Joseph MBINDZOUKOU et Joséphine TSOUNGI, mon père et ma mère.
A Augustine BOUTSOMBA, G~orges MOUKINDA, Etienne MBOYI,
Dieudonné MBINDZOUKOU, et Auguste MBOYI, ma sœur et mes frères.
A Augustin BIBAYE, Dépoiquet MAPOLA, Flore MAPOLA, Marius
MASSALA, Hervé MOMBO, Joseph-Marie MOMBO, Robertine et Jean-
Chrisostome MONDZO, Lorraine MOUKELI, Cyriaque MOUKOUNDJI, et
Nicola NDONGO.

---

Remerciements.
J'exprime mes sincères remerciements aux rapporteurs qui ont accepté de m'accorder un
peu de leur temps pour lire cette thèse, et qui m'ont apporté de précieuses suggestions:
Michel TREHEL, Professeur à l'Université de Besançon, Rudy LAUWEREINS, de
l'Université de Leuven, et Claude JARD, de l'Université de Rennes, qui ont accepté de
se déplacer; et Luc BOUGE, Professeur à l'Ecole Normale Supérieure de Lyon, qui m'a
apporté une aide précieuse. Je remercie Dominique Duval qui a accepté de participer
au jury de cette thèse.
Je remercie Jean-Marc ADAMO, qui m'a accepté dans son équipe, et qui m'a encadré.
C'est grâce à ses suggestions sur les probabilités que j'ai pu proposer une nouvelle
version de l'algorithme probabiliste. Ses interventions ont été déterminantes pour
comprendre le fonctionnement du bus de contrôle, et cela a parfois nécessité de longues
journées.
Je remercie mes collègues de l'équipe Langages et Systèmes Parallèles (Christophe
BONELLO et Luis TREJO), qui eux aussi ont contribué à faire avancer ce travail. C'est
par la détermination de toute l'équipe que le projet C_NET a pu aboutir.
Je remercie toutes les personnes qui de près ou de loin m'ont apporté le confort moral.
Je remercie ma famille, en particulier Georges qui a fait le voyage pour me soutenir;
ainsi que Léa pour ses multiples encouragements.
Je remercie mes amis: Guy ANZIANO, Sonia et Jean-Christophe GEMINARD, Alain
MATOKA, Jean-Aimé MIHINDOU-HINDET, Léon MUGWANEZA, Alain
NZOUKOU, et Maurice TCHUENrE.
Je remercie Mme Evelyne MOUNIER qui s'est intéressée à mon travail.
Je remercie Mme LIMARE qui m'a souvent soutenu.

---

Table des matières.
Introduction
1
1. Description de l'environnement C_NET
1
1.1. SuperNode
1
1.2. Logiciel de reconfiguration dynamique
.1
1.3. Système de routage
2
II. Objectifs et motivations de ce travail
2
m. Présentation de ce travail
4
Chapitre 1
7
Les Principales.Approches de Conception de Systèmes de Mise au Point pour les
lAngages Parallèles
7
Introduction
7
1. ~s traces
8
II. Enregistrement de traces
9
II.1. Mécanisme de traitement des exceptions
9
II.2. Observation de processus
9
II.3. Prise de vues
10
m. Utilisation de traces
11
m.l. Utilisation directe des traces
ll
m:2. Composition des événements
12
m.2.1. Compositions simples des événements de base
.12
m.2.2. Compositions multiples
13
m.2.3. Observations sur la composition d'événements
15
m.3. Reprise de l'exécution
16
m.3.l. Reprise totale de l'exécution
16
m.3.2. Reconstitution de l'état d'un système
17
m.3.3. Remarques
:
17
IV. Analyse statique et traces
:
18
IV.1. Arbre des états
19
IV.2. Graphe des événements
20
V. Synthèse et discussion
22
V.1. Analyse statique
23
V.2. Composition des événements
24
V.3 . Reprise de l'exécution
25
VI. CONCLUSION
27
Chapitre 2
29
Construction d'horloges globales pour les machines Parallèles
29
1. Introduction
:.~
29
II. Concepts de synchronisation des horloges
l~":'
.30
II.1. Notions de base
~~t..j~=,
.30
II.1.1. ~ temps
,'.-: '.
f ..~ ,
30
ll.1.2. Horloge et dérive_
·P.)'"'..~
.31
II.1.3. Synchromsanon des horloges: éf~~r~
n
.32
II.1.4. Relation entre précision, dérive e "ni
el'
.32
II.2. Problèmes liés à la synchronisation des horloges
.33
II.2.1. ~ temps de communication
33
II.2.2. La dérive
34
II.2.3. La précision
34
II.3. Propriétés des horloges globales
.35
m. Techniques de synchronisation des horloges
.36
1.
Sommaire.

---

III. 1. Approches statistiques
.37
III.2. Synchronisation par diffusion périodique de messages
.38
III.2.1. Algorithmes de convergence
.38
III.2.2. Algorithmes de consistance
.39
III.2.3. Avantages et inconvénients
.40
III.3. Approche probabiliste
40
IlIA. Autres méthodes de synchronisation des horloges
.42
IlIA. 1. Synchronisation matérielle
.43
III.4.2. Synchronisation hybride
44
IV. Discussion
44
Conclusion
46
Chapitre 3
47
Etude d'un moniteur de communication sur le bus de contrôle du SuperNode.
47
Introduction
47
1. Objectifs et motivations
48
n. Etude expérimentale du bus de contrôle
50
n.!. Fonctionnalités offertes par le bus de contrôle
50
n.2. Organisation et modélisation du bus de contrôle
51
n.2.1. Organisation matérielle du bus
51
n.2.2. Organisation logique du bus de contrôle
52
a) I...e Bus
52
b) Le CGA maître
52
c) I...e CGA esclave
54
n.3. Fonctionnement du bus de contrôle
55
n.3.1. I...e CGA maître
55
a) Cycle de lecture des flags
56
b) Cycle de sélection des ST
56
c) Cycle d'une commande de communication
58
d) Cycle interne: génération des interruptions
59
II.3.2. I...e CGA esclave
59
n.4. Conséquences et observations
60
III. Etude de protocoles de base d'utilisation du bus
61
III.!. Etude des protocoles de base
62
III. 1. !. Protocole de communication MS (maître1Eesclaves).
......................................................................................................62
III. 1.2. Protocole de communication SM (esclave.tEmaître)
62
III. 1.3. Protocole de synchronisation ALL
63
III. 1.4. Protocole de synchronisation ANY
64
III.2. Mesure et analyse des peIformances des protocoles de base
64
III.2.1. Mesures
64
III.2.2. Analyse des performances
~
66
IV. Analyse des contraintes et problèmes liés au bus
67
IV. 1. Analyse des contraintes Imposées par le bus
67
IV.2. Analyse des problèmes liés au bus
67
IV.3. Proposition de solutions
68
IV.3.1. Arbitrage des conflits d'accès au bus
68
a. Arbitrage des conflits maître-esclave
68
b. Arbitrage de la concurrence sur le même transputer.
..........................................................................................69
[IV.3.2. Optimisation des communications pour gagner du
temps
69
V. Moniteur asynchrone de communication sur le bus
70
V.1. Architecture et fonctionnement.
70
V.1.1. Moniteur du transputer de contrôle
71
Il
Sommaire.

---

V.1.2. Moniteur du transputer de travail
72
V.2. Mesure et analyse des performances
73
V.2.1. Répartition des temps de communication à travers le
moniteur
73
V.2.2. Temps de communication entre transputers de travail.
......................................................................................................75
V.3. Quelques applications utilisant le moniteur
75
V.3.l. !..es entrées-sorties
75
V.3.2. La reconfiguration dynamique
75
V.3.3. Synchronisation des horloges
76
V.3.4. Communication entre transputers
76
V.3.5. Mise au point interactive des processus
76
V.4. Avantages et limitations
77
VI. Moniteur de communication Synchrone
77
VI.l. Présentation du moniteur synchrone
.78
VI.l.l. Protocole déterministe
79
VI.l.2. Synchronisation globale
79
VI.l.3. Optimisations
79
VI.2. Eléments de performances
80
VI.2.l. Répartition des temps de changement de phase
80
VI.2.2. Mesure d'un exemple d'application: le gradient
conjugué
:
81
V. Conclusion
81
Chapitre 4
83
Algorithme statistique et probabUiste pour Ùl synchronisation des horloges
83
I. Introduction
83
II. Analyse des performances du bus pour la synchronisation des horloges
84
II.!. Mesure de l'erreur de lecture sur le bus de contrôle du
SuperNode
84
II.2. Mesure de la dérive des horloges
85
II.3. Analyse des possibilités d'utilisation des algorithmes existants.
...................................................................................................... ,
86
m. Algorithme statistique et probabiliste
87
m.l. Présentation
87
m.l.l. Limites de l'algorithme probabiliste
87
m.1.2. Description informelle de notre solution
88
m.2. Description formelle de la solution
89
m.2.l. Intervalle de lecture d'une horloge relativement à la
moyenne arithmétique
89
m.2.2. Estimation de la moyenne arithmétique et de l'écart
type
91
m.2.3. Estimation de la borne inférieure de la probabilité de
.
synchronisation
91
m.2.4. Estimation du nombre moyen de tentatives de
synchronisation
92
m.2.5. Adaptation à la charge du réseau
92
m.2.6. Simplifications
93
m.2.7. Critère de comparaison
93
IV. Etude expérimentale sur le SuperNode
94
IV.1. Implémentation
94
IV.2. Mesure et analyse des performances
95
IV 2
. .1. Tests et mesures prélim'
.
!narres
96
IV.2.2. Tests en temps réel.
97
V. Extensions et adaptations
97
m.
Sommaire.

---

V.1. Une meilleure adaptation à la charge du système
:-.
97
V.2. Une meilleure estimation de la dérive
98
V.3. Test d'hypothèses
98
VA. Amélioration d'Alari et Ciuffoletti
98
Conclusion
99
Chapitre S
101
Un système de construction de points d'a"êt globaux pour les programmes
parallèles
101
1. Introduction
101
n. Les points d'arrêt distribués
l02
n.l. Déf111Ïtions
102
II.2. Arrêt consistant.
l02
n.2.1. Consistance de l'arrêt relativement à l'état global
103
II.2.2. Consistance de l'arrêt relativement à l'ensemble des
événements
103
n.3. Travaux existants
103
II.4. Objectifs et motivations
l05
n.5. Hypothèses sur le modèle de système parallèle
.l06
m. Système d'arrêt sélectif des processus
106
m.l. Présentation
106
m.2. Construction de prédicats globaux
107
m.2.1. Principe de représentation non ambigut! des prédicats.
.................................................................................................... 107
m.2.2. Système de gestion des prédicats
109
m.2.3. Evaluation
ll0
m.2.4. Application à la construction des prédicats
.ll0
m.3. Arrêt consistant des processus
lll
m.3.1. Procédure d'arrêt des processus
l11
m.3.2. Complexité
113
m.3.3. Preuve de consistance de l'arrêt..
.113
mA. Spécification d'actions distribuées
.l15
m.5. Procédure de terminaison de l'arrêt.
.116
IV. Implémentation et performances
117
IV.1. Implémentation
117
IV.2. Mesure et analyse des performances
.l18
VI. Conclusion
119
Chapitre 6
121
Etude et Mise en Œuvre de CDS: C-Net Debugging System
121
Introduction
121
1. Présentation générale de CDS
122
1.1. L'état de l'art
122
1.1.1. Les modèles classiques
122
1.1.2. Les orientations actuelles de la recherche
122
a) SMAP multi-fonctions
123
b) Automatisation
123
c) Standardisation
123
d) Méthodologies
124
1.2. Les choix de CDS
125
1.2.1. Le modèle de CDS
125
1.2.2. Les fonctionnalités de CDS
.125
1.2.3. Les caractéristiques conceptuelles de CDS
.127
a) Mfichage synchrone des traces
127
b) Descripteur de contexte des processus
.127
IV.
SommaR.

---

II. Etude de COS
128
Ill. Modèle de répartition des problèmes
.l29
II.2. Problèmes de conception de COS
130
II.2.1. Problèmes liés au matériel.
130
a) Nature du SMAP dictée par le matériel..
130
b) Compatibilité des composantes de COS sur
différents matériels utilisés
131
c) Fluidité du transport des observations liée à la vitesse
de communication
131
d) Effets pervers des niveaux de priorité du transputer.
........................................................................................ 131
e) Robustesse du SMAP dépendant des mécanismes de
protection mémoire
132
II.2.2. Problèmes liés à la spécification
.l32
II.2.3. Problèmes liés à l'exécution
133
a) Modification de l'ordonnancement des processus.
........................................................................................ 133
b) Consistance du système
133
c) Fiabilité
133
II.2.4. Problèmes liés à l'observation
133
II.3. Analyse des choix de mise en œuvre
134
II.3.1. Choix liés au matériel: le moniteur interactif
134
a) Choix de l'architecture du moniteur interactif
134
b) Compatibilité des composantes
135
c) Fluidité du transport..
136
d) Minimisation des interférences et résolution des
problèmes d'équité
136
e) Robustesse
137
II.3.2. Choix liés à la spécification des actions de mise au
point.
137
a) Lisibilité et redondance
138
b) Facilité d'usage et efficacité
138
II.3.3. Choix liés à l'exécution
138
a) Techniques de communication avec le moniteur
interactif
:
138
b) Ordonnancement des processus
14O
c) Consistance du contexte
14O
d) Fiabilité des observations
140
II.3.4. Choix liés à l'interface d'observation
141
a) Format des observations
141
b) Restitution du parallélisme: affichage synchrone des
traces
141
c) Filtrage
142
m. Mise en œuvre de COS
142
m.1. Architecture de COS
142
m.1.1. Moniteur interactif
142
a) Le moniteur du SuperNode
142
b) Interface de communication
144
c) Moniteur de gestion des observations
l44
m.I.2. Interface graphique
l45
m.1.3. Bibliothèque de fonctions
147
m.2. Mise en œuvre des fonctionnalités de COS
148
m.2.1. Les traces
149
a) Collecte, transport et gestion des traces
149
b) Affichage en temps réel..
149
V.
Sommaire.

---

c) Affichage différé
149
d) Affichage synchrone des traces
.150
m.2.2. Construction et gestion des descripteurs de contexte
des processus
150
m.2.3. Mise en œuvre des points d'arrêt individuels: les
.
dialogues
152
a) Dialogue du côté du processus utilisateur
.152
b) Dialogue du côté du moniteur et de l'interface
graphique
153
m.2.4. u scanner
154
a) Le processus scanner.
.154
b) Adressage du scanner.
155
m.2.5. L'espion
156
m.2.6. Gestion des vues
157
m.2.7. Communication entre processeurs
157
IV. Extensions
158
IV.1. Analyse de l'état des processus après une panne logicielle
.158
IV.l.1. Interrogation de la mémoire d'un transputer (peek and
poke)
158
JV.1.2. Vecteurs d'état des processus
.158
IV.2. Génération de messages à la compilation
.159
Conclusion
159
Conclusion
161
J. Bilan
162
II. Perspectives
164
Références
167
Annexe 1. Tableaux de programmation du bus
179
Annexe 2. Transmission de plusieurs messages simultanément.
.183
Annexe 3. Clock synchronization algorithrns
184
Annexe 4. Mesures de l'horloge
189
Annexe S. Programmation des prédicats et points d'arrêt
.191
Annexe 6. Comparatif des modèles classiques de SMAP
.198
VI.
Sommaire.

---

Introduction.
I. Description de l'environnement C_NET.
Le travail présenté dans cette thèse a été réalisé dans le cadre de la conception de
l'environnement C_NET [6] [7] [10]. C_NET est un environnement de programmation
pour la machine multi-processeurs SuperNode, qui a été conçu pour tirer parti des
possibilités de reconfiguration dynamique qu'elle offre, pour permettre de développer
des programmes comportant plusieurs topologies. C_NET vise à virtualiser l'usage du
SuperNode, et est constitué de composantes logicielles que nous allons présenter
brièvement.
1.1. SuperNode.
Le SuperNode [101] [123] est une machine MIMD multi-processeurs et reconfigurable.
à base de transputers. conçue dans le cadre du projet esprit P1085. Cette machine peut
être constituée de 16 à 1024 processeurs. La machine de base est composée de 16 ou 32
processeurs de travail et un processeur de contrôle. Des machines plus grandes peuvent
être construites en combinant recursivement des machines de base. Le travail présenté
dans cette thèse a été réalisé sur un T.Node (SuperNode de chez Telmat) de 32
processeurs; mais il peut être étendue à des configurations plus grandes de SuperNode.
Chaque nœud est un transputer T800 avec une mémoire interne. Les nœuds
communiquent entre eux à travers un commutateur programmable. Ils peuvent
également communiquer avec le transputer de contrôle à travers un bus de contrôle. Une
Inodélisation et une étude des performances de ce bus sont faites dans le troisième
chapitre de cette thèse.
1.2. Logiciel de reconfiguration dynamique.
~ logiciel de reconfiguration dynamique de C_NET se compose de trois langages
algorithmiques basés sur CH (fig. 1). qui permettent le développement de programmes
à phases. Le premier langage. PPL (Phase Programming Language). est destiné à
spécifier l'enchaînement des phases du programme [9]. Le deuxième. GCL. est destiné à
décrire les topologies qui seront enchaînées de phase en phase lors de l'exécution du
programme [28]. Enfin. le troisième langage. CPL (Component Programming
Language) [14]. sert à décrire les composantes constituant le programme C_NET. Une
description détaillée de ces logiciels est disponible dans [13].
1.
Introduction.

---

,.-------------
1
CPL or Logical Systems C
CSP/OCCAM
primllivl!II
1
t • upon
: • node (n1)
: • mapp1na
1 • connecl (n1,n2)
1 _ Inter
: : ~=:~1~;n2)
: : ~~~le
1
L
1
J
1
1
-Figure 1-
1.3. Système de routage.
Le système de routage de C_NET comporte un routeur paramétrable et une bibliothèque
de données de routage prédéfInies. Une méthode de génération de fonctions de routage
adaptatif, minimal et sans interblocage a également été développée. Elle est basée sur le
modèle de graphes de précédences. Pour plus de détails, se reporter à [5] [104].
II. Objectifs et motivations de ce travail.
Le travail réalisé pour cette thèse avait deux objectifs principaux. Le premier a été la
conception d'un système de base permettant à tous les processus d'accéder au bus de
contrôle du SuperNode. Cela pour d'une part permettre de réaliser la reconfIguration
dynamique, et d'autre part pour permettre à la fois à tous les processeurs d'accéder à la
carte frontale (e.g. opérations d'entrées/sorties) et de réaliser des protocoles de contrôle
indépendants des confIgurations du réseau principal du SuperNode (e.g. diffusion de
données de contrôle).
La mise œuvre de la reconfIguration nécessite en effet de synchroniser le transputer de
contrôle avec les transputers de travail de façon que d'une part ces derniers n'utilisent
pas les liens pendant que le commutateur est en cours de programmation; et d'autre part,
pour communiquer les données relatives au changement de phase (e.g. numéro de la
phase suivante). Comme on peut le deviner, la vitesse de communication sur ce bus
détermine le grain de la reconfiguration dynamique. Il nous a donc été essentiel
d'optimiser ces communications.
Sur le SuperNode, seul un petit nombre de processeurs peuvent accéder à la carte
frontale. Nous avons donc été amené à concevoir un moniteur permettant d'étendre cet
2.
Introduction.

---

accès à tous les processeurs grâce à des communications à travers le bus de contrôle
entre les transputers de travail et le transputer de contrôle; ce dernier étant relié à la
carte frontale.
Le deuxième objectif de cette thèse a été de concevoir un outil de mise au point pour
l'environnement C_NET. Un tel outil est en effet indispensable pour faciliter la
programmation, d'autant plus que l'environnement de base sur lequel C_NET a été
conçu (T.Node [123], C de Logical Systems [82], LD-NET [82]) ne disposait pas d'un
tel outil. Cet outil devait répondre à un certain nombre de critères.
Le premier critère est que système de mise au point devait être compatible avec
l'environnement C_NET, en particulier avec la reconfiguration dynamique. En effet,
pour éviter d'interférer avec les communications des processus utilisateurs sur le réseau
principal du SuperNode, le système de mise au point doit partager le bus de contrôle
avec le logiciel de reconfiguration dynamique.
Le deuxième critère est que le système de mise au point devait permettre de collecter un
minimum de traces pour analyser le comportement du programme après l'exécution,
avec la possibilité d'établir une relation temporelle entre les événements. Etablir une
relation d'ordre entre les événements est en effet indispensable car certaines situations
d'erreurs sont étroitement liées à l'ordonnancement des processus (congestions,
problèmes de partage de variables, choix gardés, temporisation), c'est à dire l'ordre
d'occurrence des événements.
Le troisième critère est que le système de mise au point devait permettre la mise au
point en ligne pour le contrÔle des processus pendant l'exécution. Ce choix est
principalement motivé par le fait que le bus de contrôle a une faible vitesse de
communication ne permettant pas une collecte de traces abondantes, et que l'analyse de
traces ne permet pas de couvrir toutes les erreurs possibles.
Enfin, comme il n'existe pas de méthode spécifique permettant de couvrir un large
domaine de recherche des erreurs, la seule alternative actuellement largement utilisée
est de concevoir des systèmes de mise au point multi-fonctions donnant un grand choix
de moyens de recherche des erreurs au programmeur. Nous avons donc cherché à
concevoir un système possédant plusieurs fonctionnalités.
3
Introduction.

---

III. Présentation de ce travail.
Le travail mené pour cette thèse peut être décomposé en six phases correspondant à
chaque chapitre de ce document.
• Le premier chapitre est une analyse des techniques de base de conception des systèmes
de mise au point basés sur l'utilisation des traces. TI décrit les principaux moyens de
spécification, de collecte et d'exploitation des traces. Nous avons centré cette analyse
sur les traces du fait que c'est le moyen le plus utilisé pour la mise au point des
programmes parallèles, et que c'est la technique certainement la plus simple
qu'intuitivement les programmeurs utilisent pour mettre au point leurs applications.
• Le deuxième chapitre est consacré à l'étude des techniques de conception d'horloges
globales pour les machines parallèles. La littérature se rapportant à la synchronisation
des horloges est en général difficile à aborder. Dans notre travail, nous avons donc
cherché à dégager les principaux concepts et les propriétés liés à la synchronisation des
horloges. Nous avons ensuite analysé les techniques de conception de synchronisation
des horloges. Cette étude nous a permis comprendre comment les principaux travaux
qui ont été réalisés sur la synchronisation des horloges, ont répondu aux questions
suivantes que nous nous sommes posées : quels sont les paramètres caractérisant une
horloge globale? Dans quelles les limites peut-on synchroniser des horloges d'une
machine donnée? Quelles sont les propriétés pouvant caractériser une horloge globale?
Et fmalement, étant donnée une machine parallèle, qu'est-ce qu'il est possible d'en faire
en terme de synchronisation des horloges? Nous avons fait cette étude dans la
perspective de construire une horloge globale utilisant le bus de contrôle du SuperNode,
nécessaire au système de mise au point que nous voulions construire.
• Le troisième chapitre présente l'étude que nous avons faite pour réaliser un moniteur
de communication sur du bus de contrôle du SuperNode. Cette étude a consisté à
modéliser le fonctionnement de ce bus, et analyser ses performances. Cette étude a
débouché sur la conception de deux moniteurs tirant au mieux parti des spécificités de
ce bus. L'un est dédié à la reconfiguration dynamique, et l'autre au système de mise au
point. Ces deux moniteurs sont présentés dans ce chapitre. Cette étude est la plus
complète qui ait été réalisée sur ce bus, et comble un vide pour les utilisateurs du
SuperNode.
• Le quatrième chapitre porte sur les travaux que nous avons entrepris sur la conception
d'une horloge globale utilisant et tirant au mieux parti du bus de contrôle du SuperNode.
4.
Introduction.

---

TI s'agit premièrement de l'analyse des performances du bus de contrôle pour la
synchronisation des horloges. Cette analyse a été faite en se basant sur l'étude du
deuxième chapitre. La deuxième partie présente l'horloge globale que nous avons
conçue afm entre autres d'établir une relation temporelle entre les événements.
• Le cinquième chapitre décrit un système de points d'arrêt globaux que nous avons
conçu pour le contrôle global de l'exécution. fi permet l'expression de prédicats globaux
et l'arrêt consistent des processus. Ce système est basée sur la représentation binaire des
prédicats globaux et les actions distribuées. Nous le comparons aux systèmes existants
[29] [35] [56] [85] [86] [87] [90], desquels il se distingue par un nombre limité de
messages générés et une moindre indence sur les processus utilisateurs.
• Le sixième chapitre présente le système de mise au point COS (C_NET Oebugging
System) conçu dans le cadre de cette thèse, et implément pour l'environnement C_NET
et le SuperNode. C'est un système multi-fonctions orienté vers la mise au point en ligne.
TI comporte un moniteur logiciel pour la collecte, le transport et la gestion des
observation; une interface graphique multi-fenêtres; et une bibliothèque de fonctions à
insérer au niveau du cod~ source. CDS résulte de l'ensemble des travaux présentés dans
les cinq premiers chapitres. Nous situons ce logiciel par rapport aux travaux récents de
la recherche sur la mise au point des programmes parallèles.
L'ensemble des travaux présentés dans cette thèse, pensons nous, et comme nous allons
le montrer, va au delà de l'environnement (C_NET, SuperNode) sur lequell'esssentiei
des dévéloppements ont été réalisés. Nous pensons en particulier à l'horloge globale, au
système de points d'arrêt globaux, et aux diverses techniques que nous avons conçues
pour la mise en œuvre de CDS. Lors de cette thèse, nous avons fait un effort de
développement très important: le système CDS est fonctionnel et disponible au LIP et
chez Telmat le constructeur du SuperNode.
5. Introduction.

---

---

Chapitre 1.
Les Principales Approches de Conception de Systèmes de
Mise au Point pour les Langages Parallèles.
Introduction.
Un nombre important de langages dédiés au parallélisme ont été proposés ces dernières
années. Les outils de mise au point correspondants se développent avec un certain
retard. L'objectif de ce chapitre est de présenter une synthèse des principales approches
pour la conception des systèmes de mise au point de programmes parallèles (SMAP),
basés sur l'utilisation des traces de processus. La trace d'un processus, telle que la définit
Hoare [58], est l'enregistrement séquentiel de son comportement pour une exécution
donnée.
Un SMAP est en général constitué de deux parties, une qui enregistre les traces,
distribuée sur chaque site, et une autre qui est chargée de la détection des erreurs à
partir de ces traces. La détection des erreurs, généralement centralisée, peut se faire sur
la machine où s'exécute le programme, sur une machine qui simule la machine
d'exécution, ou encore sur une machine qui peut être monoprocesseur.
Nous nous intéressons essentiellement à la présentation des principales approches
utilisées actuellement pour d'une part enregistrer les traces, et d'autre part exploiter ces
traces pour la détection des erreurs. Nous nous intéressons aux traces parce c'est le
moyen le plus utilisé actuellement pour la mise au point de programmes parallèles. A
cela, trois raisons. La première est que l'analyse in vivo d'un programme parallèle pose
deux problèmes. D'une part le nombre de processus est généralement élevé, d'autre part,
i! Ya une forte interférence avec leur exécution. La seconde raison est que les machines
parallèles sont utilisées pour leur puissance de calcul. Or l'analyse in vivo peut ralentir
considérablement la vitesse d'exécution, car la détection d'une erreur demande souvent
beaucoup de temps. La troisième raison est que la détection des erreurs ne peut pas se
baser sur l'analyse statique du programme, car elle ne permet de signaler que des erreurs
potentielles, que seule l'exécution peut confirmer; et en plus, les techniques qu'elle
propose sont en général inutilisables.
7.
Chapitre 1.

---

Ce chapitre se compose de cinq parties. Dans la première, nous donnons une description
des divers types de traces. Dans la deuxième partie, nous présentons les approches pour
collecter les traces. Dans la troisième, nous présentons les principales approches pour
exploiter les traces en vue de la détection des erreurs. Dans la quatrième partie, nous
présentons les approches qui associent les traces avec une analyse statique du code
source. La cinquième partie est une analyse de synthèse.
QuelQues notations:
Certains de nos exemples seront écrits dans le langage C_NET [2]. Nous utiliserons
principalement les instructions send et recv
qui sont des instructions de
communication avec synchronisation, et l'instruction par qui déclare des blocs à
exécuter en parallèle, le processus qui l'a exécutée se suspend jusqu'à la terminaison de
tous ses fIls.
I. Les traces.
Nous avons défini la trace d'un processus comme étant l'enregistrement séquentiel de
son comportement pour une exécution donnée. On distingue deux types de traces, à
savoir, les traces comme enregistrement
d'événements, et les traces comme
enregistrement des états des processus. Les événements peuvent être l'occurrence de
communications, la modification de variables, les choix, le franchissement de
séquences, les appels de fonctions ou simplement l'exécution d'instructions. Ces
événements générés par le processus sont dits événements de base.
L'état d'un processus est l'état de son environnement d'exécution (mémoires, registres)
ou simplement son état de synchronisation. Dans certains SMAP, l'enregistrement des
états se fait en arrêtant tout le système pour en prendre une vue. Dans Igor [52], BugNet
[36] [67] et Amoeba [48], ces vues sont constituées de pages mémoire du programme.
D'autres SMAP tels que Recap [105] ou Agora [54] enregistrent individuellement l'état
de chaque processus. Dans SR [113], on enregistre
les variables persistantes.
Rappelons qu'une variable est dite persistante si toute modification de cette variable
entrâme automatiquement une écriture de sa valeur sur disque.
Notons que l'ensemble des événements de b.ase doit être représentatif du système; c'est
son image observable la plus fine. Le flot des données de ces événements conduit
souvent à la 'saturation du support d'enregistrement. C'est l'un des problèmes majeurs
que pose la collecte de traces. La granularité (temps d'exécution du code introduit pour
8. .
Chapitre 1.

---

enregistrer les traces) est un autre problème posé par les traces. Pour économiser
l'espace d'enregistrement et améliorer la granularité, dans Igor [52] on ne sauvegarde
que les pages qui ont été modifiées depuis la dernière sauvegarde.
II. Enregistrement de traces.
En plus de la simple insertion de code, on distingue trois principales techniques pour
obtenir les traces d'un système de processus, à savoir, l'utilisation du mécanisme de
traitement des exceptions, l'observation de processus, et la prise de vues.
D.l. Mécanisme de traitement des exceptions.
Une exception est signalée par l'occurrence d'une condition anormale pendant
l'exécution d'un programme [3] [27] [113]. Dans les systèmes Mach [27] et SR [113],
le mécanisme de
traitement des exceptions (en anglais, handler) peut permettre
d'enregistrer des informations concernant le processus et l'exception associés. C'est un
moyen sélectif de mémoriser l'ensemble des exceptions survenues pendant l'exécution.
D.2. Observation de processus.
Un observateur est un processus espion. li a pour tâche l'observation et la mémorisation
de l'activité d'autres processus [19] [31] [67] [113]. Dans SR [113], on associe un
observateur à chaque événement. Son rôle est de détecter l'occurrence dudit événement
et d'en enregistrer dans une trace. Une collaboration entre l'observateur et le processus
épié se fait par appel de fonctions et par partage de variables. Dans Parasight [19], un
observateur est attaché à chaque processus; son comportement est asynchrone par
rapport au processus qu'il épie. On retrouve un scénario analogue dans BugNet [38] [67]
où deux processus TRAP et TRACE sont associés à chaque processus utilisateur. Le
rôle du processus TRAP est de capturer et mémoriser les traces des communications
concernant le processus associé; et le processus TRACE sert à en enregistrer les traces
des événements successifs.
RemarQyes:
L'utilisation d'observateurs pose trois problèmes. Le premier est qu'un certain nombre
d'événements peuvent échapper à l'observateur du fait que son activité est asynchrone,
comme dans Parasight [19]. Le deuxième problème est qu'il subsiste un décalage entre
le moment où un événement a lieu et le moment où il est détecté et signalé par l'espion.
9.
Chapien. 1.

---

Le troisième est que le langage doit assurer que tous les événements observables sont
détectables quand ils se produisent. Pour éviter l'interférence, l'observateur ne doit pas
être autorisé à modifier les variables du processus qu'il espionne. Le rôle d'espion peut
être affecté à un processeur particulier.
II.3. Prise de vues.
Un autre moyen permettant d'enregistrer les traces d'un système de processus consiste à
arrêter régulièrement le système pour en prendre une image (une vue). Cette approche
est utilisée par les systèmes Igor [52], BugNet [38] [67] [127], Amoeba [49], et Agora
[54]. Ces quatre systèmes se distinguent par la détermination de l'instant de prise de
vue. Dans BugNet [38] [67] [127], un processus TRACE associé à chaque processus
utilisateur interrompt régulièrement celui-ci pour en prendre une vue. Le processus
TRACE détermine les instants de prise de vues en fonction de l'heure globale. Dans le
système Amoeba [49], les processus sont ~êtés par groupes (ou clusters). Quand tous
les groupes de processus sont arrêtés, on procède alors à la prise de vue du système.
L'approche d'Igor [52] et Agora [54] consiste à envoyer une consigne de prise de vues
au système. Cette interruption est déclenchée par une horloge globale. Tous les
processus sont suspendus et les pages mémoire utilisées sont sauvegardées. Dans Igor,
l'ensemble des pages est considéré comme une mémoire virtuelle. On ne sauvegarde
que les pages qui ont été modifiées depuis la dernière sauvegarde. La fonction UNIX
pagemod permet d'obtenir la lis~~e telles pages. De même l'horloge est assurée par
(1
. '
ualarm, une autre foncti~1JNIX.
Remarques.
Le problème principal de la prise de vues est la granularité. Lors des prises de vues,
l'ensemble des processus est gelé dans les systèmes BugNet et Igor. Les contraintes
temporelles peuvent donc se trouver modifiées, par exemple quand on utilise des
processus alarmes, ou des communications et des attentes temporisées. Dans BugNet ce
problème est résolu en décomptant le temps de prise de vues sur les horloges utilisées
dans l'application, (de même qu'au football, où on décompte les arrêts de jeu). Cette
approche est fort séduisante. Nous proposons de contrôler l'espace disque nécessaire à
l'enregistrement des vues, en supprimant les vues les plus anciennes. Cela aura
malheureusement pour conséquence de limiter les reprises aux périodes les plus
récentes.
10.
Cbapi~ 1.

---

Toujours lié à l'enregistrement de traces, le problème du "timeout". Dans le système
Amoeba par exemple, un processus peut être bloqué à cause de l'enregistrement de
traces, alors qu'il est impliqué dans une communication avec un autre processus déjà en
attente de cette communication. Cette attente peut occasionner un dépassement de
temps limite pour ce dernier processus si la communication possède une temporisation.
III. Utilisation de traces.
Nous venons de voir divers moyens pour enregistrer les traces d'un système de
processus. Nous allons maintenant en présenter les trois principales approches
d'utilisation. La première approche est l'utilisation directe des traces pour visualiser le
comportement du programme, ou pour valider un modèle de comportement. La
deuxième, la composition des événements permet de détecter les erreurs avec une
analyse post mortem. La troisième approche permet la reprise de l'exécution du
programme.
m.l. Utilisation directe des traces.
Les événements constituant les traces peuvent être directement utilisés, pour donner une
représentation de l'exécution [2], ou pour valider un modèle de comportement [31] [36].
Le SMAP que propose
Fang [51] permet, à partir de traces, de donner une
représentation de l'arbre de création des processus, de la séquence des états d'un
processus, et du graphe de communications.
Dans l'approche proposée par Chang [36], le comportement d'un processus est modélisé
sous forme de réseau de Pétri, à partir du programme source. Les traces de l'exécution
permettent de valider ce modèle. On trouve une démarche semblable pour le SMAP
IdéflX [31], où les traces servent à retrouver le schéma d'exécution à partir des graphes
de contrôle et de synchronisation des modèles de processus, et permettent de valider les
contraintes de temps réel.
La validation de modèles de comportement à partir de traces pose deux problèmes. Le
premier est que le modèle peut masquer certaines erreurs. Le deuxième problème est la
conformité du modèle par rapport au comportement effectif à l'exécution.
Il.
Chapitre 1.

---

ill.2. Composition des événements.
Nous avons dit que les événements emegistrés de l'exécution d'un programme sont des
événements de base. Ces événements peuvent être utilisés, soit par compositions
simples en utilisant des automates d'états fInis, soit par compositions multiples.
ill.2.I. Compositions simples des événements de base.
On peut composer plusieurs événements de base sous forme d'expressions régulières
[32] [61]. Ceci arrange bien les choses car les expressions régulières sont
reconnaissables par des automates d'états finis, comme on peut le voir sur l'exemple
suivant:
Exemple
Un fIchier "f' est utilisé par un processus "p". Cette utilisation est régulière si elle donne la trace suivante
{ouverture. lecture/écriture autant de fois que nécessaire. fermeture}. Si les événements "fm trace" ou
"fm processus p" sont rencontrés avant la fermeture du fIchier "f' alors on signale cette une anomalie par
un signal "BIP". L'expression régulière représentant cette utilisation. et l'automate d'état fini
correspondant sont donnés ci-dessous. La première ligne décrit l'utilisation normale. la deuxième. une
utilisation irrégulière.
flle ::= open<f,p> & (read + write)*<f,p> & close<f,p>
1
open<f,p> & (read + write)*<f,p> & (trace_end + end_of<p»
r/w Fp
trace_end/end-of p
-Figure 1-
Automate de reconnaissance d'un défaut d'accès à un fichier.
Hseush et Kaiser [61] [106] proposent un modèle de ce type où des reconnaisseurs
d'événements sont décrits en composant des événements sous forme de prédicats, à
l'image de YACC dans Unix. A chaque prédicat est attaché une action qui est effectuée
quand le prédicat est validé. Un système analogue est décrit par Cameron [32]; les
prédicats pouvant y être des invariants.
12.
Chapitre 1.

---

On peut remarquer que les outils tels que LEX et YACC dans Unix, permettent de
construire ces reconnaisseurs. On y intègre aussi un traitement contextuel pour exprimer
des contraintes telles que le parallélisme de deux événements, comme nous le montre
l'exemple suivant.
Exemple:
Si A est l'événement composé de la conjonction des événements de base Al et A2;
sachant que Al et A2 peuvent se produire en parallèle:
A ::= Al & A2 & "Al parallèle à Ai'.
C'est une expression régulière où la contrainte "Al parallèle à Ai' peut être exprimée
par un traitement contextuel avec une grammaire ad hoc.
De manière plus générale, le langage de composition doit fournir des opérateurs pour
exprimer le parallélisme, la sélection et l'ordre séquentiel des événements.
m.2.2. Compositions multiples.
La composition
telle que nous venons de l'étudier ne prend en compte que les
événements de base. La
composition des événements de base donne des événements
de deuxième niveau. En appliquant ce mécanisme de manière récursive, on construit
des niveaux d'observation,
des abstractions du système. Les modèles de SMAP
proposés par Bates [24]' [25], Lin [80] et Cheng [39] suivent cette approche. Les
événements de base sont défmis lors de la conception de l'application. Les événements
composés sont définis par la suite suivant les besoins, sous forme de modèles
d'événement. Dans la suite de cette section, le terme événement désignera
indifféremment les événements de base ou les événements composés.
Dans le modèle de Cheng [39], un processus est décrit sous forme d'un arbre de modèles
d'événements (process pattern). Les événements peuvent être composés (aggregate
event), ce qui distingue cette approche de celles décrites en m.l et m.2.1. Une erreur
est détectée lorsque la trace d'un processus ne valide pas le modèle associé.
L'approche proposée par Lin [80] utilise la composition des événements pour exprimer
des niveaux d'abstraction. Cette approche est calquée sur celle de Bates [25], la
différence tenant (précise Lin), à la spécification des événements de base. Le modèle
13.
Cbapille 1.

---

que propose Bates [24] [25] (Event Based Behavior Abstraction (EBBA» généralise la
composition des événements. Un événement composé y est décrit suivant le format:
descripteur_événement ::= est nom_événement
comp
liste_de_composants
cond
conditions_de_composition
avec
liste_d_attributs
fin.
Cette expression déclare un événement, avec la liste des événements qui le composent,
des conditions que doivent vérifier ces composants, et une liste d'attributs qui
différencieront 'les instances du modèle d'événement. Ces attributs véhiculent une
information contextuelle. Les utilisateurs de YACC verront facilement la traduction de
ce modèle en une règle, avec nom_événement correspondant à la partie gauche de la
règle, Iiste_de_composants. une liste composée de symboles non-terminaux et de
lexèmes. Le terme conditions_de_composition correspond à un ensemble d'actions
pour vérifier les contraintes contextuelles. Et liste_d_attributs correspond à la variable
$$.
L'ensemble des outils composant le SMAP dans le modèle de Bates, est décrit par le
schéma de la figure 2 :
modèles
existants
-Figure 2-
Modèle de Bates.
La liste des événements composés, une fois décrite par le programmeur, est soumise au
compilateur pour les contrôles syntaxiques et sémantiques. Le compilateur génère d'une
part le code de reconnaissance des événements, code qui formera une partie du
14.
Chapitre 1.

---

reconnaisseur, et d'autre part le modèle de chaque événement qui est envoyé au
gestionnaire de la banque.
Le système génère le flot des événements de base. Ce flot est stocké et destiné au
reconnaisseur. L'ensemble des modèles d'événements intéressants qui correspondent au
niveau d'observation est spécifié par l'utilisateur grâce au simulateur. L'observation
portera sur les événements défmis par ces modèles. Le simulateur sert d'intermédiaire
entre l'utilisateur et le reconnaisseur.
L'ensemble des modèles d'événements
reconnaissables est stocké dans une banque.
m.2.3. Observations sur la composition d'événements.
La composition des événements pose un certain nombre de problèmes. Le premier, c'est
la taille que peut atteindre les fichiers de traces. Le flot de données engendré par la
reconnaissance des événements peut très vite devenir énorme. TI faut donc défmir des
flltres permettant de ramener cette information à des proportions plus raisonnables.
Dans
le
modèle
de
Bates
[24]
décrit
plus
haut,
la
clause
"e 0 n d
conditions_de_composition" permet de réaliser cette fonction de filtre. Le système
décrit est imperméable aux bruits (faux événements) grâce à ce mécanisme de flItres.
Le deuxième problème posé par cette approche est l'ordonnancement des événements.
Les systèmes distribués n'ont pas d'horloge globale. Ce problème peut être résolu par
l'estampillage des événement avec l'heure locale du processus. On arrive à créer un
ordre partiel des événements de base. Cet ordre peut être rendu total par les horloges
logiques dites de Lamport [72]. Cheng [39], Bates [24] et Lin [80] proposent cette
technique pour l'ordonnancement des événements de base. Mais cet ordre total sur les
événements de base redevient un ordre partiel pour les événement composés car l'heure
locale perd sa propriété d'ordre, comme le montre l'exemple suivant.
Exemple:
Des événements de base eVi issus d'un même processus sont étiquetés de l'heure locale
au processus; ils sont des composants de deux événements El et E2. Le symbole '&'
désigne la conjonction.
El = eVI«lO»
& eV2«l5»;
E2 =eV3«l2»
& eV4«l3»
& eV5«l6»
Les événements de base eVi dont la conjonction compose les événements El et E2 sont
totalement ordonnés par l'heure locale alors que El et E2 sont incomparables.
15.
Cbapi~ 1.

---

Le troisième problème est le partage d'événements, car deux événements peuvent
partager les mêmes composants. Plusieurs événements peuvent donc se recouvrir
rendant ainsi la reconnaissance laborieuse. Les événements composés perdent la
précision qu'ont les événements de base, et généralement l'observation ne porte pas sur
ces derniers. La granularité (temps introduit pour enregistrer les événements de base) est
aussi un facteur de pénalité. Le choix des parties du SMAP à distribuer est un autre
facteur décisif de l'efficacité.
L'efficacité d'un SMAP construit suivant cette approche dépendra de la manière dont
ces divers problèmes ont été résolus.
Un tel SMAP étant totalement passif,
l'interaction avec le système est univoque. Elle se réduit à la communication des
événements de base. Les fùtres permettent de réduire le flot d'informations, mais cela
appauvrit l'observation.
Le SMAP peut être activé autant de fois que nécessaire. La détection des erreurs se fait
à moindres frais,
et elle peut se dérouler sur un autre site car elle est indépendante de
l'environnement d'exécution du programme parallèle dont est issue les traces
d'événements.
m.3. Reprise de l'exécution.
Les traces peuvent être utilisées pour reprendre partiellement ou totalement l'exécution
d'un programme, interrompue à cause d'une anomalie. Elles servent alors soit à recréer
le schéma d'exécution [78], soit à reconstituer l'état du système à un moment donné [38]
[52] [67] [105]. La première approche utilise les traces d'événements, et la seconde, les
traces d'états du système.
m.3.t. Reprise totale de l'exécution.
En recommençant l'exécution suivant le même schéma, on peut espérer retrouver les
erreurs rencontrées lors de la première exécution. Plus précisément, pendant
la
première exécution, on mémorise l'ordre partiel d'accès aux variables partagées et les
choix non-déterministes. On retrouve le schéma d'exécution en exhibant le même
ordre et les mêmes choix lors de la ré-exécution. Cette approche est utilisée par
Leblanc [78] et appelé Instant Replay (IR). L'objectif visé par Leblanc est de rendre
vraie l'assertion suivante, dans l'hypothèse d'un langage avec partage d'objets :
16.
Chapitre 1.

---

Assertion : Dans un programme parallèle, si chaque processus a invariablement les
mêmes données en entrée, il produira toujours les mêmes résultats, et l'ensemble des
processus s'exécutera selon le même schéma.
Pour cela on enregistre l'ordre partiel des événements importants lors de la première
exécution, et on reproduit le même ordre lors de la ré-exécution. On associe à chaque
objet partagé un ordre partiel des accès, ce qui permet de sérialiser les opérations
d'accès aux données lors de la ré-exécution. L'utilisateur doit s'assurer de pouvoir
reconstituer le même environnement lors de la reprise de l'exécution.
Mais Leblanc a restreint l'accès en écriture d'une variable à un seul rédacteur.
L'exclusion mutuelle aurait pu être assurée par moniteur ou sémaphore. On aurait
étendu alors cet ordre au cas où plusieurs rédacteurs modifiaient la même variable.
Dans ce cas, l'ordre entre rédacteurs lors de la reprise de l'exécution aurait été total.
Cette méthode est applicable aux langages tels que C-NET [2] et OCCAM utilisant la
commande gardée de Dijktra [45].
m.3.2. Reconstitution de l'état d'un système.
Un certain nombre de SMAP permettent de reprendre partiellement l'exécution d'un
système de processus à partir de vues enregistrées [38] [52] [54] [67] [105]. Dans
BugNet [38] [67], la reprise peut porter sur un seul processus. Le processus TRACE
associé au processus qu'on veut relancer restaure l'état de celui-ci, et, quand il veut
communiquer, le processus TRAP associé restitue les messages enregistrés lors de la
première exécution. Cette stratégie permet par exemple de comparer les messages
qu'émet le processus avec ceux qui ont été enregistrés.
Dans le système Recap [l05], créer une vue revient, pour un processus, à mettre une
copie de lui même sous forme de processus en attente. Revenir en arrière consiste alors
à activer la bonne image. La détection des erreurs dans Agora [54] est faite en
visualisant les variables du système lors de la reprise de l'exécution.
m.3.3. Remarques.
Pour reconstituer l'état du système à partir des pages mémoire, on détermine les pages
correspondant au point de reprise, et on les restaure. Elles doivent contenir tout le
contexte d'exécution des processus actifs à ce moment [38] [52] [67], à savoir le code,
les données, les piles d'exécution et les registres. Pour les fichiers, ces pages doivent
comporter leurs descripteurs. Le problème devient moins évident pour un système
17.
Chapitre 1.

---

temps réel. Par exemple si un processus reçoit régulièrement la température d'une
pièce, une telle information devient incontrôlable lors de la reprise. L'utilisateur doit
prévoir des procédures pour assurer la reprise dans ces cas.
Cette approche demande une forte intervention au niveau du système d'exploitation.
Par exemple, il faut disposer d'un chargeur pour recréer les processus en mémoire, d'un
gestionnaire de pages mémoire qui soit accessible, d'une horloge globale (à moins
qu'un algorithme ne gère les points de prise de vues), et d'un gestionnaire de fichiers
donnant accès à leurs descripteurs.
La prise de vues doit être accompagnée de l'enregistrement d'événements à caractère
non-déterministe pour permettre de retrouver le même schéma d'exécution, car en
général on reprend l'exécution dans l'espoir de reproduire les mêmes erreurs. Dans
BugNet [67] par exemple, on enregistre les communications.
Comme nous le suggérions dans le paragraphe II.3, si on supprime régulièrement les
vues les plus anciennes, on peut contrôler l'espace d'enregistrement de traces, et même
garder sa taille constante. Cela aura pour conséquence de limiter la reprise de
l'exécution aux vues les plus récentes. Mais cela permet de faire la première exécution
sans se soucier de l'espace d'enregistrement de traces.
IV. Analyse statique et traces.
Comme le souligne Hoare dans son étude des traces [58], l'ensemble des traces d'un
processus est connu d'avance. Cet ensemble est décrit par le modèle du processus. Un
modèle de processus décrit l'ensemble de comportements que pourront prendre ses
instances, les processus. A partir de l'analyse statique du code source, on peut obtenir un
ensemble d'informations sur le comportement du programme [31]. Ce comportement
peut être modélisé sous forme de graphe des états [17] [31] [36], ou sous forme de
graphe des événements [31] [17] [50] [120]. Le modèle ainsi obtenu peut être utilisé
avec des traces, pour comparaison avec le comportement effectif du programme [31.1
[36].
Dans le cas SMAP Idéfix [31.1, l'analyse statique permet de repérer les branches de code
inexécutables, ou les variables non initialisées. Elle permet également de construire le
graphe de contrôle et le graphe de synchronisation de chaque modèle de processus.
Après l'exécution, ces graphes sont comparés avec aux traces obtenues du programme.
18.
Chapitre 1.

---

Dans le modèle de Cheng [36], l'analyse statique permet de modéliser le comportement
du processus sous forme de réseau de Pétri. Les traces permetent de valider ce
comportement après l'exécution du programme.
Les propriétés statiques que doit vérifier le programme source, peuvent se refléter sur
le graphe des états ou le graphe des événements [17] [50]. Ces graphes peuvent alors
permettre de mettre en évidence certaines anomalies. Nous allons présenter deux
exemples de modélisation d'un processus sous forme de graphe, le modèle de Appelbe
[17] et celui de Ernrath [50].
IV.1. Arbre des états.
Dans l'approche de Appelbe [17], l'arbre de synchronisation d'un programme parallèle
(Concurrent History Graph, dans sa terminologie) est un arbre dont les nœuds sont les
points de synchronisation des tâches, et dont les arcs représentent les transitions de la
synchronisation. Soit par exemple le programme modélisé par le schéma de contrôle
suivant (fig. 3) :
-Figure 3-
Modèle de programme.
Schéma de synchronisation d'une tâche "Main" qui crée n sous-tâches et continue en
séquence jusqu'au point de synchronisation
X.
Chaque sous-tâche s'exécute en
séquence jusqu'au point de synchronisation Y.
L'arbre des états correspondant pour trois tâches est donné par la figure 4 : une tâche
principale m, et deux sous-tâches st! et st2. Chaque rectangle représente un état possible
du système. Chaque lettre dans un rectangle correspond à l'état de synchronisation d'une
tâche donnée. Les tâches sont supposées ordonnées. Nous avons factorisé certains états
pour gagner de la place :
19.
Chapi1re 1.

---

o
-Figure 4-
Concurrent history graph.
Sur cet arbre, la tâche principale m est lancée (état 0). Dans l'état 1, elle crée deux sous-
tâches, inactives (S). Dans l'état 2, m se trouve dans le bloc X, alors que les deux sous-
tâches restent inactives. Dans l'état 3, la tâche stl que m vient de créer exécute le bloc
Y, alors que st2 est inactive. Dans l'état 7, tous les trois tâches sont actives, m exécute le
bloc X, st! et st2 exécutent le bloc Y.
Comme on peut le constater, chaque branche de cet arbre correspond à un schéma
d'exécution possible du programme, c'est à dire à une trace des états possibles du
système.
Un tel arbre devient très vite complexe et est soumis à l'explosion
combinatoire. Appelbe [17] propose une solution qui consiste à regrouper certains
nœuds en un état virtuel. On remarque par exemple qu'il y a une ressemblance entre les
rectangles 3 et 4 ou 5 et 6 sur notre exemple. On peut alors factoriser ces états en un état
virtuel.
Selon Appelbe, sur un tel arbre, les interblocages et attentes infmies se traduisent par
des nœuds qui n'ont pas de successeurs et ~~ ont des tâches actives. Si pour chaque
nœud de l'arbre, les processus sont étiquetés par les.y,ariables partagées qu'ils utilisent,
la présence dans un même nœud de deùx processùs' actifs qui ont la même étiquette
indique une concurrence d'accès potentielle.
IV.2. Graphe des événements.
Comme l'indique Emrath [50], un programme pàrallèle peut être modélisé par un graphe
de blocs. L'échange de messages avec synchronisation et la dépendance de données
induisent un ordre partiel entre ces blocs.
On sait construire le graphe orienté
20.
Chapitre 1.

---

correspondant à cet ordre. Deux blocs de ce graphe sont ordonnés s'il y a un chemin
de l'un vers l'autre. Deux blocs non ordonnés peuvent être exécutés en parallèle,
Exemple : (C_NET [2])
Un processus qui crée trois ms et imprime un résultat. Deux des fils communiquent par
le canal p.
process p_model_name 0 {
int
z = 2;
channel p;
/* canal de communication entre processus */
PAR {
{ int x = z;
send(p. x);
}
{ int x;
recv(p. x);
z= x * x;
}
z = 0; }
}
print(z);
}
Voici le graphe de la relation d'ordre partiel des blocs de ce programme:
3
B
5
6 ....
.....
-Figure S-
Graphe de la relation d'ordre partiel des blocs.
Notons "m -+ n" la relation
[m doit être exécuté avant n]. Par cette relation, on a
l'ordre partiel suivant entre les blocs de la figure 3 : (0 -+ l, .. " 6) et (l -+ 4)
et
(l -+ 5) et (2 -+ 5) et (0, .., 5 -+ 6). On a 1 -+ 5 à cause de l'échange de message
entre les blocs 2 et 4. Et on a 1 -+ 4
et
2 -+ 5 à cause de la dépendance de données
sur x. Un bloc ni représente le comportement du processus Pi.
21.
Cbapilrc 1.

---

Si deux blocs non ordonnés accèdent à une même variable de manière conflictuelle
(lecture/écriture, écriture/écriture)
alors il y a risque de non-déterminisme et de
concurrence d'accès. Sur la figure précédente par exemple, on remarque que le bloc 3
accède à la variable z de manière conflictuelle avec les
blocs 1 et 5, et que le
résultat imprimé (0 ou 4) par la fonction print sera non-déterministe.
Pour détecter de tels conflits, on étiquette chaque nœud par la liste des variables
partagées que le bloc correspondant utilise, avec le type d'accès (lecture, écriture). TI
suffit alors de faire des comparaisons de listes en tenant compte de l'ordre partiel des
blocs. On peut aussi associer à chaque variable la liste des blocs qui l'utilisent. On
vérifie alors pour chaque bloc s'il n'est pas en concurrence avec ses prédécesseurs dans
la liste. Cette dernière stratégie est plus efficace que la précédente car on n'attend pas
d'avoir construit toutes les listes pour détecter les conflits.
RemarQ.ues :
Le graphe des événements peut être réduit à une catégorie donnée d'événements. Sur la
figure précédente,
on aurait pu ne retenir par exemple que les instructions de
communication. Taylor [120] par exemple, se base sur les instructions de
synchronisation et propose un algorithme qui permet à partir du graphe de
synchronisation de processus, de faire une analyse statique d'un programme parallèle
pour détecter entre autres les interblocages. Mais la complexité de tels graphes est
rebutante.
L'analyse statique peut être utile pour les langages qui acceptent le partage d'objets.
Mais certains partages peuvent être cachés et indétectables, c'est le cas des pointeurs
avec conversion de types, par exemple dans le langage C parallèle de Logical Systems.
L'analyse statique signale des erreurs potentielles que seule l'exécution peut confirmer;
d'où la nécessité d'une utilisation conjointe avec un outil d'analyse dynamique [17] [31].
L'analyse statique est bien adaptée aux langages avec parallélisation automatique
faite à la compilation, tel est le cas de certains compilateurs fortran [124].
v. Synthèse et discussion.
Dans les trois sections précédentes, nous avons présenté les divers aspects des traces de
l'exécution pour le déverminage de programmes parallèles. Dans cette dernière section,
nous allons mener une discussion sur les différentes approches exposées dans les
22.
Chapitre 1.

---

sections précédentes, nous allons notamment montrer les principaux problèmes liés à la
mise en œuvre de ces approches.
V.1. Analyse statique.
Ce moyen de déverminage des programmes parallèles est très peu utilisé car il n'est pas
pratique, et cela pour cinq raisons. La première est que les erreurs potentielles qu'il
permet de repérer ne peuvent être confirmées que par l'exécution du programme.
L'analyse statique se base presque exclusivement sur la modélisation du comportement
du programme sous la forme de graphes construits à partir du code source (graphe des
états [17], graphe de synchronisation des processus [31], graphe de contrôle [31], réseau
de Pétri [36]). Mais, et c'est là notre deuxième raison, ces graphes sont difficilement
exploitables de par leur complexité; l'exemple du paragraphe IV.l nous en donne un
aperçu avec le CHG de Appelbe [17].
La troisième, comme le souligne Caillet [31], est que l'analyse statique ne permet pas de
distinguer les chemins exécutables de ceux qui ne le sont pas. La quatrième raison est
que certaines erreurs liées au partage des variables ne sont détectables qu'à l'exécution,
citons notamment l'accès à un même élément d'un tableau ou d'une structure. Ces
erreurs ne peuvent être détectées qu'en enregistrant les traces des accès à ces variables.
Enfm, la cinquième raison est que le modèle ne représente jamais qu'un sous ensemble
des comportements possibles du programme, ce qui peut être une limitation sévère.
TI reste que la combinaison de l'analyse statique avec l'analyse dynamique permet
d'obtenir de bons outils de déverminage. Cela se traduit actuellement par un couplage
étroit entre le SMAP et le compilateur [119]. Des exemples la combinaison de l'analyse
statique avec l'analyse dynamique sont IDEFIX, décrit par Caillet [31] et le modèle de
Chang [36].
Dans IDEFIX, chaque modèle de processus est représenté par son graphe de contrôle, ce
qui en limite la complexité. Les traces servent à rechercher par élimination, dans ces
graphes, les chemins compatibles. La difficulté est d'assurer l'unicité de ces chemins,
c'est à dire qu'à une ligne de contrôle (un processus) doit correspondre un chemin
unique dans le graphe du modèle de processus associé. Enfm, le modèle limite le champ
d'investigation des erreurs par rapport à la quantité des informations que peuvent fournir
les traces. Dans l'approche de Chang [36] par exemple, le modèle en réseaux de Pétri ne
sert qu'à vérifier si toutes les communications sont réalisables.
23.
Chapitn: 1.

---

On peut également associer un SMAP statique
à une analyse dynamique pendant
l'exécution,
par exemple pour comparer dynamiquement un schéma d'exécution
potentiel avec le schéma
effectif. Un tel scénario est utilisé par Baiardi [22]. On peut
alors instantanément signaler une erreur quand elle se produit, un peu à l'image des
exception~. Mais le schéma potentiel peut ne pas correspondre au schéma effectif; et la
représentation des choix et des boucles peut compliquer la spécification de ce schéma.
V.2. Composition des événements.
C'est de loin la voie la plus utilisée pour le déverminage de programmes parallèles [24]
[25] [31.1 [32] [36] [39] [51] [60] [61] [80] [106] [113] [127]. L'analyse post mortem
qu'elle implique est peu coQteuse à mettre en œuvre, pour peu que les traces soient une
image fidèle de l'exécution. L'analyse peut être recommencée à volonté. La composition
des événements permet de définir plusieurs niveaux d'observation, par exemple en
partant d'une vue globale vers des vues plus fmes. Cette classe de SMAP se prête bien à
une utilisation conjointe avec une analyse statique [17] [31] [36]. Dans les paragraphes
qui vont suivre, nous allons montrer les principaux problèmes que pose la mise en
œuvre des approches basées sur la composition des événements.
La limitation majeure des SMAP utilisant la composition des événements, est la perte
d'informations (certains détails) et l'abondance d'informations inutiles à l'analyse; ce qui
peut sembler paradoxal. Le domaine des erreurs détectables est défmi et limité par les
événements de base composant les traces. Dans ces SMAP, c'est au programmeur de
défmir les modèles qu'il juge utiles et nécessaires pour l'analyse du comportement de
son programme. Cela peut avoir un effet pervers de rendre le SMAP inutilisable. Car en
effet, dans le modèle de Bates [24] [25] qui semble représentatif de cette classe,
l'utilisateur doit connaître l'essentiel des modèles d'événements disponibles dans sa
banque pour pouvoir les utiliser; ce qui visiblement est une charge supplémentaire. En
outre si plusieurs utilisateurs partagent la même banque, cela peut créer un amalgame.
Enfin, plus l'application est grande, plus nombreux seront les modèles d'événement, ce
qui augmentera la difficulté d'utiliser le débogueur.
L'enregistrement de traces a une incidence sur l'ordonnancement des processus (process
scheduling). Du point de vue de la mise en œuvre, l'enregistrement de traces, s'il n'est
fait par un observateur [19] [67] [113], peut être réalisé avec le mécanisme de file
d'attente ou par des appels synchrones à un serveur. Dans le premier cas, chaque
processus inscrit les informations de traces dans une fue d'attente commune, sans se
suspendre, et un serveur est chargé de l'enregistrement effectif sur disque. li faut alors
24.
Chapitre 1.

---

prévoir un mécanisme pour traiter les débordements de cette flle. Dans le deuxième cas,
le processus communique ses informations par des appels synchrones au serveur disque.
Ce dernier doit être très rapide pour éviter de ralentir l'exécution et modifier
notablement l'ordonnancement des processus. EnfIn, la machine sur laquelle s'exécutent
les processus peut naturellement causer des ralentissements à cause de l'enregistrement
de traces. Dans des machines à base de transputer par exemple, le nombre limité des
liens de communication avec l'extérieur nécessite la présence d'un bus spécial par lequel
transitent les données constituant les traces, comme dans les machines SuperNode de
chez Telmat [123]. Un tel bus cependant, conditionnant la vitesse du serveur, est un
véritable goulot d'étranglement. Il est donc nécessaire de disposer d'un mécanisme
permettant d'estimer la charge du serveur pour en éviter la surcharge qui fatalement
bloquerait le système.
La datation des événements, indispensable pour leur ordonnancement est souvent
proposée en faisant référence aux horloges logiques [24] [39] [72] [80]. Or nous avons
vu au paragraphe m.2.3 que l'ordre total qu'elles fournissaient sur les événements de
base redevenait un ordre partiel pour les événement composés car l'heure locale perdait
sa propriété d'ordre. Une horloge globale pour tout le système serait la solution idéale,
mais les systèmes distribués n'en disposent pas. Une solution honorable consiste à
recaler les horloges physiques à partir d'une horloge de référence, solution envisageable
dans une machine ayant un bus de contrôle comme dans le SuperNodeH23].
Une autre limitation de la composition des événements, comme le souligne [106]
Hseush et Kaiser, est qu'elle ne permet pas d'exprimer correstement les contraintes de
temps. De ce fait, les systèmes utilisant cette approche ne sont pas adaptés aux
programmes temps réel.
V.3 . Reprise de l'exécution.
Les approches de reprise de l'exécution que nous avons présentées ne sont pas des
moyens de détection d'erreurs. Pour une analyse in vivo, on peut les utiliser avec des
points de contrôle pour pouvoir observer l'évolution des processus par exemple. Sinon,
pendant la reprise, on peut enregistrer des trace d'événements pour permettre une
analyse post mortem. Nous allons dans les paragraphes suivants, montrer un ensemble
de problèmes liés à la reprise de l'exécution et la prise de vues.
La reprise de l'exécution ne permet malheureusement pas de reproduire les erreurs liées
à la concurrence, pourtant très fréquentes avec les programmes parallèles. Cela à cause
25.
Chapitre 1.

---

du changement de l'ordonnancement des processus d'une exécution à l'autre. En fait,
comme c'est noté dans [1], la reprise ne reproduit pas la même exécution, mais, au
mieux, une exécution équivalente. C'est à dire une exécution respectant un ensemble de
propriétés de l'exécution précédente; par exemple, reproduire les mêmes
communications dans le même ordre.
Reprendre une exécution dès le début peut être une pénalité considérable, voire une
démarche difficile à envisager. La prise de vues permet de réduire ce temps,
car la
reprise se fait en certains points de l'exécution. Si l'on veut retrouver le même schéma
d'exécution des processus, il faut alors garder les traces des choix non-déterministes et
l'ordre d'accès aux variables partagées [78].
Le mécanisme de prise de vues doit assurer la cohérence du système, c'est à dire assurer
la validité des horloges temps réel [38], la préservation des événements de nature
asynchrone tels que les interruptions, et la préservation des messages en cours de
transmission quand la prise de vues intervient. La synchronisation des processeurs pour
une prise de vues simultanée n'est envisageable que sur des machines disposant d'un
processeur maître, comme le SuperNode [123] qui a un transputer et bus de contrôle.
Dans Bugnet, en plus des vues, on enregistre les communications, ce qui permet la
reprise d'un seul processus, et la comparaison entre les messages enregistrés et ceux
qu'il peut avoir à émettre. Mais, et de manière plus générale, la reprise de l'exécution
peut masquer certaines erreurs à cause du parallélisme des processus (erreurs non
reproductibles), nous pensons par exemple à la concurrence d'accès à une variable entre
deux processus dont l'ordre d'exécution change entre deux exécutions consécutives. Une
solution à ce problème ne peut être envisageable qu'en adoptant une approche semblable
à celle de Leblanc [78].
La reconstitution du contexte d'exécution lors de la reprise est un problème très délicat.
Par exemple, dans le cas du modèle du système Recap [105] qui semble fort séduisant,
l'activation d'une copie d'un processus suspendu nécessite la restauration des mémoires
du processus correspondant. Quand des contraintes temps réel s'en mêlent, la tâche est
alors difficile à négocier. La prise de vues et la reprise partielle de l'exécution sont une
solution qui peut se révéler fort co(l~use et c'est de loin l'approche la plus complexe à
mettre en œuvre.
26.
Chapitre 1.

---

VI. CONCLUSION.
Nous voici arrivés au terme de ce chapitre. Tout le long nous nous sommes efforcés de
faire ressortir l'aspect fondamental des principales approches actuelles de mise au point
des programmes parallèles, utilisant les traces. La mise en œuvre d'un SMAP est un
problème dont on connaît d'avance bon nombre de limitations. Le non-déterminisme
lors de la reprise de l'exécution est levé en utilisant les traces des événements et les
choix à caractère non-déterministe. Mais l'enregistrement de ces traces conduit à la
saturation de la mémoire. TI serait donc dérisoire de dire qu'une technique est meilleure
qu'une autre dès lors que toutes sont basées sur les traces de l'exécution. Mais on peut
dire en revanche que telle technique est plus efficace qu'une autre pour résoudre telle
classe de problèmes.
Ainsi les SMAP à composition d'événements minimisent le temps de détection
d'anomalies, mais ceci contre une perte de place et de détail de l'exécution, et une
granularité qui n'est pas fine. La reprise totale corrige ces inconvénients mais ce au
détriment du temps. Entre les deux, la prise de vues semble se poser en médiane. Mais
sa complexité est à elle seule dissuasive; et le temps de prise de vues n'est pas un facteur
négligeable dans le déroulement d'un programme, avec une granularité grossière.
L'association de diverses approches [31] [53] [68] donne de bons outils de mise au
point et ce n'est pas une maigre consolation. Le choix d'une approche est étroitement lié
au type de problèmes pour lesquels le futur SMAP est destiné. Mais on se rassurera en
gardant à l'esprit qu'un SMAP n'est jamais qu'un outil d'aide à la mise au point et non
pas une panacée.
27.
Chapitre 1.

---

,

---

Chapitre 2.
Construction d'horloges globales pour les
machines Parallèles.
1. Introduction.
Une base de temps commune à tous les nœuds d'une machine parallèle est
unanimement considérée comme indispensable. A cela, plusieurs raisons. Une horloge
globale permet de développer des algorithmes comportant des contraintes temps réel
(temporisation, détection de la terminaison, exclusion mutuelle) [65] [70] [75] [107]
[109]. Elle permet de synchroniser les processeurs pour réaliser une action collective en
même temps, ou pour prendre une décision au même moment (e.g. élection) [21] [75]
[107]. Elle permet d'effectuer des mesures sur différents nœuds sur la même base (e.g.
performances) [65] [118] [128]. Enfin, pour la mise au point des programmes
parallèles, une horloge globale permet de définir des points d'arrêt et d'établir une
relation temporelle entre les événements [21] [86] [87] [109].
Le problème des horloges comporte trois aspects dégagés par Lamport :
synchronisation des horloges physiques [72], tolérance aux pannes [76], relation de
causalité [72]. Le premier aspect se rapporte à la construction d'une base commune de
temps (horloge globale) entre les nœuds d'une machine parallèle en synchronisant les
horloges physiques de ces nœuds. Le deuxième aspect, la tolérance aux pannes,
concerne le comportement d'une horloge globale en présence de pannes. Enfin, le
troisième aspect, la relation de causalité, concerne l'ordre partiel entre les événements
qui doit être respecté par l'ordonnancement de ces événements avec l'horloge globale.
Dans ce chapitre, nous nous intéressons uniquement à la synchronisation des horloges.
Le lecteur intéressé par la relation de causalité se rapportera à [1] [44] [72] [86] [87].
De même, les aspects se rapportant à la tolérance aux pannes sont traités dans [46] [75]
[76] [84] [116].
La solution la plus répandue pour construire une horloge globale consiste à
synchroniser régulièrement les horloges physiques du fait qu'elles dérivent entre elles.
D'autres techniques de construction d'horloges globales existent. fi s'agit pour l'essentiel
de l'horloge de Lamport présenté par le premier algorithme dans [72]; et l'horloge
vectorielle de Mattem [86] [87]. Ce sont en fait des techniques de numérotation qui ne
29.
Chapitm 2.

---

mesurent pas le temps. C'est pourquoi nous n'y nous sommes pas intéressés. La
synchronisation se fait soit par logiciel, soit avec un matériel dédié, ou en associant les
deux méthodes.
Ce chapitre est une synthèse des techniques de synchronisation des horloges. Notre
objectif en faisant cette étude a été de faire un tour d'horizon des principales techniques
de synchronisation des horloges pour déterminer laquelle pouvait être efficacement
implémentée dans notre environnement. D'autres travaux de synthèses ont été réalisés
avant le nôtre. La synthèse présentée dans [114] ne contient pas les derniers
développements sur la synchronisation des horloges comme ceux de [42] et [65]. Celle
qui a été effectuée dans [108] porte spécialement sur la tolérance aux pannes. Enfin, la
synthèse de [66] qui pose bien le problème de la synchronisation des horloges n'analyse
cependant pas toutes les principales techniques de synchronisations des horloges; en
particulier les techniques de synchronisation mises en œuvre dans les algorithmes
tolérance aux pannes; ainsi que la synchronisation par le matériel et la synchronisation
hybride.
La deuxième partie de ce chapitre présente les concepts et les principales propriétés de
la synchronisation des horloges utilisés dans cette thèse, conformément à la littérature.
La troisième partie est une synthèse des techniques de synchronisation des horloges.
Elle analyse leurs avantages et limitations. Enfm, la quatrième partie est une discussion
de ces techniques.
Il. Concepts de synchronisation des horloges.
Cette partie présente les principales notions des horloges utilisées dans cette thèse.
Nous donnons les concepts de base, les contraintes pouvant limiter la synchronisation
des horloges, et présentons un ensemble de propriétés caractérisant les horloges d'après
la littérature que nous avons consultée.
D.l. Notions de base.
II.!.!. Le temps.
Toute mesure du temps suppose la présence de deux types de temps. Le premier est le
temps réel, continue, non observable et newtonien. C'est le temps de référence
théorique. Le temps réel est un sous-ensemble dense de l'ensemble 9t des réels. Le
deuxième est le temps physique, discret, observable à partir d'une horloge physique.
30.
Chapitte 2.

---

II. 1.2. Horloie et dérive.
Une horloge est défmie comme étant une fonction C qui au temps réel t associe le
temps physique T; C(t) = T, est le temps physique associé au temps réel t par l'hQrloge
C. L'inverse c de cette fonction est encore une horloge [75]; c(T) =t, est l'heure réelle
au moment où l'horloge c indique T.
Dans ce chapitre, nous prenons les conventions suivantes, qui désignent ce que nous
appellerons un système d'horloges C C désignera une horloge quelconque. Les horloges
étant numérotées de 1 à N, Ci et Cj désignent les horloges de numéro i et j
respectivement. Nous supposons que chaque processeur i dispose d'une horloge Cio et
qu'il existe un réseau reliant tous les processeurs. Nous emploierons souvent les termes
"bonne horloge" et "bon processeur" pour désigner l'absence de pannes.
q(t) = (l + p)t
T
---
p=O
C (t) = (1 - p)t
J
Ci (0 = (l + p)t
R
Oock
C(t) = t
time
ideal clock
Real time
r
~I
-Figure 1-
Temps réel et dérive.
-Figure 2-
Synchronisation. période. dérive.
L'horloge physique de chaque processeur est en général un oscillateur à quartz. De ce
fait, elle dérive par rapport au temps réel t d'un facteur <I>(t) tel que:
•
C(t) = t + <I>(t).
(RO)
Pour une bonne horloge, la dérive est considérée par Lamport [72] comme une fonction
linéaire du temps: <I>(t) = pt; où p est le coefficient de la dérive. Ce qui donne (fig. 1) :
•
C(t) = (1 + p)t.
(R!)
Comme en général p est très petit (de l'ordre de 10-6), et compte tenu de la
décomposition en série de Taylor : - 1
1
= 1 - p + p2 - p3 + p4 - ..., dans les cal~uls,
+p
on ignore les termes d'ordre supérieur ou égal à2: p2, p3,... On a alors:
1
1
•
-1-
".. 1 - p
et
-1-".. (l + p).
(R2)
+ p
- p
31.
Chapiœ 2.

---

On remarquera que si deux horloges Cï et Cj dérivent de p par unité de temps réel, alors
la dérive maximale de l'une par rapport à l'autre est 2p (fig. 1).
0.1.3. Synchronisation des horl0ies ; période et précision.
Les horloges physiques des différents nœuds dérivent entre elles. A cause de cette
dérive, il est nécessaire de les synchroniser périodiquement; ce qui revient à construire
des horloges logiques telles que tous les sites aient la même heure logique [65]. En
plus de l'horloge physique, chaque processeur dispose alors d'une horloge logique,
l'ensemble desquelles formant l'horloge globale. L'horloge logique avance en même
temps que l'horloge physique, sauf quand on la resynchronise [70] (fig. 2). On peut
considérer la resynchronisation comme le fait de démarrer une nouvelle horloge [21].
La synchronisation des horloges physiques est le principe de base de la plupart des
horloges globales.
Deux horloges Ci et Cj sont dites ~synchronisées dans un intervalle [d, t2] si on a :
•
"if t E [tl, t2]; ICi(t) - Cj(t)1 s: 6.
(R3)
Les horloges d'une machine parallèle sont dites ô-synchronisées, si elles sont deux à
deux 6-synchronisées; 6 est la précision de l'horloge globale ainsi construite. Pour tout
6 donné, il existe une taille maximale r de l'intervalle [d, t2] au delà de laquelle R3
n'est plus respecté. TI faut donc resynchroniser les horloges à la limite de cet intervalle.
Resynchroniser les horloges revient alors, à la fm de la période, à appliquer un terme de
correction ç à chaque horloge logique de sorte que pour la prochaine période, les
horloges logiques vérifient R3. Cette correction peut être appliquée de manière
instantanée (fig 2, lignes brisées en gras) ou continue (fig 2, traits externes). La
construction de ç et la manière dont il est appliqué diffèrent selon les algorithmes. Nous
noterons R la période (temps qui s'écoule) entre deux synchronisations consécutives.
n.lA. Relation entre précision. dérive et période.
Soit C un système d'horloges 6-synchronisées, dont la dérive maximale par rapport au
temps réel est pt. Deux horloges quelconques ont un écart maximal l'une de l'autre dans
un intervalle de temps réel [tl, t2], si elles dérivent inversement; c'est à dire que l'une
dérive de pt et l'autre de -pt par rapport au temps réel (fig. 2) :
':t Ci E C, Cj E C, ':t tE [d, t2];
ICï(t) - Cj(t)1 s: 6
~ I(l+p)t-(l-p)tl S;6
~. 12ptl S; 6.
TI existe un réel r ~ 0, tel que 2pr =6 ~
•
6
(R4)
r= 2p'
32.
Chapi~ 2.

---

Le terme r est la borne supérieure de la période de temps réel au bout duquel les
horloges doivent être resynchronisées pour Bet p donnés. Comme chaque horloge peut
dériver au maximum de pr du temps réel pendant cette période. il faut donc que la
période de temps physique R soit: R ~ (l + p)r. En remplaçant r. nous obtenons une
borne supérieure de la période de synchronisation des horloges pour une précision Bet
une dérive maximale p données (fig. 2) :
•
R~ (l ;pp) B.
(R5)
ll.2. Problèmes liés à la synchronisation des horloges.
La synchronisation des horloges dépend de quatre paramètres: dérive p, précision Ô,
temps de communication ~, et période de synchronisation R. Nous avons vu que la
période est liée à la précision et à la dérive (RS). Nous allons examiner la contribution
de chacun des trois autres paramètres à la synchronisation des horloges.
II.2.1. Le temps de communication.
En pratique et selon Lamport [72], dans la formule (R3), on ne peut pas connaître
simultanément Ci et Cj à l'intérieur du système. On est obligé connaissant l'un, d'estimer
l'autre par envoi de message. Or le temps de communication ~ est une variable aléatoire
dont on ne connait pas toujours la distribution, et qui dépend de trois variables
aléatoires: le temps d'accès au réseau, le temps de transfert, et le temps de livraison du
message au destinataire. De cette variation va dépendre la précision de la
synchronisation. Cela est illustré par la figure 3 tirée de [70]. Un processeur envoie à un
autre, un message avec une date d'émission. Le second reçoit le message ~ unités de
temps après et cherche à estimer l'heure actuelle de l'émetteur. La valeur ~ n'étant pas
connue, elle est estimée avec ~, qui varie entre ~min et ~max. Ce qui donne une erreur
maximale E dans l'appréciation de ~. Le terme E est appelé erreur de lecture, car c'est
l'erreur commise par le second processus pour lire ou estimer l'heure du premier
processus. Un théorème démontré dans [83] dit que:
Théorème 1. Si N est le nombre de processeurs; E,l'erreur de lecture; et B,la précision:
1
•
E(l - N) ~ Bmin.
(R6)
Autrement dit, la variation du temps de communication introduit une limite à la
précision avec laquelle on peut synchroniser des horloges. C'est à dire que E(l - lIN) est
la meilleure précision qu'on peut atteindre en synchronisant. N horloges avec une
variation Edu temps de communication. même s'il n'y a ni panne ni dérive.
33.
Chapitre 2.

---

li Y a une probabilité non nulle qu'un bon message ait un délai Ll plus grand que Llmax
qui est une valeur fIxée par le programmeur. Lors de la synchronisation, on sera donc
amené à rejeter des messages de bons processeurs, dont le délai estimé est supérieur à
â max. Un bon algorithme de synchronisation des horloges doit minimiser le nombre de
ces messages.
date de....réception
,
/
ê
date d'émission
1'"
·1
Emin
1
1'"
·1
1
1
1
Ll'
1
mm
1
1
1
t
Llest
1
1
1
1
â
1
1
â max 1
-Figure 3-
Délai de communication, erreur de lecture.
II.2.2. La dérive.
Tout comme l'horloge physique, l'horloge globale a une dérive. Celle-ci est souvent une
constante choisie comme le maximum des dérives des horloges physiques. Un théorème
démontré dans [118] dit que:
Théorème 2. Pour n'importe quel algorithme de synchronisation des horloges, même
en l'absence de pannes, la borne p du coeffIcient de la dérive de l'horloge logique par
rapport au temps réel est toujours plus grande que la borne y des dérives des horloges
physiques:
•
y~p.
(R7)
L'algorithme de synchronisation des horloges doit donc chercher à rapprocher p de y.
II.2.3. La précision.
Plus le terme fi de la formule R3 désignant l'écart maximal entre deux horloges sera
grand, moins bonne sera la précision de l'horloge globale; c'est à dire que l'horloge
différenciera moins les dates d'occurrence des événements. Plus précisément, l'horloge
globale est souvent utilisée pour la datation des événements, af'm d'établir entre eux une
relation temporelle. Mais la précision de cette horloge introduit une limite à cet
ordonnancement, et cela à deux niveaux.
Au niveau local, l'horloge globale peut ne pas permettre d'ordonnancer totalement tous
les événement d'un même processeur du fait que plusieurs événements peuvent se voir
affecter la même date. En effet, la précision d'une horloge globale ne peut pas dépasser
celle des horloges physiques.
Or même avec l'horloge physique, dans le même
34.
Chapitre 2

---

processeur, il peut être difficile de dater les événements avec une précision qui respecte
leur ordre total d'occurrence. C'est le cas par exemple du transputer, dont l'horloge de
basse priorité a un cycle de 64 ilS, et celle de haute priorité, un cycle de 1 ilS, alors que
le cycle de base du processeur est à 50 ns.
Au niveau global (ensemble des processeurs), sont considérés comme simultanés, les
événements survenus dans des processeurs différents, et dont l'écart entre les dates
d'occurrence est plus petite que la précision. Or plus faible est la précision, plus grand
est le nombre d'événements jugés simultanés. En d'autres termes, la précision détermine
la capacité d'ordonnancer les événements. Ce problème peut être relié à celui de la
préservation de la relation de causalité [72].
fi.3. Propriétés des horloges globales.
Les propriétés caractérisant une horloge globale varient d'un auteur à un autre. Nous en
proposons ici une synthèse résumant ce que nous venons de présenter. Dans ces
propriétés, Cest un système d'horloges, et '1'un intervalle de synchronisation de taille R
[42] [47] [72] [75] [83] [107] [108] [116] [118] [125] :
• Toute horloge C doit être une fonction croissante du temps réel. L'heure globale doit
être chronoscopique, c'est à dire qu'elle doit permettre de mesurer de petits intervalles
de temps:
'li C €
C. 'li t € 9t, 'li d> 0: C (t) S; C (t + d).
(Pl)
Mais comme les horloges sont en général des fonctions discrètes, Pl devient:
'li C €
C. 3 g ~ 0, 'li t € 9t. 'li d ~ g: C (t) ~ C (t + d).
(Pl')
• L'écart entre deux horloges quelconques de C, est borné à tout moment. C'est à dire
que la différence des temps indiqués par deux horloges distinctes pour mesurer le même
événement en temps réel, doit être bornée :
36 € 9t+, 'li Ci €
C. 'li Cj € C. 'li t € '1': ICi (t) - Cj(t)1 S; 6.
(P2)
• La dérive par rapport au temps réel est bornée, et l'heure est dans une enveloppe de
temps réel (fig. 1 et 2) :
3 p €
9t, 'li C € C, 'li tl € '1, 'li t2 € '1, tl S; t2 :
(1- p)(t2 - tl) S; C(t2) - C(tl) S; (1+ p)(t2 - tl).
(P3)
• La précision est la meilleure possible, c'est à dire égale à celle des horloges physiques:
3 p € 9t. 'li t €
'1, 'li C €
C: (1- y)t S; C(t) S; (1 + y).
(P4)
35.
Cbapitm 2.

---

• Pour tout intervalle de temps réel [tl, t2], toute horloge C est une fonction monotone et
différentiable sur [Tl, T21, où C(tI> = Tl et C(tû =T2 :
"d C € C 'r/ t € [tl, t2] : d~~t)
1
- 11 < p. Cette propriété implique P3.
(P5)
• Conformément à la relation R5, si les horloges sont synchronisées par envoi de K
messages dans les dernières unités de temps de la période, et & la durée maximale de
communication mesurée par chaque horloge, alors:
R VA,;' (l+p)ô
ù'"
I d e "
d
- n.L.l
;::.
2 p ' 0 ~ est e temps
commurncatlon entre eux processeurs.
(P6)
• Une autre propriété enfin est que:
L'horloge globale ne doit pas dégrader les performances du système.
(P7)
Construire une horloge globale revient à construire un système vérifiant ces propriétés;
mais cela n'est pas toujours possibles. Les algorithmes que nous allons présenter n'en
vérifient qu'une partie. Tout algorithme satisfaisant les conditions P2-3 résout le
problème de la synchronisation des horloges posé par Lamport [75]. Une horloge
satisfaisant P2-3 est dite bonne horloge.
III. Techniques de synchronisation des horloges.
Le deuxième algorithme proposé par Lamport dans [72] permet la synchronisation des
horloges physiques au fur et à mesure que chaque processeur reçoit un message d'un
autre. Sous l'hypothèse que le temps de communication est borné par &.nm, pour chaque
message x qu'il reçoit, le nœud j ajuste son horloge Cj avec la date T(x) du message x :
•
Cj(t) =max(Cj(t), T(x) + &mm>.
Cette technique de synchronisation nécessite un système ayant des communications
fréquentes. Mais même sous cette hypothèse, la synchronisation peut ne pas être
possible si le graphe est acyclique ou s'il n'est pas fortement connexe.
Un ensemble d'algorithmes ont été développés à partir de l'idée de Lamport, et d'autres
ont cherché à s'affranchir de la communication des messages de transport de l'heure. On
peut distinguer trois classes d'algorithmes: les approches statistiques, les algorithmes
de diffusion de messages de synchronisation, et les algorithmes probabilistes. TI existe
deux autres techniques de synchronisation des horloges dont le développement est plus
récent : la synchronisation par le matériel et la synchronisation hybride. Nous allons
décrire succinctement ces techniques et dégager leurs avantages et inconvénients.
36.
Chapitre 2.

---

TIll. Approches statistiques.
L'objectif des méthodes statistiques est de réduire ou de s'affranchir de l'erreur de
lecture (R6). La méthode proposée par [55] pour réduire cette erreur consiste à eff~tuer
plusieurs échanges et à sélectionner ceux des messages qui ont le meilleur temps de
transmission pour estimer le décalage entre deux horloges.
Cette idée a ensuite été reprise par [48] afin d'estimer l'écart et la différence de
fréquence entre deux horloges. La méthode proposée consiste à déterminer l'écart entre
les fréquences des deux horloges, et à construire une fonction de correction une bonne
fois au début de l'application. L'évaluation de l'écart de fréquence se fait de la façon
suivante. On suppose que l'on connait le coefficient de dérive y pour chaque horloge
physique:
•
\\i i ~ N, 3 Yi ~ 0, ai ~ 0, ~ ~ 0: Ci(t) =ai + (1+ yJt + &ï(t) = ai + ~it + &ï(t).
Pour chaque nœud j voisin de i, il existe trois réels aij, ~j, et &ïj tels que :
•
Cj(t) = a ij + ~ijCi(t) + Ôij. Sachant que Ôij est la convolution de ôi et Ôj.
aij = q - (r:\\j / ai)
En remplaçant Cj(t) par sa valeur, on obtient le système suivant :
~j = f1./ f1.
{ &ïj =~ -f3ij Ôi
Les valeurs (aij' ~ij) peuvent être calculées par un algorithme géométrique. La dérive
entre les horloges i et j ayant ainsi été calculée au lieu d'être bornée, de même que
l'écart initial entre ces deux horloges, il n'est plus nécessaire de transmettre de message.
Jézéquel [65] a généralisé cette démarche pour construire une fonction d'horloge
globale pour un nombre quelconque de nœuds. La fonction est construite une seule fois
au début de l'exécution. Pour cela, chaque nœud i calcule (Uij, 13ij) avec chacun de ses
voisins j. On obtient un système d'inéquations:
aU < C1ij < aij
(S)
\\i Ci €
(Jo, \\i Cj € Voisins(Cü :
_
+
{ t\\j < POu < t\\j
L'objectif alors est de chercher des termes [q, a:J et [~i, ~:J solutions de toutes ces
inéquations pour chaque nœud. Pour cela, tous les nœuds voisins s'échangent les
valeurs (CXij,13ij) calculées. En suite, on élit un nœud maître. Puis, on construit un arbre
de recouvrement dont le maître est la racine. Et enf'm, on résout le système (S) .pour
chaque nœud récursivement en partant de la racine. L'heure globale obtenue est donnée
sur chaque nœud par la fonction suivante :
Ci(t) + 2-1(07 + ai )
•
JCi(t) = - - - - - -
2-1(~7 + Pi)
37.
Chapitœ 2.

---

Ayantaa:es et inconvénients.
L'horloge de Jézéquel évite les communications de synchronisation des horloges.
Cependant la phase initiale semble très longue (3OOs sur hypercube [65]), et peut faire
perdre son intérêt à cette horloge pour de petites applications. D'autre part, elle suppose
que l'on connait exactement la dérive de chaque horloge par rapport au temps réel.
EnfIn, à cause de l'erreur dans l'estimation des termes (aij, ~ij), la précision de l'horloge
se dégrade avec le temps, au point qu'il faille re-initialiser les horloges au bout d'un
certain temps [65]. Une borne de cette erreur n'est pas connue.
llI.2. Synchronisation par diffusion périodique de messages.
Le principe de ces algorithmes est que périodiquement, chaque nœud diffuse son heure
à tous les autres. En suite, chacun applique une fonction spéciale pour déterminer
l'heure globale à partir des messages reçus, après avoir éliminé ceux dont le délai de
transmission dépasse une valeur fIxée à l'avance. Ces algorithmes ont pour la plupart été
associés à la. tolérance aux pannes. Nous nous intéressons ici uniquement aux
techniques de synchronisation mise en œuvre dans ces algorithmes.
Ces algorithmes utilise le principe de Lamport pour synchroniser les horloges, mais
cette fois avec un échange de messages à intervalles réguliers. La fonction de correction
y est plus complexe. On suppose que le temps de communication est borné. Nous
distingons deux sortes d' algorithmes de diffusion périodique de messages de
synchronisation. Les algorithmes de convergence visent à maintenir les horloges aussi
proches les unes des autres que l'écart qui leur est toléré d'atteindre, cela en utilisant une
fonction d'estimation de l'écart effectif entre les horloges. Les algorithmes de
consistance se basent sur le consensus des processeurs autour d'une même valeur [76].
m.2.1. Alaorithmes de converaence.
A la date de synchronisation, chaque nœud diffuse son heure à tous. Puis il reçoit celle
de tous les autres dans un intervalle de temps fIxé. A partir de ces messages, il calcule
l'écart des temps à sa propre horloge. EnfIn, il utilise une fonction de sélection des
écarts contribuant au calcul du terme de correction ç. Les algorithmes diffèrent par la
technique de sélection.
L'algorithme CNV [75] utilise la moyenne arithmétique des écarts. Si une valeur reçue
est trop grande par rapport à une valeur fIxée à l'avance, elle est remplacée par celle de
l'horloge du nœud. Dans [84], on élimine les plus grandes et les plus petites valeurs et
on prend la médiane des N - 2m valeurs centrales restantes; où m est le terme
38.
OIapilœ 2.

---

d'élimination correspondant au nombre de pannes tolérables. Un algorithme semblable à
CNV est décrit dans [21]. On y suppose un système où les processeurs communiquent
par diffusion de messages (full message exchange FME). Chaque message ainsi diffusé
est daté. Ce qui permet de transporter l'heure. Un FME spécial n'est envoyé pour la
synchronisation que si aucun FME normal n'a été envoyé dans la période de
synchronisation par le processeur intéressé. La synchronisation n'engendre de
communications supplémentaires que dans ce dernier cas. Dans [70]. ç est la moyenne
des N - 2m valeurs centrales.
rn.2.2. Alaorithmes de consistance.
Les algorithmes de consistance se basent sur le consensus des processeurs autour de la
valeur diffusée par chaque processeur à la date de synchronisation. Dans l'algorithme
COM [75]. quand un processeur reçoit un message de synchronisation. il calcule l'écart
aentre son horloge et celle de celui qui l'a transmis. et rediffuse le message vers les
nœuds restants en même temps que aet l'heure locale. Chaque processeur dispose ainsi
de plusieurs copies du même message. A la fm de la période de synchronisation. le
nœud fait la somme des écarts portés par chaque copie et prend la médiane de ces
sommes comme l'écart de son horloge avec le nœud émetteur. n prend alors comme
terme correcteur ç la médiane de ces médianes.
L'algorithme CSM [75] (plutôt orienté vers la tolérance aux pannes) utilise la signature
digitale inviolable décrite dans [76]. Quand un nœud reçoit un message diffusé. il le
signe et le rediffuse à tous ceux qui ne l'ont pas signé; il en garde une copie. Chaque
copie du message est ainsi rediffusée jusqu'à m fois. Pour assurer l'inviolabilité. chaque
processus ne peut pas modifier l'heure d'émission indiquée par le message de plus de E;
de plus. pour détecter les imitations. chaque processus recevant un message vérifie que
l'émetteur l'a correctement signé. A la fin de la période de synchronisation. chaque
nœud dispose de m + 1 copies du message émis par chaque nœud. Pour déterminer
l'écart aij avec le nœud j. le nœud i compte le nombre k de signatures de chaque copie
du message diffusé par j. TI le multiplie par ~ + E. y ajoute l'heure d'émission Tj
portée par le message. et y soustrait sa propre heure Ti' nobtient: a= k(~ + E)+Tj - Ti'
Le nœud i choisit comme écart aij avec j. le maximum des a obtenus des copies. Le
terme correcteur ç est le maximum des aij.
L'idée présentée dans [118]. est que si un processus reçoit m + 1 messages de
synchronisation. il met son horloge à kR + ç. avec ç fixé d'avance, et k le numéro de la
période. Puis il rediffuse les m + 1 messages. Les messages sont signés. En prenant m
égal à 0, et en ignorant la signature, on obtient un algorithme simple avec un protocole
de synchronisation maître esclaves. Pour cela, périodiquement le processeur maître
39.
Chapitno 2.

---

diffuse un message de synchronisation. Chaque esclave en recevant ce message démarre
sa nouvelle horloge avec la valeur kR + ç, et éventuellement propage le message à ses
VOlsms.
m,2.3. Avantaies et inconvénients.
Les algorithmes de convergence et de consistance ont quatre principaux défauts. Le
premier est qu'ils nécessitent un réseau de diffusion complet [75] ou spécial [118]. Le
dewtième est qu'il faut que l'erreur de lecture E et le délai de communication /1 soient
bornés; ce qui conduit au rejet des valeurs dépassant ces bornes. Or de telles valeurs
augmentent avec la charge du réseau. Le troisième défaut, et de taille, est le nombre
considérable de messages générés. En effet, le nombre minimal de ces messages est N2;
c'est le cas pour [118]. Chez Lamport [75] ce nombre est de Nm+l pour l'algorithme
COM, plus élevé pour CNV, et plus de 2N2 pour CSM. Le quatrième défaut est que la
précision n'est pas très bonne à cause du paramètre m (la tolérance aux pannes coQte
très cher) :
•
Algorithme CVN :
(6m + 2)E + (3m + l)pR ~ 5.
•
Algorithme COM :
(6m + 4)E + pR ~ 5.
•
Algorithme CSM :
(m + 6)E + pR ~ 5.
Or l'erreur de lecture E n'est pas un terme négligeable. Dans [118] cependant, la
précision est garantie la meilleure car la dérive des horloges logiques est la même que
celle des horloges physiques.
On remarque des équations précédentes que si m = 0, on gagne en précision. C'est à dire
qu'en renonçant à la tolérance aux pannes, on obtient de bons algorithmes de
synchronisation des horloges.
rn.3. Approche probabiliste.
La précision de synchronisation dépend de l'erreur de lecture E (R6) [83]. L'approche
probabiliste proposée par Cristian [42] permet de rendre cette erreur aussi petite que
l'on veut, en minimisant le temps de communication /1. Elle ne garantit pas toujours
d'atteindre la précision voulue. Mais en essayant de lire une horloge un nombre
suffisant de fois, on peut espérer atteindre une précision donnée avec une probabilité
proche de 1. On suppose connue ~ la borne inférieure du délai de communication /1.
Le théorème suivant donne l'intervalle de lecture d'une horloge:
Théorème 3. Soient P et Q sont deux processeurs sans panne. Soient /1 la moitié du
temps qui s'écoule entre le moment où P demande l'heure de Q et le moment où il reçoit
40.
Chçille 2.

---

la réponse de Q. Si T est la date à laquelle Q a envoyé la réponse (T est porté par cette
réponse), alors l'heure de Q au moment où P reçoit cette réponse est dans l'intervalle:
•
1 = rr + (1 - p)~, T + 2(1 + 2p)~ - (1 + p)U.
Ce théorème illustré par le figure 4, dit que P peut mesurer l'intervalle 1 dans lequel se
trouve l'horloge de Q. Mais ne connaissant pas exactement la position de Q dans cet
intervalle, il faut à P une fonction C:;(T,~) pour estimer l'heure CQ(t). Avec cette
estimation, on a une erreur IC~(T, M- CQ(t)1 qui est minimale si P prend le centre de 1
comme estimateur de CQ(t) :
•
~(TA) = T + (l + 2p)~ - p~.
Mais comme p~ est très petit, on le néglige. Ce qui fait que :
•
CQ(t) E rr + ~min' T + 2~ - U;
~(TA) =T+~;
Cq(t)
Cq
T
1
Cpl
-Figure 4-
Estimation de l'heure entre deux horloges.
Avec l'expression de ê, plus ~ est proche de ~min' meilleure est l'estimation de Cq, donc
meilleure est la précision de synchronisation. L'algorithme de synchronisation consiste
alors à lire plusieurs fois l'heure jusqu'à ce qu'on trouve un délai ~ tel que:
•
I~ - ~I ~ Emu;
avec l'erreur maximum Emu fixée.
Soit p la probabilité d'atteindre une erreur inférieure à Emax; P est déterminé suivant la
distribution de ~ qui est supposée connue. Comme il faut au minimum deux messages
pour lire l'heure (fig. 4), le nombre moyen de messages pour se synchroniser est, selon
la loi de Bernoulli: ft = 21 (1 - p). Ce qui donne un nombre moyen de tentative de tV2.
La période de synchronisation peut être améliorée grâce une bonne estimation de la
dérive (R5). Le coefficient de la dérive étant considéré comme une constante non
connue, Cristian propose, à chaque synchronisation de calculer l'intervalle qui contient
ce coefficient. Soient ti le temps réel quand l'horloge P reçoit l'heure Ti de Q, et Hi
l'heure de l'horloge de P à cet instant. On a :
•
Hi -Ho
Hi -Ho =(l + p)(~ - to)
~ p = ~ _to - 1.
41.
Cbapilte 2.

---

Mais comme on ne connait pas to et~, on les estime par Yo = To+ ~ et Yi = Ti + ~i'
Ce qui donne les erreurs de:
eo =~ -~
et ei =~i - ~min' On a donc l'intervalle:
•
{Yo-eo~to~Yo+eo
~
Hi-Hp
1~ ~
Hi-Hp
-1
Yi -ei ~ti~Yi+ei
Yi-YO+ei+eo -
P
Yi -YO-ei-eo
.
On corrige ensuite les bornes de cet intervalle avec le maximum des bornes inférieures
et le minimum des bornes supérieures des synchronisations précédantes. On utilise le
milieu de l'intervalle résultant comme estimateur de la dérive. Cet estimateur converge
vers la dérive réelle.
Une amélioration de l'algorithme probabiliste a été faite par Alari et Ciuffoletti [15],
consistant à adapter la précision au temps qui s'est écoulé depuis la dernière
synchronisation. Cette amélioration réduit le nombre de messages de synchronisation de
près 30% par rapport à l'algorithme initiaL Une application de ce nouvel algorithme a
été faite [16] pour améliorer l'algorithme de Babaoglu et Drummond [21] (cf. m.2.1).
Ayantaees et inconvénients.
Plus E est petit, plus la quantité des messages échangés augmente. Cet algorithme est·
destiné à améliorer la précision de synchronisation des autres algorithmes [42]; ce qui
semble difficile car ces derniers utilisent tous la diffusion. D'autre part, il suppose la
connaissance de la loi de distribution de ~, car si la probabilité p est mal choisie,
l'algorithme atteindra moins souvent la synchronisation. La vitesse de convergence de la
méthode proposée pour estimer dynamiquement la dérive n'est pas connue. En outre,
l'utilisation des constantes ~ et de U (avec ~ ~ ~ ~ U), ne permet pas de s'adapter à
la variation de ~ avec la charge du système. Cet algorithme nécessite une loi de
probabilité qui concentre ~ près de ~ pour minimiser U - L\\m.n, Enfm, cet algorithme
ne tolère pas les pannes pouvant résulter du mauvais fonctionnement du contrôleur.
m.4. Autres méthodes de synchronisation des horloges.
Les techniques de synchronisation que nous venons de décrire sont basées sur
l'utilisation d'un logiciel qui tourne en même temps que les programmes utilisateurs,
avec les perturbations qu'on peut imaginer. La précision de ces horloges est souvent très
loin de celle des horloges matérielles. Pour répondre à ces deux problèmes, deux
méthodes sont actuellement proposées : la synchronisation par le matériel et la
synchronisation hybride. Nous allons les présenter succinctement.
42.
Chapitre 2.

---

mA. 1, Synchronisation matérielle.
Une horloge globale matérielle est constituée d'un réseau de modules horloge [108] (fig,
5), indépendant du réseau principaL Le module horloge sur chaque nœud est un «ircuit
constitué d'un récepteur d'horloge, d'un détecteur-correcteur de phase, et d'un oscillateur
à quartz (fig, 6) [125], Le détecteur-correcteur détecte en temps réelle décalage de
phase entre l'oscillateur local et un signal de référence, corrige l'erreur correspondante
et envoie le signal corrigé à l'oscillateur [108] [125]. L'horloge est accessible sous
forme de registres. Parmi les problèmes à résoudre on compte la génération du signal
de référence et l'interconnexion des nœuds, Dans [59], avec 4 horloges, on utilise la
médiane de toutes les horloges comme référence, et on ne tolère qu'une seule panne
byzantine conformément à [46] [75], La précision de cette horloge globale est de 50ns.
La solution utilisée ne peut pas être généralisée car avec la médiane, des pannes
byzantines peuvent diviser les bonnes horloges en cliques non synchronisées entre elles,
alors que dans la même clique les horloges sont synchronisées [125].
Clock
Module
Clock
Module
Clock
Crystal
Clock
Clock
~
Clock
1----
Phase
1..-.
Inputs
Output
Module
i Detector
Oscillator
..
~~
Receiver
Cl<&Bu;
Clock Module
-Figure 5-
Réseau d'horloges.
-Figure 6-
Module horloge.
Dans [108] , au moment de la synchronisation, chaque module horloge diffuse sa date à
tous. Chaque module sélectionne les plus grandes valeurs des diverses copies qu'il a
reçues d'un même module, et prend la moyenne de ces valeurs comme heure de
référence, La stratégie utilisée a cependant l'inconvénient de nécessiter que chaque
nœud détermine sa position dans la liste des messages qu'il reçoit à chaque
synchronisation. Dans [125], on utilise également une fonction de sélection pour
déterminer l'horloge de référence. Ces systèmes nécessitent un réseau complet. Une
solution à ce problème d'interconnexion consiste à diviser le réseau en cliques [116]
[108]. Chaque module horloge se synchronise avec les membres de sa clique et un
membre de chacune des autres cliques. Cette solution nécessite moins du tiers des
connexions d'un réseau complet. Les solutions matérielles sont encore peu explorées à
cause de leur coOt. La complexité des réseaux croît avec N,
43.
Cbapiùe 2.

---

WA.2. Synchronisation hybride.
L'objectif des horloges hybrides est de trouver un compromis entre les horloges
matérielles et les horloges logicielles: améliorer la précision de ces dernières avec un
minimum de matériel. Un circuit horloge (CSU : clock synchronisation unit) est associé
à chaque processeur. Son rôle est d'estampiller les messages de synchronisation et de
réaliser la correction en continu. Ces horloges utilisent en général des algorithmes de
diffusion.
Dans le système de Kopetz et Ochsenreiter [70], à la date de synchronisation, chaque
process.eur lit son heure et la diffuse à tous. Chaque processeur reçoit alors N-l
messages et détermine l'écart 6ïj de l'émetteur à l'horloge locale. Puis il prend les N -2m
valeurs centrales avec lesquelles il calcule le terme correcteur çj utilisé par le CSU :
1
•
çj = N -2m r. 6ï}
Le CSU est accessible à travers des registres, et offre une heure locale dont la précision
est 1 J.lS et un~ heure globale à 100 J.ls. L'erreur de lecture du CSV est: E =9 J.ls. Ce
système nécessite que tous les nœuds soient reliés par un réseau de diffusion (e.g. bus).
Les horloges hybrides de [107] ne nécessitent qu'un réseau point à point. L'algorithme
utilisé dérive de CNV [75]. Comme dans ce dernier en effet, chaque processeur diffuse
son heure à tous. Chacun estampille le message au passage, le fait suivre, et en garde
une copie avec l'heure d'arrivée. A la fm de la période de synchronisation, chaque nœud
ayant reçu plusieurs copies du même message, calcule l'écart avec l'émetteur pour
chacune d'elle. Puis il prend la m+ lième valeur comme l'écart effectif. Le terme
correcteur ç est la moyenne des écarts ainsi obtenus avec tous les nœuds. La précision
de cette horloge globale dépend du réseau utilisé. Elle est de 100 J.lS pour un hypercube
de 64 nœuds. Par opposition à CNV, l'heure ici est diffusée le long de toute la période
de synchronisation.
IV. Discussion.
La comparaison des algorithmes que nous venons de présenter est difficile en terme de
performance du fait qu'ils ont été implémentés sur des architectures différentes. Nous
allons comparer leur coOt en terme de messages générés, et analyser leur précision.
La plupart de ces algorithmes génèrent beaucoup de messages à travers le réseau
principal. L'horloge de Lamport [72] rajoute un entier à chaque message transmis.
L'horloge de Jézéquel ne coOte qu'en phase d'initialisation où il génère des messages de
calcul des termes (aij, ~ij) dont le nombre dépend de l'algorithme géométrique choisi; et
44.
Chapitre 2.

---

des messages de calcul du terme correcteur dont le nombre dépend du réseau utilisé:
O(N) en général.
Les algorithmes de convergences nécessitent au minimum N2 messages. Les
algorithmes de consistance peuvent nécessiter jusqu'à Nm+l messages. Pour l'algorithme
probabiliste, le nombre de messages échangés dépend de la probabilité p. Suivant la loi
de Bemoulli,le nombre moyen pour un réseau maître esclaves est de 2N 1(1- p). Enfin,
les systèmes hybrides ont la même complexité que les algorithmes de diffusion qu'ils
utilisent. Les horloges matérielles ne génèrent pas de message sur le réseau principal.
Les horloges logicielles sont flexibles et économiques. Leur implémentation ne pose
pas de problème particulier. Les horloges matérielles sont coOteuses (implémentation
des modules horloge) et nécessitent un réseau supplémentaire dédié aux horloges. Les
horloges hybrides intègrent à la fois le coOt de développement logiciel et la réalisation
des circuits CSU. La précision des horloges logicielles est proportionnelle à E~ alors
qu'elle est proche du cycle de base du processeur pour les horloges matérielles.
Il est intéressant de noter (proposition R2 et R6) que ce n'est pas le temps de
communication qui dégrade la précision, mais sa variation d'une communication à
l'autre. De notre étude nous tirons deux remarques.
La première est que la précision dépend des paramètres E, et N. La dérive et la période
de synchronisation peuvent être calculées à l'exécution [42]. Vu le coOt prépondérant de
m sur la précision b, il peut être intéressant de renoncer à la tolérance aux. pannes, et de
se limiter à leur détection. Ainsi dans un système maître-esclave, l'algorithme de [118]
peut être simplifié comme nous l'avons décrit dans la section ID.2.2.
La deuxième remarque est qu'en utilisant les statistiques et les probabilités, il est
possible d'améliorer ces algorithmes et de limiter l'utilisation des constantes car elles
donnent une mauvaise précision. Prenons deux exemples. La dérive est souvent prise
comme le maximum des dérives des horloges physiques. Or ce maximum' est un
majorant de la dérive réelle. Par R4-S on voit que la dérive détermine la période de
synchronisation des horloges. Une bonne estimation de la dérive conduit donc à un
meilleur ajustement de la période de synchronisation. Le deuxième exemple est
l'adaptation à la charge du réseau. L'augmentation de la charge du réseau est assimilée à
une panne, car les délais li. des messages augmentent. Ces messages sont donc rejetés
conformément à la politique de sélection des messages contribuant à l'estimation de
l'heure globale (ou de tolérance aux pannes) qui devient alors pernicieuse. Or en
étudiant la statistique des temps de communication, on peut facilement corriger cette
méprise. Pour illustrer notre propos, nous allons nous intéresser à l'algorithme
45.
Cbapitle 2.

---

probabiliste. li suppose que la loi de probabilité de ~ est connue, ce qui n'est pas
souvent possible. Or des éléments de statistique permettent à la fois d'estimer cette loi,
et de s'adapter à la charge du réseau. Nous y reviendrons en détail au chapitre 4.
Conclusion.
Nous avons présenté les notions de base de la synchronisation des horloges; et nous
avons analysé les principales techniques de constructions d'horloges globales. Ces
techniques peuvent souvent être améliorées par une meilleure estimation des paramètres
comme la dérive des horloges. Pour cela. on peut utiliser les éléments de statistiques et
de probabilités. Nous illustrons ce propos au chapitre 4.
Ce qui manque actuellement aux horloges globales. c'est une utilisation effective. Ce
manque d'utilisation vient en partie du fait que la précision de ces horloges est trop
faible comparée à de celle des horloges physiques. pour qu'elles soient jugées
intéressantes. n semble que la solution idéale serait que la synchronisation des horloges
soit directement prise en compte au niveau du matériel, car seul le matériel assure la
meilleure précision.
46.
Cbapitm 2.

---

Chapitre 3.
Etude d'un moniteur de communication
sur le bus de contrôle du SuperNode
Introduction.
Les transputers du SuperNode sont reliés par deux types de réseaux. Le premier est
réseau reconfigurable constitué d'un communtateur dynamiquement reconfigurable,
auquel sont reliés les liens de tous les transputers. Le deuxième est un bus bidirectionnel
appelé bus de contrôle, reliant tous les transputers de travail (Slave Transputer : ST) au
transputer de contrôle (Master Transputer: MT) par recouvrement d'adresses mémoire.
Dans ce chapitre, nous nous intéressons exclusivement au bus de contrôle.
Min de véhiculer les informations de contrôle du système C_NET de manière
transparente au réseau principal, un moniteur logiciel a été développé pour permettre à
tous les transputers communiquer à travers ce bus. La mise en œuvre de ce moniteur a
nécessité à la fois l'étude des mécanismes de base du bus (communication, interruption,
programmation), l'identification des contraintes et des problèmes qu'il impose, et
l'analyse de ses performances. Des algorithmes tirant au mieux parti de la spécificité de ce
bus ont ensuite été développés. C'est l'ensemble des études menées pour concevoir ce
moniteur que nous présentons dans ce chapitre. .
Le bus de contrôle est essentiellement utilisé par le configureur dynamique [28] et le
système de mise au point CDS. Nous avons développé deux versions d'un moniteur
mettant en œuvre une politique de partage, de communication et de synchronisation entre
le transputer de contrôle et les transputers de travail. La première, dite asynchrone,
permet à n'importe quel processus d'envoyer ou diffuser un message à travers le bus,
message destiné aux processus du configureur dynamique, à la carte frontale, ou à des
processus s'exécutant sur d'autres transputers de travail. La deuxième version, dite
synchrone, à cause du protocole symétrique et déterministe qu'il met en œuvre entre le
Mf et les ST, est dédiée au configureur dynamique.
La première partie de ce chapitre présente nos objectifs et motivations, et ainsi que
l'originalité de ce travail. La deuxième partie est consacrée à l'étude du bus. Elle présente
les mécanismes de base et un modèle de fonctionnement du bus pour les communications
et la synchronisation entre le MT et les ST, ainsi que les performances du bus. La
47.
Ch.pift 3.

---

troisième partie présente des algorithmes adaptés à ce fonctionnement avec une étude de
leurs performances. La quatrième partie est une analyse de contraintes et problèmes qui se
posent pour la mise en œuvre de protocole de partage du bus. La cinquième partie
présente la version asynchrone du moniteur du bus, avec ses performances. La sixième
partie enfm présente le moniteur synchrone dédié au configureur dynamique. Elle a été
conçue pour améliorer le grain de la reconfiguration dynamique. Enfm, la conclusion
traite de la portabilité. Ce moniteur est écrit en C de Logical Systems [33] [82], ainsi que
les exemples de ce chapitre. Le travail présenté dans ce chapitre a été mené en
collaboration avec lM. Adamo en ce qui concerne le fonctionnement du bus et la
conception des protocoles du minoteur.
1. Objectifs et motivations.
L'originalité du travail présenté dans ce chapitre réside dans le fait que c'est la première
étude complète réalisée sur ce bus qui est un des éléments essentiels du SuperNode; étude
visant à la fois de fournir un modèle expliquant le fonctionnement du bus, d'établir ses
performances, et de proposer des algorithmes compatibles avec ce fonctionnement. Deux .
travaux ont été entrepris sur le fonctionnement de base de ce bus. Le premier mené par
Waille (lOI] porte sur les algorithmes de base de communication sur le bus, et les
mécanismes de génération des interruptions. li ne présente pas les performances de ces
algorithmes, et le modèle proposé ne permet pas d'expliquer un bon nombre de
comportements du bus comme l'incompatibilité entre la communication et la génération
des interruptions, ou encore la réinitialisation du mécanisme de génération des
interruptions. Un autre travail présenté dans [122] se limite aux algorithmes de
communication sur le bus, sans les compléter par des performances et un modème
permettant de bien comprendre le fonctionnement du bus. C'est pour combler ce vide que
nous avons tenté de mener une étude plus poussée sur ce bus. Les autre objectifs que
nous avons visé en réalisant les moniteurs que nous allons décrire sont les suivants :
•
Construire un outil permettant au transputer de contrôle (MT) de communiquer
avec les transputers de travail (ST) de manière indépendante du réseau principal. Ces
communications concernent le transport des messages des processus système (système
de mise au point, configureur dynamique) et utilisateur (propagation des requêtes du
programmeur par exemple). Elles portent à la fois sur l'envoi de massages simples ou la
diffusion du MT vers les ST, ou d'un ST quelconque vers tous les autres, ainsi que
l'accès de tous les ST à la carte frontale pour étendre l'utilisation des fonctions du CIO
(gestion des entrées sorties). Cette extension est indispensable notamment pour la mise au
point, car we le nombre limité des liens du transputer, seul un petit nombre de ST
peuvent accéder à la carte frontale.
48.
Chapitre 3.

---

•
Permettre la synchronisation du MT avec les ST. Cette synchronisation est
indispensable à la reconfiguration dynamique, de façon d'une part à garantir que pendant
la reconfiguration du commutateur, les ST ne vont pas tenter d'utiliser leurs li~ns, et
d'autre part pour communiquer au ST les données de changement de phase
indépendamment de la topologie utilisée.
La conception de ces moniteurs nous a conduit à chercher à comprendre comment
fonctionnait ce bus pour en tirer le meilleur profit possible. A titre indicatif, nous avons
pu gagner des temps d'un facteur de 1()()() entre la première version du moniteur que nous
avons réalisée [94] et la plus rapide des version que nous allons présenter; de même que
le rapport de temps de changement de phase entre les deux versions du moniteur que
nous allons présenter est de l'ordre de 10 relativement au bus.
Aucun des travaux réalisés au préalable [101] [121.] ne donnait une explication suffisante
pour comprendre le fonctionnement de ce bus. Nous avons donc pour cette raison
entrepris de construire un modèle de comportement du bus, de le valider, et d'effectuer
une ensemble de mesures pour déterminer les performances de ce bus. Nous avons
effectué ces mesures à trois niveaux: les accès de bas niveau au bus; les fonctions de
communication et de synchronisation; et le moniteur utilisant ces fonctions.
Le T.Kernel [122], système d'exploitation livré avec le SuperNode par Telmat, assure les
mêmes fonctionnalités de communication que le moniteur que nous voulions réaliser.
Mais l'environnement C_NET nécessite la présence de processus permanents sur le
transputer de contrôle, notamment pour la reconfiguration dynamique [9] [28]. Le
T.Kernel ne permet pas de charger des processus utilisateurs sur le transputer de
contrôle.
Par ailleurs, le T.Kernel fonctionne comme un système de requêtes nécessitant la
présence de processus pilotes sur la carte frontale pour envoyer des commandes au
T.Kernel s'exécutant sur le transputer de contrôle. Nous avons cherché a minimiser cette
dépendance avec la carte frontale. Notre moniteur ne doit communiquer avec la carte
frontale que pour les entrées-sorties. En effet la configuration dynamique ne met en jeu
que les transputers du SuperNode, il aurait été donc maladroit de commander cette
reconfiguration à partir de la carte frontale : augmentation du temps de reconfiguration,
nécessité de commandes supplémentaires pour le T.Kernel en plus des commandes de
programmation du réseau, et utilisation non optimale du transputer de contrôle. Seul le
système de mise au point nécessite l'échange de messages avec la carte frontale pour les
entrées-sorties.
49.
Cbapift 3.

---

Il. Etude expérimentale du bus de contrôle.
Le bus de contrôle du SuperNode (fig. 1) peut être programmé pour mettre en œuvre des
protocoles de communication et de synchronisation entre le MT et les ST. Cette partie
présente un modèle d'organisation et de fonctionnement du bus, qui permet en partiéulier
de comprendre les mécanismes de génération des interruptions et de communication. Ce
modèle résulte du recoupement entre la description technique du constructeur, et les
observations que nous avons menées sur ce bus. Nous décrivons les fonctionnalités
offertes par le bus de contrôle, son organisation, son fonctionnement, et les algorithmes
et performances des opérations élémentaires qu'on peut y effectuer. Nous terminons avec
un ensemble de remarques fondamentales pour la programmation de ce bus. Le lecteur
intéressé pourra aussi se rapporter à [93] [94] (lOI], et à la documentation de Telmat
[121] et du projet Esprit P1085 [77].
Workers
..
d
-
•
-Figure 1·
TNode.
II.1. Fonctionnalités offertes par le bus de contrôle.
Le bus de contrôle a été conçu pour réaliser les fonctions suivantes:
•
Utilisation des signaux de contrôle des transputers de travail: reset, analyse,
signal Event [62];
•
Sélection de la vitesse des liens, examen du flag erreur, et positionnement du
mode de chargement (bootfrom iinklbootfrom ROM) [62] des transputers de travail;
•
Communication entre le transputer de contrôle et les transputers de travail par
échange d'octets.
•
Synchronisation entre le transputer de contrôle et les transputers de travail par des
interruptions générées par le bus de contrôle sur le canal EVENT de chaque transputer,
ou par lecture des flags du bus (scrutation).
50.
Chapitro 3.

---

Dans ce chapitre, nous nous intéressons uniquement à la communication et à la
synchronisation à travers ce bus.
II.2. Organisation et modélisation du bus de contrôle.
Cette section a pour but de donner un modèle d'organisation du bus de contrOle
permettant de comprendre son fonctionnement.
ne2e!. Orianisation matérielle du bus.
Le bus de contrOle comporte des points d'entrée formés par des composants appelés
control gate array (CGA) reliés entre eux par un bus; voir figure 2. Chaque CGA est
associé à un transputer du SuperNode en recouvrant l'espace mémoire correspondant aux
adresses (en hexadécimal) de ''00000008'' à "OOOOOOlF" pour un transputer de travail
(CGA esclave), et de "00000024" à "ooOOOO3C" pour le transputer de contrOle (CGA
maître); soit 13 mots de 4 octets.
Dans le cas d'un TandemNode ou d'un MégaNode, le transputer de contrôle peut devenir
à son tour transputer esclave d'un autre contrôleur [lOI] [126] auquel il est relié par un
CGA esclave [121] (fig. 2). Le CGA est également connecté aux entrées Analyse, Event,
Reset et Error du transputer. Le MT peut aussi recevoir une horloge temps réel sur le
CGA esclave et une interruption externe par le CGA maitre (fig. 2).
Dans le bus de contrôle, les CGA des transputers de travail sont répartis en 7 groupes de
8 transputers. Le bus peut donc logiquement recevoir 56 transputers de travail; mais un
mécanisme spécial a été prévu pour permettre d'utiliser un nombre plus important de
transputers de travail [77].
Mastec Control Bus
Control Bus
,
1 1
1
11
oIl
10 isY
Event
J
1
1Slave CGA
al
-1 Master mA 1
~ Controllec
·1 Request
1
·1
1 Transputer
1SlaveCoA
Local
t
Channel
Transputer
Event
Event
-
Event 11
Memory
RTC
1RS2321
Space
1 Worker
1 Local Transputer
1 Transputer
Memory Space
ControlJer Bord
Worker Board
-Figure 2-
Bus de contrOle et CGA.
SI.
CMpi1re 3.

---

n,2,2. Or&anisation lo&iQue du bus de contrôle,
Une image simplifiée du bus de contrôle est que le transputer de contrôle y partage avec
chaque transputer de travail, un buffer d'un octet et deux flags pour synchroniser l'accès
à ce buffer. Le flag MSDF (Master To Slave Data-buffer Full), initialement à 0, est mis à
1 par le MT pour indiquer au ST qu'une donnée est disponible dans le buffer. Le ST
remet ce flag à 0 pour acquitter la réception de l'octet. Le flag SMDE (Slave To Master
Data-buffer Empty), initialement à 1 est mis à 0 par le ST pour signaler au MT qu'une
donnée est disponible dans le buffer. Le MT le remet à 1 pour acquitter la réception de
l'octet. Mais en pratique, l'organisation et le fonctionnement du bus sont beaucoup plus
complexes, L'objectif de cette section est de modéliser l'organisation de ce bus, pour
mieux expliquer son fonctionnement et mieux l'exploiter. Nous avons dit que le bus de
contrôle est constitué d'un CGA maître (MCGA) relié à des CGA esclaves (SCGA) par
un bus.
a) Le Bus.
li relie le MCGA à tous les SCGA. Il peut être divisé en deux parties. Un bus de
commande, uni-directionnel, par lequel le MCGA sélectionne les SCGA et leur transmet
des commandes. li véhicule le numéro de groupe des SCGA (3 bits), le masque des
SCGA à l'intérieur du groupe (8 bits: 1 par SCGA), le mode (sélection/de-sélection: 1
bit), et un code opération (5 bits maximum). La deuxième partie est un bus bi-directionnel
de transfert de données (8 bits).
b) Le CGA maitre.
Le MCGA supervise l'utilisation du bus. TI peut être décomposé en trois parties (fig. 3) :
une unité de contrôle (UC), un générateur d'interruptions (GI), et un ensemble de
registres à travers lesquels le MT adresse des commandes aux MCGA :
• L'UC est l'organe central bus bus de contrôle. Elle reçoit les commandes du transputer
de contrôle à travers les registre; et selon le type, programme le générateur d'interruption,
ou génère une commande sur le bus à destination des SCGA.
• Le générateur d'interruptions peut reconnaître 5 types d'événements, pour lesquels il
peut générer une interruption sur le canal EVENT du MT auquel il est relié. Deux types
en particulier nous intéressent: le type ANY, généré quand l'un quelconque des ST
sélectionnés a mis son flag SMDE à 0; et le type ALL, généré quand tous les ST
sélectionnés ont mis leurs flags MSDF à O. Le GI ne génère effectivement une
interruption sur le canal EVENT du MT que si le MT a spécifié le type d'interruption qu'il
52.
<::h8pilre 3.

---

veut recevoir, et qu'il a re-initialisé la génération des interruptions à travers les registres
adéquats. Cette logique est représentée sur la figure 3.
Control transputer memory space
Event Cbannel
-----1~--........--~CO:-n""!'t-ro":""l :""'bus-......---t- Command
- - - -.........- - - - - - - - - - - - - - Data
-Figure 3-
Modélisation du CGA maître.
• Les registres. TI y en a 6, utilisables par le MT pour programmer le MCGA (voir
Annexe 1, tableau Al) :
• Registre adresse: permet au MT de sélectionner un groupe de SCGA et de
spécifier le type d'opérations qu'on veut lui faire exécuter. TI est composé en
réalité de deux régistres, l'un permettant de sélectionner le SuperNode (2 bits),
et l'autre d'adresser un groupe et de spécifier le type d'opération (1 octet).
• Buffer : il a un double rôle. C'est une ~xtension du registre adresse servant au
MT à spécifier les ST auxquels il veut s'adresser dans un groupe (un ST par bit
à 1). TI sert aussi au MT à inscrire ou récupérer les trois sortes de données qui
peuvent transiter par le bus de données: octet à envoyer aux ST, octet émis par
un ST, état des flags d'un groupe de ST donné.
• Registre de cycle: une écriture à ce registre permet au MT de demander à l'UC
d'exécuter la commande inscrite dans les registres adresse et buffer.
• Registre d'état de l'UC : il permet au MT de connaître à tout moment l'état du
MCGA. Quand l'UC vient de recevoir une commande, elle met la valeur 3 dans
ce registre. Quand elle a lu la commande, elle y met la valeur 2. Une nouvelle
commande peut alors être inscrite dans les registres. Quand elle a terminé
d'exécuter la commande, elle met ce registre à 0, indiquant qu'elle est prête à
exécuter une nouvelle commande.
SJ.
ClYpift 3.

---

• Masque des interruptions : permet au MT de spécifier le type d'interruptions
que le GI peut générer. A chaque type correspond un bit.
• Registre d'initialisation des interruptions: permet au MT d'indiquer au GI qu'il
peut générer l'interruption suivante. Au début de l'application, et une fois
qu'une interruption a été reçue sur le canal EVENT, il faut re-initialiser ce
registre associé au GI. Cette re-initialisation est un acquittement indiquant au GI
qu'il peut générer l'interruption suivante.
c) Le CGA esclave.
TI sert d'interface du bus au ST. TI peut être décomposé en trois parties (fig. 4) : un
interpréteur de commandes, un ensemble de registres et un générateur d'interruptions.
• Interpréteur de commandes (IC). TI a pour rôle de recevoir les commandes envoyées
par le MCGA sur le bus, et selon la nature de celles-ci, de mettre sur le bus de données le
contenu des registres, de lire la donnée présente sur le bus, ou de modifier le contenu des
registres. TI est relié au bus de commande par un décodeur d'adresses qui reconnaît le
numéro de groupe (3 bits GGG), le masque associé au ST dans le groupe (l bit Bi), et le
mode sélection/de-sélection (1 bit S).
• Les registres. TI y en a 5, accessibles au ST (voir Annexe 1, tableau Al) :
• Buffer : permet au ST de lire un octet émis par le MT, et d'inscrire un octet
destiné au MCGA. A la demande du MCGA, l'IC commande ce registre pour
transférer son contenu sur le bus de données, ou pour lire la donnée présente sur
ce bus.
• Le flag MSDF : est initialement à O. L'IC peut le mettre à 0 ou à 1 sur une
commande du MCGA. TI peut être mis à 0 par le ST (Clear MSDF).
• Le flag SMDE : est initialement à 1. TI peut être mis à 0 par le ST (Clear
SMDE). L'IC peut le mettre à 0 ou à 1 sur une commande du MCGA. Un
registre spécial permet au ST de lire l'état de MSDF et SMDE (un bit par flag).
• Masque des interruptions: permet au ST de spécifier les interruptions qu'il
veut recevoir sur le canal EVENT.
• Registre d'initialisation des interruptions : permet au ST d'indiquer au CGA
qu'il peut générer l'interruption suivante. n faut re-initialiser ce registre au début
de l'application, et une fois qu'on a reçu une interruption sur le canal EVENT.
54.
Cbapin 3.

---

Contro){~ ....~
"""!,,,,
-+--+-
Bus
S BiGGG
Slave
CGA
-Firure 4·
Modélisation du CGA esclave.
• Génération des interruptions (GI). La logique de génération des interruptions est
présentée par la figure 4. Une interruption est générée sur le canal EVENr du ST quand
l'un des fIags SMDE ou MSDF est à 1. TI faut qu'au préalable le ST ait positionné le
masque de chaque type d'interruptions qu'il veut recevoir, et qu'il ait initialisé le
mécanisme de génération des interruptions. Cette re-initialisation ~ert à indiquer au GI
qu'il peut générer l'interruption suivante. La lecture du registre des fIags permet de savoir
lequel des deux fIags est à l'origine de l'interruption.
II.3. Fonctionnement du bus de contrôle.
Nous avons décrit les différentes composantes du bus. Nous décrivons maintenant leur
logique de fonctionnement pour la synchronisation et les communications dans le sens
MS (maître-+esclave, fIag MSDF) et SM (esclave-+maître, fIag SMDE), et nous en
donnons les performances.
n.3.!. Le CGA maître.
Le MCGA fonctionne par cycle (fig. 5 A). Un cycle externe déclenché par le Mf permet
au MCGA d'exécuter la commande inscrite dans ses registres. Un cycle interne toujours
actif tant qu'il y a un groupe de ST sélectionnés pour la synchronisation, permet au
MCGA de générer les interruptions sur le canal EVENT du Mf. Le MCGA peut recevoir
trois types de commandes : commande de lecture des fIags des SCGA (commande de
lecture adressée); commande de sélection des SCGA pour une communication ou une
synchronisation (commande d'écriture adressée); commande de modification des fIags
55.
Cbapilm 3.

---

des SCGA et de réalisation de transfert d'octet (commande non adressée ou de
communication). Cette section décrit les algorithmes ces commandes et donne les
mesures de temps du cycle correspondant.
a) Cycle de lecture des nags.
Quand elle reçoit une commande de lecture d'adressée, l'unité de commande (UC) du
MCGA détermine le type de flags à lire et le groupe concerné. Ensuite, elle affiche une
commande de lecture de ces flags sur le bus de commande. Chacun des 8 SCGA du
groupe en question affiche en réponse la valeur de son flag sur le bus de données (un bit
par SCGA) .. Quelques micro-secondes après l'envoi de la commande, le MCGA lit la
valeur présente sur ce bus et l'inscrit dans son buffer. Cet algorithme est représenté par
figure 5 A et Al. Le tableau 1 donne la durée d'un cycle de lecture, pour 5000 mesures.
Le format d'une commande de lecture adressée est le suivant:
•
Registres adresse (deux octets) : '
ס
0ooooo1 ! GGG xxxxx '; l'octet de poids fort
sert à sélectionner le SuperNode. Dans l'octet de poids faible, GGG indique le numéro
du groupe (Annexe l, tableau A3), et xxxxx, le numéro de la commande (Annexe 1,
tableau A4) qui correspondent au type de flags à lire.
•
Registre Buffer : contient l'état des flags après le cycle du bus (un bit par ST).
Type de commande 1 Durée du cycle en Ils
Minimum
Amplitude
Lecture du fla2 MSDF
11
3
Lecture du fiait SMDE
12
2
-Tableau 1-
Durée d'un cycle de lecture de fiags.
b) Cycle de sélection des ST.
Une commande d'écriture adressée permet de spécifier les ST avec lesquels le MT veut
communiquer ou se synchroniser. Quand elle reçoit une telle commande, l'UC détermine
le groupe concerné, le mode (sélection/de-sélection), le sens de communication/
synchronisation (MS ou SM), et les ST sélectionnés dans le groupe. S'il s'agit d'une
synchronisation, elle transmet la commande au générateur d'interruptions; sinon, elle
l'affiche sur le bus de commande. Chaque SCGA détectant cette commande se met en état
sélectionné (ou de-sélectionné); c'est à dire qu'il peut accepter des transferts et modifier
ses registres pour cette sélection. Cet algorithme est donné par la figure 5 A et A2. Le
tableau 2 donne la durée d'un cycle de sélection, pour 5000 mesures.
56.
Cb.pin 3.

---

Al
Addr_ed write
g .. c.g:roup
S ... c.mod
o=c.op
w =buffer
Bus_slalUS.reg =FRFE
Unaddressed operation
A3
Hag
-Figure 5-
Algorithmes de contrôle du MCGA.
Le fonnat d'une commande de sélection est le suivant:
•
Registre adresse: ' 00000oo1, GGG S xxxx'; deux octets. L'octet de poids fort
indique le numéro de SuperNode. Dans l'octet de poids faible, les trois bits GGG
indiquent le numéro du groupe (Annexe 1, tableau A3). Les quatre bits XXX){ indiquent le
numéro de la commande (Annexe 1, tableau A4). Le bit S vaut 1 pour sélectionner, et 0
pour de-sélectionner le groupe pour cette commande.
•
Registre buffer : ,II II II II " un octet. Chaque bit T à 1 indique que le ST
correspondant est concerné par l'opération. Le tableau A3 donne pour chaque ST son
groupe et sa position dans l'octet du groupe.
57.
Cbapi~ 3.

---

Type de sélection
1 Durée du cycle en ILs
Minimum
Amplitude
Stlection MSDEN
9
4
Stlection SMDEN
9
5
Stlection ALBEN
9
3
Stlection ANBEN
9
3
De-sélection MSDEN
11
2
De-sélection SMDEN
10
3
De-stlection ALBEN
10
2
De-stlection ANBEN
10
2
-Tableau 2-
Durée d'un cycle de sélection d'un groupe.
c) Cycle d'une commande de communication.
Une commande non adressée sert à modifier les flags des SCGA ou à transférer une
donnée de buffer à buffer. En recevant une telle commande, l'UC détermine le type de
flag ou de transfert concerné. Pour les flags, elle affiche sur le bus de commande, une
requête de mise à 0 (Reset) ou à 1 (Set) du flag concerné. Les SCGA qui ont été au
préalable sélectionnés pour ce type de communication reçoivent cette commande et
modifient en conséquence leurs flags. Dans le cas d'un transfert, l'UC affiche une
requête de transfert sur le bus de commande. S'il s'agit d'un transfert MS, elle affiche en
même temps le contenu de son buffer sur le bus de données. S'il s'agit d'un transfert
SM, elle lit la valeur affichée sur le bus de données. De leur côté, les SCGA sélectionnés
au préalable pour ce type de communication, en recevant la commande, lisent la valeur
affichée sur le bus de données, ou y affichent celle de leur propre buffer. Cet algorithme
est donné par la figure 5 A et A3. Le tableau 3 donne la durée d'un cycle de
communication, pour 5000 mesures.
Type de commande 1 Durée du cycle en ILs
Minimum
Amplitude
Modification du flag MSDF
10
2
Modification du fllU?: SMDE
10
2
Transfert MS
8
2
Transfert SM
8
2
,
..
-Tableau 3-
Durée d un cycle de transfert et de modif1caoon de flag.
Le format d'une opération non adressée est:
•
Registre adresse: un octet de sélection du SuperNode et un octet llllxxxx; où
xxxxx est le numéro de la commande (voir Annexe 1, tableau A4).
58.
Chapitre 3.

---

•
Registre buffer : contient l'octet à envoyer aux ST pour un transfert MS, ou l'octet
reçu d'un ST à la fin du cycle du bus. Dans le cas d'une modification de flags, son
contenu est indéfini.
d) Cycle interne : génération des interruptions.
Le générateur d'interruptions mémorise les SCGA sélectionnés pour une synchronisation
par interruption (algo A2). Régulièrement l'UC rentre dans un cycle durant lequel elle
commande la lecture des flags des groupes sélectionnés, et le générateur d'interruptions
récupère les valeurs de ces flags à travers le bus de données. Si le mécanisme
d'interruption a été initialisé comme nous l'avons décrit (§II.2.2.b), une interruption est
générée quand l'un des flags SMDE est trouvé à 0 (synchronisation de type ANY) ou
quand tous les flags MSDF des SCGA sélectionnés sont à 0 (synchronisation de type
ALL). Du fait que ce cycle utilise le bus de données, il n'est donc plus possible de
réaliser de transfert de données tant que la sélection pour synchronisation est active. La
durée d'un cycle de génération d'une interruption est donnée par le tableau 4.
Type de commande 1 Durée du cycle en ILS
Minimum
Amplitude
Génération interruption ALL
10
0
Génération interruption ANY
10
0
,
-Tableau 4-
Durée d un cycle mterne de généranon d mterrupuon.
"
n.3.2. Le CGA esclave.
Contrairement au MT qui doit attendre la fm d'un cycle du MCGA, le ST peut accéder
aux registres du SCGA à n'importe quel moment. Cet accès ne modifie pas le
comportement du SCGA, car ce dernier n'obéit qu'aux commandes envoyées sur le bus
parle MCGA.
Le SCGA fonctionne selon la logique: sélection -+ {opérations} * -+ de-sélection. n est
toujours à l'écoute du bus en attente d'une commande. Un SCGA ne répond à une
commande que s'il a été sélectionné au préalable pour ce type de commande. n se
reconnait sélectionné quand la valeur de groupe et le bit auxquels il est associé dans le
groupe, affichés sur le bus de commande correspondent à son adresse (fig. 4). Si la
sélection concerne une lecture de flag, il affiche sur le bus de données un bit
correspondant à la valeur du flag spécifié. Pour une toute autre sélection, il en mémorise
le type. De sorte que, chaque fois qu'il recevra une commande associée à ce type, il y
répondra comme nous l'avons décrit §II.3.1.C. L'algorithme modélisant ce
comportement est donné par la figure 6.
S9,
Cbapitre 3,

---

Setfllnset
BuffeT
-Figure
6-
Algorithmes de contrôle du SCGA.
II.4. Conséquences et observations.
Du modèle que nous venons de décrire, nous pouvons tirer les observations suivantes,
capitales pour la mise en œuvre de protocoles d'utilisation du bus:
•
On peut déduire des mesures que nous avons présentées que la durée de traversée
du bus est d'environ 10 IlS. Et par conséquent, la fonction linéaire caractéristique du bus
est: (nl = t = IOn, et la fonction de chaque opération est : grn) = t = (1Q + a)n;
où t est le temps en micro-seconde; n est le nombre référence à l'opération (e.g. octets
transférés); 10 est le coup de base par opération; a est le coup moyen supplémentaire par
opération dû à l'amplitude et au logiciel utilisé. L'amplitude est une variable aléatoire de
moyenne 3 Ils et de maximum observé 5 I!S. En d'autres termes, tout accès au bus aura
un délais d'environ 10 IlS.
NB. A partir de la fonction caractéristique, nous pouvons déduire que la vitesse
théorique du bus de contrôle est de 100 000 opérations par seconde; ce qui correspond
effectivement à la vitesse annoncée par le constructeur: 100 ko/s.
•
Le MT et le ST peuvent détecter le changement d'état des flags par réception d'une
interruption sur le canal EVENT, ou par scrutation (lecture adressée pour le MT, accès
mémoire pour le ST). Pour le ST, le choix de l'un quelconque des modes est indifférent à
l'attente active près. Par contre l'attente d'une interruption par le MT interdit tout transfert
de données sur le bus à cause du cycle interne du MCGA qui utilise le bus de données.
Par conséquent, le bus ne peut véhiculer dans ce cas que des signaux de synchronisation.
Tout transfert de données ne peut donc se faire que si le MT fonctionne en mode
60.
Chapitre 3.

---

scrutation. Le bus a donc deux modes de fonctionnement qui s'excluent mutuellement: le
mode signal (ou synchronisation) et le mode communication.
•
Les deux modes (SM et MS) de sélection d'un SCGA peuvent être actifs en même
temps. C'est à dire que si un SCGA a été sélectionné dans un des modes (MS par
exemple) par le MT, il peut être sélectionné à nouveau dans le deuxième mode (SM) sans
attendre de désactiver le premier mode. En d'autres termes, le ST et le MT peuvent armer
et attendre plusieurs types d'interruptions ou de transfert à tout moment.
•
Comme des collisions peuvent survenir si plusieurs SCGA mettent simultanément
le contenu de leur buffer sur le bus de données, un seul SCGA doit donc être sélectionné
en mode de communication SM. Cette restriction ne s'applique pas aux communications
MS, ni aux synchronisations. En conséquence, les communications dans le sens Mf-+ST
sont de type 1-+N; les communications ST-+MT sont de type 1-+ 1; et les
synchronisations sont de type 1+-+N. Le Mf peut donc diffuser un octet à plusieurs ST.
•
Tant qu'un flag est à 0, une interruption peut être générée sur sur le canal EVENT
du MT, dès qu'il active la génération des interruptions pour ce type de flag. li en est de
même pour le ST quand un flag est à 1. Cela signifie que le ST ne doit pas autoriser
d'interruption avant d'avoir mis le flag SMDE à 0; de même que le Mf doit remettre à 1
les flags MSDF des ST pour lesquels il veut attendre une interruption.
•
Avant de commander un transfert d'octet sur le bus, le MT doit désactiver toutes
les sélections de ST qu'il a faites pour la réception des interruptions ANY et ALL,
quelque soit le sens du transfert.
•
Comme données et commandes empruntes deux voies distinctes, il est possible de
transmettre simultanément un octet et une commande. li existe pour cela deux commandes
non adressées : l'une permet de positionner le flag MSDF et de transférer un octet du
MCGA aux SCGA; l'autre permet de positionner le flag SMDE et de transférer un octet
d'un SCGA vers le MCGA. Leur durée: 10 J.l.S, correspond à la durée de la plus longue
des deux instructions ainsi fusionnées.
III. Etude de protocoles de base d'utilisation du bus.
Après avoir expliqué les mécanismes de base du fonctionnement du bus de contrôle, nous
allons maintenant nous intéresser à leur utilisation pour la conception de protocoles de
base de communication et de synchronisation. Nous présentons ces protocoles sous la
forme de couples de fonctions utilisées par un processus du MT et un autre du ST, les
deux fonctionnant de manière symétrique. Nous présentons ensuite les mesures et
61.
Chapitre 3.

---

l'analyse des performances de ces protocoles, que nous comparons aux temps de
références des mêmes fonctions, déduits des mesures présentées dans la partie II.
111.1. Etude des protocoles de base.
De la section II.4, on déduit qu'il y a quatre types de protocoles de base
les
communications MS et SM, et les synchronisations ALL et ANY.
m.l.l. Protocole de communication MS (maitre--7esclaves),
Le principe du protocole pour émettre un octet du Mf vers le ST est le suivant. Le Mf
sélectionne le groupe et le ST dans le mode MS. Puis il transfert un octet, positionne le
flag MSDF à 1, et se met à scruter ce flag pour attendre qu'il reviennent à O. Ensuite, il
désactive la sélection. De son côté, le ST autorise et se met en attente de l'intenuption
MSDF. Quand il est réactivé, le ST lit l'octet du buffer du SCGA, remet le flag MSDF à
0, re-initialise le mécanisme de génération des intenuptions et interdit l'interruption
MSDF:
Control transputer :
Worker transputer :
void MS_send (char group, char worker. cha byte) {
char MS recv 0 {
char"byte;
ENABLE_MSDEN (group, worker) ;
ENABlE_EVENT (MSDF) ;
MS_TRANSFER (byte) ;
WAICEVENT (MSDF) ;
SET_FLAG (MSDF) ;
byte = BUFFER ;
while {Read_FLAG_MSDF (group. worker) = 1)) ;
UNSECFLAG (MSDF) ;
mSABLE_MSDEN (group, worker) ;
RESEf_EVENTS_GLOBALO;
}
DISABLE_EVENT (SMDE) ;
return (byte) ;
}
Ce protocole peut être étendu pour transférer n octets. li suffit pour chaque octet, que le
Mf de répète la séquence : transfert~postionnement de flag~scrutation de flag; et pour le
ST, la séquence: attente de l'interruption~lecturede l'octet~dépositionnementdu flag
MSDF~re-initialisation des intenuptions. Pour diffuser le message à plusieurs ST, le
Mf doit répéter la sélection et la de-sélection pour chaque groupe de ST, et répéter la
scrutation pour chaque groupe et chaque octet. Comme nous l'avons dit dans la section
II.4, il est possible dans ces protocoles de fusionner le transfert de l'octet
(MS_TRANSFER) avec le positionnement du flag (SET_FLAG) en une seule instruction
(MS_SET_&_TRANSFER).
m.l.2. Protocole de communication SM (esclave--7maitre).
Le principe du protocole pour envoyer un octet d'un ST vers le Mf est le suivant. Le Mf
sélectionne le groupe et le ST dans le mode SM, et se met à scruter le flag SMDE du ST
pour attendre qu'il soit à O. Puis il commande le transfert de l'octet, positionne le flag
SMDE à 1, et désactive la sélection. De son côté, le ST inscrit l'octet dans le buffer du
62.
Chapitre 3.

---

SCGA, et met le flag SMDE à O. Ensuite, il initialise la génération des interruptions, et
autorise et se met en attente de l'interruption SMDE. Quand il est réactivé, il interdit
l'interruption SMDE :
Control transputer :
VVorkertransputer:
char SM_recv (char group. char wa-ker) {
void SM_send (char byte) {
char byte;
BUFFER = byte;
ENABLE_SMDEN (group, wmer) ;
UNSEf_A...AG (S~IDE) ;
While (READ_RAG_SMDE (group, wa-ker) = 1);
RFSEf_EVENfS_GLOBAL 0;
byte =SM_lUNSFER 0 ;
ENABLE_EVENT (SMDE);
SEf_A...AG (SMDE);
WAIT_EVENT (SMDE) ;
DISABLE_SMDEN (group, wmer) ;
DISABLE_EVENf (SMDE) ;
,
retum (byte) ;
,
Ce protocole peut être étendu pour transférer n octets. TI suffit pour chaque octet, que le
MT de répète la séquence : scrutation~transfert~positionnement de flag; et pour le ST, la
séquence: inscription de l'octet~dépositionnement de flag~re-initialisation des
interruptions~attente. Là aussi, il est possible de fusionner le transfert de l'octet
(SM_TRANSFER) avec le positionnement du flag (SET_FLAG) en une seule instruction
(SM_SET_&_TRANSFER).
m.l.3. Protocole de synchronisation ALL.
Le principe du protocole pour synchroniser le MT avec les ST d'un groupe en mode ALL
est le suivant. Le MT sélectionne le groupe et les ST dans les modes MS et ALL. Puis il
positionne le flag MSDF à 1, autorise l'interruption ALL (positionnement du masque),
initialise la génération des interruptions, et se met en attente de l'interruption. Ensuite, il
interdit l'interruption, et désactive la sélection ALL et MS. De son côté, le ST exécute le
même algorithme que dans le transfert MS, sans inscrire d'octet dans le buffer :
Control transputer :
Ali worker transputers :
void Wait_ALL (char group. char wmer) {
void Smd_ALL_SIGNAL 0 {
ENABLE_MSDEN (group. wmer) ;
ENABLE_EVENT (MSDF) ;
ENABLE_ALBEN (group, wmer) ;
WAIT_EVENT (MSDF);
SEf_RAG (MSDF) ;
UNSEf_A...AG (MSDF);
ENABLE_EVElIoT_AU 0;
RFSEf_EVENfS_GLOBAL 0;
RFSEf_EVENTS_GLOBAL 0;
DISABLE_EVENT (SMDE);
WAIT_EVENT 0 ;
,
DISABLE_EVENT_AU 0 ;
DISABLE_ALBEN (grouP. wmer);
DISABLE_MSDEN (group, wmer) ;
,
TI est possible de recevoir n interruptions successives. TI suffit pour chaque interruption
que le MT répète la séquence de positionnement du flag à l'attente, et que chaque ST
répète la séquence de l'attente à la re-initialisation des interruptions. Pour se synchroniser
63.
Chapitre 3.

---

avec des ST de groupes différents, il suffit que le MT répète les opérations de sélection
(MS et ALL) et de de-sélection pour chaque groupe.
m.1A. Protocole de synchronisation ANY.
Le principe du protocole pour synchroniser le MT avec un ST en mode ANY est le
suivant. Le MT sélectionne le groupe et le ST dans les modes SM et ANY. Puis il
autorise l'interruption ANY (positionnement du masque), initialise la génération des
interruptions et se met en attente de l'interruption. Ensuite, il positionne le flag SMDE à
1, interdit l'interruption, et désactive la sélection ANY et SM. De son côté, le ST exécute
le même algorithme que dans le transfert SM, sans lire d'octet du buffer :
Control transputer :
Worker transputer :
void WaiCANY (char group. char waker) {
void Send_ANY_SIGNAL 0 {
ENABLE_SMDEN (group, waker) ;
UNSET_A...AG (SMDE) ;
ENABLE_ANBEN (group, waker) ;
RESET_EVENfS_GLOBAL 0;
ENABIE_EVENCM'Y 0 ;
ENABIE_EVEl'\\'T (SMDE) ;
RESECEVENTS_GWBAL 0;
WAIT_EVENT (SMDE) ;
WAfCEVENT 0;
D1SABLE_EVENf (SMDE);
SET_A...AG (SMDE) ;
DISABIE_EVEl'\\'T_ANY 0;
}
DISABLE_ANBEN (groJp, wOl'ker) ;
DISABLE_SMDEN (groJp, waker) ;
}
TI est possible de recevoir n interruptions successives. TI suffit pour chaque interruption
que le MT répète la séquence de la re-initialisation des interruptions au positionnement du
flag SMDE, et que chaque ST répète la séquence du dépositionnement du flag à l'attente
de l'interruption. La généralisation à plusieurs transputers est un peu plus compliquée. La
sélection et de-sélection doit être répétée pour· chaque groupe. Mais comme l'interruption
est générée dès qu'un des ST sélectionnés a dépositionné son flag SMDE, le MT doit
donc faire une boucle de lecture de flag pour déterminer lequel des ST est à l'origine de
rIT. S'il veut acquitter l'interruption individuellement, il doit en plus de-sélectionner tous
les autres ST du mode SM, pour que l'instruction de positionnement à 1 du flag SMDE
ne soit prise en compte que par le SCGA du ST auteur de l'interruption. Le coup d'une
telle opération n'est pas négligeable comme nous allons le voir maintenant.
111.2. Mesure et analyse des performances des protocoles de base.
ill.2.1. Mesures.
Nous avons effectué 5000 mesures pour chacun des protocoles de base décrits à la
section précédente. Ces mesures ont été réalisées sur le MT pour pouvoir les comparer
aux valeurs de référence déduites de la partie n, et dans des conditions telles que chaque
ST est toujours près à l'échange. Les valeurs observées (tableau 5) sont sensiblement
égales aux valeurs de référence.
64.
Chapitre 3.

---

Fonction
1 Durée en J.lS
Minimum de référence
Minimum observé
MS send
49
50
SM recv
49
50
Broadcast pour un groupe
49
50
Wait all pour un groupe
59
60
Wait any
59
60
•Tableau 5-
Temps minimum pour transmettre un octet ou une interruption.
Fonction 1 Mesures Durée de référence
Durée observée
Vitesse de référence Vitesse observée
(en us) x octets
(en us) x octets
(octets/seconde)
(octets/seconde)
Communication MS
20 + 21x
23 + 25x
47 619
40000
Communication SM
19 + 22x
20 + 24x
45454
41666
Diffusion (4 2rouoes)
80 + 54x
100 + 65x
18418
15384
Synchronisation ALL
156 + 20x
221 + 21x
50000 (IT/s)
47619 (IT/s)
(42roupes)
-Tableau 6-
Fonctions de transfert d'interruptions et d'octets sur le bus.
135OO'T"""--------------------------------,
13000
12500
...
y = 100.7105 +6S,(XX)4x
BCAST
12000
Y= 23.3368 + 25,6006x
11500
-MS
...
Y= 20,4421 + 24.6829x
SM
Y= 221.1684 + 21,S803x
11000
-All_IT
10500
lŒXlO
9500
9(0)
..:::1.
8500
..
E
lKXX>
i=
7500
7000
6500
6(XX>
S500
SOOO
4500
4000
3500
3000
2500
2000
1500
1000
SOO 1....l~~.....
Mal_lu
o+e=:;....,.._.,ro_~~......,ro_.,...~_.,ro_"'r""""~__..-
__..-.,.____....-_...,..._1
o
10
20
30
40
50
60
70
80
90
100
110
120130
140
150 160
170
180
190
200
-Figure 7-
Courbes de transfert (broadcast. MS. SM. ALL_m.
Nous avons utilisé ces protocoles d~ base pour déterminer les fonctions de temps de
transfert de x octets ou x interruptions, en ayant appliqué les modifications que nous
65.
Chapitre 3.

---

avons proposées, et en combinant la modification des flags avec le transfert d'octets.
Nous avons effectué les mesures pour 10 à 200 transferts. Chaque mesure a été répétée
100 fois. Les temps obtenus (moyenne de chacune des 100 mesures) sont représentés par
le tableau 6 et le figure 7, avec en comparaison les valeurs de référence des mêmes
fonctions déduites des tableaux 1 à 4.
Remargues : La fonction de diffusion pour un seul groupe est exactement la même que
la fonction de communication MS. La fonction de synchronisation ALL pour un groupe
est la même que pour 4 groupes, à la valeur initiale près.
m.2,2. Analyse des performances.
Des mesures que nous venons de présenter, on peut tirer les enseignements suivants :
•
La vitesse du bus en mode communication ou synchronisation est inférieure à 50
kilo-octets par seconde du fait que ces deux opérations nécessitent au minimum de
modifier un flag (1O~) et d'attendre un acquittement (l0 ~).
•
L'écart entre les valeurs théoriques et les valeurs mesurées résulte de la moyenne
des amplitudes aléatoires des mesures. Ce qui fait que la probabilité d'atteindre la valeur
théorique de 50 ko est presque nulle.
•
Les fonctions de communication MS et SM ont des performances comparables.
Les petites différences qu'on note résultent du comportement aléatoire de l'amplitude.
•
La fonction de diffusion est coûteuse du fait qu'il faut lire l'état des flags MSDF
pour chaque groupe; ce qui coûte au minimum 10 ~ par groupe et par octet. Cependant,
elle permet le transfert d'un maximum de données: le même octet peut être transmis à 32
ST en même temps.
•
La synchronisation est le seul protocole pour lequel la fonction théorique est
équivalente à la fonction caractéristique du bus pour deux. opérations (modification dé flag
+ acquittement) et est comparable à la fonction mesurée. Cela s'explique par le fait que:
l'acquittement (réception de l'interruption par le MT) se faisant en temps constant (cycle
interne du MCGA), seule la modification de flag admet une amplitude. Cependant, la
synchronisation n'est intéressante par rapport aux fonctions de communication qu'au delà
d'un certaine nombre d'interruptions consécutives. Par exemple la diffusion de moins de
trois octets est plus rapide que l'envoi d'autant d'interruptions. En d'autres termes, il vaut
mieux. pour le MT de diffuser deux octets que d'attendre deux interruptions, d'autant plus
que la diffusion réalise elle aussi la synchronisation.
66.
Chapitre 3.

---

IV. Analyse des contraintes et problèmes liés au bus.
fi est essentiel de connaître les contraintes et les problèmes liés à l'architecture spéciale du
bus de contrôle pour réaliser des protocoles élaborés de communication et de
synchronisation sur ce bus. Dans cette section, nous analysons ces contraintes et
problèmes, et nous proposons des solutions adaptées.
IV.1. Analyse des contraintes Imposées par le bus.
Le bus de contrôle pose trois contraintes majeures liées à sa structure, et dont il faut tenir
compte si l'on veut utiliser efficacement ce bus :
•
Faible vitesse du bus. C'est de loin la contrainte la plus importante. Pour 32
transputers servis consécutivement, chacun transmettra à peine un peu plus d'un kilo
octets par seconde. En outre, l'unité de transmission est l'octet, et le MT ne peut recevoir
d'octet que d'un ST en même temps. Tout système de partage du bus devient très vite un
goulot d'étranglement. li faut donc chercher à minimiser le nombre d'accès au bus.
•
Contrôle centralisé. Les transputers de travail ne peuvent pas communiquer entre
eux sans passer par le contrôleur. Deux ST ne peuvent donc pas échanger plus de 25 ko
par seconde. Le transputer de contrôle devient de ce fait un goulot d'étranglement. li faut
donc minimiser les communications individuelles (e.g. entre le MT et un seul ST).
•
Mode de programmation. La séquence type de programmation du bus est :
sélection-transfert-annulation de la sélection. Or les opérations de sélection et
d'annulation (phases initiale et finale) sont très coOteuses,
en particulier pour la
synchronisation et la diffusion. L'utilisation du bus ne devient intéressante que si la phase
de transfert est longue (e.g. plus de trois interruptions). En outre, certaines opérations
sont incompatibles avec d'autres (synchronisation / communication; transfert dans le
•
même sens de messages différents destinés à des ST différents), ce qui nécessite de
sélectionner et de-sélectionner les ST pour ces opérations. Enfin, il n'existe pas de
commande globale pour annuler une sélection: on est obligé de procéder groupe par
groupe; il en est de même pour la lecture des flags dont on voit les effets dans la fonction
de diffusion. li faut donc maximiser le nombre de transferts une fois qu'une sélection est
faite, et ne faire la de-sélection qu'au moment de réaliser une opération incompatible avec
la sélection courante: la de-sélection par nécessité.
iV.2. Analyse des problèmes liés au bus.
Le bus de contrôle pose deux problèmes qu'il est essentiel de résoudre pour réaliser un
protocole de communication ou de synchronisation à travers ce bus:
67.
Chapitre 3.

---

•
Conflits d'accès au bus entre le MT et les ST. Le ST et le MT peuvent modifier
simultanément les flags et le buffer du SCGA. notamment si chacun décide d'envoyer un
octet à l'autre. li faut donc un protocole d'arbitrage pour régler ce type de conflits.
•
Concurrence d'accès au bus entre plusieurs processus sur le même transputer. Un
seul processus à la fois peut accéder au bus de contrÔle sur chaque transputer du fait qu'il
n'y a qu'un seul canal EVENT. et que les adresses mémoire sont fixes. Le bus est de ce
fait une ressource critique qui nécessite un protocole de partage si l'on veut que plusieurs
processus l'utilisent.
IV.3. Proposition de solutions.
Nous proposons dans cette section. des solutions pour arbitrer les conflits d'accès au bus
et pour optimiser les commUIÙcations en vue de gagner du temps sur la lenteur du bus.
IV.3.1. Arbitraie des conflits d'accès au bus.
a. Arbitrage des conflits maître-esclave.
Un conflit maître-esclave naît uniquement quand le MT (maitre) et le ST (esclave)
décident d'émettre en même temps. Une solution consiste à réaliser un protocole
déterministe. de sorte que ce conflit ne se présente jamais. Mais cela n'est pas toujours
possible et peut en particulier imposer des restrictions comme une taille fIxe pour les
messages. Nous proposons une solution qui consiste à détecter et résoudre le conflit
dynamiquement lors de l'émission du premier octet de la communication. En effet.
comme le MT et le ST après avoir modifié chacun son flag (MSDF. SMDE) attendent un
acquittement l'un de l'autre. il suffIt alors pour arbitrer. qu'un des deux soit capable de
détecter le changement des deux flags. li doit alors recevoir le message du partenaire,
avant d'envoyer le sien. Le MT et le ST peuvent tous les deux jouer ce rôle. Après avoir
analysé les deux possibilités d'arbitrage, nous avons décidé de choisir -le ST comme
arbitre. Nos raisons sont les suivantes:
•
CoOt minimum en temps d'arbitrage. Si le MT est l'arbitre, alors, après avoir
positionné le flag MSDF, il doit lire l'état des deux flags SMDE et MSDF pour connaître
l'état du ST. Si MSDF est à 0, cela signifIe que le ST a accepté de commUIÙquer parce
qu'il n'avait rien à émettre. Si le flag SMDE est à 0, cela veut dire que le ST veut lui aussi
émettre. Le MT doit donc recevoir le message du ST avant de transmettre le sien. A cause
de la lecture du flag SMDE, il coOtera donc au minimum 10 ilS au MT pour détecter et
résoudre le conflit. Alors que si nous tenons le même raisonnement avec le ST. le coOt est
68.
Chapitre 3.

---

de l'ordre de deux micro-secondes (accès au flag au flag MSDF en mémoire, test de l'état
de ce flag).
•
CoOt supplémentaire pour la diffusion. Choisir le MT comme arbitre interdit
automatiquement la diffusion. En effet, avant de diffuser, le maître doit d'abord arbitrer
tous les conflits possibles avec chaque esclave. C'est à dire qu'il doit au minimum lire
l'état des flags SMDE de chacun des groupes de ST; ce qui coOte au minimum 10 JLS par
.groupe.
Pour éviter que le MT et ST n'écrivent simultanément dans le buffer du ST, le premier
accès au bus du ST pour chaque message à émettre sera une simple demande
d'autorisation d'émettre consistant à mettre à 0 le flag SMDE. Ne donnant pas lieu à un
transfert, cela ajoute un coOt minimum de 20 I-lS par message émis par l'esclave,
correspondant à l'acceptation par le MT de la demande: lecture du flag SMDE +
positionnement de ce flag à 1. Ce coOt aurai été le même si le MT était arbitre. Cependant
en choisissant le ST comme arbitre, si le MT procède par scrutation du bus, alors le
temps lié à la lecture du flag peut être partagé par tous les ST du même groupe.
b. Arbitrage de la concurrence sur le même transputer.
Ce conflit nait quand plusieurs processus d'un même transputer veulent accéder
simultanément au bus. Une solution possible est d'utiliser un sémaphore. Cette solution -
n'est acceptable que si les communications se font dans un seul sens: l'émission; sinon il
faut en plus résoudre le problème qui résulterait du fait qu'un processus peut récupérer
sur le bus un message qui n'est pas le sien. Dans le cas de communications mixtes, nous
proposons d'utiliser un processus contrôleur chargé de communiquer sur le bus sur
chaque transputer. li reçoit à travers une FIFO ou des canaux les messages des autres
processus, qu'il émet sur le bus; et il livre à ceux-ci les messages arrivant, à travers des
canaux internes ou une FIFO.
N.3.2. Optimisation des communications pour iaiJ1er du temps.
Une technique pour gagner du temps consiste à regrouper les opérations de base
communes à plusieurs communications sur le MT. Les opérations de sélection et de de-
sélection portent sur tout un groupe; les opérations de lecture de flags aussi; les
opérations de transfert et de modification des flags portent sur tous les transputers
sélectionnés. Optimiser les communications revient donc à grouper ces opérations au
niveau de l'octet, du message, ou du groupe de messages à transmettre simultanément.
(f).
Chapitre 3.

---

•
Niveau octet. On peut regrouper le transfert et le positionnement du flag
correspondant comme nous l'avons déjà dit. Le coût est le même que celui de l'opération
de positionnement de flag seu1e. On gagne donc 10 ~s par octet.
•
Niveau message. L'opération de sélection peut se faire une seule fois pour le
premier octet, et la de-sélection pour le dernier octet, comme nous l'avons décrit §m.l.
•
Groupement de messages. Nous avons étudié la possibilité d'envoyer
simultanément des messages différents à des ST différents. La procédure est décrite en
annexe 2. Son principe consiste à transférer individuellement le ième octet de chaque
message, et à envoyer une interruption à tous les ST pour signaler le transfert de ce ième
octet. L'analyse de cette procédure montre que la taille maximale de chaque message doit
être d'un octet et qu'il faut au minimum 4 ST par groupe. Dans ce cas, par rapport à la
procédure décrite §m.l.l qui consiste à envoyer chaque message individuellement, on
gagne 10 ilS par groupe. Chaque ST supplémentaire, fait gagner 10 ilS. On remarque
ainsi (Annexe 2, tableau A7) que cette procédure fait gagner 200 ~s pour un octet
différent envoyé à chacun des 32 transputers, que si l'on appliquait les procédures de la
section §ill.1.1.
V. Moniteur asynchrone de communication sur le bus.
Le moniteur décrit dans cette partie résu1te de l'étude menée dans les parties précédentes.
Il met en œuvre une politique de partage du bus entre tous les processus pouvant
s'exécuter sur le SuperNode. li permet à n'importe quel processus de communiquer à
travers le bus avec des processus d'autres transputers ou de la carte frontale. li sert en
particulier à véhiculer les messages du système de mise au point CDS et du configureur
dynamique. Ce moniteur est destiné à être utilisé en phase de mise au point. li est
constitué de processus permanents repartis sur tous les transputers du SuperNode, et
d'un ensemble de mes d'attente pour communiquer avec les processus utilisateur. Le
moniteur est accessible à travers un petit nombre de fonctions.
Cette section décrit l'architecture et le fonctionnement de ce moniteur. Nous en donnons
également des mesures de performances et quelques applications qui l'utilisent. EnfIn,
nous dégageons les avantages et le limitations de ce moniteur.
V.l. Architecture et fonctionnement.
Le moniteur comporte un ensemble de processus résidents sur le transputer de contrôle et
les transputers de travail (fIg. 8).
70.
Chapitre 3.

---

Y, l. l. Moniteur du transputer de contrôle.
Le rôle de ce moniteur est d'assurer le transfert à travers le bus des messages en
provenance ou à destination des transputers de travail, de la carte frontale, ou du
processus du reconfigureur s'exécutant sur chaque transputer. Ce moniteur comporte
trois processus en plus du processus reconfigureur :
•
Processus moniteur. C'est le gestionnaire du bus. TI scrute le bus pour voir si un
ST veut communiquer. Si oui, il lui donne l'autorisation d'émettre et reçoit aussitôt le
message et selon son code, l'envoie à travers un canal interne au processus du
reconfigureur ou au processus interface du lien de sortie de la carte frontale, ou bien
l'empile dans une FIFO en attendant de le transmettre au ST destinataire. Ensuite, si la
FIFO du reconfigureur n'est pas vide, il retire un message et selon le type, le diffuse à
tous les ST ou l'envoie à un ST donné. Enfin, si cette fIle est vide, le moniteur retire un
message (s'il en existe) de la fIle des messages en transit et, selon le type, le transmet au
ST destinataire ou le diffuse à tous les ST. La fonction de scrutation sélectionne les ST de
la façon suivante. Elle lit les flags SMDE d'un groupe. S'il existe des bits à 0, la fonction
détermine la position du premier bit et le numéro du ST correspondant. Lors du prochain
appel, la fonction détermine la position du bit à °suivant; et ainsi de suite jusqu'à
épuisement de l'octet. Si aucun bit du groupe n'est à 0, ou si un groupe a été épuisé, la
fonction lit les flags du groupe suivant et cela éventuellement jusqu'à parcourir chacun
des 4 groupes.
•
Processus interfaces des liens d'entrée/sortie. Le premier processus sert à
transmettre à la carte frontale les messages émis par le processus moniteur ou le
processus du reconfigureur. Le second sert à recevoir les messages émis par la carte
frontale. Il inscrit ceux destinés aux ST dans la file des messages en transit, et
communique au processus TéNOR les siens à travers un canal (ce dernier cas est une
extension éventuelle de TéNOR).
•
Processus du reconfigureur. fi est dédié à la configuration dynamique. fi reçoit du
processus moniteur, les messages de fins de phase émis par les ST, et transmet à ce
processus à travers une FIFO, les messages de changement de phase destinés aux ST.
71.
Chapitre 3.

---

Host transputer
board input link
Control transputer
TéNOR
process
Control bus
Worker
transputers
-Figure 8-
Architecture du moniteur du bus de contrôle.
y. 1.2. Moniteur du transputer de travail.
Le rôle de ce moniteur est de transmettre sur le bus, les messages des processus
utilisateur, du système de mise au point ou du reconfigureur dynamique, destinés à
d'autres ST, à la carte frontale, ou au processus reconfigureur du transputer de contrôle.
Il comporte quatre processus en plus de ceux du système de mise au point, de
l'utilisateur, et du reconfigureur dynamique:
• Processus
moniteur. C'est le gestionnaire du bus du côté du ST. li est en
permanence en attente d'une communication sur trois types de canaux :
• Une communication sur le canal EVENT signifie que le MT veut émettre un
message sur le bus. Le processus reçoit le message en question en utilisant la
procédure §ITI.1.1. Ensuite, selon le type, il communique le message au
processus reconfigureur ou l'inscrit dans la FIFO des messages à livrer.
• Une communication sur le canal de l'interface du reconfigureur indique la
présence d'un message dans la FIFO du reconfigureur. Le processus reçoit alors
ce message de l'interface et demande une communication sur le bus. Si un conflit
se produit, c'est à dire que le MT veut lui aussi émettre, conformément à ce que
72.
Chapitre 3.

---

nous avons dit §IV.3.1.a, le moniteur reçoit le message du MT, le livre, et se
remet en attente de l'acceptation de sa demande de communication. Quand celle-ci
est accordée, le moniteur transmet le message.
• Une communication sur le canal de l'interface utilisateur indique la présence
d'un message dans la FIFO des processus utilisateur et du système de mise au
point. Le processus moniteur procède comme avec le reconfigureur.
• Processus interfaces. Ce sont deux processus serveurs de chacune des FIFO du
reconfigureur et utilisateur. Quand il y a un message dans une des FIFO, l'interface
correspondante le communique au processus moniteur. Quand une FIFO est vide, son
interface se suspend, et n'est réveillée que lors qu'un nouveau message est inscrit par le
reconfigureur ou un processus utilisateur. Ces deux processus ont été prévus pour que le
processus moniteur puisse prendre en compte la présence d'un message dans la FIFO de
la même manière que la présence d'une communication sur le bus. Ce qui nous a permis
d'éviter une attente active du moniteur.
• Processus serveur. Son rôle est de livrer au système de mise au point ou aux
processus utilisateurs les messages arrivant sur le bus et inscrit par le processus moniteur
dans la file d'attente correspondante. Chaque message porte soit un code de canal
standard, soit une adresse de canal par lequel il doit être livré. Les communications sont
temporisées pour éviter l'attente infinie.
• Processus reconfigureur. Il reçoit du processus moniteur, les messages de
changement de phase transmis par le MT à travers le bus. Il inscrit dans une FIFO
spéciale, les messages de fin de phase destinés au MT.
• Processus utilisateur et système de mise au point. Ces processus inscrivent
dans une FIFO, les messages destinés à d'autres ST ou à la carte frontale. lis reçoivent
les messages émis par d'autres ST ou la carte frontale, à travers des canaux pre-définis ou
des canaux dont les messages portent l'étiquette (fig. 12).
V.2. Mesure et analyse des performances.
Y.2.1. Répartition des temps de communication à travers le moniteur.
L'acheminement d'un message à travers le moniteur, se divise en 10 étapes tl-l0 (fig. 9)
pour un message utilisateur ou du système de mise au point, et 9 étapes 1'1-9 pour un
message du reconfigureur (fig. 10). Ces étapes sont constituées des temps suivants:
accès aux FIFO (inscription, retrait de message); communication à travers des canaux
73.
Chapitre 3.

---

internes; accès au bus; et transfert sur le bus. Le tableau 7 donne le minimum de ces
temps. L'étape t4 (ou T4) ) comprend l'accès au bus (scrutation) et le transfert SM.
t7
User
process
S_bus_monitor
M_bus_monitor
t4
L:=:.....:....-.:.-.J-;~II.l.wu..LlJ
-Figure 9-
Cheminement d'un message utilisateur.
r------.;I"""-.......- - - - - , T8
1....-
----1 T4
T5
-Figure 10-
Cheminement d'un message du reconfigureur.
Comm.
AccèsFIFO
scrutation
commSM
CommMS
Diffusion
canal
Temps
5-10
10-20
4
8
20,4 + 24,6x
23 + 25,Sx
100,7 + 65x
en Ils
20~ (l + ~ (1 - bij»
Etapes
t3, UO
t1, tS, t8,
t4,
t7,
t7,
TI. T5. 1'9
Tl, T6
T4
T8
T8
-Tableau 7-
Répartition des temps (le : nombre de ST; n nombre de groupes; x nombre d'octets du message;
bij = valeur du bit nO j du groupe i).
17000 . . , . . . - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ,
y=688,6212+ 129,7315x
. . Beas!
16000
15000
y = 565.6667 + 60,4231x
....
Send
14000
13000
12000
'"
:::L
11000
10000
Ë
!=
9000
8000
7000
6000
5000
4000
3000
2000
l000-l...oo'~~
Bytenumber
O+-......."""T'.....,.-r--or--"T'""...,..."""T'--r......,r--......"T'"".......-r.....,.......,r--..--T'""".......-r............,.-~
o
10
20
30
40
50
60
70
80
90
100
110
120
-Figure 11-
Temps de communication entre transputers de travail.
La scrutation comme nous l'avons dit comprend la lecture et l'exploitation des flags
SMDE qui sont à O. La lecture des flags coOte 20 JlS pour chaque groupe, et l'exploitation
de chaque bit (y compris le premier) coOte 20 JlS. Cela signifie que pour accéder au kxme
bit du groupe, il faut au minimum 20(1 + k) JlS. De même un tour de scrutation des ~4
groupes coOte au minimum 20n IlS. D'autre part, l'étape t2 (ou T2) correspond à
l'activation du processus interface; de même l'étape t6 (ou T7) correspond à un simple
74.
Chapitre 3.

---

test. Ces transitions ne donnent pas lieu à de mouvement de données et ne sont de ce fait
pas représentées dans le tableau 7.
V.2.2. Temps de communication entre transputers de travail.
La figure Il représente la fonction du temps moyen de cheminement d'un message d'un
ST vers un autre, c'est à dire au parcours de t1-1O sur la figure 9: ST--+MT--+ST. L'envoi
à travers le moniteur, d'un message d'un processus vers un autre (fonction Send) et la
.diffusion d'un processus vers tous les 32 transputers (fonction Bcast) ont un coat initial
très élevé da au franchissement des différentes transitions de la figure 9 et au transfert de
deux octets de contrôle. La fonction Send comporte deux transferts sur le bus: SM
(émission) et MS (réception). En se reportant au tableau 6 et à la figure 7, on remarque
que le coat observé minimal pour transmettre un octet avec la fonction Send est 95 J.1S.
Mais la présence d'une couche logicielle supplémentaire (temps de transferts
intermédiaires) augmente considérablement ce coat.
V.3. Quelques applications utilisant le moniteur.
V.3.1. Les entrées-sorties.
A cause du nombre limité des liens du transputer, seul un petit nombre de ST peuvent être
reliés à la carte frontale. Seuls ceux-ci peuvent donc réaliser des entrées-sortie. Pour
pallier à cet inconvénient, nous avons réalisé un fonction de trace, qui permet à n'importe
quel processus d'envoyer sur la sortie standard, des messages dont le format est le même
que celui de la fonction printf du langage C. Les limites principales de cette fonction sont
le temps de communication (282 + 30x J.1S pour transmettre x octets) et la taille bornée des
mes d'attente. Malgré ces limites, cette fonction a été d'un grand recours lors de la mise
au point du système C_NET.
V.3.2, La reconfiiillation dynamique,
Le bus de contrôle est un des pilliers de la mise en œuvre de la reconfiguration
dynamique. Nous avons dit plus haut que les messages de changement de phase
transitaient par le moniteur du bus. Mais plus encore, le moniteur du bus permet de
synchroniser les processus du reconfigureur des ST et du MT, de telle sorte que ce
dernier peut reconfigurer le switch en étant sOr qu'aucun processus n'utilise les liens
correspondant sur les ST, et que les communications de la phase suivante ne peuvent
démarrer que quand la reconfiguration est terminée. Comme on peut le constater, la
vitesse de transmission des messages par le moniteur est particulièrement déterminante
pour le changement de phase, et contribue à définir la granularité de la reconfiguration.
En effet, pour changer de phase, il faut ·que chaque ST émette un octet signalant la fm de
75.
Chapille 3.

---

phase, et que le MT diffuse un autre octet indiquant le numéro de la phase suivante.
Suivant le tableau 6 et 7, cela prendrait au minimum 2293 IJ.S pour changer de phase en
utilisant ce moniteur (scrutation et communications) pour 32 transputers. li faudrait y
ajouter le temps de transit dans les FIFO, et le temps de reconfiguration proprement dit.
Nous y reviendrons dans la partie suivante.
y.3.3. Synchronisation des horloies.
Nous avons développé un protocole supplémentaire pour la synchronisation des
horloges. L'initialisation de ce protocole se fait par un message transmis par le moniteur
du ST vers le MT. Ensuite le ST et le MT exécutent chacun une fonction spéciale
permettant au ST de recevoir l'heure du MT et de mettre sa propre horloge à jour. Ce
protocole est détaillé au chapitre 4.
y.3.4. Communication entre transputers.
A travers le moniteur du bus, n'importe quel processus peut envoyer un message à
n'importe quel autre sur un autre transputer, ou diffuser un message destiné à tous les
ST. Ces messages peuvent être reçu à travers des canaux pre-défmis ou n'importe quel
canal. Ce mécanisme est utilisable pour concevoir des protocoles de contrôle
indépendants des topologies. Nous avons développé deux applications utilisant ce
mécanisme pour la génération des points d'arrêt globaux (chapitre 5). La première est la
gestion des prédicats globaux, et la seconde, la gestion des demandes et des terminaisons
des points d'arrêt des processus. En utilisant la diffusion, à partir de la figure lIon
remarque qu'il faut au minimum 8181J.S pour arrêter le système.
V.3.5. Mise au point interactive des proceSSus.
Le système CDS (chapitre 6) utilise le moniteur pour convoyer les messages de mise au
point de façon transparente au réseau principal. La figure (fig. 12) montre un exemple
d'acheminement d'un message de mise au point par le moniteur. On y voit l'inscription
d'un message dans la file (SCBUS-post), son formatage, et la transmission sur le bus
jusqu'à la carte frontale. Un message suivant le chemin inverse est également représenté.
Grâce à cette communication bi-directionnelle, CDS permet au programmeur de dialoguer
avec les processus, et en particulier la validation des prédicats, d'activer et désactiver les
points d'arrêt depuis sa console de mise au point (voir chapitre 6).
76.
Chapitre 3.

---

recv from frontal board(. ..)
send to frontal board
~zwAAAAmessage
FIFO
y message AAAAsz 1
message MAA c w
sz: message size
w: worker transputer number
C : message code
AAAA : channel address
message
ChanOut(AAAA,message. sz)
message
.SCBUS_receiveCAAAA. buffer)
User process
-Figure 12-
Transit des messages de mise au point dans le moniteur.
V.4. Avantages et limitations.
L'atout majeur du moniteur que nous venons de présenter est la possibilité qu'il donne à
tous les processus de réaliser des communications à travers le bus, à n'importe quel
moment. Cela permet en particulier de réaliser des protocoles indépendants de la
topologie du réseau principal. Mais il présente un certain nombre de limitations:
•
La facilité de communiquer se paye contre des temps de transfert élevés par
rapport aux temps espérés. Cela est dû en particulier à la scrutation, à la résolution des
conflits (demande d'accès au bus) et aux étapes intermédiaires (PIFO, communication par
des canaux), et au transfert d'octets de contrôle (codes)
•
Le moniteur n'exploite pas toutes les potentialités du bus. La synchronisation par
les interruptions ALL et ANY n'est pas utilisée. Or nous avons w que la synchronisation
ALL avait des performances très proches de la vitesse annoncée du bus.
•
Dans le cas spécifique de la reconfiguration dynamique, le fait que le Mf reçoive
les messages de fm de phase individuellement de chaque ST conduit à un grain de
reconfiguration très grossier.
VI. Moniteur de communication Synchrone.
Mm 'd'améliorer le grain de la reconfiguration dynamique, nous (équipe SLP) avons
étudié une version du moniteur, dite synchrone du fait que le protocole qu'il met en
œuvre entre le MT et les ST est symétrique et déterministe. TI ne comporte pas de conflit
7i.
Chapilte 3.

---

entre transputers, et est basé sur la transmission de séquences de signaux entre les ST et
le MT. Avec ce moniteur,le bus est totalement dédié à la réconfiguration dynamique [9]
[28]. Cette partie présente ce moniteur, et en donne des éléments de performances.
VI.1. Présentation du moniteur synchrone.
Vu que ce moniteur comporte un certain nombre de similitudes avec le moniteur
asynchrone sur le plan architectural (fig. 13), nous allons simplement décrire les
spécificités liées à son fonctionnement, à savoir, le déterminisme, l'utilisation de la
synchronisation globale, et des optimisations.
end_oCinterphase_computation
next_phase_id_available
cJJWitch
1
oonfigpart
node_dataJeq
,
~
config_end_oCprogra m
l
switchJeset
one_phase_furtherjn_config
c~pl
switchJeset_done
&end: NDR
,1
broadcast: NPI,
1
USR, SRL, END
::tI
00
t'l
t'l
Z
Z
l
t'l
::tI
0
0
e e
t-
t-
""0
""0
0
0
_ FIFO_
e
0
e
host transputer
board
1
M:....bus.,.monltor
CONTROUER
,
WORKERS
S....bus.,.monltor
.- --
1
1
1
t
Z
c:::
00
t'l
Z
~ FIFO_ ~ interface 1
:s 00 ::tI Z e
::tI
t-
e
::tI
f-
I
/
1
,
1
1
1
.......
_
stoPJoutin~layer_done
NDGI,NDGD
stoPJoutin~layer
router
w~l
REL, SRLD, EOP, EOPG
-Figure 13-
Moniteur synchrone (extrait de [28]).
78.
Chapitre 3.

---

YI. 1.1. Protocole déterministe.
Pour éliminer les conflits maître-esclave, le MT et les ST exécutent des séquences
symétriques et déterministes, mais comportant un certain nombre de choix déterminés
statiquement à la compilation du programme utilisateur.
VI. 1.2. Synchronisation ilobale.
Au lieu de recevoir individuellement les messages de fm de phase des ST, le MT reçoit
une interruption globale sur le canal EVENT quand tous les ST sont arrivés en fm de
phase. Le message de fin de phase est un simple code, ce qui fait qu'il nous a été facile de
le remplacer par un signal. La séquence se déroule de la façon suivante: quand le
processus moniteur du ST (fig. 13) a reçu un message de libération des canaux
(RELEASE) du
processus reconfigureur, il dépositionne le flag MSDF. Le
dépositionnement de ce flag par tous les ST génère une interruption ALL sur le MT
comme nous l'avons décrit. En plus de RELEASE, il existe d'autres signaux dont le MT
et chaque ST déterminent le type suivant l'ordre d'occurrence.
Cependant, chaque ST peut avoir des données spécifiques à communiquer au MT (une
seule donnée par phase). Dans ce cas, le MT après avoir diffusé une demande de
communication des données, reçoit le message de chaque ST.
VI.1.3. Optimisations,
Nous avons réalisé deux types d'optimisations dans ce moniteur :
•
Recouvrement des communications. Nous avons appliqués la technique de de-
sélection par nécessité que nous avons décrite. Quand plusieurs séquences de diffusion
ou de synchronisation se suivent, la sélection n'est faite que pour la première séquence, et
la de-sélection, pour la dernière. De plus, un message arrivant du bus est livré au
reconfigureur avant d'annuler la sélection des ST.
•
Utilisation de la mémoire interne. Le bus n'est pas seul responsable des longs
temps de transfert des messages (fig. Il), mais également l'accès à la mémoire externe
des transputers. Ce temps est particulièrement élevé pour les tableaux. Nous avons donc
placé les variables du moniteur en mémoire interne, dont l'accès est beaucoup plus
rapide.
79.
Chapitre 3.

---

VI.2. Eléments de performances.
Ces performances visent à établir le grain de la reconfiguration dynamique. Ces mesures
ont été menées en collaboration avec Christophe Bonello pour les parties concernant
l'accès au configureur [28].
VI.2.1. Répartition des temps de chana:ement de phase.
Nous avons mesuré le temps minimum qu'il fallait pour parcourir les 9 étapes de la
figure 10 et le temps de positionnement du switch par le processus reconfigureur. Ces.
temps (tab. 8) peuvent être divisés en 5 parties:
•
Envoi d'une requête de fin de phase (RELEASE) : étapes TI-2 (fig. 9). Cette
partie concerne le processus reconfigureur qui à la fm de la phase compose une requête
destinée au MT et l'inscrit dans la FIFO.
•
Envoi d'un signal global de fm de phase MT : étapes T3-4. Cette phase met en jeu
le processus interface et le processus moniteur du ST. L'interface, activée éventuellement
par le processus reconfigureur si la file était vide, demande une communication au
processus moniteur. Celui-ci de son côté attend un signal du contrôleur. Quand il l'a
reçu, il accepte alors la demande de communication de l'interface et il met à 0 le flag
MSDE. La mise à 0 de ce flag par tous les ST produit une interruption sur le MT.
•
Reconfiguration du switch : étapes T5-6. Le processus moniteur du MT ayant
reçu l'interruption, envoie un message de fm de phase au processus recoilfigureur,lequel
reconfigure alors le switch (200 ilS maximum). Et dès qu'il a terminé, il met dans la FIFO
une requête de changement de phase indiquant que la configuration est terminée et
donnant le numéro de la nouvelle phase.
•
Diffusion d'un message de changement de phase: étape TI-8. Le processus
moniteur du MT retire le message de la FIFO et le diffuse à tous les ST.
•
Changement de phase: étape T9. Le processus moniteur de chaque ST ayant reçu
l'octet diffusé par le MT sur le bus, le transmet au processus reconfigureur par un canal
interne. Ce dernier en recevant ce numéro, détermine et démarre la nouvelle phase.
Envoi requête Envoi signal Reconfiguration Diffusion d'un Changement
de fin de phase global de fin
du switch
message de
de phase
de phase
changement
de ohase
Temos en Us
57
196
244
122
43
Etaoes (fig. 9)
Tl-2
1'3-4
T5-6
T7-S
1'9
-Tableau 8-
Répartition des temps pour un changement de phase.
80.
Chapitre 3.

---

Ces mesures montrent clairement le gain de temps de changement de phase par rapport à
la version asynchrone du moniteur. Ce gain est confirmé par l'exemple du gradient
conjugué que nous allons maintenant présenter.
VI.2.2. Mesure d'un exemple d'application: le ifadient conjuiué.
Une application du gradient conjugué développée par un membre de l'équipe LSP pour le
.projet C_NET a donné les temps du tableau 9. Cette application utilise trois topologies.
Ces mesures montrent clairement un gain de temps avec le moniteur synchrone.
Taille matrice
32
64
128
256
512
1024
Version
179 582
828 867
5394 719
asynchrone
16073
32413
66 020
Temos en Us
Version
synchrone
2819
6418
20 612
98795
641 595
4901 987
Temps en Us
-Tableau 9-
Mesures comparatives des deux versions du moniteur pour le gradient conjugué.
V. Conclusion.
Nous avons présenté un modèle de fonctionnement du bus de contrôle du SuperNode.
Ensuite, nous avons proposé des protocoles de base de communication et de
synchronisation entre les transputers de travail et le transputer de contrôle. Enfm, nous
avons décrit deux versions d'un moniteur utilisant ce bus. La première permet de réaliser
tous les types de communications possibles avec ce bus, et la seconde est dédiée au
reconfigureur pour améliorer le grain de la reconfiguration dynamique. Les mesures
données dans ce chapitre peuvent être réparties en trois groupes: temps des opérations de
base; temps des protocoles (ou fonctions) de base; performances du moniteur.
Le moniteur qui vient d'être décrit est facilement portable sur d'autres configurations de
SuperNode. Pour le MégaNode, il nécessitera l'extension du codage des messages et
l'adaptation du processus M_bus_monitor aux transputers de contrôle intermédiaires. Le
moniteur peut être vu comme un lien supplémentaire sur chaque transputer. Un
mécanisme spécial, décrit dans [93] a été prévu pour permettre à plusieurs processus de
recevoir des messages du moniteur à travers des canaux internes à chaque processus.
Ce moniteur permet de développer des applications nécessitant des échanges de messages
indépendamment de la configuration du réseau principal. Un exemple d'application de ce
type est l'extension de l'accès aux ressources standards (e.g. entrées-sorties) à tous les
transputers. La seule limite à une telle application est la vitesse du bus.
81.
Cbapitre 3.

---

Comme tout moniteur logiciel, le fonctionnement de ce moniteur induit des perturbations
sur l'ordonnancement des processus utilisateurs car le moniteur s'exécute essentiellement
en haute priorité (interruption de processus de basse priorité). On peut rendre ces
interférences équitables à tous les processus en exécutant le moniteur en priorité basse.
Mais en contre partie, cela ralentirait le débit du moniteur.
82.
Chapitre 3.

---

Chapitre 4.
Algorithme statistique et probabiliste pour la
synchronisation des horloges.
1. Introduction.
La réalisation des points d'arrêt globaux (chapitre 5) et l'estampillage des traces en w
d'établir une relation temporelle entre les événements (chapitre 6) nous ont conduits à
étudier les possibilités d'utilisation du bus de contrôle du SuperNode pour synchroniser
les horloges des transputers de travail. L'étude faite au chapitre 2 nous a permis
d'analyser les algorithmes de synchronisation des horloges existants, avec les
contraintes que cela comporte. Nous avons utilisé les mesures faites (chapitre 3) pour
d'une part estimer ce qu'il coûterait en temps de communication d'utiliser le bus de
contrôle pour implémenter ces algorithmes. Cette étude devait nous permettre de choisir
le meilleur de ces algorithmes (minimum de messages, maximum de précision) pour
notre système. Compte tenu des résultats obtenus, nous avons étudié et implémenté une
nouvelle version de l'algorithme probabiliste (cf. chapitre 2, section m.3) qui s'adapte
mieux aux performances de ce bus.
Ce chapitre présente l'analyse que nous avons menées sur les performances du bus de
contrôle pour la synchronisation des horloges, et la nouvelle version de l'algorithme
probabiliste que nous avons développée. Cet algorithme (dit statistique et probabiliste)
est basé sur les statistiques des temps de communication pour déterminer l'intervalle des
temps de communication acceptables pour la synchronisation des horloges, et
l'intervalle de lecture des horloges. En utilisant le théorème de Bienaimé-Chebychev et
la loi de Bernoulli, nous avons dérivé une borne inférieure de la probabilité de
synchroniser les horloges, et une borne supérieure du nombre moyen de
communications pour lire une horloge. Grâce à ces bornes, à la différence de celui de
Cristian [42], notre algorithme peut être utilisé même si la loi de probabilité des temps
de communication n'est pas connue. De plus, contrairement à celui de Cristian, notre
algorithme s'adapte à la charge du réseau.
La deuxième partie de ce chapitre présente l'analyse des performances du bus pour la
synchronisation des horloges. Nous y décrivons comment nous avons mesuré les
paramètres de synchronisation des horloges, et nous donnons les mesures que nous
avons utilisées pour estimer les perf~rmances des algorithmes existants. La troisième
partie décrit l'algorithme statistique et probabiliste pour la synchronisation des horloges.
83.
Cbopitre 4.

---

Cet algorithme étant dérivé de l'algorithme de Cristian, nous ne présentons donc que les
aspects spécifiques à notre version. La quatrième partie décrit l'implémentation et
l'analyse des performances de notre algorithme et établit une comparaison avec
l'algorithme de Cristian implémenté à cet effet. La cinquième partie présente des
extensions possibles de notre algorithme. Enfin, l'annexe 3 donne les algorithmes
implémentés, et l'annexe 4 donne une trace de cet algorithme.
Il. Analyse des performances du bus pour la synchronisation
des horloges.
Nous avons cherché à établir ce qu'il coûterait d'utiliser le bus de contrôle pour la
synchronisation des horloges en regard des paramètres et des algorithmes présentés au
chapitres 2, et des mesures du chapitre 3 effectuées sur ce bus. L'objectif de cette partie
est de présenter cette analyse. La contribution du bus porte sur les paramètres de
synchronisation et sur le mode de communication:
•
Nous avons vu au chapitre précédent que la dérive p et l'erreur de lecture E sont
les deux paramètres dépendant de la machine qui interviennent dans la synchronisation
des horloges. Les autres paramètres sont soit des constantes (nombre de processeurs,
précision à atteindre, nombre de pannes à tolérer), soit déductibles des autres
paramètres (période de synchronisation, nombre d'essais). Nous avons donc dans un
premier temps estimé ces deux paramètres.
•
Les modes de communication possibles sont la diffusion de chaque transputer de
travail (ST) vers tous les autres ou du transputer de contrôle (MT) vers tous les ST, et la
communication entre les ST ou entre le Mf et chaque ST.
Dans cette section, les termes se rapportant au bus sont ceux qui ont été définis au
chapitre 3.
n.l. Mesure de l'erreur de lecture sur le bus de contrôle du SuperNode~
Nous avons vu au chapitre 3 que l'amplitude des opérations de communication sur le
bus était de 3 ilS mesurés sur le Mf. Nous avons également effectué sur les ST la
mesure du temps de transfert d'un octet (unité de base de tout transfert sur le bus) du
transputer du MT vers les ST. Pour cela, le flag MSDF étant mis à 1 par le Mf, nous
avons mesuré le temps entre la mise à 0 du flag MSDF par le ST et son retour à 1 quand
l'octet a été transféré par le MT, et nous avons pris la moitié de ce temps comme
estimateur du temps de transfert MT~ST. Ce choix est justifié par le fait les temps des
opérations de base sur le bus sont à peu près égaux; il s'agit dans le cas présent, de la
84.
Chapitre 4.

---

lecture du flag MSDF et du transfert MS avec mise à 1 du dit flag. La distribution des
valeurs observées est représentée sur la figure 1. Le minimum observé est 8 ~s, le
maximum 14 Il, et la moyenne Il ~. Ce qui nous donne une erreur de lecture maximale
de:
•
Emu =6~ .
(1)
1000 '"T"'""----------------------,
900
800
700
600
500
400
300
200
100
Time Ils
O..._-Gl-_-lit"".:;=::;:........-""T"-.......""T"-~IICiI_...,... ......,..._G_.............,...~
7
8
9
10
Il
12
13
14
15
16
17
-Figure 1-
Distribution des temps de transfert Mf-+ST d'un octet sur le bus.
ll.2. Mesure de la dérive des horloges.
Nous avons utilisé le MT comme horloge de référence, et nous avons cherché à
déterminer la dérive des horloges des ST par rapport au MT. Nous avons procédé de la
façon suivante. Le MT met à 1 le flag MSDF et attend. Pour demander l'heure du MT,
le ST lit sa propre heure Tl, met le flag MSDF à 0 et se met en attente. Quand le MT -
constate que MDSF est à 0, il lit son horloge T et envoie au ST les quatre octets
correspondants l'un après l'autre. Quand le ST reçoit le premier octet, il lit à nouveau
l'heure TI; puis reçoit les 3 octets suivants (fig. 2).
Cootroller
Suivant la formule (RI, chapitre 3), la dérive du ST par rapport au MT est donnée par :
•
1'2 = (1 + p)t; où t est l'heure indiquée par l'horloge Mf quand ST reçoit le premier octet.
(2)
Comme. le ST ne connait pas t, il l'estime avec T et le temps qui s'écoule entre
l'émission par le MT et la réception par le ST du premier octet. Suivant [42] (voir
chapitre 2 §m.3), ce temps peut être estimé par H tel que:
85.
Chapitre 4.

---

•
A
_
T2 - Tl
H =T + il, et
L.l
-
2
(3)
En estimant t par H, le ST commet une erreur Ed'au maximum de 6 ilS conformément
au théorème 5 du chapitre 2. Suivant (1) et en supposant que l'horloge du ST est
initialement synchronisée avec celle du MT, on a:
TI-H
T2-t±E
•
p •
(4)
=
H
t± E
Dans la formule (4), plus le terme TI - H est grand, plus l'effet de l'erreur Eest faible
dans l'estimation de p. Autrement dit :
T2-H
•
Lim ~ = p.
(5)
H-++oo
Nous avons donc pris une mesure toutes les 20 minutes pendant deux heures, et, avec
les valeurs (H, TI - H) que nous avons obtenues, nous avons calculé la fonction
générale de la dérive en tenant compte de l'écart initial entre les horloges du MT et des
ST. Nous avons obtenu un coefficient maximum de :
•
p = 1,61~.
(6)
n.3. Analyse des possibilités d'utilisation des algorithmes existants.
Pour estimer qu'est-ce qu'il coOterait d'utiliser le bus pour les algorithmes existants,
nous avons étudié la durée minimale de synchronisation des horloges en terme de temps
de communication sur le bus. C'est à dire la durée de la diffusion d'un ST vers tous et
du MT vers tous les ST, ainsi que la communication du MT vers un ST, 'ou d'un ST vers
un autre. Nous avons utilisé les mesures du èhapitre 3 pour effectuer ces estimations
(tableau 1).
communication 1 -+ N.
Temps de transmission de 4 octets
Diffusion ST -+ 32 ST
1192 Ils
Diffusion Mf -+ 32 ST
360 J,IS
Envoi Mf -+ 1 ST
125 US
Envoi ST -+ 1 ST
805 US
-Table 1-
Temps de transmission de 4 octets sur le bus.
TI ressort du tableau 1 que si chaque ST diffuse un message à tous, la synchronisation
des 32 ST prendrait au environ 33 112 IlS. Alors que si le MT diffuse son heure à tous,
la synchronisation durerait 360 ilS. De même, si chaque processeur lit l'heure du MT
suivant l'algorithme probabiliste par exemple, il lui coOterait environ 125 ilS par
tentative.
86.
Chapitre 4.

---

En considérant ces chiffres, on peut écarter les algorithmes utilisant la diffusion de
chacun des ST vers tous à cause du temps trop élevé. TI reste donc trois choix possibles
: la fonction de Jézéquel, la diffusion de l'heure du MT (c'est l'algorithme de [118]
simplifié comme nous l'avons suggéré au chapitre 2), et l'algorithme probabiliste [42].
•
Avec l'algorithme de Jézéquel, le temps initial serait au minimum de 798560 I.1s
(c'est à dire 32x3lx805 I.1s) si chaque transputer doit lire au moins une fois l'heure de
.tous les autres. Or la fonction géométrique d'estimation des dérives nécessite bien plus
de messages.
•
Suivant la formule (1) donnée plus haut et la relation (R6) du chapitre 2,
l'algorithme de [118] simplifié que nous avons proposé (chapitre 2, §ID.2.2) aura une
précision minimum égale à l'erreur de lecture entre le MT et chaque ST, soit 61.1S. Mais
son gros défaut est qu'il nécessite que tous les ST soient prêts à recevoir l'heure
diffusée par le MT. Cela conduira à immobiliser le bus pendant un temps variable
compte tenu de la lenteur éventuelle de certains ST.
•
Enfin, l'algorithme probabiliste donnerait une meilleure précision. Mais
malheureusement, conformément à la figure l, les temps sont concentrés autour de la
moyenne. il faudrait donc au moins choisir la moyenne comme borne supérieure du
temps de transfert du premier octet si l'on espère atteindre la synchronisation en une
seule lecture de l'heure du MT avec une probabilité supérieure à 0,47 (conformément à -
nos mesures). En choisissant la moyenne (11 I.1s) comme maximum, et 7 I.1S comme
minimum, on obtiendrait une erreur maximale de 4 I.1s, c'est à dire une précision
minimale de 4 1.1S.
Nous avons donc étudié un nouvel algorithme probabiliste conservant l'avantage de
donner une bonne précision, mais cette fois avec une grande probabilité d'atteindre la
synchronisation en une seule lecture.
III. Algorithme statistique et probabiliste.
nI.!. Présentation.
m.l.l. Limites de l'aliorithme probabiliste.
L'algorithme de Cristian [42] (voir éventuellement le chapitre 2, section ill.3) comporte
trois défauts principaux:
87.
Chapitre 4.

---

•
il nécessite la connaissance de la loi de probabilité des temps de communication.
Or la distribution
de cette loi est inconnue la plupart du temps et elle varie en
corrélation avec la charge du système.
•
Pour avoir une grande probabilité de synchroniser les horloges, il faut que la
distribution des temps de communication soit concentrée près du minimum. Ce qui veut
dire que cet algorithme n'est pas adapté aux systèmes ayant une loi de probabilité
normale ou asymptotiquement normale.
•
Cet algorithme ne s'adapte pas à la charge du système. En effet, quand cette
charge augmente, les temps de communication peuvent aussi augmenter. Cela a pour
conséquence de réduire la probabilité de synchroniser les horloges.
m.1.2. Description informelle de notre solution.
Pour résoudre ces trois problèmes, nous proposons d'utiliser les statistiques des temps
de communication. Au lieu de borner par deux constantes (min et max) l'intervalle des
temps (valeurs) de communication acceptables, nous proposons de centrer cet intervalle
sur la moyenne arithmétique des temps de communication. D'autre part, à défaut de
connaître la loi de distribution des temps de communication, nous proposons d'utiliser
le théorème de Bienaimé-Chébychev pour estimer une borne inférieure de la probabilité
de synchroniser les horloges, et la loi de Bernoulli pour estimer une borne supérieure du
nombre moyen de tentatives de lecture d'une horloge. Mais plus que cela, la statistique
des temps de communication possède des propriétés intéressantes qui peuvent être
exploitées pour la sy'nchronisation des horloges:
•
La moyenne des temps de communication s'adapte à la charge du système en ce
sens qu'elle croît ou décroît avec la valeur des temps de communication en corrélation
avec la charge du système. Or cette moyenne est un estimateur efficace et non-biaisé de
la moyenne arithmétique des temps de communication [117].
•
Si la loi de probabilité des temps de communication est normale ou
asymptotiquement normale, alors ces temps sont concentrés autour de la moyenne. Ce
qui revient à dire que la probabilité de synchroniser les horloges est plus élevée si
l'intervalle des valeurs acceptables est centré sur la moyenne arithmétique des temps de
communication, que borné par min et max.
•
Etant donné que la connaissance de la distribution des temps de communication
permet de mieux choisir la taille de l'intervalle des valeurs acceptables, on peut faire des
hypothèses sur cette loi et les valider pendant l'exécution grâce aux statistiques des
temps de communication.
88,
Chapitre 4.

---

111.2. Description formelle de la solution.
L'algorithme de base est le même que celui de Cristian [42], dont un résumé est donné
au chapitre 2, section III.3. Dans cette partie, nous ne décrivons que les aspects
spécifiques à notre version et les changements que nous avons apportés en utilisant les
statistiques des temps de communication. Nous redéfinissons l'intervalle des valeurs
acceptables relativement à la moyenne arithmétique des temps de communication; c'est
à dire la plage des temps de communication qui peuvent être utilisés pour estimer
l'heure d'une horloge. Nous donnons une nouvelle expression de l'intervalle de
synchronisation des horloges équivalente au théorème 5 du chapitre 2. Nous donnons
également les expressions de l'estimateur de la moyenne arithmétique, de l'écart type,
de la probabilité d'atteindre la synchronisation, en du nombre moyen des essais de
lecture d'une horloge. Nous prouvons que l'horloge que nous proposons s'adapte à la
variation de charge. Et enfin, nous établissons un critère de comparaison avec
l'algorithme de Cristian.
Cette partie fait référence aux propriétés (Pi) et aux relations (Ri) du chapitre 2.
m.2.1. Intervalle de lecture d'une horl0ie relativement à la moyenne arithmétiqye.
Soit P un processeur qui veut lire l'heure d'un autre processeur Q. Soit T la date que Q
envoie à P en réponse à la demande de ce dernier. Soit .1 la moitié du temps qui s'écoule
entre ~ moment où P envoie sa demande à Q et le moment où il reçoit la réponse; et
soit .1
la moyenne arithmétique des temps .1 (voir éventuellement le chapitre 2,
section ill.3).
Théorème 1. Si les processeurs P et Q ont de bonnes horloges, et s'il existe un réel E~ 0
tel que 1.1 - .1 1~ E, alors au moment où P reçoit la réponse de Q, l'heure CQ(t)
indiquée par l'horloge de ce dernier est dans l'intervalle:
•
~(t) E [T + (1 -2p)(~ - 2E), T + 2(1 + 2p).1- (~- 2E)].
Preuve.
Soient P et Q deux horloges comme nous les avons définies plus haut. Soit
2d ~ 0 le temps réel qui s'écoule entre le moment où P envoie sa demande à Q et le
moment où il reçoit la réponse de ce dernier. Soit 2 d ~ 0 la moyenne arithmétique des
-
-
temps de communication. Soient d + a et d + ~ les temps réels mis respectivement par
la demande de P pour parvenir à Q et par la réponse de Q pour arriver à P. Par
défiIÙtion :
2d =2 d + a + ~;
(1)
TI existe un réel a~ 0, tel que: a~ Id.- d 1
(H)
89.
Chapitre 4.

---

Par défmition de a et ~ on a :
(H), (1) ~ 2a ~ lai et 2a ~ 1~1.
(2)
(1, 2) ~ 2d - 2d + 2a ~~.
(3)
Comme P et Q sont de bonnes horloge~
(P3)
~
CQ(t) €
[T + (1- p)( d + ~), T + (1+ p)( d + ~)].
(4)
(2,3, 4) ~ ~(t) € [T+ (1- p)(d -2a), T + (1+ p)(d + 2d -2d + 2a)].
(5)
(5) ~
CQ(t) €
[T + (1- p)(d -2a), T + (1+ p)(2d - (d - 2a))].
(6)
Comme l'horloge avec laquelle P mesure d, d et a dérive au maximum à une vitesse p
du temps réel, il s'en suit de la propriété (P3) que :
si: ~ =(1 - p)d, alors: (1 - p)~ :5: ~ =(1 - p)d :5:d:5: (1+ p)~;
De même si : ~ =(1 + p)d, alors: (1 - p)~ :5: d:5: ~ =(1 + p)d:5: (1+ p).
On a donc en raisonnant de la même façon pour ~,
-
-
(1 - p)~:5:d:5: (1+ p)~; (1 - p) ~ :5: d :5: (1 + p) ~ ; 3y~o:a:5:(1+p)y.
(7)
-
-
-
(7) ~
(1-p)I~- ~ 1:5: Id- d 1:5: (1 +p)I~- ~ 1
(8)
(H), (8) ~
(1 - p)l~ - ~ 1:5: a.
(9)
(7), (9) ~
(1 - p)l~ - ~ 1:5: (1 + p) y.
(10)
(R2), (10) ~
I~- ~1:5:(1+2p)y.
(11)
Dans l'intervalle (6), en remplaçant les valeurs temps réels par les ·valeurs mesurées par
P, le nouvel intervalle ainsi obtenu doit contenir l'intervalle (6). La substitution doit
donc déplacer la borne inférieure vers la gauche et la borne supérieure vers la droite.
Pour cela, il faut minorer d
et majorer a dans la partie gauche de l'intervalle; et il faut
majorer d et a et minorer d
dans la partie droite. Cela revient en appliquant la formule
(7), à remplacer d
et a respectivement par (1 - p) ~ et (1 + p) y dans la partie
gauche; et à remplacer d, d
et a respectivement par (1 + p)~, (1 - p)~ et (1 + p) y.
Ce qui nous donne:
(R2), (6, 7) ~ ~(t) E [T + (1 -2p) ~ - 2y, T + 2(1 + 2p)(~ + y) - ~].
(12)
Posons E = (1 + 2p) y. En remplaçant y dans les formules (11-12), nous obtenons:
(R2), (11) ~
I~ - ~ 1:5: E.
(13)
(R2), (12) ~
CQ(t) E [T + (1 -2p)( ~ - 2E), T + 2(1 + 2p)~ - ( ~ - 2EH.
(14)
Cqfd.
Ce théorème signifie que P peut déterminer un intervalle contenant l'heure de Q étant
donnés le temps de communication, la moyenne des temps de communication, et un
écart maximum E entre ces deux valeurs. Conformément à l'argumentation de Cristian,
90.
Chapitre 4.

---

P ne sait pas faire la différence entre (a = 0, 2d = 2:i + ~) et (~= 0, 2d = 2 d + a).
Par conséquent, l'intervalle (14) est le plus petit intervalle que P puisse calculer étant
donné T, ~, ~ et E.
Comme P ne connait pas la position de l'heure CQ(t) affichée par l'horloge de Q dans
l'intervalle (14), il minimise l'erreur qu'il commet en estimant CQ(t) s'il choisit le centre
de cet intervalle comme estimateur G; de CQ(t) :
~ (T, ~, E) =T + (1 + 2p)~ - p(~ - 2E).
(15)
Avec cette estimation, l'erreur maximum que P peut commettre est la moitié de cet
intervalle :
e = (1 + 2p)~ - (1 - p)( ~ - 2E).
(16)
Ce la signifie que si Q est un processeur maitre et P un processeur esclave, en
positionnant son horloge à C ~ (T, ~, E), P aura un écart maximum de e avec l'horloge de
Q. Par conséquent, la précision minimale de l'horloge globale ainsi constituée est e.
m.2.2. Estimation de la moyenne arithmétique et de l'écart type.
Un estimateur efficace et non biaisé de la moyenne arithmétique d'une population est
la moyenne des échantillons extraits de cette population [117]. Par conséquent, nous
pouvons choisir la moyenne ~D des temps Ôu mesurés par P à chaque tentative de
lecture de l'heure de Q comme estimateur de ~ . A la nième tentative, cette moyenne est:
•
~:::: A = 1 ~D~. = n-1 A +1 A
'-"D
n
J
n '-"D-}
n '-"D'
(17)
J
Chaque fois que P fait une tentative de lecture de l'heure de Q, il mesure le temps 2Ôu
mis entre la demande de lecture et la réception de la réponse et il calcule la contribution
de cette communication à la moyenne.
L'écart type a des temps de communication peut être estimé par l'une des deux
formules suivantes [117] :
1 D
-
•
a2 :::: 82 = ÏÏ ~ (~j - ~ )2;
estimateur efficace et biaisé.
(18)
•
estimateur non-efficace et non biaisé
(19)
m.2.3. Estimation de la borne inférieure de la probabilité de synchronisation.
La constante E dans la formule (13) qui défmit la taille 2E de l'intervalle des valeurs
acceptables, est fixée compte tenu de la précision recherchée, par exemple en
91.
Chapitre 4.

---

appliquant la formule (R5) du chapitre 2. Cependant une bonne connaissance de la
distribution des temps de communication ~ permet de faire un meilleur choix de E.
Comme la distribution des temps de communication ~ est inconnue la plupart du
temps, on ne connait par conséquent pas la probabilité de synchronisation des horloges.
A défaut de la connaître, E étant fIxé et connaissant l'écart type 0 de ces temps, une
borne inférieure de cette probabilité peut être déduite du théorème de Bienaimé-
Chebychev, qui dit que:
-
0 2
•
Proba(l~D - ~ 1~ E) S 2'
(20)
E
2
0
•
(20) => Proba( I~ - ~ 1S E) ~ 1-"2 =p.
(21)
E
L'expression
(20)
donne la borne inférieure de la probabilité d'atteindre la
synchronisation. L'écart type 0 peut être estimé par la formule (19). Cela veut dire
qu'étant donné un écart maximal entre la valeur mesurée et la moyenne des temps de
communication, P peut estimer la probabilité d'atteindre la synchronisation à la
prochaine tentative de lecture de l'heure de Q. Plus cet écart E est grand, plus grande est
la probabilité d'atteindre la synchronisation.
Ill,2.4. Estimation du nombre moyen de tentatives de synchronisation.
Suivant la loi de Bernoulli, si p est la probabilité d'atteindre la synchronisation, alors le
nombre moyen de tentatives est:
1
•
fi. = -
(22)
p'
•
(21) => p ~p.
(23)
1
•
(22, 23) =>
fi. S p'
(24)
La formule (24) signifIe que connaissant l'intervalle des· valeurs acceptables et la
statistique des temps de communication, P peut calculer une borne supérieure du
nombre moyen de tentatives pour atteindre la synchronisation à la prochaine période de
synchronisation.
m.2.5. Adaptation à la charae du réseau.
Théorème 2. Soient P et Q deux processeurs ayant de bonnes horloges. En utilisant la
moyenne des temps de communication pour déterminer l'intervalle de lecture de
l'horloge de Q, P adapte la synchronisation à la variation de la charge du réseau.
Preuve. La charge du réseau se reflète sur les temps de communication. Pour prouver
notre théorème, il nous faut donc montrer que la moyenne ~ de ces temps s'adapte à
la variation des temps de communication. Comme nous estimons cette moyenne avec la
formule (17), il nous faut prouver que, si ~ est le temps de communication mesuré par
92.
Chapitre 4.

---

P à la nième lecture de l'heure de Q;
~n-l la moyenne des temps de communication à
la n-1ième lecture; et ~D la moyenne à la nième lecture:
(i)
Si ~D ~ ~-l alors ~D ~ ~-l
- -
- - - -
(ii)
Si ~D ~ ~-l alors ~D ~ ~.l
La démonstration de (i) est la suivante. Supposons que ~ ~ ~D-l'
(01)
Soit n > 0, la nième tentative de lecture de l'heure de Q par P,
1
1 -
•
(Dl) ~ n~D ~ n ~.l
(02)
1
n - 1 -
1 -
n - 1 -
•
(D2)~ n~+ I l ~-l ~ n ~D-l + I l ~.l'
(02)
-
- -
•
(03), (17) ~
~ ~ ~.l.
La démonstration pour (ii) se fait de la même façon au symbole de l'inégalité près.
Ce théorème signifie que dans la formule (17), si ~ ~ ~D ,alors ~ augmente avec la
-
-
contribution de ~D; sinon, .& décroît. C'est à dire que ~ se déplace à gauche pour les
petites valeurs de ~ (temps de communication mesuré par P), et à droite pour de
grandes valeurs. Comme ~ est lié à la charge du réseau, les formules (15) et (17)
signifient donc que P adapte la synchronisation à la variation de cette charge. Comme
ces formules sont la base de l'horloge globale que nous proposons, celle-ci s'adapte
donc à la variation de charge du réseau.
Cqfd.
m.2.6. Simplifications.
Le fait que p soit très petit (1,6 1()-6) et que ~, ~ , et € soient de l'ordre de la dizaine de
micro-seconds, fait que les termes p~, p~, et p€ soient négligeables. Nous pouvons
donc simplifier les formules (14-16) :
CQ(t) E [T + ~ - 2€, T + 2(~ + €) - ~].
(14')
~ (T, ~, €) =T +.&.
(15')
e = ~ - ~ + 2€.
(16')
(H), (16') ~
€ ~ e ~ 3€.
(25)
m.2.7. Critère de comparaison.
La formule (25) donne les bornes de l'erreur que P peut commettre en estimant l'heure
de Q. Cette expression nous permet d'établir un critère de comparaison entre notre
algorithme et celui de Cristian. Soient Min et Max, le minimum et le maximum des
temps utilisés pour définir l'intervalle des valeurs acceptables dans [42]. De la formule
93.
Chapitre 4.

---

(25) ci-dessus et des formules (6'_8') de [42], il suit qu'à probabilité égale, notre
algorithme est meilleur que celui de Cristian si
•
(Max - Min) ~ 3e:.
(26)
IV. Etude expérimentale sur le SuperNode.
Notre algorithme a été implémenté sur le SuperNode et intégré au système de mise au
point CDS pour la datation des événements (chapitre 6) et les points d'arrêt globaux
(chapitre 5). Cette section décrit l'algorithme tel qu'il a été implémenté et analyse les
performances observées. Nous avons également implémenté l'algorithme de Cristian
pour établir des comparaisons.
IV.I. Implémentation.
Nous avons utilisé le protocole maitre-esclave auquel se prête le bus de contrôle:
chaque transputer de travail (esclave) se synchronise avec le transputer de contrôle
(maître) en lisant l'heure de celui-ci de la façon suivante:
•
Le contrôleur: il scrute régulièrement le bus. Quand il détecte une demande de
synchronisation d'horloge (réception d'un octet spécial d'un ST quelconque), il envoie
une interruption à ce ST, et il attend que le ST lui réponde en mettant le fIag MSDF à
0, ce qui signifie qu'il est près à recevoir l'heure et à chro~ométrer le temps de
communication. Le MT lit alors son heure T et envoie les quatre octets correspondants
au ST en question.
•
Le transputer de travail: quand un ST veut lire l'heure du MT, il envoie une
demande (un octet spécial) au contrôleur. Dès qu'il a reçu une interruption en réponse
du MT (demande accordée), il lit sa propre heure Tl (démarrage du chronomètre), met
le fIag MSDF à 0 et se met en attente du premier octet. Dès qu'il le reçoit, il lit à
nouveau son heure T2 (temps intermédiaire), ainsi que lorsqu'il reçoit le quatrième octet
T3 (fm du chronométrage). Ensuite il estime l'heure du MT au moment de la réception
du quatrième octet. Comme on peut le voir sur la figure 3 qui résume ce protocole, le
ST n'a besoin d'estimer que le temps de communication pour le premier octet, car le
temps total de transfert est égal au temps inconnu de transfert du premier octet, plus le
temps de transfert des trois autres octets (égal à T3 - TI). Le ST applique alors la
formule (14') pour estimer l'heure du MT à la date de réception du quatrième octet:
w
T2 - Tl
Cc (t) =T + T3 - TI +
2
.
(27)
Le terme 1'2;Tl =!!,. correspond à l'estimation du temps de transfert du premier octet.
Le ST l'utilise pour calculer!!" et cr selon les formules formules (17) et (19). Si le ST
94.
CbapilJ'e 4.

---

obtient un temps de communication I~ --X 1:s; E, alors il a atteint la synchronisation. n
met son horloge la valeur calculée à l'aide de la formule (27). Sinon, il fait une nouvelle
tentative de lecture de l'heure du MT.
En modifiant ainsi son heure, le ST peut reculer son horloge si T3 - ~ (t) > O. Dans ce
cas, pour éviter qu'aucun processus ne soit activé pendant le temps de recouvrement qui
en résulte, le ST exécute une boucle de haute priorité pendant le temps TI - C~ (t).
... yte4
Oock read time
T3
-Figure 3-
Prococol of a lock reading attempt.
La procédure que nous venons de décrire dure 120 Ils pour une tentative. On remarquera
que ce temps est comparable à l'estimation que nous en avons faite (tableau 1). Le ST
reçoit le premier octet en mode scrutation, et les trois derniers, en mode interruption. Ce
détail est important en ce sens que la synchronisation ·ne monopolise le processeur que
pendant la réception du premier octet, soit au maximum: T2 - Tl :s; 30 J.l.S. La dérive
pendant la réception des trois derniers octets étant négligeable, l'algorithme peut donc
largement déborder les 120 IlS, sans cependant coOter plus cher en temps d'exécution, ni
dégrader la précision de synchronisation avec le terme TI - TI.
Pour implémenter l'algorithme de Cristian, nous avons simplement modifié le test
d'acceptation des messages, c'est à dire remplacer I~ - ~ 1 :s; E par ~ - Min s: e
conformément au critère de comparaison que nous avons défini §ill.2.7.
IV.2. Mesure et analyse des performances.
Nous avons d'abord étudié le comportement de l'algorithme sur un ensemble de tests
préliminaires pour déterminer la période de synchronisation et la taille de l'intervalle de
lecture de l'heure. Durant ces tests, nous avons appliqué notre algorithme pour voir
comment il se comportait, c'est à dire si à chaque test il atteindrait la synchronisation, et
nous avons fait autant avec l'algorithme de Cristian. Ensuite, après avoir fixé toutes les
constantes de synchronisation, nous avons à nouveau fait des tests en temps réel pour la
durée de la période que nous nous sommes fixée.
95.
Cbapitn: 4.

---

IV.2.1. Tests et mesures préliminaires.
La figure 1 donne la distribution de ~ telle que nous l'avons observée pour 1000 tests
successifs, répétés une dizaine de fois. Le tableau 2 donne les statistiques de cette
distribution. Comme le minimum observé est 8 ~s, nous avons pris 7 ~s comme
minimum théorique pour appliquer le test de sélection de Cristian (Min =7 ~s). Ce
choix étant fait, nous avons réalisé les comparaisons données par le tableau 3.
minimum
maximum
mean
standard
Proba(l~ - ~ 1~ 1) Proba(l~ - ~ 1~ 2)
-
deviation CJ
~
Observed value
8us
14 US
11 US
0.118
0.995
0.999
-Table 2 -
Statistic of the half round trip delay.
Pour E =1 ~s, ce qui suivant la formule (25) donne: e
=3 J.1S, avec notre algorithme,
max
nous avons obtenu une probabilité de 0,996 d'atteindre la synchronisation en une
tentative, alors que celui de Cristian donne une probabilité de 0,004. Pour E =2 ~s, ce
qui donne e
=6 ~s, avec notre algorithme, nous avons obtenu une probabilité de
max
0,999 d'atteindre la synchronisation en une tentative, et exactement la même probabilité
avec l'algorithme de Cristian. Pour des valeurs supérieures de E> 2 ~s, nous n'avons
obtenu aucun changement si ce n'est l'augmentation de l'erreur e. D'autre part, le tableau
2 montre que la valeur p calculée en appliquant la formule (21) est très proche de la
valeur de p observée. Dans ce cas p est un bon estimateur de p..
Reading error E
Max error e
Cristian scheme
Statistical scheme
Lower bound p
lUS
3 US
0.004
0.9956
0.985
2 US
6us
0.999
0.999
0.996
..
-Table 3-
Probabillty to reach rapport.
Nous avons donc fixé E = 1 ~s. Et nous avons déterminé l'intervalle de synchronisation
de la façon suivante.
•
Comme une tentative dure normalement 120 ~s, et que la synchronisation est
atteinte au bout de la première tentative, il faut donc 3840 ~s au contrôleur pour
synchroniser les horloges des 32 ST. Mais par mesure de sécurité, nous avons choisi un
nombre maximum de trois essais avant que le ST n'abandonne la synchronisation
concluant à une erreur du bus. Cela nous donne un total de 11520 ~s pour synchroniser
les 32 ST. En fixant à 3 J.1S l'écart maximum du à la dérive entre le MT et le ST, et avec
une dérive maximum 1,6xl0-6 nous avons une période maximum de 2 secondes.
Chaque ST doit donc commencer la première tentative de lecture de synchronisation au
plus tard 1988480 ~s après la dernière synchronisation. Avec ces choix, nous avons un
96.
Chapitre 4.

---

écart minimum de 1 ~s entre le MT et le ST juste après la synchronisation, et un écart
maximum de 6 ~s au terme des deux secondes de période.
Notre implémentation assure un écart· minimal de 2 ~s et maximal de 12 ~s entre les
horloges des transputers de travail.
IV.2.2. Tests en temps réel.
Nous avons utilisé un processus rimer, qui au bout d'une période d'une seconde envoie
un message au moniteur du bus (chap. 3) pour lui signifier qu'il est l'heure de se
synchroniser. Le moniteur exécute alors la fonction de synchronisation jusqu'à ce qui
atteigne la synchronisation. Ensuite, il re-active le rimer. De son côté, le transputer
scrute normalement le bus en attente de requêtes de lecture d'heure. Dès qu'il en perçoit
une, il exécute la fonction de lecture et de communication de l'heure. Ces fonctions sont
données dans l'annexe 3. Les valeurs que nous avons observées lors de l'utilisation de
cet algorithme sont données par l'annexe 4. L'algorithme s'est comporté comme nous
l'attendions. C'est à dire que la synchronisation s'est faite à la première demande. Par
contre, nous avons observé que:
•
La moyenne des temps de communication s'est portée sur 9 ~s, que l'algorithme
a bien suivi.
•
L'ecart entre l'horloge du transputer de contrôle et celle du transputer de travail
avait une à deux micro-secondes de plus que les temps attendus. Ce surplus de temps
résulte de trois facteurs : les instructions de lecture et de calcul de l'heure; l'horloge de
chaque transputer a une précision d'une seconde; les arrondies dans le calcul de
différents termes.
En conclusion, nous pouvons dire que l'algorithme est efficace. TI faudrait dans une
utilisation effective, porter l'intervalle de lecture à un rayon de 2 ~s pour mieux
répondre aux variations du temps de communication. Et pour minimiser l'écart entre le
transputer de contrôle et les transputers de travail, il faut réduire la durée de
synchronisation à moins de deux secondes. C'est ce qui est fait dans l'horloge de CDS
(chapitre 6).
v. Extensions et adaptations.
V.l. Une meilleure adaptation à la charge du système.
Les formules (17-19) indiquent que quand n est très grand, les variations de ~
deviennent négligeables. Cela signifie que l'on perd l'adaptation à la charge du système.
97.
Cbopitre 4.

---

Nous suggérons pour répondre à ce problème de ne prendre en compte dans le calcul de
li. et (} que les M dernières valeurs li. mesurées. M doit être choisi assez petit pour une
adaptation rapide, et grand pour une adaptation plus lente. Selon Spiegel [117], 30 est
une bonne limite entre les petites et les grandes valeurs de M.
V.2. Une meilleure estimation de la dérive.
Nous avons résumé dans le chapitre 2 §ill.3 un algorithme proposé par Cristian [42]
pour estimer la dérive des horloges pendant l'exécution. Cet algorithme converge vers la
dérive réelle. Cependant la vitesse de convergence n'est pas connue. Nous suggérons de .
prendre la moyenne des dérives calculées à chaque synchronisation comme estimateur
de la dérive réelle. Nous bénéficions alors d'une double convergence. Une convergence
due à l'algorithme initial, et une seconde due à l'utilisation de la moyenne. Comme les
valeurs mesurées sont très petites (de l'ordre de 10-6), vers la trentième itération, la
contribution à la moyenne des termes mesurés devient très faible.
V.3. Test d'hypothèses.
Une meilleure connaissance de la distribution des temps de communication permet de
mieux estimer la taille de l'intervalle des valeurs acceptables et la probabilité d'atteindre
la synchronisation. Des tests d'hypothèses peuvent aider à connaître cette distribution
dynamiquement. Par exemple, si les délais de communication suivent une loi normale,
l!. -
l!.
alors la variable aléatoire centrée et réduite: Z =
suit la loi normale. Cela
(}
signifie entre autres que, sachant que: Z =0, Oz =1 (écart type de Z), on a :
•
Proba(lZ - Z I:S; 1,96) :::: 0,95.
Mais le test le plus simple et peut-être le plus utilisé est celui du X}, qui sert à mettre en
évidence la corrélation éventuelle entre les valeurs observées et les valeurs espérées
pour une distribution donnée. Nous invitons le lecteur intéressé à se rapporter à [23]
[117]. Notre algorithme étant bien adapté la distribution normale et à celles qui y
ressemblent, on peut donc deviner l'intérêt de tels tests.
V.4. Amélioration d'Alari et Ciuffoletti
L'amélioration de l'algorithme probabiliste proposée par Alari et Ciuffoletti [15],
consistant à adapter la précision au temps qui s'est écoulé depuis la dernière
synchronisation, peut également être appliquée à notre version. Tout comme celui de
Cristian, notre algorithme peut aussi être appliqué de la même façon que dans [16] pour
améliorer l'algorithme de Babaoglu et Drummond [21] .
98.
Chapitre 4.

---

Conclusion.
Nous avons analysé les performances du bus de contrôle du SuperNode pour la
synchronisation des horloges, en estimant en particulier la contribution de ce bus en
terme de temps de communication minimal. Nous avons ensuite développé une
nouvelle version de l'algorithme probabiliste en nous appuyant sur les statistiques des
temps de communication. A partir du théorème de Bienairné-Chebychev, nous avons
dérivé une borne inférieure de la probabilité de synchroniser les horloges; et à partir de
la loi de Bernoulli nous avons dérivé une borne supérieure du nombre moyen de
tentatives de lecture d'une horloge. A défaut de connaître la distribution des temps de
communication, ces deux bornes peuvent être utilisées dans notre algorithme pour
synchroniser les horloges. Nous avons ensuite montré que notre algorithme s'adapte à
la variation de la charge du réseau. Nous avons également présenté une implémentation
de notre algorithme sur le SuperNode en utilisant le bus de contrôle comme moyen de
communication. Une implémentation de l'algorithme de Cristian nous a permis d'établir
quelques comparaisons sur l'opportunité d'utiliser le bus avec cet algorithme.
De manière générale, notre version de l'algorithme probabiliste a l'avantage par rapport
à celle de Cristian de s'adapter à la charge du réseau, et de s'appliquer en particulier aux
distributions ayant une tendance normale. Cette version peut être utilisée même si le la
loi de probabilité n'est pas connue, cela grâce aux bornes que nous avons déduites du _
théorème de Bienaimé-Chebychev et de la loi de Bernoulli. Ce qui n'est pas le cas de la
version de Cristian.
On peut retenir de ce travail, qu'il peut être possible d'améliorer les algorithmes
existants en utilisant les statistiques des temps de communication. Un des avantages est
de réduire le nombre de constantes qui limitent la flexibilité de ces algorithmes. Nous
avons vu le cas des bornes min et max avec l'algorithme probabiliste. Une autre
application est une meilleure estimation de la dérive. Dans le cas de notre algorithme
par exemple, cela peut permettre à chaque processeur d'adapter sa période de
synchronisation à sa dérive par rapport au processeur maître, sans perdre la précision de
l'horloge globale.
99.
Chapitre 4.

---

---

Chapitre 5.
Un système de construction de points d'arrêt
globaux pour les programmes parallèles.
1. Introduction.
La mise au point des programmes parallèles nécessite souvent que le programmeur
arrête les processus à des points intéressants [90], pour en collecter des vues, prendre
des décisions sur l'exécution, modifier le contexte d'exécution, ou vérifier des propriétés
stables [29] [86] (103]. L'arrêt d'un seul processus est bien maîtrisé avec l'expérience
des programmes séquenciels. Mais l'arrêt d'un ensemble de processus pose un certain
nombre de problèmes. En effet, la décision d'arrêt peut être prise par
plusieurs
processus, de manière indépendante, à partir de processeurs différents. De plus, il est
souvent nécessaire d'exprimer la condition d'arrêt à partir de conditions locales de
différents processus. En outre, il faut garantir la consistance de l'arrêt. EnfIn, il faut un
choix cohérent de l'action à exécuter pendant l'arrêt des processus.
Un ensemble de travaux ont été menés sur les points d'arrêt globaux pour tenter de
résoudre chacun des problèmes que nous venons de soulever [29] [35] [56] [85] [86]
[87] [90]. Les solutions proposées sont en général coûteuses en terme du nombre et de
la taille des messages générés. Ces solutions utilisent pour la plupart les canaux des
processus pour propager les messages d'arrêt, ce qui induit une forte interférence avec
ces processus. EnflO, un petit nombre de processus peut bloquer la réalisation de l'arrêt
en empêchant la progression des messages. Dans ce chapitre nous proposons un
système de construction de points d'arrêt globaux qui répond à ces problèmes. TI permet
la gestion de prédicats globaux et l'arrêt des processus dans un état consistant. li permet
également de déflOir individuellement les actions à exécuter pour chaque processus
arrêté, ce qui offre une collecte sélective des données et un grand choix des actions
exécutables pendant l'arrêt. Ce système réduit la taille et le nombre des messages
générés à l'aide de trois techniques : représentation binaire des prédicats globaux;
diffusion; partage de la mémoire par les processus d'un même processeur.
Ce chapitre est organisé de la façon suivante. Dans la deuxième partie, nous défmissons
les te.rmes utilisés (point d'arrêt global, état global, prédicat global, consistance). Puis
nous analysons les inconvénients des principaux travaux existants; et nous donnons nos
objectifs et motivations. La troisième partie décrit le système de points d'arrêt. La
quatrième partie donne les performances de ce système pour une implémentation faite
\\01.
C1uIpitre 5.

---

sur le SuperNode dans le cadre du projet C_NET [6] [7] [10]. Nous terminons ce
chapitre en comparant notre système à celui de [56] avec lequel il a deux points
communs : l'utilisation de processus gestionnaires, et la diffusion entre ces
gestionnaires. L'annexe 5 donne les algorithmes de gestion des points d'arrêt globaux.
Il. Les points d'arrêt distribués.
II.t. Définitions.
Un système distribué est constitué d'un ensemble fini de processus s'exécutant sur
plusieurs processeurs, et communicant par des canaux. Un processus est défmi par
l'ensemble de ses états, et les événements qui le font passer d'un état à un autre [35].
L'état d'un processus est caractérisé par son contexte (i.e. variables, canaux, registres).
Un événement est une action atomique qui modifie l'état d'un processus. La notion
d'action atomique dépend du niveau d'observation du processus.
L'état global d'un système est constitué de l'état de chacun des processus qui le
composent [35] [72]. Comme il est pratiquement impossible de l'avoir instantanément,
l'état global d'un système est obtenu en exécutant une procédure d'arrêt des processus,
que nous appelerons point d'arrêt. Un point d'arrêt peut être décomposée en quatre
phases : évaluation de la condition d'arrêt, déroulement de la procédure d'arrêt,
exécution de l'action justifiant l'arrêt, terminaison de l'arrêt.
La condition d'arrêt est en général exprimée sous forme de prédicats. Pour reprendre
les définitions de Miller-Choi [90], un prédicat simple est une condition portant sur les
événements d'un seul processus. Un prédicat composé est
la conjonction, la
disjonction, ou le lien de plusieurs prédicats simples ou composés. Un prédicat lié est
une suite P =PoPl ...Pn de prédicats composés, telle que le prédicat Pi n'est évalué que
si Pi-l est vrai (~). TI sert à exprimer une séquence d'événements. Un prédicat global
est un prédicat composé impliquant plusieurs processus. La procédure d'~êt du
système est déclenché quand un prédicat global est vrai.
II.2. Arrêt consistant.
Garantir la consistance de l'arrêt d'un système est essentiel pour permettre de valider
les propriétés stables d'un système [29] [35] [86] [103]. Cette consistance concerne à la
fois l'état global obtenu, et l'ensemble des événements qui se sont produits jusqu'à l'arrêt
de chaque processus.
102.
Chapitre 5.

---

112.1. Consistance de l'arrêt relativement à l'état i lobal,
Selon Chandy-Lamport, l'état global EL d'un système peut être obtenu en demandant à
chaque processus de collecter son propre état avant de s'arrêter [35]. Un algorithme
permettant la collecte de EL a été proposé par les deux auteurs.
Propriété 1: Selon [90], un arrêt est dit consistant si le système est arrêté dans un état
équivalent à EL.
II.2.2. Consistance de l'arrêt relativement à l'ensemble des événements.
Une exécution peut être caractérisée par l'ensemble E des événements qu'elle a produits.
Cet ensemble peut être partitionné par une coupe, en deux sous-ensembles PASSE et
FUTUR [86]. Une coupe C de E est défInie par son sous-ensemble PASSE par:
•
V e 1i E C, V e2i E E: e2i -7 e 1i ~ e2i E C; où -+ est la relation de précédance ou de
causalité définie dans [72]; événements du processus i.
Une coupe C est dite consistante [86] si :
•
V e E C, V e' E E: e' -7 e ~ e' E C.
Une coupe consistante correspond à une exécution partielle. C'est un sous-ensemble de
E fermé à gauche, appelé aussi sUce dans [29]. Cette défmition signifIe que tous les
événements de E qui se sont produits avant l'arrêt de chaque processus font parti de la
coupe C. Suivant [1], cette défInition revient en particulier à dire qu'à toute réception
de message prise en compte dans la coupe, correspond une émission du dit message
elle aussi prise en compte dans cette coupe.
Propriété 2: Un point d'arrêt est consistant s'il permet d'obtenir une coupe consistante
du système [86]. C'est à dire que l'ensemble des événements qui se sont produits avant
l'arrêt de chaque processus forment une coupe consistante.
II.3. Travaux existants.
Un certain nombre d'algorithmes ont été proposés pour construire des prédicats
globaux, arrêter le système dans un état consistant au sens des propriétés précédentes, et
collecter des observations. L'algorithme de Chandy-Lamport [35] permet de collecter
un état global consistant (propriété 1). Mais il comporte deux principaux défauts. Le
premier est qu'il ne garantit la consistance que pour une seule collecte de l'état global.
Luc Bougé [29] a résolu ce problème en introduisant une numérotation des points
d'arrêt. Le deuxième défaut est que cet algorithme nécessite que le graphe orienté de
communication entre processus soit fortement connexe, et que chaque processus puisse
103.
Chapitre 5.

---

envoyer des messages à tous les autres. Ce problème a été résolu par Miller-Choi en
introduisant un processus spécial relié à chaque processus utilisateur par un canal bi-
directionnel. Mattern a de son côté proposé un algorithme de construction de coupes
consistantes, basé sur le consensus des processus autour d'une date vectorielle d'arrêt
[86]. Tous ces algorithmes sont basés sur la propagation des messages à travers les
canaux des processus utilisateurs. Cela pose quatre principaux problèmes:
• En pratique ces algorithmes sont très coûteux en terme du nombre de messages
générés. En effet, dans le cas de [29] [35] [85], ce nombre est comparable au produit du
nombre de processus par le nombre moyens des canaux d'un processus. Dans le cas de
[86], ce nombre est proportionnel au nombre de processus; mais la taille de la date
vectorielle que porte chaque message est égale au nombre de processus.
• Un petit nombre de processus peut empêcher l'arrêt du système en bloquant la
progression des messages d'arrêt (e.g. interblocage, boucle infmie, fm prématurée).
• Ces algorithmes ne permettent pas de limiter l'arrêt à un groupe de processus (arrêt
sélectif).
• Chaque processus doit avoir au moins un canal de communication; ces algorithmes ne
permettent pas d'arrêter des processus qui ne communiquent pas.
Miller et Choi [90] ont également proposé un algorithme de construction de prédicats
globaux. Il consiste à utiliser un processus gestionnaire central servant à envoyer le
prédicat lié PoPl ...Pn à chaque processus impliqué dans la composante PO. Quand un
processus a validé PO, il le retire de la liste et envoie le reste Pl...~Pn à tous ses voisins.
Si un processus n'est pas impliqué par la tête de liste qu'il a ainsi reçue, il fait suivre
cette liste. Et ainsi de suite. Cet algorithme nécessite une connaissance préalable des
processus impliqués dans la liste des prédicats. Il engendre un nombre de
communications très élevé (comparable au produit du nombre de processus, par le
nombre de canaux de chaque processus, par la longueur du prédicat), en particulier si
les processus impliqués dans un prédicat lié sont très éparpillés.
Haban et Weigel [56] de leur côté ont proposé un système de points d'arrêt utilisant les
horloges vectorielles de Mattern [86] et l'algorithme d'arrêt de Chandy-Lamport [35].
Dans ce système, on suppose que chaque nœud dispose d'un gestionnaire local (GL) et
d'un gestionnaire central (GC). La condition d'arrêt global est décrite sous la forme d'un
arbre binaire de conditions, que le GC distribue à tous les nœuds concernés. Quand un
processus valide une condition locale, il transmet un message au GL qui le diffuse à
tous les autres GL. Chaque GL évalue la condition globale d'arrêt. Si elle est vraie, le
104.
Chapitre 5.

---

GL arrête les processus locaux en utilisant l'algorithme de [35], et diffuse un message
d'arrêt à tous les autres GL. Toutes les messages sont estampillés de l'heure de Mattern
[86] pour permettre de construire la relation de causalité entre les événements [72]. Le
sytème de [56] comporte en plus de problèmes spécifiques, les limitations liées à
l'algorithme de [35] et l'horloge vectorielle de Mattern [86] qu'il utilise. Nous avons
déjà décrit les limitations liées à [35]. L'horloge de Matternest très coûteuse du fait que
chaque message est estampillé d'un vecteur dont la taille minimale est le nombre total
.des processeurs. La communication entre le GL et chaque processus induit des
perturbations supplémentaires en plus de celles occasionnées par la présence du GL.
D'autre part, ce système nécessite une connaissance préalable des processus impliqués
dans la condition globale.
Un autre système de construction de point d'arrêt globaux est décrit dans [85]. Comme
celui de [56], il suppose la présence d'un GL sur chaque processeur. Le GL est supposé
capable de : connaître le type du prochain événement que produira un processus; voir
chaque message émis ou reçu par chaque processus; activer et désactiver tout processus;
observer l'état de chaque processus. Ce système, supposant que l'exécution est
déterministe, est destiné à la reprise d'exécution. Son défaut majeur est la forte
intercation entre les processus utilisateur et le GL.
L'arrêt d'un programme est justifié par l'action que l'on veut réaliser. Dans la plupart des
cas [1.] [35] [90], c'est une action globale: c'est à dire une même action exécutée par ou
pour tous les processus engagés dans le point d'arrêt. Cette action est en général
prédéfinie comme étant la collecte de traces [40]. L'action globale conduit à une
collecte abusive des informations.
II.4. Objectifs et motivations.
Notre premier objectif est de concevoir un système de point d'arrêt générant un nombre
de messages borné et indépendant du nombre des processus utilisateurs. Cela, pour que
le système ait une moindre incidence sur l'exécution des processus utilisateurs par
rapport aux systèmes que nous venons de citer.
Notre deuxième objectif est de permettre un arrêt consistant du système, avec la
possibilité de limiter cet arrêt à une partie seulement des processus. La procédure d'arrêt
doit être telle qu'aucun processus utilisateur ne peut la bloquer autrement qu'en altérant
l'état du système (e.g. viol de l'espace mémoire des processus système).
105.
Chapitre 5.

---

TI.S. Hypothèses sur le modèle de système parallèle.
Pour la suite de ce chapitre, nous faisons les hypothèses suivantes. Le système est
constitué de processus repartis sur plusieurs processeurs et communicant entre eux de
manière synchrone, par envoi de messages à travers des canaux. Une communication se
termine dès que l'un des processus concernés a été remis dans la flle d'ordonnancement.
Les processus s'exécutant sur le même processeur partagent une zone mémoire
commune accessible en exclusion mutuelle. Le système dispose d'un mécanisme
permettant de diffuser un message d'un processeur vers tous les autres; c'est le cas par
exemple sur le SuperNode avec le bus de contrôle (cf. chapitre 3). Le système permet à
un processus de s'inscrire volontairement en fm de me d'ordonnancement.
III. Système d'arrêt sélectif des processus.
TILl. Présentation
Nous avons dit que le fonctionnement d'un point d'arrêt peut se décomposer en quatre
phases : évaluation de la condition d'arrêt, déroulement d'une procédure d'arrêt.
exécution de l'action justifiant l'arrêt, et terminaison de l'arrêt. C'est suivant ce principe
que fonctionne notre système.
•
Construction des prédicats globaux. Les prédicats globaux servent à exprimer
les conditions globales d'arrêt. Dans notre système, un prédicat global est la conjonction
de prédicats de base. Un prédicat global est un mot binaire dont la valeur est prédéfInie
par le programmeur,'et visible à tous les processus. A un prédicat de base est associé un
chiffre binaire dans le prédicat global auquel il intervient; de sorte que, quand ce
prédicat de base est vrai, le chiffre correspondant est positionné à un, et la nouvelle
valeur du prédicat global est diffusée à tous les processeurs. Le prédicat global est vrai
quand chacun de ses prédicats de base est vrai, c'est à dire que chacun de ses chiffres
binaires est positionné à un. Pour spécifier un prédicat global, il suffIt au programmeur
de choisir un nombre dont la représentation binaire comporte autant de chiffres 1 que de
prédicats de base.
•
Procédure d'arrêt. Quand un prédicat global est vrai, un message d'arrêt est
diffusé à tous les processeurs, avec une valeur caractérisant l'arrêt. Ce message est reçu
par un processus gestionnaire sur chaque processeur, qui positionne aussitôt un drapeau
demandant aux autres processus de s'arrêter. A partir de ce moment, chaque processus
qui exécute la fonction d'arrêt conditionnel est suspendu et inscrit dans une liste d'arrêt.
La valeur d'arrêt permet aux processus de choisir à quel point d'arrêt adhérer.
106.
Chapitre 5.

---

•
Action distribuée. A chaque point d'arrêt, tout processus arrêté spécifie une
fonction que le système exécute pour collecter l'état de ce processus: c'est l'action du
processus pour ce point d'arrêt. Cette fonction est passée comme un paramètre de la
fonction d'arrêt conditionnel. L'ensemble des fonctions exécutées lors d'un point d'arrêt
global constitue ce que nous appelons une action distribuée.
•
Terminaison de l'arrêt. L'arrêt global se termine quand le processus qui l'a
déclenché a diffusé un message de terminaison de l'arrêt. Tous les processus suspendus
sont alors réveillés par le système.
Ce système pose un certain nombre de problèmes. En effet, les prédicats globaux
peuvent être évalués simultanément par plusieurs processus sur des processeurs
différents. Cela engendre donc autant de messages à diffuser, et éventuellement autant
de demandes d'arrêt du système. De plus, les points d'arrêt peuvent se chevaucher. En
outre, le système doit permettre au programmeur d'exprimer d'autres types de prédicats.
Enfin, un problème de terminaison de l'arrêt se pose du fait que l'action exécutée n'est
pas la même pour chaque processus arrêté; par conséquent on ne connait pas a priori
quand chaque action se termine. Nous allons montrer dans les sections qui vont suivre
comment le système a été conçu pour répondre à ces problèmes.
m.2. Construction de prédicats globaux.
Les principaux problèmes liés à la construction des prédicats globaux sont la génération
d'une grande quantité de communications, la connaissance des processus impliqués
dans un prédicat, et la représentation non ambigu~ des prédicats. Dans cette section,
nous décrivons les algorithmes de construction de ces prédicats, et évaluons leur
complexité en nombre de messages générés. Puis
nous montrons comment notre
système s'applique à la construction et la spécification d'expressions logiques. Dans la
suite, sauf indication, le terme prédicat désignera un prédicat global.
ill.2.1. Principe de représentation non ambiiUe des prédicats.
Le système que nous proposons repose sur la représentation binaire des prédicats. Un
prédicat de base est un booléen. Un prédicat est un mot binaire tel qu'à chacun de ses
chiffres correspond un prédicat de base. TI est possible de numéroter les prédicats de
sorte que deux prédicats différents aient des numéros différents, et que la représentation
binaire de chaque numéro coïncide avec celle du prédicat associé. Par exemple le
prédicat nO 25 sera représenté par le mot binaire 11001. A chaque position à 1 du
numéro on fait correspondre un prédicat de base. Un prédicat est alors représenté par un
couple (numéro, valeur) de sorte que pour construire le prédicat, il suffit de positionner
107.
Chapitn: 5.

---

les chiffres de sa valeur de façon que celle-ci soit identique à la représentation binaire
du numéro. Cela est illustré par la figure 1 où l'on voit la construction du prédicat nO 21.
Le prédicat est vrai quand sa valeur coïncide avec son numéro; ce qui est le cas sur la
figure 1 après la troisième transition.
~
O101 5ot-",""iœtc(21~) 110101 15oU>..wœtc(21~) 10101 5o,-",""iœte(21,1)
------I...
10101
~
.. r:-:-::7"I------II...~
0
סס
oo
00100
10100
10101
-Figure 1-
Construction d'un prédicat.
Pour représenter les prédicats, il suffit par exemple de prendre une taille de mot
supérieure ou égale à la taille du plus long prédicat. Ainsi, avec des mots de taille 32, on
peut représenter jusqu'à 232-1 prédicats distincts. Comme il n'y a pas de lien implicite
entre les positions de différents prédicats, il y a donc un polymorphisme entre les
prédicats de base et les positions. En d'autres termes, le nombre de prédicats de base
peut être supérieur au nombre de positions.
Dans ce système, un prédicat représente un ensemble donné d'événements (numéro du
prédicat) et mémorise pendant l'exécution ceux des événements qui se sont produits
(valeur du prédicat). Le prédicat est vrai quand la valeur du prédicat coïncide avec celle
du numéro. Construire un prédicat revient à construire son numéro. Pour associer un
prédicat à un ensemble d'événements (prédicats de base), il suffit au programmeur de
choisir un numéro dont la représentation binaire comporte autant de chiffres 1 qu'il y a
d'événements dans l'ensemble. A chaque position à 1 du numéro, .on affecte un
événement de l'ensemble, de sorte que quand cet événement se produit, le chiffre
associé est mis à 1, comme le montre l'exemple ci-dessous:
Exemple: Le prédicat n014 est choisi par le programmeur pour désigner un défaut mémoire occasionné par la
fonction malloc. Chiffre nO 2 : défaut d'un octet; chiffre 3 : défaut d'un entier, chiffre 4: autre défaut. Les séquences
suivantes permettent de construire le Prédicat 14, où la fonction Set..,predicate permet de positionner les chiffres d'un
prédicat:
if (!(pC = (char*) malloc (sizeof (char»»
SecPredicate (14, 2) ;
if (!(pv = (void*) malloc (SIZE»)
SecPredicate (14, 4) ;
if (!(pi = (int*) malloc (sizeof (int»»
Set_Predicate (14, 3) ;
Comme plusieurs processus peuvent produire le même événement, le premier qui
positionne un chiffre, communique la nouvelle valeur du prédicat à tous les autres
processus. Quand tous les chiffres sont positionnés, c'est à dire qu'on a écrit le numéro,
108.
Chapitre 5.

---

le prédicat est valide : une condition globale d'arrêt est atteinte. Avec cette
représentation, l'association entre ensemble d'événements et numéro de prédicat est
implicite: il n'y a pas de spécification de prédicats. D'autre part, un même événement
peut intervenir dans plusieurs prédicatS.
m.2.2. Système de iestion des prédicats.
Le principe du système de gestion des prédicats est le suivant: sur chaque processeur,
les prédicats sont gérés par une structure de données partagée (e.g. arbre équilibré)
accessible en exclusion mutuelle. Un prédicat y est inséré lorsque son numéro est
instancié pour la première fois. Chaque fois qu'un prédicat est modifié, sa valeur est
diffusée à tous les processeurs. Pour tout processeur, un chiffre d'un prédicat n'est
modifié que par le premier processus qui y accède. Chaque processeur dispose d'un
processus spécial (le gestionnaire) chargé de mettre à jour la structure locale avec les
messages diffusés. Les algorithmes sont donnés ci-dessous. Dans ces algorithmes, un
prédicat pe
comporte un numéro: num; un statut: status (état du prédicat sur le
processeur); et une valeur : value (état du prédicat tel qu'il est vu par tous les
processeurs). Le signe t indique que la fonction est interruptible à cet endroit.
• Fonction de positionnement des chiffres d'un prédicat (fig. 2). Si le chiffre de numéro
position du prédicat numéro num est égal à 0, il est mis à l, et la nouvelle valeur du
prédicat est diffusée à tous les gestionnaires. Cette fonction retourne la valeur actuelle
du prédicat. SET et NOT_SET sont des macros pour positionner et tester un chiffre
d'un prédicat; PREDICATE est une constante.
• Fonction pour tester la validité d'un prédicat (fig. 3). Si le prédicat numéro num existe
dans la structure des prédicats, cette fonction retourne 1 si la valeur de ce prédicat
coïncide avec celle du numéro; 0 sinon.
Set_Predicate(int num, int position) {
TesCPredicate (num) {
Prcdicate_eIem .pc ;
Prcdicate_elem .pc ;
pc =Rnd_or_create (num) ;
pc =Find (num) ;
if (Not_SET (pe-+status, position» {
if (pe)
SET (pe......sstatus. position) ;
retum «pe-+value & num) = num);
t
Broadcast (pREDICAlE, num, pc......status) ;
eise
}
retum (0);
retum «pe-+sstatus & num) = num) ;
}
}
-Figure 2- Algorithme de positionnement d'un prédicat.
-Figure 3-
Test d'un prédicat.
• Fonction pour lire la valeur d'un prédicat (fig. 4). Si le prédicat numéro num existe
dans la structure des prédicats. cette fonction retourne sa valeur; 0 sinon.
109.
Chapitre 5.

---

• Processus gestionnaire (fig. 5): pour chaque message diffusé qu'il reçoit, il met à jour
la valeur du prédicat associé, après l'avoir créé s'il n'existe pas. SET_VALUE est une
macro pour positionner la valeur d'un prédicat.
Get]redicate_Value (num) {
Process Predicate-processO {
Predicate_elem *pe ;
pe = Find (num) ;
struct Predicate_elem pe. *pt ;
if (pe)
FOREVER {
retum (pe-+value) ;
t
Receive (pe) ;
else
pt = Find_occreate (pe.num) ;
retum (0);
SET_VALUE (pt-+value. pe.status) .
}
}}
-Figure 4· Lecture de la valeur d'un prédicat.
-Figure 5-
Gestionnaire de prédicats.
RemarQJJe: Comme la diffusion prend un certain temps, la valeur status donne l'état du
prédicat sur le processeur, et la valeur value représente l'état du prédicat tel qu'il est vu
par tous les processeurs. Cette dernière valeur n'est modifiée que par le gestionnaire
pour garantir que tous les processeurs ont la même valeur du prédicat, au temps de la
diffusion près.
rn.2.3. Evaluation.
Ce système n'empêche cependant pas que le même chiffre d'un prédicat soit modifié et
la nouvelle valeur diffusée simultanément par des processus de différents processeurs.
Ce qui fait que le nombre n des messages pour évaluer un prédicat est: kN :s;; n:S;; kN2;
où k est le nombre de chiffres 1 dans le numéro du prédicat; N le nombre de
processeurs; avec l'hypothèse qu'une diffusion est comptée pour un seul message. Si K
est la taille maximale d'un prédicat en nombre de chiffres binaires, on a la borne
suivante: n:S;; KN2. Comparée à la méthode de Miller-Choi [90], notre technique a
l'avantage de ne pas nécessiter la connaissance· a priori des processus impliqués dans un
prédicat, ni la spécification de prédicats. Le codage est simple et nécessite peu de place.
Pour une taille de prédicat de 32 bits, 8 octets seulement sont diffusés pour un message
d'évaluation d'un prédicat (numéro, valeur); c'est à dire deux mots.
m.2.4. Application à la construction des prédicats.
Notre système s'applique directement aux prédicats conjonctifs. Pour former un prédicat
disjonctif il suffit de lui associer numéro qui soit une puissance de 2 (un seul chiffre 1).
Pour construire un prédicat lié, il suffit de choisir n mots, et de construire le i~me
prédicat (i~l) quand le i-hme est vrai. Ce système permet de profiter pleinement des
opérations logiques classiques (et, ou, etc...) et des opérateurs du langage C de
manipulation des booléens pour spécifier et construire des prédicats complexes. Nous
allons illustrer notre propos à l'aide de quelques exemples dans lesquels nous
définissons des prédicats et les manipulons ensuite sous forme d'expressions
booléennes.
110.
Chapitre 5.

---

#define P30
Test_predicate (3D)
/* définition du prédicat 30 */
#defme P5I
Test-predicate (51)
/* défmition du prédicat 51 */
#define P{n)
Test_predicate (n)
/* définition d'un prédicat */
#defme PV{n)
Gecpredicate_value (n)
/* Valeur d'un prédicat
*/
1* n. m et v: variables représentant des prédicats. Les nombres sont des numéros de prédicats "'/
if (P30
&& P51)
action (...) ;
/* conjonction de prédicats */
if (P(23)
&& P{v))
action (...) ;
/*conjonction de prédicats */
if (P{n)
Il
P (57))
action ( ) ;
/* disjonction de prédicats */
if (PV(32) & PV{m))
action ( ) ;
/* Composition de chiffres */
if (PV(267) 1 PV(l21))
action ( ) ;
/* Association de chiffres */
Ces exemples et tous les autres qu'on peut construire dans le même style nous montrent
que notre système permet
de définir
des prédicats de manière très simple (en
particulier en utilisant des macros) et de les manipuler efficacement avec des opérateurs
logiques. On voit en particulier de ces lignes que notre système permet de construire
des protocoles de contrôle de processus.
nI.3. Arrêt consistant des processus.
La procédure d'arrêt décrite dans cette section est basée sur l'arrêt volontaire: un
processus n'est arrêté que s'il a exécuté une fonction d'arrêt conditionnel au moment
adéquat. L'appel à cette fonction doit être inséré au niveau du code source à l'endroit où
le programmeur juge intéressant d'arrêter chaque processus. Le principe de la procédure
d'arrêt est le suivant. Quand un processus valide un prédicat, il diffuse à tous les
processeurs un message d'arrêt des processus. Un processus spécial (le gestionnaire) est
chargé sur chaque processeur de recevoir ce signal et de positionner un indicateur
reconnu par la fonction d'arrêt conditionnel. Tout proce~sus qui exécute cette fonction à
ce moment est alors suspendu. Le problème de ce mécanisme est que plusieurs
processus peuvent déclencher la procédure d'arrêt au même moment. Cela peut poser un
problème de cohérence de l'état du système. Nous allons voir comment y répondre.
Nous présentons les algorithmes de la procédure d'arrêt, avec une estimation de leur
complexité. Puis nous montrons que l'arrêt est consistant au sens des propriétés 1 et 2.
W.3.1. Procédure d'arrêt des processus.
La procédure d'arrêt des processus comporte deux fonctions, l'une pour demander l'arrêt
du système, et l'autre adhérer à l'arrêt; et un processus gestionnaire de point d'arrêt est
associé à chaque processeur. Nous supposons que les algorithmes qui suivent sont
exécutés en mode protégé et ne sont interruptibles qu'aux endroits marqués du signe t,
pour garantir la consistance des données partagées sur chaque processeur. Dans la suite,
nous dirons qu'un point d'arrêt est actif si la procédure d'arrêt est en cours. La procédure
Ill.
Chapitre 5.

---

d'arrêt comporte une structure BP contenant entre autre la liste des processus arrêtés et
un flag d'état du point d'arrêt.
• Fonction de demande d'arrêt des processus (Enable_Breakpoint ): cette fonction
peut être exécutée par n'importe quel processus, n'importe quand. Elle vérifie que le
point d'arrêt n'est pas actif et qu'aucun autre processus n'a démarré la procédure d'arrêt
sur le processeur. Ensuite, elle diffuse un message d'arrêt (comportant le numéro du
point d'arrêt, le numéro du processeur et l'identificateur du processus initiateur), et
attend un message d'acquittement du gestionnaire local indiquant que la demande d'arrêt
ait été reçue.
AO
Enable_Breakpoint (num) {
Al
if (BP.Break_flag == PREE) {
A2
BP.Break_flag,
=BUSY;
A3t
Broadcascbreak_message (num, gecnode_numberO, Get-pidO);
A4t
Receive_signal (BP.Channell) ;
}
}
•
Fonction d'arrêt conditionnel d'un processus (Conditional breakpoint) : elle
est exécutée par tout processus qui veut s'arrêter soit à cause d'une condition interne
(arrêt dit volontaire); soit quand le point d'arrêt est actif. Le processus s'inscrit au point
d'arrêt (B2); et si l'arrêt est volontaire, il se suspend en attendant d'être réveillé quand le
point d'arrêt deviendra actif (B3-4). Ensuite, une action distribuée (B6) est exécutée
(nous la supposons prédéfinie pour l'instant). Le dernier processus à.terminer son action
(B8-9) réveille le gestionnaire (fm de l'action distribuée sur le processeur). Puis, le
processus se suspend pour attendre la fm du 'Point d'arrêt; cela évite en particulier au
même processus de s'arrêter plusieurs fois au même point d'arrêt.
BO
Conditional_breakpoint (code) {
BI
if «BP.Break_flag == ACTIVE) Il (code == NOT_CONDmONAL»
B2
Registerjor_breakpoint (code, Time (» ;
B3
if «code == NOT_CONDmONAL) &&
(BP.Break_flag '* ACTIVE»
B4t
Stop (1, BP.List) ;
B5
BP.Ctr++;
B6t
Do_distributed_action 0
B7
BP.Ctr-- ;
B8
if «BP.Ctr == 0) && (BP.Break_flag == END»
B9t
Send (BP.ChanneI2, SIGNAL) ;
B lOt
Stop (2, BP.List) ;
}
• Processus gestionnaire des points d'arrêt. Ce processus (un par processeur) attend
le message diffusé pour l'arrêt (Cl; A3), positionne le flag d'arrêt, et éventuellement
réveille le processus qui a demandé l'arrêt du système (C4-6; A4). Ensuite, il réveille les
processus arrêtés volontairement (C7; B3-4). Puis il attend le message de fin de l'arrêt;
112.
Chapitre 5.

---

interdit tout nouvel arrêt conditionnel de processus (CIO); et éventuellement attend que
le dernier processus inscrit au point d'arrêt termine son action (CI2-14; B8-9). li
réveille alors tous les processus inscrits au point d'arrêt (CI5; B10), et libère le flag
d'arrêt.
CO
FOREVER {
Cl t
Receive_break._message (msg) ;
C2
BP.Start date
= Time 0;
C2.1
BP.Pid -
= msg.pid;
C2.2
BP.Node
= msg.node ;
C2.3
BP.Num
= msg.num;
C3
tmp
= BP.Break._flag ;
C4
BP.Break._flag
= ACTIVE;
C5
if (tmp == BUSY)
C6t
Send (BP.Channell, SIGNAL);
C7
Restarcuser..,processes_stopped_acl (BP.List) ;
C8t
do Receive (msg) while (msg:l: Stop_message) ;
C9t
Reschedule 0 ;
ClO
BP.Break._flag
=END;
CIl
BP.Stop_date
=Time 0 ;
Cl2
if (BP.Ctr :1: 0) {
C13t
Receive_signal (BP.ChanneI2) ;
Cl4t
Reschedule 0 ;
}
C15
Restarcuser..,processes_stopped_ac2 (BP.List) ;
C16
BP.Break._flag
=PREE;
}
Les séquences B8-9 et C12-14 assurent que sur chaque processeur, un point d'arrêt ne
se termine qu'avec la fm de l'action distribuée. L'enregistrement de la date d'arrêt (B2)
permet de déterminer l'ordre d'arrêt des processus.
W.3.2. Complexité.
La procédure d'arrêt nécessite la diffusion d'au moins un message de demande d'arrêt
des processus. Mais comme chacun des N processeurs peut diffuser un tel message, un
arrêt peut donc générer jusqu'à N messages de diffusion résultant d'autant de demandes.
W.3.3, Preuve de consistance de l'arrêt.
Dans cette section, nous montrons qu'un seul processus peut déclencher l'arrêt sur
chaque processus, et qu'une seule et même demande est prise en compte par touts les
processus. Nous montrons ensuite que l'arrêt est consistant; c'est à dire qu'il vérifie les
propriétés 1 et 2.
Lemme 1. Deux processus ne peuvent pas activer concurremment un point d'arrêt sur le
même processeur.
113.
Chapitre 5.

---

Preuve: Supposons que les processus Pl et P2 d'un même processeur tentent d'activer
concurremment la procédure d'arrêt. Pl précède P2. Si le point d'arrêt est actif, les deux
processus échouent (Al). Sinon, Pl positionne le flag (A2) et diffuse le message d'arrêt
en se bloquant éventuellement (A3). Si P2 arrive à ce moment, il échoue à cause du flag
positionné par Pl. Ensuite, Pl attend le signal d'activation du point d'arrêt que lui
envoie le processus gestionnaire. Si P2 arrive à ce moment, on a deux possibilités. Soit
le processus gestionnaire est en Cl et n'a pas encore reçu de message d'arrêt diffusé,
auquel cas BreakJlag vaut BUSY et P2 échoue; ou bien le gestionnaire a déjà reçu le
message et BreakJlag vaut ACTIVE (C3), auquel cas P2 échoue encore. CQFD.
Cependant, deux processus de deux processeurs différents peuvent activer le même
point d'arrêt du fait que la diffusion n'est pas instantanée, ce qui peut conduire à une
inconsistance du système. TI existe au moins trois solutions à ce problème.
La première est représentée par l'itération CS qui consiste à ignorer les messages
redondants. Cependant ce rejet ne distingue pas si ces messages se rapportent au même
point d'arrêt (i.e. même condition d'arrêt) ou pas.
La deuxième solution consiste à inscrire les messages de demande arrivant dans une
FIFO d'attente. Cette solution garantit que les fIles contiennent les mêmes messages
dans le même ordre, car la diffusion se fait de manière synchrone.
La troisième solution est basée sur le consensus des gestionnaires autour du numéro du
point d'arrêt. Le mécanisme de diffusion garantit que les messages sont reçus dans
l'ordre d'émission, quel que soit le processeur émetteur. Par conséquent les
gestionnaires reçoivent les messages d'arrêt dans le même ordre, et adoptent donc le
même numéro de point d'arrêt. Pour résoudre le problème des messages superflus, il
suffit que chaque demande d'arrêt soit étiquetée de l'adresse de l'émetteur, de sorte que
la fonction de demande d'arrêt (algorithme A) retourne un code indiquant si la demande
a été acceptée ou rejetée, car tous les processeurs connaissent la demande qui a été
acceptée.
Lemme 2. Les processus arrêtés sont dans un état consistant au sens de la propriété 1.
Preuve: soit P un processus quelconque arrêté (B 10). Si P s'est arrêté quand .le point
d'arrêt est actif, alors il a exécuté l'action distribuée, qui correspond en fait à la
continuation du même processus. Par conséquent, P peut enregistrer les informations
concernant son propre état (B6). Si P s'est arrêté volontairement, quand le point d'arrêt
devient actif, P est réveillé par le gestionnaire. On se retrouve alors dans le même cas
que le précédant. P peut donc collecter son propre état. CQFD.
114.
Chapitre 5.

---

Comme tous les processus suspendus sont inscrits dans la liste d'arrêt, un processus
spécial peut éventuellement collecter leur état en appliquant une action prédéfInie.
Lemme 3. L'ensemble des événement,s survenant avant CIl hors mis les réceptions de
messages, et l'ensemble des réceptions de messages survenant avant l'instruction C2
forment un ensemble, consistant au sens de la propriété 2 (C2 et Cl! désignent
l'ensemble des événements C2i et C11" pour tout gestionnaire i).
Preuve: soit • l'ensemble constitué des événements de réception de messages survenant
avant l'instruction C2 et des événements survenant avant C11 hors mis les réceptions de
messages. Selon [1], il nous suffIt de prouver que toute réception de message prise en
compte dans • comporte une émission elle aussi prise en compte dans •.
Soit m un message quelconque reçu avant C2i sur le processeur i. Soit r jm €
•
l'événement correspondant à la réception de m sur le processeur i; et soit e r
l'événement correspondant à l'émission de m sur le processeur j. L'événement r m s'est
j
produit avant C2i par hypothèse. Comme les communications sont synchrones, et que le
gestionnaire j a exécuté C9j (retour en fm de file d'exécution), le processus générateur
de l'événement e .m a été re-activé et a enregistré la terminaison e.m de la communication
J
J
m. Par conséquent, ej s'est produit avant C11j et appartient donc à •. Tout message reçu
avant C2i quel que soit i, a donc l'événement d'émission correspondante pris en compte
dans •. CQFD.
Pour construire ., il faudrait cependant au minimum enregistrer et dater tous les
événements de communication; avec les conséquences prévisibles.
111.4. Spécification d'actions distribuées.
L'action distribuée est défmie comme l'ensemble des actions exécutées par chacun des
processus ayant adhéré à l'arrêt. L'action exécutée par chaque processus est une fonction
passée en paramètre à la fonction d'arrêt conditionnel (algorithme B). Une liste variable
de paramètres peut être passée à l'action. L'algorithme de la fonction d'arrêt prenant en
compte l'action distribuée est le suivant :
B'O
Conditional_breakpoint (code, action, parameters) {
B'l
if ((BP.Break_flag == ACTIVE) Il (code == NOT_CONDmONAL)) {
B'2
Register3or_breakpoint (code, Time ()) ;
B'3·
if ((code == NOT_CONDmONAL) &&
(BP.Break_flag '* ACTIVE))
B'4t
Stop 0, BP.List) ;
B'5
BP.Ctr++ ;
B'6
if (action '* EMPTY)
IIS.
Chapitre s.

---

t
action (parameters) ;
B'7
else
t
DefaulCaction 0 ;
B'8
BP.Ctr-- ;
B'9
if ((BP.Ctr == 0) && (BP.Break_flag == END»
B'lOt
Send (BP.Channe12, SIGNAL);
B'Ut
Stop (2, BP.List) ;
}
}
En spécifiant l'action distribuée au niveau de chaque processus et de chaque point
d'arrêt, le programmeur peut contrôler plus efficacement les processus et la collecte des
données qu'avec une action globale. De plus, ce mécanisme permet de profiter de la .
puissance algorithmique du langage de programmation pour définir une infinité
d'actions, et en particulier d'exploiter une bibliothèque d'actions prédéfinies. De même,
couplé à une interface graphique, il est possible au programmeur d'examiner
interactivement l'état de chaque processus [98] (voir chapitre 6).
nI.S. Procédure de terminaison de l'arrêt.
Une façon de déterminer la fin du point d'arrêt consiste à contrÔler sur chaque
processeur que l'action distribuée est terminée. Chaque processeur doit alors annoncer
cette terminaison à un processeur privilégié (soit élu par les autres; soit fixé au choix du
programmeur; ou encore le processeur qui a déclenché l'arrêt), qui se charge de diffuser
un acquittement général. Mais cette méthode nécessite de définir un délai minimal pour
laisser aux processus le temps de s'inscrire; et elle génère au minimum N messages (N-l
signaux de fin, et un acquittement global). Une autre solution consiste à démarrer un
timer au bout duquel un ordre de terminaison est diffusé. La terminaison de l'action
distribuée est alors contrÔlée sur chaque processeur. Une troisième solution consiste à
laisser au programmeur l'initiative de déclencher la procédure de terminaison. Cela est
particulièrement utile en cas de contrÔle interactif. Le programmeur peut attribuer ce
rÔle de maître d'orchestre préférentiellement au processus qui a déclenché l'arrêt. Un
contrôle de l'identité de ce processus est facile à réaliser. C'est la solution que nous
avons retenue, en garantissant que la fm du point d'arrêt n'est effective sur chaque nœud
que lorsque l'action distribuée s'est totalement terminée :
DO
Disable_BreakPoint (pid) {
Dl
if (BP.Break_flag == ACTIVE)
D2
if ((pid == BP.Pid) && (BP.Node == GeCNodeNumberO) {
D3
BP.Break3lag
= END ;
D4t
broadcast (Stop_message);
}}
Le contrÔle d'identité (D2) et l'instruction (D3) permettent de ne diffuser qu'un seul
message de fin de l'arrêt. Mais avec cette stratégie, un nouveau point d'arrêt peut
116.
Chapitre 5.

---

commencer sur certains processeurs, alors que d'autres terminent le dernier. Ce
problème est résolu par la numérotation des points d'arrêt A3 [29].
IV. Implémentation et performances.
IV.I. Implémentation.
Les algorithmes qui viennent d'être présentés ont été implémentés sur le SuperNode du
'LIP (voir annexe 5). Les gestionnaires des prédicats et des procédures d'arrêt ont été
fusionnés en un seul sur chaque processeur. De plus, comme la modification d'un
prédicat donne lieu à une diffusion de message, de même que l'activation d'un point
d'arrêt, la fonction de validation des prédicats a été conçue pour activer le point d'arrêt
quand le prédicat devient valide: le premier processus qui valide le prédicat, active le
point d'arrêt. Le programmeur garde cependant la possibilité de valider les prédicats et
d'activer l'arrêt des processus séparément. Ce qui lui donne la liberté de concevoir ses
protocoles de contrôle des processus.
Dans cette implémentation, les prédicats ont une taille de 32 chiffres binaires (bits), et
sont gérés sous la forme d'un arbre équilibré. Comme certains prédicats n'utilisent
qu'une partie de ces chiffres (ceux qui coïncident avec les chiffres à 1 du numéro), le
programmeur a la possibilité d'utiliser le reste des chiffres pour véhiculer une
information contextuelle. Les fonctions ont été paramétrées et réduites à quatre (voir .
tableau 1). L'action distribuée a été implémentée comme un pointeur de fonction avec
des arguments variables. Un contrôle d'identité est effectué pour toute demande de
terminaison.
Exemples d'utilisation de ces fonctions :
• La plus simple expression pour activer et désactiver un point d'arrêt dont la valeur
associée est value:
• Arrêt conditionnel: le processus numéro 10 se trouvant à l'étape 5 imprime un
message donnant son numéro et sa position :
CDS_Bpoint (10, 5, printf, 3, "Processus %d arrêté à %d\\n", 10,5) ;
• Positionner le chiffre 4 du prédicat 24 sans activer le point d'arrêt.
CDS_Predicate (24, 4,0);
117.
Chapitre 5.

---

• Positionner le chiffre 5 du prédicat 24. Si le prédicat est vrai, le point d'arrêt est activé,
et chaque processus arrêté est invité à exécuter l'action qui lui est associée.
• Désactiver le point d'arrêt dont l'initiateur est ws.
CDS_Disable_Bpoint (ws) ;
IV.2. Mesure et analyse des performances.
Nous avons effectué une série de mesures pour déterminer le temps de propagation des
prédicats et d'arrêt des processus. Nous avons d'abord mesuré le temps d'exécution de
chaque fonction (tableau 1) pour estimer son coOt minimal sur un seul transputer. La
colonne de droite de ce tableau donne le coOt minimal de chacune de ces fonctions. On
notera par exemple que la fonction d'arrêt conditionnel Bpoint ne coOte que 7 Jls à
chaque appel quand le point d'arrêt n'est pas actif. Les valeurs de la colonne du centre,
quand l'action spécifiée est acceptée, représente le coOt minimal auquel il faudrait
ajouter le temps de communication ou de propagation d'un message diffusé.
FONCTION
Accepted Not acceptee
Predicate : positionnement d'un prédicat
53
27
Enable Bpoint: demande d'arrêt des processus
18
5
Predicate + Enable Bpoint: association des deux précédantes
64
32
Bpoint : arrêt conditionnel d'un processus
37
7
Disable Bpoint; demande de terminaison de l'arrêt
5
5
-Tableau 1-
Temps minimum des fonctions en J.lS.
Nous avons ensuite utilisé le moniteur du bus de contrôle que nous avons développé sur
le SuperNode pour la diffusion des messages (chapitre 3). Avec ce moniteur, le temps
de diffusion d'un message utilisateur de 10 octets d'un transputer de travail quelconque
vers tous les 32 transputers est de 1980 IlS. Nous avons obtenu les temps suivants :
•
Temps minimum pour positionner et diffuser un prédicat:
2034 IlS.
•
Temps minimum pour arrêter les processus:
1999 IlS.
•
Temps minimum pour terminer l'arrêt:
1986 IlS.
Ces mesures montrent combien l'efficacité de la gestion des prédicats et de l'arrêt des
processus est relative aux temps de communication. On peut comparer ces temps à un
anneau de 32 transputers, dont le temps théorique d'un tour pour 10 octets est de
1177,7 I.l.S sur un anneau unidirectionnel, et 612,8 I.l.S sur un anneau bi-directionnel. A
ces deux valeurs il faudrait ajouter le temps de communication des octets de contrôle.
118.
Chapitre 5.

---

VI. Conclusion.
Le système de gestion des prédicats que nous avons présenté peut être appliqué à la
programmation de protocoles nécessitant des choix consensuels (e.g. exclusion
mutuelle, élection). Nous avons démontré que l'arrêt sélectif des processus avec notre
système, est consistant au sens des propriétés 1 et 2. Le paramétrage du point d'arrêt
avec un pointeur de fonction donne une souplesse au programmeur pour spécifier les
actions distribuées que nous avons définies. Tout comme le système de Miller-Choi
peut ne pas atteindre l'arrêt pour des problèmes locaux, dans notre système un processus
ne peut s'arrêter que s'il a appelé la fonction d'arrêt au moment adéquat. Le nombre de
processus arrêtés dépend de la durée de l'arrêt.
Notre système génère peu de messages par rapport aux systèmes auxquels nous avons
fait référence dans ce chapitre. Le nombre total m des messages diffusés pour activer
un point d'arrêt dans notre système est: kN + 2 ~ m ~ KN2 + N + 1; où k est le
nombre de chiffres à un d'un prédicat, K est la taille maximale d'un prédicat, et N le
nombre de processeurs utilisés. Sachant que chaque message comporte au maximum 8
octets pour des prédicats de 32 bits, notre représentation des prédicats est peu coûteuse
en place mémoire (2 mots de 32 bits par prédicat). Les prédicats ainsi construits
peuvent être utilisés pour valider les propriétés stables du programme, car un prédicat
mémorise les événements qui se sont produits; et il reste vrai tant qu'il n'a pas été
invalidé
Notre système a en commun avec celui de Haban [56], le fait de disposer d'un processus
gestionnaire sur chaque processeur, et d'utiliser la diffusion entre les gestionnaires.
Mais les deux systèmes comportent des différences importantes. Notre système
n'estampille pas les messages diffusés comme dans [56]. li n'y a pas de communications
directes entre les gestionnaires et les processus utilisateurs du fait que la diffusion est
déclenchée par ces derniers. Notre système a de ce fait une moindre interférence avec
les processus utilisateurs et génère moins de messages; e.g. dans [56], la validation
d'une condition conjonctive donne lieu à plusieurs communications entre le gestionnaire
local et les différents processus pouvant valider cette condition. La procédure d'arrêt des
processus dans notre système diffère de celle de [56] qui utilise l'algorithme de [35]
avec les inconvénients qu'il comporte. De plus, notre système permet un arrêt sélectif
des processus. Enfin, un groupe de processus ne peut pas bloquer notre procédure
d'arrêt tant que l'état du système n'a pas été altéré.
Les systèmes d'arrêt ajoutent un surcoût non négligeable à l'exécution des processus,
qui a pour conséquence de changer l'ordre d'occurrence des événements. Mais ce
119.
OJapitre 5.

---

problème est inévitable à cause du caractère logiciel de ces systèmes. En outre à cause
des délais de communication, l'état des processus peut évoluer considérablement entre
le moment où la décision d'arrêter le système est prise et le moment où elle devient
effective.
120.
Chapitre 5.

---

Chapitre 6.
Etude et Mise en Œuvre de COS · C-Net
Oebugging System.
Introduction.
Ce chapitre est consacré à la conception de CDS (C_NET Debugging System), le système
de mise au point de programmes C_NET. Concevoir un système de mise au point de
programmes parallèles (SMAP) à partir d'un ensemble de fonctionnalités, dans un
environnement donné est un problème complexe comportant beaucoup de problèmes à
résoudre. D'abord le SMAP doit être étudié pour l'utilisateur fmal. Or celui-ci n'est pas
unique, et par conséquent, les exigences sont multiples. En outre, l'environnement de
programmation (architectures, langages de programmation, systèmes d'exploitations,
outils intégrés, ete...) représente une multitude de contraintes qu'il faut prendre en
compte lors de la conception du SMAP. D'autres difficultés viennent de l'absence de
méthodologies permettant de guider la conception de SMAP, et de l'absence d'outils
standards (e.g. visualisation, analyseurs de traces). De même un défaut de standard rend
difficile la réutilisation d'outils existants pour des raisons de portabilité, en particulier les
outils de mise au point de programmes séquentiels dont l'efficacité est éprouvée.
CDS comme bon nombre de SMAP, est un système multi-fonctions principalement
orienté vers la mise au point en ligne. TI permet à la fois, le contrôle global du système
(point d'arrêts globaux conditionnels présentés au chapitre 5); le contrôle individuel des
processus (point d'arrêt individuel); la communication entre les processus et le
programmeur; la collecte de traces estampillées avec l'horloge globale présentée au
chapitre 4; la communication entre processeurs grâce au moniteur du bus (chapitre 3); la
collecte de vues du contexte des processus à la fois par les processus eux-mêmes, par des
processus espions (voir chapitre 1) et par le programmeur lui-même; la collecte de l'état
global du système. CDS peut être étendu à de nouvelles fonctionnalités définies en
particulier par l'utilisateur en exploitant la communication directe avec les processus.
CDS comporte trois composantes. La première est une bibliothèque de fonctions que le
programmeur introduit dans le code source aux endroits qu'il juge intéressants. Ces
fonctions servent à préparer les observations qui sont en suite, collectées, transportées et
gérées par un moniteur logiciel, deuxième composante de CDS. Enfin, une interface
graphique multi-fenêtres (troisième composante) permet de visualiser ces observations, et
121.
Chapitre 6.

---

de recevoir les commandes du programmeur destinées aux processus en cours
d'exécution.
Ce chapitre est organisé de la façon suivante. La première partie situe CDS par rapport
aux travaux actuels de la recherche. Après un résumé de l'état de l'art, elle décrit les
fonctionnalités et les spécificités de CDS. La deuxième partie présente l'étude des choix
de mise en œuvre de CDS. Elle présente les problèmes que nous avons rencontrés lors de
la conception de CDS, et les choix que nous avons faits pour résoudre ou minimiser ces
problèmes. La troisième partie décrit la mise en œuvre de CDS conformément à ces
choix. Elle décrit l'architecture de CDS et son fonctionnement du point de vue système,
ainsi que certains choix de programmation que nous avons faits. Enfin, la quatrième
partie présente quelques extensions possibles de CDS. Les algorithmes de ce chapitre
sont écrits en C de Logical Systems [33] [82] [123].
1. Présentation générale de CDS.
Cette section a un double objectif. Le premier est de situer CDS par rapport aux
orientations actuelles de la recherche sur la mise au point des programmes parallèles, dont
nous donnons un aperçu. Le deuxième objectif est de donner au lecteur une vue générale
de CDS: modèle, fonctionnalités, caractéristiques conceptuelles.
1.1. L'état de l'art.
1.1.1. Les modèles classiÇPJes.
Les SMAP classiques (cf. chap. 1) peuvent être regroupés en quatre classes. Le tableau
A 1 (Annexe 6) résume pour chacune de ces classes, les caractéristiques et les domaines
d'application (.), les avantages (+) et les inconvénients (-). Aucune classe a elle seule ne
permet de couvrir l'essentiel des domaines des erreurs possibles. Notre classification ne
prend pas en compte l'analyse statique, qui certes présente un intérêt pour la recherche
des erreurs (cf. chap. 1), mais ne constitue pas une technique de mise aù pomt à part
entière.
1.1.2. Les orientations actuelles de la recherche.
Devant les limites des modèles classiques, les exigences des utilisateurs [88], et
l'évolution des machines et des environnements de programmation, la recherche sur la
mise au point des programmes parallèles connait un grand essor. Ses orientations peuvent
être reparties en quatre axes orthogonaux : étude de SMAP multi-fonctions;
automatisation de la mise au point; standardisation; recherche de méthodologies de mise
122.
Chapitre 6.

---

au point et de conception des SMAP. Chacun de ces axes représente un domaine de
recherche ouvert.
a} SMAP multi-fonctions.
Pour couvrir un large domaine des erreurs détectables, les SMAP sont étudiés comme des
boîtes à outils dans lesquelles le programmeur peut choisir lès outils les plus appropriés
pour résoudre son problème [40]. C'est le cas des systèmes comme CXdb [119] et bdb
[129] qui intègrent à la fois les points d'arrêt, l'analyse symbolique et l'analyse de traces.
Comme le souligne Couch [41], une difficulté majeur de conception de ces SMAP est de
gérer l'interaction entre les composantes réalisant les différentes fonctions du SMAP;
composantes qui en général s'exécutent sur des machines et des systèmes différents.
b} Automatisation.
Pour simplifier l'usage des SMAP, la recherche s'intéresse à l'automatisation de la
procédure de mise au point. L'aspect le plus concret concerne le couplage entre le SMAP
et le compilateur [37] [81] [119]. Ce couplage présente beaucoup d'intérêts. TI permet au
SMAP d'exploiter les informations statiques générées ou connues à la compilation (table
des symboles, adresses relatives, arbre syntaxique, variables automatiques générées par
le compilateur, portée des variables, etc...). li permet d'insérer automatiquement les
actions de contrôle d'exécution et de collecte des données dynamiques dans le code
généré par le compilateur. li permet également, à partir de la spécification de modèles de
comportements ou d'événements, de réaliser automatiquement la collecte des données
nécessaires à la validation de ces modèles comme dans [20). L'insertion automatique des
points de collecte de traces permet d'autre part de recueillir des informations à un niveau
de détail très fm et à grande échelle comme dans [79]. Nous pensons aussi à la possibilité
de réaliser des actions système spécifiques, comme piéger les communications pour la
mesure des performances [20]. Le couplage entre le compilateur et le SMAP nécessite
que ces deux logiciels soient conçus dans cet objectif. Or, en général le compilateur est
antérieur au SMAP.
c} Standardisation.
Pour faciliter la réutilisation des outils existants ou l'exploitation des informations
générées par ces outils, un effort de standardisation est réalisé, et quatre modèles sont
proposés. Le premier est la norme DWARF [81.] qui défmit un format des données
produites par les compilateurs, les assembleurs et les éditeurs de liens, et destinées aux
SMAP. Les trois autres normes visent à défmir un interpréteur universel pour l'analyse
des traces. La première proposée par Reed [111] consiste à définir un format standard
123.
Cbapi1>e 6.

---

d'enregistrement des traces: entête + message. Les fichiers ainsi constitués sont destinés
à un interpréteur universel. La deuxième approche citée dans [4l.] consiste à construire un
interpréteur universel dont les fonctions d'accès aux traces doivent être écrites par
l'utilisateur ou le concepteur du SMAP. Enfin, la troisième norme proposée par Couch
[41], consiste à associer l'interpréteur universel avec un langage de spécification. Les
traces sont collectées dans un format libre et l'utilisateur spécifie ensuite le modèle des
divers types de traces. La spécification compilée, donne un traducteur qui convertit les
traces en vecteurs (tallies dans sa terminologie) reconnaissables par l'interpréteur
universel.
La génération de traces dans des formats prédéfinis permet de ré-utiliser les outils de
visualisation existants. C'est le cas des systèmes CDBX [112] et VIPS [115] qui
communiquent des requêtes à DBX (un système de mise au point symbolique d'Unix) à
travers un pipe et récupèrent les résultats qu'ils affichent alors sur plusieurs fenêtres, avec
différents niveaux de vue. Mais comme le souligne Couch [41], les normes imposent en
général un formalisme contraignant et une quantité non négligeable de données
supplémentaires à collecter ou mémoriser. Dans un domaine en plein essor, la
standardisation ne s'adapte pas facilement aux nouvelles idées;
d) Méthodologies.
TI existe deux axes de recherche de méthodologies, l'un visant la conception des SMAP et
l'autre, les techniques de mise au point.
Le premier axe cherche à définir un modèle général de SMAP, et par conséquent une
démarche globale de conception. Dans [40], comme un SMAP est un système en
interaction avec son environnement, la démarche de conception proposée consiste à
découper cet environnement en domaines et à étudier les interactions du SMAP avec
chaque domaine. Cela permet de mettre en lumière les problèmes à résoudre lors de la
conception du SMAP. Nous avons repris cette idée [98] et avons proposé un ensemble
d'étapes pour mener cette conception. Young [129] propose un modèle de SMAP basé
sur des bibliothèques de fonctions facilement extensibles. Khanna [69] propose de
décomposer le SMAP suivant ses fonctions fondamentales : visualisation; gestion de la
table des symboles; moniteur d'exécution; interfaçage de ces composantes. L'un des
problèmes auquel on se trouve confronté en élaborant un modèle général de SMAP est la
diversité des environnements.
Le deuxième axe vise à défmir une méthodologie de mise au point. La situation et sa
difficulté sont bien posées dans [18] : pour établir une démarche méthodique de mise au
point, il importe de définir l'ensemble des hypothèses que l'on peut faire sur le
124.
Chapitre 6.

---

comportement du programme et les erreurs à chercher, et de définir les opérations
possibles sur cet ensemble. Cela nécessite par conséquent : une théorie sur les
programmes (spécification formelle, modèle de programmation, modélisation du
comportement du programme, etc ...); une théorie sur les erreurs (classification,
causalité); et une théorie du raisonnement. La stratégie de mise au point proposée dans
[18] est basée sur la validation d'hypothèses. Dans [115] la mise au point se base sur la
représentation à plusieurs niveaux d'abstraction de listes liées. Dans [79] c'est une
technique de représentation spacio-temporelle (4 dimensions) qui est proposée, là aussi
avec plusieurs niveaux d'abstraction. Enfm, [41] propose une organisation relationnelle
des données collectées qui permet entre autres d'utiliser une stratégie question-réponse
pour la mise au point. Bâtir une méthodologie de mise au point nécessite de prendre en
compte la diversité des situations et des causes d'erreur.
1.2. Les choix de CDS.
La section précédente nous a donné un repère par rapport auquel nous allons maintenant
situer CDS, c'est à dire son modèle, ses fonctionnalités et ses caractéristiques
conceptuelles.
1.2.1. Le modèle de CDS.
CDS s'inscrit dans l'orientation actuelle de la recherche sur les SMAP. C'est un système
multifonctions, permettant la mise au point interactive en ligne de programmes C_NET, à
un niveau d'observation et de contrôle très fm. Pour réaliser ce contrôle, le programmeur
dispose d'une bibliothèque de fonctions à insérer dans le programme source aux endroits
qu'il juge adéquats. Ce choix, qui est aussi celui d'un certain nombre de SMAP existants
[20] [57] [129], se justifie par le fait que l'environnement C_NET ne se prête pas à un
couplage entre le compilateur et CDS, car ce compilateur utilise C++ et les bibliothèques
du C de Logical Systems [82] qu'il aurait alors fallu modifier. Ces fonctions permettent
aux processus utilisateurs de communiquer avec une interface graphique multifenêtres, à
travers le moniteur interactif de CDS chargé de convoyer les informations. Ce système
permet de recevoir les commandes du programmeur et de les répercuter sur les processus
en cours d'exécution.
1.2.2. Les fonctionnalités de CDS.
CDS comporte six fonctionnalités principales compatibles avec son environnement.
La première fonctionnalité est le contrôle d'exécution par des points d'arrêt conditionnels
pouvant placer les processus en mode conversationnel. Il s'agit d'une part de points
d'arrêt globaux défmis au chapitre 5, que le programmeur peut éventuellement activer à
125.
Chapitre 6.

---

l'aide de l'interface graphique. Il s'agit d'autre part de points d'arrêt individuels à chaque
processus permettant au programmeur de dialoguer avec ces processus pour en obtenir
des vues et modifier leurs contextes : variables internes, canaux de communication,
variables système {Wptr+i, i=O..n} [62] [63] et descripteurs de processus [82].
La deuxième fonctionnalité est l'observation des processus à travers de vues qui sont soit
envoyées individuellement par chaque processus; soit obtenues collectivement par un
processus spécial de CDS; soit commandées directement par le programmeur à partir de la
console de mise au point, à n'importe quel moment et sans suspendre ces processus. Ce
sont des vues internes comme dans [79] donnant l'état du contexte des processus
(canaux, variables internes, variables système). Cette fonctionnalité est particulièrement
utile quand des événements graves n'affectant pas le SMAP se produisent; situations
courantes avec les programmes parallèles (interblocages, boucles infinies).
La troisième fonctionnalité est la communication de manière indépendante du réseau
principal, à la fois entre le programmeur et les processus, et entre processus de
processeurs distants. La communication entre le programmeur et les processus permet au
programmeur de transmettre des données ponctuelles à ceux-ci (e.g. valeurs initiales) et
d'écrire des extensions du système de mise au point. La communication entre processeurs
est destinée à diffuser les informations transmises par le programmeur à des processus
privilégiés. Elle est également destinée à échanger des informations spécifiques comme
les mesures de performances.
La quatrième foncti.onnalité est l'enregistrement de traces (événements et vues) des
processus et leur visualisation pour revoir à tout moment l'historique de l'exécution. Une
relation temporelle établie entre les événements grâce à l'estampillage des traces avec
l'horloge globale présentée au chapitre 4, permet de synchroniser l'affichage des traces
entre plusieurs fenêtres. Cela permet de donner une image de l'exécution restituant assez
fidèlement son déroulement parallèle.
La cinquième fonctionnalité est l'affichage en temps réel des événements des processus,
ainsi que l'état du réseau principal de communication du SuperNode. Cela,
indépendamment de l'observation des traces, notamment en cas de saturation des fichiers.
La sixième fonctionnalité est la collecte intercative par le programmeur de l'état global de
chaque processeur. TI s'agit en particulier de l'état des quatre liens, des processus CDS,
des prédicats globaux, des processus ayant adhéré à un point d'arrêt global.
126.
Chapitre 6.

---

1.2,3. Les caractéristiques conceptuelles de CDS.
CDS, comme on peut le noter, ressemble à un certain nombre de SMAP [20] [79] [119]
[129]; mais il présente quelques aspects spécifiques. Nous avons déjà mentionné
l'utilisation d'un algorithme statistique et probabiliste pour l'estampillage des événements
(chap. 4) et le système de points d'arrêt globaux présenté au chapitre 5. Dans CDS,
l'observation des événements des processus est basée sur une technique d'affichage
synchrone; et l'observation et le contrôle de l'état des processus sont basés sur
l'utilisation de descripteurs de contexte.
a) Afficbage syncbrone des traces.
Les traces des événements collectées par CDS sont visualisées suivant une technique que
nous appelons affichage synchrone des traces. Cette techniques vise à restituer
l'évolution temporelle de l'exécution. Contrairement à l'affichage classique, l'affichage
synchrone permet de prendre en compte la simultanéité d'occurrence des événements
entre différents processeurs. L'affichage synchrone consiste à associer une fenêtre à
chaque processeur (ou éventuellement à un groupe de processeurs), et à commander
l'affichage à partir d'une fenêtre pilote de sorte que les événements qui se sont produits
au même moment relativement à l'horloge globale, apparaissent en même temps dans
chacune des fenêtres. Cette technique est un moyen naturel pour restituer le déroulement
parallèle du programme.
b) Descripteur de contexte des processus.
L'observation et le contrôle de l'état des processus dans CDS sont basés sur l'utilisation
de descripteurs de contexte des processus (PCD). TI s'agit d'une structure construite par
chaque processus utilisateur à contrôler, dans laquelle il inscrit ses canaux, ses variables
internes et ses variables système qui caractériseront son contexte. L'image (ou vue) de ce
contexte peut être prise à n'importe quel moment en utilisant ce descripteur. Un PCD peut
être exploité de quatre façons complémentaires :
•
Dialogue. Un processus atteignant un point d'arrêt individuel communique son
PCD au moniteur interactif qui en prend une vue et la transmet à l'interface graphique. Le
programmeur peut alors consulter cette vue et la modifier variable après variable. Tout se
passe comme si le programmeur communiquait directement avec le processus, d'où le
terme dialogue. A la fm du dialogue, les modifications dü programmeur sont répercutées
sur le processus qui continue ensuite son cours normal avec un nouveau contexte. De ce
fait, un point d'arrêt individuel est dans CDS un point de changement de contexte.
127.
Chapitre 6.

---

•
Obtention d'un état global consistant. Le processus peut inscrire l'adresse de son
PCD dans une liste d'observation. Les points d'arrêt globaux sont typés dans CDS. Un
de ces types permet à CDS de lire la liste des PCD, de collecter une image (vue) du
contexte de chaque processus inscrit et de la transmettre au moniteur interactif. L'état
global ainsi obtenu est consistant au sens de Chandy-Lamport [35] comme nous l'avons
montré au chapitre 5.
•
Espionnage. CDS dispose d'un processus espion (chap. 1) qui lit régulièrement
la liste des PCD, collecte des vues et les transmet au moniteur interactif. Ce processus
peut être contrôlé par les processus utilisateurs (activation, désactivation, ajustement de la
phase d'espionnage), ou directement par le programmeur à travers l'interface graphique et
le moniteur interactif.
•
Scanner. Le scanner allie l'activité d'espionnage avec la technique de dialogue. Le
programmeur peut à travers l'interface graphique et le moniteur interactif, demander à tout
moment au scanner de lui communiquer la liste des PCD. Une fois que cette liste est
transmise par le scanner au moniteur interactif, le programmeur peut alors spécifier au
scanner lesquels des processus il veut obtenir une vue. Cette spécification faite, le
scanner collecte les vues et les transmet au moniteur interactif. Ce mécanisme est
particulièrement utile quand un événement grave épargnant CDS se produit. n donne au
programmeur un contrôle réel et direct de l'exécution.
L'utilisation des PCD fait que l'activité du scanner et du processus espion n'occasionne
pas la suspension des processus utilisateurs en dehors du mécailisme naturel
d'ordonnancement. C'est un moyen efficace pour contrôler discrètement une exécution,
ou de fouiller une erreur dans le cas de processus évanescents. Tous ces mécanismes
comme on peut s'en douter posent un certain nombre de problèmes de mise en œuvre:
consistance des observations, congestions dans le circuit de transport, équité d'accès au
moniteur, coordination des décisions entre différentes composantes du SMAP, efficacité,
etc... C'est l'objectif de la partie suivante de montrer comment ces problèmes ont été
résolus ou minimisés.
II. Etude de CDS.
Construire un SMAP revient à trouver un compromis entre les fonctionnalités qu'on se
donne, la capacité de l'environnement à supporter ces fonctionnalités et les exigences de
l'utilisateur. La conception d'un SMAP doit prendre en compte les besoins de l'utilisateur
qui attend d'un SMAP qu'il soit facile à utiliser et qu'il permette de répondre au
maximum de situations d'erreurs [102] [88]. L'environnement de programmation impose
128.
Chapitre 6.

---

des contraintes à la mise en œuvre d'un SMAP : spécificités d'un langage de
programmation, architecture, concept d'état du système, modèle de parallélisme,
portabilité, ete... C'est l'ensemble de ces problèmes et contraintes liés à la conception de
CDS, et les solutions que nous avons trouvées, minimisant ou résolvant ces problèmes,
que cette partie présente.
Nous utilisons le modèle de SMAP de [40] que nous avons étendu, pour organiser cette
présentation. Nous décrivons d'abord ce modèle étendu. Ensuite, suivant ce modèle,
nous présentons successivement les problèmes de conception que nous avons rencontrés,
et les solutions que nous avons trouvées.
II.I. Modèle de répartition des problèmes.
Une des difficultés majeures pour concevoir un SMAP est l'implémentation des
fonctionnalités de mise au point pour un environnement donné. Une solution possible
consiste à décomposer l'environnement de mise au point en domaines et d'analyser les
interactions du SMAP avec chaque domaine. Cheng, Black et Manning CBM] ont
suggéré de décomposer l'environnement de mise au point en trois domaines :
spécification, exécution, et observation. Le premier est le code source au niveau duquel le
programmeur spécifie le comportement du programme et les données à collecter. Le
deuxième domaine concerne la relation entre le SMAP, le système d'exploitation et les
processus du programme à mettre au point. Le troisième domaine se rapporte aux
interactions possibles entre le programmeur et le SMAP pour observer et contrôler le
programme. Le SMAP est l'agent de liaison entre ces trois domaines.
Nous complétons ce modèle avec un domaine supplémentaire: le matériel sur lequel le
SMAP doit être implémenté (fig. 1). Ce domaine impose un ensemble de contraintes que
le concepteur du SMAP doit prendre en compte. Concevoir un SMAP consiste alors à
trouver les moyens pour résoudre ou minimiser les problèmes liés à l'interaction du
SMAP avec chaque domaine sous les contraintes imposées par le matériel.
Le reste de cette partie est structuré suivant ce modèle (SMAP + 4 domaines). Nous
analysons pour chaque domaine, les problèmes rencontrés lors de la conception de CDS
et décrivons les choix et solutions que nous avons retenus.
129.
Chapitre 6.

---

II.2. Problèmes de conception de CDS.
Nous avons dit §I.2.1, que CDS comportait trois composantes, à savoir une bibliothèque
de fonctions, un moniteur interactif et une interface graphique. Le graphe des interactions
de la figure 2 montre les quatre types d'échanges d'informations qui ont lieu dans CDS :
insertion des actions de mise au point (domaine de spécification 0-1); collecte des
observations et contrôle d'exécution (domaine d'exécution 3-4); affichage des
observations et introduction des informations de contrôle par l'utilisateur (domaine
d'observation 9-10); échanges internes à CDS (domaine du matériel 2, 5-8). Le reste de
cette section examine domaine par domaine les principaux problèmes de mise en œuvre
liés à ces échanges, que nous avons rencontrés lors de la conception de CDS.
O. Inserting debugging code
1. Debugging strategy modification
2. Parallel program loading and execution
3. Observation collecting
4. Programmer request delivery
5. Observation transport
6. Request transport
7. Observation delivery
8. Request collecting
9. Observation display
10. On-line dialogue requests
-Figure 2-
Schéma des échanges dans CDS.
112.1. Problèmes liés au matériel.
Nous avons dit que le matériel impose des contraintes dont il faut tenir compte à la
conception du SMAP. Elles sont multiples, et nous n'en présentons que les plus
importantes.
a) Nature du SMAP dictée par le matériel.
Certains environnements favorisent le développement de moniteurs matériels ou hybrides
qui sont plus robustes que les moniteurs logiciels et minimisent les interférences avec les
processus utilisateurs [26J [40]. Dans la machine Hathi-2 [20J par exemple, tout est mis
en œuvre pour faciliter la conception d'un SMAP. Les processeurs y sont organisés en
25 grappes de 5 nœuds. Chaque grappe comporte un contrôleur T212 et quatre
transputers de travail T800 reliés par un C004. Les T212 sont statiquement reliés entre
eux en anneau, et les T800 forment un réseau réconfigurable. Chaque T800 présente une
FIFO avec son transputer de contrôle grâce à un recouvrement mémoire. Un circuit
spécial permet d'estimer la charge de chaque T800 en observant les accès en mémoire
130.
Chapitre 6.

---

externe. Chaque T212 peut envoyer une interruption sur le canal EVENT de chaque
T800. EnfIn, chaque T800 présente une FIFO de 512 octets avec le T212, dans laquelle il
peut envoyer un compte rendu à ce dernier.
C'est là une machine permettant de développer un moniteur hybride pouvant fonctionner
même après qu'une anomalie affectant le SMAP se soit produite. Les PIFO peuvent
servir à mémoriser des informations à collecter en cas de pannes logicielles. Des
interruptions sur les canaux EVENT peuvent servir à synchroniser l'accès aux FIFO
comme c'est proposé dans [20]. EnfIn l'observation des accès mémoire permet de de
mesurer le taux d'activité d'un processeur.
Avec le SuperNode, nous n'avons pu envisager qu'un moniteur logiciel. Son exécution
perturbe l'ordonnancement des processus utilisateurs du fait de l'accès du CPU. Seuls les
moniteurs matériels sont non-interférants [26] [130]. D'autre part, l'organisation du
SuperNode conduit implicitement à une structure hiérarchique de CDS, du fait que les
observations transitent par le bus de contrôle (voir chapitre 3). De plus, comme le
souligne [26], les moniteurs des systèmes distribués ne peuvent être que des systèmes
distribués.
b) Compatibilité des composantes de CDS sur différents matériels utilisés.
Les composantes de CDS s'exécutent en parallèle sur des machines et des systèmes
différents (SuperNode, carte Parsytec, serveur Sun, station Sun, C de Logical Systems
[82], Unix). Comme le souligne Couch [41], cette diversité engendre des problèmes de
compatibilité des données et des communications (e.g. canaux sur le transputer vs
sockets sous Unix, binaire pur vs ASCI).
c) Fluidité du transport des observations liée à la vitesse de communication.
L'organisation hiérarchique du moniteur imposée par le matériel, engendre des goulots
d'étranglement et des congestions dans le circuit de transport des messages, ce qui peut
ralentir dramatiquement tout le système. Pour un système utilisant la collecte des traces
comme CDS, ce problème ne peut être effIcacement résolu qu'avec l'enregistrement des
traces distribué sur chaque nœud; solution malheureusement non-envisageable dans notre
environnement.
d) EtTets pervers des niveaux de priorité du transputer.
L'ordonnancement des processus selon leur niveau de priorité conduit à des effets
pervers. L'un d'eux se manifeste sur l'estampillage des messages: il peut se passer un
certain temps entre le moment où un événement a lieu et le moment où il est daté. C'est le
131.
Chapitre 6.

---

cas pour un processus de basse priorité qui peut être interrompu entre le moment où il
vient de terminer une action et le moment où il entre dans la fonction d'estampillage. Cela
est da au fait que dans cet intervalle, le processus peut avoir épuisé son quantum de
temps, ou qu'un processus de haute priorité est prêt à s'exécuter. Ce décalage entre les
dates d'occurrence et d'estampillage fait que la datation des événements peut violer
l'ordre total des événements sur un même processeur; ordre total que l'horloge globale est
sensée préserver. Un autre effet est l'équité, qui se présente de deux façons.
Premièrement, les processus utilisateurs doivent accéder au moniteur interactif de
manière équitable, pour notamment éviter des cas de famine, ou favoriser les processus
qui produiraient plus et plus vite de traces que d'autres. Or les processus de hautes
priorités n'étant interruptibles qu'à des endroits précis (points de communication, de
temporisation ou de choix gardé), ils peuvent donc produire un nombre illimité de traces.
De même un processus de basse priorité peut produire une quantité de traces
proportionnelle à son quantum de temps.
Deuxièmement, un processus de haute priorité peut interrompre tout processus de basse
priorité à n'importe quel endroit. Ce qui fait que ce sont les processus de basse priorité
qui vont le plus souffrir de l'interférence avec le moniteur. En effet, si le moniteur
s'exécute en haute priorité, il interrompra arbitrairement les processus de basse priorité.
S'il s'exécute en basse priorité, les processus de haute priorité pourront l'interrompre, et
par conséquent ne subiront pas d'interférence avec le moniteur. TI faut donc trouver un
mécanisme rendant l'interférence du moniteur équitable à tous les processus.
e) Robustesse du SMAP dépendant des mécanismes de protection mémoire.
Une séparation entre le SMAP et les processus utilisateurs est nécessaire pour permettre
l'observation de ceux-ci en cas d'anomalie. Mais le transputer n'offre pas de protection
mémoire. Les processus utilisateurs peuvent donc a priori modifier le comportement de
CDS.
II.2.2. Problèmes liés à la spécification.
La spécification des actions de mise au point consiste pour le programmeur, à insérer les
fonctions adéquates de CDS dans le code source aux endroits intéressants. Cela pose
quatre principaux problèmes, à savoir, la lisibilité, la redondance des actions de mise au
point, l'efficacité des fonctions et leur facilité d'usage.
132.
Chapitre 6.

---

n.2.3. Problèmes liés à l'exécution.
La mise en œuvre des mécanismes de communication entre le SMAP et les processus
utilisateurs doit prendre en compte les problèmes que ces communications peuvent
engendrer pendant l'exécution. Dans CDS, ces communications portent sur la collecte des
traces et des vues, le transfert des messages entre processeurs, et la modification du
contexte des processus utilisateurs. Les principaux problèmes que nous avons rencontrés
peuvent être regroupés en trois catégories.
a) Modification de l'ordonnancement des processus.
Les communications que nous venons de citer changent l'ordonnancement des processus
utilisateurs à cause de la mise en attente de ces processus: FIFü pleines (chap. 3), attente
d'une synchronisation ou d'une communication, points d'arrêt individuels, transfert de
message. Les processus ainsi arrêtés vont provoquer l'arrêt
en cascade d'autres
processus à cause des dépendances de communication.
b) Consistance du système.
Un point d'arrêt individuel ayant pour effet de modifier le contexte du processus associé,
il est donc essentiel de garantir la cohérence de ce contexte au moment de l'arrêt et lors de
la reprise de l'exécution du processus.
c) Fiabilité.
Elle se pose aux niveaux qualitatif et quantitatif. Au niveau qualitatif: les vues collectées
doivent correspondre à l'état réel du processus au moment de la collecte. Mais en même
temps, il faut éviter de collecter des vues non significatives: variables d'un processus
qui vient tout juste d'être créé, résultats intermédiaires, vue d'un processus terminé. Au
niveau quantitatif: le programmeur doit pouvoir collecter l'essentiel des informations
qu'il désire. Or le fait que les points d'arrêt soient réalisés par des appels de fonctions ne
garantit pas qu'on peut toujours arrêter un processus, en particulier s'il se comporte mal.
n.2.4. Problèmes liés à l'observation.
Le problème majeur de l'observation est la restitution fidèle du comportement et de l'état
des processus. Cela concerne à la fois le format de présentation des observations au
programmeur, et la restitution du parallélisme: l'interface graphique doit refléter le
parallélisme du système [89]. Elle doit également permettre le fùtrage des messages, car
les systèmes avec traces sont connus pour la profusion des informations collectées.
133.
Chapitre 6.

---

II.3. Analyse des choix de mise en œuvre.
Ces choix ont été faits avec le souci de répondre aux problèmes qui viennent d'être
dégagés, au niveau de chaque composante de CDS (fig. 2). Par exemple les problèmes
liés au matériel son pris en compte au niveau du moniteur interactif. Nous allons d'abord
examiner la structure du moniteur interactif en montrant comment les contraintes
matérielles ont influencé nos choix. Ensuite, nous allons analyser les choix liés à la
spécification des actions de mise au point, à l'interaction des processus utilisateurs avec le
moniteur, et à l'interface graphique.
II.3.1. Choix liés au matériel; le moniteur interactif.
Nous examinons d'abord la structure générale du moniteur, et nous montrons ensuite
comment il intègre les contraintes liées à la compatibilité des composantes, la fluidité dans
le circuit de transport, les interférences, l'équité et la robustesse.
a) Choix de l'architecture du moniteur interactif.
Conformément à l'architecture du SuperNode, nous avons divisé le moniteur de CDS en
quatre niveaux organisés de la façon suivante (fig. 3) ;
•
Sur chaque transputer de travail, un moniteur local est chargé de collecter les
observations, de réaliser la modification du contexte des processus, les points d'arrêt
globaux et la synchronisation avec l'horloge du processeur de contrôle. Ce moniteur
comporte en plus d'une extension du moniteur du bus de contrôle présenté au chapitre 3,
un scanner destiné à collecter les vues des processus à la demande du programmeur; et un
processus espion destiné à observer périodiquement le contexte des processus.
•
Sur le transputer de contrôle, un moniteur central est chargé de véhiculer les
observations entre la carte frontale et les transputers de travail, de synchroniser les
horloges des processeurs de travail, et de relayer les messages des points d'arrêt ,globaux
entre processeurs de travail. Le moniteur central est également une extension du moniteur
du bus de contrôle.
•
Une interface de communication repartie sur la carte frontale et le serveur du
SuperNode, est chargée de véhiculer les informations entre le processeur de contrôle et la
station de mise au point.
•
Enfin, un moniteur s'exécutant sur la station de mise au point sert à gérer les
observations (traces, dialogues, vues, commandes de contrôle) et à communiquer avec le
serveur du réseau et l'interface graphique.
134.
Chapitre 6.

---

Les informations de mise au point circulent en flot bidirectionnel dans le moniteur
interactif; d'où le qualificatif interactif. Sortant du SuperNode on a les traces et les vues.
Entrant dans le SuperNode on a les vues modifiées pour le changement de contexte,les
demandes d'arrêt global, les requêtes du programmeur aux scanners ou aux processus
espions, et les messages spécifiques du programmeur à certains processus.
-Figure 3-
Répartition du moniteur interactif.
b) Compatibilité des composantes.
Le problème de compatibilité se pose entre : le transputer de la carte frontale et le serveur
Sun; le serveur Sun et la station de mise au point; l'interface graphique et le moniteur de
la station. Entre transputers il n'y a pas problème de compatibilité. Ces problèmes ont été
traités de la façon suivante:
•
La connexion frontal-serveur est réalisée par un bus VME. Une adaptation du
logiciel existant pour communiquer entre ces deux machines a été nécessaire pour d'une
part partager ce bus entre COS et le configureur dynamique [28], et d'autre part réaliser
des communications bidirectionnelles.
•
Comme un réseau Eternet relie le serveur à la station, nous avons donc choisi
d'utiliser des sockets pour communiquer entre ces deux machines.
135.
Chapilre 6.

---

•
La communication entre l'interface graphique et le moniteur de la station a lieu à
travers des fichiers et une mémoire partagée. Les fichiers contiennent les traces et les vues
inscrites par le moniteur. Nous avons préféré ce choix aux sockets du fait qu'un fichier,
en plus d'une grande taille, peut être accessible à n'importe quel tâche et à n'importe quel
moment. La mémoire partagée contient les requêtes que le programmeur envoie aux
processus. L'utilisation de la mémoire nous a permis de limiter le nombre de fichiers
ouverts par CDS, sachant que les multiples fenêtre sont vues comme des fichiers par le
système Unix.
•
Le format de transfert des données dans les sockets (ASCI) n'étant pas le même
que le binaire pur des transputers, une conversion est donc nécessaire.
c) Fluidité du transport.
Les observations sont transportées sans stockage à travers le moniteur. Une lenteur de
trafic des messages peut cependant résulter des délais de communication sur le bus (cf.
chap 3) et de l'encombrement du réseau Eternet. L'effet de la lenteur du bus peut être
minimisé en limitant la quantité de traces collectées. C'est pourquoi dans CDS, nous
avons mis l'accent sur l'observation en ligne.
Les traces et certaines vues sont automatiquement enregistrées par le moniteur interactif
dans des fichiers spéciaux sur la station de mise au point en attendant l'affichage. En cas
de saturation de ceux-ci, les traces sont automatiquement affichées dans une fenêtre
spéciale de l'interface graphique. Les vues liées aux dialogues sont stockées dans des
tables en mémoire sur la station puisque leur .nombre est limité et égal au nombre de
processus engagés dans des points d'arrêt locaux.
d) Minimisation des interférences et résolution des problèmes d'équité.
Les problèmes d'équité et les interférences du moniteur avec les processus utilisateurs
résultent du partage de ressources (voies de communications, CPU) et de l'accès au
moniteur :
•
Les voies de communications. L'utilisation du bus de contrôle permet d'éviter
toute interférence avec les communications du réseau principal du SuperNode, dédié aux
processus utilisateurs.
•
Partage du CPU. A défaut d'éviter l'interférence du moniteur avec les processus
utilisateurs pour le partage du CPU, une voie alternative est de rendre cette interférence
équitable à tous les processus. La solution que nous proposons est la suivante. Le
moniteur s'exécute en haute priorité, jusqu'à ce qu'il atteigne un point d'ordonnancement
136.
Chapitre 6.

---

(communication, choix gardé, timer); il passe alors en basse priorité. Après le point
d'ordonnancement, il revient en haute priorité. S'exécutant en haute priorité, le moniteur
ne peut pas être interrompu. Par conséquent, les processus de haute priorité ne sont plus
privilégiés. Comme le moniteur passe en basse priorité aux points d'ordonnancement, il
n'interrompt pas de processus de basse priorité autrement que par le mécanisme normal
d'ordonnancement du transputer (quantum de temps, file d'ordonnancement) qui est
supposé équitable.
•
Equité d'accès au moniteur interactif. Pour assurer l'équité d'accès au moniteur,
l'inscription des messages dans les PIFO du moniteur du bus (chap. 3) se fait par
tentatives successives, et les processus qui échouent (FIFO pleine) sont remis
systématiquement dans la file d'ordonnancement de basse priorité: plus aucun processus
n'est privilégié.
•
Estampillage. Un moyen efficace pour éviter l'écart entre la date d'occurrence
d'un événement et la date d'estampillage est d'exécuter la section de code correspondante
en haute priorité. Cependant, cela peut engendrer d'autres problèmes dont la modification
du comportement du programme. Nous avons également envisagé de procéder à une
double datation: il s'agit de lire l'heure avant et après l'occurrence de l'événement. Mais
ce mécanisme n'est pas plus satisfaisant. Nous avons donc assimilé la date d'occurrence
d'un événement avec la date d'estampillage.
e) Robustesse.
Etant donné qu'il n'y a pas de mécanisme de protection mémoire dans le transputer, ni
dans le système C_NET, il n'est pas possible de protéger efficacement le moniteur du
mauvais comportement des processus. Cependant, le transputer dispose d'un mécanisme
peek and poke [62] [63] permettant de lire et modifier sa mémoire à travers les liens.
Cela peut permettre de récupérer des données à la suite d'un incident logiciel. Ce
mécanisme ne garantit pas la fiabilité des informations ainsi collectées; mais il ne constitue
cependant pas moins une extension possible de CDS.
ll.3.2. Choix liés à la spécification des actions de mise au point.
Pour les raisons que nous avons déjà évoquées §I.3.1, comme dans bdb [129], nous
avons choisi de réaliser une bibliothèque de fonctions que le programmeur peut insérer
dans le code source pour préparer les observations. Ces fonctions prennent en compte les
problèmes de la section n.2.2.
137.
Chapitre 6.

---

a) Lisibilité et redondance.
TI Ya deux techniques pour assurer la lisibilité du code de mise au point. La première est
d'insérer les fonctions du SMAP automatiquement avec le compilateur comme dans [37]
[119]. Dans ce cas, ce code est transparent au programmeur. La deuxième technique
consiste à insérer ces fonctions dans des gestionnaires d'exceptions séparés du code des
processus [3] [94]. Ne disposant pas de ces deux possibilités dans notre environnement,
une lisibilité minimale est assurée par un nomage adéquat des fonctions de CDS. D'autre
part, seule la gestion des exceptions permet de réduire efficacement les redondances de
code de mise au point [94].
b) Facilité d'usage et efficacité.
Nous avons réduit le nombre des fonctions de CDS grâce à la paramétrisation. Par
exemple, une seule fonction permet de collecter les traces des événements, soit sans
bloquer le processus; soit en le bloquant jusqu'à l'inscription du message dans les FIFO
du moniteur (chap. 3); soit en bloquant le processus jusqu'à ce que le message soit
effectivement récupéré par le moniteur. Ce dernier cas de figure permet de récupérer les
traces de processus qui créent des pannes. De même, une seule fonction permet de gérer
les descripteurs de contexte des processus (PCD). Le défaut de la paramétrisation est que
l'appel des fonctions peut devenir fastidieux (trop de paramètres, polymorphisme des
fonctions). Nous avons donc également défini des macros pour simplifier l'appel de
certaines fonctions quand il était possible de passer certains paramètres automatiquement.
ll.3.3. Choix liés' à l'exécution.
Les processus utilisateurs communiquent avec le moniteur interactif à l'aide des
fonctions adéquates de CDS. Nous allons d'abord présenter les techniques de
communication que nous avons choisies de mettre en œuvre à l'intérieur de ces fonctions,
et ensuite, nous allons montrer comment ces techniques répondent aux problèmes posés
dans la section ll.2.3.
a) Techniques de communication avec le moniteur interactif.
Le transputer offre deux modes de communication entre processus: le partage mémoire et
les communications à travers des canaux internes. Nous avons examiné chaque type
d'échange de données (traces, messages entre transputers, vues, modification de
contexte) entre les processus utilisateurs et le moniteur pour déterminer lequel des deux
modes s'appliquait le mieux.
138.
Chapitre 6.

---

•
Collecte de traces. Les processus utilisateurs inscrivent les traces dans une FIFO
(fig. 4). Quand celle-ci est pleine, le processus peut soit essayer à nouveau en passant en
basse priorité (cf. §ll.3.1.b); soit abandonner la communication. Le choix d'une mémoire
partagée permet de minimiser le temps de communication : pas de transfert.
•
Transfert de messages entre processeurs. Les processus utilisateurs inscrivent les
messages destinés à d'autres processeurs, dans une FIFO (fig. 4) pour les mêmes raisons
qu'au point précédent. Chaque message est étiqueté du numéro ou de l'adresse du canal
sur lequel il sera livré par le moniteur au processus destinataire (cf. chapitre 3). Le
processus destinataire doit donc attendre une communication sur le canal en question. Ce
choix nous a permis de profiter du moyen efficace et simple offert par le transputer pour
mettre un processus en attente. Dans le système Mach [27] qui utilise la même technique,
à chaque processus est associé un canal spécial connu du moniteur, sachant que certains
processus peuvent ne pas s'en servir. Dans CDS, ces canaux sont encapsulés dans les
messages et sont invisibles aux processus utilisateurs.
User
Interactiv
process
monitor
Private channel
-Figure 4-
Communication entre processus utilisateurs et moniteur interactif.
IOther processesl
5
.<;:
=
o
a
~
l:s
User
process
-Figure 5-
Liste de descripteurs de contexte des processus.
•
Collecte des vues et modification du contexte des processus. La collecte des vues
et la modification du contexte d'un processus se font à l'aide du descripteur de contexte
(PCD) que le processus construit au début de l'exécution et inscrit éventuellement dans la
liste des PCD observables (fig. 5). Un PCD contient les variables internes, les canaux et
les variables système du processus. La liste des PCD est accessible au scanner et au
processus espion qui peuvent collecter des vues de processus sans les interrompre
autrement que par le mécanisme normal d'ordonnancement. Le PCD peut également être
passé 'en paramètre à la fonction de dialogue (point d'arrêt individuel) qui transmet alors
une vue du contexte du processus au programmeur, lequel la modifie, et la fonction
répercute ces modifications sur les variables correspondantes: c'est le changement de
139.
Chapitre 6.

---

contexte. Dans CDS, une seule structure,le PCD, permet de réaliser toutes les opérations
sur le contexte d'un processus.
b) Ordonnancement des processus.
La modification de l'ordonnancement des processus occasionnée par l'exécution des
fonctions de CDS ne peut être évitée qu'avec un moniteur matériel [26]. Certaines
fonctions de CDS sont cependant non-bloquantes. Le programmeur a également la
possibilité de se limiter à l'observation au scanner et au processus espion. Ce qui permet
de se passer des appels aux fonctions provoquant l'attente des processus, et par
conséquent de réduire la modification de l'ordonnancement. En effet, l'observation au
scanner et l'espionnage ne nécessitent que la création de PCD au début de chaque
processus à contrôler. Mais ce choix comporte les inconvénients de l'observation passive
que nous avons énoncés au chapitre 1.
c) Consistance du contexte.
Cette consistance concerne l'arrêt et la reprise d'exécution des processus. Nous avons
choisi de faire d'un point d'arrêt une fonction appelée par le processus utilisateur, ce qui
assure que celui-ci est toujours arrêté dans un état consistant au sens de Chandy-Lamport
[35] (voir chap. 5). Les variables inscrites dans les PCD sont modifiées compte tenu de
leur type; et les canaux de communication et variables système ne sont accessibles qu'en
lecture. Ces choix permettent d'assurer que le processus repart avec un contexte
consistant après l'arrêt.
d) Fiabilité des observations.
Un processus n'est observable au scanner ou par le processus espion que s'il a inscrit
son PCD dans la liste des PCD observables. On s'assure ainsi que le processus a
commencé à s'exécuter avant d'être observé. Par contre à la terminaison, le processus
doit retirer sa PCD de cette liste. Cette action ne peut être réalisée automatiquement
qu'avec le compilateur. Un PCD ne peut contenir que les variables simples; ce qui assure
qu'on n'accède pas à des variables partiellement mise à jour. La prise en compte des
tableaux et structures est un problème complexe. En effet, pour ne pas accéder à des
résultats partiels, il faut synchroniser le SMAP avec chaque processus utilisateur. Ce qui
rend le SMAP dépendant de ces processus. En outre, il faut que le programmeur
fournisse les fonctions d'accès à ces structures. Le programmeur peut cependant inscrire
les éléments de tableaux et structures individuellement dans le PCD, ou construire ses
propres processus d'observation.
140.
Chapitre 6.

---

Pour permettre d'observer les processus dans diverses situations, nous avons multiplié
les moyens de collecte des informations. D'une part, la fonction de trace possède trois
modes (non bloquante, bloquante jusqu'à l'inscription du message dans la FIFO,
bloquante jusqu'à la récupération du message par le moniteur). D'autre part, la fréquence
d'activation du processus espion peut être ajustée par n'importe quel processus. En outre,
le scanner permet d'observer n'importe quel processus inscrit. EnfIn, l'arrêt individuel ou
global sont autant des possibilités de collecte d'informations.
II.3.4. Choix liés à l'interface d'observation.
Pour réaliser l'interface graphique, nous avons choisi X-window logiciel graphique
standard Unix pour des raisons de portabilité. Nous avons étudié cette interface pour
répondre aux problèmes dégagés à la section II.2.4.
a) Format des observations.
La. spécifIcation du format d'affichage des traces se fait en même temps que leur collecte,
à l'aide d'une fonction semblable à printf. Nous avons renoncé à faire cette spécifIcation
au moment de l'observation du fait que cela nécessite de développer un langage spécial.
Mais faisant ce choix, nous nous sommes privés des avantages de la spécifIcation, dont la
possibilité de modifIcation du format d'affIchage et les fIltres. Nous avons choisi un
format fIxe (type, nom, valeur, adresse) pour la présentation des vues du fait qu'elles ne
comportent que des variables simples, les variables système et les canaux.
b) Restitution du parallélisme : affichage synchrone des traces.
Nous avons étudié cette restitution à la fois au niveau individuel et au niveau global. Au
niveau individuel (processus, processeur), les fenêtres sont gérées dynamiquement et
communiquent en permanence avec le moniteur interactif. Cela permet d'observer et
contrÔler simultanément un nombre quelconque de processus, et d'affIcher les
observations individuellement pour chaque processeur ou chaque processus.
Au niveau global, nous avons étudié une technique d'affichage permettant au
programmeur d'observer le déroulement de l'exécution de plusieurs processeurs en
parallèle sur plusieurs fenêtres. La. solution que nous avons trouvée consiste à trier les
événements suivant l'heure globale et par processeur; et à choisir un processeur de
référence de sorte qu'en faisant avancer l'affIchage pour ce processeur, l'affIchage des
événements des autres processeurs s'alligne sur celle-ci: c'est l'affichage synchrone des
traces. Pour la mise en œuvre, il faut concevoir les fenêtres de sorte que le programmeur
puisse attacher une fenêtre de trace à un ou plusieurs processeurs. Cette technique est une
141.
Cluipitre 6.

---

alternative à l'exécution pas à pas qu'il n'est pas toujours facile de réaliser sur les
machines parallèles.
c) Filtrage.
En général, le fùtrage se fait par spécification des événements qu'on veut observer. Cela
nécessite un langage de spécification de modèles d'événements. Nous avons choisi une
solution plus simple qui permet d'éliminer un nombre non négligeable d'événements :
l'élimination se fait par processeur et par date. Pour cela, chaque fenêtre de visualisation
des traces est affectée dynamiquement à un ou plusieurs processeurs, de sorte qu'elle ne
fasse apparaître que les traces de ces processeurs. De plus, le programmeur peut ftxer une
date donnée de l'horloge globale comme point début de l'afftchage.
III. Mise en œuvre de CDS.
La mise en œuvre de CDS suit les choix analysés dans partie II, complétés des choix de
programmation système. Cette partie présente cette mise en œuvre. Elle décrit
l'architecture de CDS et montre comment les différentes fonctionnalités de la section 1.3.2
ont été réalisées. Cette partie décrit CDS d'un point de vue système.
111.1. Architecture de CDS.
III, 1.1. Moniteur interactif.
n est mis en œuvre comme un ensemble de processus (processeurs) et de tâches (Unix)
pour la collecte, le transport et la gestion des observations. C'est un système distribué
composé de trois parties : moniteur du SuperNode; interface de communication
s'exécutant sur la carte frontale et le serveur du réseau LIP; gestionnaires des
observations s'exécutant sur la station de mise au point (fig. 6).
a) Le moniteur du SuperNode.
C'est à la fois une extension du moniteur du bus de contrôle (chap. 3) et un ensemble
de processus permanents résidant sur chaque processeur de travail :
•
Extension du moniteur du bus. En plus du fonctionnement décrit au chapitre 3,
le moniteur véhicule les observations de mise au point, et assure la synchronisation des
horloges suivant l'algorithme probabiliste (chapitre 4) et le transport des informations
de gestion des point d'arrêt globaux. Le moniteur du bus communique avec tous les
autres processus du moniteur interactif résidant sur chaque TI (fig. 6).
142.
Chapitre 6.

---

t
Observation dispatcher & collector
bservation mllMger
LDebugging w~ke~ta:'on
1
SuperNode
Network
la
input relay
server
li
I~
1
1
-Figure 6-
Architecture de CDS (moniteur interactif + interface graphique).
•
Timer. C'est un processus qui régulièrement, au terme de la période de
synchronisation, envoie un signal au moniteur du bus pour que celui-ci synchronise
son horloge avec le processeur de contrôle. Son algorithme est décrit en annexe 3.
143.
Chapitre 6.

---

•
Gestionnaire de points d'arrêt. C'est le processus de gestion des prédicats et des
points d'arrêt dont l'algorithme est donné en annexe 5. TI communique avec le moniteur
du bus pour recevoir les requêtes de modification des prédicats et de génération des
points d'arrêt. Certaines requêtes peuvent venir du programmeur et sont diffusées par le
moniteur du bus à partir du processeur de contrôle.
•
Scanner. TI sert à collecter les vues des processus à la demande du programmeur.
Il reçoit du moniteur du bus sur un canal interne, les requêtes
envoyées par le
programmeur, et selon le type, il transmet à ce moniteur la liste des PCD inscrits ou une
vue des PCD que le programmeur veut observer.
•
Espion. li sert à collecter périodiquement les vues des processus. Ce processus
parcourt régulièrement la liste des PCD, et en collecte des vues qu'il transmet au moniteur
du bus. TI peut être activé ou désactivé par n'importe quel processus utilisateur, ou par le
programmeur à travers l'interface graphique. De même sa fréquence d'activation peut être
ajustée par les processus utilisateurs ou le programmeur.
•
Processus utilisateurs. lis accèdent au moniteur du bus à l'aide des fonctions
adéquates de CDS. Les processus observables au scanner et par l'espion doivent inscrire
leurs PCD dans la liste d'observation. Ces processus peuvent également valider les
prédicats et participer à l'arrêt global comme décrit au chapitre 5.
b) Interface de communication.
Cette interface réalise les fonctions du CIO : elle sert à véhiculer les observations entre le
SuperNode (moniteur du bus) et la station de mise au point. Elle est composée de deux
parties. Sur le processeur de la carte frontale, un premier processus sert à recevoir les
observations émises par le SuperNode et à les transmettre au serveur du réseau; un
second fait l'opération inverse. Sur le serveur du réseau, une première tâche Unix reçoit
les observations venant du frontal et les transmet à la station de mise au point; une
seconde fait l'opération inverse. La communication entre le serveur et la station a lieu à
travers deux sockets, alors qu'entre le serveur et le frontal, ce sont des communications
entre les liens du processeur frontal et le bus VME du serveur.
c) Moniteur de gestion des observations.
Ce sont cinq tâches Unix qui s'exécutent sur la station de mise au point, destinées à gérer
les observations. Elles communiquent entre elles et l'interface du serveur à travers des
sockets, et avec l'interface graphique à travers des fichiers et une méoire partagée, pour
l'échange de ces observations.
144.
Chapibe 6.

---

•
Distributeur-collecteur des observations. Cette tâche reçoit les observations venant
du serveur et selon le type, les distribue aux différents gestionnaires. Elle inscrit les traces
et les vues dans des fichiers spéciaux, ce qui permet de disposer à tout moment de
l'historique de l'exécution. En retour, elle reçoit de ces gestionnaires les messages
destinés au SuperNode, et les transmet au serveur.
•
Gestionnaire de traces. nsert à trier les traces suivant l'heure globale et le numéro
de processeur. Il est également chargé de créer les tâches des fenêtres de traces de
l'interface graphique, et de coordonner l'affichage dans ces fenêtres.
•
Gestionnaire de dialogues. n gère les vues de tous les processus engagés dans des
points d'arrêt individuels; vues qu'il reçoit du distributeur. Ce gestionnaire est également
chargé de créer les tâches des fenêtres de dialogue, et de leur communiquer les vues
associées. A la fm de chaque dialogue, le gestionnaire récupère les variables modifiées et
les transmet au collecteur.
•
Gestionnaire de vues. n est chargé de coordonner l'affichage des vues dans les
fenêtres de l'interface graphique et de créer les tâches des fenêtres d'affichage de ces
vues.
•
Gestionnaire des informations de contrôle. Cette tâche reçoit les commandes du
programmeur à travers l'interface graphique, et compose les messages de contrôle
correspondant qu'elle transmet au collecteur. n s'agit des commandes adressées aux
scanners, aux processus espions, et aux gestionnaires de points d'arrêt, et des messages
destinés aux processus utilisateurs. Cette tâche adresse à l'interface graphique les
messages de contrôle que lui transmet le distributeur : erreurs système, événements temps
réels signalés par les processus utilisateurs.
ill.I.2. Interface ifaphique
Son rôle est de présenter les observations au programmeur et de recevoir les requêtes de
celui-ci, destinées aux processus s'exécutant sur le SuperNode. Elle offre quatre types de
fenêtres (fig. 6) : contrôle, traces, vues et dialogues. L'interface graphique s'exécute sur
une station de travail XII. Elle est réalisée avec X-window, et permet de tirer pleinement
partie des outils de manipulation des fenêtres d'Openwindow. A chaque fenêtre est
associée une tâche servant à la fois à l'affichage et à la communication avec les
gestionnaires.
145.
Chapitre 6.

---

~
CDS
GRAPHICAL INTERFACE
(Quit CDS) (Open trace win.) (Open view win. )(Get transp. stateJ transp --.Œl
(He1p )
(Dialogue list)(Open dialog. win) num.
@.EŒ)OScanno-
!D'jI Œ)OSpy
mm
(Enab. globo bpoint) Val ----Ill]
(SPEB)
(SetpredicAte)
CDS%
CDS%
CDS%
1
A.Fenêtre de contrôle.
-
.....,
CDS
DIALOGUE <Transputer xx> <label> my process name
I!J
(Dooe )( Clear ) ( DiplayaIl ) ( Show ) ( Syst. var. ) ( Save) ( Help )
Digit input: ----IAI!l Text input:
Process variable names
Display Panel
Oc. user channel
-
1 s. string variable
2 B. Byte variable
3 S. Short variable
41. 1nteger variable
5 L. Long variable
~
6 D. Double variable
I~
...
N ...
B. Fenêtre de dialogue.
....
...
CDS TRACE DISPLAy WINDOW 6
I!J
Cuïù (Hep) (PlaY back) ŒU (Mode S~ 0 0 Trace Trans. ----.WEI
(Next step) Val.----iŒI
0 0 RDV with win.--..JE] at:-.mfl
(Halt at)
time: --.m (Mask)
( List sm)
~ sm win. num.
rgJ
~
Il
~ il
C. Fenêtre de traces.
..-
...
CDS VIEW DISPLAY WINDOW 4
m
Cuïù CNex0 (Nextview) (FindPid ) (FiDd Pdesc ) (Fmdview) (He)
Transp.
U2I
Proc. identifier ----lEI
Proc. descriptior
Il
D. Fenêtre de vues.
-Figure 7-
Fenêtres de l'interface graphique de CDS.
146.
Chapitre 6.

---

•
Fenêtre de contrôle (fig. 7A). Elle remplie plusieurs rôles. Elle sert à
commander l'ouverture des autres fenêtres, et à afficher en temps réelles messages
système (e.g. erreurs) et les événements arrivant du gestionnaire des informations de
contrôle. C'est à travers elle que le programmeur compose les commandes destinées aux
scanners et aux espions, ainsi que les données destinées à certains processus, et les
requêtes de collecte de l'état global de chaque processeur. Cette fenêtre communique avec
les gestionnaires de traces, de dialogue, de vue, et de contrôle pour commander
l'ouverture des fenêtres à la demande du programmeur. Enfin, en cas de saturation des
fichiers de traces et de vues, celles-ci sont automatiquement affichées dans cette fenêtre.
•
Fenêtres de dialogue (fig. 7B). Une fenêtre de dialogue permet au
programmeur de modifier le contexte d'un processus engagé dans un point d'arrêt
individuel. La fenêtre présente une vue du contexte du processus (variables système et
locales, canaux). Le programmeur n'est autorisé à modifier que les variables locales du
processus. TI peut sauvegarder une vue du dialogue qui pourra ensuite être examinée
comme une vue émise par le processus. Cela permet au programmeur de constituer une
historique des dialogues qu'il a tenu avec les processus. A la fm du dialogue la tâche
associée transmet au gestionnaire de dialogue les variables qui ont été modifiées.
•
Fenêtres d'affichage de traces (fig. 7C). Le programmeur peut en ouvrir
autant qu'il veut. A une fenêtre peuvent être associés dynamiquement plusieurs
processeurs dont cette fenêtre affichera les traces. Ces traces peuvent être manipulées
avec Openwindow (recherche de chaîne de caractères, balayage, etc...). Cette fenêtre met
en œuvre la technique d'affichage synchrone des traces.
•
Fenêtres d'affichage des vues (fig. 7D). Le programmeur peut en ouvrir à
son gré. Chaque fenêtre présente l'ensemble des variables locales et système et le statut
des canaux au moment de prise de la vue, ainsi que l'identité du processus auquel elle
appartient. Les vues sont affichées les une après les autres soit par processeur, soit par
processus, soit par ordre d'occurrence. Le fait d'ouvrir plusieurs fenêtres simultanément
permet d'observer l'état du système relativement à l'heure globale. Les vues résultant de
dialogues sont traitées de la même façon que les vues des processus.
m.1.3. Bibliothèque de fonctions.
La bibliothèque de CDS comporte cinq types de fonctions :
•
Fonctions de traces. TI y en a deux. L'une permet de générer des messages qui
sont affichés automatiquement dans la fenêtre de contrôle pour signaler l'occurrence des
147.
Cbapilre 6.

---

événements en temps réel. La deuxième est semblable à print! Elle permet la collecte de
traces qui sont affichées dans des fenêtres spécifiques.
•
Fonctions de manipulation de contexte de processus. li y en a deux. L'une sert à
créer un PCD, à la supprimer et à l'inscrire dans la liste des PCD observables. Elle inscrit
automatiquement les variables système relatives à la pile d'exécution; les autres sont
déduites d'un paramètre de la fonction (taille et adresse de l'espace de travail, adresse de
chargement, nombre de paramètres du processus). La deuxième fonction sert à inscrire et
retirer les variables, et les canaux dans le PCD.
•
Fonctions de points d'arrêt. li y a deux types. Le premier sert à l'arrêt global. Ce
sont les fonctions de manipulation des prédicats et d'arrêt global décrites au chapitre 5. Le
deuxième type est une fonction de dialogue servant à l'arrêt individuel des processus. Elle
prend en paramètre un PCD, dont elle prend une vue et la transmet au moniteur du bus.
Elle se termine après avoir modifié le contexte du processus conformément au contenu du
PCD et aux choix du programmeur.
•
Fonctions de communication entre transputers. li y en a deux. L'une sert à
l'émission simple ou à la diffusion de messages d'un processus vers les transputers.
L'autre sert à recevoir un message diffusé ou émis par autre processeur ou par le
programmeur à travers la fenêtre de contrôle de l'interface graphique. La reception se fait
à travers un canal prédéfini du moniteur interactif, ou un canal du processus dont le
message porte l'étiquette.
•
Fonctions diverses. Une fonction permet de modifier la fréquence d'activation du
processus espion. L'accès à l'horloge se fait par la fonction usuelle du C de Logical
Systems [82]. L'estampillage des événements est réalisé automatiquement par les
fonctions de CDS. L'horloge globale peut être désactivée ou re-activée à l'aide de deux
macros fonctions.
Ill.2. Mise en œuvre des fonctionnalités de CDS.
Dans cette section, nous décrivons comment les différentes fonctionnalités de CDS ont
été implémentées. Nous présentons d'une part les algorithmes de certaines de ces
fonctionnalités, et d'autre part certains choix de programmation système. Cette section
décrit le fonctionnement de CDS du point de vue système.
148.
Chapitre 6.

---

m.2,t. Les traces.
Cette section décrit la mise en œuvre de la gestion des traces: de la collecte jusqu'à
l'affichage. Elle montre également comment certains points spécifiques ont été
implémentés (communication entre fenêtres ou entre un gestionnaire et une fenêtre).
a) Collecte, transport et gestion des traces.
Les traces sont collectées à l'aide des fonctions CDS_event (traces d'événements de
première importance qui doivent être affichées en temps réel) et tprintf(traces ordinaires).
La fonction tprintf a trois modes de fonctionnement (cf. §II.3.2.b). Dans le troisième
mode, après avoir inscrit le message dans la FIFO, le processus se suspend. TI est réveillé
par le moniteur du bus après que celui-ci ait transmis sur le bus.
Ces deux fonctions estampillent automatiquement les traces avec l'heure globale, et le
moniteur les étiquette du numéro du processeur émetteur, puis les véhicule jusqu'au
distributeur de la station de mise au point. Celui-ci l'inscrit dans le fichier de traces, et s'il
s'agit d'un événement impératif, il envoie une copie du message au gestionnaire des
informations de contrôle. Quand le fichier des traces est plein, le distributeur affiche les
messages arrivant dans la fenêtre de contrôle qu'il voit comme un fichier ouvert en
écriture.
b) Affichage en temps réel.
Le gestionnaire des informations de contrôle voit la fenêtre de contrôle (fig. 7A) comme
un fichier ouvert en écriture. TI y inscrit (affiche) les messages de traces que lui transmet
le distributeur. Ce qui permet de suivre en temps réelle déroulement du programme.
Nous avons mis en œuvre une deuxième méthode pour suivre le déroulement en pseudo
temps réel qui consiste à ouvrir une fenêtre de traces (fig. 7), à lui associer les
processeurs dont on veut suivre l'exécution, et à activer la commande d'affichage
automatique de la fenêtre. Cette commande communique le nom de la fenêtre au
gestionnaire des traces qui la voit alors comme un fichier qu'il ouvre en écriture. TI lit les
traces en permanence et les affiche dans les fenêtres correspondantes. Pour déterminer
quel processeur est associé à quelle fenêtre, le gestionnaire des traces partage une
mémoire commune avec chaque fenêtre, dans laquelle celle-ci inscrit ses attributs.
c) Affichage différé.
L'utilisateur peut ouvrir une fenêtre de traces (fig. 7C) et lui associer dynamiquement un
nombre variable de processeurs. Chaque fenêtre est en fait une tâche Unix. Cette tâche lit
149.
Chapitre 6.

---

le fichier des traces, sélectionne les traces des processeurs associés et les affiche soit pas
à pas, soit jusqu'à atteindre une date indiquée par le programmeur.
d) Affichage synchrone des traces.
Le programmeur peut désigner une fenêtre de traces (fig. 7C) comme pilote et lui asservir
d'autres fenêtres de traces. La tâche associée à la fenêtre pilote voit les fenêtres asservies
comme des fichiers qu'elle ouvre en écriture. De plus comme toutes les fenêtres partagent
une mémoire commune indiquant les attributs de chacune, la tâche pilote sait donc
déterminer quels processeurs sont associés à chaque fenêtre. Elle lit alors le fichier des
traces et affiche les messages dans les fenêtres adéquates. Comme les traces sont datées et
que les messages sont numérotés à l'affichage, le pilote met en correspondance les
numéros dans chaque fenêtre avec les numéros de la fenêtre pilote indiquant que ces
événements sont simultanés au sens de l'horloge globale.
L'affichage progresse soit pas à pas, soit jusqu'à ce qu'un événement portant une date
indiquée par le programmeur ait été atteint. Le pas est atteint quand l'une des fenêtres
synchronisées a atteint le nombre de traces indiqué par la valeur de pas de la fenêtre
pilote. Notre technique permet d'avoir simultanément plusieurs pilotes en même temps.
m.2.2. Construction et &estion des descripteurs de contexte des processus.
Le descripteur du contexte d'un processus est une structure composée d'un ensemble de
flags indiquant l'état d'utilisation de la structure, une liste de variables et de canaux, et
des pointeurs sur les variables système, qui constituent le contexte du processus.
struct CDS_st....pcd {
char
*label;
/* user defmed identifier */
int
num;
/* CDS internai identifier */
int
*pdesc;
/* Process descriptor */
int
mode;
/* Access mode: scanner, spy or both */
int
state ;
/* Set by the user for view colleting */
int
busy;
/* Indicate if the PCD is free or in use */
int
*ws;
/* process work space */
CDS_scvaclist *var_list ;
/* list of variables and channels */
CDS_PT""pcd
next ;
}
Deux fonctions permettent de gérer un PCD :
•
La fonction CDS _hycd dont l'algorithme est donné ci-dessous permet la
création d'un PCD, ainsi que sa suppression, et son insertion dans la liste des PCD
observables. Le descripteur du processus passé en paramètre à cette fonction, permet par
la suite d'accéder aux données suivantes: adresse de chargement; pointeur de l'espace de
travail; taille de cet espace; nombre de paramètres du processus. Un PCD a deux
identificateurs. Le premier est un label passé en paramètre qui permettra au programmeur
d'identifier les vues issues de ce PCD. Le deuxième identificateur est un numéro d'ordre
ISO.
Cbapitn: 6.

---

affecté automatiquement par la fonction, qui, associé au numéro de processeur, permet
lors de l'affichage de retrouver toutes les vues issues d'un PCD. Lors de la suppression
d'un PCD, il est automatiquement retiré de la liste des PCD observables. Si ce PCD est
en cours d'utilisation par le scanner ou l'espion, ceux-ci sont avisés à travers le flag
adéquat du PCD, et la suppression est retardée jusqu'à ce que ces deux processus
interrompent la lecture. Lors de l'inscription du PCD dans la liste, le processus peut
spécifier si ce descripteur est accessible au scanner, à l'espion, ou aux deux en même
temps.
CDS_P'fR...,pcd CDS_h_pcd (char code, CDS_P'fR...,pcd p, char* label, Process* pdesc, int mode) {
int
*ws, prio ;
char
*msg;
CDS_P'fR...,pcd
q ;
switch (code) {
/* create a PCD */
case CREATE_PCD:
if (!(q = (CDS...,pt...,pcd) malloc (sizeof (CDS_ST...,pcd))))
return 0 ;
if (!(q->label = (CDS...,pt...,pcd) malloc (strlen (label) + 1»» {
free (q) ;
retum 0;
}
strepy (q->label , label) ;
q->num
= CDS_PCD_NUM++ ;
q->var_list
=NULL;
q->pdesc
= pdesc ;
q->mode
= 0;
q->stat
= 0;
q->busy
= 0;
q->ws
= 0;
q->next
= 0;
retum q;
/* Delete a PCD */
case DELE1E_PCD :
if(p=NUlL)
retum 0;
prio
= ProcToHigh () ;
if (p->busy > 0) {
/* PCD in use by the scanner or the spy */
p->busy-- ;
/* i.e : PCD to be removed */
/* Get process workspace pointer */
#pragma asm
lDLP
0
sn..
[ws]
#pragma endasm
p->ws
=ws;
/* Stop until the scanner or the spy releases the PCD */
#pragma asm
sropp
#pragma endasm
}
eds_remove_from...,pcd_list (P) ;
free (p->label) ;
free (p) ;
if (prio)
ProcToLow 0 ;
retum 0;
/* Insert p in the PCD list */
case INSERT_PCD :
if(p=NULL)
return 0;
151.
Chapibe 6.

---

prio
= ProcToHigh 0 ;
p->next
= CD-pc(Uist ;
CD-pc(Uist
=p;
p->mode
= (int) mode;
if (prio)
ProcToLow 0 ;
return 0 ;
/* Remove p from the PCD list */
case REMOVE_PCD:
if(p=NUU.)
return 0 ;
prio
= ProcToHigh 0 ;
if (p->mode) {
if (p->busy ) {
/* PCD in use by the scanner or the spy */
p->busy-- ;
/* i.e: PCD to he removed */
/* Get process workspace pointer */
#pragma asm
illU>
0
sn..
[ws]
#pragma endasm
p->ws
=ws;
/* Stop until the scanner or the spy releases the PCD */
#pragma asm
sropp
#pragma endasm
}
remove3rom-pc(Uist (p) ;
}
if (prio)
ProcToLow 0 ;
rebJrn 0 ;
default :
return 0 ;
•
La fonction CDS_vycd permet d'inscrire ou retirer les variables et les canaux de
la PCD. Une variable est défInie par son type, son nom et son adresse; ~t un canal par
son nom et son adresse. Les variables de type chaîne de caractères sont supposées se
terminer par le caractère '\\D'.
m.2.3. Mise en œuvre des points d'arrêt individuels: les dialOilles.
a) Dialogue du côté du processus utilisateur.
Un processus entre dans un point d'arrêt individuel en exécutant la fonction
CDS_dialogue. C'est un protocole de communication entre le processus et le moniteur du
bus. Ce protocole est présenté par l'algorithme ci-dessous. TI se divise en deux phases:
•
Collecte et émission d'une vue du contexte d'un processus. Dans la fonction de
dialogue, le processus a un canal interne dont l'adresse sert d'étiquette aux messages de
dialogue. Le processus construit un message entête avec le label du dialogue, qu'il
transmet au moniteur du bus. Ensuite, il parcourt le PCD et construit un message pour
chaque variable (adresse, type, nom, valeur) et chaque canal (adresse, nom, état) qu'il
communique au moniteur. Puis il construit un message système avec le pointeur de
152.
Chapitre 6.

---

l'espace de travail Wptr. Enfm, si le descripteur du processus a été associé au PCD, un
message de fm est composé avec les éléments de ce descripteur, sinon, c'est un message
vide de fin qui est transmis au moniteur.
•
Modification du contexte. Le processus se met sur le canal interne en attente des
modifications effectuées par le programmeur. Pour chaque message qu'il reçoit, le
processus modifie la variable correspondante en lui affectant la valeur portée par le
message. La fonction de dialogue se termine en recevant un message vide. Le processus
reprend alors son cours normal.
void CDS_dialogue ( CDS_PT...,pcd p. char· label) {
int
*ws. sz ;
char
bufl256] ;
Channel
ch = NOPROCESS ;
mS_PT...,pcd
q;
'*
*'
get process workspace pointer
.
#pragma asm
I..I>Œ
0
SIL
[ws]
#pragma endasm
1* View collecting *1
sz
= compose_header_msg (buf. &ch, label) ;
mS_poST (sz. buf. DIALOGUE_LABEL) ;
q
=p;
while (q) {
sz
= compose_variable_or_channel_msg (buf. &ch. q->pte_elem) ;
ms_poST (sz. buf. DIALOGUE_VAR_OR_CHAN) ;
q
= p->next;
}
sz
= compose_system_variable_wptr (buf. &ch. ws) ;
ms_poST (sz. buf. DIALOGUE_SYST) ;
if (q->ptc...,process_desc)
sz
= compose_system_variable...,pdesc (buf. &ch. q->pte...,pdesc) ;
else
sz
= compose_empty_msg (buf. &ch) ;
ms_poST (sz. buf. DIALOGUE_ENO_OF_PCD);
1* Reception and Contexte modification *1
while (sz = ChanInInt (&ch» {
ChanIn (&ch. buf. sz) ;
modify_variable (buf. sz) ;
}
b) Dialogue du côté du moniteur et de l'interface graphique.
Les messages émis par le processus sont récupérés par le moniteur du bus et transmis au .
gestionnaire de dialogue de la station de mise au point. Celui-ci en recevant le message
entête, crée une table dans laquelle il inscrit tous les autres messages identifiés par le
numéro du processeur et l'adresse du canal dont ils sont étiquetés. En recevant le
message de fin de PCD, le gestionnaire affiche un message dans la fenêtre de contrôle
pour indiquer au programmeur qu'un processus est en mode dialogue. Le programmeur
153.
Chapitre 6.

---

peut alors ouvrir une fenêtre de dialogue pour ce processus en adressant une requête au
gestionnaire.
Le gestionnaire en recevant une requête d'ouverture de dialogue (fig. 7B) de l'interface
graphique, crée une tâche et lui transmet la vue correspondant à la requête. Cette tâche
ouvre la fenêtre de dialogue qui présente la vue. Le programmeur peut alors la modifier et
éventuellement en garder une copie. A la fm du dialogue, la tâche transmet les variables
modifiées au gestionnaire avant de se terminer. Ces variables sont ensuite acheminées
jusqu'au moniteur du bus qui les transmet au processus à travers le canal interne dont
chaque message porte une étiquette.
m.2.4. Le scanner.
Cette section décrit comment le scanner est mis en œuvre, et comment il est adressé à
partir de l'interface graphique.
a) Le processus scanner.
C'est un processus qui s'exécute sur chaque processeur de travail. li est construit autour
du protocole de dialogue et fonctionne selon l'algorithme ci-dessous. TI attend une requête
du programmeur livrée par le moniteur du bus sur un canal prédéfmi. Ensuite, il parcourt
la liste des PCD observables, et inscrit dans son propre PCD le label et l'indicateur d'état
de chacune des PCD observables au scanner. Puis il appelle la fonction de dialogue avec
le PCD ainsi construit. Enfin, le scanner parcourt à nouveau la liste des PCD observables
et collecte une vue de chaque PCD ayant un s,tatut non nul: c'est à dire les PCD pour
lesquels le programmeur a modifié la variable correspondante lors d'un dialogue. Le
scanner revient à l'état d'attente, après avoir envoyé un message au moniteur du bus
destiné à indiquer au gestionnaire des informations de contrôle qu'il est prêt à recevoir
une nouvelle requête.
Le fait que pour la collecte des vues, le scanner parcourt à nouveau la liste des PCD au
lieu d'utiliser directement le PCD qu'il a construit permet de s'assurer qu'il n'accède pas
à un PCD qui a été détruit pendant que le programmeur spécifiait les PCD à observer. A
l'intérieur de la fonction de collecte de vue, le test du statut du PCD permet d'abandonner
la prise de vue si ce PCD est en cours de destruction.
CDS_scanner (Process* pr, Channel* ch) {
int
sz ;
char
bufI256] ;
CDS_PT...J>cd
p, q ;
CDS_PT...J>cd_list
pl ;
p
=CDS_h...J>cd (CREATE, 0, 0) ;
RJREVER.{
ProcToLow 0 ;
154.
Chapitre 6.

---

ChanInInt (ch) ;
/* wait for user request from the bus monitor .,
pl
=CDS..j)C<Uist ;
ProcToHigh 0 ;
/* insert user PCD labels as variables in the scanner PCD .,
while (pl) {
if «(Pl->ptc->mode = SCANNER) Il (pl->ptc->mode = SCAN_SPY) {
pl->ptc->stat
=0 ;
CDS_v.J)cd (P. pl->ptc->stat. pl->ptc->label. CDS_CODE_INT);
}
pl
= pl->next;
}
/* Enable dialogue protocol in which the programmer is .,
/* requested to specify PCD whose veiws must be collected .,
CDS_dialogue (P. "Scanner") ;
pl
= CDS...Pcd_list ;
/* Collecting PCD views .,
while (Pl) {
if «pl->ptc->stat != 0) && «pl->ptc->mode = SCANNER)
Il (pl->ptc->mode = SCAN_SPY)) {
pl->ptc->stat
=0 ;
pl->ptc->busy++ ;
CDS...gecview (pl->ptc) ;
pl->ptc->busy-- ;
if (pl->ptc->busy < 0) {
/* restart user process to remove the PCD .,
#pragma asm
LDL [pl->pcd->wptrl
RUNP
#pragma endasm
}
}
pl
=pl->next ;
}
reset.J)cd (P);
/* Reseting the scanner PCD .,
CDS_POST (O. O. SCANNER_IS_FREE) ;
}
b) Adressage du scanner.
Une commande spéciale de la fenêtre de contrôle (fig. 7A) permet au programmeur
d'envoyer une demande de collecte de vues à un scanner quelconque ou à tous. Le
gestionnaire des informations de contrôle récupère cette commande et vérifie si
l'indicateur du scanner du processeur concerné est positionné (donnée locale au
gestionnaire). Si oui, il ignore la commande: le scanner est occupé avec une observation
en cours. Sinon, il positionne cet indicateur et envoie la commande au moniteur du bus.
Sur le processeur de contrôle, cette commande est soit diffusée, soit transmise au
processeur destinataire. Le moniteur du bus local au processeur de travail transmet cette
commande au scanner par un canal spécial. Celui-ci peut alors démarrer le dialogue
comme décrit plus haut. Lors du dialogue, le programmeur indique les pcn pour
lesquels il veut prendre une vue. Ces vues collectées par le scanner sont enregistrées dans
un fichier spécial par le distributeur de la station de mise au point. Quand le gestionnaire
reçoit un message de libération du scanner, il dépositionne l'indicateur associé. Toute
155.
Chapitre 6.

---

demande d'accès au scanner d'un processeur donné est rejetée si ce scanner est encours
de prise de vues. Ce qui permet d'éliminer les demandes superflues.
111.2.5. L'espion.
Un processus espion s'exécute sur chaque processeur de travail. TI fonctionne par cycle
selon l'algorithme ci-dessous. A chaque cycle, il parcourt la liste des PCD observables et
collecte une vue de chaque PCD pour lequel l'espion est autorisé à prendre une vue. La
variable contenant la période de l'espion peut être modifiée par n'importe quel processus
avec la fonction CDS _set_spy_time dont l'algorithme est donné ci-dessous. Le
programmeur peut lui aussi modifier cette variable pour un ou tous les espions à l'aide
d'une commande adressée au gestionnaire des informations de contrôle. C'est le moniteur
du bus du processeur de travail qui modifie effectivement la variable. Pour arrêter
l'espion, il suffit de lui donner une valeur de temps nulle.
/* Spy process */
CDS_spy (Process* pr) {
int
*ws;
CDS_PT-pc(Uist
pl;
/* get process workspace pointer */
.
#pragma asm
lDlP
0
SIL
[ws]
#pragma endasm
fQREVER{
. if (CDS_spy_tîme) {
ProcToLow 0 ;
ProcWait (CDS_spy_tîme) ;
ProcToHigh 0 ;
pl
=CDS-pcd_list ;
/* Collecting PCD views */
while(pl) {
if «Pl->ptc->mode = SPY) Il (pl->ptc->mode == SCAN_SPY» {
pl->ptc->busy++ ;
CDS~eCview (pl->ptc) ;
pl->ptc->busy--;
if (pl->ptc->busy < 0) {
/* restart user process to rernove the PCD*!
#pragma asm
LDL [pl->pcd->wptr]
RUNP
#pragma endasm
}
}
pl
= pl->next ;
}
else {
/* Stop the spy process*!
156.
Chapitre 6.

---

#pragma asm
STOPP
#pragma endasm
}
1* Function to set the spy time and eventually to restart the spy ""
void CDS_seCspy_time (int time) {
int
prio ;
prio
=ProcToHigh 0 ;
CDS_spy_time
= time ;
if (CDS_spy_stop && CDS_spy_time) {
CDS_spy_stop
= 0;
1* restart the spy process ""
.
#pragma asm
LDL [CDS_spy_wptr]
RUNP
#pragma endasm
}
if (prio)
ProcToLow 0 ;
m.2.6. Gestion des vues.
Au fur et à mesure de leur collecte par le scanner, l'espion, les processus utilisateurs ou le
programmeur à partir des fenêtres de dialogue, les vues sont acheminées jusqu'au
distributeur de la station de mise au point qui les enregistre dans un fichier spécial.
Comme dans le cas du dialogue, une vue est composée d'une entête identifiant la vue, des
messages relatifs aux variables internes et aux canaux du processus, d'un message
décrivant l'espace de travail du processus, et d'un message de fin contenant
éventuellement le descripteur du processus. Chaque vue est identifiée par: le numéro de
processeur, l'identificateur associé par le programmeur au processus, le numéro d'ordre
du PCD, et la date de collecte de la vue. Ce sont autant de critères suivant lesquels le
programmeur peut faire progresser l'affichage des vues à travers les fenêtres adéquates
(fig. 70). Chaque tâche associée à une fenêtre de vues accède directement au fichier des
vues. Ce qui permet d'afficher les vues parallèlement à leur collecte.
m.2.7. Communication entre processeurs.
Deux fonctions permettent aux processus utilisateurs d'envoyer des messages et à
d'autres de les recevoir à travers le bus (chapitre 3). Une commande de la fenêtre de
contrôle permet au programmeur d'envoyer un message à un seul ou à tous les
processeurs de travail. Le message est récupéré par le gestionnaire des informations de
contrôle et transmis au moniteur du bus du processeur de contrôle, lequel le communique
157.
Chapitre 6.

---

au processeur de travail adéquat ou le diffuse à tous. Le message est alors livré à travers
un canal prédéfIni.
IV. Extensions.
IV.I. Analyse de l'état des processus après une panne logicielle.
Le processeur possède un mode permettant d'accéder à la mémoire interne et externe.
Nous allons décrire comment ce mécanisme fonctionne et proposer une utilisation
possible pour déterminer l'état des processus après une panne logicielle.
IV. 1.1. Interroption de la mémoire d'un transputer (Peek and poket
Quand le transputer est placé en mode boot from link [63], sa mémoire peut être
interrogée et modifiée à partir de n'importe quel lien. Pour écrire une donnée dans la
mémoire, il faut envoyer 9 octets sur un lien: le premier octet vaut 0 (écriture); les 4
octets suivants indiquent l'adresse en mémoire où doivent être inscrits les 4 derniers
octets (donnée). Pour lire une zone mémoire, il faut d'abord envoyer 5 octets: le premier
vaut 1 (lecture) et les 4 suivants indiquent l'adresse à lire. Le transputer lit 4 octets à
l'adresse indiquée, et les envoie sur le même lien. Le transputer reste dans ce mode
jusqu'à ce qu'il reçoive un premier octet supérieur à 1, indiquant le début du chargement
(boot).
La procédure que nous venons de décrire peut être utilisée pour déterminer l'état des
processus à la suite d'une panne logicielle. Il suffit en effet de réserver une' zone mémoire
dans laquelle les processus inscrivent une trace de leur état, et de lire cette zone après la
panne en appliquant le procédure ci-dessus.
IV. 1.2. Vecteurs d'état des processus.
On suppose que la zone d'observation est une matrice V de taille MxN~ où M est le
nombre de processus à observer à chaque instant sur un transputer; et N-l est le nombre
d'états d'un processus à mémoriser. Les états des processus sont désignés par les lettres
d'un alphabet {Bi120}. A chaque processus p est associé le vecteur V[p] de la matrice
V. Les N-l premiers éléments de ce vecteur servent à mémoriser les N-l derniers états
par lesquels le processus p est passé; l'élément d'indice N-l sert à mémoriser la position
du dernier état de p dans le vecteur. On suppose qu'initialement V[p] [N-l] est égal à -1.
Quand p arrive dans l'état Bi, il le mémorise de la façon suivante :
V [pl [N-l]
= (V [pl [N-l] + 1) % (N-l);
1* % est la fonction modulo */
V [pl [V [pl (N-ll] = Bi;
158.
Cbapi1re 6.

---

Les n-l premiers ~l~ments du vecteur V[pl donnent les N-l derniers ~tats par lesquels le
processus p est pass~, et l'~l~ment V[p] [N-l] est l'indice du dernier ~tat dans ce vecteur.
En cas de panne logicielle, il suffit d'acœder à ces vecteurs par la procédure peek and
poke, pour d~terminer l'~tat de chaque processus.
IV.2. Génération de messages à la compilation.
Des informations comme les noms de variables et les messages constitu~s de chaînes de
caractères sont connues à la compilation. TI n'est donc pas nécessaire d'encombrer le bus
de contrôle en les transmettant pendant l'ex~ution. Le compilateur C_NET pourrait être
appel~ avec une option sp~iale pour cr~er un fichier .dbg pour chaque programme
source. Pour chaque appel de la fonction de traces d'~v~nements impératifs rencontré, le
compilateur enregistre le message donné en paramètre dans le fichier de trace statique, et
il remplace l'appel de la fonction par un code qui sera généré à l'ex~ution. La figure 8
donne les différentes informations qu'on peut collecter pour les instructions sp~iales de
C_NET. Dans ce tableau, les colonnes (Type, Numéro ligne, Autre) désignent les
informations statiques qui peuvent être collectées par le compilateur. Les informations
dynamiques (lOF processus, Date) seront transmises et enregistrées au moment de
l'ex~ution, étiquetées de la r~férence aux données statiques associées.
Info. générées
IDF
Date
Type
Numéro
Autre
Instructions C-Net \\
processus
Ligne
SEND
oui
oui
SND
oui
Nom du canal
RECY
oui
oui
RCV
oui
Nom du canal
ALT
oui
oui
ALT
oui
Branche choisie
PAR
oui
oui
PAR
oui
Nombre de flls
Debut Processus
oui
oui
DBP
non
IDFdupère
Fin Procssus
oui
oui
FNP
oui
Info Utilisateur
oui
oui
lUI'
Taille
Information
-Figure 8-
Informations de la trace.
Conclusion.
Le système multi-fonctions qui vient d'être d~rit es! adapté à la recherche des erreurs à
un niveau très fm. TI offre au programmeur une panoplie de possibilités pour analyser le
observer et contrÔler le comportement des processus pendant ou après l'ex~ution. TI est
extensible à de nouvelles fonctionnalités, notamment celles que le programmeur peut
défmir. Le système de points d'arrêt permet au programmeur de défmir des conditions
logiques globales pour le contrÔle de l'ex~ution.
159.
Chapitre 6.

---

CDS comporte un certains nombre de limites. Comme tous les SMAP utilisant une
bibliothèque de fonctions, l'inconvénient principal de CDS est qu'il laisse au
programmeur la charge de spécifier les observations à collecter. D'autre part, l'interface
graphique n'est pas suffisamment élaboré pour permettre une manipulation très fine des
traces, par exemple avec la recherche multi-critères d'événements. Par ailleurs, comme
avec tout moniteur logiciel CDS modifie l'ordonnancement des processus et peut de ce
fait masquer un certain nombre d'erreurs. Enfin, le bus de contrôle impose une sévère
limitation de la quantité des observations que CDS peut collecter.
160.
Chapitre 6.

---

Conclusion.
Les divers travaux que nous avons présentés dans cette thèse ont été réalisés dans le cadre de
la conception de l'environnement de programmation C_NET. La contribution de ces travaux
à cette conception comporte à la fois le développement des moniteurs du bus de contrôle du
SuperNode et la mise en œuvre du système de mise au point CDS.
La conception des moniteurs du bus nous a conduit à étudier en détaille comportement de ce
bus et à évaluer ses performances. Ces moniteurs peuvent être facilement étendus à d'autres
configurations de SuperNode. Sur le MegaNode, il suffrrait d'étendre le codage des messages
sur deux octets, et d'adapter le moniteur aux transputers de contrôle intermédiaires en utilisant
les fonctions de communication que nous avons développées. Sur un SuperNode de 16
nœuds, le portage ne nécessite aucune transformation comme nous avons pu l'expérimenter
lors d'une installation du système C_NET sur le site de Besançon. De même, sur un
TademNode, il suffirait au transputer de contrôle de sélectionner chaque SuperNode avec l'un
des deux bits du régistre de sélection, et d'étendre le codage des transputers jusqu'à 64 .
Le système de mise au point CDS est disponible. Il intègre à la fois l'horloge globale et le
système de points d'arrêt globaux que nous avons conçus. Le portage de CDS sur d'autres
configurations de SuperNode ne pose pas de difficultés particulières. Il se ramène au portage
du moniteur du bus, et la réalisation éventuelle de processus pour assurer le relais des
messages entre le transputer de contrôle et la station de mise au point. Dans C_NET, nous
avons été emmené à modifier le CIO [82] pour le transport des messages de CDS. L'interface
graphique ne nécessite qu'un terminal X-window, car nous avons justement choisi X-view
pour des raisons de portabilité.
Nous avons conçu CDS avec le souci d'en permettre l'extension. En effet, l'ajout de nouvelles
fonctions dans la bibliothèque de CDS est ce qu'il y a de plus simple. L'extension du moniteur
interactif avec de nouveaux codes de messages a été facilité par l'organisation des
programmes sources de ce moniteur. Nous avons prévu un bouton d'extension sur chaque
fenêtre de l'interface graphique pour recevoir de nouvelles fonctionnalités dont le nombre
peut être étendu sans limite en utilisant les nombreux champs numériques de ces fenêtre pour
entrer des codes spéciaux.
Le bilan et les perspectives de cette thèse sont données ci-dessous.
161.
CooclusioD.

---

1. Bilan.
L'analyse de synthèse faite dans le premier chapitre de cette thèse donne une base de départ
pouvant servir aux personnes désirant concevoir un système de mise au point. Elle dégage en
effet les techniques de base utilisées pour la collecte, le transport et l'analyse des traces.
Le deuxième chapitre fait une synthèse des concepts et des algorithmes de construction
d'horloges globales. Comme la littérature se rapportant aux horloges globales est en général
difficile à aborder, nous nous sommes efforcé de tirer l'essentiel de cette littérature et d'en
faire une présentation simple. Sur la base des nombreux travaux qui ont été faits sur les
horloges globales, nous avons résumé les concepts caractérisant les horloges, dégagé dans
quelle limites les horloges d'une machine parallèle donnée pouvaient être synchronisées, et
déterminé les propriétés pouvant caractériser une horloge globale. Ce chapitre permet de
répondre à la question suivante : dans quelle mesure peut-on synchronser les horloges d'une
machine parallèle donnée?
Dans le troisième chapitre, nous avons modélisé le comportement du bus de contrôle et
déterminé ses performances. Nous nous sommes spécialement intéressés à la communication
et à la synchronisation à travers ce bus. Mais sur la base de notre travail, il est relativement
simple d'aborder les autres fonctionnalités de ce bus Ce.g. test d'erreur, positionnement de la
vitesse des liens), car notre modèle permet de comprendre leur fonctionnement. Le moniteur
synchrone que nous avons conçu est une pièce essentielle de la reconfiguration dynamique en
ce sens qu'il en définit le grain et en véhicule tous les messages. D'autres travaux ont été
réalisés sur ce bus. Celui de Waille [lOI] visait à modéliser le comportement du bus. Mais s'il
donne une bonne explication de la génération des interruptions, il ne permet pas d'expliquer
certains aspects du bus, comme l'incompatibilité entre communications et interruptions sur le
transputer de contrôle; ou le fait que chaque transputer dispose de son propre buffer; ou
encore le fait d'activer les événements globaux à chaque interruption sur le transputer de
travail. Telmat [121] a également donné des algorithmes de base de communication sur le
bus, sans cependant proposer un modèle de fonctionnement du bus pour ces algorithmes, ni
leurs performances. Ce travail est le plus complet qui ait été réalisé sur ce bus pour en
expliquer le comportement. Nous espérons que les utilisateurs du SuperNode trouveront en ce
chapitre un document essentiel l'exploitation de cette machine.
Dans le quatrième chapitre, nous avons présenté une nouvelle version de l'algorithme
probabiliste. Notre algorithme conserve les propriétés de l'algorithme initial Ce.g. précision),
et il comporte des avantages sur ce dernier. Le premier est qu'il permet de s'adapter à la
162.
Coœlusion.

---

variation de charge du réseaux sans perdre la précision de synchronisation. Le deuxième est
qu'à défaut de connaître la distribution des temps de communication, une borne inférieure de
la probabilité de synchroniser deux horloges est déduite des temps de communication
observés pendant l'exécution. Cette borne peut être utilisée comme estimateur de la borne
supérieure du nombre moyen des messages nécessaires pour synchroniser les horloges. Dans
le cas du bus de contrôle du SuperNode, nous avons observé que ces bornes sont très proches
des valeurs réelles que nous avons mesurées. Enfm, avec notre algorithme, il est possible au
programmeur d'effectuer des tests d'hypothèses pour cerner la distribution des temps de
communication. Cet algorithme est particulièrement adapté aux distributions de temps de
communication ayant une forme asymptitiquement normale, ou non concentrées près du
minimum. Nous pensons, comme il a été observé dans [16] pour l'lagorithme de Cristian [42],
que notre algorithme peut contribuer à améliorer des algorithmes de synchronisation des
horloges existants.
Dans le cinquième chapitre, nous avons présenté un système de points d'arrêts globaux. li
permet d'exprimer des prédicats globaux et d'associer individuellement les actions à effectuer
à chaque processus arrêté. Nous avons décrit des algorithmes de ce système permettant de
limiter le nombre de messages générés. Ce nombre peut encore être réduit si le processeur de
contrôle (ou le circuit de diffusion) gère lui aussi une structure de prédicats qui lui permette
de ne pas diffuser les messages supplémentaires résultant du fait que plusieurs processeurs
peuvent valider le même prédicat simultanément. Par rapport aux systèmes existants [29] [35]
[56] [85] [86] [87] [90], notre système a l'avantage de ne pas nécessiter de communiquer entre
les processus utilisateurs. De plus le nombre de messages générés par notre système est
proportionnel au nombre des processeurs, alors que dans les systèmes précédemment cités, ce
nombre est proportionnel au nombre de processus, qui dépasse toujours celui des processeurs.
Dans le sixième chapitre, nous avons présenté un système de mise au point s'inscrivant dans
l'orientation actuelle de la recherche. L'affichage synchrone des traces que nous avons
introduit peut être améliorée en défmissant de nouveaux critères de sélection des messages.
Nous pensons en particulier à l'identificateur de processus. De même le scanner qui est une
autre originalité de CDS peut être affIné en spécifiant interactivement les données à collecter,
comme nous l'avons fait avec le processus espion. Nous pensons que l'utilisation d'une
horloge globale comme celle que nous avons conçue et les points d'arrêt globaux sont
indispensables aux systèmes de mise au point. Et plus généralement, l'association du contrôle
en ligne de d'exécution et de l'analyse des traces permet de couvrir un large domaine de
recherche des erreurs. Nous pensons que notre travail, au delà de son environnement de
développement, apporte une contribution à la mise au point des programmes parallèles.
163.
Ûloclusioll.

---

II. Perspectives.
La mise au point des programmes parallèles est un sujet en plein essor pour lequel il reste
encore d'énormes efforts à faire pour aboutir à des outils à la fois efficaces, conviviaux et
faciles d'usage. Dans cette thèse nous avons présenté un travail qui, sans avoir la prétention
d'approcher ces objectifs, peut être amélioré et étendu à d'autres fonctionnalités selon les axes
suivants.
• Une étude expérimentale des algorithmes de synchronisation est nécessaire pour d'une part
établir leur viabilité et disposer de comparaisons. Cela permettrait de savoir quels algorithmes
s'appliquent à quelles configurations. Et surtout, cela permettrait de savoir dans quelle mesure
ces algorithmes peuvent êtres améliorés. Cette thèse a donné une piste sérieuse pour
l'amérioration des algorithmes existants, car nous pensons que l'utilisation des statistiques
permettrait d'améliorer un bon nombre de ces algorithmes, par exemple avec une meilleure
connaissance de la distribution des temps de communication, ou une estimation de la dérive
réelle de chaque horloge par rapport aux autres.
• Le couplage de CDS avec le compilateur CPL de C_NET peut permettre d'éliminer les
données statiques des messages collectés à la compilation comme nous l'avons suggéré. Une
autre possibilité est de réaliser un analyseur permettant de reconnaître ces données statiques et
de les extraire des messages qui seront générés à l'exécution, en les y remplaçant par un code
faisant référence à un fichier spécial. Et, de manière plus générale, on simplifierait
énormément la charge du programmeur en couplant les systèmes de mise au point avec les
compilateurs, soit par une conception conjointe de ces logiciels, soit en définissant des
standards comme entre les compilateurs et les éditeurs de liens.
• En concevant l'interface graphique de CDS, nous avons mis l'accent sur le multi-fenestrage
et l'exécution en parallèle des tâches gérant ces fenêtres. C'est une de travail base pour
développer des outils de visualisation du comportement des processus. C'est là un domaine de
recherche où presque tout reste encore à faire. Nous avons conçu le moniteur interactif pour
permettre de collecter et gérer n'importe quel type de données. Une interface de visualisation
plus élaborée peut donc être rajoutée à CDS en utilisant les fenêtres de type canvas de X-
view et les boutons d'extension de CDS. Et plus généralement, l'efficacité des prochains outils
de mis~ sera spécialement basée sur leur capacité de visualisation de l'exécution sur plusieurs
fenêtres, avec plusieurs niveaux de vue et plusieurs modèles. Nous pensons que l'affichage
synchrone des traces dans dans ce sens.
164.
Conclusion.

---

Finalement, CDS peut être vu comme un système précurseur, qui a établi une base sur
laquelle de nouveaux outils peuvent se développer, se greffer, ou s'inspirer. Nous avons
justement fait un effort particulier dans la mise en œuvre de CDS pour permettre ces
extensions. Cela à la fois en prévoyant des points d'extension, mais aussi de manière plus
élémentaire, en organisant le code source de CDS en conséquence.
Un problème intéressant, pour la mise en œuvre d'un système de mise au point de
programmes parallèles, est la reconnaissance parallèle des événements. On peut se donner un
modèle de machine où à chaque instant, on a plusieurs flots d'instructions opérant sur un flot
de données. Dans ce cas, les reconnaisseurs d'événements, des automates d'états fmis, peuvent
opérer en parallèle sur un seul flot de données, constitué par les traces des événements. C'est
là une utilisation possible des machines multi-processeurs pour la mise au point de
programmes parallèles. Une voie de recherche ouverte.
En attendant de disposer de langages permettant d'écrire systématiquement des programmes
corrects, les systèmes de mise au point occuperont encore pour l'avenir une grande place
dans le concert du parallélisme.
165.
Conelusion.

---

---

Références.
[1] Adam M., Hwfm M., Raynal M., Plouzeau N.
Distributed Debugging Techniques
Rapport de Recherche nO 1459 INRIA-Rennes
[2] lM. Adamo
C_NET, a C++ Based Language for Distributed and Real_Time Programming
Ilth OUG Meeting, 25-26 Sept. 1989, Edinburg
[3] Adamo J.M.
Exception Handling in the C_NET Paralle1 Programming Language
Laboratoire LIP-IMAG
Ecole Normale Supérieure de LYON
46, allée d'Italie, 69364 Lyon cedex 7, France
[4] Adamo lM.
Extending C++ with Communicating Sequential Processes
Rapport de Recherche N° 90-25
LIP-lMAG, Ecole Normale Supérieure de Lyon
46, allée d'Italie, 69364 Lyon cedex 7, France
[5] Adamo J.M. , Alhafez N.
A Parametrable Router for the C_NET Programming Environment
Rapport de Recherche nO 92-25
LIP-IMAG, Ecole Normale Supérieure de Lyon
46, allée d'Italie, 69364 Lyon cedex 7, France
[6] Adamo lM., Alhafez N., BoneUo C., Bonneville l, Moukeli P., Trejo L.
Developing A High Level Programming Environment for SuperNode,
Proc. of Transputer Applications 91, Aug. 28-30, Glasgow, lOS Press.
[7] Adamo lM., Alhafez N., BoneUo C., Bonneville l, Moukeli P., Trejo L.
Design Principles of Virtual Machine for Dynamically Reconfigurable
Workshop on Parallel and distributed Workstation Systems, European Institute
of Multiprocessors
Technology, Florence, Sept. 26-27, 91,
to appear in Future Generation Computer Systems
[8] Adamo lM, BoneUo C.
Proceedings of COMPAR'90 conference,
TéNOR++: A Dynamic Configurer for SperNOde Architecture
Proceedings of COMPAR'90 conference,
Springer Verlag Pub!., 1990, pp: 640-651
[9] Adamo lM, Bonello C.
The PPL Language: Reference Manual, Release 1.0
Rapport de Recherche nO 92-23
LIP-IMAG, Ecole Normale Supérieure de Lyon
46, allée d'Italie, 69364 Lyon cedex 7, France
[10] Adamo J.M, BoneUo C.
The C_NET Programming Environment: An Overview, Release 1.0
Rapport de Recherche nO 92-17
LIP-IMAG, Ecole Normale Supérieure de Lyon
46, allée d'Italie, 69364 Lyon cedex 7, France
16ï .
RéféIen<:es.

---

[11] Adamo J.M, Bonello C., Bonneville J.
C_NET a High Level Programming Environment for
SuperNode Multprocessor
Proc. WP&DP'90, SOFIA March 27-291990, Elsevier.
[12] Adamo J.M, Bonello C., Bonneville J.
Virtualizing Communication in the C_NET programming Environment;
Proceedings of the 13th OUG, Technical Meeting 339-349.
[13] Adamo J.M., Bonello C., Trejo L.
The C_NET Programming Environment: An Overview, Re1ease 1.0
Rapport de Recherche nO 92-17
LIP-IMAG, Ecole Normale Supérieure de Lyon
46, allée d'Italie, 69364 Lyon cedex 7, France
[14] Adamo J.M., Trejo L.
The CPL Language: Reference Manual, Release 1.0
Rapport de Recherche nO 92-19
LIP-IMAG, Ecole Normale Supérieure de Lyon
46, allée d'Italie, 69364 Lyon cedex 7, France
[15] Alari G., Ciuffoletti Augusto.
Improving the Probabilistic Clock Synchronization Algorithm
Università degli Studi di Pisa -Dipartimento di lnformatica
Corso ltalia n. 40, 56100 Pisa -Italy
[16] Alari G., Ciuffoletti Augusto.
Using Full Message Exchange for Probabilistic Clock Synchronization
(Extended abstract), Università degli Studi di Pisa -Dipartimento di lnformatica
Corso Italia n. 40, 56100 Pisa -Italy
[17] Appelbe W., McDowell C.
Integrating Toois for Debugging and Developping
Multitasking Programs
pp. 78-87 cf[Pr]
[18] Araki K., Furukawa Z., Cheng J.
A General Framework for Debugging.
IEEE SOFIWARE, May 1991, PP. 14-20
[19] Z. Aral, I. Gertner
High-Ievel Debugging in Parasight
pp.l51-162 cf[Pr]
[20] Aspnlis M., Ungbacka T.
A Monitoring System for a Transputer-Based Multiprocessor
Proceedings of Transpting'91
Welch P. et al., eds, lOS Press, 1991
[21] Babaoglu O., Drummond R.
(Almost) No Cost Clock Synchronization
Proc. of the Seventeenth Int. Symposium on Fault Tolerant Computing,
June 1987, PP. 42-47
[22] Baiardi F., de Francesco N., Vaglini G.
Development of a Debugger for a Concurrent Language
IEE TRANSACTIONS ON SOFTWARE ENGENEERING.
Vol SE-12 N°. 4 April 1986 PP. 547-553
168.
Références.

---

[23] Baily D.E.
Probability and Statistics, Models for Research
John Wll...EY & SONS INC.
[24] Bates P.
Debugging Heterogeneous Distributed Systems Using
Event-Based Models of Behavior
Proceedings of the ACM SIGPLAN and SIGOPS Workshop on Parallel and
Distributed Debugging, pp.11-22 ,May 5-6, 1988 University of Wisconsin,
Madison, Wisconsin 53706
[25] Bates P.C., Wileden J.J.
. High-Level Debugging of Distributed Systems:
the Behavioral Abstraction Approach
The Journal of Systems and Software, 3, PP. 255-264, 1983
[26] Bemmerl T., Lindhof R., Treml T.
The Distributed Monitor System of TOPSYS
Departement of Computer Science TU Munich
Lehrstuhl fUr Rechnerteehnik. und rechnerorganisation
Arcisstr.21, 8000 Munichen 2, FRG
[27] Black D., Golub D., Hauth K., Tevanian A, Sanzi R.
The Mach Exception Handling Facility
Proceedings of the ACM SIGPLAN and SIGOPS Workshop on Parallel and
Distributed Debugging, pp.45-56 , May 5-6, 1988 University of Wisconsin,
Madison, Wisconsin 53706
[28] Bonello C.
The GCL Language: Reference Manual, Release 1.0
Rapport de Recherche nO 92-22
LIP-IMAG, Ecole Normale Supérieure de Lyon
46, allée d'Italie, 69364 Lyon cedex 7, France
[29] Bougé L.
Repeated Snapshots in Distributed Systems with Synchronous Communications
and their Implementation in CSP
Theorical Computer Science N° 49, 1987, PP. 145-69
[30] Bristow, Drey G. C. , Edwards B., Riddle W.
Anomaly Detecting in Concurrent Prograrns
in (Concurrent Prograrnming Addison-Wesley
PP.567-585
1988)
The Journal of Systems and Software 3,255-264 1983
[31] Caillet lF.
IDEFIX : un Outil de Test de Logiciels Temps Réel Ada
BIGRE + GLOBULE Test et validation du logiciel
pp. 42-48, Janvier 1989
[32] Cameron E.l, Cohen D.
The IC* System for Debugging Paralle1 Prograrns via Interactive
Monitoring and Control
Proceedings of the ACM SIGPLAN and SIGOPS Workshop on Parallel and
Distributed Debugging, pp.261-270 ,May 5-6, 1988 University of Wisconsin,
Madison, Wisconsin 53706
169.
Réfén:nces.

---

[33] Champion T.
Manuel d'utilisation du langage C de Logical Systems sur SuperNode
LIP, rapport technique nO 89-03.
46, allée d'Italie, 69364 Lyon cedex 7, France
[34] Champion Thierry, Tourancheau Bernard
SuperNode: document utilisateur Version 1.0
LIP, rapport technique nO 89-02.
46, allée d'Italie, 69364 Lyon cedex 7, France
[35] Chandy K.M., Lamport L.
Distributed Snapshots : Determining Global States of Distributed Systems.
Trans. on Computing Systems 3, 1, February, 1985, PP. 63-75.
[36] Chang C.K., Wong L.F.
A Specification-based Approach for Testing Distributed Software
1988, Department of EECS (m/c 154), University of lllinois at Chicago,
Chicago, lllinois 60680
[37] Chase B.B.
Intermediate Languages for Debuggers
Proceedings of Supercomputer Debugging workshop'91
Albuquerque, New Mexico, November 14-16, 1991
[38] Chaumette S.
A Replay Mechanism within an Environment for Distributed Programming
Proceedings of Supercomputer Debugging workshop'91
Albuquerque, New Mexico, November 14-16, 1991
IEEE Software January 1990, PP. 106-115
[39] Cheng W.H., Wallentine V.E.
DEBL: A Knowledge-Based Language for Specifying and
Debugging Distributed Programs
Commnication of the ACM Sept. 1989 Vol. 32 Number 9 PP. 10789-1084
[40] Cheung W.H., Blacks P. B., Manning E.
A Framework for Distributed Debugging
IEEE Software, January 1990, PP. 106-115
[41] Couch A.L., Krumme D.W.
An Integrated Debugging, Analysis, and Visualization Environment
for Large-Scalr Multiprocessors
Proceedings of Supercomputer Debugging workshop'91
Albuquerque, New Mexico, November 14-16, 1991
[42] Cristian F.
Probabilistic Clok Synchronization
Distributed Computing, N° 3, 1989, PP. 146-158
[43] Curtis R., Wittie L.
BugNet : a Debugging System for Parallel
Programming Environments
Proc. 3rd Int. Conf. on dist. Computing syst. (Hollywood, FL)
pp. 394-399, Oct 1982
[44] Diehl C., Jard C.
. Observation de la Causalité Dans les Exécutions Réparties
Journée C3, Pôle Systèmes et Environnement,
Datation et Contôle des Exécutions Repartie.
Rennes, 4 déc. 1991 IRISA, Campus de Beaulieu.
170.
R.éférences.

---

[45] Dijkstra E.W.
Cooperating Sequencial Processes
Genuys F. (Eel.), Programming Languages, 1968, PP. 43-112,
Accademic Press, New-York.
[46] Dolev D.
The Byzantine GeneraIs Strikes Again
Journal of Algorithms, N° 3, 1982, 14-30
[47] Dolev D., Halpern J.Y., Strong R.
On the Possibility and Impossibility of Achieving Clock Synchronization
Journal of Computer and System Sciences, N° 32, 1986, PP. 230-250.
Bigre 78, Mars 1992, PP. 21-40
[48] Duda A., Harrus G., Haddad Y., Bernard G.
Estimating Global Time in Distributed System.
Proc. 7th. Conf. on Distributed Computing Systems, Berlin, 1987.
[49] Elshoff I.
A Distributed Debogueur for Amoeba
Proceedings of the ACM SIGPLAN and SIGOPS Workshop on Parallel
and Distributed Debugging
Proceedings of the ACM SIGPLAN and SIGOPS Workshop on Parallel and
Distributed Debugging, pp.l-lO, May 5-6, 1988 University of Wisconsin,
Madison, Wisconsin 53706
[50] Ernrath, Padua P.D.
Automatic Datection of Nondeterminacy in Parallel Programs
Proceedings of the ACM SIGPLAN and SIGOPS Workshop on Parallel and
Distributed Debugging, pp.89-99, May 5-6, 1988 University of Wisconsin,
Madison, Wisconsin 53706
[51] Fang K.Y., Tasi J.P., Bi Y.D.
A Non-Interference Monitoring System for Real-Time Software
Testing and Debugging
.
Department of Electrica1 Engineering and Computer Science, 1988,
University of Illinois at Chicago, Chicago, lllinois 60680
[52] Feldman S., Brown C.
IGOR: a System for Program Debugging via Reversible Execution
Proceedings of the ACM SIGPLAN and SIGOPS Workshop on Parallel and
Distributed Debugging, pp.112-123, May 5-6, 1988 University of Wisconsin,
Madison, Wisconsin 53706
[53] Ferrante J.
High Level Language Debugging with a Compiler
mM Thomas J. Watson Research Center
PP. 123-129, 1983 ACM
[54] Forin A.
Debugging of Heterogeneous Parallel Systems
Proceedings of the ACM SIGPLAN and SIGOPS Workshop on Parallel and
Distributed Debugging, pp. 130-140, May 5-6, 1988 University of Wisconsin,
Madison, Wisconsin 53706
[55] Gusella R., Zatti S.
A Network Time Controller for a Distributed Berkeley Unix System
IEEE Distr. Proc. Tech. Comm. Newsletter, SI-2 (6), PP. 7-15, June 1984
l il.
Références.

---

[56] Haban D., Weigel W.
Global Events and Globalbreakpoints in Distributed Systems.
21th Hawaï International Conference on System Science. Jan. 1988, PP. 166-175
[57] Halsall F., Hui S.C.
Performance Monitoring and Evaluation of Large Embedded Systems
Software Engineering Journal, Sept. 1987, PP. 184-1992
[58] Hoare c.A.R.
Processus Séquenciels Communicants
Masson 1986
[59] Hopkins A.L., Smith T.B .• Lala J.H.
FrMP - A Highly Reliable Fault-Tolerant Multiprocessor for Aircraft
Proc. IEEE, Vol. 66, N° 10, Oct. 1978, PP. 1221-1240
[60] Hough A. A.. Cuny J.E.
Belvedere: Prototype of Pattern-Orïented Debogueur
for Highly Parallel Computation
1987. Department of Computer and Information Science
University of Massachusetts, Arnhrest, MA 01003
[61] Hseush W. ,Kaiser G.
Data Path Debugging : Data-Oriented Debugging for Concurrent
Programming Language
Proceedings of the ACM SIGPLAN and SIGOPS Workshop on Parallel and
Distributed Debugging, pp.236-247, May 5-6,1988 University of Wisconsin,
Madison, Wisconsin 53706
[62] INMOS Ltd.,
The transputer reference manual,
Prentice Hall 1988
[63] INMOS Ltd.,
Transputer Intruction Set, a compiler writer's guide
Prentice Hall 1988
[64] Jesshope C.
Transputers and switches as objects in OCCAM;
Parallel Computing, (8), 1988, pp: 19-30
[65] Jezéquel lM.
Building a Global Time on Parallel Machines
Rapport Interne nO 513. Février 1990, INRIA-Rennes
[66] JezéquelJ.M.
.
Outils pour l'expérimentation d'algorithmes distribués sur machines parallèles
Thèse N° 404. Université de Rennes 1, Octobre 1989
[67] Jones S. H.• et al.
BugNet : a Real Time Distributed Debugging Systems
Proc. 6th Int Symp. on Reliability in distributed Soft. and
DB syst. Williamsburg, Va, pp. 56-65, March 1987
[68] Joyce J.• Lomow G., Slind K.• Unger B.
Monitoring Distributed Systems
University of Calgary
.ACM Transaction on Computer Systems
Vol. 5, N°. 2, May 1987, PP. 121_150
Références.

---

[69] Khanna A.
Design of a Debugger for a Heterogeneous Distributed System
Proceeclings of Supercomputer Debugging workshop'91
Albuquerque, New Mexico, November 14-16, 1991
[70] Kopetz H., Ochsenreiter W.
C10ck Synchronization in Distributed Rea1-Tirne Systems
IEEE Transaction on Computers
Vol. C-36, N° 8, August 1987, PP. 933-940
[71] Krishnamoorthy M.S.
DBL: An Interractive Debugging System
Proceedings of Supercomputer Debugging workshop'91
Albuquerque, New Mexico, November 14-16, 1991
[72] Lamport L.
Tirne, Clocks and the Ordering of Events in a Distributed System.
Comm. ACM, vol 21, 7, JuIy 1978, PP. 558-565.
[73] Lamport L.
Using Tirne Instead of Tirneout for Fault-Tolerant Distrubuted Systems
ACM Transactions on Programming Languages and Systems
Vol. 6, N° 2, April 1984, PP. 254-280
[74] Lamport L.
Concurrent Reading and Writing of Clocks
ACM Transactions on Computer Systems.
Vol. 8, N° 4, Nov. 1990, PP. 305-310
[75] Lamport L., Miller-Smith P.M.
Synchronizing Clocks in Presence of FauIts
Journal of the Association for Computing Machinery
Vol. 32, N° l, January 1985, PP. 52-78
[76] Lamport L., Shostak R., Pease M.
The Byzantine Generais Plobem
ACM Transactions on Programming Languages and Systems
Vol. 4, N° 3, Ju1y 1982, PP. 382-401
[77] Landstaff D.P., Moore M., Nicole D.A.
Esprit P1085 SNODE CONTROL BUS WORKING NOTES
Jun. 1987, Dept. of Electronic and Computer Science,
Univ. of Southampton,
[78] Leblanc TJ., Mellor-Crurnmy J.M.
Debugging Parallel Programs with Instant Replay
Transaction on Computers vol. C_36, n04, 471-482, April 1987
[79] Leblanc TJ., Mellor-Crurnmy lM., Fowler RJ.
Analyzing Parallel Program Execution Using Multiple Views
Journal of Parallel and Distributed Computing 9, PP. 203-217, 1990
[80] Lin C., Leblanc R.
Event-Based Debugging of Object/Action Programs
Proceedings of the ACM SIGPLAN and SIGOPS Workshop on Parallel and
Distributed Debugging, pp.23-33, May 5-6, 1988 University of Wisconsin,
Madison, Wisconsin 53706
173.
Réf6n:oces.

---

[81] Livingston 1., Spohrer K.
DWARP: A Debugging Standard
Proceedings of Supercomputer Debugging workshop'91
Albuquerque, New Mexico, November 14-16, 1991
[82] Logical Systems
Logical Systems transputer toolset
[83] Lundelius 1., Lynch N.
An Upper and Lower Bound for Clock Synchronization
Information and Control, Vol. 62, N° 2-3, 1984, PP. 190-204
[84] Lundelius 1., Lynch N.
A New Fault-Tolerant Algorithm for C10ck Synchronization
Information and Computation, Vol. 77, N° 1, 1988, PP. 1-36
[85] Manabe Y., Imase M.
Global Conditions in Debugging Distributed Prograrns.
Journal of Parallel and Distributed Computing 15, PP. 62-69, 1992.
[86] Mattern F.
Virtuel Time and Global States of Distributed Systems
Department of Computer Science, University of Kaiserslautern
D 6750 Kaiserslautern, Germany
[87] Mattern F.
On the Relativistic Structure of Virtual Time in Distributed Systems.
Journée C3, Pôle Systèmes et Environnement,
Datation et Contôle des Exécutions Repartie.
Rennes, 4 déc. 1991 IRISA, Campus de Beaulieu.
Bigre 78, Mars 1992, PP. 3-19
[88] McDonald C.
Dream Debugger
Proceedings of Supercomputer Debugging workshop'91
Albuquerque, New Mexico, November 14-16, 1991
[89] McDowell C.E., Helmbold D.P.
Debugging Concurrent Programs
pp. 593-622, ACM Computing Surveys, Vol 21, No. 4 December 1989
[90] Miller B.P., Choi 1.D.
Breakpoints and Halting in Distributed Programs
Proc. Eighth Int'l Conf. Distributed Computing Systems,
CS Press, Los Alamitos Calif. 1988, pp. 316-323
[91] Moukèli P.
Les Principales Approches de Conception des Débogueurs pour les
Langages Parallèles
Rapport de Recherche nO 90-05
LIP-IMAG, Ecole Normale Supérieure de Lyon
46, allée d'Italie, 69364 Lyon cedex 7, France
[92] Moukeli P.
Déverminage de Programmes Parallèles, le cas du Système du C-Net.
BIGRE N° 70, Septembre 1990, PP. 54-65
1i4.
Références.

---

[93] Moukeli P.
Conception et réalisation d'un moniteur de communication sur le bus de
contrôle de SuperNode
Rapport technique n09l-0l, LIP-IMAG, Ecole Normale Supérieure de Lyon
46, allée d'Italie, 69364 Lyon cedex 7, France
[94] Moukeli P.
Etude et Mise en Œuvre du Système de Mise au Point de
Programmes C_NET.
Rapport de Recherche nO 91-22. LIP-IMAG,
Ecole Normale Supérieure de Lyon
46, allée d'Italie, 69364 Lyon cedex 7, France
[95] Moukeli P.
Présentation d'un moniteur de communication sur le bus de
contrôle du SuperNode, La Lettre du Transputer, Sept. 1991, PP. 33-50.
[96] Moukèli P.
Présentation du Système de Mise au Point du Projet C_NET: CDS.
Rapport de Rechercheno 91-11. LIP-IMAG, Ecole Normale Supérieure de Lyon
46, allée d'Italie, 69364 Lyon cedex 7, France
[97] Moukèli P.
CDS: C_NET Debugging System
Manuel d'utilisation (verion 2.0).
Rapport Technique nO 91-03, LIP-IMAG, Ecole Normale Supérieure de Lyon
46, allée d'Italie, 69364 Lyon cedex 7, France
[98] Moukeli P.
Designing CDS: an On-Line Debugging System for
The C_NET Programming Environment
Proceedings of Supercomputer Debugging workshop'91
Albuquerque, New Mexico, November 14-16, 1991
[99] Moukeli P.
Statistical Probabilistic Clock Synchronization Algorithm
CONPAR'92, Lyon, Sept. 1992
[100] Moukeli P.
Un système de Construction de Points d'Arrêt Globaux pour les
Programmes Parallèles,
Premier Colloque Africain sur La Recherche en Informatique,
Yaoundé Cameroun, october 14-20,92.
[101] Muntean TraYan, Waille Philippe
L'architecture des machines Supemode
PP. 11-40, La Lettre du Transputer, septembre 1990
[102] Myers T.
Debugging at the National Security Agency :
"The State of the Use Meassge"
Proceedings of Supercomputer Debugging workshop'91
Albuquerque, New Mexico, November 14-16, 1991
[103] Naimi M.
Global Stability Detection in the Asynchronous Distributed Compuations
IEEE, Proc. Work. on the Future Trends of Distributed Computing
Systems in 1990s, Hong Kong, 14-16 Sept. 1988, PP. 87-92
175.
Réfbeo<:cs.

---

[104] Nizar A.
Etude et Mise en Œuvre de Routages non Blocant dans les Architectures
Multi-porcesseurs
Thèse de doctorat en Informatiqu'e.
Université Claude Bernard de Lyon, Dec. 1991
[105] Pan D., Linton M.
Supporting Reverse Execution for Parallel Programs
Proceedings of the ACM SIGPLAN and SIGOPS Workshop on Parallel and
Distributed Debugging, pp.124-129, May 5-6,1988 University of Wisconsin,
Madison, Wisconsin 53706
[106] Ponamgi M.K, Hseush W., Kaiser G.E.
Debugging Multithreaded Programs with MPD
IEEE SOFIWARE, May 1991, PP. 37-43
[107] Ramanathan P., Kandlur D.D., Shin KG.
Hardware-Assisted Software Clock Synchronization for
Homogeneous Distributed Systems,
IEEE Transaction on Computers, Vol. 39, N° 4, April 1990, PP. 514-524
[108] Ramanathan P., Shin KG., Butler R,W.
Fault-Tolerant Clock Synchronization in Distributed Systems
IEEE Computer, October 1990, PP. 33,-42
[109] Raynal M.
Order Notions and Atomic Multicast in Distributed Systems: a Short Survey.
Rapport de Recherche nO 1197 INRIA-Rennes, Mars 1990
[110] Raynal M., Mizuno M., Neilsen M.L.
Mesure de la Synchronisation et de la Concurrence des Calculs Repartis
Journée C3, Pôle Systèmes et Environnement,
Datation et Contôle des Exécutions Repartie.
Rennes, 4 déc. 1991 IRISA, Campus de Beaulieu.
Bigre 78, Mars 1992, PP. 41-60
[111] Reed D.A., et al.
Scalable Performance Environments for Parallel Systems
Proc. Sixth Fifth Distributed Memory Computing Conference,
IEEE Computer Society Press 1991
[112] Rigsbee P.A.
X Window System Interface for CDBX
Proceedings of Supercomputer Debugging workshop'91
Albuquerque, New Mexico, November 14-16, 1991
[113] Schlichting R"
Cristian F., Purdin T.D.M.
Mechanism For Failure Handling In
Distributed Programming Languages
Research Report
Computer Science 6/24/87 IBM
[114] Schneider F.B.
A Paradigm for Reliable Clock Synchronization
Tech. Report TR-86-735, Computer Science Dept.,
. Comell Univ., Ithaca, N.Y., Feb 1986
[115] Shimomura T., Isoda S.
Linked-List Visualization for Debugging
IEEE SOFIWARE, May 1991, PP. 44-51
176,
Références,

---

[116] Shin K.G., Rarnanathan P.
Clock Synchronization of a large Multiprocessor System
in the Presence of Malicious Failures.
IEEE Trans. Computers, Vol. C-36, N° l, Jan. 1987, PP. 2-12
[117] Spiegel M.R.
Probabilités et Statistiques, cours et problèmes.
Série Schaum, McGraw-Hill
[118] Srinkanth T.K., Toueg S.
Optimal Clock Synchronization
Journal of the Association for Computing Machinery
Vol. 34, N° 3, July 1987, PP. 626-645
[119] Streepy L.
Convex CXdb Concpets
Convex Computer Corp.
Proceedings of Supercomputer Debugging workshop'91
Albuquerque, New Mexico, November 14-16, 1991
[120] Taylor R.N.
A General-Purpose Algorithm for Analyzing Concurrent Prograrns
Concurrent Prograrnming, Addison-Wesley PP. 586-621
1988
[121] Telmat Informatique
Control Bus Hardware Description,
Technical Report N°6, T.Node Department,
Rue de l'Industrie, Z.I., B.P.12, SOULTZ 68360 FRANCE
[122] Telmat Informatique
T.Node TOOLs (TNT), T.Kemel
ed. 01/90 réf. TN/docfl_05/3.1
T.Node Department, Rue de l'Industrie, Z.I., B.P. 12,
SOULTZ 68360 FRANCE
[123] Telmat Informatique
Tnode documentation
T.Node Department, Rue de l'Industrie, Z.I., B.P. 12,
SOULTZ 68360 FRANCE
[124] Triolet R.
Prograrnming Environments for Parallel Machines
Ecole des Mines de Paris
Centre d'Automatique et Informatique
35, rue Saint Honoré
77305 FONTAINEBLEAU cedex
FRANCE
[125] Vasanthavada N., Marinos P.N.
Synchronization of FauicTolerant Clocks in the Presence of
Malicious Failures
IEEE Transaction on Computers, Vol. 37, N° 4, April 1988, PP. 440-448
[126] Waille P.
Introduction à l'Architecture des Machines SuperNode
Rapport technique RT -56- Février 1990, LOI, Institut !MAG
1ïi.
Réfén:oces.

---

[127] Wittie L.
Debugging Distributed C Programs by Real Time Replay
Proceedings of the ACM SIGPLAN and SIGOPS Workshop on Parallel and
Distributed Debugging, pp.57-67. May 5-6, 1988 University of Wisconsin,
Madison, Wisconsin 53706
[128] Yanev K., Giurov J.
Monitoring of Transputer CPU/FPU Utilisation in Runtime
Parallel and Distributed Processing
K. Boyanov (Editor, North-Holland), 1991, PP. 361-376
[129] Young B.
bdb : A Library Approach to Writing a New Debugger
Proceedings of Supercomputer Debugging workshop'91
Albuquerque, New Mexico, November 14-16, 1991
[130] Zitterbart M.
Monitoring and Bebugging Transputer-Networks with NETMON-II
Institute of Telematics, University of Karlsruhe, Kaiserstr. 12,
7500 Karsruhe, FRG
178.
RéféreDces.

---

Annexe 1.
Tableaux de programmation du bus.
Adresse
Mode accès Fonction
(int *) 0x00000024
écriture
Registre d'adresse; sert à spécifier le type d'opération pour laquelle on
veut utiliser le bus. et le groupe de ST sur lequel elle porte. Le deuxième
octet permet de sélectionner le SNode auquel on veut accéder:
• Bit 0 : SNode maître, ou SNode de 32.
• Bit 2 : SNode esclave du TandemNode
(char*) 0x00000028
lecture!
Registre utilisé comme buffer, ou comme complément du registre
écriture
d'adresse selon le type d'opération. Dans le dernier cas, ce registre sert à
indiquer les ST sur lesquels porte l'ooération : un bit par ST.
(char*)0x0000002C
lecture!
Registre pour autoriser (1) ou interdire (0) les interruptions sur le canal
écriture
EVENT:
• Bit 0 : interruption BALL (. MSDF)
• Bit 1 : interruption ANY (. SMDE)
• Bit 2 : interruption Daisy (. BERR)
• Bit 3 : interruption externe
(char*) OXOOOOOO30
lecture
Registre pour déterminer le type de l'interruption qui d' a eu lieu:
• Bit 0 : interruption BALL
• Bit 1 : interruption ANY
• Bit 2 : interruption Daisy
• Bit 3 : interruption'externe
(char*) 0x00000034
écriture
Active un mécanisme interne au CGA pour la génération des
interruptions. Ce registre doit être positionné au démarrage. et chaque fois
au'on a acquitté une interruption.
(char*) 0x00000038
lecture
Registre d'état du bus, Une lecture de ce registre donne l'état du bus:
• Bit 0: quand ce bit est à O. on peut à nouveau charger le registre· adresse
et le buffer.
• Bit 1 : reste à un tant Que le bus est occupé.
(char*)0x0000003C
écriture
Une écriture à cette adresse permet de demander au CGA d'exécuter la
commande chargée dans le registre adresse et le buffer. Cela a pour effet
de mettre les deux bits du registre d'état du bus à 1. Un nouveau cycle ne
doit être démarré Que quand les deux bits enguestion sont à nouveau à O.
-Tableau Al-
Registres du transputer de contrôle.
179.
Auncxcs.

---

Adresse
Mode accès
Fonction
(char·) OxOOOOOOO8
lect/écrit
Buffer
(char·) OXOOOOOOOC
lecture
Registre pour autoriser ou interdire les interruptions (canal EVENT) :
écriture
.• Bit 0 : interruption SMDE
• Bit 1 : interruption MSDF
• Bit 2: interruption Daisy (CGA maître)
• Bit 3: interruption externe (CGA maître)
(char·) 0x00000010
lecture
Sert à déterminer l'état des fiags et le type des interruptions actives:
• Bit 0 : interruption SMDE
• Bit 1 : interruption MSDF
• Bit 2 : interruption Daisy (CGA maître)
• Bit 3 : interruption externe (CGA maître)
(char·) 0x00000014
écriture
Active un mécanisme interne au CGA pour la génération des
interruptions. Ce registre doit être positionné au démarrage. et chaque
fois qu'on a acquitté une interruption.
(char·) 0x00000018
écriture
Dépositionne le flag SMDE pour signifier au maître qu'un octet est
1 présent dans le buffer du ST. ou Qu'il acquitte une interruption SMDE.
(char·) 0x0000001 C
écriture
Dépositionne le flag MSDF pour signifier au maître qu'un octet es
1présent dans le buffer du ST. ou qu'il acquitte une interruption MSDF.
-Tableau A2-
Registres du transputer de travail.
lNuméro de \\troupe 222
Numéro de transputer de travail. position du bit dans l'octet du group .
GRO =(char) 0x00
GRI =(char) Ox20
GR2 =(char) Ox40
GR3 =(char) 0x60
O.
4
1. 5
2.
6
3.
7
4.
0
5.
1
6.
2
7.
3
GR4 =(char) 0xS0
8.
4
9. 5
10. 6
11. 7
12. 0
13.
1
14. 2
15. 3
GRS =(char) 0xA0
15. 4
17. 5
18. 6
19. 7
20. 0
21.
1
22. 2
23. 3
GR6 =(char) OxCO
24. 4
25. 5
26. 6
27. 7
28,
0
29.
1
39. 2
31, 3
-Tableau A3-
Répartition en groupe des transputers de travail du SuperNode du LIP.
ISO.
Annexes.

---

Opération
Code hexa.
Ree:istre
MSDF
(char) OXOC
Donne l'état des flags MSDF du groupe, qui permettent de vérifier
Quels sont les ST Qui ont vidé leurs buffers
SMDE
(char) OxOD
Donne l'état des flags SMDE du groupe. qui permettent de savoi
auels sont les ST Qui ont remplis leur buffer.
ERRR
(char) OxOE
Donne l'état des flags ERR du groupe. qui permettent de savoir
auels sont les ST Qui sont en état d'erreur.
PERR
(char) OxOF
Donne l'état des flags PERR du groupe, qui permettent de savoir
Quels sont les ST Qui sont en état d'erreur de oarité mémoire.
-Tableau A4-
Opérations de lecture adressées.
Opération
Codehexa.
Ree:istre
MSDEN
(char) OxOl
Sélection/dessélection des ST pour une communication maître~sclaves
SMDEN
(char) OX02
Sélection /dessélection des ST pour une communication esclave-.+maître
ANBEN
(char) 0x03
Sélection/dessélection des ST pour une synchronisation par interruption en
mode ANY : quand le flag SMDE d'un des ST ainsi sélectionnés est à 0, une
interruption est générée sur le canal EVENT du maître
ALBEN
(char) Ox04 Sélection/dessélection des ST pour une synchronisation par interruption en
mode ALL : quand les flags MSDF de tous les ST ainsi sélectionnés sont à O.
une interruption est générée sur le canal EVENT du maître
ERBEN
(char) 0x05 Sélection/dessélection de ST oour synchronisation oar interruption ERROR
ERREN
(char) 0x06 Sélection/dessélection des ST DOur analyse en cas d'erreur
BROMN
(char) 0x07 Sélection/dessélection des ST. pour positionner le mode de chargement :boot
From ROM / bootJrom link
RESEN
(char) 0x09 Sélectionne/dessélection des ST pour des opérations de contrôle (reset. analyse.
vitesse des liens)
PAREN
(char) OxOA Sélection/dessélection des ST DOur annuler l'erreur de parité mémoire: PERR
·Tableau AS·
Opérations d'écriture adressées.
181.
ADocxes.

---

Ooération
Codehexa.
Registre
(char) OxOI
Positionne le flag reset des esclaves sélectionnés au oréalable avec RESEN
(char) 0x02 Déoositionne le flag reset des esclaves sélectionnés au oréalable avec RESEN
(char) OX03
Positionne le flag analyse des esclaves sélectionnés au oréalable avec RESEN
(char) Ox04 Déoositionne le flag anah'se des ST sélectionnés au oréalable avec RESEN
(char) OxOS
Pour reinitialiser le CGA d'un ST Qui était en erreur, et sélectionné oar ERREN
Set MSDF
(char) Ox06 Positionne le flag de communication maître-+esclaves des ST sélectionnés par
MSDEN. Ce Qui 2énère une interruotion sur le canal EVENT de ces ST.
ClearMSDF
(char) 0x07 Déoositionne le fla.e: maître-+esclaves des esclaves sélectionnés oar MSDEN.
Send byte
(char) OX08 Transfert 1 octet du buffer du MT vers le buffer des ST sélectionnés oar MSDEN
SetSMDE
(char) 0x09 Positionne le flag de communication eSclave-+maître des ST sélectionnés par
SMDEN. Cela à pour effet de générer une interruption sur l'EVENT de ces ST.
OearSMDE (char) OxOA DéDositionne le flag esclave-+maître des ST sélectionnés par SMDEN.
Receive byte (char) OxOB Transfert un octet du buffer d'un (seul) ST vers le buffer du maître. ST
sélectionné au préalable par SMDEN
Combine
char) OXOC
Positionne le flag de communication maître-+esclaves des ST sélectionnés par
6&8
MSDEN, et transfert un octet du buffer du maître vers les buffers de ces ST.
Combine
char) OxOD Positionne le flag de communication esclave-+maître d'un ST sélectionné par
9& 11
SMDEN, et transfert un octet du buffer de ce ST vers celui du maître.
ClearPERR
char) OxOE
Efface le registre d'erreur de parité d'un ST sélectionné au préalable par PAREN
LINKspeed
OxIO à OxIS Changement de la vitesse des liens des ST sélectionnés par RESEN
-Tableau A6-
Opérations non adressées.
182.
Annexes.

---

Annexe 2. Transmission de plusieurs messages simultanément.
Nous ne décrivons la procédure que pour les transferts MS. A une transformation des
opérations près, la procédure est la même pour les transferts SM. L'objectif de
l'algorithme donné ci-dessous est d'envoyer des messages différents à n transputers
différents d'un même groupe g, sous l'hypothèse que les n messages ont la même taille
k. La procédure consiste à transférer individuellement le ième octet à chaque ST, à
envoyer à tous les ST une interruption pour signaler l'arrivée de ce ième octet, et à
attendre que tous aient positionné leurs flags pour acquitter chacun son octet.
for (i=O; iS: k; i++) {
for 0=0; j~; j++) {
if (INVOLVED G) {
ENABLE_MSDEN (g, j) ;
MS_TRANSFERT (msg[j] [iD;
DISABLE_MSDEN (g, j) ;
}
}
ENABLE_MSDEN (g, INVOLVED_SLAVES(g));
SET_FLAG (MSDF) ;
while (Read_FLAG_MSDF (g, INVOLVED_SLAVES(g)));
DISABLE_MSDEN (g, INVOLVED_WORKERS(g));
}
Remarque: Cet algorithme peut être étendu à des messages de taille variables en excluant de la sélection tout
transputer dont le message aété intégralement transmis.
Pour estimer à partir de quel nombre N de transputers et de quelle taille K de message
on gagne du temps avec cet algorithme d'entrelassage (n, k), par rapport l'envoi
individuel de chaque message, nous utilisons la fonction caractéristique du bus §ll.4
pour estimer le coût de chaque opération. Nous utilisons en comparaison, l'algorithme
du MT §ID.l.l pour lequel on a regroupé le transfert d'un octet avec le positionnement
du flag.
Sachant que chaque opération coûte 10 ~, la fonction caractéristique de l'àlgoritluite ci-
dessus est: (30n + 30)k.
La fonction caractéristique de l'algorithme §ill.1.1 adapté comme nous l'avons indiqué
pour transmettre k octets est: 20 + 20k. Soit, pour n transputers : 20(k + 1)n.
L'algorithme ci-dessus est meilleur que celui de §ill.l.l, si et seulement si on a :
•
(30n + 30)k ~ 20(k + 1)n.
183.
A1mcxes.

---

1C'est à dire: k S; n2:3 .
Les différentes valeurs du couple (n, k) sont données par le tableau ci-dessous, sur
lequel on constate qu'il y a un gain substantiel pour 8 transputers, et qu'il faut au
minimum 4 transputer par groupe. On remarque que pour 4 groupes de 8 transputers, on
gagnerait 200 IJ,S, ce qui n'est pas rien.
N
K
30(n + l)k ~s 20(k + l)n IJ,S Gain ~s
1
0
0
0
0
2
0
0
0
0
3
1
120
120
0
4
1
150
160
10
5
1
180
200
20
6
1
210
240
30
7
1
240
280
40
8
1
270
320
50
-Tableau A7-
Fonctlon d'entrelassage des commurucatlons
Annexe 3.
Clock synchronlzatlon algorlthms.
Name :
send_time_to_worker
Role :
Read the clock of the controller transputer and sends its value to a
given worker transputer. This function must be called whenever the the
control bus-monitor has detected a clock reading request from given
worker transputer.
Parameter :
worker transputer number.
static void
send_time_to_worker(char trp) {
char
ctr, worker, group;
char
*pt;
int
var;
var
= 0;
pt
= (char*) &var ;
worker
= Adbus[trp] [BIT];
group = Adbus[trp][GRP];
/* select the worker */
while «(char)*M_CYCLE_STAT) & Ox03) ;
*M_ADDR_BUF
= (unsigned int) (group 1MSDEN_SET);
*M_DATA_BUF
= (char) worker;
*M_CYCLE_START
= (char) 0;
184.
Annexes.

---

while «(char)*M_CYCLE_STAT) & Ox03);
/* send signal */
*M_ADDR_BUF = (unsigned int) MSDF_TRANSFER ;
*M_DATA_BUF =(char) 0;
*M_CYCLE_START =(char) 0;
while «(char)*M_CYCLE_STAT) & Ox03) ;
/* Wait ack. */
*M_ADDR_BUF =(unsigned int) (group 1MSDF_READ) ;
do {
*M_CYCLE_START = (char) 0 ;
while «(char)*M_CYCLE_STAT) & Ox03);
} while (*M_DATA_BUF & worker) ;
var
=Time 0;
/* Send the first byte */
*M_ADDR_BUF =(unsigned int) MSDF_TRANSFER ;
*M_DATA_BUF =(char) pt(O] ;
*M_CYCLE_START =(char) 0 ;
while «(char)*M_CYCLE_STAT) & Ox03);
/* Wait ack. */
*M_ADDR_BUF =(unsigned int) (group 1MSDF_READ) ;
do {
*M_CYCLE_START =(char) 0 ;
while «(char)*M_CYCLE_STAT) & Ox03) ;
} while (*M_DATA_BUF & worker);
/* Send byte 2, 3 and 4 */
for (ctr=l; ctr<4; ctr++) {
/* Send byte ctr */
*M_ADDR_BUF = (unsigned int) MSDF_TRANSFER ;
*M_DATA_BUF =(char) pt(ctr] ;
*M_CYCLE_START = (char) 0;
while «(char)*M_CYCLE_STAT) & Ox03) ;
/* Wait ack. */
*M_ADDR_BUF =(unsigned int) (group 1MSDF_REAn) ;
do {
*M_CYCLE_START =(char) 0;
while «(char)*M_CYCLE_STAT) & Ox03);
} while (*M_DATA_BUF & worker);
}
/* unselect the worker */
*M_ADDR_BUF ~ (unsigned int) (group 1MSDEN_UNSET) ;
*M_DATA_BUF =(char) worker ;
*M_CYCLE_START = (char) 0 ;
}
185.
A!mexeo.

---

Comment:
Constants and variables used by the slave-clock function and the slave
timer process
#define CDS_CODE_TIME
(char) OxSO
#define CDS_TIME_VALUE
1000000
#define CDS_READING_ERR
1
static long
sCdev
=0;
static long
proba
=1 ;
static Channel
cds_timer_channel
=NOPROCESS ;
Name:
clock_timecprocess
Role :
When CDS_TIME_VALUE
JlS have elapsed, this process sends a
request to the control-bus monitor process on the worker transputer,
meaning that the synchronisation period is soon over. It invites that
process to resynchronize its clock.
static clock_timer-process (Process* p) {
ProcToHigh 0 ;
while (1) {
ProcWait(CDS_TIME_VALUE);
ChanOutInt(&cds_timer_channel, 0) ;
}
}
Name:
clock_readin&-attempt
Role:
Function used by the worker transputer control-bus monitor to read the
master clock. The function fifst sends a clock reading request on the
control-bus. It then receives four bytes from the controller tranputer, and
computes the mean round trip delay. If the half round trip delay is within
CDS_READING_ERR JlS from the mean delay, the function resets the
high priority-Ievel clock and the timer process, and then returns 0
meaning that it has reached the rapport; elsewhere, it returns -1, and the
monitor can make a new attempt.
static int
clock_readin&-attempt 0 {
static double mean =Il ;
static int
n
=1 ;
static double d;
static int
Tl, T2, var ;
static char
*pt;
static double w = 0 ;
pt
= (char*) &var ;
/* Bus-monitor special code */
DISABLE_EVENT (MSDF) ;
186.
Annexes.

---

DISABLE_EVENT (SMDE) ;
SET ENABLE EVENTS GLOBAL;
-
/*****E~****/
/* Send clock reading request */
*S_DATA_BUF
=CDS_CODE_TIME;
UNSET SM;
ENABLE_EVENT(SMDE) ;
WAIT_SM_EVENT 0;
DISABLE_EVENT(SMDE) ;
SET_ENABLE_EVENTS_GLOBAL ;
/* Wait for start signal */
ENABLE_EVENT (MSDF) ;
WAIT_MS_EVENT 0;
DISABLE_EVENT (MSDF) ;
Tl
= Tirne 0;
/* start round trip rimer */
UNSET_MS ;
SET_ENABLE_EVENTS_GLOBAL ;
/* Wait and receive the frrst byte */
while (!(*S_EVENT_STAT & MSDF» ;
T2
=Tirne 0 ;
/* end of round trip */
pt[O]
=(char) *S_DATA_BUF ;
UNSET_MS ;
SET_ENABLE_EVENTS_GLOBAL;
/* Wait and receive byte 2 */
ENABLE_EVENT (MSDF) ;
WAIT_MS_EVENT 0;
DISABLE_EVENT (MSDF) ;
pt[l]
= (char) *S_DATA_BUF ;
UNSET_MS ;
SET_ENABLE_EVENTS_GLOBAL;
/* Wait and receive byte 3 */
ENABLE_EVENT (MSDF) ;
WAIT_MS_EVENT 0 ;
DISABLE_EVENT (MSDF) ;
pt[2]
=(char) *S_DATA_BUF ;
UNSET_MS ;
SET_ENABLE_EVENTS_GLOBAL ;
/* Wait and receive byte 4 */
ENABLE_EVENT (MSDF) ;
WAIT_MS_EVENT 0 ;
DISABLE_EVENT (MSDF) ;
pt[3]
=(char) *S_DATA_BUF;
UNSET_MS;
SET_ENABLE_EVENTS_GLOBAL ;
187.
Amexcs.

---

/* compute the half round trip delay */
d
= (double) «1'2 - Tl) / 2) ;
/* compute the the mean and the standard deviation */
n++ ;
mean = «double)«(n - 1) * mean) / n))
+«double)(d / n)) ;
w
=w + «d - mean) * (d - mean)) ;
sCdev
= w / (n - 1) ;
/* Standard deviation */
proba =1 - (sCdev * scdev); /***CDS_READING_ERR is 1***/
if (abs(d - mean) > CDS_READING_ERR)
retum (-1) ;
/* Compute master time and reset the dock */
var
= var + «int) d) - 1'2 ;
SetTime (Time 0 + var) ;
/* Consume the overlaping time */
if (var < 0) {
var
=abs (var) ;
while (var--) ;
}
ChanInInt (&cds_timer_channel); /* restart the Timer process */
retum (0);
}
188.
AJmcxeo.

---

Annexe 4.
Mesures de l'horloge.
Mesure de la synchronisation du Mf avec le STO sur 100 secondes. La synchonisation est faite toutes les secondes.
t:..
t:..
Master clock : T Slave clock : S
IT+t:.. -SI
1
10 9
10
סס
oo3
1000101
89
(89 is the initial dilTen:nce between the Iwo cloch)
2
9
9
2000397
2000411
5
3
9
9
3000647
3000660
4
4
9
9
4000903
4000917
5
5
9
9
5001159
5001173
5
6
9
9
6001415
6001429
5
7
9
10
7001671
7001686
5
8
9
9
8001927
8001941
5
9
9
9
9002183
9002196
4
10 9
9
10002439
10002453
5
11 9
9
11002695
11002709
5
12 9
9
12002951
12002965
5
13 9
9
13003207
13003220
4
14 9
9
14003463
14003477
5
15 9
10
15003719
15003735
6
16 9
9
16003975
16003989
5
17 9
9
17004231
17004244
4
18 9
9
18004487
18004501
5
19 9
9
19004743
19004757
5
20 9
9
20004999
20005012
4
21
9
9
21005255
21005270
6
22 9
9
22005511
22005524
4
23 9
9
23005767
23005781
5
24 9
9
24006023
24006037
5
25 9
9
25006279
25006292
4
26 9
9
26006535
26006549
5
27 9
9
27006791
27006805
5
28 9
9
28007047
28007060
4
29 9
9
29007303
29007317
5
30 9
9
30007559
30007574
6
31 9
9
31007815
31007830
6
32 9
9
32008071
32008085
5
33 9
9
33008327
33008340
4
34 9
9
34008583
34008597
5
35 9
9
35008839
35008853
5
36 9
9
36009095
36009108
4
37 9
9
37009351
37009366
6
38 9
9
38009607
38009621
5
39 9
9
39009863
39009876
4
40 9
9
40010119
40010134
6
41 9
9
41010375
41010388
4
42 9
9
42010631
42010645
5
43 9
9
43010887
43010901
5
44 9
9
44011143
44011156
4
45 9
9
45011399
45011413
5
46 9
9
46011655
46011669
5
47 9
9
47011911
47011924
4
48 9
9
48012167
48012181
5
49 9
10
49012423
49012438
5
50 9
9
50012679
50012693
5
51 9
9
51012935
51012949
5
52 9
9
52013191
52013204
4
53 9
9
53013447
53013461
5
54 9
9
54013703
54013717
5
55 9
9
55013959
55013973
5
56 9
9
56014215
56014228
4
57 9
9
57014471
57014485
5
58 9
9
58014727
58014740
4
189.
Annexes.

---

59 9
9
59014983
59014997
5
60
9
9
60015239
60015253
5
61
9
9
61015495
61015510
6
62 9
9
62015751
62015764
4
63 9
9
63016007
63016022
6
64 9
9
64016263
64016276
4
65 9
9
65016519
65016533
5
66 9
9
66016775
66016789
5
67 9
9
67017031
67017044
4
68 9
9
68017287
68017301
5
69 9
9
69017543
69017557
5
70 9
10
70017799
70017814
5
71
9
9
71018055
71018068
4
72 9
9
72018311
72018325
5
73 9
9
73018567
73018580
4
74 9
9
74018823
74018837
5
75 9
9
75019079
75019093
5
76 9
9
76019335
76019349
5
77 9
9
77019591
77019605
5
78 9
9
78019847
78019861
5
79 9
9
79020103
79020117
5
80 9
9
80020359
80020373
5
81
9
9
81020615
81020629
5
82 9
9
82020871
82020885
5
83 9
9
83021127
83021141
5
84 9
9
84021383
84021397
5
85 9
9
85021639
85021652
4
86 9
9
86021895
86021909
5
87 9
9
87022151
87022165
5
88 9
9
88022407
88022420
4
89 9
9
89022663
89022677
5
90 9
9
90022919
90022933
5
91
9
9
91023175
91023188
4
92 9
9
92023431
92023445
5
93 9
9
93023687
93023701
5
94 9
9
94023943
94023957
5
95 9
9
95024199
95024212
4
96 9
9
96024455
96024469
5
97 9
9
97024711
97024726
6
98 9
9
98024967
98024981
5
99 9
10
99025223
99025238
5
100 9
9
100025479
100025492
4
190.
ADncxes.

---

Annexe 5 : Programmation des prédicats et points d'arrêt.
'* Constantes
#define HIGH(prio)
prio *'
:: ProcToHighO ;
/* Debut de séquence protégée *'
#define LOW(prio)
if (prio) ProcToLowO ;
/* Fin séquence de protégée
*'
#defme _NOOE_number
_node_number
#defme CDS_PREDICATE_MAX
32
#defme CDS_SPY_OEFAULT_TIME
25000
#defme CDS_USER_BP
1
#defme CDS_SYST_BP
2
#defme CDS_SE'CUSER_BP
3
#define CDS_SET_SYST_BP
4
#define CDS_BP_END
5
#defme CDS_SPY_BP_STATUS
6
#defme CDS_SPY_BP_UST
7
#defme CDS_SPY_BP]ROC
8
#derme CDS_SPY_All_PROC
9
#define CDS_SPY_STATUS
10
#defme CDS_SPY_TIMER
11
#define CDS_SPY_PREDICATE
12
#defme CDS_PREDICATE
13
/* pointeurs de la liste des processus arrêtés et des prédicats *'
typedef struct CDS_BpoinUt*
COS_Pt_Bpoint ;
typedef struct CDS_Predic_st*
COS_Pt_Predic ;
/* ## liste des processus engages dans un point d'arret *'
struct CDS_BpoinUt {
int
*pws;
int
pid ;
int
place;
int
date;
int
status ;
CDS_Pt_Bpoint
next;
} ;
/* ## liste des predicats actifs *'
struct CDS_Predic_st {
int
num;
int
node;
int
value;
int
status ;
int
reserved;
CDS_Pt_Predic
left ;
CDS_Pt_Predic
roght;
} ;
/* ## variables de point d'arret et de predicat *'
static int
cds_break_status =cds_break_action = cds_break_nbp =cds_break_nurnber =0 ;
static int
cds_break_node
=cds_break_value =cds_break_end =cds_spy_tirner
= 0;
static int
*cds_break..Jlid;
static char
cds_spy_status =cds_spy_flag =0;
CDS_Pt_Bpoint
cds_break_list ;
CDS_Pt_Predic
cds..Jlredicate_list ;
static Channel
cds_bpoinLchanl =cds_bpoint_chan2 =NOPROCESS;
,. Tableau des masques des predicats *'
static int cds_mask[32l =
{OxOl.0x02,0x04.0x08.
OxlO.0x20.0x40.0x80.
OxlOO.0x200.0x400.0x800.
OxlOOO. Ox2000. Ox4000. Ox8000.
OxlOOOO. Ox20000. Ox40000. OXSOOOO.
OxlOOOOO. Ox200000. Ox400000. Ox800000.
OxlOOOOOO. 0x2000000. Ox4000000. Ox8000000.
OxlOOOOOOO. Ox20000000. Ox40000000. OXSOOOOOOO} ;
/* Fonctions de base de gestion des prédicats et points d'arrêt *'
191.
Annexes.

---

extern void
cds_broadcast(char size, char* msg) ;
extern int
cds_receive(char* buf) ;
extern int
cds_delete...,predicate(int num) ;
extern int
cds_find...,predicate(int num) ;
extern int*
cds_find_or_create...,predicate(int num) ;
1******************************************************************************1
1* Function:
CDS_Predicate
*1
1* Role: Positionne, supprime. invalide ou lit la valeur d'un predicat et diffuse la modiffication. *1
1*
Si cela est demande, la validation du predicat declanche le point d'arret
*1
1* parametre:
. numero de predicat
*1
1*
. code de l'operation a effectuer: (-3) suppr. (-2) lecture valeur. (-1) lecture
*1
1*
etat (vrai, faux), (0) invalide, (1 à MAX) postionne le bit nOdu predicat.
*1
1*
. Type d'action a declencher pour le BP si le predicat est vrai
*1
1* Retour:
Valeur du predicat. ou descripteur de BP
*1
1******************************************************************************1
int* CDS_Predicate(int n. int b. char c) {
CDS_Pt_Predic
pp ;
int
prio. val. *ws ;
char
bufIlO] ;
1* controle de validite *1
if «n <= 0) Il (b < -3) " (b >= CDS_PREDICAlE_MAX))
return (0) ;
IDGH(prio) ;
val
= 0;
switch (b) {
case -3:
1* suppression d'un predicat *1
cds_delete...,predicate(n) ;
break ;
case -2:
1* lecture valeur du predicat *1
if (pp = cds_find...,predicate (n))
val
= pp->value ;
LOW (prio);
return «inl"') val) ;
case -1:
1* lecture du predicat *1
if (pp = cds_find...,predicate(n))
val
= pp->value ;
break ;
case 0:
1* Invalide le predicat *1
if (!(Pp = cds_find...,predicate(n)))
break ;
if «pp->status = pp->value) && «(pp->status & n)=n) Il (pp->status == 0))) {
pp->status
= 0 ;
val
= 0;
bufIOl
= CDS_PREDICAlE;
bufIl]
= _NODE_number;
memcpy(&bufT2l. (char*) &n. 4);
memcpy(&bufT6J, (char*) &val. 4) ;
cds_broadcast (10, buf) ;
/* diffuse le message *1
}
break;
default :
1* modifie le predicat *1
if (!(Pp = cds_find_or_create...,predicate(n)))
break ;
val
= pp->status 1cds_mask[b-l] ;
1* active le BP si le predicat est vrai *1
if «(val & n)==n) && «c = CDS_SET_USER_BP) Il (c = CDS_SET_SYST_BP))) {
pp->status
= val ;
ws
= CDS_Enable_Bpoint (c. n) ;
LOW (prio);
return «inl"') ws) ;
}
1* verifie si le bit n'est pas postionne *1
if (!(pp->status & cds_mask[b-l])) {
pp->status
= val ;
bufTO]
= CDS_PREDICAlE;
bufTl]
= _NODE_number;
192.
Amlexcs.

---

memcpy(&bufI2J, (char*) &n, 4);
memcpy(&buf[6J, (char*) &val, 4) ;
cds_broadcast (lO, buf) ;
/* diffuse le message */
}
}
LOW (prio);
return ((int*) (val & n)=n) ;
}
/******************************************************************************/
/* Function:
cds...J)redicate..,proc_func
*/
/* Role: Fonction de mise a jour des predicats utilisee par le processus gestionnaire
*/
/* parametre:
. type de mise a jour; (0) modification; (1) mise a vrai; (2) mise a faux
*/
/*
. buffer contenant le descripteur du predicat
*/
/*
. noeud ayant demande la mise a vrai ou faux
*/
/*
. numero de predicat
*/
/******************************************************************************/
static void cds_predicate-proc3uDc (int code. char *buf, int node, int value) {
CDS_Pt_Predic
pp ;
int
b. n •prio ;
HIGH (prio) ;
switeh (code) {
case 0 :
/* Met a jour un predicat defini par buf */
memcpy((char*) &n, &buf[2J, 4) ;
/* numero predicat */
memcpy((char*) &b, &buf[6J. 4) ;
/* valeur du predicat */
/* cherche ou cree le predicat */
if(!(Pp =cdsJmd_oureate..,predicate(n))) {
HSemP (Strace) ;
printf("CDS ERRl'n") ;
HSemV (Straee) ;
}
else {
/* met a jour le predicat */
if (b == 0)
pp->value
=0 ;
else
pp->value
= pp->value 1b ; .
pp->status
=pp->status 1pp->value ;
pp->node
=bufIlJ ;
/* noeud eriletteur */
}
break ;
case 1 :
/* Met le predicat value a vrai */
n
=value
/* numero de predicat */
b
=value
/* numero de predicat */
/* cherche ou cree le predicat */
if(!(Pp =cdsJmd_or_create..,predicate(n))) {
HSemP (Strace) ;
printf("CDS ERRl'n") ;
HSemV (Strace) ;
}
else {
1* met a jour le predicat */
pp->value
=pp->value 1b ;
pp->status
=pp->status 1pp->value ;
pp->node
=node; 1* noeud emetteur */
}
break ;
case 2:
1* Remet le predicat value a 0 */
if(pp =cds_find..,predicate(value)) {
pp->value
=0 ;
pp->status
== 0 ;
pp->node
=node; 1* noeud emetteur */
}
}
LOW (prio);
}
1******************************************************************************/
193.
ADneXeIi.

---

/'" Function:
CDS_Enable_Bpoint
*/
/'" Role: Active le point d'arrel. Un messages d'arret est diffuse a tous les noeuds. Blocante
*/
/'"
jusqu'a la fm de cette diffusion
*/
/'" parametre:
. Type d'action a realiser
*/
/'"
. valeur associee au point d'arret
*/
/'" Retour:
Identificateur du point d'arret; (0) si le BP etait deja actif;
*/
/"'*****************************************************************************/
int* CDS_Enable_Bpoint(char type. int val) {
int
*ws, prio, node. ct ;
char
buf[101 ;
/'" verifie si un BP est actif */
lnGH(prio) ;
if (cds_brealcstatus Il «type != CDS_USER_BP) && (type != CDS_SYST_BP)
&& (type != CDS_SET_USER_BP) && (type != CDS_SET_SYST_BP))) {
LOW (prio);
retum (0);
}
cds_break_status =·2;
/'" lit l'adresse du processus */
#pragma asm
LDLP
0
STL
[wsl
#pragma endasm
/'" copie le type et l'adresse du processus */
node
= _NODE_number ;
buf[Ol
= type ;
buf[11
= node ;
memcpy(&buf[21. (char*) &val, 4) ;
memcpy(&buf[61. (char*) &ws. 4) ;
cds_broadcastOO. but) ;
/* Diffuse un message d'activation du BP: type et ws */
ChanInInt(&cds_bpoint_chanl) ;
/* Attend l'activation du BP */
ProcReschedule 0 ;
/'" Verifie si on est bien l'auteur du BP */
if «cds_breal,--pid != ws) Il (cds_break_node != node» {
LOW (prio);
retum (0);
}
LOW (prio);
return (ws) ;
}
/"'*****************************************************************************/
/'" Function:
CDS_Disable_Bpoint
*/
/'" Role: Desactive le point d'arrel. Un point d'arret ne peut etre desactive que sur le processeur */
/'"
ou il a ete active
*/
/'" parametre:
. Identificateur du point d'arret
*/
/'" Retour:
(0) si la desactivation est acceptee; (-1) si le BP n'est pas actif; (-2) si
*/
/'"
l'identificateur n'est pas celui du point d'arret en cours
*/
/"'*****************************************************************************/
int CDS_Disable_Bpoint(int* ws) {
int
prio;
char
buf;
/'" verifie qu'il y a un BP */
lnGH(prio) ;
if «cds_break_status != 1) Il cds_break_end) {
LOW (prio);
return (·1) ;
}
/* controle d'identite */
if «ws != cds_break-pid) Il (cds_break_node != _NODE_number» {
LOW (prio);
return (-2) ;
}
/'" diffuse un message de fm de point d'arret */
cds_bresle_end
= 1 ;
/'" empeche le double arret */
buf
= CDS_BP_END ;
cds_broadcast(I, &but) ;
194.
Amlexes.

---

LOW (prio);
return (0) ;
}
,
~
~ Function:
CDS_Bpoint
.,
~ Role: Point d'arret conditionnel. L'action associee n'est execute que si la condition globale
.,
~
est active. Le processus est ensuite suspendu et n'est reveille que quand le
.,
~
signal de fl1l est recu, et que tous les autres processus se sont arretes. Les 10 .,
~
premiers parametres donnes sont passes a l'action; les autres sont donnes
.,
~
dans une structure 1hème paramètre, exploitable avec la fonction va_arg
.,
~ parametre:
. Numero du processus. Négatif pour une arrêt impératif, positif sinon
.,
~
. Place d'arret
.,
~
. Nom de l'action a effectuer lors de l'arret
.,
~
. Nombre de parametres de l'action
.,
~
. liste de parametres
.,
~ Retour:
valeur retoumee par l'action; (0) si le point d'arret n'est pas actif
.,
,
~
int CDS_Bpoint(int num, int place, int (·action)O, int nb,
) {
int
·ws, prio, val[10), ct, ret ;
struct
CDS_BpoinUt
pt ;
va_list
ap;
~ verifie si le BP est actif·'
ü(num=O)
return (0) ;
HIGH (prio) ;
ü ((num > 0) && (cds_brealutatus != 1)) {
LOW (prio);
return (0) ;
}
,. lit l'adresse du processus .,
#pragmaasm
LDLP
0
S11..
[ws)
#pragma endasm
~ enregistre le processus dans la liste du Bp·,
pt.pws
= ws;
pt.pid
= num ;
pt.place
= place;
pt.date
= Time 0 ;
pt.status
= 1 ;
pt.next
= cds_break_list ;
cds_break_list
= &pt ;
cds_break_number++ ;
~ suspend le processus si le BP n'est pas actif·'
ü(num <0) {
ü (cds_break_status != 1) {
#pragma asm
STOPP
#pragma endasm
}
ptpid
= -num ;
}
cds_break_nbp++ ;
~ realise l'action confonne au type du Bp·,
ü (cds_break_action = CDS_SYST_BP) {
~ action systeme: appel scanner .,
System_action (CDS_break_value) ;
ret
= 0;
}
else {
~ action deflnie : utilisateur .,
va_start (ap, nb) ;
ct
=0;
ü(nb>=0)
while ((ct < nb) && (ct < Il)) {
val[ct) = va_arg (ap, int) ;
et++;
195.
ADDens.

---

}
if (action != NULL)
Defauluction 0 ;
else
if «nb >= 0) && «cds_break_action = CDS_USER_BP)
Il (cds_break_action = CDS_SET_USER_BP))) {
switch(ct) {
caseO:
ret =action() ;
break ;
case 1 :
ret = action(val[O]) ;
break ;
case 2:
ret = action(val[Ol, val[l]) ;
break ;
case 3:
ret = action(val[O], valUl, val[2]) ;
break ;
case 4 :
ret = action(val[0], val[ll, val[2l, val[3]) ;
break ;
cases:
,
ret = action(val[Ol, val[ll, val[2l, val[3], val[4]) ;
break ;
case 6:
ret = action(val[Ol, val[ll, val[2l, val[3], val[4l, vallS]) ;
break ;
case? :
ret = action(val[Ol, val[ll, val[2], val[3l, val[4], val[Sl, val[6]) ;
break ;
case 8:
ret = action(val[Ol, val[ll, val[2l, val[3l, val[4l, val[Sl, val[6l, val[?]) ;
break ;
case 9:
ret = action(val[O], val[ll, val[2l, val[3], val[4l, val[Sl, val[6l, val[?], vallS]) ;
break ;
case 10:
ret = action(val[Ol, val[ll, val[2], val[3l, val[4], val[Sl ,val[6], val[?l, val[8l, val[9]) ;
break ;
default:
ret = action(val[Ol, val[l], val[2l, val[3l, val[4l, val[S], val[6], val[?], val[8l, val[9], ap);
}
va_end (ap) ;
}
ProcToHigh 0 ;
/* Protection */
cds_break_nbp-- ;
/* Reveille le processus gestionnaire de point d'met */
if ((!cds_break_nbp) && (cds_break_status == -1»
ChanOutInt(&cds_bpoinCchan2,O) ;
plstatus = 0 ;
,
/* suspend le processus */
#pragmaasm
STOPP
#pragma endasm
ProcReschedule 0 ;
cds_breal,-number-- ;
/* attend que l'espion termine l'observation */
if (cds_spy_flag) {
HSemP (Spy) ;
HSemV (Spy) ;
}
LOW (prio);
return (ret) ;
}
196.
Annexes.

---

,.
/
,. Processus:
cds_bpoint...,predicate...J>rocess
./
,. Role: Processus gestionnaire de points d'arret et des predicats. li recoit les messages
./
,.
correspondants diffuses par les processus utlisatuer sur le bus
./
,.
/
static cds_bpoinCpredicate_process(Process· p) {
int
·ws, ct. sz. node ;
char
buf[20) ;
CDS_Pt_Bpoint
pt ;
CDS_Pt_Bpoint
ps ;
node
=_NODE_number ;
ProcToHighO ;
while (1) {
,. Attend la demande et active le Bp·/
buf[O]
=0;
while «buf[O] != CDS_USER_BP) && (buf[O] != CDS_SYST_BP)
&& (buf[O) != CDS_SET_USER_BP) && (buf[0] != CDS_SET_SYST_BP» {
sz =cds_receive(buO ;
if (buf[O] = CDS_PREDICATE)
cds...,predicate...,proc_func(O. buf. O. 0) ;
,. Recopie les valeurs decrivant le point d'arret·/
cds_breaJeaction =buf[O] ;
,. type d'action ./
cds_brealenode
=buf[l) ;
,. noeud initiateur./
memcpy«char*)&cds_break_value. &buf[21. 4) ;
,. valeur d'arret./
memcpy«char*)&cds_break...,pid. &buf[6). 4) ;
,. pid de l'initiateur ./
,. positionne a vrai le predicat ayant occasionne l'arret ./
if «cds_break_action = CDS_SELUSER_BP) Il (cds_break_action = CDS_SET_SYST_BP»
cds...,predicate...,proc_func(1. O. cds_break_node. cds_break_value) ;
,. reveille le processus qui a tente d'activer le BP ./
if (cds_break_status = -2)
ChanOutInt(&cds_bpoinUhanl. 0 ) ;
cds_break_staluS =1 ;
/. active le Bp./
,. Reveille les processus engages volontairement dans le Bp./
pt
=cds_break_list ;
while (pt) {
if (pt->pid < 0) {
ws
=pt->pws ;
#pragmaasm
LDL
[ws)
RUNP
#pragma endasm
}
pt
=pt->next ;
}
ProcToLow 0 ;
ProcReschedule 0 ;
,. Attend la fin du point d'arret */
buf[O]
=0;
while (buf[O] != CDS_BP_END) {
sz =cds_receive(buO ;
if (buf[O] = CDS]REDICATE)
cds...,predicate...,proc_func(O. buf. O. 0) ;
}
ProcReschedule 0 ;
ProcToHighO ;
cds_break_status =-1 ;
,. attend la fin des processus engages dans le BP. Le dernier processus le revcille */
if (cds_break_nbp ) {
ChanInInt(&cds_bpoinCchan2) ;
ProcReschedule 0;
,. Attend que le processus qui l'a reveille se suspende */
}
,. attend que l'espion termine l'observation ./
19i.
Anoexcs.

---

HSemP (Spy) ;
HSemV (Spy) ;
}
/* Reveille les processus engages dans le BP */
pt
= cds_break_list ;
ps
=NULL;
while (pt) {
if (pt->pid >= 0) {
ws
= pt->pws ;
.
#pragma asm
LDL
[ws]
RUNP
#pragma endasm
if (ps = NULL)
cds_break_list
= pt->next ;
else
ps->next
= pt->next;
e1se{
if (ps = NULL)
cds_break_list
= pt ;
ps
= pt;
}
pt
= pt->next ;
}
1* positionne a faux le predicat ayant occasionne l'arret·/
if «cds_break_action = CDS_SET_USER_BP) Il (cds_break_action = CDS_SET_SYST_BP))
cds.jlredicate.jlroc_func(2. O. cds_break_node. cds_break_value) ;
/* desactive le point d'arret ./
cds_break_status = 0 ;
cds_break_end
=0;
cds_break.jlid
=NULL;
}
198.
Annexes.

---

Annexe 6.
Comparatif des modèles classiques de SMAP.
Momentrrvoe
Observation du comportement
Détection des erreurs
En ligne
· Observation des événements en temps réel
· Analyse des événements
· Utilisation de points d'arrêt pour contrôler
· Utilisation d'automates pour l'analyse et
l'exécution
l'observation en temps réel.
· Moniteur logiciel pour la collecte et le
· Moniteur matériel ou hybride pour la
transport des observations.
collecte des observations.
....-_..._......_................_-----_..........._-.......-_......._---........--_.. ...._..._--...._----_...--_......_....._-_....._--_...._-------...._-----_..---
+ Observation fine d'un petit nombre de
+ Observation d'un grand nombre de
processus
processus.
+ Analyse interactive du programme
+ Détection instantanée des erreurs
+ Modification du comportement de
+ Faible interférence: indépendance avec les
processus
processus
------ ..- .... _----_........-----......._......-.._-....._--_......---.....- ....... _-
- ...._----_.._-----_.._-----_...._--............_--..........._---.._-----
• Dépendance avec les processus: le mauvais
- Nécessité d'un matériel dédié à la capture et
fonctionnement d'un processus peut
la reconnaissance des événements
perturber le moniteur
- Réaction: Décalage possible entre
• Forte interférence à l'exécution
l'occurrence et la détection d'un événement
• Inadapté pour un environnement temps réel
· Difficulté de donner un sens aux
- Observation limitée à l'état courant du
informations collectées
système: latence, propagation et migration
· Limitation du domaine des erreurs
des erreurs.
- Portabilité et coûtprohibitif.
Après
· Observation de l'historique d'un grand
· Interprétation du comportement du
exécution
nombre de processus avec plusieurs niveaux
programme à l'aide d'automates
d'abstraction.
· Collecte de traces avec un moniteur logiciel
· Collecte de traces avec un moniteur logiciel
· Langage de spécification des événements et
· Interface d'observation élaborée
du comportement des processus
.... _---_.......-----_.............-......_-----_......- ......._.._---.........._---.......
..... _.. _------------_...._--_......-...._-_.._-_....._.._---_..._--_.
+ ~tition de l'observation de l'historique
+ Répétition de l'observation
ou de la simulation de l'exécution.
+ Faible interférence à l'exécution
+ Faible interférence à l'exécution
+ Utiliser les mêmes traces pour appliquer
+ Ordonnancement des événements
plusieurs modèles de comportement
-_............_-_...---_.__.._----_....._-----_._---_. ------------------------_....----------------_..
- Saturation du support d'enregistrement
• Saturation du support d'enregistrement
- Vue limitée de l'exécution et insuffisance
- Adéquation des informations collectées avec
des informations collectées
l'erreur recherchée
-Tableau Al·
Comparatif des modèles clasS1qUes de SMAP.
199.
Am1exCll.

---