Proposal for a Dynamic Synchronous Language Pejman Attar, Frédéric Boussinot, Louis Mandel, Jean-Ferdy Susini To cite this version: Pejman Attar, Frédéric Boussinot, Louis Mandel, Jean-Ferdy Susini. Proposal for a Dynamic Syn- chronous Language. 2011. hal-00590420 HAL Id: hal-00590420 https://hal.archives-ouvertes.fr/hal-00590420 Preprint submitted on 3 May 2011 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Proposal for a Dynamic Synchronous Language∗ Pejman Attar Fr´ed´eric Boussinot Louis Mandel INRIA - INDES INRIA - INDES Universit´eParis 11 - LRI [email protected] [email protected] INRIA - PARKAS [email protected] Jean-Ferdy Susini CNAM - C´edric [email protected] May 3, 2011 Abstract or Java threads). The simplification basically results from a cleaner and simpler semantics, which reduces We propose a new scripting language called DSL bas- the number of possible interleavings in parallel com- ed on the synchronous/reactive model. In DSL, sys- putations. However, standard synchronous languages tems are composed of several sites executed asyn- introduce specific issues (namely, non-termination of chronously, and each site is running scripts in a syn- instants) and have major difficulties to cope with dy- chronous parallel way. Scripts may call functions that namic creation (of threads, components, or signals); are considered in an abstract way: their effect on the moreover they are generally not able to fully bene- memory is not considered, but only their “orchestra- fit from real parallelism, as that provided by multi- tion” i.e. the organisation of their calls in time and in core machines. We propose a new synchronous lan- place (the site where they are called). The mapping guage, called DSL (for Dynamic Synchronous Lan- of sites onto cores allows one to benefit from multi- guage), which addresses the above issues in the fol- core architectures. Two properties are assumed by lowing way: DSL: reactivity of sites and absence of interferences between scripts run by distinct sites. We consider • We use the reactive variant [4] of the synchron- several variants of DSL. In the first variant, functions ous approach, which is able to express dynamic are defined in FunLoft. In the second variant of DSL, creation; basically, in this variant “causality cy- functions are defined in ReactiveML and the JoCaml cles” are eliminated “by construction”, by for- system is used for asynchronous inter-sites communi- bidding immediate reaction to absence. Several cations. The third variant is based on SugarCubes related proposals are based on this variant (e.g. which is a Java based framework for reactive pro- Reactive-C [9], SugarCubes [14], ReactiveML gramming. Finally, in the fourth variant, functions [17]). are defined in Scheme/Bigloo. • We introduce the notion of site, for combining synchronous and asynchronous aspects of sys- tem decompositions into a unique framework. 1 Introduction This combination is inspired by the FairThreads model [10] which mixes cooperative and pre- Synchronous programming [6] simplifies concurrency, emptive threads. Sites can be run by dedicated compared to standard approaches based on the ex- cores, thus giving a way to fully exploit multi- clusive use of the classic model of threads (pthreads core architectures. ∗with support from ANR-08-EMER-010, project PARTOUT DSL is designed with a simple formal semantics, describing without ambiguity how the system evolves. 1 Our approach is an alternative to the use of locks by events) and by listening to the music they play for memory protection in a classic threading context. (also modelled by events; imagine events correspond- We claim that our proposal makes both semantics and ing to sound waves produced by the instruments or programming easier. by the voices). The conductor must be able to do sev- eral things in parallel: she must direct and listen to all 1.1 Orchestration Model instruments at the same time. Of course, as needed by any orchestra, a common clock is defined by the The computing model we consider is the following: conductor; in our model, this clock which should be there are N sites, each of them being composed of shared by the whole orchestra is given by instants. two levels, the orchestration level and the host level. One can see the presence of several orchestras (sites) The sites are completely autonomous and are run playing asynchronously as what happens sometimes asynchronously (possibly on different processing re- in music festivals, when several stages are used inde- sources). pendently, possibly simultaneously (of course in this At the orchestration level, each site runs a script case, the absence of interferences between distinct which is fundamentally parallel. At that level, inputs stages is mandatory: nothing should be shared by are: distinct sites). • new scripts dropped by the other sites, by the external world, or by the host level of the site; 1.2 Variants of DSL these new scripts are put in parallel with the We consider several variants of DSL, depending on one currently executed by the site; events are the language (which we call the host language) in input as simple scripts generating them. which functions are expressed. • boolean values coming from the host level and • In the first variant, the host language is Fun- if used by instructions; Loft [11, 12]. The basic properties of reactiv- • integer values coming from the host level and ity and of absence of data-races are checked by used by repeat statement. the FunLoft compiler. In order to insure these properties, the use of functions is restricted (for The outputs of the orchestration level are: example functions cannot be stored in mem- ory). As FunLoft does not currently provide • new scripts sent to other sites; any means for code distribution, this feature is • calls of functions belonging to the host level of not presently available. the site. Functions are treated in an abstract • In the second variant of DSL, functions are de- way: we do not consider their effect on the fined in ReactiveML [17] which is an extension memory but only their “orchestration” i.e. the of ML to reactive programming. Higher-order organisation of their calls in time and in place functions can be defined without restriction in (the site where they are called). this variant of DSL. The JoCaml system [3] Scripts run by the same site synchronise by means is used for asynchronous inter-site communica- of local events which are broadcast in the whole site. tions. Moreover, the ReactiveML variant pro- Two properties are assumed in DSL: reactivity of vides users with the scripting top-level of Re- sites, and absence of interferences between sites (i.e. activeML. The ReactiveML variant does not sites do not share instants, nor memory, nor events). check the reactivity and interference freeness These two properties of sites allow them to be mapped properties which are thus left to the program- on distinct cores while preserving the semantics, and mer’s responsability. to therefore benefit from multicore architectures. • The third variant is based on SugarCubes [14] Sites bear an analogy with a musical orchestra: which is a Java based framework for reactive the orchestration level corresponds to the orchestra programming. Like with the ReactiveML vari- conductor who leads the host level corresponding to ant, the basic reactivity and data-race freeness the music players. The conductor follows a music properties are not checked. The SugarCubes partition (script) and communicates with the musi- variant allows one to use the object approach cians by sending them orders and signals (modelled of Java to program functions. Communication 2 between two sites is implemented with the RMI These functions have parameters of basic types only protocol of Java. (integer, boolean, string). Tasks are special functions whose execution is not • The fourth variant is based on Scheme/Bigloo immediate; actually, execution of a task does not [1]. It directly implements the semantic rules. start immediately, but at the next instant; moreover, In the current implementation, distribution as- the execution of a a task can last several instants or pects are not covered but we plan to address even never terminate. Tasks are called using a specific them using the Hop [2] system implemented in keyword (launch). Scripts “orchestrate” the execu- Scheme/Bigloo. tion of functions and tasks on the various sites that compose a program. 1.3 Implementations We first present scripts in 2.1, then introduce sites in 2.2 and events in 2.3. The basic properties of DSL At the implementation level, each variant of DSL has are presented in 2.4. Finally, an example which will its own particularities. The most interesting aspect be used to benchmark implementations is described of comparison is how the notion of instant in DSL is in 2.5. reflected in the various host languages. With ReactiveML and SugarCubes, instants of DSL and instants of the host language are in a di- 2.1 Scripts rect one-to-one correspondence. Actually, there is no Scripts are made of basic instructions whose informal need to introduce any supplementary mechanism to semantics is as follows: run DSL scripts, which are just directly translated in the host language to be executed. This is possi- • nothing does nothing ble because the expressivity of these host languages is comparable to that of DSL: actually, each DSL prim- • cooperate terminates the execution for the cur- itive (except drop) has a direct counterpart in them.