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

Subject: Re: [boost] Synchronization (RE: [compute] review)
From: Rob Stewart (rob.stewart_at_[hidden])
Date: 2014-12-31 05:10:55

On December 31, 2014 3:15:10 AM EST, "Gruenke,Matt" <mgruenke_at_[hidden]> wrote:
> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Thomas
> M
> 
> > With respect to the command_queue "guarantee" I keep my opinion that
> I
> > consider it absolutely useful; I also don't see why it's more
> error-prone
> > in general (see below).
> 
> It's error-prone, because the guarantee must have a smaller scope than
> all of the containers it's intended to protect.  You can't just
> instantiate new containers as you need them.  That type of usage error
> isn't possible with event guarantees.
> 
> You're correct to point out that this applies equally to wait_list
> guarantees.  Hence, I am withdrawing my support for them.

What if the guarantees were part of the construct in use and only registered or lifetime-managed objects can be used with it? By that I mean that of you want synchronization, then you create a synchronizing command queue our wait list. If you want to use host memory with it, the API requires a host memory object that was previously registered with the queue/wait list or a special host memory object with a ref count the queue/wait list can increment.

The point is to have an interface that enforces correct lifetime management rather than relying on the user to remember to do certain things in a certain order.

Another thought is to get the guarantee from the queue/wait list and then pass it to constructors and APIs that should be protected. That doesn't preclude using unprotected objects and calls unless the queue/wait list can verify that it's guarantee object was used to create the object handed to it or on the API call invoked on it whenever there is an extant guarantee object.

___
Rob

(Sent from my portable computation engine)