La communication et la synchronisation

La communication et la synchronisation entre événements et processus du système LIMOS reposent sur l’utilisation des tuples qui est un principe tiré du langage LINDA [Gelernter 1985] [Ahuja 1986] [Rowstron 1996]. Ce langage est dédié à la programmation parallèle et introduit des concepts appropriés à la réalisation d’applications distribuées sur des architectures multiprocesseurs hébergeant une multitude de processus en concurrence.

La notion d’espace de tuples est l’élément central qui, par son mode de fonctionnement, autorise une communication entre les objets (processus ou événement) avec :

• découplage spatial ;

• découplage temporel.

Un objet dispose d’un tuple propre stocké localement ou dans un endroit distant (un autre microcontrôleur). Pour communiquer avec cet objet, les autres n’ont pas à connaître son adresse ou sa localisation, ils ont uniquement besoin d’identifier son tuple d’où la notion de découplage spatial. Parfois, ils doivent connaître le microcontrôleur auquel le tuple est rattaché [Park 1997]. L’identification d’un tuple est obtenue par comparaison du contenu ou, plus précisément, par appariement des champs du tuple.

Le découplage temporel est basé sur le fonctionnement de l’accès au tuple et permet la communication asynchrone et la synchronisation. Pour le mode asynchrone, dès qu’un message est placé dans le tuple d’un objet, les autres pourront y accéder (le lire) par la suite soit une seule fois pour l’ensemble des objets, soit indéfiniment jusqu’à ce que le message soit remplacé par un autre [Park 1997]. Le producteur du message est libre d’effectuer d’autres traitements immédiatement après son dépôt. Deux objets voulant se synchroniser vont se mettre d’accord sur un tuple « rendez-vous » vide au départ. Ce dernier est, la plupart du temps, associé à l’un des deux objets. L’un des objets, le consommateur, va effectuer une

CemOA : archive ouverte d'Irstea / Cemagref

lecture sur ce tuple et donc attendre l’arrivée d’un message. Le placement d’un message dans le tuple par le producteur va permettre la synchronisation entre les deux objets.

Les principes que nous venons d’énoncer ont déjà été repris de manière simplifiée dans les systèmes H-LINDA, M-LINDA, DREAM et SDREAM. Les simplifications apportées ont permis d’adapter ceux-ci à des systèmes s’exécutant sur des architectures matérielles aux ressources limitées. La principale est l’identification d’un tuple à l’aide d’un unique identifiant appelé la clé.

Dans le système LIMOS, les concepts de LINDA ont été adaptés pour prendre en considération l’architecture hybride événement/processus. La structure des tuples des événements est identique à celle des processus (voir Figure 2.33). Leur principale caractéristique est l’utilisation d’une file circulaire pour le stockage des messages. Des attributs d’adresses de début et de fin de file sont donc disponibles pour délimiter celle-ci en mémoire. Pour gérer les messages dans la file, deux pointeurs sont utilisés. L’un indique quel est le message courant c’est-à-dire le premier devant être lu. L’autre pointe sur le premier emplacement disponible pour l’insertion ou l’écriture d’un nouveau message.

Les autres attributs des tuples sont :

• son identifiant ou sa clé ;

• son état ;

• sa taille ;

• le nombre de messages stockés.

Figure 2.33 – Structure d’un tuple du système LIMOS

Les 2 états d’un tuple sont « Libre » pour aucun message présent ou « Utilisé » dans le cas contraire. Les tuples permettent la communication entre les différents objets définis au sein du système LIMOS avec le respect de certaines règles. La première est qu’une communication entre événements ou processus entre eux est possible, mais pas d’événement à processus, ni dans l’autre sens. De plus, la communication interprocessus n’est autorisée qu’entre processus appartenant au même événement. Les différents objets peuvent écrire dans autant de tuples qu’ils souhaitent mais ne peuvent lire que leur propre tuple. Enfin, il ne s’agit pas d’une règle mais plutôt d’un rappel : tout message écrit dans un tuple par un événement n’est accessible qu’à la fin de l’exécution de celui-ci.

/*!

unsigned char tuple_len; /* taille */

unsigned long tuple_stadr /* adresse de début de file */

unsigned long tuple_endadr /* adresse de fin de file */

unsigned char* tuple_wptr /* pointeur pour l’écriture de messages */

unsigned char* tuple_rptr /* pointeur pour la lecture de messages */

char tuple_num /* nombre de messages stockés */

};

CemOA : archive ouverte d'Irstea / Cemagref

Les opérations de lecture et d’écriture sur les tuples sont réalisées à l’aide de 2 primitives (voir Figure 2.34) :

• la fonction In() ;

• la fonction Out().

L’extraction (lecture) d’un tuple est réalisée à l’aide de la primitive In(). Son fonctionnement diffère selon qu’il s’agit d’événement ou de processus. Quand un processus accède à un tuple sans message par la primitive In(), il est « Suspendu » et préempté jusqu’à l’arrivée d’un message et de son tour d’exécution. A l’inverse, pour éviter le blocage du système, la primitive In() interdit l’accès des événements à un tuple sans message. Pour un événement confronté à ce problème, les deux solutions envisageables dépendent de l’importance du message normalement attendu dans le tuple et se résument soit à la poursuite des traitements soit à la fin de l’exécution. Dans ce dernier cas, l’événement retourne dans l’état « Inactif » et attend de nouveau un signal correspondant à l’arrivée du message souhaité.

La fonction Out() permet le stockage de données ou l’écriture de messages dans le tuple. Sa principale particularité est d’être non bloquante. L’écriture d’un message entraîne, dans certains cas, la préemption du processus courant par un autre processus de priorité plus grande et en attente de l’information déposée. Cette écriture s’accompagne parfois de la modification des attributs du tuple et parfois d’un ré-ordonnancement des événements en attente d’être pris en charge par le noyau.

Figure 2.34 – Fonctionnement des primitives In() et Out()

2.7.4 La gestion des périphériques

Les interruptions matérielles sont primordiales dans la gestion des périphériques par le système. Les tuples sont encore utilisés pour faire le lien entre une interruption matérielle et un événement (voir Figure 2.35). L’occurrence d’une interruption est suivie de l’écriture d’un message dans le tuple de l’événement associé. On parle dans ce cas de signal plutôt que de message. Un événement est au maximum lié à une interruption.

CemOA : archive ouverte d'Irstea / Cemagref

Figure 2.35 – Illustration de l’association interruption matérielle/événement