Re: [boost] [msm] Review

Subject: Re: [boost] [msm] Review
From: David Bergman (David.Bergman_at_[hidden])
Date: 2009-12-05 19:30:30

On Dec 5, 2009, at 7:03 PM, Michael Caisse wrote:

> David Bergman wrote:
>> 
>> Repeating: the MSM/Statechart overlap in features and interface is quite unique to Boost. I argue that this is a bad thing. "You can never get too many goodies!" Well, I think you can. Is that situation bad enough not to be outweighed by the quite terrific design of MSM? Probably not, but I just wanted to raise the general question of duplicity (and redundancy), and also that of potentially deprecating libraries.
>> 
>>  
> 
> Back in the mid to late 90's I worked closely with a company called ObjecTime [1]. They
> were a telco spin-off that promoted a tool set and methodology called ROOM (Real-time
> Object Oriented Modeling). ROOM was very successful to the point that the ObjecTime/IBM's
> submission to OMG was about to be accepted as *the* real-time modeling language. Rational
> was distraught and quickly purchased a controlling stake of ObjecTime and integrated ROOM
> as the first release of UML for Real-time. 
> What does all of this have to do with MSM/Statechart overlap? Even ObjecTime saw that not all FSM implementation/designs are created equal. While the "front end" modeling concepts provided a rich language that we could apply to various problem domains, not all domains have the same design/implementation requirements. A profitable, resource-conscience company made the choice to provide multiple FSM libraries implementing the same modeling concepts because it made good sense. 
> I have my own graphical tool/code generator based heavily on ROOM and UML. I have considered
> SC and MSM as additional backend offerings to my own FSM libraries. SC is a non-starter for
> many of my (and my clients') targets with very small stack space. Constant creation/destruction
> of state objects makes me seriously question the viability of that approach for those targets.
> I have some small concern about the final build size of MSM; however, creating a machine
> in global space that is completely initialized on start-up fits perfectly with the
> requirements of those targets.
> 
> On the other hand, some of my targets running actual OS's with real amounts of memory create and destroy actors dynamically and perform various nifty dynamic port bindings that
> are much more in-line with a design/implementation utilizing virtual functions and inheritance.
> SC might be the perfect choice for these targets.
> 
> I have many other examples of why specifically different FSM's are appropriate for different
> targets... but this email is already much longer than I had intended. Interface variations
> make/break library adoption all the time. Design/implementation choices differentiate
> libraries for specific domains constantly. There is so much more than equivalent feature
> sets that make libraries "equivalent".

Heh, yes. I have probably used dozens of implementation of each "feature set" (regex, BNF, DFA, hash tables, other trees, graphs); but, here we are about to have two rivaling - for a lot of use cases - libraries filling the same purpose within our meta library. A clearly interesting situation. And, yes, the way to use Statechart and MSM are *much more* similar compared to Regex vs Xpressive :-) Look at my other post, containing a trivial state machine under both Statechart and MSM, and you will see that even from an interface POV, they are fairly similar. Implementation-wise they are quite different, as you noted. In fact, MSM is around six times faster than Statechart in almost all my sample scenarios, where Statechart, for instance, consumes a lot of time inside dynamic_cast. Well, I hope to remember all these points for my review of MSM :-)

/David