Re: SDL-News: SDL Transition atomic or not ?

Subject: Re: SDL-News: SDL Transition atomic or not ?
From: Rick Reed TSE (
Date: Wed Mar 31 2010 - 09:50:45 GMT

Become an SDL Forum Society member <>
The originator of this message is responsible for its content.
-----From Rick Reed TSE <> to sdlnews -----

Dear Simon,

The simple answer is "yes".

The more detailed answer is as follows:
From Rec. Z.100 11.12.1
"A transition in one process of a block can be interpreted at the same time
as a transition in another process of the same block (provided they are not
both enclosed by a process) or of another block. Transitions of processes
contained in a process are interpreted interleaving, that is, only one
contained process interprets a transition at a time until it reaches a
nextstate (run-to-completion). A valid model of the interpretation of an SDL
system is a complete interleaving of different processes at the level of all
actions that cannot be transformed (by the rules given in the Model sections
of this Recommendation) into other actions, and are not excluded because
they are in a transition alternating with a transition that is being
interpreted (see 9.3)."

From Rec. Z.100 9.3 - special case of enclosed process instances:
"An instance of a process with contained process instance sets is
interpreted by interpreting the instances in the contained process instance
sets alternating with each other and with the state machine of the
containing process instance, if any. Alternating interpretation implies that
only one of the instances inside the alternating context can interpret a
transition at a time, and also that once interpretation of a transition of
an involved process instance has started, it continues until a (explicit or
implicit) state is reached or the process instance terminates. The state can
be an implicit state introduced by transformations (for example, due to a
remote procedure call)."

So (except from transitions in enclosed process instances) other process
instances are allowed to interpret a transition at the same time as the
process instance and can interpret an output of a signal to the process

Rec. Z.100 does not state anywhere that it is not allowed to add a signal to
a the input port of a process instance while it is in a transition. Though
Rec. Z.100 does not seem to state anywhere (at least I could not find it)
that this is allowed, signals can be placed in the input port whether the
process in in a state or in a transition. Maybe this SHOULD be written in
the standard explicitly.

It is not obvious that it would make an difference if placing the signals
instances in the input port only when the process instance entered a state.
One assumes that in this case the signal instances would still be placed in
the input port in the order that they arrived, and as the input port is only
examined while in a state the result would be the same. However, for a
process instance that outputs a signal on a non-delaying communication path,
this would imply the sender has to wait until the receiver reaches a state
before continuing, which is not the case.

With respect to scheduling of process instances, the basic idea is that each
process instance can (potentially) run concurrently as if each process
instance has its own processor, except for process instances contained
within an instance of a process (see above).

On 29/3/10 16:54, "Simon Bouland" <> wrote:

> Hello all,
> Could you help me about a semantic detail.
> Is transition execution atomic, or is it possible for a signal to be queued in
> the input port, during a transition ?
> The following code illustrates my question :
> PROCESS p1(0,1);
> STATE s;
> /* Transition t1 */
> INPUT in1;
> OUTPUT out1;
> OUTPUT out2;
> /* Transition t2 */
> INPUT in2;
> OUTPUT out3;
> During execution of t1, is it possible for another process to send in2 into
> the
> input queue of p1 between the emission of out1 and out2.
> Regards,
> Simon Bouland
> INRIA expert Engineer

Rick Reed -
Tel:+44 15394 88462 Mob.:+44 7970 50 96 50
Skype: rickreed_windermere (by arrangement)

--End text from Rick Reed TSE <> to sdlnews --- For extra SDL Forum Society benefits join at <>.

This archive was generated by hypermail 2a23 : Thu May 09 2013 - 16:05:50 GMT