Re: [Boost-users] [multi state machine/ MSM] execute_queued_events

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