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

Subject: Re: [boost] [MSM] event deferral and dispatching with base event
From: Richard Szabo (sz.richard_at_[hidden])
Date: 2011-07-21 17:11:28

On 19 July 2011 23:16, Christophe Henry
<christophe.j.henry_at_[hidden]> wrote:
>> 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.

Ok if I use UML like definition for the event deferral than at least
event 5 is not getting dispatched each time thanks for that.
And actually I can leave with the situation that even1 is dispatched 2
times it only happens when no trans is taken in sub state machine so
than it is not hurting.
What I find disturbing that in this case the No Trans in not getting
called ? Is it possible to fix at least this ?.

>
> Sorry, not to be able to help more.
No problem you are a great help to us !.

> Regards,
>
> Christophe
>
Cheers
Richard

> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>