Re: [boost] [msm] Review

Subject: Re: [boost] [msm] Review
From: Simon Gittins (Simon.Gittins_at_[hidden])
Date: 2009-11-30 20:23:42

Hi Cristophe

[Advantages/disadvantages of state local storage...]

>+ speed: states don't need to be constructed again and again.
>Constructing a state (and its attributes) each time it becomes active
>can be costly, even if memory allocation can be optimized.

I agree that the feature can be costly.  I don't have a lot of experience with fsms with very tight time constraints though - SC seems to meet our time requirements (ie the state machine itself is much faster than the other operations we perform).  

>+ your state data is always available. In my experience, state data is
>not only needed in the entry or when the next event is processed, but
>during a transition or even at some time after a transition. This
>means, that you have, during a transition, access to data from the
>source or the target state.

This is simple to emulate in SC.  The state data can be owned by the outer state, or by the state_machine itself.
 
The advantage of true state local storage is that it encourages the use of meaningful destructors.  As a (real life) example, a common strategy in our use of (asynchronous) SC is to instantiate a timer in the constructor of the state (which may be an inner state of another state which has its own timer).  Since exiting the state destructs the timer, we don't have to explicitly cancel it (in the exit action for example).  It's just one less thing we risk forgetting to do.  

>+ combined with the visitor, you can at any time access data from the
>currently active state and build a generic way to do something with
>state data.

Granted.  Personally though, I prefer to keep my fsm opaque, and force the use of events and actions to update and monitor the fsm respectively.  Any other method (in our application) is a violation of the desired encapsulation.  

Of course, this probably just means that I haven't come across such a requirement in my use of fsms, so I won't hold the visitor against you :)

>+ you can build examples like the iPodSearch where states keep
>iterators to some container, thus keeping information from an
>iteration to the next one.

Again, the iterator can be held by an outer state, or by the state_machine itself in SC.

>+ you avoid having data released inside a destructor. Knowing that
>destructors should not throw, it makes your life easier.

If releasing data in destructors (or in exit actions) is considered harmful, one can simply not use state local storage (make all state data owned by the state_machine).

>+ on_entry is templatized, giving you more leeway to add
>event-specific handling.
>+ your event data is not lost upon state entry

True, I believe that these features could be useful.

IMO the lack of state local storage is actually a relatively minor issue.  The big ticket issue for me is its ability (or rather, the compiler's ability) to create large state machines.  With SC, I might create a 50 transition state machine.  Over time, normal maintenance might add another 10 or 20 transitions.  This isn't a big deal.  However, I'd be less likely to start developing such a state machine with msm for fear that any additional transitions might push the compiler 'over the edge'.

So for medium to large state machines, I would choose SC.  For very small state machines, I might be tempted to choose a C style hand written state machine to avoid the learning overhead for such a trivial application (though Euml is cool enough that I might overcome that).  

Cheers
Simon

---------------------------------------------------------------------
CONFIDENTIALITY NOTE: Please consider our environment before printing this email.This email and any attachments are confidential and may be subject to copyright, legal or some other professional privilege. They are intended solely for the attention and use of the named addressee(s). They may only be copied, distributed or disclosed with the consent of the copyright owner. If you have received this email by mistake or by breach of the confidentiality clause, please notify the sender immediately by return email and delete or destroy all copies of the email. Any confidentiality, privilege or copyright is not waived or lost because this email has been sent to you by mistake.
---------------------------------------------------------------------