[boost] Re: Some questions on the FSM submission

From: Chris Russell (cdr_at_[hidden])
Date: 2003-06-04 15:42:20

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

It's been argued by many Venture Capitalists that there's absolutely nothing
real world about my project. But I digress ;-)

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

Only one way to find out.

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

Thanks - I will.

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

This sounds a little scary given my schedule. I'm going to try it anyway.
And if things get too out of control, then I'll fall back to something
simpler (i.e. nested case-statement FSM implementation) and come back to it
in several weeks when I've got more time.

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

I think there's a lot that we can do to codify this generically and satisfy
practical and aesthetic requirements. I'll hold my comments until I've
become familiar with your library design and spent some quality time staring
at William Kempf's boost::thread (I'm currently using a thread library I
wrote myself that is inferior to boost::thread but it does what I need and I
understand and trust it).

Thanks for all the hard work and inspiration Boosters!

- Chris