[boost] Re: Re: FSM Review

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.