Purge de messages de résultats en transit

Lorsque la négociation est un échec, les tâches marquées à purger ne vont pas effectuer d’action suite à cette négociation. Dans ce cas, on peut envisager qu’une porte ignore le message de purge. Cependant, ce comportement de la part d’une porte pourrait mener à des actions invalides, comme le montre la figure 2.11, qui illustre un déroulement du protocole sur le système suivant :

2.5. Cohabitation de l’auto-verrouillage et des rendez-vous en avance de phase 61

processT1 [A: none] is loop select A [] i end select end loop end process A i

processT2 [A: none] is select A [] i ; A; select A [] i ; A end select end select; stop end process A i A i A A par Ain T1 [A] | | T2 [A] end par A A ^A i i i i ⁱ

Les tâches T1 et T2 se signalent prêtes sur la porte A, qui lance une première négociation pour laquelle elle demande une confirmation. La tâche T1 effectue une action interne puis s’auto-verrouille sur la porte A, par un message “ready(locked)” qui met du temps à être délivré. Entre temps, les tâches T1 et T2 acceptent la demande de verrou de la porte A, et T2 demande confirmation à la porte via le message “lock(A,confirm,0,{T1,T2},{T2})” qui indique la purge de la tâche T2. La porte A refuse alors la négociation pour des raisons externes, ignore le champ de purge et envoie un message “abort” aux deux tâches T1 et T2. On suppose que le message à destination de T2 est reçu après un certain délai. La porte A reçoit entre temps la notification d’auto-verrouillage de la tâche T2. Une nouvelle négociation contenant seulement la tâche T1 dans son chemin de verrouillage est alors lancée par la porte A. La tâche T1 accepte cette demande de verrou, et une première action sur A est ainsi réalisée. La tâche T1 envoie un message “commit” à la tâche T2, qui n’a toujours pas reçu le message “abort” de la porte A. La tâche T2 considère donc ce message “commit” comme le résultat de la toute première négociation.

Ensuite, les deux tâches T1 et T2 sont de nouveau prêtes sur la porte A, qui lance une nouvelle négociation, en demandant à nouveau une confirmation. Les tâches T1 et T2

T1 {T1,T2} A T2 ready ready action interne lock(A,confirm,0,{T1,T2},{}) ready(locked) lock(A,confirm,0,{T1,T2},{}) lock(A,confirm,0,{T1,T2},{T2})

La porte A refuse la négociation pour des raisons externes abort

abort lock(A,0,{T1},{})

T1 accepte le verrou et est dernière du chemin de verrouillage : 1ère

action sur A commit(0) commit _ready ready lock(A,confirm,0,{T1,T2},{}) lock(A,confirm,0,{T1,T2},{}) lock(A,confirm,0,{T1,T2},{})

Les deux tâches sont verrouillées et la porte A confirme : 2ème

action sur A commit(0)

commit(0) T2 reçoit “abort” et considère que la négociation pour la 2ème

action sur A est un échec

action interne ready(locked)

ready lock(A,0,{T1},{})

T1 accepte le verrou, 3ème

action sur A, invalide selon la spécification commit(0)

commit

Figure 2.11 – Une action invalide peut avoir lieu si la porte ignore le signal de purge d’une négociation qui échoue.

2.5. Cohabitation de l’auto-verrouillage et des rendez-vous en avance de phase 63 acceptent les demandes de verrou, et la tâche T2 transmet le message de demande de verrou à la porte A pour confirmation. La porte A confirme la négociation : une deuxième action sur A est ainsi réalisée et la porte envoie un message “commit(0)” aux deux tâches. Cependant, la tâche T2 va obligatoirement recevoir le message “abort” en attente avant le message “commit” correspondant à la deuxième action sur la porte A, car les messages de la porte A vers la tâche T2 restent ordonnés. La tâche T2 considère donc que la porte n’a pas confirmé la négociation, et elle décide d’effectuer une action interne. On remarque ici qu’aux yeux de la tâche T2, la deuxième action sur A n’a pas eu lieu.

La tâche T2 se signale ensuite auto-verrouillée sur la porte A. Entre temps, la tâche T1 a reçu la confirmation pour la deuxième action sur A, et s’est signalée de nouveau prête. La porte A considère alors la tâche T1 comme prête et la tâche T2 comme auto-verrouillée, elle lance donc une négociation qui ne contient que la tâche T1 dans son chemin de verrouillage. La tâche T1 accepte le verrou et annonce une troisième action sur A. Or la spécification de la tâche T2 est telle que le système peut réaliser au plus deux actions sur la porte A. Cette troisième action est donc invalide, ce qui montre qu’une porte ne doit pas ignorer le signal de purge en cas d’échec de négociation.

Dans le contre-exemple précédent, le problème vient d’un décalage entre l’avancement de la tâche T2 et le reste du système. Ce décalage est déclenché par le croisement du message “abort” concernant la première négociation, et le message “commit” concernant la deuxième. Ce message “commit” résulte de la deuxième négociation qui n’a pas effectué de demande de verrou à la tâche T2, car la porte A considérait à ce moment cette tâche comme auto-verrouillée. Cependant, la porte A a reçu un signal de purge pour la tâche T2 avant de lancer la deuxième négociation.

Ce problème est résolu par la prise en compte de la purge même en cas d’échec de négocia-tion. La figure 2.12 illustre le protocole sur le même exemple que précédemment, mais cette fois ci la porte A prend en compte la purge de la première négociation. Ainsi, la deuxième négociation contient la tâche T2 dans son chemin de verrouillage. Quand la tâche T2 reçoit la demande de verrou pour la deuxième négociation, elle place cette demande en attente car elle s’est déjà engagée pour la première négociation. La tâche T2 ne va pas traiter la demande de verrou pour la deuxième négociation tant qu’elle n’a pas reçu la réponse pour la première, ce qui empêche le croisement de message du contre-exemple de la figure 2.11. En d’autres termes, le fait de retirer l’auto-verrouillage de la tâche T2 lorsqu’elle s’est signalée à purger impose de lui envoyer une demande de verrou pour toute négociation ultérieure, et cette demande de verrou ne sera pas traitée par la tâche T2 avant qu’elle ne reçoive la réponse de la négociation sur laquelle elle s’est signalée à purger. Nous forçons ainsi la purge du message de résultat négatif, ce qui permet d’éviter les croisements de messages de résultats.

Remarque 2-3

Le protocole α-core n’a pas besoin de purger des messages en attente, car lorsqu’une ac-tion est confirmée à une tâche, cette tâche avertit toutes les autres portes sur lesquelles

T1 {T1,T2} A T2 ready ready action interne lock(A,confirm,0,{T1,T2},{}) ready(locked) lock(A,confirm,0,{T1,T2},{}) lock(A,confirm,0,{T1,T2},{T2})

La porte A refuse et considère T2 comme prête, mais non auto-verrouillée abort

abort lock(A,0,{T1,T2},{})

lock(A,0,{T1,T2},{})

T2 s’est déjà engagée, elle place la demande de verrou en attente

La réponse à la première négociation a été purgée du réseau commit(0)

commit

Figure 2.12 – À la réception d’un signal de purge suite à une négociation qui échoue, la porte A continue de considérer la tâche T2 comme prête, mais pas comme auto-verrouillée. Ce comportement force à effectuer une nouvelle demande de verrou à la tâche T2, et permet depurger la réponse à la première négociation.

elle était prête et attend une confirmation de ces portes avant d’effectivement réaliser l’action. Le protocole α-core impose ainsi une sorte de re-synchronisation entre tâches et portes à chaque action. Cette re-synchronisation empêche le phénomène de synchronisa-tion en avance de phase, et facilite la mise en place de l’auto-verrouillage. La phase de re-synchronisation du protocole α-core requiert toutefois des messages supplémentaires, qui ralentissent l’exécution du protocole. Notre mécanisme de signal de purge permet de combiner l’auto-verrouillage et les synchronisations en avance de phase sans nécessiter de