Re: [boost] [MSM] event deferral and dispatching with base event

Subject: Re: [boost] [MSM] event deferral and dispatching with base event
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2011-07-19 17:16:52

> I'm running the attached test program  it generates the following output :
>
> entering: Idle MS1_
> leaving: Idle
> Action: MS1::onEvent1
> entering: RunningStateMachine MS1_
> entering: RunningStateMachine::PseudoEntry1
> leaving: RunningStateMachine::PseudoEntry1
> entering: Inner1 RunningStateMachine_
> entering: InnerState11
> FwdGuard: returns:0, event: event5
> FwdGuard: returns:0, event: event1
> FwdGuard: returns:0, event: event1
> FwdGuard: returns:0, event: event5
> FwdGuard: returns:0, event: event1
> FwdGuard: returns:0, event: event1
> FwdGuard: returns:0, event: event5
> FwdGuard: returns:0, event: event1
> FwdGuard: returns:0, event: event1
> FwdGuard: returns:0, event: event5

Hi Richard,

unfortunately, I don't have good news. We are using non-standard, self-made 
UML features (base event, Defer functor) here so we're moving in uncharted 
territory.

> I believe it is incorrect after state machine entered state   InnerState11 
> .
> FwdGuard should have been called ones with event5 and than 3 times with 
> event1
> and event1 shall have triggered after the first dispatching a no 
> transaction.
> But this case no trans was triggers on even1 and and the deferred
> event5 got dispatched even there was no state change for every event1
> dispatching.
>

After thinking about it, I think I will disagree. What you could expect at 
first would be one call with event5, then with event1, then event5, then 
event1, then event5 etc.
Why? Because we have a transition conflict between the transition:
Row < Inner1          , baseEvent , none , ProcessBaseEvent , FwdGuard 
 >
and
Row < RunningStateMachine, event5 , none , Defer, none >

If you follow the other discussion on this list, there is talk about 
priority. The Standard says that the most inner transitions have higher 
priority, so when you want to process event5, the above transition gets 
tried first and rejects event5. So the transition did not fire. Again, as 
the Standard says, we continue until one fires. We then try the second one, 
which has no guard, so it fires and defers the event5.

Then comes event1, the above transition rejects, processing of event1 stops 
here. We try again the deferrd event5, and you see it again. And again it is 
deferred. And again and again.
So, what you COULD expect would be:
 FwdGuard: returns:0, event: event5
 FwdGuard: returns:0, event: event1
 FwdGuard: returns:0, event: event5
 FwdGuard: returns:0, event: event1

But there is a second factor here, a conflict between an event (event1) and 
its base state. I can only advise you to avoid this. I see this as the fsm 
equivalent of Meyer's tip "make base classes abstract".
In our case, we get rows added by msm in your SM1 transition table for 
events present in RunningStateMachine's table:
RunningStateMachine: event1 (comes from _row < PseudoEntry1    , event1    , 
Inner1  >)
RunningStateMachine: baseEvent (comes from Row < Inner1 , baseEvent , none , 
ProcessBaseEvent , FwdGuard  >)

This means event1 is in conflict with his base class. MSM tries both 
transitions, with event1 and baseEvent, as with any conflict. Interestingly, 
both map to the one from baseEvent, so it is called twice, which gives you 
what you see.

So, what should msm do?
Remove the transition with eventBase? No because base events would not work 
for submachines any more.
Remove the transition with event1 because eventBase is present? Also no, 
because you would only get the submachine called with baseEvent (would be 
slicing, again, see Meyer).

So, I need to think about it, but I really see no way to make this work :(

> this breaks our code execution completely  :(.

I understand it's bad. All I can suggest you is:
- do not create conflicts between an event and its base. I don't see how 
this could be a right design.
- if you don't want event5 to come haunt you forever, stick to the UML 
conform deferring inside a state unless you really know you will get no 
transition conflict.

Sorry, not to be able to help more.
Regards,

Christophe