KhronosGroup / KhronosGroup/SYCL-Docs
Ownership wrong term to describe relationship of host pointers and SYCL objects
- Dominant language
- JavaScript
- Stars
- 158
- Forks
- 80
- Avg merge
- 7d 6h
- Merged PRs (30d)
- 5
Description
Description when passing raw pointers to SYCL runtime is misleading:
https://github.com/KhronosGroup/SYCL-Docs/blob/8f8dd56921f20126ec106630807a3864532711fd/latex/programming_interface.tex#L2148
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:
https://github.com/KhronosGroup/SYCL-Docs/blob/8f8dd56921f20126ec106630807a3864532711fd/latex/programming_interface.tex#L1171
https://github.com/KhronosGroup/SYCL-Docs/blob/8f8dd56921f20126ec106630807a3864532711fd/latex/programming_interface.tex#L1215
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:
https://github.com/KhronosGroup/SYCL-Docs/blob/8f8dd56921f20126ec106630807a3864532711fd/latex/programming_interface.tex#L2168
Except in this instance, where "full ownership" is used differently:
https://github.com/KhronosGroup/SYCL-Docs/blob/8f8dd56921f20126ec106630807a3864532711fd/latex/programming_interface.tex#L2132
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:
https://github.com/KhronosGroup/SYCL-Docs/blob/8f8dd56921f20126ec106630807a3864532711fd/latex/programming_interface.tex#L1534
https://github.com/KhronosGroup/SYCL-Docs/blob/8f8dd56921f20126ec106630807a3864532711fd/latex/programming_interface.tex#L2107
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.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.