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

Subject: Re: [Boost-users] [multi state machine/ MSM] execute_queued_events
From: christophe.j.henry_at_[hidden]
Date: 2014-09-22 15:21:14

>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