Re: [Boost-users] [msm] multi thread access

Subject: Re: [Boost-users] [msm] multi thread access
From: Sam Fisher (infest21h_at_[hidden])
Date: 2015-02-03 05:32:14

On 26.01.2015 23:10, christophe.j.henry_at_[hidden] 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.