Re: [Boost-users] [statechart] : asynchronous_state_machine -accessmember functions

From: Oliver.Kowalke_at_[hidden]
Date: 2007-02-07 02:57:08

Hello 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?

My io-framework (sockets) requiers that the service handler is derived
from enable_shared_from_this and will be managed by an shared_ptr. This
service handler is invoked if a message is delivered over tne network
and implements a state machine  in order to process the network message
(communication protocol).
Because asynchronous_state_machine is created by
fifo_scheduler::create_processor it will not work with the io-framework.
I could split the class into a io service handler class which aggregates
a state_machine but this leads to other problems because I need a way to
call io sevice handler functions from several states of the fsm.

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

Why deadlocks? I protect the state machine with a mutex. So only one
thread has access to the state machine at the same time.
I believe that you use also a mutex in the fifo_scheduler in order to
synchronize access to the state machine -right?

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

Using sc::state_machine together with a multithreaded queue which stores
push operations (meaning sc::state_machine::process_event() invokations)
should also model your implementation. Producer threads put function
objects into the queue and one consumer thread dequeues the functions
objects and invokes operator() on the function object (which leads to
inserting an event into fsm via process_event()).
May this work?

Regards,
Oliver