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

Subject: Re: [Boost-users] [MSM] stack overflow happens when there is a false-guard anonymous transition
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2010-09-07 15:10:10

<snip previous discussion>

> Thanks for getting me on the same page. I think completion events are
> peculiar only in the sense that their event is implicitly generated.
> Run-to-completion step semantics must still be obeyed as well as guards
> must be evaluated only once.

Yes, I agree on this. This is now the trunk state.

> If the completion event has been dispatched and it fails to take a
> transition I believe the state is now quiescent (for reasons articulated
> earlier).

I also see it that way after re-reading the standard.

> So... how do we exit? The *only* way to exit via the completion
> transition is for a completion event to be dispatched again. How can
> this happen? Via a self transition (or compound transition that returns)
> or via hierarchical search and a return to history.
>
>
>             -----------           -----------
>       ----->|          | [g]      |         |
>             |    S1    |--------->|    S2   |
>          -->| entry/F1 |          |         |
>          |  | exit/F2  |          |         |
>          |  |__________|          |_________|
>          |____|
>                E

You are probably right from a Standard perspective (IIUC) but it is
not a very elegant solution. Worse, those using completion events
often write a complete state machine this way, and this method will
almost double their number of transitions, which will cost much in
compile-time.

> I think executing process_completion is actually a violation of the
> model (UML). Completion events occur based on a well defined set of
> rules. Failure to take a completion transition because of a guard is by
> design or implementation (intentional or a flaw). A new event must be
> processed that results in a completion event to be dispatched for the
> evaluation to occur again. It also rubs me wrong because
> run-to-completion steps are always initiated via an event being
> dispatched. process_completion would produce a second "interface" for
> injecting behavior.
>
> My recommendation would be to stick with the standard. Typically the
> side affects of entry F1 or transition E will result in the evaluation
> of g to true. If simply calling process_completion again results in g
> becoming true it means significant state changes outside of the state
> machine (or in a parallel machine). In my opinion, this would be an
> indicator of a bad design. The one place where I do something similar is
> when "polling" real hardware; however, I use the above configuration and
> trigger E to evaluate g in a predictable manner.

As msm is used in embedded systems, there is plenty of hardware and it
seems a valid use case.
Anyway, thinking about it again today, I realized that we do not need
process_completion. I'm wondering how I could miss this.
As completion events are defined for msm as having the event "none",
the same effect can be achieved by simply calling:
fsm.process_event(none());

And now we are UML-conform. We have our completion semantics for the
first time the source state becomes active, and our standard event
semantics using "none" as event.
And this costs us no extra transition. Now this is a win-win scenario :)
So, process_completion is out :)

> As for the "wildcard" or any trigger, ROOM had this notion and I have
> used it extensively over the years. In 13.3.1 you will find
> AnyReceiveEvent. A transition trigger can be associated with this
> message event which would specify the transition should be triggered by
> receipt of any message. I don't think MSM encompasses the Communications
> Package models and this may be a stretch to get working.

BTW, MSM does not have the wildcard concept (yet) but is coming pretty
close using a base event.
If you define in your fsm an event called "any_event" and all your
other events inherit from any_event:
struct eventA : public any_event{};
struct eventB : public any_event{};

The following transition:
Row<State1, any_event, State2>

Will fire if you throw at it an any_event, an eventA or an eventB.
It's not perfect but it will help until I find a better solution.

Thanks for your very useful insights!

Regards,

Christophe