I've looked on GitHub and can't seem to find the version of MSM you refer to below. Can you send me a link (I think you did this once, but I can't seem to find it now). As to your question on my application: I'm considering several possibilities: 1) One or more threads enqueueing events and a separate thread running the state machine processing them. 2) Multiple cooperating state machines that may send events to each other. --- Steve H. -----Original Message----- From: christophe.j.henry@gmail.com [mailto:christophe.j.henry@gmail.com] Sent: Monday, September 22, 2014 12:21 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] [multi state machine/ MSM] execute_queued_events
In the MSM doc section "Enqueueing events for later processing", you state that "Calling execute_queued_events() will then process all enqueued events (in FIFO order)."
You also said in a previous post that MSM is not thread safe, thus requiring an external mechanism to insure thread safety.
True.
I don't see a mechanism to execute a single event at a time, which would be preferable if I have to lock the queue while processing events. Having said that, a cursory examination of the "execute_queued_events" code makes me think it only processes one event per call.
Looks like the implementation is wrong, I'll fix this and provide a second member for single event processing. May I ask what is your use case? Do you have a thread enqueuing events and another executing of several threads doing both? 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. HTH, Christophe