Boost Users :
From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2006-05-15 02:59:05
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):
>> 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 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.
>> 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
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
>>> 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
>> 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.
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net