Re: [boost] Asynchronous library now in Boost Library Incubator

Subject: Re: [boost] Asynchronous library now in Boost Library Incubator
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2016-12-06 10:44:43

On Dienstag, 6. Dezember 2016 15:55:14 CET you wrote:
> On Dienstag, 6. Dezember 2016 15:44:39 CET you wrote:
> > On Donnerstag, 1. Dezember 2016 21:45:52 CET Christophe Henry wrote:
> > > <snip>
> > > 
> > > > I didn't quite understand the state machine explanation - but I'll
> > > > continue looking through the boost.asynchronous material until I am
> > > > happier.
> > > 
> > > I tried to add an example and the underlying rationale
> > > (https://htmlpreview.github.io/?https://github.com/henry-ch/asynchronous
> > > /b
> > > lo b/master/libs/asynchronous/doc/asynchronous.html#d0e6437).
> > > 
> > > The Manager is a very simplified state machine but I hope you get the
> > > idea.
> > 
> > When looking at the example code, doesn't it contain a race on
> > Manager::needs_second_task member. If not, how is it avoided?
> 
> So in this example, the race is avoided because it uses a single thread
> scheduler as the "thread world", right? What happens if I'd change it to run
> on multiple threads?

Just out of curiosity, I implemented your example just with executors and 
future::then:
https://gist.github.com/sithhell/42eec1e183df206556086cfbf20918ac

 Granted, it doesn't bind the lifetime of the manager to the object, but that 
should be a trivial, for example with an intrusive pointer instead of raw this 
in the continuations. And it misses the proxy object which
could be implemented to hide this lifetime tracking in a similar way that 
boost.async, although, the destructor of the executor waits until all threads 
have been processed (implicitly keeping the object alive long enough). Other 
than that, it has the same race freedom guarantees, due to only ever 
manipulating the object on a single thread of execution. It only blocks on the 
future returned from start(). The location on where to execute the callback/
continuation is fixed. The "thread world" is defined by the executor, which is a 
very generic and powerful abstraction and properly aligned with the current 
development in the C++ Standards Committee. The layered example can be done in 
a similar fashion, each object containing its own executor.
What do you think?

> 
> > > Cheers,
> > > Christophe
> > > 
> > > _______________________________________________
> > > Unsubscribe & other changes:
> > > http://lists.boost.org/mailman/listinfo.cgi/boost