Une version en français est également disponible
Reactive systems are computer systems that react continuously to their environment, at a speed determined by the latter. Synchronous languages have been designed to facilitate the programming of reactive systems. The main synchronous languages are Esterel, Lustre, Argos, and Signal.
Many reactive systems have to be distributed on several computing sites, for various reasons: performance increase, location of sensors and actuators, fault tolerance. The ocrep tool parallelizes synchronous programs, according to distribution specifications given by the user.
Ocrep is based on the object code parallelization method. It consists in compiling the source program into a single object program, and then parallelizing this centralized program towards as many programs as there are computing sites, so that each site only has to perform its own computations. Therefore, ocrep takes advantage of the existing common format OC for synchronous languages. Indeed, OC code can be obtained from Lustre, Esterel and Argos compilers. Without going into details, an OC program is a finite state automaton with a finite memory for the computations. Ocrep takes as input:
foo.oc, andfoo.rep.The distribution specifications consist in a partition of the set of inputs and outputs of the program into as many sub-sets as there are computing sites. This assigns a unique computing site to each input/output. Finer specifications can be given by also assigning a computing site to local variables. Concretely, the distribution specification file contains a table of sites, with the same overall syntax as the other OC tables:
site_part : /* empty */
| 'sites:' number_of_sites site_table 'end:'
;
number_of_sites : integer
;
site_table : site_table site_definition
;
site_definition : site_num ':' identifier '(' signal_list ')'
| site_num ':' identifier '(' signal_list ')' '(' variable_list ')'
;
site_num : integer
;
Here, signal_list is a list of names of
input and output signals of the OC program. More distribution
specifications can be given by adding to a site definition an optional
variable_list of variable indexes. However, since
OC is an internal format, it is uneasy to relate OC
variables to the source program. Also, there should be no conflicts
between the signal_list and the
variable_list. In particular, it is forbidden to assign
an input signal to a site and assign the linked variable to another
site. In case of conflict, an error will be raised and ocrep
will stop.
A few words on local and
exception signals. They come from Esterel programs and
are used to express special synchronization constraints:
synchronization between parallel modules, trap-exit, and
so on. However, in the OC code, all these synchronization
constraints are directly expressed by the control structure of the
automaton: local and exception signals are
translated into state transitions by the Esterel compiler. A
consequence is that there should be no output or
present actions involving local or
exception signals. This is why ocrep arbitrary
decides to localize any local or exception
signal to site 0. Note that these signals have no name, so a site's
signal_list cannot contain local or
exception signals.
The communications take place through a fully-connected network of FIFO channels. Two communication primitives are used:
put(s,x) instruction writes the value x
to the queue directed towards process s; it is non
blocking;x:=get(s) instruction extracts the head value
from the queue originating from process s and assigns it
to the variable x; it blocks if the queue is empty.Ocrep produces one OC program for each site specified in the distribution specification file. Each OC program contains the necessary communication actions to permit references to non local variables. For instance, the command:
ocrep foo.oc
produces two files foo.2.0.oc and
foo.2.1.oc if the file foo.rep specifies a
distribution towards two sites. Each file produced by ocrep can
then be compiled, for instance, by the Esterel compiler.
The following options are available:
| -h | Print the help message. | ||
| -version | Display the version number of ocrep. | ||
| -info | Display all informations about ocrep. | ||
| -sb | Synchronize the OC programs weakly (only those who already communicate). | ||
| -st | Synchronize the OC programs weakly (all of them). | ||
| -e | Locally eliminate the redundant
puts. | ||
| -E | Globally eliminate the redundant
puts. | ||
| -a | Insert the puts as soon as
possible. | ||
| -r | Reduce the branchings for which both branches have equivalent behaviors. |
The ocrep tool is available for Unix architectures:
This distribution of ocrep contains four directories:
bin contains the executable
ocrep.man contains the user manual.src contains the C files
distinet.c and trace.h:distinet.c file contains the procedures for
creating the execution environment for distributed OC
programs (procedures for establishing the FIFO queues, as well as
the put and get procedures for exchanging data through these
queues);trace.h file is used by distinet.c
for tracing the connections.demo contains three demos:
Filter, Lightbulb, and
Twocopies.The poc tool that pretty-prints OC programs is available here.
Enjoy!
This work has been partially supported by the Merlin-Gerin company (now part of the Schneider Electric group), by Inria, and by UC Berkeley.
