• Aucun résultat trouvé

Travaux similaires

Reactive-C [BOU 91], cr´e´e par F. Boussinot, est une impl´ementation (la premi`ere) de ce que l’on appelle le mod`ele r´eactif synchrone; elle a ´et´e faite en C et dispose d’une s´emantique formelle donn´ee avec des r`egles de r´e´ecriture. L’objectif est d’obtenir un assembleur r´eactif pour impl´ementer divers mod`eles de calcul fond´es sur des notions de r´eaction ou d’instant. Parmi les impl´ementations d´ej`a r´ealis´ees, on peut citer :

• Les r´eseaux de processus r´eactifs (r´eseaux ”de Kahn” avec une notion d’instant) dans lesquels le test de la file vide devient possible tout en pr´eservant le d´eterminisme (environ 200 lignes de RC).

• Le langage SL qui est une version d’Esterel sans pr´eemption forte, dans lequel la r´eaction `a l’absence d’un signal est report´ee `a l’instant suivant, ce qui permet d’´eliminer les cycles de causalit´e (environ 800 lignes de RC).

• Le mod`ele POR (”Programmation par Objets R´eactifs”) impl´ement´e par Soft Mountain sous le nom RLib, sur lequel Modcomp-AEG a construit l’outil PROTOP/IX. Cet outil est utilis´e pour contrˆoler la cimenterie d’Angoul`eme des Ciments Lafarge (l’application comprend plusieurs milliers d’agents POR ex´ecut´es en parall`ele et a ´et´e d´ecrite `a RTS’94).

Ind´ependamment du langage de programmation utilis´e par Junior et Reactive-C (Java et C respectivement), on peut dire que le mod`ele d’ex´ecution de Reactive-C est un mod`ele plus expressif que celui de Junior. En effet, Reactive-C permet le contrˆole fin de l’ex´ecution d’un programme r´eactif que Junior ne permet pas. Par exemple, en Reactive-C le programmeur a `a sa disposition une primitive pour suspendre l’ex´ecution d’une branche et donner le contrˆole `a une autre. Ceci a deux cons´equences :

• On peut construire un ensemble plus large de programmes et donc l’expressivit´e du langage est plus grande. Avec Reactive-C, on pourrait impl´ementer le moteur d’ex´ecution de Junior et ses programmes mais pas l’inverse. Les programmes Junior sont un sous-ensemble des programmes g´en´er´es avec Reactive-C. • Le coˆut `a payer est de pouvoir construire des programmes qui sont syntaxiquement corrects mais s´

emantique-ment incorrects en ce qui concerne la gestion des micro-r´eactions. Par exemple, si on impl´emente Ju-nior avec Reactive-C, il faudrait s’assurer que toutes les branches suspendues de l’instruction Par soient r´eactiv´ees au cours du mˆeme instant pour qu’elles voient toutes les modifications qui ont ´et´e faites lorsque l’instruction ´etait suspendue (voir le mˆeme probl`eme en SugarCubes ci-dessous).

Par rapport `a Junior, Reactive-C est vraiment un langage de bas niveau5 (assembleur r´eactif) car il n’existe pas d’´ev´enements ; lorsque le programmeur les impl´emente, il doit faire attention `a l’efficacit´e en ´evitant des attentes actives. Reactive-C d´efinit quelques instructions dont l’op´erateur de parall´elisme d´eterministe (Merge) est l’un des plus importants.

SugarCubes

Les SugarCubes[BOU 98c]sont la premi`ere impl´ementation du mod`ele r´eactif en Java. La premi`ere impl´ementation (V1) fut tr`es prometteuse car elle r´eunissait les meilleures caract´eristiques de Reactive-C, de Java et surtout de l’exp´erience accumul´ee dans la construction des syst`emes r´eactifs. L’´equipe de d´eveloppement (L. Hazard, F. Boussinot et J-F. Susini) a tr`es vite propos´e des am´eliorations (V2) et pendant ce processus se sont pr´esent´es deux probl`emes: 1) la nature du mod`ele est telle que l’on peut l’impl´ementer de plusieurs fa¸cons, et 2) cer-taines de ces impl´ementations peuvent conduire `a la construction de programmes incoh´erents que l’on voudrait ´

eliminer. Pour ´eviter ces probl`emes, il a ´et´e propos´e Junior; Junior d´efinit un ensemble d’instructions r´eduit (sans les instructions potentiellement dangereuse) et donne une s´emantique formelle aux instructions pour bien pr´eciser les comportements r´eactifs `a impl´ementer.

Pour mieux comprendre les complications de la programmation de bas niveau, voyons comme est utilis´ee la notion de micro-instant en SC. Les micro-instants sont cr´e´es en utilisant l’instruction Suspend et l’instruction Close. Une instruction suspendue se comporte comme l’instruction Stop si elle n’est pas envelopp´ee d’une instruction Close. L’instruction Close active son corps tant qu’il n’est pas stopp´e ou fini. L’instruction Suspend divise l’instant en micro-instants et l’instruction Close combine les micro-instants pour cr´eer un seul instant. Voici un exemple: SC . C l o s e ( SC . Merge ( SC . Seq (SC . P r i n t ( ” S u s p e n d i g ” ) , SC . Suspend ( ) , SC . P r i n t ( ” 1 ” ) , SC . Stop ( ) , SC . P r i n t ( ” 2 ” ) ) , SC . Seq (SC . P r i n t ( ”A” ) , SC . Stop ( ) , SC . P r i n t ”B” ) ) ) )

Ce programme imprimeSuspending A1au premier instant et 2Bau deuxi`eme instant, puis termine. Voici un exemple d’un programme en SugarCubes qui pose des probl`emes:

SC . Merge ( SC . Seq (SC . Await ( ”E” ) ,

SC . P r i n t ( ” A c t i o n A t o m i q u e ” ) , SC . Seq (SC . Suspend ( ) ,

SC . G e n e r a t e ( ”E” ) ) )

5En fait, Reactive-C n’est pas un langage avec un compilateur, il s’impl´emente avec des macros. L’utilisation des macros ne permet pas de faire des optimisations.

Ce que l’on attend de ce programme est l’ex´ecution de l’action atomique `a l’instant de la g´en´eration de l’´ev´enement"E". Cependant l’action atomique est ex´ecut´ee avec un d´ecalage d’un instant car l’environnement ne d´etecte aucun changement (aucune g´en´eration d’un ´ev´enement pendant la premi`ere activation) et donc la fin de l’instant est d´eclar´ee.

L’instructionSuspendest une des instructions potentiellement dangereuses qui a ´et´e ´elimin´ee en Junior. Les diff´erences principales entre SugarCubes (V3) et Junior sont:

• Nombre d’instructions

Il y a moins d’instructions en Junior (16) qu’en SugarCubes (32). • Style de programmation

Le style de programmation de SugarCubes est bas´e sur l’utilisation de l’instruction Cube qui n’existe pas en Junior. Le Cube est d´efini comme

Cube = Link + Shell + F reezable

et il n’est pas seulement une instruction; il joue aussi le rˆole de machine r´eactive ce qui permet une programmation par hi´erarchies.

• Diff´erences s´emantiques

– La s´emantique de l’instruction Freezable de Junior est diff´erente de celle de SugarCubes : l’imbrication d’instructions Freezable en Junior est ex´ecut´ee de l’int´erieur ver l’ext´erieur; en SugarCubes c’est l’inverse.

– L’instruction de parall´elisme en Junior est non-d´eterministe tandis que celle de SugarCubes est d´eterministe (l’ordre est donn´e par la position des instructions).

– L’instruction Loop de SugarCubes stoppe les boucles instantan´ees. En particulier les boucles sont stopp´ees apr`es avoir ex´ecut´e deux fois le corps dans le mˆeme instant. En Junior les boucles instan-tan´ees sont permises.

FairThreads

Les FairThreads [BOU 02], cr´e´ees par F. Boussinot, d´efinissent un mod`ele de programmation concurrente et parall`ele. Ce mod`ele a ´et´e d´efini par une s´emantique formelle et il a ´et´e impl´ement´e en plusieurs langages (Java, C, Scheme).

Le mod`ele des FairThreads ressemble fortement au mod`ele r´eactif synchrone en plusieurs aspects:

1. Les entit´es concurrentes sont ex´ecut´ees de fa¸con coop´erative avec une notion d’instant `a la Junior, c’est-`

a-dire dans laquelle tous les composants sont ex´ecut´es `a chaque instant, d’o`u le nom de Fair (´equitable), 2. Les entit´es peuvent interagir `a l’aide d’un m´ecanisme de communication par diffusion d’´ev´enements, 3. Il est possible de cr´eer de nouveaux composants dynamiquement.

Les FairThreads se distinguent de Junior par :

1. Le langage de programmation est un sous-ensemble de celui de Junior; en particulier la plupart des in-structions ´ev´enementielles n’existe pas et l’instruction Until, d’une part, n’existe pas en tant qu’instruction et d’autre part a la s´emantique du Kill de SL.

2. Le parall´elisme n’existe pas en tant qu’instruction; on le trouve comme dans les threads, au plus haut niveau (on obtient un parall´elisme plat).

• Le d´etachement de comportements r´eactifs pour les ex´ecuter de fa¸con pr´eemptive. Ceci est seulement possible lorsqu’on ex´ecute les FairThreads dans une plate-forme qui supporte l’interface POSIX. Autrement dit, les FairThreads sont un habillage au-dessus de l’API POSIX.

• L’attente d’´ev´enements avec une instruction await(E, N) qui attend la g´en´eration de l’´ev´enement

Ependant au plus N instants. Pour impl´ementer efficacement l’attente d’´ev´enement les FairThreads utilisent des files d’attente.

• Il est possible de g´en´erer du code efficace sous la forme d’un automate.

Impl´ementations pour l’embarqu´e

Spirit machine. Cette machine r´eactive, cr´e´ee par J-F Susini, est une impl´ementation du mod`ele r´eactif qui vise la construction de syst`emes qui disposent de tr`es peu de ressources, comme les syst`emes embarqu´es. Pour atteindre son objectif, la Spirit machine utilise un algoritme `a base de bytecode, avec des optcode r´eactifs. La Spirit machine est impl´ement´ee en C et d´efinit un ensemble d’instructions r´eactives `a la Junior : des instructions ´

ev´enementielles comme Generate et Await mais aussi des instructions r´eactives de bas niveau (une sorte de goto r´eactif et des tests) pour impl´ementer les instructions non ´ev´enementielles comme les boucles. La Spirit machine est en d´eveloppement. Le probl`eme principal de la Spirit machine est sa programmation de bas niveau qui se fait avec de macros et des offsets. Dans la section6.4, on pr´esente un langage de programmation de haut niveau (RAUL) qui g´en`ere du code pour ce moteur.

Jrc. Jrc est un langage de programmation r´eactive qui vise les syst`emes embarqu´es `a faibles ressources. Cette impl´ementation, faite par O. Parra[PAR 03]a ´et´e con¸cue pour m´elanger des primitives r´eactives avec un langage efficace tel que le C. Jrc s’inspire de Reactive-C et de Junior et utilise les diff´erentes techniques d’ex´ecution de Junior (arbre d’ex´ecution et files d’attente) ainsi que ses primitives ´ev´enementielles ; de R´eactive-C, Jrc utilise l’op´erateur de parall´elisme d´eterministe, le Merge, et la structuration des programmes sous forme de fonctions. La Spirit machine et Jrc restent des prototypes et il faut attendre leur maturit´e pour pouvoir bien appr´ecier l’´etendue de leurs int´erˆet. Cependant on peut d´ej`a observer les avantages du bytecode (en termes d’espace m´emoire) et ceux de la g´en´eration de code sans interpr´etation (vitesse d’ex´ecution).

L’approche r´eactive fonctionnelle

Plusieurs impl´ementations de l’approche synchrone ont ´et´e effectu´ees, Lustre, Signal, Lucid Synchrone. Dans cette section on va pr´esenter les deux principaux portages de l’approche r´eactive synchrone.

Librairie r´eactive en Standard ML Cette librairie r´eactive a ´et´e impl´ement´e par Pucella [PUC 98] avec l’objectif de porter Reactive-C en Standard ML; elle est donc tr`es proche du mod`ele de programmation de Reactive-C.

Les similitudes sont:

• La possibilit´e de programmer un contrˆole fin `a l’int´erieur des instants, c’est-`a-dire de programmer les micro-instants avec des instructionssuspendet close.

• Une s´emantique formelle (SOS) et une impl´ementation directe de la s´emantique, par exemple le cœur de l’impl´ementation est la fonctionsstepqui joue le rˆole de la r´e´ecriture dans la s´emantique.

Parmi les diff´erence on trouve:

• La diff´erence entre instruction r´eactive et expression r´eactive. Les expressions r´eactives peuvent ˆetre d´efinies comme des types de donn´ees (datatype).

• La pr´eemption est impl´ement´ee avec le m´ecanisme d’exception.

• Il n’existe pas de m´ecanisme de communication autre que les variables partag´ees.

• La possibilit´e de programmer des fonctions d’ordre sup´erieur. Un travail similaire a ´et´e fait par Caspi et Pouzet[CAS 96]en Lustre.

Senior [DEM 01], cr´e´e par J. Demaria, est une librairie r´eactive pour le compilateur Scheme Bigloo. Senior a ´

et´e cr´e´e avec l’objectif d’exp´erimenter le m´elange de la programmation fonctionnelle et de Junior. En particulier, d’avoir acc´es `a l’expressivit´e de Scheme (adoption d’une syntaxe moins lourde par rapport `a Junior) et `a l’ordre sup´erieur conforme `a la s´emantique de Junior.

Le r´esultat est une programmation tr`es puissante dans laquelle : • Les ´ev´enements sont repr´esent´es par des symboles Scheme.

• Il y a un meilleur lien entre les donn´ees de Scheme et les programmes r´eactifs.

• On retrouve l’utilisation de l’ordre sup´erieur `a tous les niveaux (implantation et utilisateur) ce qui perp´etue la puissance et la souplesse du fonctionnel.

• Il est possible de cr´eer des programmes r´eactifs r´ecursifs (des fonctions r´ecursives).

• L’existence d’une lambda r´eactive impl´ement´ee avec une fonction Scheme qui renvoie un programme r´eactif (arit´e variable, typage des param`etres).

Quelques probl`emes restent sans solution, par exemple, les programmes r´eactifs ne sont pas r´eentrants et chaque invocation entraˆıne l’allocation d’un nouveau programme; le programme r´eactif ne peut donc ˆetre li´e qu’`a un seul objet.