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]>
>> 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
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.
-- AgustÃn K-ballo BergÃ©.- http://talesofcpp.fusionfenix.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk