LA MACHINE (INFRASTRUCTURE)

L’implémentation d’NJN est constituée en deux parties

l’infrastructure et la superstructure

L’infrastructure assure l’ordonnancement général de l’application et fournit à la superstructure les primitives qui lui permettent de fonctionner dans un cadre causal. Trois actions principales sont à la charge de l’infrastructure : la gestion des évènements du système, la gestion des messages entre processus logiques et le nettoyage de la mémoire. Pour gérer les communications et la mémoire, l’infrastructure utilise les bibliothèques support abordées au chapitre précédent. La gestion des évènements repose sur l’implémentation du graphe causal vue dans la première partie (voir page 66). Variables et tâches sont des objets de la superstructure. Au niveau infrastructure, NJN ne voit des variables que les signaux qui en mémorisent l’état et il ne voit des tâches que les gestionnaires de tâches qui prennent en charge leur fonctionnement. Ce chapitre s’intéresse à l’infrastructure et présente d’abord le graphe causal et la gestion des évènements, ensuite la gestion des messages de service, enfin l’ordonnancement général et la gestion de la mémoire.

LA MACHINE (INFRASTRUCTURE) 

Les signaux, les évènements et les gestionnaires de tâches Le graphe causal est à la base du comportement causal d’NJN. Il trace les relations de cause à effet entre toutes les opérations effectuées dans l’application.

Les évènements et la structure du graphe causal

La figure 62 fournit le diagramme de classes simplifié du graphe causal. Figure 62. Diagramme de classes du graphe causal. Le graphe est constitué de trois principaux objets : • des évènements d’exécution (XEvent) qui matérialisent l’exécution d’une tâche (champ owner) à une date donnée (xtime) ; • des évènements d’écriture (WEvent) qui représentent l’écriture de donnée (champ value) à une date (wtime) sur un signal ; • des évènements de lecture (REvent) qui représentent la lecture de l’état d’un signal à un instant donné (revent). Des objets intermédiaires implémentent les relations entre ces trois objets principaux : Infrastructure – 161 • les objets WList permettent de relier l’exécution d’une tâche (un objet XEvent) à toutes les opérations d’écriture (objets WEvent) que cette exécution a provoquées ; • les objets RQueue classent selon l’ordre temporel toutes les lectures d’une même donnée (objet WEvent) effectuées lors de divers exécutions de tâches (objets Xevent) ; • les objets WQueue permettent de classer selon l’ordre temporel les évènements d’écriture se rapportant à un même signal ; • les objets XQueue permettent de classer selon l’ordre temporel les évènements d’exécution se rapportant à une même tâche. Figure 63. Le graphe causal. Lorsqu’une tâche écrit une donnée sur une variable, un objet WEvent est créé et ajouté au signal associé à cette variable. La relation causale de l’opération est matérialisée par l’objet WList dans lequel est également placé ce nouvel évènement. Lorsqu’il s’agit d’écriture sur des signaux distants, un objet WList est construit du côté de la cible et est référencé par le champ others de la liste localement associée à l’évènement d’exécution. Ce lien distant est implémenté par un objet DOHC de type Handle. Lorsqu’une tâche lit l’état d’une variable, NJN cherche sur le signal correspondant l’objet WEvent le plus récent antérieur à la date de lecture. Un objet REvent est créé pour matérialiser l’opération et est ajouté à la liste rqueue du WEvent concerné. 162 – Chapitre 8 Figure 64. Lien entre XEvent et WEvent distants. Le déclenchement d’une tâche est provoqué par l’apparition d’un évènement associé à une des variables placées dans la liste de sensibilité de la tâche. Le graphe causal crée, dès le déclenchement l’objet XEvent qui servira de support à l’exécution de la tâche. La relation de cause à effet entre l’écriture sur la variable et l’exécution est matérialisée par une relation bidirectionnelle entre les objets WEvent et XEvent impliqués. L’objet XEvent voit les écritures qui l’ont déclenché (champ triggerings) tandis que l’objet WEvent voit les exécutions qu’il a provoquées (triggered).Chaque tâche est associée à un gestionnaire spécifique qui assure son bon fonctionnement et gère ses exécutionsConcrètement, le gestionnaire de tâche gère l’état des évènements d’exécution associés à la tâche dont il a la charge. Un évènement d’exécution peut être placé dans six états distincts : déclenché (scheduled), exécuté (executed), abandonné (aborted), invalidé (invalidate), annulé (cancelled) ou détruit (destroyed) : • L’état scheduled est l’état de l’évènement à sa création. Il correspond au déclenchement de la tâche. L’évènement se trouve alors en attente d’exécution. • L’état executed témoigne de l’exécution effective de la tâche correspondante. Sauf si un retour arrière rend l’exécution invalide, l’évènement restera dans cet état jusqu’à ce qu’il soit supprimé de la mémoire. Infrastructure – 163 • L’état aborted correspond à une exécution déclenchée par timeout pour laquelle la condition temporelle n’est plus remplie. • L’état invalidate correspond à un évènement rendu invalide par une violation de causalité. Si l’évènement a déjà été exécuté, il devra être déclenché à nouveau. • L’état cancelled correspond à un évènement qui, à la suite d’un retour arrière ou une violation de causalité, n’a plus d’évènement d’écriture déclencheur. Il n’a donc plus de raison d’exister. • Enfin l’état destroyed correspond à un évènement supprimé du graphe causal. Il sera nettoyé par le ramasse-miette de DOHC. Au moment du déclenchement d’une tâche, le gestionnaire de tâche place l’objet XEvent nouvellement créé dans une liste globale d’évènements d’exécution à traiter1 . L’objet y reste tant qu’il est dans l’état scheduled. Une fois traité – c’est-àdire une fois que la tâche aura été exécutée – l’évènement sera retiré de la liste globale mais sera conservé dans le graphe causal. Le déclenchement par timeout est géré par un signal spécifique : la propriété beat (figure 65). A chaque exécution, un évènement est inscrit sur ce signal. Toutes les tâches déclenchées par timeout sont sensibles à leur propriété beat, ce qui a pour conséquence que chaque exécution provoque systématiquement un nouveau déclenchement. L’exécution suite à un timeout est conditionnée par le respect du délai correspondant depuis la précédente exécution. Si le délai est respecté, la tâche est exécutée et le XEvent associé passe dans l’état executed. Dans le cas contraire, l’évènement d’exécution passe dans l’état aborted.