Re: [boost] [msm] Async transition

Subject: Re: [boost] [msm] Async transition
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2010-08-26 16:14:19

> Thanks for your answer.
>
> It was in fact a question from my employer that asked if msm allows to
> do the same as the last example of the statechart doc :
> http://www.boost.org/doc/libs/1_44_0/libs/statechart/doc/tutorial.html
> (at the end of the page).

It depends. As the event processing function of msm is reentrant
thanks to the message queue, you have no risk in single threaded
programs.
In multithreaded programs, you will need to protect the access to process_event.

> It's not a requirement, just a technical question because from my
> understanding of UML, state regions should be managed separately and I
> thought maybe they were threaded in some way. We wanted to be sure of
> the whole behaviour before starting testing it.

What UML writes about regions is that they are "logically" concurrent,
meaning (IIUC) that they each get a chance to handle an event.
MSM is implemented this way, each region being called in turn (in the
order of the initial_state typedef).
Of course, doing this concurrently would speed up event processing at
the cost of predictability (if regions sent events to each other, you
could not know which is processed first).

> Anyway I see that I should treat the state machine like a STL
> component in regards to thread-safety and asynchronous event
> management.

Yes, I also tend to see it that way.

>As it's not a requirement, it's not a problem for me but I
> was asking myself if there would be an interest in having the event
> processing being thread-safe, allowing multiple threads to send
> events? Maybe like haveing a msm2 like signals2?
> I'm not experienced enough to see if it would be a good idea and I
> don't need it so it's just a theorical question.

As I don't see msm as a  library closed for changes, there is no need
for a msm2 yet ;-)
I'm working on the next version so if there is a need, I will happily
implement it.

I've been thinking about thread safety for a while but failed to see a
huge gain. I could replace:

lock() // whatever you need for locking
fsm.process_event(event());
unlock();

by:

fsm.process_event();

where process_event would lock at the beginning and unlock at the end,
but it seems pretty limited.
This leaves us with the valid use case of concurrent region processing.
I don't see any other yet, but I'd be interested if someone does as
it's a subject I'll want to handle of at some point.

Regards,

Christophe