Re: [Boost-users] [statechart] Event handlers and state reusage

From: Tim Milward (tim.milward_at_[hidden])
Date: 2006-05-09 07:26:10

>>>2. Is is somehow possible to reuse state definitions as substates of
>>>different "higher-level" states?
>>
>>In boost/libs/statechart/doc/tutorial.html#TransitionActions it says,
>>"With Boost.Statechart, a transition action can be a member of any
>>common outer context" and goes on to give some examples. If I've
>>understood your question correctly then the answer is "Yes".
> 
> 
> Actually, I'm inclined to say "No" considering the following (partially 
> duplicated from your part later in the posting):
> 
>  Top
>    Remote
>      Idle
>      Executing
>    Local
>      Idle
>      Executing
> 
> This I cannot do, right? Idle and Executing would ideally be the same, but 
> as they are statically associated with their outer states (and vice versa) 
> it doesn't look like it's possible. 

OK, I've miss understood. Does this help? 
boost/libs/statechart/doc/tutorial.html#SubmachinesAndParametrizedStates

It describes how to use templates to implement submachines. In the above 
example you'd use Executing<Remote> and Executing<Local>.

>>>- I've got an application that can be either in remote or locally
>>>controlled mode (this is the highest-level states).
>>>- Certain events are allowed both in remote and local, while some
>>>are not. As an example, the "CommandEvent" event should be handled
>>>both in remote and local - resulting in the "ExecutingCommandState"
>>>being entered. - I'd like to be able to reuse the definition of
>>>ExecutingCommandState regardless of the enclosing state being Remote
>>>or Local - Possible?
>>
>>Could you implement this with orthogonal regions?
>>
>>Top
>>  Remote
>>  Local
>>  ------
>>  Idle
>>  Executing
> 
> Sorry for my ignorance, but what then happens if there would be an 
> additional substate, that should only be possible when in e.g. the Remote 
> state.

Then it would go in the remote state. If you want a state only available 
in Remote and Executing that can't be done. But then you are not simply 
reusing Executing submachine because it's different in Remote and Local.

>>Top
>>  Remote
>>    RIdle
>>    RExecuting
>>  Local
>>    LIdle
>>    LExecuting
> 
> This is more similar to what I've got. There isn't really any other code 
> duplication that having to define the e.g. RIdle, LIdle, RExecuting, 
> LExecuting, as the state machine itself holds a reference to the domain 
> object responsible for executing the actions. Within the different states I 
> simply get this object using context<StateMachine> and delegate - so the 
> state machine is in this case only used for discriminating the disallowed 
> events according to the current state.

So what is it you want to reuse? Is it a common list of reactions, to 
which each of L & RExecuting add the reactions specific to Local and Remote?

>>UML
>>provides "Do Activities" that can be used for this purpose. The
>>statechart docs suggest simulating this "with a separate thread that
>>is started in the entry action and canceled (!) in the exit action of
>>a particular state". I quite like that approach.
> 
> 
> I considered executing the commands in a worker thread similar to that 
> approach; when receiving a command the FSM would enter the ExecutingCommand 
> state, kick off a new thread (or using a previously existing worker thread) 
> to execute the command. The problem I ran into that I wanted the 
> command-executing thread _itself_ being able to signal the completion of the 
> command (and thus trigger exiting the ExecutingCommand state to the previous 
> state). It should never be possible to exit the state unless the command has 
> run to an end, e.g. by unconditionally joining the worker thread in the 
> state's destructor.
> 
> I couldn't really find a clean, thread-safe way to implement this. Did you 
> actually try to implement anything like this?

Not yet. Can the worker thread, after processing the command push a 
Finished event onto the queue. When the statemachine thread receives 
this event it exits the Executing state.