From: Andreas Huber (ah2003_at_[hidden])
Date: 2003-06-04 02:31:26
Chris Russell wrote:
> I read through the documentation but haven't tried coding against the
> library yet. It looks quite useful for building isolated FSM
> mechanisms. I observe in my own work that I typically have many FSM
> that interact with
> each other.
Yep, I think that's the case for almost all non-trivial programs using FSMs.
> It could be argued that this is really just one large
> FSM, but I like to think of them in terms of discrete FSM that
It is indeed sometimes beneficial to use orthogonal regions instead of
multiple FSMs, but only sometimes.
> interact with each other because it makes it easier to conceptualize
> class structure, threading, and occasionally inter-process or in the
> case of a distributed application, inter-system partitioning.
I absolutely agree.
> That being said, I have the following questions (note these are not
> criticisms of the library or even a formal review - I'm trying to
> understand how it fits into my own work to decide how much time to
> invest in it).
> If I understand the documentation correctly, the submission is geared
> more towards creating hermetically sealed FSM mechanisms than for
> describing multiple interacting FSM's. Is this correct?
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.
> Also, I have some need to deal formally with Petri Networks. Related
> to FSM and automata theory in general, has any thought been given to
> this class of FSA?
No. I know little about these subjects. Can you recommend any books?
> I'm not a big UML fan so this aspect of the submission troubles me a
> little. Do we have a lot of UML fans here? I would be happier if it
AFAICT, UML is the only internationally standardized modelling 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?
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk