commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Barnett, James" <>
Subject RE: [scxml] processing multiple events
Date Mon, 21 Nov 2005 14:35:38 GMT
  SCXML's semantics are based on the formulation in UML, which is much
simpler than some of Harel's formulations.  In particular, SCXML
maintains a single event queue into which all events are inserted.  This
implies two things:
1.  There is no super step since internal events are inserted into the
same queue as external ones.  Super steps involve blocking/holding
external events while internal ones are processed, but the single queue
does not distinguish between them.
2.  The queue implies a total order on events, namely the order in which
they were inserted into the queue.  So there cannot be a set of events
that are processed at the same time since they are pulled off the queue
one at a time.

It sounds like the existing code implements Harel State Charts, but not
SCXML (to the extent that it differs from HST.)  I think I'll start
working on a single queue version to see what it would look like.  I'll
report back on what I end up with but I won't check it in.  

- Jim

-----Original Message-----
From: Rahul Akolkar [] 
Sent: Friday, November 18, 2005 1:52 PM
To: Jakarta Commons Developers List
Subject: Re: [scxml] processing multiple events

On 11/18/05, Barnett, James <> wrote:
> I'm puzzled by the behavior of the scxml engine when I enter multiple
events (separated by spaces) at one time.  For example, when running the
Standalone version with test script transitions-01.xml, and in state
'ten', I would expect to be able to enter events 'ten.done
twenty_one.done twenty_two.done' and have the machine process all of
them and go to state 'thirty'.  However, the system only takes the first
transition, to state twenty/twenty_one.

Jim - Thanks for asking.

The space separated list is the list of events received between the
last trigger and the current one (this is the asynchronous time model
for state charts, where the engine reacts whenever an external event
is received -- as against the synchronous model where one step is
executed per unit time/clock tick). In fact, this does not imply any
temporal associations between the events being fired based on the
sequence in which they appear in the space separated list. Moreover,
all the events in the space separated list operate over the set of
candidate transitions that result from the ancestor closure of the
states that were active when the trigger was received i.e. all events
in a space separated list operate over the *same* ancestor closure.

The correct way to imply the temporal sequence that you refer to for
this SCXML example [1], therefore, is to fire events separately as
"ten.done", "twenty_one.done" and "twenty_two.done", in that order,
rather than a space separated list.

Note this does not mean the engine disregards multiple events when
fired at a time. You can verify that multiple events are accounted for
by specifying this list " ten.done" when in state
"ten", and observing that the appropriate transition for event
"ten.done" is indeed followed. A better example might be the trigger
"thirty_one_child_one.done thirty_two_child_one.done
thirty_three_child_one.done" right after entering the parallel and
noting that *each* of the orthogonal states follow their transitions.

> Looking at the code, I think that there is a  problem in triggerEvents
in  The method consists of a do loop, with each
iteration through the loop processing a single event.  However at the
bottom of the loop, we have:

Each iteration is not processing one event, rather all events in that
trigger. Note that the constructor for Step takes the entire list of
events, not just the first one.

>            if (superStep) {
>               evs.clear();
>            }
>        } while(superStep && currentStatus.getEvents().size() > 0);
> so if 'superStep' is true, the event list is cleared (via
'evs.clear').  However, if 'superStep' is false, the 'while' condition
will cause the loop to exit after the first iteration.  So multiple
events will never get processed.  I find that if I comment out both
conditions mentioning superStep, the multiple events do get processed
and the system transitions to state 'thirty'.

The superStep concept, and that bit of code, is orthogonal to the
space separated event list question you ask above. That bit of code
merely ensures that if the external triggers have caused any internal
events fired by the SCXML engine to be enqueued for processing, the
external trigger list be cleared so the external triggers are not
considered to have been "fired" once again when the engine takes a
stab at processing the internal events.

a) One only needs to continue iterating if the engine is processing
triggers as a superstep, and
b) One needs to continue iterating until the state machine reaches a
"stable" configuration, whereby all internal events have been
processed and the event queue has been exhausted.

> These complications may arise from the semantics of superStep and its
interaction with the Standalone environment.  The simplest change would
be to change the upper condition to 'if (! superStep)...', but I would
think that in that case the events should not be thrown away, but rather
left in the queue for further processing.

Indeed, if events were "thrown away" that'd lead to extremely
undesirable behavior. But, as pointed above, that is not the case.

> Or am I completely off base?
> - Jim
> P.S. I have been able to compile the code, thanks to the previous
pointers to the commons-build area.  Many thanks.

Thanks for the nudge :-) In addition, if you update your local SCXML
root from the Commons Sandbox repository, you won't need commons-build
anymore. I committed the related changes yesterday, and I also created
a "Building Commons SCXML" page [2].



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message