Hi, sorry for hijacking this thread, but I do have a very similar use case. I modeled the states of a simple network communication (implemented using boost::asio) using boost::msm. The states are: *Disconnected -> Connecting -> Idle -> Sending Message -> Waiting for Response -> Idle* I have multiple threads, which use this network communication to send messages. While the state "Waiting for Response" is active, I cannot send any further message. So when a thread wants to send a message, I enqueue this in a separate queue and I read this queue only when entering state "Idle". The reason for the separate queue is that the transition "Waiting for Response -> Idle" can only be triggered through the boost::asio read handler. Maybe this can be done easier with your new implementation? Thanks, Manuel 2014-09-23 23:55 GMT+02:00 Hickman, Steve (AdvTech) < Steve.Hickman@honeywell.com>:
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. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users