Query state on an asynchronous_state_machine

Hi. Can anyone tell me how to query a state on an asynchronous_state_machine? The obvious answer would be to say use the state_downcast method (which is inherited from state_machine. But in practise it seems harder than so. But opposed to state_machine, when using asynchronous_state_machine the instance is not created explicitely, it is created implicitely by the scheduler, like this: myMachine = myEventHandler.create_processor<AsyncMachine>(); , hence there is no handle to the state machine itself. All I have is a handle to the processor (sc::fifo_scheduler<>::processor_handle ). So is there a way to come from sc::fifo_scheduler<>::processor_handle to AsyncMachine (which inherits sc:asynchronous_state_machine)? Jarl

Hi Jarl
Can anyone tell me how to query a state on an asynchronous_state_machine?
The obvious answer would be to say use the state_downcast method (which is inherited from state_machine. But in practise it seems harder than so.
But opposed to state_machine, when using asynchronous_state_machine the instance is not created explicitely, it is created implicitely by the scheduler, like this: myMachine = myEventHandler.create_processor<AsyncMachine>(); , hence there is no handle to the state machine itself. All I have is a handle to the processor (sc::fifo_scheduler<>::processor_handle ).
This is intentional. If fifo_scheduler supported a state_downcast method then inevitably race-conditions would arise (the result of a state_downcast is a state object, which could have been destructed long before the caller gets hold of it).
So is there a way to come from sc::fifo_scheduler<>::processor_handle to AsyncMachine (which inherits sc:asynchronous_state_machine)?
No, for the same reasons. A sc:asynchronous_state_machine<> subtype is serviced by the fifo_scheduler thread. Directly accessing it from a different thread would again open the door to race-conditions or dead-locks. The proper way to query an asynchronous state machine is by sending it a special event carrying a boost::function object. The state_machine typically defines an in_state_reaction for said event, which simply calls boost::function::operator(). This arrangement lets you execute arbitrary external code in an FSM. Of course, if said external code needs to send results to another thread, then you'd need to employ a condition variable or some such and make sure that you make copies of all heap-allocated data that you hand over. This whole procedure could be implemented nicely with futures, but Boost does not (yet) sport such a library :-/. HTH, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

"Andreas Huber"
Hi Jarl
That's what I thought... However the context I am requesting this feature is VERY controlled. It's in a unit test. Everything is in one thread, I wait for the scheduler to process all events, and then I want probe the state and verify correct state. It may sound like test of the statechartlibrary itself. It's not; I am testing that I have correctly defined my statemachine.
So is there a way to come from sc::fifo_scheduler<>::processor_handle to AsyncMachine (which inherits sc:asynchronous_state_machine)?
No, for the same reasons. A sc:asynchronous_state_machine<> subtype is serviced by the fifo_scheduler thread. Directly accessing it from a different thread would again open the door to race-conditions or dead-locks.
Yes, under normal conditions (hostile production environment). But not in test envs.
The proper way to query an asynchronous state machine is by sending it a special event carrying a boost::function object.
Interesting, that sounds like a feasible solution for the test. The function could probably be the assertion itself. Thanks for the answer, I might have a look at it. Jarl
participants (2)
-
Andreas Huber
-
Jarl Friis