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

Subject: [boost] Common future base class (was Re: Boost.Fiber mini-review September 4-13)
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-09-04 18:56:37

Le 05/09/15 00:32, Giovanni Piero Deretta a écrit :
> On 4 Sep 2015 8:09 pm, "Oliver Kowalke" <oliver.kowalke_at_[hidden]> wrote:
>> 2015-09-04 21:14 GMT+02:00 Thomas Heller <thom.heller_at_[hidden]>:
>>
>> 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?