Jody Hagins wrote:
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.
These links will be in index.html under Audience, I hope that's a better place.
So, basically... you use exit() so that you are not technically throwing from the dtor.
That's only part of the game, exit() is only called if there isn't already an exception pending.
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.
Absolutely. [snip]
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).
Nope, answering posts more than fills of what I can invest at the moment ;-). 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,
Do you mean hubris as defined in http://en.wikipedia.org/wiki/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.
I don't think that turning out to right is the point of the performance discussion.
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.
As I have already mentioned to Dave, I do have a few ideas (O(1) dispatch seems theoretically possible for non-orthogonal machines)that I'm going to try as soon as I have more time. I see a few obstacles for which I don't yet have solutions. I guess I'll post the details to the developers list so that other brains than my increasingly biased one can think about it. Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.