On Sat, 12 Mar 2005 13:42:19 +0100 "Andreas Huber" <ahd6974-spamgroupstrap@yahoo.com> 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.