Rahul, 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 [mailto:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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. > <snip/> 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 "foo.bar ten.done bar.foo" 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 SCXMLExecutor.java. 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: <snap/> 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'. <snip/> 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. Ofcourse: 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. > <snap/> 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. > <snip/> 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]. -Rahul [1] http://svn.apache.org/repos/asf/jakarta/commons/sandbox/scxml/trunk/src/ test/java/org/apache/commons/scxml/transitions-01.xml [2] http://jakarta.apache.org/commons/sandbox/scxml/building.html --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
