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

Subject: Re: [boost] Synchronization (RE: [compute] review)
From: Gruenke,Matt (mgruenke_at_[hidden])
Date: 2014-12-28 22:40:47

-----Original Message-----
From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Kyle Lutz
Sent: Sunday, December 28, 2014 21:24
To: boost_at_[hidden] List
Subject: Re: [boost] Synchronization (RE: [compute] review)

>On Sun, Dec 28, 2014 at 6:16 PM, Gruenke,Matt wrote:

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

I have some rough ideas, but they'd probably have a deeper impact on your API than you want, at this stage.

Instead, I'm thinking mostly about how to make exception-safe use of the async copy commands to/from host memory.  I think async copies will quickly gain popularity with advanced users, and will probably be one of the top optimization tips.

I guess it'd be nice to have a scope guard that blocks on boost::compute::event.

    std::vector<int> hv(16000000);
    std::generate(hv.begin(), hv.end(), rand);
    boost::compute::vector<float> dv(host_vector.size(), context);
    boost::compute::guard wg(cq.enqueue_write_buffer_async(dv, 0, hv.size(), &hv.front());

    // do some device -> device operations

    boost::compute::guard rg(cq.enqueue_read_buffer_async(dv, 0, hv.size(), &hv.front());

[Short names used for the sake of email.]

boost::compute::guard would do nothing more than hold a reference to the event and call boost::compute::event::wait(), upon destruction (if it contains a valid event, at that point).

So, if an exception is thrown after wg is constructed, then the stack unwind blocks on its completion (or failure).  Similarly, if the exception is thrown after rg, then the unwind blocks on both wg and rg.

Obviously, this example is somewhat artificial.  If the read were really the last operation in scope, then you could just use a synchronous copy.  But, I think one strong use case for async copies is to free up device memory for subsequent operations.  So, I might transfer something off, even if I'm not going to do anything with it, at that point.

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.