RE: [boost] ANN: review of FSM library starts

From: Simon Gittins (Simon.Gittins_at_[hidden])
Date: 2005-02-22 20:15:53

I think the library should be accepted in boost.

Comments below.

> -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]]
> On Behalf Of Pavel Vozenilek
> Sent: Monday, February 21, 2005 11:31 AM
> To: boost_at_[hidden]
> Subject: [boost] ANN: review of FSM library starts

[snip]

> 
>     * What is your evaluation of the documentation?
>       How easy (or hard) it is to understand library
>       features? What can be improved?
> 

The tutorial is good.  The few times I've needed the reference, it has
been sufficient.

> 
>     * What is your evaluation of the design?
>       What features are supported better by
>       alternative FSMs? What could be added
>       (or removed) from the library?
> 

Three appealing features of boost::fsm for me are:
 - No code generation
 - Hierarchical.
 - State local data ('state is an object').  
In my application (5 state machines, each with 8 - 40 states), I was
able to use the fsm to manage the lifetime of objects local to the state
(and any inner states).  To me, it seems natural that states have the
option of 'owning' information.  Managing the lifetime and access rights
of some 50+ variables used by a state machine would be unpleasant.

I think that custom_reactions that act like guards should be
discouraged, as they effectively hide part of the state chart in the
implementation.  When I read a particular fsm, I want to be able to
clearly see all possible transitions and actions without having to
search through any decision logic code to fill in the gaps.  We should
be able to specify guards as part of the state definition.  Something
like this:

struct StState: fsm::simple_state<StState,StOuter,
  mpl::list
  <
    fsm::guard2<EvEvent,
      fsm::switch<StRes0,StRes0ActCtxt,&StRes0ActCtxt::Action0>,
      fsm::switch<StRes1,StRes1ActCtxt,&StRes1ActCtxt::Action1>
    >
  >    
>;

I guess this might make the cpp code look like this:

fsm::guard2::result StState::guard2(const EvEvent& ev)
{
  if(cond) return fsm::guard2::result<0>();
  else return fsm::guard2::result<1>();
}

I haven't thought about the implementation too much admittedly.  Having
this would be a big help in automatically generating UML state charts.

> 
>     * The library documentation contains
>       few not yet solved issues (name,
>       separating the library into two parts,
>       exception handling). What is you opinion here?
> 

I have no opinion on the possibility of splitting the library in two.  

I've avoided using the exception handling feature of boost::fsm, but the
description in the documentation looks fairly sensible.

> 
>     * What is your evaluation of the implementation?
>       Are there parts of code too obscure or
>       duplicating exiting Boost functionality?
>       Can something be factored out to standalone
>       library or among general utilities?
> 

Implementation appears concise.  No real concerns here.  I was able to
add a new type of reaction (in_state_transition - trivial though it is)
with no problems.

> 
>     * Are there performance bottlenecks?
>       Does the library design fit requirements
>       of real-time systems? How is it useable
>       for embedded systems?
>       Is the documentation clear on performance
>       tradeoffs?
> 

The library produces large binaries.  It does however, appear to scale
reasonably well (anecdotally, it seems about linear with the number of
states).  The in memory footprint is of the same order of magnitude as
the binary size.

My application is fairly soft real time, and runs on an embedded
486-like system, with a few hundred individual state machines and a few
hundred events delivered per second.  In this case, the performance of
boost::fsm is acceptable, and does not threaten any timing constraints
of the system.

> 
>     * What is your evaluation of the potential
>       usefulness of the library? Can you compare
>       this FSM to other implementations?
> 

The library has already been useful, and I see myself using the library
again.  I believe that boost::fsm is a good solution for many non
trivial compile time fsms.  

> 
>     * Did you try to use the library?  With what
>       compiler? Did you have any problems?
>       Do you have tips for better support of older
>       compilers? What are possible portability problems?
> 

I've been using an older version of the library with gcc-3.2.3

> 
>     * How much effort did you put into your
>       evaluation?
>       A glance? A quick reading? In-depth study?
> 

I've spent quite a few hours developing using boost::fsm, and about half
an hour catching up the on the latest documentation.

>     * Are you knowledgeable about the problem domain?
> 

Not overly.  I've built state machines with switch(), and have had to
build a flat dynamic fsm framework (and use it) in the past.

> 
> And finally, every reviewer should answer this question:
> 
> 
>     * Do you think the library should be accepted as a
>       Boost library?  Be sure to say this explicitly so that
>       your other comments don't obscure your overall opinion.
> 

Yes

Simon Gittins

##########################################################################
This e-mail is for the use of the intended recipient(s) only.  If you have 
received this e-mail in error, please notify the sender immediately and 
then delete it.  If you are not the intended recipient, you must not use, 
disclose or distribute this e-mail without the author's prior permission.  
We have taken precautions to minimise the risk of transmitting software 
viruses, but we advise you to carry out your own virus checks on any 
attachment to this message.  We cannot accept liability for any loss or 
damage caused by software viruses.

##########################################################################