From: Andreas Huber (ahd6974-spamgroupstrap_at_[hidden])
Date: 2005-03-14 13:50:44
Jody Hagins wrote:
> 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.
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.