Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of rafah4@gmail.com designates
 64.233.162.206 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=NWzKrzkjS05B0JduSm8dHOMb1Vrz5Pesm4Nqh6yxO1JbBWHpXI8RGsFdJfipPcnwtGB3oS/JtuoI/kxQfCQzezA7oeFqms5POVykBwdHcXgQTnWJnZNG1PkR6DWrR6aeWx2DjsIVNdKq2yiofDOmhcrnc6RZUgqa7CmjCbB8BNM=
Message-ID: <f4f207e70511210807g2bf5ecemd7e259000441c989@mail.gmail.com>
Date: Mon, 21 Nov 2005 11:07:32 -0500
From: rafah rafah <rafah4@gmail.com>
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [scxml] processing multiple events
In-Reply-To: <CDB88C76D4D72244973F442A5305F0F946E7A3@BOS1EXCH1.aspect.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_14817_25150341.1132589252171"
References: <CDB88C76D4D72244973F442A5305F0F946E7A3@BOS1EXCH1.aspect.com>

------=_Part_14817_25150341.1132589252171
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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 a=
s
event firing/step interpretation and transition trigger specifications).
This is why you are noticing these differences; for example Statemate allow=
s
for event parallelism i.e multiple events firing at the state machine at th=
e
same time, Rhapsody/SCXML/UML do not. Statemate has the notion of super-ste=
p
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 directio=
n
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 <James.Barnett@aspect.com> 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:rahul.akolkar@gmail.com]
> 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 <James.Barnett@aspect.com> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>

------=_Part_14817_25150341.1132589252171--