Re: [boost] [msm] internal/external conflicting transitions

Subject: Re: [boost] [msm] internal/external conflicting transitions
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2009-12-07 12:50:07

Hi Michael,

>I'm hoping to test it thoroughly. I'm an HFSM geek and
>ROOM/UML implementations are part of my livelihood.

Great! Welcome to the club (though you probably were there before me).

>Ok. So I think this is part of the issue. As you know, UML defines three
>types of states: simple, composite and submachines. It appears that
>MSM implements simple and maybe submachines. I'm still unclear on
>what MSM exactly has and will write another email on the subject after
>I have sorted it all out.

MSM supports all but implements submachines and composite as one
concept because I consider the difference isn't worth bringing 2
words.

>Transitions can be either internal or external. Even for simple states.
>An internal transition in a simple state will never execute exit or
>entry code.

I didn't find this in the standard, but I might have missed it out.
Whatever, after a lengthy discussion with Juraj Ivancic, I came to the
conclusion that MSM needed what we called an "execution row", which is
pretty much your internal transitions for simple states.

>And this is where I was unclear. A better question would be: For
>a simple state, how do I create an internal transition?

For the moment, you can't easily. The only way would be to specialize
on_entry and on_exit on some events, but this is less than perfect, so
this feature is quite at the top of my list.

>This also disturbs me a bit... though it isn't your problem. Bran Selic
>for some reason changed this behavior in UML. It used to be much more
>well defined. Internal transitions were always evaluated before external
>transitions.

I don't know about that change, but I know that this depth-first
strategy has some critics (which I failed to understand).
Whatever, after the new type of row for simple states is added, you'll
be able to define it wherever you want in the transition table and can
therefore decide yourself of the priority. You will not however be
able to do it for rows coming from composites because MSM will handle
it alone, otherwise it'd break the exit points.
I think it is a reasonable solution.

>Perfect! This is what I wanted to know. I think it would be helpful
>to describe the run-to-completion semantics (including the ordering)
>in the documentation as well as a summary of rules for conflict
>resolution. I do like the "last transition wins" rule you have
>created. I also understand defining it as undefined (implementation-specific)
>behavior.

This has already been requested and will be done, along with a
complete description of the dispatch algorithm.

Christophe