École des Mines de Paris Centre de Mathématiques Appliquées Sophia-Antipolis THÈSE de doctorat de l École des Mines de Paris Spécialité : Informatique temps-réel, Robotique, Automatique présentée par Jean-Ferdinand SUSINI L Approche Réactive au dessus de Java : sémantique et implémentation des SugarCubes et de Junior Soutenue le 11 septembre 2001 devant le jury composé de : Président : Rapporteurs : Directeur : Examinateurs : Gérard BERRY Florence MARANINCHI Gilles MULLER Frédéric BOUSSINOT Laurent HAZARD Jean-Bernard STEFANI
à mes parents Remerciements : En premier lieu, je voudrais exprimer ma reconnaissance à Florence MARANINCHI et Gilles MULLER qui ont accepté d être rapporteurs de ma thèse. Je tiens également à exprimer toute ma gratitude à Gérard BERRY qui m a fait l honneur de présider le jury. Je remercie particulièrement Laurent HAZARD d avoir accepté de participer au jury. Les quelques années de collaboration que nous avons eu ont été très enrichissantes pour moi. Qu il me soit également permis ici et à travers lui de remercier France Telecom R&D pour son soutient à ces travaux de recherche. Je remercie également Jean-Bernard STEFANI qui m a fait l honneur de faire partie du jury. A tout seigneur, tout honneur, je tiens tout spécialement à remercier mon chef, Frédéric BOUSSINOT, qui m a accepté comme disciple de l Approche Réactive. Au cours de ces quelques cinq années passées à ses côtés, j ai pu apprécier sa bonne humeur, son étonnante disponibilité (je crois que je connais aussi bien son bureau que le mien), sa grande patience, sa gentillesse et l humour omniprésent qu il nous prodigue. Inutile de préciser que le petit étudiant en physique que j étais a beaucoup appris à son contact sur cette discipline particulière qu est l informatique. Qu il me soit permis également de remercier ici tout particulièrement Valérie ROY qui, par ses précieux conseils, m a aidé à me réorienter et à atterrir au CMA, il y a quelques années après des études de physique. Merci aussi pour le travail énorme qu elle a effectué dans la relecture minutieuse de mon manuscrit. Je n oublie pas non plus les personnes qui constituent et ont constitué le CMA durant ces dernières années, ainsi que les membres du projet MEIJE et maintenant ceux du projet MIMOSA, auxquels j adresse une pensée émue et reconnaissante. Les nombreuses discussions et présentations que nous avons eu m ont permis, jour après jour, de me sentir un peu plus à l aise dans cette discipline d adoption et parfois m ont permis également de me remémorer de lointaines notions de physique. Merci pour leur accueil et l ambiance de travail agréable qu ils instaurent. Je salue les étudiants et compagnons de jeu ;-) que j ai côtoyé durant ces années : Raul ACOSTA-BERMEJO, Sebastien BOISGERAULT, Michel BOURDELLES, Yannis BRES, Christian BRUNETTE, Silvano DAL-ZILIO, Nicolas GOMEZ, Loic HENRY-GREARD, Karima MACHANE, Fabrice PEIX, Dimitru POTOP-BUTUCARU, Xavier THIRIOUX, Horia TOMA, Eric VECCHIE, Pascal ZIMMER... He oui, en presque 6 ans j ai eu la chance de connaitre pas mal de monde. Je ne remercie pas M. ALZHEIMER pour tous les gens que j aurais involontairement oubliés de citer ici. J adresse une pensée toute particulière aux différentes personnes qui ont partagé leur bureau avec moi pendant ces années. La bataille pour l utilisation de la clim fut rude ;-). Enfin, je remercie également : Catherine JUNCKER de l INRIA, Dominique MICOLLIER de l École des Mines, pour leur aide et leur efficacité dans l organisation matérielle de la soutenance.
Table de matières Chapitre 1 Introduction 1 1.1 Modularité et parallélisme...1 1.2 L Approche Synchrone... 2 1.3 L Approche Réactive... 4 1.4 Les formalismes réactifs...8 1.5 Systèmes réactifs en Java... 9 1.6 Structure du document... 11 Chapitre 2 Les SugarCubes v1 15 2.1 Mécanisme d exécution : instructions et machines...16 2.1.1 Instructions...16 2.1.2 Machines d exécution... 19 2.2 Les principales primitives... 20 2.2.1 Nothing et Stop... 21 2.2.2 Les actions atomiques...22 2.2.3 L opérateur de séquence... 22 2.2.4 Parallélisme...23 2.2.5 Les boucles...24 2.2.6 Contrôle de micro-étapes... 25 2.3 La programmation événementielle...27 2.3.1 Les événements...27 2.3.2 Les configurations événementielles...28 2.3.3 Génération d événements...30 2.3.4 Attente sur une configuration événementielle... 30 2.3.5 Préemption... 31 2.3.6 Contrôle d exécution par un événement... 33 2.3.7 Déclaration locale d événement...33 2.4 Exemple d utilisation des SugarCubes...34 2.5 Limitations... 40 2.5.1 L interface des SugarCubes avec Java...40 2.5.2 Interface utilisateur... 42 2.5.3 Efficacité et Sémantique... 42 Chapitre 3 Extensions des SugarCubes 45 3.1 Les Cubes... 45 3.1.1 Communication entre Cubes...46 3.1.2 Extension dynamique et gel de comportement... 49 3.2 Nouvelles primitives... 50 3.2.1 Lien entre programme réactif et objet Java...50 3.2.2 Mécanismes de notifications...51 3.2.3 Communication par événements valués...53
ii Table des matières 3.2.4 Extension dynamique et gel d instruction...54 3.2.5 La primitive Cube... 56 3.3 L'interface de programmation utilisateur... 57 3.3.1 Les interfaces de base de programmation...57 3.3.2 L exécution des programmes...59 3.3.3 Programmation des effets de bords Java...62 3.4 Exemple...67 3.5 Conclusion...71 Chapitre 4 Implémentation 73 4.1 Machine, environnement et instructions... 73 4.1.1 Instructions...73 4.1.2 Environnement d exécution...76 4.2 Link et variables locales...81 4.2.1 L interface Link... 82 4.2.2 Gestion des Links par l environnement d exécution... 82 4.2.3 La classe LinkImpl...82 4.2.4 Déclarations de variables locales...85 4.2.5 Opérations atomiques...86 4.3 Événements valués, Callback-Listener... 88 4.3.1 Modifications de la classe Event...88 4.3.2 Génération d événements valués... 89 4.3.3 Callback-Listeners... 90 4.4 Shell...91 4.4.1 L interface Shell...92 4.4.2 La classe ShellImpl...92 4.4.3 L instruction AddToShell... 93 4.5 Freezable... 94 4.5.1 La classe Freezable... 94 4.5.2 L instruction Freeze...96 4.5.3 Gestion des requêtes de gel d instruction par l environnement...96 4.6 Les Cubes... 97 4.6.1 La classe Cube... 98 4.6.2 L instruction Destroy...99 4.6.3 Les Machine Réactives... 100 4.7 Conclusion...100 Chapitre 5 Junior 101 5.1 Motivations...101 5.2 Définition... 102 5.3 Sémantique...105 5.3.1 Les règles SOS...105 5.3.2 Syntaxe...106 5.3.3 Définition de l environnement d exécution...108 5.3.4 Primitives de base... 108 5.3.5 Les primitives événementielles...111 5.3.6 Contexte d exécution... 116 5.3.7 Efficacité...117 5.3.8 REPLACE...117 5.4 Implémentations...120 5.4.1 REWRITE...120 5.4.2 REPLACE...123 5.4.3 Simple... 126 5.5 Conclusion...127
Tables des matières iii Chapitre 6 Storm 129 6.1 Parallélisme et grand nombre d événements...129 6.2 Définition de Storm...131 6.3 Algorithme et sémantique... 132 6.3.1 Un nouveau statut d exécution : WAIT...132 6.3.2 Le parallélisme...134 6.3.3 Les précurseurs... 136 6.3.4 Formalisation des précurseurs...138 6.4 Implémentations...141 6.4.1 Implémentation directe des règles de sémantique : Formal Storm...141 6.4.2 Implémentation à base de files d attente : Storm...144 6.5 Conclusion...150 Chapitre 7 Expérimentations 153 7.1 Les Scripts Réactifs...153 7.1.1 Génération de programmes SugarCubes à la volée... 154 7.1.2 Interprète d actions externes...158 7.1.3 Les différentes formes du langage des Scripts Réactifs...160 7.2 Les Icobjs... 163 7.2.1 Notion d Icobjs... 163 7.2.2 La programmation par Icobjs...164 7.2.3 Implémentation et applications...166 7.3 Les systèmes distribués... 171 7.3.1 Les systèmes synchronisés...171 7.3.2 Les algorithmes de détection de fin d instant... 173 7.3.3 Deux infrastructures de communication distribuée... 174 7.3.4 Analyse du système...176 7.4 Migration de code...177 7.4.1 Mécanisme de migration...178 7.4.2 Expérience...179 7.5 Conclusion...181 Chapitre 8 Conclusion et perspectives 183 8.1 Réalisations... 183 8.2 Perspectives...186 Bibliographie 189
iv Table des matières
Chapitre 1 Introduction L augmentation de la masse et de la diversité des informations à traiter par les systèmes informatiques actuels, en particulier dès qu il s agit de systèmes de communication, a considérablement alourdi leur développement. De par leur taille importante, la simple maintenance de ces systèmes au jour le jour, devient une tâche critique mobilisant bien souvent des équipes entièrement dédiées. La généralisation d Internet et des autres systèmes de communication aggrave encore cette situation. L adaptation aux nouvelles technologies et la prise en compte des nouveaux types de contenus nécessitent une longue planification et les transformations d un système déjà existant ne sont pas toujours évidentes alors que son environnement évolue de plus en plus vite. Si la quantité d information dont l Internet ne manque pas de nous inonder a suscité le développement d applications nouvelles, la complexité grandissante de ces systèmes oblige naturellement à se tourner vers des solutions modulaires et réutilisables capables d en faciliter la conception et la maintenance. Plutôt que de développer une application monolithique spécialisée, les techniques de programmation se sont rapidement tournées vers des paradigmes modulaires, offrant une plus grande réutilisabilité et une maintenance aisée. La montée en puissance, à pas soutenu, des ressources matérielles a d ailleurs grandement contribué à cela. La conception modulaire des systèmes consiste à les découper, de manière rationnelle, en sous-modules fonctionnels fournissant un certain nombre de services qui sont utilisés par les autres composants pour atteindre le but global de l application. Dans un tel système, chaque module s acquitte d une tâche précise en interagissant avec les autres. Cette approche modulaire permet d abstraire les différentes fonctionnalités au sein d une application et les interactions entre modules au niveau d un ensemble de services sans subir d interférences avec les moyens mis en œuvre par le module pour fournir ces services. Ainsi on dégage différents niveaux de granularité pour analyser le système, chaque niveau étant un à un plus simple à appréhender. Une caractéristique de cette approche modulaire est son aspect fractal dans le sens où le principe de la découpe d un système en modules peut être appliqué à l un de ces modules et inversement un système informatique peut lui-même être vu comme un module d un système applicatif plus complexe. De très nombreux travaux ont été réalisés afin de développer des modèles de programmation plus modulaires, capables de prendre en compte les différentes contraintes en termes de facilité de conception et de maintenance des systèmes, ainsi qu en termes de réutilisation des développements. Ces recherches aboutissent, de nos jours, au succès croissant des modèles objets dans les développements des systèmes informatiques. L importance industrielle des développements en C++ et le succès fulgurant du langage Java illustrent bien cette reconnaissance des modèles de programmation objet. Nous revenons sur langage Java plus loin dans cette introduction. Mais pour le moment, intéressons nous a un aspect plus méconnu offrant des gains de modularité très importants : le parallélisme. 1.1 Modularité et parallélisme La plupart des programmes informatiques appliquent des traitements à des données qui leur sont
2 Chapitre 1 : Introduction passées au début de leur exécution. Lorsque ces programmes terminent, ceux-ci génèrent alors les résultats des traitements qu ils ont appliqués. Cette approche, que l on qualifiera de classique, des systèmes informatiques se retrouve également au niveau des solutions utilisées pour mettre en œuvre la modularité. Ainsi une procédure, une fonction, une méthode d un objet est un programme qui accepte au début de son exécution des données (les paramètres) et génère en sortie des résultats (les retours). Cependant, avec l importance grandissante des systèmes de communication, le besoin de prendre en compte l expression du parallélisme et de la concurrence au sein d un programme potentiellement distribué oblige à envisager d autres paradigmes. Ainsi, de nombreuses recherches ont été menées afin de prendre en compte les aspects parallèles et concurrents des systèmes dans les techniques de programmation. Mais souvent, ces résultats ont été cantonnés aux seuls systèmes d exploitations et peu de langages ont réussi à imposer l expression du parallélisme comme un outil garant d une plus grande modularité et d une plus grande réutilisabilité des développements. Si le parallélisme et la concurrence sont considérés comme des points importants de la conception d un système, leur utilisation vise principalement à tirer profit des aspects distribués des ressources informatiques ou à permettre de renforcer l indépendance de tâches particulières au sein d un même système. De nos jours, le modèle le plus connu (et probablement le plus utilisé) d expression du parallélisme et de la concurrence reste le modèle des threads, hérité des architectures de systèmes d exploitations. Ce modèle, qui repose sur des notions de moniteurs d exécution, de sections critiques et autres verrous, s avère cependant complexe à utiliser et n incite pas vraiment à user pleinement des capacités modulaires du parallélisme. En 1985, D. Harel et A. Pnueli [HP] ont proposé un nouveau paradigme : les systèmes réactifs. Il s agit de systèmes qui ne sont pas censés terminer pour produire des résultats contrairement à ceux de l approche classiques présentée précédemment. Ces systèmes réagissent de façon continue, à toute modification de leur environnement, en influant en retour sur ce même environnement. Ce sont donc des programmes cycliques qui entretiennent une interaction étroite et continue avec leur environnement. Les systèmes réactifs se conçoivent naturellement dans un cadre concurrent ou parallèle. Chaque composant, s exécutant en parallèle, réagit à une perturbation de son environnement d exécution en produisant à son tour une modification de l environnement qui fera réagir d autres composants. Le développement des formalismes synchrones s inscrit dans cette optique. 1.2 L Approche Synchrone Dans le cadre de l Approche Synchrone, on passe d une interaction continue du système avec son environnement à une interaction discrète (discrétisation temporelle). L introduction d une horloge globale servant à échantillonner l environnement et de couples d activation/réaction permettent de réaliser cette transition vers un monde discret. À chaque activation, un système réagit, aussi rapidement que possible, à toute modification de son environnement (les entrées ou inputs) et engendre à son tour une modification de l environnement (les sorties ou outputs). Dans un tel système, une implémentation mettant en œuvre du parallélisme est privilégiée, du fait de la possibilité de réagir immédiatement à plusieurs modifications simultanées de l environnement du système. Dans ce cas, tous les composants parallèles du système sont exécutés au cours d une réaction, de sorte que tous peuvent réagir à toutes les modifications survenues dans l environnement. A ce niveau, deux types de systèmes peuvent être envisagés : le rythme est donné par l environnement et le système réagit instantanément à toute modification. Dans ce cas, on reste très proche du modèle théorique continu des systèmes réactifs. Lorsqu un élément de l environnement subit une transition, le système réagit instantanément. On peut avoir des rythmes de réaction différents (des horloges différentes) en fonction des éléments de l environnement considérés. le rythme est défini par le système. L horloge du système défini l échantillon de l environnement sur lequel le système va réagir. Le rythme doit être suffisamment soutenu pour que toutes les modifications de l environnement puissent être prise en compte. C est ce second cas que nous allons considérer dans ce document.
Chapitre 1 : Introduction 3 L Approche Synchrone repose sur une hypothèse fondamentale selon laquelle la durée logique des réactions est nulle (on dit qu une réaction est atomique). En d autre termes, le système réagit suffisamment vite par rapport aux modifications de l environnement de manière à ne pas perdre d événements. Dans ce cas, les sorties d un système synchrone sont émises simultanément aux entrées. Cela a pour conséquence que l environnement d un système est parfaitement déterminé et stable lors d une réaction, puisque de façon instantanée les entrées et les sorties sont connues et constituent l échantillon de l environnement. Dans la suite de ce document, nous appelons environnement l échantillon (la photographie instantanée) de ce dernier correspondant à une réaction. Les formalismes synchrones que nous considérons ici proposent différents langages permettant d exprimer dans un programme les réactions d un système à une succession d activations dans des échantillons successifs de l environnement. Mais ils doivent également s assurer que le programme ainsi exprimé satisfasse l atomicité des réactions. En particulier, il faut s assurer de l absence d incohérence dans ce qui est produit par les différentes branches parallèles d un système et que celles-ci aient bien toutes la même vision de l environnement. En effet, la puissance expressive des langages synchrones est souvent trop grande et permet d écrire des systèmes incohérents. Cette contrainte supplémentaire impose en général une analyse statique des programmes en vue de rejeter les programmes non conformes. En outre, les sorties d un système doivent être définies de manière unique en fonction des entrées à chaque réaction car les formalismes synchrones sont déterministes. L analyse statique des programmes devra en conséquence rejeter un programme pouvant conduire à plusieurs séquences de sorties différentes pour une même configuration d entrée. Or, en pratique, cette analyse ne peut-être effectuée que par approximations, ce qui conduit à rejeter des programmes qui auraient pu être admis en effectuant d autres choix d analyse. De ce fait il devient important de fixer les choix d analyse qui vont être mis en œuvre car ceux-ci ont un impact direct sur la puissance expressive du langage au final. P1 P2 P3 Fig. 1 : P1, P2 et P3 sont trois composants s exécutant en parallèle de manière atomique. Les entrées et les sorties sont synchrones. On distingue deux grandes catégories de formalismes réactifs/synchrones : Les formalismes orientés flots de données. Dans ce type de formalisme, l environnement d exécution du programme est représenté par des flots de données. Un flot de donnée est une suite temporelle de valeurs. Un flot peut être vu comme un canal de communication qui, à chaque réaction successive, présente une nouvelle valeur. Le programme réactif qui traite alors ces données est constitué d un ensemble d équations qui calculent les valeurs des flots de sortie à partir de flots d entrée. Ces équations sont évaluées en parallèles et constituent donc les composants parallèles du système. Dans ce type de formalismes, le style déclaratif est naturellement privilégié. Les principaux langages basés sur ces principes sont les langages Lustre[HCRR], Signal[GGBM], Lucid Synchrone[CP] etc. Les formalismes orientés contrôle d exécution. Dans ce type de formalisme l accent est mis sur le contrôle d exécution et plus précisément sur l ordonnancement et le contrôle des tâches à
4 Chapitre 1 : Introduction exécuter par le programme. L environnement d exécution est constitué d un ensemble d événements ou de signaux qui sont utilisés pour contrôler l exécution d un programme. La caractéristique la plus importante d un signal ou d un événement est sa présence ou son absence dans l environnement d exécution. En général, un programme réactif dans ce type de formalisme est une description dans un style impératif des réactions des différents composants parallèles à la présence ou à l absence d événements/signaux. Le principal langage basé sur ces principes est le langage Esterel[BG] En fonction du type de formalismes choisis, l hypothèse d atomicité pose des problèmes différents au moment de l analyse statique des programmes. Dans le cadre des formalismes orientés flots de données, l analyse statique d un système doit vérifier qu à chaque instant, il existe au moins une façon d ordonner les équations décrivant le système. Ainsi, la résolution du système d équations devient possible. Elle doit également conduire à une solution unique des sorties en fonction des entrées. Une autre conséquence de cette analyse statique préalable est que le programme s exécutera en mémoire bornée (cette dernière propriété est souvent prise comme caractéristique d un système réactif). En d autres termes, cela signifie qu on a la certitude que les flots de données ne s accumulent pas en mémoire dans un goulot d étranglement du programme en attente d un traitement. Si l on considère des programmes écrits en flot de données sous la forme de réseaux de processus s exécutant en parallèle et communiquant entre eux par des files d attente, ces files d attente sont de taille bornée et la taille maximale des files d attente peut-être statiquement déterminée. Dans le cadre des formalismes orientés contrôle, l analyse statique doit s assurer à chaque instant que les signaux de sortie sont définis de façon unique (solution déterministe) à partir des signaux d entrée. En particulier, cela signifie qu il faut s assurer que si un signal est considéré comme étant absent, cette hypothèse est unanimement partagée par toutes les instructions mises en jeu au cours de la réaction. Les problèmes que l on rencontre au cours de cette analyse sont appelés cycles de causalités [Be1]. Ils surviennent lorsque, par exemple, un programme faisant l hypothèse de l absence d un signal émet instantanément celui-ci, infirmant ainsi l hypothèse faite au cours de la réaction. Un certain nombre de formalismes graphiques (principalement orientés contrôle) ont également été proposés pour faciliter l implémentation des systèmes synchrones : Les StateCharts [Ha], créés par D. Harel permettent la spécification graphique de systèmes réactifs. Argos [Mar], développé par F. Maraninchi reprend les principes des StateCharts en proposant une sémantique strictement définie. L extension aux formalismes synchrones orientés flots de données et en particulier à Lustre est également couverte par ce formalisme. Les SyncCharts [An], développés par C. André, s inspire des travaux de D. Harel dans le cadre de formalismes synchrones orientés contrôle et produisent du code Esterel. Les formalismes synchrones s intéressent principalement à des systèmes statiques, bien définis (dans lesquels le nombre de composants parallèles est défini à la compilation), sur lesquels il est possible d appliquer des raisonnements formels en vue de prouver certaines propriétés. Dans ce document, nous nous intéressons aux formalismes orientés contrôle dans la mouvance du langage Esterel. 1.3 L Approche Réactive L Approche Réactive que nous allons considérer dans ce document est définie par F. Boussinot dans l ouvrage La programmation réactive [Bo1]. Cette approche dérive de l Approche Synchrone et regroupe un ensemble de formalismes permettant d implémenter des systèmes réactifs. Elle a pour caractéristique de pouvoir évoluer dynamiquement, en cours d exécution, en modifiant le nombre de composants parallèles. Dans ces conditions, la souplesse obtenue, grâce au caractère dynamique des systèmes ainsi construits, se paye par une perte d expressivité (plus ou moins dommageable en fonction du type de systèmes considérés) et l impossibilité d établir des preuves sur les aspects dynamiques. L Approche Réactive poursuit les objectifs suivants : fournir un ensemble de primitives permettant l expression simple et puissante du parallélisme au
Chapitre 1 : Introduction 5 niveau d un langage de programmation ; permettre l expression de systèmes dynamiquement reconfigurables en cours d évolution. Ceci est en effet plus adapté dans le cadre de langages de programmation généralistes, en particulier lorsqu on s intéresse à des systèmes distribués ; fournir un modèle déterministe de programmation du parallélisme, formellement spécifié, dont les résultats soient reproductibles indépendamment des implémentations et des plates-formes d utilisation ; fournir des mécanismes simples et puissants de communication et de synchronisation entre les différents composants parallèles d un système ; exhiber le caractère modulaire de la programmation parallèle en insistant sur la réutilisabilité des composants parallèles développés, en particulier, par combinaison parallèle de ces composants ; fournir un modèle de programmation du parallélisme cohérent avec un modèle de programmation à base d objets. Instants de durée non nulle Sur le modèle de l Approche Synchrone, l Approche Réactive introduit une notion d horloge globale dans les différents formalismes qu elle recouvre. Cette horloge découpe l exécution d un programme en une succession d instants logiques (réactions). À chaque activation, un programme réactif exécute une réaction dont la durée est celle de l instant : tous les composants parallèles constituant le programme évoluent au même rythme. Le temps est considéré comme un temps logique (par opposition aux systèmes appelés temps réels). La principale différence entre l Approche Réactive et l Approche Synchrone réside fondamentalement dans sa manière de gérer l évolution de l environnement d exécution du système. L Approche Synchrone fait l hypothèse d atomicité des instants. L Approche Réactive s en distingue essentiellement par un affaiblissement de cette contrainte fondamentale : aucune hypothèse particulière n est faite sur la durée d une réaction. En particulier, cela signifie qu un instant a une durée, on peut donc parler d évolution au cours d un instant. L introduction d une durée des instants a également une autre conséquence : il devient possible de découper l exécution d un instant de réaction du système en un ensemble de micro-étapes. Ainsi, l exécution d une réaction peut prendre des formes différentes, comme par exemple des enchaînements de phases successives bien définies ou bien des oscillations amorties jusqu à atteindre un état stable définissant la fin d'instant. En d autres termes, un programme dans l Approche Réactive converge vers la fin d instant en calculant un point fixe caractérisant l état stable du programme. Par contre, les perturbations de l environnement sont atomiques c'est-à-dire qu aucune action concurrente ne peut venir contrarier une modification de l environnement par le système. Ainsi, l environnement d un système est toujours présenté dans un état cohérent. L Approche Réactive propose un certain nombre de primitives qui permettent de contrôler, avec une granularité fine, l exécution d un programme, en s appuyant sur cette notion de micro-étapes. Ces primitives permettent en particulier de définir plus précisément les stratégies d exécution au cours d un instant. Elles contribuent à renforcer le caractère déterministe de l exécution parallèle d un ensemble de composants en permettant d analyser également dans certains cas l ordonnancement des effets de bords. Cependant, ces micro-étapes ne doivent pas être confondues avec la notion d instant. En effet, les événements et le parallélisme synchrone restent des notions définies par rapport aux instants (que l on appelle aussi parfois des macro-étapes). Une micro-étape ne peut donc pas revendiquer les mêmes propriétés qu un instant. En particulier, au cours d une micro-étape, l environnement d exécution peut évoluer; il ne sera donc pas vu forcément à l identique par l ensemble des composants parallèles. La vision cohérente de l environnement partagée par tous les composants d un système est une notion définie au regard des instants d exécution et non des micro-étapes. Parallélisme Comme pour l Approche Synchrone, la notion d instant fournit un moyen de définir une sémantique claire du parallélisme : chaque composant en parallèle exécute un bout de son programme au cours d un instant. Mais, le fait que ces instants aient une durée permet d appréhender le problème sous une forme différente : la fin d un instant est effective lorsque tous les composants parallèles du système ont terminé
6 Chapitre 1 : Introduction leur exécution pour l instant courant. Ainsi, tous les composants se synchronisent à chaque fin d instant. Instant 1 Instant 2 Instant 3 Instant 4 Instant 5 P1 P2 P3 Fig. 2 : Exécution parallèle des composants P1, P2 et P3. Événements La notion d instant logique permet de définir un puissant moyen de communication entre les composants parallèles d un système réactif : la communication par diffusion instantanée de signaux ou d événements (l Approche Réactive utilise en général le terme d événement). Ce type particulier de communication a été introduit par le langage Esterel[Be2] et présente les propriétés suivantes : instantanéité : un événement est un message échangé entre composants parallèles. Cet événement est en fait un élément de l environnement d exécution du système réactif dont la durée de vie (présence dans l environnement) est celle d un instant. Il s agit d une donnée non persistante entre instants dont l état sera redéfini à chaque nouvel instant. diffusion : cet événement est vu à l identique par l ensemble des composants s exécutant en parallèle dans le système à l instant de sa génération. Autrement dit, pour le même instant, deux composants parallèles ne peuvent avoir deux informations différentes sur le même événement; c est-à-dire que l on ne peut avoir un composant qui voit un événement présent, tandis qu un autre le voit absent au cours du même instant. Instant Fig. 3 : Diffusion instantanée d événements. Ce mécanisme de communication à deux conséquences particulièrement intéressantes : mémoire bornée (pas de gestion de file d attente). L état d un événement n est conservé que durant un instant. À l instant suivant le même événement aura un nouvel état qui ne sera pas directement déduit de l état précédent. Il n y a pas de mémoire de l état d un événement d un instant sur l autre (tout au moins en termes d événement purs; c est à dire lorsque l on ne s intéresse qu à la présence ou à l absence de l événement). modularité (pas de références sur l émetteur ou le récepteur). Deux composants n ont pas besoin
Chapitre 1 : Introduction 7 de se connaître a priori pour pouvoir communiquer entre eux dès qu ils se retrouvent exécutés en parallèle dans le même système. Ils communiquent à travers l environnement d exécution qu ils partagent. Cependant à la différence des variables globales, les règles d accès à cet environnement sont définies par rapport à la notion d instant. La notion d événement diffusé instantanément permet également de donner une sémantique claire aux notions de simultanéité et d absence d événements. En effet, la simultanéité de deux événements dans un cadre asynchrone est difficile à définir. Dans un cadre synchrone, deux événements sont simultanés, s ils sont présents dans l environnement dans le même instant. De même, l absence d un événement est clairement définie par rapport à la notion d instant : un événement est absent au cours d un instant s il n est pas produit au cours de celui-ci. Cas de la réaction à l absence Nous avons vu qu afin de maintenir la cohérence du système, tous les composants doivent avoir la même information sur l état d un événement au cours d un instant. Si l événement est généré au cours d un instant, il doit être considéré présent tout au long de l instant par tous les composants du système qui se réfèrent à cet événement au cours de leur exécution. Dans ces conditions, l Approche Réactive, interdit toute hypothèse sur l absence d un événement au cours d un instant. C est une des différences fondamentales de l Approche Réactive avec l Approche Synchrone. Au début d un instant, le statut d un événement est inconnu ou présent (s il est généré par l extérieur, comme une entrée du système). On ne sait qu un événement était absent qu à la fin d un instant car il ne peut plus être émis. La réaction à l absence d un événement est donc naturellement reportée à l instant d après. Au cours d un instant, aucun composant ne peut faire l hypothèse de l absence d un événement pour poursuivre son exécution immédiatement ; on autorise donc la réaction instantanée à la présence mais pas à l absence d un événement. Sans cette restriction, une hypothèse d absence pourrait en effet se voir infirmer par une génération ultérieure de l événement au cours de l instant, ce qui violerait la propriété de diffusion des événements. Ainsi, par cette simple restriction sémantique, on élimine les problèmes de causalité rencontrés dans les formalismes synchrones. Il devient alors possible de composer un système réactif complexe constitué de la mise en parallèle de modules élémentaires sans risque de soulever un problème de causalité. Cette combinaison parallèle de composants constitue un gain important en termes de modularité. Dynamisme La notion d instant global de durée non nulle de l Approche Réactive présente également l avantage de dégager naturellement des moments privilégiés où l exécution d un système a atteint un état stable : la fin d instant. Cela permet de concevoir des mécanismes : permettant l ajout dynamique de nouveaux composants parallèles entre deux instants. Cet ajout dynamique ne pose aucun problème puisque les programmes, de par les restrictions sémantiques des formalismes de l Approche Réactive, ne peuvent générer des problèmes de causalité. La composition parallèle est donc toujours possible. permettant de retirer dynamiquement des composants en train de s exécuter dans un système lorsqu ils sont parvenus dans un état stable (fin d instant). Cela permet d implémenter des systèmes de codes mobiles : le composant retiré est suspendu et son exécution peut être reprise ultérieurement sur un autre site. Il est aussi possible d implémenter des systèmes persistants par exemple pour de la tolérance aux pannes : un programme peut être copié sur un support de stockage à la fin d un instant pour être repris ultérieurement en cas de panne. Un système réactif peut ainsi être reconfiguré dynamiquement sans aucun problème entre deux réactions consécutives par ajout ou retrait de composants parallèles en cours d exécution. Cette caractéristique dynamique est une particularité de l Approche Réactive qui la rend adaptée à la programmation des systèmes présentant par nature un fort caractère dynamique, tels que les systèmes
8 Chapitre 1 : Introduction distribués, les systèmes à base d agents ou les interfaces graphiques. L Approche Synchrone est souvent perçue comme un ensemble de formalismes axés sur la modélisation et la validation de systèmes statiques, en particulier dans le domaine du hardware. De par ces différences avec l Approche Synchrone, l Approche Réactive met l accent sur la programmation des systèmes informatiques en particulier si ceux-ci présentent un fort caractère parallèle et dynamique. 1.4 Les formalismes réactifs L Approche Réactive, élaborée par F. Boussinot, est issue de travaux menés autour du Synchrone et principalement du langage Esterel. Les premiers formalismes engendrés par cette approche ont été initialement construits aux dessus de langages procéduraux tels que C et Tcl-Tk [Ou]. En particulier, le langage Reactive-C proposé comme une extension réactive du langage C, a servi, à l image d un assembleur bas niveau, à implémenter d autres formalismes réactifs de plus haut niveau. Les principaux formalismes qui ont été développés dans ce cadre sont les suivants : Reactive-C[Bo2]. Ce langage ajoute un ensemble de primitives réactive, au langage C. Toute la puissance de C est disponible, pour coder les réactions. De ce fait, la récursion et la création dynamique de nouveaux composants sont autorisées, afin de ne pas limiter la puissance expressive de C. Reactive-C se présente comme un préprocesseur générant du C. Cependant, la communication entre composants réactifs parallèles reste de très bas niveau en utilisant des variables globales. Cette communication n est donc pas vraiment définie par rapport à la notion d instant. Reactive-C est donc une sorte d assembleur réactif permettant d implémenter des mécanismes d exécution d instant. Le langage SL[BS]. Il s agit d un langage synchrone très proche d Esterel dans lequel la restriction fondamentale, pour éviter les problèmes de causalité, consiste à interdire la réaction instantanée à l absence de signaux. Comme en Esterel, la création dynamique est interdite en SL et il n y a pas de possibilité de programmation de micro-étapes de réaction. Les Objets Réactifs[DB]. Il s agit d avantage ici d un modèle de programmation, visant à intégrer les concepts de la programmation objet avec les principes de l Approche Réactive. Le modèle ROM[LB] propose de considérer un type particulier d objets, dérivé du modèle des acteurs. Chaque méthode d un objet est un programme réactif qui s exécute pour la durée d un instant à chaque fois qu elle est invoquée. Toute les méthodes réactives d un objet qui sont invoquées au cours d un instant sont activées en parallèle dans le système à l instant de leur invocation. Une méthode ne peut être invoquée au plus qu une seule fois par instant. L invocation correspond à un envoi de message instantané (l exécution a lieu dans le même instant que l invocation) et n est pas bloquante (on attend pas que la méthode invoquée soit exécutée pour poursuivre l exécution). La communication est une communication point à point entre deux objets. Un retour notifie le refus (par exemple si une invocation a déjà été faite pour l instant courant) ou l acceptation de la requête. Le caractère dynamique de l Approche Réactive permet à ce modèle d utiliser les principes de la programmation basée objet, dans laquelle un objet peut être cloné et de nouvelles méthodes peuvent dynamiquement lui être ajoutées. Les Objets Réactifs Distribués[BDS]. Il s agit d une variante du modèle ROM, dans laquelle on considère des systèmes distribués, formés d îlots synchrones communiquant entre eux de manière asynchrone. Dans chaque îlot synchrone, les objets s exécutent conformément au modèle ROM standard. Lorsque deux objets présents sur deux îlots synchrones différents communiquent entre eux, l invocation d une méthode devient un message asynchrone véhiculé à travers le réseau. Ces messages d invocation restent non bloquants puisque aucune confirmation de la prise en compte ou non du message n est délivrée en retour. Les Scripts Réactifs[BH]. Ils apportent toute la souplesse et le dynamisme d un langage interprété à l Approche Réactive. Les programmes exécutés en parallèle par l interprète sont ajoutés
Chapitre 1 : Introduction 9 dynamiquement en cours d exécution. Une implémentation sous la forme d un interprète de commandes à la UNIX a été réalisée. On identifie dans ce cas la réaction de l interprète à l entrée d une nouvelle commande de l utilisateur à la notion d instant des systèmes réactifs. Le langage des Scripts Réactifs ne définit que les primitives réactives responsables du contrôle et de l ordonnancement du programme. La gestion des données et les traitements à leur appliquer sont délégués à un langage tiers. La première implémentation des Scripts Réactifs a été réalisée en Reactive-C et utilise le langage Tcl-Tk comme langage tiers de traitement des données. En outre, les Scripts Réactifs mettent à profit la notion d état stable atteint à la fin d un instant afin de définir un mécanisme particulier de gel de programme dans un état cohérent. Un programme gelé peut être récupéré sous la forme d une chaîne de caractères qui peut être utilisée pour implémenter des mécanismes de persistance ou de migration à travers le réseau. Les Icobjs[Bo3]. Les Icobjs et en particulier la programmation graphique par Icobjs constituent un formalisme particulier, permettant d exprimer graphiquement la programmation par combinaison de comportements élémentaires. Cependant, la programmation par Icobjs n est pas un simple habillage graphique des primitives réactives. Elle met l accent sur la notion de combinaison de comportements. Cette programmation extrêmement dynamique offre à l utilisateur inexpérimenté la possibilité de programmer de manière intuitive ses propres systèmes en utilisant des primitives aussi puissantes que les notions de parallélisme, séquence, préemption, diffusion etc. Les programmes sont dynamiquement construits et reconfigurés par les interactions de l utilisateur avec l interface graphique. Ce modèle de programmation graphique a été initialement développé au-dessus des Scripts Réactifs, offrant ainsi une sémantique très précise à chaque action graphique. 1.5 Systèmes réactifs en Java Les langages de programmation à objets se sont imposés dans le développement des systèmes informatiques, en proposant une découpe en modules d un programme guidée par la structure des données que ce dernier doit manipuler. Par contre, peu de langages à objets se sont véritablement intéressés au problème de l expression de la concurrence et du parallélisme (exception faite des modèles à acteurs). En général, un langage à objets ne permet pas de décrire les notions d activités concurrentes et plus généralement de ressources d exécution des programmes. Les travaux présentés dans ce document ont pour but de proposer une extension réactive au modèle objet de Java afin d exprimer les problèmes de concurrence par des primitives de programmation dont la sémantique est présentée formellement. L application de ces techniques dans un cadre distribué est également envisagé. Concurrence et langage à objets En fait, le besoin d intégrer dans les modèles objets les notions de parallélisme et de concurrence a grandi avec la prolifération des systèmes distribués et plus particulièrement de l Internet. Dans ce nouvel environnement, les plates-formes de programmation d objets distribués à travers le réseau ont mis en évidence la nécessité de spécifier les accès concurrents aux ressources et de prendre en compte le parallélisme physique des exécutions. Dans ces conditions la concurrence n est pas vraiment perçue comme un outil de modularité mais plutôt comme un fait inévitable qu il faut obligatoirement prendre en considération. C est pourquoi nombre propositions de plates-formes d objets répartis se sont tournées vers des techniques issues des systèmes d exploitation. En effet le domaine des systèmes d exploitation a très tôt été confronté au problème de la concurrence d accès aux ressources d exécution et au parallélisme (par exemple, dans le traitement des interruptions matérielles ou sur les architectures parallèles) à travers les notions de processus et autres tâches. Le modèle couramment retenu dans les systèmes distribués est le modèle des threads qui permet d abstraire le parallélisme physique asynchrone et permet donc une extension naturelle à diverses architectures parallèles. Le développement récent du langage Java [GJS], souvent présenté comme l un des premiers langages de programmation orienté objet, largement répandu, capable de prendre en considération les problèmes de
10 Chapitre 1 : Introduction concurrence directement au niveau du langage, illustre bien ces besoins nouveaux. Cependant, le modèle de concurrence proposé en Java reste basé sur un modèle de threads et reproduit en cela les solutions mises en œuvre dans la plupart des DPE (Distributed Processing Environement). Si le modèle des threads semble bien adapté à la prise en compte du parallélisme physique des systèmes distribués ou multiprocesseurs, il ne constitue pas un cadre de programmation idéal pour l expression de très nombreuses activités concurrentes modulaires et fortement communicantes. Différentes propositions ont vu le jour afin d étendre ce langage avec différents modèles d expression de la concurrence et le rendre ainsi plus compatible avec la programmation modulaire à objets. Parmi ces différentes propositions, on remarquera l existence de quelques formalismes visant à étendre Java pour la programmation de systèmes réactifs : JavaTriveni [CJJLP] est un ensemble de classes Java pour exprimer la concurrence en s appuyant sur un modèle mélangeant les threads et un système de communication par événements. Ce framework orienté objet fournit des opérateurs de préemption et de contrôle d exécution inspirés de l Approche Synchrone. Pour fonctionner, le calcul de processus Triveni repose sur une hypothèse selon laquelle il y a équité pour l exécution de chaque branche parallèle. Cette assertion n est pas nécessaire dans un cadre totalement synchrone puisque par définition tous les composants parallèles sont naturellement exécutés de manière équitable. Reactive Java [PPLS] est un formalisme implémenté par un ensemble de classes Java, permettant la description de modules parallèles et leurs interconnections. Ce formalisme propose également des primitives permettant de communiquer de façon synchrone ou asynchrone entre composants. Chaque module est implémenté par un thread et un thread supplémentaire est utilisé pour implémenter la préemption. Ce thread de contrôle attend l événement de préemption puis interrompt le thread du module qu il contrôle. Ce thread particulier doit posséder une priorité supérieure à celle du thread contrôlé. Cependant, ce système repose sur certains mécanismes de Java qui ne sont plus désormais supportés par le langage. Jester [AF] est une extension réactive au dessus de Java dont l objectif est de faciliter le développement de systèmes embarqués. Il s agit en fait d un compilateur Esterel implémenté au dessus de Java. Des constructions syntaxiques du langage Esterel sont donc introduites dans ce langage afin de décrire des modules implémentant le comportement concurrent d un système. Un programme Java standard peut être directement passé au compilateur Java (on dit que ce programme est non-réactif ou indifférent). Si par contre le programme contient des constructions Esterel, le compilateur Jester va générer un programme Java implémentant le programme Esterel (implémentant l interface Reactive). C est dans ce cadre que nous proposons d étudier l implémentation de l Approche Réactive au dessus de Java. Approche Réactive en Java Le langage Java nous offre l opportunité d étudier la pertinence de l Approche Réactive dans un cadre orienté objet et distribué. En effet, l Approche Réactive peut être vue comme une alternative intéressante au modèle des threads pour l expression de la concurrence au niveau d un langage de programmation. L Approche Réactive se focalise sur l expression de l ordonnancement et du contrôle des opérations dans un système réactif. La plupart des formalismes et des modèles de programmation réactifs que nous avons brièvement décrits dans la section précédente ne s intéressent pas vraiment aux problèmes des traitements des données manipulées par un programme. En fait, ces traitements sont en général délégués à un langage tiers. Cela est bien illustré dans les cas du langage des Scripts Réactifs (qui délègue les traitements de données au langage Tcl-Tk) ou du langage SL (qui délègue les traitements des données au langage C), par l utilisation de constructions syntaxiques particulières (blocs entre accolades) indiquant des traitements de tâches atomiques à déléguer au langage tiers. Dans ces conditions, l utilisation d un langage tiers impératif ayant recours à des variables globales ne pose pas de grandes difficultés. Mais il n en va pas de même dès lors qu il s agit d interagir avec un langage orienté objet. En effet, l exécution d une tâche atomique va alors nécessiter la définition d un contexte particulier d exécution définissant l objet sur lequel à lieu un traitement atomique. Un langage à
Chapitre 1 : Introduction 11 objets découpe en effet les données à traiter en objets qui constituent le contexte d exécution d une méthode. Un traitement atomique est alors défini par une méthode particulière pour laquelle il faudra définir l objet sur lequel elle s applique. Il devient donc important d introduire dans les formalismes réactifs des constructions particulières permettant de définir une relation étroite entre le langage réactif et les objets gérés par le langage tiers. Dans ce documents, nous proposons un certain nombre d extensions réactives permettant de faciliter l interfaçage entre les formalismes réactifs et les objets du langage Java. Ainsi, nous proposons un ensemble de formalismes permettant d étendre le langage Java afin d exprimer dans un programme la concurrence et la communication entre activités parallèles sans recourir aux threads. Atouts du langage Java Java possède un ensemble de caractéristiques attrayantes dans le cadre de nos recherches : Java possède un modèle objet simple et facile à appréhender (héritage simple, tout est classe et objet ). Le nombre de notions à intégrer est restreint ce qui en fait un langage bien adapté au prototypage. Java possède une API très riche permettant un développement rapide en se concentrant sur l essentiel. Ses nombreuses facilités d accès au réseau (Socket, RMI, ) en font une cible particulièrement adaptée à nos besoins pour l étude de l Approche Réactive dans un cadre distribué. Nous avons employé RMI[RMI] dans l implémentation des Machines Réactives Distribuées présentées au chapitre 7 et la sérialisation des objets Java est utilisée dans des expériences de migration de code (cf. chapitre 7). Java offre en standard des mécanismes d introspection permettant d implémenter des interprètes de codes que nous utilisons dans l implémentation des Scripts Réactifs décrite au chapitre 7. Java est un langage à bytecode qui en fait un langage particulièrement portable et ce quelques soient les plates-formes considérées. Les développements peuvent être mis immédiatement à la disposition de la communauté scientifique sans avoir à se soucier des plates-formes d utilisation. Enfin, Java permet de créer rapidement de petites applications (Applets) directement accessibles à travers un navigateur Web, ce qui permet de proposer rapidement une illustration de nos différents travaux. En particulier nous mettons à profit cette capacité pour proposer sur le site Web du projet Reactive Programming un ensemble d Applets illustrant la programmation par Icobjs que nous décrivons dans le chapitre 7 de ce document. 1.6 Structure du document Le chapitre 2 présente une première implémentation de l'approche Réactive au-dessus de Java : les SugarCubes v1. Cet ensemble de classes Java est présenté en insistant en particulier sur l'implémentation originale de ce langage basé sur des objets jouant le rôle d instructions exécutées par des objets jouant le rôle de machines virtuelles d'exécution. L algorithme d exécution des instructions réactives est discuté. Les principaux opérateurs servant à exprimer l ordonnancement des tâches (séquence, parallélisme, boucles ) sont présentés, donnant un aperçu des capacités expressives de ce langage/framework. Puis nous décrivons les aspects événementiels de la programmation réactive en définissant la notion d événements diffusés instantanément et en présentant leur implémentation. Nous présentons ensuite les principales primitives permettant d exprimer les aspects contrôle d exécution, influencées par les événements présents dans l environnement d exécution. Nous illustrons alors l utilisation des SugarCubes par un exemple complet que nous analysons. Enfin, une discussion sur les limitations de cette première implémentation met en évidence les carences des SugarCubes en termes : d interfaçage avec le langage objet chargé de traiter les données; d interface de programmation et d indépendance entre l écriture des programmes SugarCubes et l implémentation des primitives du langage; d efficacité des algorithmes d exécution des instructions et de sémantique des primitives de l Approche Réactive.
12 Chapitre 1 : Introduction Le chapitre 3 présente les améliorations proposées par la nouvelle version des SugarCubes (v3). En particulier, nous présentons les nouveautés en termes d interfaçage avec le langage Java et la manière par laquelle le modèle objet a été introduit dans la programmation réactive en SugarCubes. Un nouveau modèle d objets réactifs appelés Cubes est exposé. Pour simplifier la présentation des cubes, cet objet complexe est découpé en fonctions élémentaires introduites dans le langage sous la forme de nouvelles primitives que nous détaillons. Le modèle des cubes présenté dans ce chapitre sera défini par rapport à ces fonctionnalités élémentaires. Une instruction appelée Link est introduite afin d associer un objet Java standard par défaut à un programme réactif. Cet objet Java sera alors aisément accessible directement au niveau d un traitement atomique des données en Java. Un nouveau mécanisme de communication entre objets réactifs, basé sur la diffusion instantanée d événements valués est proposé : les Callback/Listener permettent d interfacer directement les événements valués avec des traitements de données atomiques exprimés en Java. L ajout dynamique de nouveaux composants en parallèle dans le système en cours d exécution est décrit. Un nouveau type d instruction appelé Shell mettant en œuvre ce type de mécanisme est présenté. Enfin les possibilités offertes par cette nouvelle mouture pour la programmation de systèmes distribués, mettant en œuvre en particulier des mécanismes de migration de code sont décrites. L introduction d une instruction particulière permettant le gel de programme à la fin d un instant est proposée ainsi qu un ensemble de mécanismes utiles pour permettre au code migrant de se lier dynamiquement à son environnement. Nous présentons également l interface utilisateur des SugarCubes. Nous exposons dans un premier temps les motivations de cette nouvelle structure du framework. Puis nous donnons une description approfondie de cet ensemble restreint de classes et d interfaces qui permet d isoler les aspects de construction et d exécution des programmes, des aspects d implémentation des SugarCubes. Nous proposons une vision plus précise et plus technique des nouvelles possibilités expressives des SugarCubes v3. Enfin nous illustrons cette nouvelle interface de programmation par quelques exemples. Pour conclure cette première partie sur les SugarCubes, dans le chapitre 4, nous présentons les grandes lignes de l implémentation de cette nouvelle version en insistant plus particulièrement sur les nouveaux mécanismes et les nouvelles instructions mises en œuvre. L implémentation du nouvel algorithme d exécution des instructions, appelé Storm, n est pas présentée ici mais dans le chapitre 6. Les mécanismes inter-instants introduits pour implémenter le gel des instructions ou l ajout dynamique de nouvelles instructions sont exposés. L implémentation de l instruction Link est décrite ainsi que les mécanismes de notification aux objets Java. Puis nous présentons l implémentation des événements valués et en particulier l implémentation des Callbacks/Listeners. Les mécanismes permettant de rendre compte du défilement des instants implémentés par la possibilité d enregistrer des services inter-instants sont décrits. L implémentation des primitives permettant de programmer l ajout dynamique en cours d exécution de nouvelles instructions en parallèle (Shells) est présentée. Puis nous présentons les mécanismes implémentant en SugarCubes v3 les opérations de gel d instruction. Enfin, l implémentation des cubes à partir des instructions présentées dans les sections précédentes est discutée. Dans le chapitre 5, nous nous intéressons à la formalisation d un noyau des principales primitives de l Approche Réactive à travers la définition d un nouveau formalisme appelé Junior. Nous présentons les motivations à l origine de ce travail en insistant plus particulièrement sur les aspects de formalisation du réactif ainsi que sur la volonté de définir des implémentations capables de traiter un grand nombre de composants s exécutant en parallèle à chaque instant et communiquant entre eux par un grand nombre d événements. Nous précisons certains choix qui ont été retenus pour définir ce noyau, principalement inspiré par la première version des SugarCubes. La définition de Junior vient ensuite ainsi que la présentation des principaux opérateurs. Sur les bases de cette définition, deux systèmes de règles de sémantiques opérationnelle sont proposés afin de spécifier formellement ces opérateurs. Le premier système de règles de réécriture, baptisé REWRITE, constitue un noyau de référence. Tandis que le système REPLACE propose une première tentative permettant de formaliser des optimisations de l algorithme d exécution des instructions réactives. Nous présentons enfin les implémentations qui ont été réalisées directement déduites des systèmes de règles. Nous présentons, également, une implémentation particulièrement efficace en terme d objets exécutés en parallèle et du nombre d événements mis en jeu, appelée Simple.