Boost MSM parallel behavior with delayed self-transitions?
Hi Danylo,
Hi Christophe,
Thanks for your input. I'm going to use std::thread for the parallel functionality, I think.
it will work with synchronization. For simple cases it's manageable.
How stable/complete is Asynchronous? Can I rely on it, or would I still have a moderate chance of running into bugs?
It's very stable and used intensively in production code (in the industry) since 2 years. You might find some bug of course, but no stability problem has been found since a long time.
Best,
Danylo.
PS. I love your documentation! What do you use for state machine diagrams - MagicDraw?
Enterprise Architect. Regards, Christophe
Christophe, Thanks for the knowledge. It would be nice if you could give your opinion on this question of mine regarding calling process_event from inside a thread: http://stackoverflow.com/questions/42941228/boost-msm-call-process-event-fro... I'd like to know if what Takatoshi Kondo answered is really the only way to achieve the result, or if maybe there is a cleaner and more straight forward approach. Best, Danylo. On Wed, Mar 22, 2017 at 1:18 PM, Christophe Henry via Boost < boost@lists.boost.org> wrote:
Hi Danylo,
Hi Christophe,
Thanks for your input. I'm going to use std::thread for the parallel functionality, I think.
it will work with synchronization. For simple cases it's manageable.
How stable/complete is Asynchronous? Can I rely on it, or would I still have a moderate chance of running into bugs?
It's very stable and used intensively in production code (in the industry) since 2 years. You might find some bug of course, but no stability problem has been found since a long time.
Best,
Danylo.
PS. I love your documentation! What do you use for state machine diagrams
-
MagicDraw?
Enterprise Architect.
Regards, Christophe
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost
Christophe,
Thanks for the knowledge. It would be nice if you could give your opinion on this question of mine regarding calling process_event from inside a thread:
http://stackoverflow.com/questions/42941228/boost-msm- call-process-event-from-a-custom-function-not-an-action- inside-a-sta/42949021?noredirect=1#comment72995089_42949021 http://stackoverflow.com/questions/42941228/boost-msm-call-process-event-fro...
I'd like to know if what Takatoshi Kondo answered is really the only way to achieve the result, or if maybe there is a cleaner and more straight forward approach.
Best,
Danylo.
Hi Danylo, I think he's mostly right, the self-join is the problem. Your timer thread should not call anything which will join itself. I'm also afraid your options are limited, exception or resource leak, none of them appeals to me. I'll also add that the code is still wrong. stop_threads_ should not be bool but atomic<bool> or mutexed. As it is now, it might work by luck on some compilers and will fail on others because of optimizations. Frankly, this is the point where you might want to pause, step back and realize that no, it is not that easy and when your code grows, you'll be debugging for ever. This kind of code is simply hard if not impossible to maintain. With your permission, I'd even want to add it to the doc of Asynchronous to show why the library is needed. I would never manage to come up with such a good example myself. I suggest you again to have a look at Asynchronous. For example: https://github.com/henry-ch/asynchronous/blob/master/libs/asynchronous/doc/e... Now imagine that your Servant would be a state machine, all you'd need would be to call async_wait and enjoy having saved yourself quite some debugging time. Regards, Christophe
Hi Christophe, Thank you for the input. As you suggest, I've put on pause trying to achieve parallelism with pthreads/std::thread and will have a serious look into Asynchronous. To be sure: you are saying that Asynchronous+MSM is able to fulfill my objective of having a state machine with states that execute tasks in parallel (in the multi-thread sense) and that can be exited (i.e. threads closed) in response to MSM events (process_event)? If so, then it makes sense for me to read all of the documentation. Please feel free to use the example in the Asynchronous doc, it would be my honor! Best, Danylo. On Thu, Mar 23, 2017 at 1:11 PM, Christophe Henry < christophe.j.henry@gmail.com> wrote:
Christophe,
Thanks for the knowledge. It would be nice if you could give your opinion on this question of mine regarding calling process_event from inside a thread:
http://stackoverflow.com/questions/42941228/boost-msm-call- process-event-from-a-custom-function-not-an-action-inside- a-sta/42949021?noredirect=1#comment72995089_42949021 http://stackoverflow.com/questions/42941228/boost-msm-call-process-event-fro...
I'd like to know if what Takatoshi Kondo answered is really the only way to achieve the result, or if maybe there is a cleaner and more straight forward approach.
Best,
Danylo.
Hi Danylo,
I think he's mostly right, the self-join is the problem. Your timer thread should not call anything which will join itself. I'm also afraid your options are limited, exception or resource leak, none of them appeals to me. I'll also add that the code is still wrong. stop_threads_ should not be bool but atomic<bool> or mutexed. As it is now, it might work by luck on some compilers and will fail on others because of optimizations.
Frankly, this is the point where you might want to pause, step back and realize that no, it is not that easy and when your code grows, you'll be debugging for ever. This kind of code is simply hard if not impossible to maintain. With your permission, I'd even want to add it to the doc of Asynchronous to show why the library is needed. I would never manage to come up with such a good example myself.
I suggest you again to have a look at Asynchronous. For example: https://github.com/henry-ch/asynchronous/blob/master/libs/ asynchronous/doc/examples/example_asio_deadline_timer.cpp
Now imagine that your Servant would be a state machine, all you'd need would be to call async_wait and enjoy having saved yourself quite some debugging time.
Regards, Christophe
Hi Danylo,
Thank you for the input. As you suggest, I've put on pause trying to
To be sure: you are saying that Asynchronous+MSM is able to fulfill my objective of having a state machine with states that execute tasks in
achieve parallelism with pthreads/std::thread and will have a serious look into Asynchronous. parallel
(in the multi-thread sense) and that can be exited (i.e. threads closed) in response to MSM events (process_event)? If so, then it makes sense for me to read all of the documentation.
Yes. You'll have a state machine as servant. To execute tasks in parallel and as state machines should not block, you will have transition actions calling post_callback, or, if needing a timer, async_wait. You needn't care about closing threads, the library takes care of that. BTW at my work, we base our whole industrial application on this (and we are 20 developers). It really works.
Please feel free to use the example in the Asynchronous doc, it would be my honor!
Great! Thanks!
Best,
Danylo. Regards, Christophe
participants (2)
-
Christophe Henry -
Danylo Malyuta