Re: [Boost-users] [statechart] Asynchronous Machines

From: Andreas Huber (ahd6974-spamgroupstrap_at_[hidden])
Date: 2006-02-22 05:12:59

David Greene <greened <at> obbligato.org> writes:
> > The fact that it's a weak_ptr is an implementation detail. You don't 
> > need to know that as a user.
> > Besides creation and destruction of FSMs, the fifo_scheduler interface 
> > only allows you to send events. So, the only means of data exchange is 
> > through callbacks and events (as outlined in the other post). It is not 
> > possible to access the state_machine subclass objects directly because 
> > that would mean accessing data shared between threads. This in turn 
> > would mean that every state_machine member function needs to be 
> > protected by mutexes, which is a recipe for disaster, in my experience.
> 
> I understand your reasoning, but it makes it _really_ difficult to
> incorporate Boost.Statechart into an existing application.  I'd have
> to create all kinds of callbacks and special events just to get some
> state out of the machine and make decisions based on that information.

Multi-threaded programming is difficult ;-). Seriously, I'm aware that the 
asychronous_state_machine & scheduler combo has a very restrictive interface, 
which somewhat enforces the event-based programming rule that accessing shared 
state from different threads is best avoided.

> It seems as though with asynchoronous machines, it's almost an
> all-or-nothing affair.  Either everything interacts via Boost.Statechart
> objects or there is quite a bit of painful interface code to coax
> out information when needed to drive some other piece of the
> application.

I do understand that there are scenarios where shared access is unavoidable, 
asynchronous_state_machine was simply not designed to support them. However, 
you can always use the thread-unsafe state_machine directly and appropriately 
protect it with mutextes.

> Hopefully I can get by with a synchronous state machine.  It's a
> very tiny piece of my application but it is the most critical
> piece.  Before it was lots of hand-written ugly code and I was
> hoping to formalize it with Boost.Statechart.  I think I can but
> it's just turned out to be more challenging than I thought.
> 
> I'm not meaning to bash your work.

No bashing taken. Maybe I should have documented the fact that the 
asynchronous part of the library only exists because there's currently no 
library in Boost that supports multi-threaded event-based programming. As such 
it pursues (and always will be) a minimal approach.

HTH & Regards,

-- 
Andreas Huber
When replying by private email, please remove the words spam and trap
from the address shown in the header.