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

Subject: Re: [boost] Synchronization (RE: [compute] review)
From: Gruenke,Matt (mgruenke_at_[hidden])
Date: 2014-12-30 20:31:46

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.

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.