Re: [boost] Re: FSM Review

From: Jody Hagins (jody-boost-011304_at_[hidden])
Date: 2005-03-13 22:59:15

On Sat, 12 Mar 2005 13:42:19 +0100
"Andreas Huber" <ahd6974-spamgroupstrap_at_[hidden]> wrote:

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

That is certainly what I was looking for, but I completely missed the
link.  Maybe a better place would be the introduction where you first
introduce the idea of UML state machines.

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

So, basically... you use exit() so that you are not technically throwing
from the dtor.

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

Yes, it makes more sense, but I still contend that in critical apps,
every cycle used by the state machine mechanism is a cycle stolen from
the handler, and these cycles could be the difference in making/missing
the target deadline.  In these situations, tha absolute amount of time
in the dispatch is more important than the percentage of time spent in
the dispatch relative to the reaction.

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

Or, that the other bottlenecks are common enough that everyone pays them
on a relatively equal footing.  The cycles are even more important if
the competition has lower cost in the common bottleneck areas.

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

To me, that one is a little less descriptive of what is going on, but I
would be willing to accept it.

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

I would be fine with acceptance before the work was done, so long as a
concrete commitment was in place to do more research on the issue.

I think at this point, we are in a scenario in which no one has spent
significant time investigating the newly proposed issues (unless Andreas
has already tried the ones being proposed).  Thus, we can only talk
about possible solutions, and since no one has real answers, it seems to
me that our collective intelligence and good nature is turning into
technological hubris, thus preventing us from making much progress in
this discussion.  I've been there before, and it ain't a pretty picture,
even for the party that turns out to be right.

Thus, it seems that Andreas is not planning to make significant
performance changes, and he has doubts as to the possibility that such
changes are even possible.  However, he has agreed to make a solid
attempt to address the issues after acceptance (with the help of any
volunteers), if such acceptance is granted.  Maybe we should ease up a
bit on the details of performance until such time as the library is
either accepted or rejected.  Then, we can resume such discussions as
appropriate to the situation and goals of the library.