Re: [boost] [fsm review] Not quite a review

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2008-08-19 15:03:56

Darryl Green wrote:
> I don't know if I will have time to do a proper review of the library.
> The following are my notes on it so far.

Thank you for your effort.

> Docs are quite good, but perhaps lack enough rationale style
> documentation on how the library models FSM concepts. Would benefit from
> some "how to" examples of more realistic usage and some "how to" docs on
> translating FSMs expressed using UML (or Harel) statecharts into a form
> implementable using FSM.

Ok, I will add a separate rationale section. As for "how-to", I thought
the tutorial would play this role. I'll think about it.

> Bad points:
> 
> Unusual terminology. While there are obvious performance reasons for
> avoiding the Boost Statechart approach of applying an RAII model to
> state activation, it is not clear why at least basic concepts and
> terminology have not been used in FSM - especially as most Statechart
> terminology and FSM behavioural concepts are straight from UML
> terminology (it is a standard, you could pick another one, but why not
> stick with this one)? Note that this is *not* a request that the library
> include more features - just for some consistent ones.

I'm not sure what parts of documentation you are referring to when
saying "unusual terminology". I'm sure, my English is far from perfect
and may not know some formal terms. I would be glad to fix all
inconsistencies.

> Some idiosyncratic behaviour. The FSM delivers the event to the
> on_process() handler in the "switched to" state when the transition is
> specified using the transition map, while delivering it to the
> on_process() handler in the current state if no transition map entry
> matches.

There's a rationale in the docs for this behavior. The main reason is
that if the transition rule is executed after the on_process handler in
the current state, it is possible that the on_process handler switches
to another state itself, which would make the chosen transition invalid.

> There are warnings against mixing the transition map and
> switch_to() approaches to FSM specification, but even so it seems that
> the 2 uses of the on_process() handler are completely different. Would
> it not be better to have a model similar to Boost.Statechart where a
> custom reaction (implemented by a react() method) in a state is used to
> perform actions within the start state, generally including making a
> (gated) transition, while any action to occur on a transition is
> specified as part of the transition? Further, that transition action
> should be performed after the exit action of the current state and
> before the entry action of the new state.

That would completely change the purpose of transitions and transition
table. Now the transition table is used to define the conditions when to
transit and which state to transit to. With your approach the transition
table would define _how_ to transit, i.e. what to do while transiting.
This would leave the logic of deciding whether to transit or not to
event handlers only.

> No event queuing mechanism, so no way to post an event while processing
> an event - although I see there has been some discussion about adding
> event deferral - which might be (almost) enough.

Like I said, the functionality of event scheduling, with event
priorities, delivery delay support, event cancellation, periodical
events, etc. deserves its own library. It's not only FSMs where such
functionality would be useful. However, I will think about it more.

> Slow at compile time. I have not tested as yet, but if it is as slow as
> the mpl example state machine implementation, this will be a problem (I
> have previously had to abandon use of the MPL FSM due to compilation
> time issues on only moderately complex FSMs).

True. I'm not sure there can be done much with it.

> Lacks real world use? I don't know if that is true, but I haven't seen
> anything other than toy examples. I was thinking that in the cases where
> the performance of Statechart was inadequate for complex augumented FSM
> implementation I would consider using FSM - but it would mean building a
> fair bit of additional scaffolding around FSM - maybe this should be
> part of the library? Or at least some examples of ideomatic use should
> be included? I found myself wondering if anyone had actually tried to
> use it in this way? Conversely, I don't find it compelling for
> implementing something like a lexer or even the terminal emulator
> example. What is the application domain?

The library was definitely useful for me. I used a somewhat similar
library to implement FSMs for INAP dialog users and telephony services,
where performance was critical. The code is commercial, so I cannot post
it here, however these applications would be perfectly supported by this
library as well. I also made a quick C++ parser on this library to
markup the code samples I used in the library docs. The latter, indeed,
was just a toy. I think, the library would be most suitable for various
protocol clients, which should maintain internal state and act according
to it and where different event types can be distinguished.

> Not quite a conclusion:
> 
> This is a hard one. At one extreme, Boost.Statechart is extremely
> powerful and well worth using in certain application domains (but there
> are performance implications), and at the other, as has been
> illustrated, various hand-rolled solutions of varying degrees of
> elegance get the job done. There seems to be a lot of space in between,
> and I'm not sure that the proposed FSM library fills enough of it.

Thanks again for your opinion.