Re: [boost] [MSM] Is there any interest in C++14 Boost.MSM-eUML like library which compiles up to 60x quicker whilst being a slightly faster too?

Subject: Re: [boost] [MSM] Is there any interest in C++14 Boost.MSM-eUML like library which compiles up to 60x quicker whilst being a slightly faster too?
From: Krzysztof Jusiak (krzysztof_at_[hidden])
Date: 2016-02-18 12:40:42

On Wed, Feb 17, 2016 at 5:46 PM, Vicente J. Botet Escriba <
vicente.botet_at_[hidden]> wrote:

> Le 17/02/2016 16:20, Kris a écrit :
>
>> On Tue, Feb 16, 2016 at 9:50 PM, Vicente Botet [via Boost] <
>> ml-node+s2283326n4683550h69_at_[hidden]> wrote:
>>
>> Le 16/02/2016 17:44, Krzysztof Jusiak a écrit :
>>>
>>> I would assume following order according to the spec + a bit of
>>> rationality?
>>>
>>>> 1. guard [to enable transition]
>>>> 2. exit src state
>>>> 3. actions...
>>>> 4. CHANGE THE STATE TO DST HERE?
>>>> 5. entry dst state
>>>>
>>>> I agree. It was evident to me, but I can not point to any wording.
>>>
>>> Great to hear that. However, above sequence makes exception handling a
>> bit
>> harder as
>> with guards we haven't left the src state but with actions we started the
>> exit already.
>>
>> 1. When exception happens in a guard
>> * src state is unchanged
>>
>> 2. When exception happens in an action
>> * src state is exited
>>
>> Moreover, following below sequence
>>
>> 3. actions...
>> 4. CHANGE THE STATE TO DST HERE?
>>
>> makes it harder to process internal events
>>
>>      "src"_s + event / process_event(other_event) = "dst"_s
>>    , "src"_s + other_event = X // most likely, should be this one as we
>> haven't changed the state yet?
>>    , "dst"_s + other_event = X
>>
>> and, therefore, maybe it's better to have it the other way around?
>>
>> 3. CHANGE THE STATE TO DST HERE?
>> 4. actions...
>>
>
> I have never used process_event in an action on the same state machine
> (You are re-entering the state machine :( ). The single think you can do is
> to post it (push in a queue) or call process_event in another state
> machine. However you must ensure the there are no cycles. The asynchronous
> way avoids always the possible cycles.
>

It's a great point! To be honest with you, I have never liked process_event
on the transition table, however, I blindly followed MSM approach (fsm is
always passed to guards/actions in MSM, so you can do whatever) but it's a
bit dangerous here, as you mentioned. I'm going to change that to support
only defer or queue events on the transition table. Thanks for your input
on that, makes complete sense.

>
> In some projects I have defined a hierarchy of state machines and the
> upper layer state machines use synchronous communication to communicate to
> lower state machines and the reverse, lower layer use always asynchronous
> communication with upper layer state machines (half sync/half async).

> There are 3 features that I'm missing in UML state machines that I found
> in SDL [1]. Maybe these features have no sense with synchronous state
> machines.
>
> * Procedures that can contain states. The difference with nested states is
> that procedures are stack based and return to the point of call when the
> procedure terminates. You can reuse a procedure inside a state machine
> several times of course.
> * Synchronous Remote Procedures that allows to do a call/replay at once.
> This avoids the use of wait states on which the every other event tan the
> replay is deferred.
> * Synchronous Remote Variables that allows to read a remote variable.The
> same here; but just to query for the value of a remote variable.
>
> Thanks for the links. I have never seen SDL before, it looks really
interesting. A lot of new concepts for me. I know that, Christophe (author
of MSM) was working on asynchronous library and integration it with MSM,
however, I'm not sure about the status. Anyway, it's a good learning to
follow. Cheers for that. Definitely a lot of stuff to implement in the
future!

> Vicente
>
> [1]
> https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=5&cad=rja&uact=8&ved=0ahUKEwi1vqWwqP_KAhUGWhoKHa-DB3oQFghEMAQ&url=http%3A%2F%2Fwww.itu.int%2FITU-T%2Fstudygroups%2Fcom10%2Flanguages%2FZ.100_1199.pdf&usg=AFQjCNFwOMg8j5RuW77nxtjPuj3c8eq2mQ&sig2=svSxdC5kgb1EBGDbnchYwg
> [2] https://fr.wikipedia.org/wiki/Specification_and_Description_Language
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>