[boost] FSM Review

From: Jody Hagins (jody-boost-011304_at_[hidden])
Date: 2005-03-11 11:16:17

I am sorry this is late.  I made the mistake of introducing my kids to
snow skiing.  Now they can not get enough of it.  Thus, we were gone
again until Wednesday (yes, I let them skip a few days of school to go
skiing).

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

I think the documentation is relatively complete.  However, I am not
exactly thrilled by the requirement on the reader to understand UML
diagrams.  On the other hand, this library is intended to represent UML
in C++ (at least to my understanding), so I'm not sure what else can be
done.  A link to a basic tutorial on UML state machine diagrams would be
appropriate in the "UML to boost::fsm Mapping Summary."  I know you link
to the 730 page OMG document on UML, but I'd also like to see something
that describes the basic UML for state charts.

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

I think the requirements dictate the design.  Specifically, the desire
to mimic UML statecharts in C++.  As stated before, the design brings
with it some performance tradeoffs that will make this library unusable
to some.

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

I think it is obvious that the library should be separated, though I do
not think this issue itself should be a stumbling block for acceptance. 
Exception handling is very important, and I do not buy the rationale
that allowing destructors to throw is not a problem in practice.  I also
do not think I really understand "two stage exit."

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

I did not look too much at the implementation, so I can not comment much
here.

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

I think we have to define real-time.  Traditionally, real-time systems
have hard completion time requirements (e.g., the XYZ event must be
processed in under 50ms).  Even though I have performance issues with
this library, I think it can still be utilized in many real-time
situations.  Andreas has stated several times that the dispatch time
will be small compared to the handling time.  However, I find this
argument a bit lacking, especially for hard real-time requirements,
where each cycle taken for dispatch is stolen from the reaction handler.

My current application requirements do not fit the traditional
definition of real-time.  However, my SMs need to be as fast as
possible, because in a real sense, my code is competing with other code.
 Without going into too much detail, when an "opportunity" is available,
it is only available to the first one to see it, respond, and take that
opportunity.  Thus, my real-time requirement is that I have to be faster
than anyone else playing my game.  I think using this library would put
me at a disadvantage in that particular space.  However, I do have some
applications in which this library could be used successfully (if I were
inclined to learn enough UML to make sense of all the details).

The documentation is clear enough about the performance issues.  In
fact, it may be too clear, as some people seem to see problems that may
not exist in most applications.

One last thing on performance, since it has been a hot topic in relation
to this library.  I do not think it has sufficient performance to
warrant use in all my applications, and I assume the same for many
others.  However, it does have sufficient performance to be used in a
large number of applications.  If the docuemntation is clear (which it
is), then users can decide when/how it can be used.  I could make
similar performance claims agains almost every boost library (and I have
made them on this list about shared_ptr and signals).  However, that
does not mean we should eliminate those libraries from boost, nor does
it mean that they should never have been accepted (but I would like to
see a larger commitment to address performance issues in all currently
accepted libraries).  I would, however, like to see a separate
submission which has a focus on performance, and I would really like to
see the performance issue of this library revisited, especially with
input from some of the folks here who claim expertise in that area.

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

I have used sevaral versions of SMC, solutions from Samek's "Practical
Statecharts in C/C++," and my own hand-crafted stuff.  I think SMC is
the easiest to use, though it also offers the least flexibility.  With
moderate use, I think this library could become the standard tool for
implementing state machines, with the caveat of every tool: it may need
to be replaced if it is too slow.  However, I also think that this tool
requires a more structured design of your state machine than ad-hoc
methods.  Thus, if speed were an issue, translating this code to
something else would not be too difficult.

One thing I have not seen in other reviews is a comparison to GUI state
machine tools.  I know this is a library, with very different
requirements.  However, having virtually no experience with GUI tools
that build FSMs, I'd be interested to see how this code stacks up with
code generated by such tools.  Specifically, I have avoided them because
I want more control than they allow (or at least allowed when I first
looked at them).  Does anyone have experiences to offer in this regard?

    * 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 used it on linux, with gcc.  I am probably the last person in this
community to offer porting advice to older compilers.

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

I read all the documentation, and played with a few examples. 
Specifically, I tried to implement a subset of a current state machine
to compare ease of use and performance.  This library seemed more
difficult to use, but I attribute most of that to inexperience.  I am
convinced that with some moderate level of experience, I could write
state machines more easily with this tool.

    * Are you knowledgeable about the problem domain?

I would not consider myself an expert, by any stretch of imagination. 
However, I have done my fair share of work coding state machines.  I
have used a small number of tools, and I have crafted my own, so I am at
least comfortable with the problems represented by such a library.

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, with two conditions.

1. The name should definitely be changed.  I am not sure, however, what
a new name should be.  I tend to favor one of Andreas' alternatives:
umlfsm.

2. I also think there should be some commitment to revisit the
performance issues.  I am not sure how this works, but I'd be satisfied
with a commitment from Andreas, possibly accompanied by a request to the
Boost community for assitance.  I am not certain that an acceptable
solution can be found, but I think the issue at least needs to be
addressed again, specifically with input from the Boost community.