Subject: Re: [boost] [msm]exit pseudo state and event
From: Takatoshi Kondo (kondo_at_[hidden])
Date: 2011-07-29 04:51:50
Hi,
Maybe I solved the problem.
And of course it keeps your policy.
On Wed, 20 Jul 2011 23:01:53 +0200
"Christophe Henry" <christophe.j.henry_at_[hidden]> wrote:
<...snip...>
> > And UML standard said that internal transitions are not relate to
> > priority.
> > There are no guaranty that internal transitions are evaluated faster than
> > another (non internal) transitions if they have same start state.
> >
> > Consider fig1.png.
> > Thease two transitions have same priority.
> > At least in UML specification, we don't have a guaranty that
> > which transition would be handled.
> > But one of them would be handled.
>
> True, the Standard is vague about this, which caused me some headaches ;-)
> My decision on this matter is discussable, so please allow me to explain.
> After thinking hard about it, I came to the conclusion that this was just
> another variation of the Liskov substitution principle (I do use other
> sources than the Standard ;-) ).
> In your fig2, State1 is a submachine. Then its internal transitions have a
> higher priority, right?
> Now imagine I redesign it and make it a simple state (your fig1). Then if I
> follow your interpretation, the priority will change, thus breaking the
> implicit contract I had with the state machine which State1 was and my
> behaviour would silently change.
> This would lead to subtle bugs. In this spirit of this principle, I decided
> the only logical solution was to treat internal transitions as "more
> internal" and having a higher priority.
> Of course I also edged my bets and allowed the variation with
> transition_table ;-)
>
> > If we want to give the internal transition higher priority,
> > we should write the statemachine like fig2.png.
> > In the case of fig2, only the internal transition would be handled.
> >
> > Do you agree?
>
> No for the reasons I wrote above, but I can't prove you wrong.
>
> > But we can control the evaluating order using the Row's sequence.
> > (I think it is out of UML standard.)
>
> It is, but we won't care too much, right? :)
>
> > e.g.
> >
> > // Start Event Next Action Guard
> > Row < Empty , cd_detected , none , none , internal_guard >,
> > Row < Empty , cd_detected , State1 , none , another_guard >,
> > or
> > // Start Event Next Action Guard
> > Row < Empty , cd_detected , State1 , none , another_guard >,
> > Row < Empty , cd_detected , none , none , internal_guard >,
> >
> > I'd like to know why internal_transition_table is needed.
> > I think transition_table is enough.
>
> See above. Yes it's not needed but I find it pretty useful in everyday's
> life. This is of course a matter of taste.
>
> >> If you're at implementing stuff for msm, I might consider another
> >> solution:
> >> - a typedef in the front-end, which will change the reading order of the
> >> table, no to break other's code
> >
> > Thanks for good suggestion.
> > I'd like to consider a little more:)
>
> Sure :)
I introduced new typedef to statemachine class in front-end.
See 14_GuardEvalOrder.cpp. (Attached file)
class Sm1_ and class State1_ have this new typedef named evaluation_forward.
(Line 72 and 171)
It's a modifier of evaluation order.
If and only if evaluation_forward is defined,
the transition table's evaluation order becomes from top to bottom.
For your convenience, I prepared two patches. One is for trunk, and the other
is for version1.47.0.
Before applying patch or evaluation_forward is not defined,
the output is below.
-----------------
> Send Event1
Guard1_1_i_2
Guard1_1_i_1
Guard1_4
Guard1_3
Guard1_2
Guard1_1
Guard1_i_1
Guard1_i_2
Guard1
Guard2
Guard3
Guard4
0
-----------------
After applyng patch and evaluation_forward is defined,
the output is below.
-----------------
> Send Event1
Guard1_1_i_1
Guard1_1_i_2
Guard1_1
Guard1_2
Guard1_3
Guard1_4
Guard1_i_1
Guard1_i_2
Guard1
Guard2
Guard3
Guard4
0
-----------------
Of course, state id numbering policy is not changed.
Christophe, after your vacation, could you check it?
Regards,
Takatoshi