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. 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)? 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. Would asynchronous_state-machine provide a preformance benfit in this case? Would it be an adequat solution to queue the events from the three event sources in a thread-safe queue (producer-consumer pattern)? The threads providing events act as producer threads) and should not be blocked and the processing of the events (calling state_machine::process_event()) will be done snychronous (maybe by one consumer thread). Regards,Oliver