Boost logo

Boost Users :

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?

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

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

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

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at