AMDG Andrey Semashev <andysem <at> mail.ru> writes:
But it is volatile as it's being passed to the init_states_info function which does the initialization. It's argument type is volatile.
My mistake
line 912 template< typename EventT > static state_dispatcher< EventT > const& get_state_dispatcher() { static const state_dispatcher< EventT > dispatcher; return dispatcher; } function static is not thread safe.
It doesn't need to be. The state_machine class is intended to be used in single-thread context. Once you have to access the machine from multiple threads you should use locking_state_machine which synchronizes on "process" function calls which is the only way "get_state_dispatcher" gets called.
Unfortunately, it isn't that simple. The dispatcher is shared by all state machines of the same type. Therefore even apparently unrelated machines can attempt to initialize it concurrently.
locking_state_machine.hpp dynamic_locker is unnecessary you can use scoped_lock this_lock(false); and this_lock.lock(); to do the same thing.
Actually, I can't - the lightweight mutex doesn't have this. The only thing the Boost.FSM requires from the locker class is the construction/destruction locking.
I see. In Christ, Steven Watanabe