Pour qu'une application NJN fonctionne dans de bonnes conditions, le temps virtuel universel (WVT), c'est-à-dire la date d'exécution courante des tâches non temps-réel, doit être positionné dans un intervalle de temps majoré par l'horloge murale (WCT) et de longueur égale à la latence de la chaine de traitement en cours d'évaluation. Concrètement, si une tâche temps-virtuel est en cours d'exécution et qu'elle participe d'un traitement pour lequel la tâche temps-réel de sortie à une latence L, on doit avoir nécessairement :
WCT−LWVTWCT
sans quoi il sera impossible de satisfaire la latence de la tâche de sortie.
Cette particularité de fonctionnement facilite la détermination de la limite des objets fossiles (FVT) qui permet de savoir quels évènements peuvent être supprimés de la structure de données.
En supposant que le système satisfasse les contraintes temps-réel, autrement dit que tous les processus temps-réel du système soient exécutés à temps, il suffit de connaitre la latence la plus grande pour déterminer le FVT. Par exemple, si l'on adopte une approche globale, soit R l'ensemble des tâches temps-réel du système, le FVT est tel que :
FVT=WCT−maxT∈R
LT
La latence maximale trouvée représente alors le délai de fossilisation des évènements, c'est-à-dire le temps nécessaire pour que ces objets soient devenus sans intérêt pour le système.
Chaque fois qu'un paramètre de latence est modifié, qu'une nouvelle tâche temps-réel est ajoutée ou qu'une tâche temps-temps-réel est supprimée de l'application, le délai de fossilisation est réévalué. Mais NJN procède de façon locale en tenant compte des dépendances de données entre processus logiques. On détermine d'abord le maximum de la latence en considérant les tâches temps-réel hébergées localement par chaque processus logique. Cette valeur est ensuite propagée aux processus logiques avec qui des messages sont échangés. Chaque processus compare ensuite les valeurs reçues avec la latence maximale trouvée localement et conserve la plus grande valeur.
Localement, une structure de type heap permet de trouver Lmax la latence maximale des tâches hébergées localement.
Le protocole de synchronisation - 71 L'exemple de l'application distribuée de la figure 35 montre comment NJN procède, pour déterminer le délai de fossilisation FT,
Figure 35. Détermination du délai de fossilisation.
Trois processus sont représentés : LP1, LP2 et LP3. Les tâches du processus LP1
produisent des données à destination de tâches hébergées par LP2 et LP3. Pour déterminer son délai de fossilisation, LP1 devrait donc tenir compte des délais de fossilisation trouvés pour LP2 et LP3. En revanche, ces deux derniers n'ont pas besoin du FT de LP1.
LP2 et LP3 propagent vers LP1 leur délai de fossilisation, en indiquant la provenance de ce dernier, c'est-à-dire l'identifiant du processus logique qui héberge la tâche à partir de laquelle a été déterminé ce délai. Le processus LP1
déterminera alors le délai FT en comparant la valeur locale dont il dispose et les valeurs reçues des processus LP2 et LP3 dont il dépend.
Les choses se compliquent un peu lorsque les processus logiques sont liés par des dépendances circulaires. NJN procède alors comme dans le cas précédent, à ceci près que chaque processus logique ignore les délais de fossilisation dont il est l'auteur au profit de la latence locale maximale. La figure 36 présente un tel cas de figure. Le processus LP1 héberge la tâche de latence maximale (36.a). Celle-ci est propagée aux deux autres processus logiques (36.b).
Lorsque LP1 voit sa valeur Lmax modifiée (figure 37.a), une nouvelle diffusion des délais de fossilisation est engagée. La valeur de FV associée à LP1 ayant pour origine LP1 lui-même, ce dernier ne diffuse pas sa valeur de FV mais la valeur de sa latence maximale Lmax. Rapidement, la diffusion met à jour la valeur des délais de fossilisation des différents processus (37.b).
Le comportement temps-réel d'NJN n'étant pas totalement garanti, la limite des objets fossiles est calculée avec une marge de sécurité. Si FT est le délai de fossilisation déterminé localement, FVT est tel que :
FVT=WCT−1kFV
72 - Chapitre 3
où k représente la marge relative de sécurité dont la valeur est de l'ordre de 1, ce qui permet grosso modo à chaque tâche de subir un retour arrière et d'être ré-exécutée avant que le système ne soit pris en défaut par la suppression trop hâtive d'un évènement.
Figure 36. Cas d'une dépendance circulaire.
Le nettoyage de la structure de données est une opération de priorité très faible.
Elle est effectuée lorsqu'aucune tâche ne peut être exécutée. Les évènements d'écriture dont la date est antérieure à FVT sont supprimés du système. Chaque suppression d'un évènement d'écriture s'accompagne de la destruction de la file de lecture qui lui était associée ainsi que des évènements d'exécution qu'il a déclenchés.
Le protocole de synchronisation - 73
Figure 37. Cas d'une dépendance circulaire. Changement de la latence maximale de LP1.
3 Quand rien ne va plus...
La précédente partie a dévoilé le cœur du protocole de synchronisation d'NJN.
Lorsque l'application est convenablement construite et qu'un régime de fonctionnement stable est établi, ce protocole assure la reproductibilité comportementale du système. Les choses ne sont cependant pas toujours idéales et NJN doit faire face, comme tout système temps-réel, à des situations exceptionnelles ou des configurations plus ou moins tordues. Cette troisième partie se penche sur ces cas particuliers où les principes généraux d'NJN sont mis en défaut. On montrera alors comment, et avec quels outils, NJN tente de s'adapter pour assurer l'essentiel.