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

Subject: Re: [Boost-users] [multi state machine/ MSM] execute_queued_events
From: Manuel Schiller (caligano_at_[hidden])
Date: 2014-09-24 07:31:55

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_at_[hidden]>:

> >
> > 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_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>