Hello Andreas, thanks for the detailed reply. [clip] > No, but you are right in your observation that there's currently not much > support for interacting FSMs. Most importantly, the current library is > single-threaded, there's no support yet for FSMs running in their own > threads. I made the current submission so that people can review the event > processor and the way how they can build FSMs, which IMO is the most > important part of an FSM library. Threading-support (and support for > inter-FSM communication) will follow as soon as I'm convinced that there are > no major problems with the current code. >
I understand. I need to design a state-based harness for a plug-in system and I'm going to use your FSM submission code and see how it goes. Likely the review will be over before I'm done, but at a minimum I will be able to give you feedback on how it works out with the Intel compiler. This plug-in subsystem has a fairly simple and well-defined synchronization model so the fact that the library doesn't explicitly deal with threading issues is fine - I'll take care of that NP. Parenthetically, when we do get around to talking about FSM, systems, and protocols (using Scott Wood's terminology), it would be good to solicit input and advice from William Kempf and Jeremy Siek. Referring back to a post I made here over a year ago (see [1]) I see FSM, threads, and BGL all working together to address these high level system/protocol design issues. More on that later. [1] Offlist and slightly over topic: Boost.Threads locking dilemma http://news.gmane.org/onethread.php?group=gmane.comp.lib.boost.devel&root=%3COE2389SfBkHqzX5Yrbj0000f875%40hotmail.com%3E [clip] >> ... Petri Networks > No. I know little about these subjects. Can you recommend any books? I've identified Petri Networks as something that I may be able to use to model (and hopefully simplify) some nasty sections of my code. I'm still trying to get a handle on the subject myself. I've found Petri Nets World http://www.daimi.au.dk/PetriNets/ to be a good source of information on the subject. Something to be aware of, but definitely beyond the scope of the current discussion. [clip] > AFAICT, UML is the only internationally standardized modeling language for > FSMs. However, I assume FSMs work more or less the same no matter what > graphical representation you use. I guess the only thing needed would be a > mapping from your preferred modeling language to boost::fsm. No? > Scott Woods pointed out SDL (an ITU coding standard?) and remarks that in his opinion, it does a better job of handling FSM systems than UML. I'm not familiar with SDL. Check Scott's post for more information. Thanks for the great submission and I'll post a write-up of my experiences working it into my plug-in subsystem later this month for your consideration. - Regards Chris Russell _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost