On Wed, Feb 17, 2016 at 5:46 PM, Vicente J. Botet Escriba < vicente.botet@wanadoo.fr> 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@n4.nabble.com> 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