On 26.01.2015 23:10, christophe.j.henry@gmail.com wrote:
Actually your example is probably wrong (it's my worst design decision) because the fsm parameter in an action of a submachine itself is the submachine, not the outer. But yes, if you have a pseudo exit then you will call the outer from the sub fsm.
That's my case. Another thread triggers the sub-fsm to move the exit state.
I unsure of what your problem is, you could have your mutex in the outer and it would work. The sub fsm would lock the whole fsm, then call process_event, which runs to completion, done.
Unfortunately, there is no "a natural way" for subs to have access to the root... Now I use implementation that recursively goes through the states, but still it is ugly and has restrictions.
Normally, MSM is not thread-safe if that's what you mean...
Clearly, locking such a long time is still undesirable, which is why I went lockfree. Your actions run at the same time as the active state switching. It's really fast, but quite hard to debug and understand. For example, I am quite sure my implementation works for simple fsms, for internal transitions, for orthogonal regions, soon for deferred events and event queue, but my test for submachines does not and I still did not figure out if the code or the test is wrong...
If you want to try it out, I'm interested in your experience.
I'll take a look to msm3 Do you have a roadmap for v3?
Otherwise, it's all I have at the moment, I had no time to push it further yet. My priority at the moment goes to finishing the upcoming asynchronous, which solves this problem nicely (we use it at work for quite some time now) by taking care of enqueing calls between threads. I run my fsms in a single thread, avoiding concurrency on the state machine.
What is "asynchronous"? Looking through recent subjects does reveal nothing. I wanna ask another thing. As I see currently sub-fsms work as unconditional jump when returning. Consider I have a fsm "Foo" with a generic code that isolated to a sub-fsm "Bar" At the transition form Bar's exit point to Foo I don't know about the original state that calls Bar So, if Bar uses more the one time, I have to invent extra conditional/flags etc to make a decision what state to move. Foo's transition table: // Start Event Next Action, Guard // +--------+---------+--------+---------+--------+ Row < State1, evt1, Bar, none, none >, Row < State2, evt2, Bar, none, none >, // +--------+---------+--------+---------+--------+ Row < Bar::Exit, none, State1, none, ??? >, Row < Bar::Exit, none, State2, none, ??? > // +--------+---------+--------+---------+--------+ It would be nice, if the sub-fsm remembers the source state from the outer that causes call. That state can be used in guard.