2.8 Conclusion
3.1.5 Modélisation événementielle de ASP
La sémantique du modèle ASP, et en particulier l’utilisation d’un motif de com-munication requêtes/réponses avec service asynchrone des requêtes, induisent une relation de causalité locale partielle. En effet, certains évènements exécutés consécutivement sur une même activité peuvent être échangés sans modification observable du comportement de l’exécution. On parle d’évènements locaux com-patibles. En fonction de ces relations de compatibilité, nous proposons donc dans cette section une relation de causalité potentielle pour ASP (section 2.7).
Il est important de noter que les relations de compatibilité entre les évène-ments sont définies entre les évèneévène-ments locaux, et qu’elles découlent de la sé-mantique du modèle. Elles sont donc statiques, et permettent de définir une rela-tion de causalité potentielle valable pour toutes les exécurela-tions possibles en ASP, quelque soit l’application.
3.1 Le modèle : ASP 39
Propriété 3.1.5.1 (Causalité en ASP) Une relation de causalité potentielle peut
être définie statiquement pour toutes les exécutions possibles en ASP.
Nous débutons cette section en définissant une classification des évènements ainsi qu’une notation adaptée à la définition d’une relation de causalité.
3.1.5.1 Notations
Nous distinguons dans une exécution ASP donnée S−−−→ Se...en ′sept types d’évè-nement :
– l’envoi ou la réception de requête, – l’envoi ou la réception de réponse, – le service de requête,
– le premier accès à un futur, – enfin, l’évènement interne.
Dans l’ensemble des couples d’évènements de communication, noté Γ dans la relation de Lamport, les envois et réceptions de requête ou de réponse doivent être dissociés. Nous définissons donc deux ensembles distincts ΓQ et ΓRtels que : – ΓQ ⊆ {(e, e′) ∈ {e1. . . en} ∗ {e1. . . en}} définit une bijection entre l’envoi et la
réception correspondante de toutes les requêtes, – ΓR⊆ {(e, e′
) ∈ {e1. . . en} ∗ {e1. . . en}} définit une bijection entre l’envoi et la réception correspondante de toutes les réponses,
– Γ = ΓQ∪ ΓR.
L’évènement de type service de requête caractérise le démarrage du service d’une requête. Ce type d’évènement est donc associé à la réception de la requête servie : Σ ⊆ {(e, e′
) ∈ {e1. . . en} ∗ {e1. . . en}} définit une bijection entre la réception d’une requête et le démarrage de son service.
L’évènement de type accès à un futur correspond au moment où une activité utilise pour la première fois le contenu de la réponse qui a mis à jour le futur. Ce type d’évènement est donc associé à la réception de la réponse correspondante au futur : ε ⊆ {(e, e′
) ∈ {e1. . . en} ∗ {e1. . . en}} définit une bijection entre la réception d’une réponse et le premier accès au futur correspondant à cette réponse.
Enfin, l’évènement interne correspond à une étape du service d’une requête, c’est à dire une étape élémentaire de l’évaluation d’une requête.
3.1.5.2 Causalité entre évènements dans ASP
Le service asynchrone des requêtes reçues, ainsi que le mécanisme d’attente par nécessité sur les futurs introduisent des relations de causalité particulières entre les évènements locaux sur une activité [DEL 04]. En effet, la réception d’une requête ne modifie que l’état de la queue des requêtes en attente tant qu’elle n’est pas servie. La réception d’une requête est donc compatible avec tous les évène-ments sauf les autres réceptions de requêtes tant qu’elle n’est pas servie. Bien sûr, elle n’est pas compatible avec son service.
Une réception de requête n’est donc pas causalement reliée aux évènements internes ou aux envois consécutifs tant qu’elle n’est pas servie. En revanche, l’ordre relatif des réceptions de requêtes est significatif : deux réceptions de re-quête consécutives sont causalement liées.
L’évènement de type premier accès à un futur est particulier : son exécution est gardée par le mécanisme d’attente par nécessité sur les futurs. Cet évène-ment ne peut avoir lieu que si la réception de la réponse correspondant au futur a déjà eu lieu. Donc la réception d’une réponse n’est pas compatible avec le premier accès au futur. De plus, l’exécution étant caractérisée uniquement par les récep-tions de requêtes (propriété 3.1.2.2), une réception de réponse est compatible avec tous les autres évènements, sauf avec l’envoi de la requête correspondant à cette réponse (contrainte 3.1.2.2). En particulier, les réceptions de réponse sont compa-tibles entre elles.
Une réception de réponse n’est donc causalement liée qu’à l’envoi de sa requête correspondante, et au premier accès à son futur correspondant.
Enfin, on ne peut pas définir statiquement de relation de compatibilité entre les autres types d’évènements : ils sont donc tous causalement liés.
Evènement réception, service ou accès au futur Evènement interne Lien de causalité
i j Q1 X(Q1) Q3 Q2 X(Q2) X(Q3) R3 i j Q1 X(Q1) Q3 Q2 X(Q2) X(Q3) R3
FIG. 3.3 – Exemple d’exécution distribuée ASP, et le graphe de causalité associé
Les relations causales partielles induites par le service de requêtes asynchrones sont illustrées par l’exemple de la figure 3.3. Cette figure présente une exécution avec deux activités i et j communicantes en haut, et le graphe de causalité associé à cette exécution en bas. On note Qxune requête et Rxsa réponse correspondante, et X(Qx) le service de la requête Qx. Le rectangle pointillé représente la durée du service d’une requête ; l’état de l’activité est donc capturable entre les rectangles
3.1 Le modèle : ASP 41
pointillés. Certains évènements internes peuvent être mis en valeur dans cette représentation si nécessaire.
On considère ici des activités avec une politique de service FIFO. L’activité j envoie les requêtes Q1 et Q2 à i, et i envoie la requête Q3 à j. Le service des requêtes Q1 et Q2ne nécessite pas de retour de résultat. Le résultat du service de Q3 est renvoyé à i par la réponse R3.
L’envoi de la requête Q3 n’est pas causalement relié aux réceptions des re-quêtes Q1 et Q2 car il a lieu avant les services de Q1 et Q2, comme on le voit dans l’ordre causal correspondant à cette exécution. Le premier évènement sur i qui est une conséquence causale de la réception de Q2 est le service de Q2.
Enfin la réception de la réponse R3 est une conséquence causale de l’envoi de la requête Q3. Le premier évènement qui est une conséquence causale de cette réception est le premier accès au futur correspondant à R3, qui dans cet exemple a lieu durant le service de la requête Q2.
Ce graphique permet de constater visuellement que tous les évènements lo-caux à une même activité ne sont pas systématiquement causalement liés. Cette relation d’ordre partielle entre les évènements locaux est exprimée de manière formelle dans la définition d’un ordre de causalité local ≺ASP adapté au modèle ASP :
Définition 3.1.1 (Ordre causal local) ≺ASP
i est un ordre partiel défini pare ≺ASPi e′ si et seulement si
(∄ek, [(ek, e) ∈ Γ ∨ (ek, e′) ∈ Γ] ∧ e ≺hbi e′) ∨ (a)évènements internes totalement ordonnés (∃ek, el, (ek, e) ∈ ΓQ∧ (el, e′) ∈ ΓQ∧ e ≺hbi e′) ∨ (b)réceptions de requêtes totalement ordonnées (e, e′) ∈ Σ ∨ (c)conséquence causale du service
(e, e′) ∈ ε ∨ (d)réception d’une réponse et accès au futur (∃ek, e ≺ASPi ek ≺ASPi e′) (e)transitivité
Enfin, la définition d’un ordre local permet de définir une relation de causalité potentielle qui lie tous les évènements d’une exécution distribuée en ASP :
Définition 3.1.2 (Causalité potentielle pour ASP) ≺ASP est un ordre de cau-salité potentielle pour ASP :e ≺ASP e′
si et seulement si
e ≺ASPi e′ ∨ (a) ordre causal local
((e, e′) ∈ Γ ∨ (c) causalité des communications (∃ek, e ≺ASP ek≺ASP e′) (c) transitivité