Re: [Boost-users] [statechart] history transitions makestate-local-storage "un-cool"

From: Andreas Huber (ahd6974-spamgroupstrap_at_[hidden])
Date: 2005-10-16 16:33:26

Hi Mick

Mick Hollins wrote:
> I am currently using the history facility of boost::fsm. I've
> discovered
> that when I re-enter a state, X, via a history transition I don't
> actually re-enter the same instance of X that I was in before,
> but instead enter a newly constructed instance of X.
>
> I just checked the UML spec regarding history transitions and it
> says that "Any necessary entry actions are performed", so given that
> boost::fsm uses constructors to represent entry actions I guess a new
> instance
> of X has to be constructed to ensure UML compliance.

Correct.

> My actual concern is the effect this has on the "coolness" of
> state-local-storage (see
> http://boost-sandbox.sourceforge.net/libs/statechart/doc/faq.html#Whats_so_cool_about_state-local_storage)
> It seems to me that state-local-storage, which I agree is generally
> cool, is
> particularly un-cool (and bug-inducing) in the presence of history
> transitions.
>
> I'm not sure what a good alternative is, but just thought I'd raise
> the discussion.

When I implemented history, I had to make a choice between:

a) The current behavior
b) Abandon the entry-action --> ctor / exit-action --> dtor mappings and
introduce enter() and exit() functions instead (exit() already exists
for unrelated reasons). In non-history transitions the state objects
would be constructed and destructed as they are now (and enter() /
exit() would be called after construction / before destruction).
However, when a "historized" state is exited, exit() is called but the
state is not destructed. Instead, it is stored in the state_machine
object. When a transition to history is made later the state is
retrieved and only enter() is called.

In my experience none of the above behaviors is entirely satisfying in
practice because for some states you want a) and for others you'd want
b). When a state contains two members you could even want a) for the
first one and b) for the second one. Moreover, you can still get the
desired behavior with a), by pushing the state-variables that you want
preserved into outer states or the state machine object. As you
observed, this essentially wrecks the benefits of state-local storage
for those variables. I guess the main reasons that I settled with a)
are:
1. It is simpler to explain and implement.
2. There were no votes in favor of b). In fact, you are the first user
to bring this up.
3. History is used relatively rarely anyway.

Then again, almost all my experience with state machines stems from the
machine control field. Other areas might well have different
requirements / expectations, so I'm interested in your use-case and how
much of a difference b) would make. Also, there might be other, less
intrusive approaches that I haven't thought about.

> PS: does the history facility display the same semantics in
> boost::statechart?

Yes. Before switching to the current version I'd recommend reviewing the
change history here:
http://boost-sandbox.sourceforge.net/libs/statechart/doc/index.html

Regards,

-- 
Andreas Huber
When replying by private email, please remove the words spam and trap
from the address shown in the header.