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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk