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

Subject: Re: [boost] Synchronization (RE: [compute] review)
From: Thomas M (firespot71_at_[hidden])
Date: 2014-12-31 12:11:12

On 31/12/2014 12:51, Thomas M wrote:
> Since there's a range of such interactions imaginable, with
> different preconditions, equally the tools offered shall provide some
> diversity. I am against forcing users to a single but clumpsy tool (an
> all-powered event-level guarantee) if the preconditions in a given
> application can be much more relaxed and something higher-leveled does
> the job as well.

Matt, here's an example when IMHO a plain event-level guarantee as only 
tool won't do it:

for (int i = 0; i < n; ++i)
{
   cq.enqueue_write_buffer_async(devmem[i], 0, size[i], host_ptr[i]);
}

If there's a true guarantee around the cq.enqueue_write_buffer_async:

for (int i = 0; i < n; ++i)
{
   boost::compute::guarantee 
guar(cq.enqueue_write_buffer_async(devmem[i], 0, size[i], host_ptr[i]));
}

then the asynchronous nature is totally lost (it blocks on every iteration).

If the guarantee can be "moved outside of the loop" to avoid the 
blocking, something like:

boost::compute::guarantee_list guarList;
for (int i = 0; i < n; ++i)
{
guarList.move_into(boost::compute::guarantee(cq.enqueue_write_buffer_async(devmem[i], 
0, size[i], host_ptr[i]));
}

then it's not a guarantee in your sense any more, because I can 
obviously also move it out to any improper scope loosing the protection.

The way to go for is a higher-level protection (e.g. wait on a wait_list 
/ command_queue); thus the asynchronous copy nature is kept at the 
user's responsibility to place the protection at an "appropriate" scope.

Thomas