From: Andreas Huber (ahd6974-spamgroupstrap_at_[hidden])
Date: 2005-02-24 17:44:10
Hi Darryl
Thanks for you review!
>> What could be added
>> (or removed) from the library?
>
> I'm with Simon in the desire to declare all transitions including
> guards and in-state reactions in the header (rather than just declare
> a custom reaction). It isn't just automated tools that find this
> easier to follow - it simplifies the process of doodling a transition
> diagram with one hand while scrolling through the code with the other
> - or reading the doodle and touchtyping the declarations. I think it
> is highly desirable that the full set of allowed transitions be
> clearly visible from declarations alone. The documentation suggests
> "Custom reactions can of course also be implemented directly in the
> state declaration, which is often preferable for easier browsing."
> but this breaks encapsulation unless the guard actually calls a
> number of sub-functions in a way similar to Simon's suggested
> templated guard.
Ok, I'll implement something like that, but it will take a while. I
think there are more important things that should come first (like e.g.
serialization).
> Andreas has previously pointed out a problem in providing in-state
> reaction declarations in that any such transition is then forced to
> use an outer context (incomplete type otherwise) which seem somewhat
> odd for an in-state reaction, however I haven't actually found it to
> be a big problem in practice (innermost states tend to be empty).
> Maybe it would be sufficient to provide a declaration that simply
> specifies that a particular event is handled by an in-state reaction
> (ie. similar to the custom reaction declaration), but with the
> handler having no ability to return a transition object?
This has recently occurred to me also. I'll implement an in-state
reaction the way you suggest in the very near future.
>> * The library documentation contains
>> few not yet solved issues (name,
>> separating the library into two parts,
>> exception handling). What is you opinion here?
>
> Naming: Please keep UML out of it ;-). High Level is simply too
> vague. How about Matrioshka (a bit obscure I guess)...
:-)
> I don't think
> some unpronounceable abbreviation intended to distinguish it from
> other possible fsm libraries is useful.
Ok, noted. I now also lean more towards keeping fsm.
>> * Are there performance bottlenecks?
>
> The various performance tradeoffs are well described in the
> rationale. I wonder if there isn't some way of optimising empty (ie
> no associated context) states better to improve performance, but it
> isn't a big issue for me.
I can't see how at the moment (the often empty innermost states are
implemented differently already).
>> Does the library design fit requirements
>> of real-time systems?
>
> To the extent that anything that uses dynamic memory allocation does,
> yes. The documentation does cover the issues well. In long running
> (uptimes of months) soft real-time embedded systems, we are not
> seeing any problems (this is even without using custom allocators).
That's very interesting to hear! I would have expected you seeing memory
fragmentation problems within days. Could it be that the default
operator new of your platform does some pooling internally?
Best Regards,
-- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.