clSetKernelArg memory safety underspecified

The OpenCL specification states for clSetKernelArg that "Implementations shall not allow cl_kernel objects to hold reference counts to cl_kernel arguments", but it does not specify when it's safe for application to call clReleaseMemObject on bound memory objects.

The OpenCL CTS test release_during_execute in the api test calls clReleaseMemObject before it calls clFinish on the queue, though implementations might reasonably want to touch the bound kernel argument after the application calls clEnqueueNDRangeKernel, e.g. when the queue gets flushed or if the implementation offloads work from the main application thread onto an internal queue worker thread.

So at the moment I'm wondering if the CTS test is too optimistic here and relies on undefined behavior or if implementations must do all necessary processing of kernel arguments already inside clEnqueueNDRangeKernel and not later.

This also opens up the question why clSetKernelArg is special here, because implementations might reasonably postpone deallocation of memory objects used in other enqueue commands until they are fully processed (e.g. until clFinish or any other blocking command).

But we also have clSetMemObjectDestructorCallback since OpenCL 1.1 and applications had enough time to use that, so maybe it's also time to just remove this part of the specification? Or is it still important to care about OpenCL 1.0 only implementations?

Start with the linked OpenCL 3.0 specification text for clSetKernelArg and the OpenCL CTS api test release_during_execute in test_conformance/api/test_retain_program.cpp. Compare the specification wording with the CTS behavior and the lifecycle questions raised here. Done means the expected memory-object lifetime semantics are resolved and the relevant specification or test scope is clearly identified.