An OpenCL API call is considered to be thread-safe if the internal state as managed by OpenCL remains consistent when called simultaneously by multiple host threads. OpenCL API calls that are thread-safe allow an application to call these functions in multiple host threads without having to implement mutual exclusion across these host threads i.e. they are also re-entrant-safe.
All OpenCL API calls are thread-safe except those that modify the state of cl_kernel objects: clSetKernelArg, clSetKernelArgSVMPointer, clSetKernelExecInfo and clCloneKernel.
clSetKernelArg , clSetKernelArgSVMPointer, clSetKernelExecInfo and clCloneKernel are safe to call from any host thread, and safe to call re-entrantly so long as concurrent calls to any combination of these API calls operate on different cl_kernel objects.
The state of the cl_kernel object is undefined if clSetKernelArg, clSetKernelArgSVMPointer, clSetKernelExecInfo or clCloneKernel are called from multiple host threads on the same cl_kernel object at the same time.
Please note that there are additional limitations as to which OpenCL APIs may be called from OpenCL callback functions — please see section 5.11.
The behavior of OpenCL APIs called from an interrupt or signal handler is implementation-defined.
There is an inherent race condition in the design of OpenCL that occurs between setting a kernel argument and using the kernel with clEnqueueNDRangeKernel.
Another host thread might change the kernel arguments between when a host thread sets the kernel arguments and then enqueues the kernel, causing the wrong kernel arguments to be enqueued.
Rather than attempt to share cl_kernel objects among multiple host threads, applications are strongly encouraged to make additional cl_kernel objects for kernel functions for each host thread.