NJN définit trois dates courantes : une date de lecture tR, une date d'exécution tE et une date d'écriture tW. La date d'exécution correspond à la date de l'évènement en cours de traitement. La date de lecture est antérieure ou égale à la date d'exécution. En pratique, ces deux dates sont le plus souvent égales. La date d'écriture quant à elle est strictement postérieure aux deux autres. La relation ci-dessous est donc vérifiée à chaque instant :
tRtEtW
Lorsqu'un évènement est traité, l'état observable du système est celui défini à la date de lecture. Il est éventuellement possible de connaitre l'état qu'avait un signal à une date antérieure. En revanche, aucune lecture à une date postérieure n'est possible. De façon analogue, les écritures sur les signaux de l'application sont effectuées à la date d'écriture. Il est éventuellement possible de retarder une écriture en précisant un délai explicite. Mais toute tentative d'écriture à une date antérieure est prohibée1.
Une tâche est composée de deux éléments : un corps qui renferme le code exécutable de la tâche et des conditions d'activation. Les conditions d'activation peuvent être de nature temporelle. On peut par exemple vouloir qu'une tâche soit exécutée à intervalles de temps réguliers (timeslot) ou au bout d'un certain temps d'inactivité (timeout). Les conditions d'activation peuvent également prendre la forme d'une liste de sensibilité qui énonce l'ensemble des signaux du système qu'il faut surveiller. L'exécution du corps de la tâche sera alors programmé chaque fois qu'une modification affectera l'un des signaux de la liste.
Les règles d'exécution des tâches sont les suivantes : lorsque les conditions d'activation d'une tâche sont remplies, un évènement d'exécution est programmé.
1 Nous verrons un peu plus loin qu'il existe une exception avec les boites de découplage.
Le protocole de synchronisation - 65 La date associée à cet évènement dépend de la nature des conditions d'activation.
S'il s'agit d'un déclenchement temporel, la datation de l'évènement est immédiate.
Si le déclenchement est dû à un évènement d'écriture de l'un des signaux de la liste de sensibilité, la date d'activation correspond à la date de l'évènement d'écriture1. Lorsque l'évènement d'exécution est traité, c'est-à-dire lorsque la tâche est exécutée, la date d'exécution tE est fixée à la date de l'évènement.
Figure 31. Modèle temporelle d'NJN.
Deux cycles sont définis dans NJN (figure 31) : les delta, notés Δ et les micro-delta notés δ. La relation d'ordre entre deux dates (t1, Δ1, δ1) et (t2, Δ2, δ2) est définie de la façon suivante : Si t1 est égal à t2 alors la relation d'ordre est établie en comparant Δ1 et Δ2. Si ces derniers sont également identiques, c'est la relation entre δ1 et δ2 qui est examinée. L'écart temporel entre tE et tW dépend alors de la nature de la tâche. Pour une tâche classique (RTTask ou VTTask), il est d'un Δ.
Pour un répéteur ou une boite d'horloges (ClockBox), il est d'un δ. Les cycles Δ ne sont incrémentés que lorsque les cycles δ ont permis de propager les données à travers le réseau de signaux.
Le tableau II résume les relations temporelles entre les trois dates définies par NJN en fonction du type d'évènement traité.
1 Nous verrons que pour les tâches temps-réel un délai est introduit entre l'évènement d'écriture et l'évènement d'exécution qu'il produit.
66 - Chapitre 3
Tableau II. Relations temporelles entre les dates de lecture, d'exécution et d'écriture en fonction du type de tâche exécuté.
Nature de la tâche Lecture Exécution Écriture VTTask (tE, ΔE, +∞) (tE, ΔE, +∞) (tE, ΔE + 1, 0) RTTask (tE - L, +∞, +∞) (tE, ΔE, +∞) (tE, ΔE + 1, 0) ClockBox, Repeater (tE, ΔE, δE) (tE, ΔE, δE) (tE, ΔE, δE + 1)
On note que les tâches classiques (VTTask) observent l'état des signaux après relaxation du réseau (δ = +∞) et placent les messages qu'ils produisent au début d'un nouveau cycle Δ (δ = 0). Entre un cycle Δ et le suivant, les répéteurs et les boites d'horloges (ClockBox) assurent la propagation des messages en gérant les relations causales au moyen de cycle δ.
Les tâches temps-réel (RTTask) observent le monde avec retard en repoussant en arrière la date de lecture d'une durée égale à leur latence L. On peut noter que cette observation est faite sur un passé relaxé. Cycles Δ et δ sont en effet à une valeur infinie. L'écriture est réalisée quant à elle au cycle Δ suivant, comme cela est le cas pour les tâches temps-virtuel.
Le cadre temporel défini ci-dessus permet d'établir des relations causales entre évènements tout en assurant la convergence de la propagation des données à travers l'application avant que les tâches soient exécutées. Si l'on veut garantir la causalité de l'ensemble de l'application, les évènements devront être traités en respectant l'ordre partiel établi par leur date, en apparence du moins. Cette responsabilité est celle du protocole de synchronisation, objet des sections suivantes de ce chapitre.
2 Le graphe causal et le protocole de synchronisation
Le protocole de synchronisation choisi est de type optimiste. Il est donc nécessaire de mettre en œuvre une sauvegarde de l'état du système ainsi qu'un mécanisme de restauration. Notre approche fait appel à une technique d'annulation directe inspirée de Zhang [92]. Elle ne fait pas appel à une sauvegarde globale de l'état du système mais à des sauvegardes atomiques. Toutes les opérations d'écriture et de lecture effectuées par les tâches d'un processus logique sont archivées de façon atomique. Les relations entre les différentes opérations sont également représentées dans la structure de données du système. De cette manière il est possible, en cas de retour arrière, d'annuler une opération quelconque ainsi que ses conséquences. Il n'est pas nécessaire d'annuler l'ensemble des opérations du système. Seules les opérations réellement affectées par une violation de causalité sont annulées.
Le protocole de synchronisation - 67