Boost logo

Boost :

Subject: Re: [boost] Synchronization (RE: [compute] review)
From: Kyle Lutz (kyle.r.lutz_at_[hidden])
Date: 2014-12-30 23:19:45


On Tue, Dec 30, 2014 at 5:31 PM, Gruenke,Matt <mgruenke_at_[hidden]> wrote:
> Let's take another look at the big picture.
>
> In its current form, the high-level interface of Boost.Compute has safe (if overkill) synchronization with host datastructures. There's currently insufficient synchronization of device containers. Finally, the low level interface lacks the RAII objects needed to facilitate exception-safe code.
>
>
> In this thread, we've proposed:
>
> 1. Host memory containers, as a synchronization *optimization* of high-level operations involving host memory. This seems similar to the approach employed by SYCL (thanks to Peter Dimov).
>
> 2. You suggested device containers & their iterators could have the machinery to make them exception-safe. This could take the form of either refcounting, or synchronization.
>
> 3. RAII wrappers for events and wait_lists.
>
>
> Remember, if Kyle simply adopts #2, then regardless of the status of #1, I believe the high-level interface will be safe. So, there should be no need to use #3 with high-level operations.
>
> Considering the above, the existing synchronization behavior of command_queue, and the ordering dependency you mentioned (i.e. that all datastructures would need to be in scope before the guarantee on the command_queue), I conclude that it's not necessary and actually too error-prone to synchronize at the command_queue level.
>
> And regarding wait_lists, the reason I agreed with your suggestion to offer guarantees for them is that they're the primary mechanism for defining command execution order. Since I think most code using the low level interface will probably be using wait_lists anyhow, there's an undeniable convenience to offering guarantees at that level.
>
>
> As far as I'm aware, Kyle has expressed casual interest in supporting #1 (but not forcing it, presumably because this would break the nice iterator interface that many people like). I don't know where he stands on #2. And he's agreed to seriously consider #3 (in the form of a patch I've offered to submit).
>
> I think we should focus on #2. I'd really like to know his stance on it.

First off, I'd just like to thank you guys for bringing this issue up
and actually proposing solutions. Currently I'm leaning towards
solution #2 as well but I'll need some more time to think all of this
over. Also, solution #3 is the least-intrusive and could also suit
other use-cases so I think it would be worthwhile to pursue.

-kyle


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk