[boost] Re: Some questions on the FSM submission

From: Andreas Huber (ah2003_at_[hidden])
Date: 2003-06-04 14:59:26

Chris Russell wrote:
> 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.

I'm delighted to hear that you want to use the library in a real-world
project but I must also warn you: You'd be the first to do so!
Intel should be quite conformant but I wouldn't be surprised if you
encounter non-trivial problems. I started out developing on MSVC7.0 and
MSVC7.1 but I had to drop 7.0 because it caused too many problems.

Please do not hesitate to contact me if I can be of any help!

> 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.

BTW, I assume you are going to pass fsm::event subclass objects between
threads. fsm::event is intrusively reference counted and already does the
necessary locking when you use boost::intrusive_ptr. However, nobody else
has reviewed the locking for potential race-conditions and the like (as
should be done with all multithreading code). If you want to be on the safe
side you can use boost::shared_ptr, but can then no longer use event
deferral (see also Event deferral chapter in the tutorial).

> 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

I think there's little I can do. When it comes to inter-FSM communication,
one needs to make sure that a) the FSM event queue is absolutely
bullet-proof regarding MT, b) FSMs commuicate with events only and c) the
events will never contain references and pointers to data that is
simultaneously accessed by multiple FSMs.

As a library writer I can only influence a), which is tricky to get right
but definitely not rocket-science. The rest lies in the hands of the users.

> 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.

Thanks, I will have a look...

> 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.

I'll get in touch with Scott regarding SDL...

Thanks very much for your feedback, I'm looking forward to hear about your
Intel porting experiences.

Regards,

Andreas