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

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;
>>>      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.: [phone]
Fax:  [phone]
Email: thomas.heller_at_[hidden]