Subject: Re: [boost] [afio] Formal review of Boost.AFIO
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2015-08-28 07:20:58
On 08/28/2015 11:30 AM, Thomas Heller wrote:
> On 08/28/2015 11:12 AM, Asbjørn wrote:
>> On 28.08.2015 07:47, Thomas Heller wrote:
>>> Now, on to your example about a 100 parallel reads, so let's
>>> encapsulate it a
>>> bit to concentrate on the important part:
>>> future<void> read_items(handle const & h)
>>> vector<future<vector<char>>> reads;
>>> for(std::size_t i = 0; i != 100; ++i)
>>> reads.push_back(async_read(h, 4096, i * 4096));
>>> // handle reads in some form ... for simplicity, just wait on all
>>> //of them ...
>>> return when_all(std::move(reads));
>>> No continuations, cool, eh?
>> How would this affect performance?
>> From what I can gather, with the current AFIO I should be able to issue
>> the entire batch of async read/write's to copy a file, using a single
>> buffer (by making a dependency chain using the preconditions).
>> In your API, won't those read/write calls have to take the trip into
>> user land for each step?
>> Sorry if I misunderstood something and this is just noise.
> It's actually 100% equivalent to what Niall posted. The performance
> should increase as you avoid synchronization with the shared state of
> the future holding the handle when attaching a continuation. The code in
> question actually does not make a dependency chain but generates a
> dependency tree with a depth of 2 where the future to the handle is at
> the root and the future to the reads are direct children to this root.
> What I've shown should actually make this clearer. read_items is
> attached as the continuation to the asynchronously opened handle.
One more remark: When creating dependency trees, once you have more than
one children on a specific node in the tree you have to use
shared_future, of course. However once that tree generates to a list of
dependencies, in one way or another, (unique) future is perfectly fine.
This however is not the decision of the library author providing the
asynchronous APIs, how could he/she possibly know what the specific use
Returning a (unique) future from anything that does asynchronous stuff
is therefor to be preferred! This also relaxes the need for
synchronization! A (unique) future is as thread safe as an int wrt get()
and friends (there still is some need for synchronizing with the async
result provider though), whereas a shared_future has to make sure to
synchronize with other async consumers sharing the same shared state.
>> - Asbjørn
>> Unsubscribe & other changes:
-- Thomas Heller Friedrich-Alexander-Universität Erlangen-Nürnberg Department Informatik - Lehrstuhl Rechnerarchitektur Martensstr. 3 91058 Erlangen Tel.: 09131/85-27018 Fax: 09131/85-27912 Email: thomas.heller_at_[hidden]