Boost logo

Boost :

Subject: Re: [boost] [MSM] Interrupt anonymous transitions or blocking process_events?
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2011-04-23 15:50:35


>> Depending on how you use it, yes. I'm a bit worried with race
>> conditions in case your state machine is also used in another thread,
>> which would also call process_event.
>
> Yes, I protect every call to process_event with a mutex. Since I don't
> have that many events I have created a member function that wraps and
> protects the process_event call. (One member function per event.)

Usually, the destructor gets tricky. Not only, but this one is hard to
get right.

>> Alternatively (if you want to avoid locking/deadlocking/rc), you could
>> also move the worker thread out of the fsm and have both communicate
>> with synchronized message queues. You might want to have a look at
>> boost::circular_buffer, which provides an example
>> (http://www.boost.org/doc/libs/1_46_1/libs/circular_buffer/doc/circular_buffer.html#boundedbuffer).
>
> Yes, that is an interesting idea. But how do you solve the problem with
> passing events on to the message queue? The events are all of different
> types. Do you mean that there should be some parsing of strings or some
> other identifier?

You can make a circular buffer of, say, boost::function<void()>, this
allows you to anonymize functors, for example this can be assigned
into this boost::function:
template <class Fsm, class Event>
struct process_some_event
{
   process_some_event(Fsm* fsm): fsm_(fsm){}
   void operator()()
   {
      fsm_->process_event(Event());
   }
   Fsm* fsm_;
};

Or as a variant, you can make a boost::function<void(my_fsm&)> with
the corresponding operator(). Whatever fits better in your case.

Regards,
Christophe


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk