Team mimosa

Members
Overall Objectives
Scientific Foundations
Application Domains
Software
New Results
Contracts and Grants with Industry
Other Grants and Activities
Dissemination
Bibliography

Section: New Results

Reactive programming

Participants : Gérard Boudol, Frédéric Boussinot, Frédéric Dabrowski, Stéphane Epardaud.

The reactive model

In the note [25] we revisit the so-called reactive programming style, which evolves from the synchronous programming model of the Esterel language by weakening the assumption that the absence of an event can be detected instantaneously. We review some research directions that have been explored since the emergence of the reactive model ten years ago. We also outline some questions that remain to be investigated.

In [24] we revisit the SL synchronous programming model introduced by Boussinot and De Simone (IEEE, Trans. on Soft. Eng., 1996) . We discuss an alternative design of the model including thread spawning and recursive definitions and we explore some basic properties of the revised model: determinism, reactivity, CPS translation to a tail recursive form, computational expressivity, and a compositional notion of program equivalence.

Safe Concurrent Programming

We have made an experiment to add concurrency to the Cyclone programming language, in order to get a safe concurrent language. The basic model considered is that of FairThreads in which synchronous and asynchronous aspects are mixed. The language Loft implements the FairThreads model in C. The experiment basically uses Cyclone instead of C in the implementation of Loft. Using the multi-threaded version of Boehm's GC, one gets an extension of Cyclone to concurrency which is as safe as Cyclone for sequential code, with some additional safety verifications for concurrent code. Several static analyses should be added in order to get a completely safe language (for example, verification that atoms executed by linked threads indeed terminate). The difficulty to add these verifications in Cyclone leads us to leave aside this experiment and to explore a new way based on a novel language inspired from ML and considered in the section ``Cooperative Threads and Preemptive Computations''.

We propose [29] a small language for programming cooperative threads in which one can also define preemptive computations, to deal with tasks that are not well-suited to a cooperative treatment but are useful in practice (e.g. blocking I/Os). These preemptive computations are executed in preemptive mode (in parallel with the cooperative system). We have introduced a type and effect system which ensures that preemptive computations do not interfere with the normal behavior of cooperative threads. This system is used to associate to each thread a subset of the memory locations created by it, namely unsharable memory locations, which are not shared with other threads. During a preemptive computation a thread has access only to these memory locations. This eliminates data-races with the cooperative threads or with the other preemptive computations, thus preserving the atomicity of the execution provided by a cooperative model. An important consequence of this is that it allows the cooperative model to safely benefit from multi-processor architectures.

A first experimental implementation is under work. The compilation process consists in an type and effect inference algorithm, in several verifications (in particular, absence of instantaneous loops and termination of functions), and in a translation of FairThreads in C (via the Loft Language).

Reactive Programming: LURC

LURC, a lightweight reactive library based on ULM has been released this year. Originally a test project for studying new scheduling mechanisms in an optimized C library, it has grown into a full featured reactive multi-threading library with the addition of various thread implementations, all obeying a single semantics, a Reactive Event Loop and language-level features for reactive programming.

In LURC, there are four types of thread implementation, all scheduled similarly, but each with performance trade-offs at run-time. Two of them are purely cooperative and cannot become asynchronous: the first one minimises stack allocation with the cost of more memory copying when cooperating, the second one minimises cooperation time at the cost of bigger memory usage. The last two types can switch from cooperative/synchronous to asynchronous: one minimises cooperation type when synchronous by sharing its executing native thread with that of purely synchronous LURC threads, at the cost of asynchonisation time, while the second minimises asynchronisation time at the cost of native thread switching when cooperative.

In addition to mixing several models of threads, LURC uses a new reactive scheduling mechanism, based on spreading the long lasting computations of the end of instant phase during the instant. Each thread attempts to schedule itself for the next instant at a new phase called the end of action (when cooperating in most cases). This effectively reduces the time delay required by most reactive schedulers between each instant, while increasing the delay of cooperation between threads, thus bringing a comparable time cost when scheduling is done between two threads within the instant and across instants.

Although LURC is written in POSIX C as a user-level library, it can take advantage of the GCC compiler (the most widely distributed and used C compiler) when present and offer language-level primitives for most reactive primitives, via a complex use of GCC C language features and macros. This proves to be very portable and integrates the reactive primitives in a program as if they were C language primitives.


previous
next

Logo Inria