An Implementation for CRP Basant Rajan and R.K. Shyamasundar Computer Science Group Tata Institute of Fundamental Research Homi Bhabha Road, Bombay 400 005 e-mail:
[email protected]
1 Introduction Communicating Reactive Processes or CRP [1] is a relatively new programming paradigm that combines the capabilities of asynchronous and synchronous concurrent languages. This paper presents on going work related to the implementation of CRP on platforms running Unix System V. Asynchronous languages are well suited for loosely coupled distributed algorithms while synchronous languages like Esterel cater to the needs of tightly coupled, deterministic, reactive ones. Currently each language class on its own, falls short of the requirements the other satis es. While synchronous languages lack support for catering to asynchronous distributed algorithms, asynchronous languages do not help in implementing deterministic reactive algorithms. It is this void that CRP was designed to ll. CRP programs succeed in unifying both forms of concurrency. A CRP program is composed of of a number of independent, (locally) reactive Esterel [2] nodes which communicate with each other using CSP [3] style rendezvous. CRP extends both Esterel and CSP while adding possibilities like watchdog timers on rendezvous. CRP is built on Esterel extended to include a new asynchronous task execution primitive called exec. The Esterel nodes that compose a CRP program are linked by channels. A channel connects exactly two nodes and is directional. Only one rendezvous on the same channel can take place at any given instant though any number of rendezvous on the same channel may be in progress at any time. The rest of this paper is organized as follows. Section 2 introduces the exec primitive as an extension of standard Esterel and goes on to present the protocol underlying a CRP rendezvous. Section 3 describes modi cations to the rendezvous protocol when implemented using the exec primitive while section 4 discusses some implementation issues involved. The last section presents some observations and extensions.
2 Communicating Reactive Processes This section will assume familiarity with the synchronous programming language Esterel . While interfacing Esterel with routines written in a host language it was assumed that function calls could safely be treated as terminating instantaneously. This assumption however is not justi ed in the context of real-time systems where physical inertia cannot be ignored. The new exec primitive extends standard Esterel and permits interfacing of asynchronous tasks to an Esterel module. Asynchronous tasks and return signals are declared prior to usage as given below. In the case of the return statement, the syntax given is in its most general form.
task task-name(ref-args)(value-args):return-signal-type; return (sig-name):combine sig-type with function-name;
Instantiation of an asynchronous task is e ected by statements of the form given below. exec task-name(ref-args)(value-args):return signal-name; Associated to every exec statement, in addition to an explicit return signal if any, there implicitly exist three signals start.task-name, abort.task-name and return.task-name which are suitably tagged using labels to distinguish between signals associated to multiple instantiations of the same task. These functions are to be implemented in the host language in which the Esterel module is being implemented. An exec invocation can be thought of as follows. Synchronously with the execution of the `exec task-name;' statement the corresponding start.task-name is emitted. This signal is used by the environment as a cue to initiate the associated task. When the task terminates, the environment signals the event using the return.task-name signal. If at any time, at or before the completion of the asynchronous task, the Esterel module emits the abort.taskname signal, the environment is expected to abort the execution of the associated task. CRP essentially consists of a network of Esterel modules, each of which evolves locally with input/output signals and mutually independent notions of time. The network as a whole is an asynchronous entity, with its parts communicating synchronously over channels. To achieve this end, the exec primitive is extended to provide a communication primitive. We will now introduce a rendezvous primitive to Esterel and show that it captures the essence of CSP. CRP nodes are linked by channels which are declared as follows. input channel channel-name from module : data-type; output channel channel-name to module : data-type; These channels are used by the new primitive rendezvous whose syntax follows. rendezvous label:channel-name(value); . . . (send) rendezvous label:channel-name; . . . (receive) The rendezvous, being an extension of the exec primitive, also has three implicit signals associated with it. A rendezvous is initiated by emitting a start.rendezvous signal. An external asynchronous layer takes over the task of carrying out the speci ed rendezvous and returns return.rendezvous on successful completion. The Esterel module can, in the meantime emit the kill.rendezvous signal to abandon the rendezvous. Simultaneous emitting of kill.rendezvous and return.rendezvous would be taken to mean that rendezvous is complete but the local module is ignoring any data transferred. To illustrate how CRP captures the CSP style communication equivalent code sections from the two languages are given below. Other CSP constructs have more obvious translations into Esterel . In the following example, a derived version of the rendezvous statement as in the Esterel await-case statement has been used. Another aspect that needs mention is that the to model CSP like communication exclusion relations must be de ned on the return signals associated with incompatible channels while CRP only imposes the restriction that no more than one return signal associated to any given channel be present at any point in time. CSP code segment . . . [ channel-1?X ! stat1 []channel-2!exp ! stat2]
equivalent CRP code . . . rendezvous case label-1 : case label-2 : end
channel-1 do stat1 channel-2(expr) do stat2
3 Rendezvous using Exec This section discusses modi cations to the basic rendezvous mechanism required if rendezvous is implemented using the exec primitive. In this case, the rendezvous is split into two logical phases { a synchronization phase and a data transfer phase. The protocol also becomes asymmetric. As before, rendezvous is initiated by either one or both Esterel modules emitting an init.rendezvous signal. The asynchronous layer then carries on the communication. It emits the sync.rendezvous signal to both modules on receipt of two init.rendezvous signals. This ends the rst phase of the communication and synchronization is deemed to be complete at this stage. On receipt of the sync.rendezvous signal, the sender emits the ackn.rendezvous signal along with the data that is to be transferred. The asynchronous layer then issues a confirm.rendezvous signal (along with the data from the sender) to the receiver. The data is now acknowledged by the receiver with the ackn.rendezvous signal. The asynchronous layer then completes the rendezvous by issuing the confirm.rendezvous signal to the sender. The confirm.rendezvous signal is interpreted at either end to mean that data transfer is complete. Preemption is treated di erently too. A kill.rendezvous signal issued before a sync.rendezvous signal is taken to mean that the rendezvous (synchronization phase and data transfer phase) is being aborted. If either the sender or the receiver issues a kill.rendezvous. after a sync.rendezvous signal has been issued, it is taken to mean that the data transfer phase is being aborted. This is signaled to the other module by the asynchronous layer using an abort.rendezvous signal.
4 CRP Implementation This section discusses the implementation of CRP on a network of Sun workstations running SunOS5.3. The rendezvous is implemented internally using a three phase protocol as outlined below. The rendezvous can be thought of as involving three separate entities { two Esterel modules, the sender and receiver , and an asynchronous medium. The send and receive parts of rendezvous are symmetric except for the direction of data ow. The rendezvous is initiated with one or both of the Esterel modules emitting an init signal to the asynchronous layer. The asynchronous layer, on receipt of two init signals (one each from the sender and receiver ) emits a sync signal to both the sender and receiver. The receipt of a sync signal at either Esterel module is interpreted to mean that a communication is possible. Subsequent to the receipt of the sync signal the sender and receiver may respond with a ackn signal. This signal is interpreted by the asynchronous layer as a commit from the originating module. The asynchronous layer, on receipt of two ackn signals issues a confirm signal to both the sender and receiver . The confirm signal is interpreted to mean a successful completion of a rendezvous. The implementation of preemption on the above sequence is outlined next. Both sender and receiver are free to preempt a rendezvous by issuing a kill signal after the
init signal and strictly before the ackn signal have been issued. The kill signal is treated di erently during di erent phases of an ongoing rendezvous. Before the instant the sync signal is issued, the kill signal simply negates the e ect of the previous init signal. At any point after the sync signal is issued, the kill signal by either the sender or receiver causes the asynchronous layer to emit an abort signal to the receiver or sender respectively. The abort signal has the e ect of nullifying the previous sync signal issued by the asynchronous layer and any ackn signal subsequent to it. A kill signal generated after a ackn signal is
ignored by the asynchronous layer.
KILL,INIT
wait-1
{ABORT}
wait-2
AC
IN IT
KN
}
INIT,INIT
RM FI ON N K AC
{SYNC} start
{C
C} YN {S IT IN
KI LL
KILL
{CONFIRM} sync
ACKN,ACKN
end
Transition Diagram: Three Phase Protocol
Some details regarding the implementation of the protocol follow. Data transfer is handled by having the sender supply the data along with the ackn signal and the asynchronous layer passing it on to the sender along with the confirm signal. The CRP restriction of at most one rendezvous completion on a channel at any given instant is implemented by making the asynchronous layer serialize any simultaneous completions. The asynchronous layer is modelled by a collection of network CRP daemons, one on each node of the physical network. Communication is implemented using udp datagrams and the transport layer interface routines. udp was chosen over tcp because of the potentially large number of open connections that could result when multiple rendezvous are in progress. That decision implied that sequencing and retransmission of the datagrams had to be taken care of by the CRP daemons. The Esterel speci cation of each CRP node is parsed to extract network related information and communication constructs re-written to call prede ned C routines and later linked in with library routines that interface the nodes to the communication daemons on the local machine. To aid monitoring of the state of a rendezvous a CRP debugger with an X-window interface is also being developed. The debugger is capable of monitoring and supplanting either or both modules involved in a rendezvous.
5 Conclusion In unifying Esterel and CSP, CRP has provided the means to handle complex parallel systems, allowing the use of synchronous as well as asynchronous approaches as appropriate. An implementation of CRP is currently underway and is expected to be useful in implementing real-time applications in elds like robotics and process control. Since the semantic aspects of synchrony and asynchrony have been kept independent, other asynchronous communication policies (section 3) between synchronous nodes could be studied in the same way. Extensions of basic CRP are also being studied. It is hoped that CRP and its extensions will provide a platform to implement fairly complex parallel systems.
References [1] G. Berry, S. Ramesh, and R.K. Shyamasundar. Communicating Reactive Processes. ACM POPL, pages 85{99, Jan 93. [2] G. Berry and G. Gonthier. The Esterel Synchronous Programming Language: Design semantics, Implementation. SCP, 19(2):87{152, Nov 92. [3] C.A.R. Hoare. Communicating Sequential Processes. CACM, 21(8), Aug 78.
Appendix The Esterel language is described very brie y below. Only the kernel statements are described because the derived ones can be macro expanded into a set of kernel statements and as such are themselves not semantically meaningful. nothing { Terminates immediately when started and does nothing. halt { This statement never terminates and therefore retains control forever. emit S { Broadcasts S and terminates immediately making the emission of S transient. stat-1;stat-2 { Control transmission by the sequencing operator \;' takes no time in itself loop stat end { Starts stat when the loop starts and restarts stat instantaneously whenever stat terminates. Note that stat cannot be instantaneous. present S then stat-1 else stat-2 end { The presence of signal S in the current instant is tested and the then or else branch taken instantaneously. do stat watching S { stat is executed normally until termination or up to a future occurrence of the signal S. For normal termination of the watching construct stat must terminate strictly before the occurrence of S; otherwise stat along with all currently enabled transitions in stat are preempted by S. stat-1 k stat-2 { stat-1 and stat-2 are started instantaneously when the parallel construct is started and the statement terminates when both its branches terminate. The k operator takes no time in itself. trap T in stat end { stat runs normally until it executes an exit T statement, at which time the body is preempted. Unlike in the watching construct, concurrent components (i.e. currently enabled transitions) are allowed to complete their execution. exit T { Instantaneously causes an enclosing trap to be exited. signal S in stat end { Declares a lexically scoped signal S that can used for internal broadcast within stat.
