-
Notifications
You must be signed in to change notification settings - Fork 787
[SYCL] Fix a race condition when enqueueing an interop kernel #8111
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
piKernelSetArg isn't supposed to be called from different threads on the same kernel.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Failed Tests (1): |
// cache, others (e.g. interoperability kernels) share a single mutex. | ||
// TODO consider adding a PiKernel -> mutex map for allowing to enqueue | ||
// different PiKernel's in parallel. | ||
static std::mutex NoncacheableEnqueueMutex; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be probably better to have an std::mutex
stored in kernel_impl
. So, we do not serialize submission of different sycl::kernel
s.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@romanovvlad I tend to agree, although wouldn't this mutex need to be tied to pi_kernel
like described in the comment above? Otherwise we will run into issues if two interop sycl::kernel
are created with the same native kernel.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds reasonable.
Switch from using a single mutex to one per kernel when enqueueing interoperability kernels. Compared to the original solution (intel#8111), this allows to enqueue different interop SYCL kernels in parallel, but leaves out an edge case where two SYCL kernels were created with the same native handle.
Switch from using a single mutex to one per kernel when enqueueing interoperability kernels. Compared to the original solution (#8111), this allows to enqueue different interop SYCL kernels in parallel, but leaves out an edge case where two SYCL kernels were created with the same native handle.
piKernelSetArg isn't supposed to be called from different threads on the same kernel.