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

Subject: Re: [boost] [msm] internal/external conflicting transitions
From: Michael Caisse (boost_at_[hidden])
Date: 2009-12-07 12:18:51

Christophe Henry wrote:
> Hi Michael,
>
> Looks like you are thoroughly testing MSM and I find it great :)
>   

I'm hoping to test it thoroughly. I'm an HFSM geek and
ROOM/UML implementations are part of my livelihood. I'm enjoying
getting to know your library.

>
>> 2. an internal and external transition are both enabled
>>
>> I see a clear definition for the behavior of #1 in the
>> discussion; however, it is not clear that #2 will follow
>> the same rule.
>>     

<snip>

>
> I was maybe unclear with "internal" so let's see if we can converge.
> With internal, I mean internal to a composite. Suppose we have a fsm
>   

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.

For our purposes... lets just talk about simple states.

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.

<snip>

> This is were I'm unsure if I follow you. SimpleTutorial has no
> composite, so no internal transition so we must be talking about
> different things.
>   

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

> I can, however, still answer about the order of evaluation.
> UML orders that conflicts be solved by guards which are mutually
> exclusive, so your machine is currently ill-formed (no guards) and UML
> says the behavior is undefined and I, as implementer, am allowed to
> punish you like I wish ;-)
>
>   

Indeed. I was trying to determine what the punishment was going to be  (o;
Specifically I was wanting to know the behavior when there was an
internal/external transition conflict. Though that was not what I had
implemented in my test (my mistake).

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.

> If you still want to know how it works, with pleasure (this is where
> normal users could stop reading ;-) ).
> First, for every event used inside a composite, MSM adds a forwarding
> row at the end of your table (at the end, so they have no influence on
> the state index calculation system).
> Then, for a given event, MSM iterates at compile-time through the STT,
> from back to front and replaces the conflicts by a new row containing
> all of the conflicts (this is were your compiler suffers). Thus,
> transitions internal to a composite are given higher priority in the
> evaluation.
> This also means that for "normal" conflicts, the last transition wins.
> I was already asked if I would change it. It is
> implementation-specific so you should not rely on it, but it is very
> unlikely that I will ever want to change it.
>
> I hope I brought enough elements to bring clarity. If not, please let me know.
>   

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.

michael

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