On Sun, Dec 28, 2014 at 6:16 PM, Gruenke,Matt
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Kyle Lutz Sent: Sunday, December 28, 2014 20:36 To: boost@lists.boost.org 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