Quantcast

Boost MSM parallel behavior with delayed self-transitions?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Boost MSM parallel behavior with delayed self-transitions?

Boost - Dev mailing list
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Boost MSM parallel behavior with delayed self-transitions?

Boost - Dev mailing list
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

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 <
[hidden email]> 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
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Boost MSM parallel behavior with delayed self-transitions?

Boost - Dev mailing list
>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-from-a-custom-function-not-an-action-inside-a-sta/42949021?noredirect=1#comment72995089_42949021>
>
>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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Boost MSM parallel behavior with delayed self-transitions?

Boost - Dev mailing list
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 <
[hidden email]> 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-from-a-custom-function-not-an-action-inside-a-sta/42949021?noredirect=1#comment72995089_42949021>
> >
> >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
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Boost MSM parallel behavior with delayed self-transitions?

Boost - Dev mailing list
Hi Danylo,
>
>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.

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Loading...