Hello Jim Actually the current SCXML implementation follows, to a large extent, the Harel Statemate semantics, as provided in Harel's book (in contrast to UML 1.5, UML 2.0, and Rhapsody which all diverge in one way or another as far as event firing/step interpretation and transition trigger specifications). This is why you are noticing these differences; for example Statemate allows for event parallelism i.e multiple events firing at the state machine at the same time, Rhapsody/SCXML/UML do not. Statemate has the notion of super-step while Rhapsody has the notion of micro-step, etc. This implementation started a bit ahead of the SCXML specification and thus Statemate was the reference. However we do realize our divergence and the need to re-align the current implementation with the current SCXML direction as far as step interpretation. This will become more important when sync/join are supported. I am glad you are taking a stab at this.
-- Rafah On 11/21/05, Barnett, James <[EMAIL PROTECTED]> wrote: > > 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] > >
