...

Depending on how you use it, yes. I'm a bit worried with race conditions in case your state machine is also used in another thread, which would also call process_event.

Yes, I protect every call to process_event with a mutex. Since I don't have that many events I have created a member function that wraps and protects the process_event call. (One member function per event.)

Usually, the destructor gets tricky. Not only, but this one is hard to get right.

...

Alternatively (if you want to avoid locking/deadlocking/rc), you could also move the worker thread out of the fsm and have both communicate with synchronized message queues. You might want to have a look at boost::circular_buffer, which provides an example (http://www.boost.org/doc/libs/1_46_1/libs/circular_buffer/doc/circular_buffe...).

Yes, that is an interesting idea. But how do you solve the problem with passing events on to the message queue? The events are all of different types. Do you mean that there should be some parsing of strings or some other identifier?

You can make a circular buffer of, say, boost::function<void()>, this allows you to anonymize functors, for example this can be assigned into this boost::function: template <class Fsm, class Event> struct process_some_event { process_some_event(Fsm* fsm): fsm_(fsm){} void operator()() { fsm_->process_event(Event()); } Fsm* fsm_; }; Or as a variant, you can make a boost::function<void(my_fsm&)> with the corresponding operator(). Whatever fits better in your case. Regards, Christophe