May I ask what is your use case? Do you have a thread enqueuing events and another executing of several threads doing both?
[*] I haven't started using queued events yet, but if I do it will be with multiple threads enqueuing events. In the long run, I would probably have just a single thread processing the event queue (since queuing theory says that is always the best approach). However, there may be a transition period switching from process_event to queued events where the (multiple) threads queuing the events are also processing them.
I ask because I'm working on C++11 MSMv3 (msm3 branch on github) and I have an unfinished but promising implementation of a lockfree msm which is much faster than locking. It works only on simple fsms at the moment (no submachine and no pseudo entry/exit). It works this way: all threads process events, call guards and actions concurrently. In case a thread notices at the time of switching the current state (which is only a check of an atomic), it will roll back and retry. It's a bit advanced fsm building but if you feel like trying, there are some tests showing how to do and I'm ready to help. I ask your use case because it works best when a thread processes most of the events and one only from time to time.
[*] My case would be where most of the events are queued by a 'main' thread, with only occasional event queuing from other threads. So it might be appropriate. What's the URL? A brief search on Github didn't get me to the right repository.
HTH, Christophe
--- Steve H.