Re: [Boost-users] [MSM] stack overflow happens when there is afalse-guard anonymous transition

Subject: Re: [Boost-users] [MSM] stack overflow happens when there is afalse-guard anonymous transition
From: Michael Caisse (boost_at_[hidden])
Date: 2010-09-06 00:38:32

  On 9/5/2010 12:36 PM, Christophe Henry wrote:
> Hi,
>
> The problem is that UML does not specify how often an anonymous
> transition should be "tried" and I probably chose the wrong solution
> (to try again and again).
> So, as your guard always returns false, msm keeps trying, which means
> calls to process_event() until the stack overflows.
> The solution probably is to try just once but it will force you to
> manually try to reprocess by calling, say a process() function without
> event, but it arguably simply means passing the buck to you.
>
> Please let me think about it a bit more, I'd like to think this out a bit more.
> For the moment, I suggest you to either write a useful guard or revert
> to a named event, which you will process when it makes sense in your
> application.
>
> Regards,
>
> Christophe

Hi Christophe -

I hope you are well. You know how I like to dig into this stuff... so 
I'll give my thoughts. They are tainted by the the UML predecessor; 
however, I think there is good logic and possibly even a specification 
argument for my point of view.

UML 2.2 Superstructure section 15.3.14 [Transition] provides the 
associations for:

      trigger : Trigger[0..*]  -- I am assuming that no trigger is what 
you are referring to as
                                  an anonymous transition. I don't see 
that term used in current
                                  specifications anymore.

      guard: Constraint[0..1]  -- "A guard is a constraint that provides 
a fine-grained control
                                  over the firing of the transition. The 
guard is evaluated
                                  when an event occurrence is dispatched 
by the state machine.
                                  If the guard is true at that time, the 
transition may be
                                  enabled; otherwise, it is disabled. 
Guards should be
                                  pure expressions without side effects. 
Guard expressions
                                  with side effects are ill formed."

I would argue that the definition of the guard constraint requires that 
the transition is evaluated when an event is dispatched and is only 
evaluated once for that event. Because the transition is disabled if the 
guard evaluates false, then the transition cannot be evaluated again 
until another event is dispatched.

I would also argue that the system is considered stable once evaluation 
of an event begins. Guards are not allowed to cause side effects; 
therefore, the 'state' of the system when evaluation begins should be 
the same as when evaluation has completed if no transition is taken.

Personally, the least surprising thing (imnsho) would be that:

    1. event is dispatched
    2. internal transitions are evaluated for current state
    3. external transitions are evaluated for current state
    4. hierarchy is followed up and 2/3 repeated
    5. if top is reached without satisfying event ... an error has 
occurred and is acted upon as normal

I do not think whether a trigger is defined or not for a transition will 
affect this behavior. Transitions without a trigger are simply 
candidates for any event. The steps outlined above are those used for 
transitions with triggers, no?

Take care -
michael

-- 
----------------------------------
Michael Caisse
Object Modeling Designs
www.objectmodelingdesigns.com