Boost logo

Boost :

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

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


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

> 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

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


Andreas Huber
When replying by private email, please remove the words spam and trap
from the address shown in the header. 

Boost list run by bdawes at, gregod at, cpdaniel at, john at