Boost logo

Boost :

Subject: Re: [boost] Synchronization (RE: [compute] review)
From: Gruenke,Matt (mgruenke_at_[hidden])
Date: 2014-12-28 21:16:27

-----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.



This e-mail contains privileged and confidential information intended for the use of the addressees named above. If you are not the intended recipient of this e-mail, you are hereby notified that you must not disseminate, copy or take any action in respect of any information contained in it. If you have received this e-mail in error, please notify the sender immediately by e-mail and immediately destroy this e-mail and its attachments.

Boost list run by bdawes at, gregod at, cpdaniel at, john at