FW: statechart::asynchronous_state_machine and state-local storage
Hello: I have two instances of the same state machine, which are launched as asynchronous_state_machines. I also have some state-local storage in these state machines that I would like to be able to access from outside the state machines. Actually, to be more precise, I want each instance of the state machine to be able to access a single member variable of its twin. The problem is, if I create an asynchronous state machine in the usual way (via fifo_scheduler<>::initiate_processor() and fifo_scheduler<>::operator (), it seems that the actual instance of the state machine is buried in the framework somewhere; I don't have access to a pointer to the state machine itself. Can anyone tell me how I go about getting a reference to the state machine that is instantiated when fifo_scheduler<>::initiate_processor is called? Thank you, Tim Crews GECO, Inc.
Hi Tim
I have two instances of the same state machine, which are launched as asynchronous_state_machines.
I also have some state-local storage in these state machines that I would like to be able to access from outside the state machines. Actually, to be more precise, I want each instance of the state machine to be able to access a single member variable of its twin.
Ok.
The problem is, if I create an asynchronous state machine in the usual way (via fifo_scheduler<>::initiate_processor() and fifo_scheduler<>::operator (), it seems that the actual instance of the state machine is buried in the framework somewhere; I don't have access to a pointer to the state machine itself.
That's intentional. If a thread A would be able to directly access a state machine that is serviced by a thread B then often race conditions and/or deadlocks would result.
Can anyone tell me how I go about getting a reference to the state machine that is instantiated when fifo_scheduler<>::initiate_processor is called?
You can't, see above. Two asynchronous state machine must only exchange data in a, well, asynchronous manner. That is, have the requesting state machine post an event to the other FSM, which in turn posts the requested data in an event back to the requesting FSM. Of course you'll have to be careful to always *copy* the data and never let both state machines access the same data through e.g. pointers. HTH, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
You can't, see above. Two asynchronous state machine must only exchange data in a, well, asynchronous manner. That is, have the requesting state machine post an event to the other FSM, which in turn posts the requested data in an event back to the requesting FSM. Of course you'll have to be careful to always *copy* the data and never let both state machines access the same data through e.g. pointers.
Lets assume, this "shared data" is defined externally to the FSMs, and then a ptr to the data is passed to them all (in the constructors or by means of an event). If this data is accessed in a thread-safe manner, then such a design doesn't seem to be dangerous, does it? Thanks, Igor'.
Hi Igor
You can't, see above. Two asynchronous state machine must only exchange data in a, well, asynchronous manner. That is, have the requesting state machine post an event to the other FSM, which in turn posts the requested data in an event back to the requesting FSM. Of course you'll have to be careful to always *copy* the data and never let both state machines access the same data through e.g. pointers.
Lets assume, this "shared data" is defined externally to the FSMs, and then a ptr to the data is passed to them all (in the constructors or by means of an event). If this data is accessed in a thread-safe manner, then such a design doesn't seem to be dangerous, does it?
It depends on how long the lock is taken by each FSM. If we're just talking lock, read/write, unlock then no I don't think you'd have any problems with just two FSMs. The longer the lock is taken the more could shared data access become a bottleneck and adversely affect performance. Of course, for Tims problem (access of state-local data), this is not a good solution as it would inevitably make the data non-local. Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
participants (3)
-
Andreas Huber -
Igor R -
Tim Crews (boost)