Boost Users :
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
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
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.
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net