Re: [Boost-users] Fw: State machine framework with dynamic configurability

From: Andreas Huber (ahd6974-spamgroupstrap_at_[hidden])
Date: 2005-07-07 04:58:56

Dave wrote:
> the FAQ illustrates how to modify the existing layout of an FSM, but I
> doubt whether it would be possible to implement the main FSM in the
> main exe and then dynamically load dlls to add inner/sub-states to
> existing states; since the state transition/reactions have to be
> specified as template parameters.

Why do you think that the transition/reaction specification interface is a 
problem? The FAQ item shows that you can have a base FSM that uses a virtual 
function to delay the decision where to transit from a given state (Idle) when 
a specific event occurs (EvStart). The base FSM (PumpBase) would be compiled 
into the main exe. If you want to modify the behavior in a dll, all you need 
to do is to derive from the base FSM and inside the virtual function override 
you transit to the desired state.
Of course, for all this to work the main exe would need to have a means of 
constructing an object of the derived class (MyPump) that was loaded from the 
dll. This is easy enough to do with a factory.

>> Out of curiosity: Would you care to describe what kind of
>> application you need such a library for? 
> 
> This is probably off-topic for this ng but I'll provide my reasons so
> you can decide if they're reasonable or not.
> 
> The application I mentioned original post is a call control
> application, in fact several of them. (Naturally each application is
> maintained by a group of developers) Each of the applications has a
> flat Fsm with many states. My goal is to design a framework that has a
> main Fsm that is common to all the call control applications (with
> points of customization pre-defined) and then dynamically load DLLs to
> customize the behavior (by adding inner/sub-states) of the Fsm. The
> obvious advantage of doing so would be code reuse.

All this should be possible with Boost.Statechart, see above.

> Another reason to
> do so is that if a customization for a specific customer is needed
> (say add a few states to the fsm), only a few DLLs need to be
> modified/added, whereas in the existing design the main application
> has to be modified and recompiled. In this way the customization may
> be done by a developer who does not have full access to the source
> code/statechart, all he/she needs to know is the interface of the
> "point of customization".

Exactly.

> Dynamic configurabliity aside, the application I'm working on is a
> call control application, so I only need one instance of the state
> machine, one instance of each state and use context objects to store
> state information for each call. 

Maybe there's just a terminology misunderstanding but I don't see the benefit 
of the context object. In fact, the use of a context object here looks like a 
common antipattern, a "winnebago" object (stolen from Jeff Garland). You'll 
find more on this here (search for the first occurrence of "heuristic" and 
read what follows):

http://lists.boost.org/MailArchives/boost/msg79540.php

> When I skimmed through the statechart
> tutorial I see that the "Entry" and "Exit" functions are implemented
> using the constructor and destructor of the simple_state class, so I
> suppose that each state object is constructed when entered and
> destructed when exited.

Exactly. This mechanism allows multiple developers to work on the same state 
machine without even knowing of each other. Very often you need additional 
variables (counters, etc.) that are associated with a state or a group of 
states. A developer working on a part of the machine can then simply add such 
a variable to an appropriate state class and never needs to modify a global 
context class or the state machine class.

> I'm not sure.. if a state is entered and
> exited repeatedly, say in the stopwatch example, whether the object
> construction/destruction incurs an unecessary cost. If I'm wrong,
> please correct me.

That really depends on your application. If you have small flat fsms with no 
or little additional context associated with states then this cost can be 
prohibitive indeed. From what you have described so far this is not the case 
in your application. I don't think the construction/destruction overhead will 
be noticeable in your app, given that there is a lot of network communication 
involved (I assume). BTW, you can easily customize memory management to cut 
down the new/delete overhead.

HTH & Regards,

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