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
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk