Branches causalement indépendantes d’un processus “mémoire”

En fait, on peut voir cette même exécution comme l’exécution de deux branches causalement indépendantes sur le même processus, comme représenté par la fi-gure 2.8. Considérer une causalité potentielle plus précise que la relation de Lam-port, et donc un ordre local de causalité partiel revient à considérer l’existence de plusieurs branches d’exécution causalement indépendantes dans un même pro-cessus. L’exécution locale peut donc être vue comme un graphe orienté acyclique

(DAG) d’évènements.

L’existence de relation de fausse causalité est plus évidente dans les systèmes formés de processus à fils d’exécution multiples (multi-thread) [DAM 99]. Les mul-tiples fils d’exécution qui constituent un processus peuvent alors être vus comme plusieurs “sous-processus” communiquant entre eux par messages. L’existence d’un ordre de causalité locale partiel sur ces processus à fils d’exécution multiples devient alors évidente ; l’exécution de chaque processus est un ensemble d’évène-ments partiellement ordonnés par la relation de Lamport.

Si la représentation en plusieurs sous-processus peut être une solution inté-ressante dans le cas des processus à fils d’exécution multiples, elle ne l’est pas dans les autres cas. En effet, il est difficile dans la pratique manipuler le pro-cessus comme plusieurs sous-propro-cessus, et par exemple être capable de faire des images d’état indépendantes pour chacun de ces sous-processus.

2.7.2 Pourquoi une causalité potentielle ?

Éviter les liens de fausse causalité peut être utile dans différents domaines tels que le debugging distribué [MIT 00], la détection dynamique d’erreur de syn-chronisation [TAR 98a], mais aussi dans le domaine qui nous intéresse ici : la tolérance aux pannes par recouvrement arrière.

En effet, considérer une causalité potentielle plus précise augmente le nombre d’exécutions équivalentes, puisque certains évènements locaux qui ne sont pas causalement liés peuvent être exécutés dans n’importe quel ordre. De manière générale, le nombre d’évènements à ordonner de façon stricte pour assurer l’équi-valence d’une réexécution diminue : dans [SIL 99b], les auteurs utilisent les spé-cificités de l’ordonnancement des messages dans une application pour réduire le nombre de réceptions à journaliser. Par exemple, dans la figure 2.7, les deux récep-tions delireValeur()n’ont pas à être journalisées de façon stricte entre elles. Grâce à cette réduction, les auteurs proposent un protocole de validation d’état global (output-commit) efficace.

L’utilisation de la sémantique des messages pour identifier les liens de fausse causalité entre les réceptions de messages est généralisée par Enokido et al. dans [ENO 98]. Les auteurs proposent un protocole qui assure l’ordonnancement causal des réceptions de message mais qui tient compte d’un ordre de précédence

significative des messages. Ils montrent que certaines réceptions n’ont pas besoin

d’être ordonnées sans pour autant violer l’ordonnancement causal ; ces réceptions sont liées par des liens de fausse causalité. Identifier ces liens leur permet de pro-poser un protocole plus efficace.

Dans le cadre de la tolérance aux pannes par points de reprise, un ordre de cau-salité potentielle plus précis permet de relâcher les conditions de cohérence d’un état global par rapport à une définition de la cohérence se basant sur la relation de Lamport. Par exemple, dans [LEO 94], les auteurs exploitent la sémantique des messages pour déterminer le dernier état recouvrable. Ils classifient les messages dans trois catégories : écriture, lecture et autres, et montrent que certains états,

2.8 Conclusion 31

bien qu’incohérents par rapport à la relation de Lamport, sont recouvrables selon la sémantique des messages orphelins. Nous verrons par la suite que le protocole proposé dans cette thèse tire parti de la même manière d’un ordre de causalité potentielle plus précis que la relation de Lamport.

2.8 Conclusion

Nous avons présenté dans ce chapitre les trois aspects essentiels de la tolé-rance aux pannes par recouvrement arrière : la mémoire stable, la persistance et la recouvrabilité d’état. Ce dernier point se reposant principalement sur les relations de causalité entre les évènements, nous avons présenté le concept de

causalité potentielle. Une relation de causalité potentielle pour une exécution

dis-tribuée est une relation qui évite certains liens de fausse causalité entre les évè-nements en relâchant l’ordre de causalité local, considéré comme un ordre total dans la relation de Lamport. Nous avons vu que considérer une relation de cau-salité potentielle plus précise était utile dans le cadre de la tolérance aux pannes par recouvrement arrière ; cela permet par exemple de relâcher les conditions de cohérence donc de recouvrabilité d’un état global.

Nous avons présenté les deux grandes familles de protocoles de tolérance aux pannes par recouvrement arrière, i.e. par points de reprise et par journalisation des messages, et avons montré qu’il n’existe pas de solution unique qui soit adap-tée à toutes situations. Selon les propriétés de l’infrastructure physique utilisée mais aussi selon les propriétés de l’application, une solution donnée peut engen-drer de mauvaises performances, voir même être totalement inapplicable.

C’est cette constatation qui va motiver le développement d’un protocole par points de reprise adapté à notre contexte de travail présenté dans le chapitre sui-vant. Nous allons voir en effet que si les protocoles de journalisation de messages peuvent facilement s’appliquer dans ce contexte, les protocoles par points de re-prise coordonnés ou induits par message classiques ne peuvent pas s’appliquer directement. Il nous faut donc proposer une solution par points de reprise adap-tée ; cette solution est présenadap-tée dans le chapitre 4.

Chapitre 3

Contexte et Analyse

Nous décrivons dans ce chapitre le contexte de notre travail : le modèle à objets communicants ASP [CAR 04b], et son implémentation en Java ProActive [CAR 06c]. Le but de ce chapitre est d’identifier clairement les contraintes induites par le mo-dèle et son implémentation, et leurs conséquences dans le cadre d’un protocole de tolérance aux pannes par point de reprise. Ces contraintes doivent être respectées par le protocole de tolérance aux pannes, mais aussi assurées en cas de panne et de reprise du système. Nous identifions de plus les propriétés qui pourront être exploitées dans ce cadre.

3.1 Le modèle : ASP

ASP pour Asynchronous Sequential Processes (Processus Séquentiels Asyn-chrones) est un calcul d’objet basé sur la notion d’activités communicantes. Les activités s’exécutent en parallèle, mais les opérations au sein d’une activité sont séquentielles.

3.1.1 Activités

De façon simplifiée, une activité1est un processus unique (thread d’exécution) ainsi qu’un ensemble d’objets. Parmi ces objets, un est dit actif, et les autres sont dits passifs. L’objet actif est le point d’entrée de l’activité : les autres activités ne peuvent référencer que cet objet actif. De manière générale, le modèle ASP ne per-met pas le partage des objets passifs entre activités ; les seuls objets qui peuvent avoir une référence sur un objet passif d’une activité sont les objets appartenant à cette même activité. Un objet passif d’une activité ne peut avoir de référence sur un objet passif d’une autre activité, mais peut avoir une référence vers une autre activité.

Propriété 3.1.1.1 (Pas de partage de mémoire) Les activités ne partagent pas

de mémoire ; elles ne peuvent communiquer entre elles que par message.

1Nous utiliserons à partir de maintenant le terme activité pour désigner l’unité d’exécution locale d’une exécution répartie

La Figure 3.1 donne un exemple de topologie d’objets dans une configuration formée de trois activités, représentées par les zones grises. Les objets sont repré-sentés par des ellipses, les références par des flèches et les objets actifs par des ellipses en gras. Sur cette figure, l’absence de partage de mémoire est représenté par le fait que les seules flèches d’une activité à une autre sont des flèches en gras pointant vers des objets représentés par des ellipses en gras (référence vers un objet actif). Activité i Objet Actif Objet Passif Activité j Activité k