Re: [boost] Synchronization (RE: [compute] review)

Subject: Re: [boost] Synchronization (RE: [compute] review)
From: Kyle Lutz (kyle.r.lutz_at_[hidden])
Date: 2014-12-28 21:23:33

On Sun, Dec 28, 2014 at 6:16 PM, Gruenke,Matt <mgruenke_at_[hidden]> wrote:
> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Kyle Lutz
> Sent: Sunday, December 28, 2014 20:36
> To: boost_at_[hidden] List
> Subject: Re: [boost] Synchronization (RE: [compute] review)
>
>> On Sun, Dec 28, 2014 at 4:46 PM, Gruenke,Matt wrote:
>
>>> My understanding, based on comments you've made to other reviewers, is
>>> that functions like boost::compute::transform() are asynchronous when
>>> the result is on the device, but block when the result is on the host.
>>> This is what I'm concerned about.  Is it true?
>
>> Yes this is correct. In general, algorithms like transform() are asynchronous
>> when the input/output ranges are both on the device and synchronous when one
>> of the ranges is on the host. I'll work on better ways to allow asynchrony in
>> the latter case. One of my current ideas is add asynchronous memory-mapping
>> support to the mapped_view class [1] which can then be used with any of the
>> algorithms in an asynchronous fashion.
>
> Why block when only the source is on the host?  Are you worried it might go out of scope?
>
> If so, that's actually not a bad point.  I was just pondering how to write exception-safe code using local host datastructures.  I guess blocking on all operations involving them is a simple way to ensure nothing is read or written after it's out of scope.  Not the only way that comes to mind (nor the most efficient), but it does the job.

Yes, that is one of the major motivations. Avoiding potential
race-conditions with host code accessing the memory at the same time
is another. I'd be very open to other solutions.

-kyle