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-09-01 09:15:22

On 9/1/2015 9:35 AM, Giovanni Piero Deretta wrote:
> On 30 Aug 2015 10:04 pm, "Agustín K-ballo Bergé" <kaballo86_at_[hidden]>
> wrote:
>>
>> On 8/30/2015 5:06 PM, Niall Douglas wrote:
>>>
> [...]
>>> 7. future.wait() very rarely blocks in your use scenario i.e. most if
>>> not nearly all the time the future is ready. If you are blocking, the
>>> cost of any thread sleep will always dwarf the cost of any future.
>>
>>
>> `future::wait` should not be a concern, you just spawn a
> `condition_variable` and attach a fake continuation to the future that will
> wake it up. The cv will be stored in the thread stack, which is guaranteed
> to stay around since we will be sleeping. This allows the fake continuation
> to simply be `reference_wrapper`, for which you only need `sizeof(void*)`
> embedded storage. Since the (unique) future cannot be used concurrently
> with `wait`, there can only ever be at most one fake continuation.
>
> This is unfortunately not true. Std::future::wait is const, so, without an
> explicit prohibition, multiple threads can call it as long as no other non
> const function is concurrently called. This is possibly a defect of the
> standard.

Indeed, that is correct. I overlooked that detail, and would have to 
check my code if I weren't using a single implementation of waits for 
both `future` and `shared_future`.

>> The situation gets trickier for `wait_for/until`, where you need to remove
>> the fake continuation on a timeout without racing.
>>
>
> Also needed to implement wait any.

Once `wait` returns the shared-state is ready. You don't even need to 
remove the fake continuation pointer, it will never be looked up again.

 >  A dismissible, efficiently implementable
> 'then' protocol could be the key for future composition across libraries. I
> would prefer if in this case the continuation were pointer sized to allow
> lock free implementations.

I don't think pointer sized continuations would buy you anything, you 
can attach multiple continuations to a single shared-state (via 
`shared_future`) so you will always end up needing memory allocation 
eventually. That doesn't stop you from attaching the pointer to the 
continuation decayed-copy in a lock free way.

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