Re: [boost] Boost.Fiber mini-review September 4-13

Subject: Re: [boost] Boost.Fiber mini-review September 4-13
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2015-09-04 18:32:01

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.
-- gpd