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