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

Subject: Re: [boost] Synchronization (RE: [compute] review)
From: Gruenke,Matt (mgruenke_at_[hidden])
Date: 2014-12-30 09:24:49

> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Peter Dimov
> Sent: Tuesday, December 30, 2014 8:57
> To: boost_at_[hidden]
> Subject: Re: [boost] Synchronization (RE: [compute] review)
>
> Thomas M wrote:
>
>> If you are going to implement such RAII guards here's a short
>> wish-list of features / guard classes:
>
> I don't know much about the subject, but I did look (quickly) at SYCL, and it
> appears to have taken lifetime issues into account, so maybe it would
> be worth it to see how it solves the problem.

They seem to use an approach similar to the host_mem<> container I suggested (sans copying):

  Memory objects can be constructed with or without attached host memory.
  If no host memory is attached at the point of construction, then destruction
  of that memory object is non-blocking.  The user can optionally provide a
  storage object which specifies the behaviour on construction and destruction
  (see Storage section 2.7.1 below).  If host memory is attached and the user
  does not supply a storage object, then the default behaviour is followed,
  which is that the destructor will block until any command groups operating
  on the memory object have completed, then, if the contents of the memory
  object is modified on a device those contents are copied back to host and
  only then does the destructor return.

The reason I like copying is that, if the memory is owned by the container, you can implement future<>-like blocking when there are pending writes to it.  Also, when copying into it, the data can be made contiguous.  But I suppose copying might be a high price to pay, for those benefits.

BTW, I only intended guarantees as a low-level mechanism.  It was always my belief that the high-level interface would best be served by a host_mem<> container and some form of protection (either blocking or refcounting) embedded in the device containers.

Matt

________________________________

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.