[boost] Common future base class (was Re: Boost.Fiber mini-review September 4-13)

Le 05/09/15 00:32, Giovanni Piero Deretta a écrit :

On 4 Sep 2015 8:09 pm, "Oliver Kowalke" wrote:

...

2015-09-04 21:14 GMT+02:00 Thomas Heller :

Could you please elaborate a bit why non-allocating futures wouldn't

...

require a mutex? Or more generally, a execution context suspension/yield mechanism?

I mean no std::mutex (pthread_mutex) is required. a protocol, utilizing atomics, between future and promise does the job - http://blog.forecode.com/2012/05/23/a-non-allocating-stdfuturepromise/ in 'void promise::set_value(R && r)' boost::this_fiber::yield() could be used, if the future is not ready yet (e.g. AS(future->state, 0, 'R') fails). That's not really what I meant though.

I believe that a future can be implemented efficiently without any internal mutex or condition variable (which would relegated only to the wait side). A spin lock might be needed to implement a tiny critical session in 'then' or 'wait' for shared_futures, but that's it. Such a future would work well as the underlying implementation for boost::thread::future or boost::fiber::future, which would only need to override the wait implementation and would still allow both futures to interoperate.

My suggestion is to convince Vicente to implement such functionality in Boost.Thread.

Hi Giovanni, boost::future has a lot of design issues. I will welcome and base class from which boost::future can inherit as it is quite difficult to maintain it by myself :(. I'm a little bit skeptical about the approach, but who knows. Note that boost::future and boost::thread have some interactions (at thead exit family functions) that need to be taken in account I believe that Adrey Semashev intent with Boost.Sync was more or less that, but I maybe wrong. I don't know where he is with his library. Best, Vicente P.S. to the HPC people on this list. When we could expect to see the work on HPX moved to Boost?