Ownership wrong term to describe relationship of host pointers and SYCL objects

[jpg85]

Description when passing raw pointers to SYCL runtime is misleading:

SYCL-Docs/latex/programming_interface.tex

Line 2148 in 8f8dd56

When using a SYCL buffer, the ownership of the pointer passed to the constructor

A developer coming from OpenCL will likely understand the correct behavior, but a developer coming from C++ will be misled. Specifically the default behavior is as follows:

• Data and state within the address space passed to the object is fully controlled by the SYCL runtime
• Lifetime of the data is still managed by the original owner of the memory
• Original owner only manages the lifetime and cannot legally view or modify the state of the data

This behavior is not the behavior implied by "the ownership of the pointer passed to the constructor of the class is, by default, passed to SYCL runtime". While the specification clarifies that "pointer cannot be used on the host side until the buffer or image is destroyed", it states nothing about lifetime management besides "memory pointed by host pointer will not be de-allocated by the runtime".

Furthermore, descriptor given throughout the specification simply states:
"The ownership of this memory is given to the constructed SYCL buffer for the duration of its lifetime". This is the same description given for both raw and smart pointers, further complicating the meaning:

SYCL-Docs/latex/programming_interface.tex

Line 1171 in 8f8dd56

Construct a SYCL \codeinline{buffer} instance with the \codeinline{hostData} parameter provided. The ownership of this memory is given to the constructed SYCL \codeinline{buffer} for the duration of its lifetime.

SYCL-Docs/latex/programming_interface.tex

Line 1215 in 8f8dd56

Construct a SYCL \codeinline{buffer} instance with the \codeinline{hostData} parameter provided. The ownership of this memory is given to the constructed SYCL \codeinline{buffer} for the duration of its lifetime.

Finally, the specification introduces something called "full ownership" which is really just ownership plus invalidation of any references to that data outside the SYCL runtime:

SYCL-Docs/latex/programming_interface.tex

Line 2168 in 8f8dd56

In the case where there is host memory to be used for initialization of data

Except in this instance, where "full ownership" is used differently:

SYCL-Docs/latex/programming_interface.tex

Line 2132 in 8f8dd56

In order to allow the \gls{sycl-runtime} to do memory management and allow

In C++, "ownership" of a pointer is in reference to lifetime. For example, unique_ptr:
https://en.cppreference.com/w/cpp/memory/unique_ptr/unique_ptr
"2) Constructs a std::unique_ptr which owns p"

Additionally, ownership implies nothing about control of the underlying data, which can still be referenced by other objects which have no control of the lifetime. Therefore, ownership is the wrong term to describe the behavior.

Note that the information is available to understand what is meant by the specification is available, specifically:

SYCL-Docs/latex/programming_interface.tex

Line 1534 in 8f8dd56

A buffer can be constructed with associated host memory and a default

SYCL-Docs/latex/programming_interface.tex

Line 2107 in 8f8dd56

For the lifetime of the image object, the associated host memory must

The problem is that one has to read the specification completely or be misled. The specification does a good job overall of describing the behavior, but misleadingly uses "ownership". Because ownership is a term that already has strong meaning within C++, it is misleading to use that term outside the standard meaning.

Another term should be used and that term specifically defined to avoid any confusion. "Data control", "management", or something else that doesn't already have a strong meaning in C++ would be appropriate.

[AerialMantis]

SYCL WG:

This should be clarified to differentiate between a buffer taking ownership in the case that the pointer is passed as a unique_ptr or shared_ptr with a single ref and a buffer taking responsibility for the memory, i.e. resulting in any modification or deallocation of the memory to be undefined behaviour.

[fraggamuffin]

Mar 24:

• wording fix needed by 2020

[fraggamuffin]

Still need wording fix for SYCL NEXT

[fraggamuffin]

@gmlueck if you have time, please come up with wording.

[keryell]

Actually not clear to me whether this can be a SYCL 2020 revision or for SYCL Next.