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: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2016-02-17 12:46:19

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.

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.

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