Re: [Boost-users] [StateChart] event processing order in asyncmachine

Subject: Re: [Boost-users] [StateChart] event processing order in asyncmachine
From: Andreas Huber (ahd6974-spamboostorgtrap_at_[hidden])
Date: 2010-10-24 05:13:41

Hi Igor

Sorry for the delay.

> Right. To be more exact, it's because in (2) "all deferred events for
> that state" are *enqueued* into the general event queue, i.e. pushed
> in fifo manner. Although, intuitively I'd say that these deferred
> events have "higher priority" than those in the queue, because they
> were posted earlier for sure. So this is exactly the question: wasn't
> it more appropriate to push them to front of the "queue" (well, not
> real queue then)?

I don't know whether that will be more in the spirit of the UML standard. I 
quote from UML Superstructure Specification, v2.3, page 569 
<http://www.omg.org/spec/UML/2.3/Superstructure/PDF/>:

<quote>
Deferred events

A state may specify a set of event types that may be deferred in that state. 
An event that does not trigger any transitions
in the current state, will not be dispatched if its type matches one of the 
types in the deferred event set of that state.
Instead, it remains in the event pool while another non-deferred event is 
dispatched instead. This situation persists until a
state is reached where either the event is no longer deferred or where the 
event triggers a transition.
</quote>

So the standard says that deferred events should stay in the queue until 
they are no longer deferred. I think it is clear that my implementation 
fails to satisfy the standard under the circumstances you pointed out. While 
your suggestion (to move the deferred events to the front of the general 
queue) would probably work in your case, it seems it will not satisfy the 
standard when both outer and inner states defer events.

Problem is, I currently don't see how the standard can be implemented in an 
*efficient* manner with the current interface. I'll put some more thought 
into this. In the mean time, I'd suggest to use the workaround I outlined in 
my previous post.

I'll post again in this thread when I have a workable solution. Of course, 
if you have a suggestion how the implementation can be fixed, I'd be very 
happy to hear it.

Regards,

-- 
Andreas Huber
When replying by private email, please remove the words spam and trap
from the address shown in the header.