Boost logo

Boost :

Subject: Re: [boost] Synchronization (RE: [compute] review)
From: Gruenke,Matt (mgruenke_at_[hidden])
Date: 2014-12-29 18:56:19

-----Original Message-----
From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Thomas M
Sent: December 29, 2014 16:20
To: boost_at_[hidden]
Subject: Re: [boost] Synchronization (RE: [compute] review)

> If input/output ranges generally refer to iterators from the boost::compute library, then:
> -) an iterator can store the container (or other data structure it belongs to, if any)
> -) an algorithm can, via the iterators, "communicate" with the container(s)
> For an input operation the data must be available throughout & in unaltered manner from
> the time of enqueuing the input operation until its >completion.

Essentially, what I think you want is to embed the equivalent of a shared_ptr to the underlying storage. Event callbacks could be used to decrement it, when the operation has completed. That way, even if the container object is deleted, the device memory sticks around so long as any pending operations reference it.

For host data structures, it'd be nice if they could be restricted to iterators of a special container - let's call it host_mem<>, for the sake of discussion. Unlike mapped_view<>, you could only copy into it, so that it owns the memory. Reads & destruction could block on any pending operations that have been enqueued with it as a destination.

If you don't want to pay the penalty of copying into a host_mem<> object, then just do an explicit command_queue::enqueue_write_buffer() or command_queue::enqueue_write_buffer_async(). Another benefit of requiring host_mem<> is that the host -> host copy is explicit.

BTW, for command_queue-level operations, Kyle seems to agree with my proposal to have a sort of guard object that calls event::wait(), upon destruction. I actually wonder if it makes sense to call this a 'guarantee', since it doesn't quite behave like traditional guard objects. He's even accepted my offer to code this up.



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