[boost] FSM Review

From: Peter Petrov (ppetrov_at_[hidden])
Date: 2005-03-06 20:28:24

I have used and watched closely this library for more than a year, since
its early versions. Initially, we needed a good modern state machine
framework for a project at the company I work for. After evaluating the
possibilities, we decided to take the risk and go with Andreas' FSM,
despite its early-alpha state at the time. Now, one year later, that
choice has proved to be correct. We have used FSM in one more project
and are planning to use it in future projects too.

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

The documentation is very adequate. I was able to quickly understand how
to use the basic features of the library, and then proceed to the
advanced ones. At that time I had experience with different kinds of
state machines, but primarily SDL-specified. FSM's documentation was my
first introduction to UML state charts, and did the job well. The
tutorial is excellent. The FAQ and Rationale sections give important
answers to questions which are likely to arise. There is also an
extensive Reference section, which I needed very rarely.

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

To me, the design is good and follows naturally from the objectives of
the library. It imposes some restrictions, although they can be overcome
if necessary (for me it has not been necessary). For example, machines
don't recognize polymorphic events, therefore they cannot "forward"
unknown events to another machine. This can be circumvented by using a
"wrapper" event around such events, which works, but only with
asynchronous machines. Another example is the way that state machines
are inherited - it's not very flexible and only allows altering how a
state machine reacts to an already recognized event. One cannot add
support for new events, except using again the "wrapper event" trick.

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

The name (boost::fsm, Boost.FSM) is fine for me. Regarding separating
the library into two parts, I prefer it being separated, since the
Worker part is useful by itself.

     * 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?

It's as obscure as its complexity requires. At the same time it is
stable and bug-free, which is proved by extensive bulk-testing in our labs.

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

The documentation is definitely clear on performance tradeoffs, and it's
up to the potential user to take an informed decision.

One tradeoff is that dispatch time is linear to the number of nested
states. In my experience this is not a problem, since there are rarely
more than two nested states, and I have never seen more than three.

A possible problem is that states are constructed using operator new().
The documentation clearly states that, and the library allows overcoming
the issue by specifying a custom allocator for the state machine, as
well as writing custom operator new()'s for all state classes. I
personally am against the second requirement and think that it
complicates things too much. Specifying a custom allocator for the state
machine should be enough. (this is mentioned in the documentation, in
the Rationale section under "Memory management customization")

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

The greatest distinction of code written using the FSM library is its
manageability. It's very easy to write and subsequently evolve state
machines and most common mistakes are caught at compilation time. When
state machines are involved, using FSM is definitely a great improvement
over using a primitive framework, or not using a framework at all (the
notorious switch/case idiom). Especially if the library's advanced
features are used.

     * 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?

Used with MSVC++ 7.1 and GCC 3.x. Currently without problems. In the
early versions there were some minor issues which Andreas has addressed
quickly. Regarding older compilers, I don't think they should be
supported by this library.

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

In-depth study, as well as real-world usage.

     * Are you knowledgeable about the problem domain?

To a good extent. I have developed two different state machine
frameworks, although both of them were significantly lower level than
FSM. I have also worked extensively with various kinds of state
machines, mainly protocol-related and in telecom applications.

     * 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. Definitely.