Oliver.Kowalke@qimonda.com 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.