Analyse des résultats pour le protocole de DLC

Nous avons appliqué notre méthode de vérification au protocole que nous avons mis au point pour DLC, sur l’ensemble de la base de tests. Au cours du développement du protocole, notre méthode nous a permis de détecter plusieurs fois de possibles livelocks ou deadlocks. Les contre-exemples détaillés ont facilité la compréhension de la source de ces erreurs. Nous avons pu ainsi itérer sur la conception du protocole en s’assurant qu’une nouvelle modification n’introduisait ni livelock, ni deadlock. Aucune possibilité de livelock ou de deadlock n’est détectée sur la version courante de notre protocole, telle que présentée dans la section 2.7.

Les résultats d’équivalence entre la spécification et le modèle de l’implémentation sont discutés plus en détail dans la suite de cette section.

Équivalence entre spécification et modèle d’implémentation

Au même titre que les deadlocks et les livelocks, la vérification d’équivalence entre la spécification du système et le modèle de son implémentation nous a été très utile lors du développement du protocole. En particulier, nous n’avions pas envisagé que la cohabitation de l’auto-verrouillage et des synchronisations en avance de phase puisse mener à des actions invalides, comme le montrent les contre-exemples dans la section 2.5. Encore une fois, ces contre-exemples nous ont aidé dans la compréhension de la source du problème. Lors de la mise au point de la technique des signaux de purge, notre méthode nous a été d’un très grand soutien. La version courante de notre protocole ne relève aucune possibilité d’action invalide, ou manquante.

5.3. Application de la méthode de vérification 123 La table 5.1 montre une classification des tests selon la plus forte relation d’équivalence vérifiée entre la spécification du système et le modèle de son implémentation. On remarque que la relation d’équivalence la plus forte à être vérifiée par l’ensemble de la base de tests est la relation de sûreté (safety equivalence) [BFG+91]. Toutefois, une grande partie des tests générés automatiquement vérifient une relation d’équivalence plus forte que celle de sûreté.

Plus forte équivalence Tests écrits manuellement Tests générés automatiquement

Forte 0 1

Branchement 22 681

τ∗.a 24 303

Sûreté 17 523

Table 5.1 – Nombre de tests pour lesquels une certaine relation d’équivalence est la plus forte à être vérifiée.

Cas de relation d’équivalence forte

Nous avons été surpris de constater qu’il existe un test pour lequel l’équivalence forte est vérifiée. En effet, cette relation d’équivalence ne traite pas les actions internes d’une manière spécifique. Or, n’importe quelle transmission du protocole se traduit par une action interne dans le modèle de l’implémentation.

Le test qui vérifie la relation d’équivalence forte correspond à la composition parallèle de deux tâches qui réalisent uniquement des actions internes. Aucune négociation du protocole n’est réalisée, et les tâches n’ont même pas de message “ready” à transférer car elles ne sont jamais prêtes pour une action sur porte. La résolution des actions internes se fait di-rectement au niveau de chaque tâche. Les seules transitions du modèle de l’implémentation sont ainsi des annonces de réalisation d’actions internes. Ce genre de configuration permet de vérifier une équivalence forte entre la spécification et le modèle de son implémentation.

Cas général : relation d’équivalence de sûreté

Dans le cas général, la relation d’équivalence la plus forte à être vérifiée est celle de sûreté. Nous avons étudié les tests pour lesquels cette relation est la plus forte à être vérifiée afin de déterminer les causes de ce résultat. Nous avons constaté que les relations d’équivalence plus fortes de celle de sûreté ne sont pas vérifiées lorsque le protocole résout de manière concurrente des choix d’actions qui ne sont pas en conflit.

processT1 [A: none] is A; stop end process A processT2 [B, C: none] is select B [] C end select; stop end process B C par T1 [A] | | T2 [B,C] end par A A C B A ^B C

Dans ce système, les rendez-vous sur la porte A ne sont pas en conflit avec ceux sur les portes B ou C. Au niveau de l’espace d’états de la composition parallèle, on note que lorsque la première action est réalisée sur la porte A, le système atteint alors un état depuis lequel il a le choix entre une action sur la porte B ou une action sur la porte C (chemin indiqué en gras dans la représentation du LTS).

La figure 5.1 donne un aperçu schématique d’une partie du LTS de l’implémentation, où les transitions ont été renommées en vue de la comparaison avec l’espace d’états de la spécification, et toutes les transmissions apparaissent comme des actions internes.

chemins d’exécution menant à une première action sur B ou C

A A B C B C A i i i i i i i i

Figure 5.1 – Aperçu de l’espace d’états du modèle de l’implémentation après préparation pour la comparaison avec celui de la spécification (une flèche en tirets indique un diagramme de transmissions du protocole).

Dans cet espace d’états, il existe des chemins d’exécutions où, après une première action sur la porte A, le système n’a plus le choix entre une action sur les portes B ou C. Par exemple, dans le chemin marqué en gras sur la figure 5.1, après l’action sur la porte A, seule

5.3. Application de la méthode de vérification 125 l’action sur la porte B est atteignable. Dans ce chemin, l’état qui suit l’annonce de l’action sur la porte A n’a pas d’état bisimilaire dans le LTS de la spécification, où après une action sur la porte A, les deux actions sur les portes B ou C sont atteignables. La présence de cet état empêche les relations d’équivalence τ∗.a et observationnelle – et, a fortiori, les relations plus forte que ces deux-ci – d’être vérifiées. Au niveau de l’équivalence de trace, la présence d’actions internes uniquement dans le LTS de l’implémentation empêche cette relation d’être vérifiée. La relation la plus forte a être vérifiée est alors celle de sûreté. La figure 5.2 détaille un chemin d’exécution du système qui est inclus dans le chemin en gras de la figure 5.1. La tâche T1 se déclare auto-verrouillée sur la porte A, et cette porte va annoncer la réalisation d’une action. Entre temps, une négociation pour une action de la tâche T2 sur la porte B a été démarrée, et le verrou a été accepté par la tâche T2. Ainsi, au moment où l’action sur la porte A est annoncée, il est déjà certain que l’action suivante du système sera réalisée par la tâche T2 sur la porte B. Ce déroulement illustre la possibilité de ne plus avoir le choix entre une action sur la porte B ou C après une première action sur la porte A. {T1} A T1 {T2} B T2 {T2} C ready(locked) ready ready lock(B,0,{T2})

T2 accepte le lock de B, la négociation de C échouera

Annonce : A

L’action sur A a été annoncée, et seule une action sur B peut ensuite avoir lieu lock(C,0,{T2}) commit(0)

Annonce : B commit abort

Figure 5.2 – Le choix non déterministe d’une action sur la porte B ou sur la porte C pour la tâche T2 peut déjà être entériné au moment où une action sur la porte A est annoncée. On note que, si nous nous sommes focalisés sur le cas où la deuxième action du système est nécessairement sur la porte B, dans le cas général le protocole ne privilégie pas une action en particulier. En effet, il est possible que ce soit la négociation pour l’action sur

la porte C qui arrive à verrouiller la tâche T2 avant que l’action sur la porte A ne soit annoncée. De même qu’il est possible que la réalisation de l’action de la tâche T2 ne soit pas encore décidée au moment où l’action de la tâche T1 est annoncée, ou encore que la première action a être annoncée soit une action de la tâche T2 sur la porte B ou C. D’une manière générale, le fait que la résolution de choix d’action par le protocole ne soit pas atomique, car ce choix est résolu via la transmission de plusieurs messages, permet à plusieurs négociation de se dérouler en parallèle. L’annonce du succès d’une négociation peut avoir lieu alors que d’autres négociations sont suffisamment avancées pour restreindre le choix des prochaines actions du système. Ce comportement est donc une manifestation du fait que le protocole résout les synchronisations indépendantes de manière concurrente.

Remarque 5-2

Dans le cadre de leurs travaux sur l’implémentation de LOTOS, Parrow et Sjödin ont mis au point la relation d’équivalence de simulation couplée (Coupled Simulation) [PS92]. Cette relation d’équivalence, proche de celle de sûreté, traite spécifiquement les états du LTS de la spécification depuis lesquels un choix non déterministe est possible à travers une notion destabilité d’un état. Cette relation d’équivalence semble plus fine et plus pertinente pour comparer les LTS de spécification et d’implémentation. Nous n’avons cependant pas pu expérimenter la relation d’équivalence de simulation couplée car elle n’est pas disponible au sein de CADP à ce jour. Dans le cadre de travaux futurs, il serait intéressant d’étudier si la relation d’équivalence de simulation couplée peut être ramenée à la vérification de la relation d’équivalence de sûreté complétée par la vérification d’une autre propriété,

exprimable en MCL, qui couvrirait la notion de stabilité.

Choix interne et relation d’équivalence

Nous justifions ici une particularité de la spécification du comportement du manager, présentée en section 2.7.3.

On dit qu’une tâche a un choix interne lorsqu’à partir d’un état, une même action peut mener à différents états. Par exemple, la tâche T1 suivante a un choix interne lorsqu’elle effectue une action sur la porte A :

processT1 [A, B, C: none] is select A ; B [] A ; C end select; stop end process A A B C

Le moment où un choix interne est résolu influe sur la relation d’équivalence entre la spécification et le modèle d’implémentation. Sur le LTS de la tâche T1, on note qu’une

5.3. Application de la méthode de vérification 127 fois une première action sur la porte A effectuée, cette tâche n’a plus le choix pour l’action suivante. En d’autres termes, le choix d’effectuer la deuxième action sur la porte B ou sur la porte C doit être déjà réalisé au moment où l’action sur la porte A a lieu.

Au niveau de l’implémentation de la résolution d’un choix interne, deux approches sont possibles :

Résolution du choix interne après confirmation de l’action. Cette approche, qui semble la plus naturelle au premier abord, consiste à décider quel état la tâche va rejoindre une fois que l’action sur la porte A a été confirmée. Dans le LTS de l’im-plémentation, après l’annonce de l’action sur la porte A, les deux actions sur les portes B et C restent donc atteignables.

Résolution du choix interne avant toute négociation. Cette approche consiste à choisir quel état la tâche va rejoindre avant même d’envoyer un message “rea-dy” à la porte A. Au moment de l’annonce de l’action sur la porte A, le choix interne est donc déjà résolu, et seule une des deux actions sur les portes B ou C est réalisable par la suite.

Nous avons opté pour la deuxième approche afin que la relation d’équivalence de sûreté soit vérifiée entre la spécification et le modèle de son implémentation. En effet, si après une action sur la porte A, les deux actions actions sur les portes B et C restent accessibles, cette relation d’équivalence n’est pas vérifiée. Ainsi, dans la spécification du comportement du manager, le choix interne est résolu avant même d’envoyer les messages “ready” aux portes afin de renforcer l’équivalence entre la spécification et son implémentation.