From: Chris Russell (cdr_at_[hidden])
Date: 2003-06-04 10:16:02
Hello Andreas, thanks for the detailed reply.
> 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
> 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 ) I see FSM, threads, and BGL all
working together to address these high level system/protocol design issues.
More on that later.
 Offlist and slightly over topic: Boost.Threads locking dilemma
>> ... 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
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk