Boost logo

Boost Users :

Subject: Re: [Boost-users] [multi state machine/ MSM] execute_queued_events
From: Hickman, Steve (AdvTech) (Steve.Hickman_at_[hidden])
Date: 2014-09-23 17:55:38


>
> 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 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