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

From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2006-05-15 02:59:05

Tim,

thanks for your earlier replies. I've been off the list for a while and 
couldn't respond earlier.

Tim Milward wrote:
>>>> 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 tried this originally, but it somehow grew the complexity beyond my 
control so I reverted to my previous solution. IIRC it was rather complex to 
keep the forward declarations and actual definitions in the correct order 
when the template parameter was a kind of State. I might take another stab 
at it later.

[snip]

>>> 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?

I did want to reuse the inner states - but in the end I found it wasn't 
worth the work involved, so I allowed myself to do some code duplication 
instead (which is basically what I said above - sorry for not being very 
clear).

>
>>> 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.

I tried modeling this with an asynchronous statemachine and it looks 
promising. There's just one thing that I don't like - it doesn't seem to be 
possible to query the asynchronous statemachine for its current state. I 
realize that during real execution this isn't a good thing to do, but I need 
this for my unit tests. In the tests I feed the statemachine with events in 
a controlled environment and check that the transitions and the states' 
behaviour are as expected.

// Johan