Re: [Boost-users] [statechart] : asynchronous_state_machine -access member functions

From: Andreas Huber (ahd6974-spamgroupstrap_at_[hidden])
Date: 2007-02-06 19:45:13

Oliver.Kowalke_at_[hidden] wrote:
> Hi Andreas,
>
> Your solution will not work in my application. I use an io-framework
> which has some requirements that could not be fullfilled with the
> creation process of an asynchronous_state_machine.

Could you please expand on this?

> asynchronous_state_machine is derived from state_machine - does this
> mean that asynchronous_state_machine provides only a thread-safe
> access to state_machine (acts as a wrapper)?

This might be a little counter-intuitive, but asynchronous_state_machine 
itself is not thread-safe. It is the fifo_worker inside the 
fifo_scheduler that does all the locking and waiting. That's why you 
cannot create asynchronous_state_machine subclass objects yourself but 
must let fifo_scheduler create them for you.

> In my application I've three event sources (io-device, UNIX-signal
> handler, trigger which periodically produces events). Each event
> source runs in ist own thread. I could use a state_machine and
> synchronize the insertion of events (process_event() function) via a
> mutex.

That's bad practice performance-wise and can easily lead to deadlocks.

> Would asynchronous_state-machine provide a preformance benfit
> in this case?

Almost certainly. fifo_scheduler has an internal event queue and locks 
are only taken for push and pop operations. Events are processed outside 
locks, which improves performance.

> Would it be an adequat solution to queue the events from the three
> event sources in a thread-safe queue (producer-consumer pattern)?

See above, that's essentially the job of fifo-scheduler

Regards,

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