From: Andreas Huber (ah2003_at_[hidden])
Date: 2004-05-25 19:09:30
Rob Stewart wrote:
> From: Andreas Huber <ah2003_at_[hidden]>
>>
>>> Could the fsm manage a container of (pointers to) state objects
>>> that it populates as it first creates each state object and from
>>> which it retrieves a state object when transitioning? IOW, the
>>> first time the fsm encounters the need to transition to a given
>>> state (from A to B, say), it creates B and tracks it in the
>>> container. Upon transition back to A, the fsm locates state A in
>>> the container and reuses it.
>>
>> This is certainly possible. I just have my doubts whether this
>> approach is so much better speed-wise. If you customize state memory
>> management, construction and destruction doesn't take an awful
>> amount of cycles. Searching that state container might well take
>> longer for large FSMs.
>
> That's certainly an important consideration, but I was thinking
> in terms of something built into the fsm framework, thus
> providing the benefit for all clients versus requiring clients to
> do work if they want the speed improvement. If your concern
> proves correct, then using the container approach isn't helpful.
> However, the states' base class, which I presume is part of your
> library, could provide a pool allocator for state objects. That
> would put the onus on the library, rather than the clients, and
> would still reduce the (perceived, not proven) overhead caused by
> creating and destroying state objects on each transition.
<rationale quote>
simple_state<> and state<> subclass objects are constructed and destructed
only by the state machine. It would therefore be possible to use the
state_machine<> allocator instead of forcing the user to overload operator
new() and operator delete(). However, a lot of systems employ at most one
instance of a particular state machine, which means that a) there is at most
one object of a particular state and b) this object is always constructed,
accessed and destructed by one and the same thread. We can exploit these
facts in a much simpler (and faster) new/delete implementation (for example,
see UniqueObject.hpp in the BitMachine example). However, this is only
possible as long as we have the freedom to customize memory management for
state classes separately.
</rationale quote>
Building a pool allocator into state_machine<> or even using the one that
the user can pass would mean to needlessly throw away some opportunities for
optimization. The user has to make that decision.
> Don't forget, though, that part of my proposal was that state
> objects would have enter() and exit() mfs rather than relying on
> the ctor and dtor for entry and exit, respectively. That can
> simplify matters when dealing with exceptions.
The longer I think about it the more am I convinced that separate entry()
and exit() functions don't buy you anything w.r.t to exception handling (see
my discussion with Dave).
Regards,
Andreas