Boost Users :
Subject: Re: [Boost-users] [multi state machine/ MSM] execute_queued_events
From: Hickman, Steve (AdvTech) (Steve.Hickman_at_[hidden])
Date: 2015-01-23 11:57:30
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_at_[hidden] [mailto:christophe.j.henry_at_[hidden]] Sent: Monday, September 22, 2014 12:21 PM To: boost-users_at_[hidden] 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
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net