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

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> reads; reads.reserve(100); 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 case is? 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.

...

Cheers - Asbjørn

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

-- 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@cs.fau.de