[boost] Re: [prereview request][fsm]

From: Darryl Green (darryl.green_at_[hidden])
Date: 2004-05-28 00:56:14

Andreas Huber <ah2003 <at> gmx.net> writes:
> David Abrahams <dave <at> boost-consulting.com> writes:
> > Darryl Green <darryl.green <at> unitab.com.au> writes:
> > > Maybe I'm just being thick
> > If exit actions happen after transition actions...
> They don't. In any transition all exit actions are executed first, then the 
> transition action and finally all entry actions.

Ok - make that definitely being thick and failing to rtfm :o) In hindsight, 
this is clearly the order one would expect for action execution but the idea 
that a state would "exist" until a new state was entered was too strongly 
ingrained, and I failed to think this through fully.

It seems that this whole business of having an FSM that has meta-states in 
which no state exists (ok, you call them unstable states and an outer state, 
or possibly the FSM itself, always exists, but the outer state isn't really 
part of the simple state machine) is a LEM violation that just makes things 
complicated.

I do think there is utility in having memory and resources associated 
with/contained by the state. However I think the current state lifetime wrt 
actions is wrong. To quote Bruce Douglass in Doing Hard Time - 7.3.1 Basic 
State Semantics ".. a state is a condition of an object during which a set of 
events is accepted and some actions and activities are executed, and the 
object can reach some set of states based on the events it accepts."

If the lifetime of the state object (afaik in UML a state isn't an object at 
all) is to model the duration of the state, this implies that the state must 
exist until the transition is complete (and a new state exists). Anything else 
is a LEM violation.

So, I now see that mapping entry/exit actions to c'tor/d'tor of the state gets 
one or the other of action invocation order or state duration wrong. I think 
that with a separation and re-ordering made, the exception handling should be 
less controversial, though if the previous state is destroyed before the new 
state is constructed, a throwing constructor will still be interesting to 
handle. That said, one suspects the "can't acquire resources to enter state" 
exception is really one which dooms at least the inner fsm, and it isn't 
particularly likely that the previous state could have dealt with this in any 
useful way.

This change would also allow an action's context be to be the source state - 
or would there still be some problem with that? Does the context really have 
to be an outer state of the destination as well as the source?

Oh - and I should have said somewhere earlier in all this that it is a very 
nice library - it really does seem very powerful, and I'm very keen to put it 
to real use.

Regards
Darryl.