[boost] Re: FSM Review

From: Andreas Huber (ahd6974-spamgroupstrap_at_[hidden])
Date: 2005-03-12 07:42:19

Hi Jody,

Thanks for your review!

Jody Hagins wrote:
> 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.

http://www.objectmentor.com/resources/articles/umlfsm.pdf
doesn't do the trick (linked from the tutorial under Audience)?

>    * 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'm basically saying that you *usually* don't need to propagate 
exceptions out of exit actions. But sometimes you still need to do it 
and then you can use two stage exit.

> I
> also
> do not think I really understand "two stage exit."

Two stage exit means that you now have two functions that are called 
whenever a state is exited. If present, exit() is called first and the 
states' destructor is called second. If you need to signal an exit 
action failure, you can do so by propagating an exception out of exit().

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

What I meant was that if you have a typical hierarchical FSM with 
*empty* actions, then the time used to find the transition triggered by 
the current event (dispatch time) is typically small compared to what it 
takes to execute that transition (exit the original state configuration 
and enter the target state configuration). Even more so if you add 
non-trivial actions.

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

I hope the argument makes more sense with the explanation above.

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

Agreed, given that there are no other bottlenecks (network latency, 
etc.).

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

I'm having exactly this gut-feeling ever since the performance 
discussion started and I'm really relieved that at least someone else 
thinks this way :-).

> 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,

I'd like to see that too.

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

I'm willing to do that, see below.

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

Agreed.

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

Ugh, I'm not so fond of that name. I'd prefer Alexander's 
"Boost.Statechart".

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

That's fine with me. I think it would be easiest if interested people 
contact me directly, so that we can look at ways to improve the 
performance. If we find ways to improve it *considerably* that require 
only small or no interface changes (and all the requirements are still 
satisfied), I will implement them (and I'm happy not to add the library 
until they are implemented). I'll leave it up to the interested people 
to define the acceptance process in case no ways to improve the 
performance are found within a certain time frame.

Regards,

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