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