Re: [boost] [afio] Formal review of Boost.AFIO

Subject: Re: [boost] [afio] Formal review of Boost.AFIO
From: Agustín K-ballo Bergé (kaballo86_at_[hidden])
Date: 2015-08-31 15:21:18

On 8/31/2015 4:17 PM, Thomas Heller wrote:
> On 08/31/2015 06:53 PM, Niall Douglas wrote:
>> On 31 Aug 2015 at 16:50, Thomas Heller wrote:
>> None of those get wait() called on them, and therefore you very
>> rarely block. As an example, if you executed 1000 promise + future +
>> continuations but blocked on just one of those, my condition
>> "future.wait() very rarely blocks in your use scenario" is fulfilled
>> by virtue that future.wait() is simply never called.
>
> Looks like a problem with my english, sorry, I am not a native speaker.
> Let's see if I got it correct now: "Your code rarely calls
> future<T>::wait to avoid blocking because that is usually costly".
>
>  From my experience that holds true for any future implementation (be it
> based on OS synchronization primitives or user level context based
> synchronization), and is probably the number one reason why one would
> want something like future<T>::then, when_all and friends.
>
> So I take it that this requirement is nothing special to your
> lightweight futures.

My interpretation (which could of course be wrong) is that the 
"lightweight future" implementation of `wait` does busy-waiting because 
there is nowhere to store a `condition_variable`, so a spinlock is used 
instead. There is no technical reason for that to be the case.

A spinlock is still a perfectly adequate choice for a future 
implementation, given that there's very little concurrent access to the 
shared state. That doesn't rule out yielding the thread/cpu while 
waiting. An implementation could use a thread-local `condition_variable` 
and have the future point to it while it waits. This is not necessarily 
a good approach, but it is simple and should do as a proof of concept.

Again, I could just be misinterpreting things.

Regards,
-- 
Agustín K-ballo Bergé.-
http://talesofcpp.fusionfenix.com