search

KhronosGroup / OpenCL-Docs

OpenCL API, OpenCL C, Extensions, SPIR-V Environment Specs, Ref page, and C++ for OpenCL doc sources.
Other
361 stars 113 forks source link

exiting program without waiting for the completion of all commands #1238

Open aharon-abramson opened 2 months ago

aharon-abramson commented 2 months ago

The spec is unclear about what happens when function main returns while commands are still in flight, even if their queue has been released. The problem is that the finalization flow in C/C++ after main has returned is not well-defined and is platform-dependent. That might lead to things like crashes, deadlocks, or resource leaks. I propose adding a note in the spec that applications must ensure all enqueued commands have been completed before exiting main, otherwise the behavior is undefined.

bashbaug commented 2 months ago

This may be the best we can do, but I'd like to at least explore some alternatives, since OpenCL currently does not provide a mechanism to ensure that all commands executing on a device have completed similar to vkDeviceWaitIdle in Vulkan.

Let's assume that all OpenCL objects have been properly released, and in particular all OpenCL command queues and the OpenCL context used to create the command queues have been released. Could we find a way to say that this case is well-defined?

For reference, the spec currently says that clReleaseCommandQueue performance an implicit command-queue flush, but not an implicit command-queue finish. (Aside: it's ambiguous whether this happens for any command-queue release or just the last one that cause the reference count to go to zero.)

Perhaps we say something like: any commands that are in-flight (meaning: their execution status is not CL_COMPLETE) may be abnormally terminated when the context is destroyed?

I'd really like to avoid a case like the one below, where the following code anywhere in a program could lead to undefined behavior given the proposal above, because there's no way to confirm the commands are complete after the command-queue is released.

queue = clCreateCommandQueue(context);
clEnqueueNDRangeKernel(queue, kernel);  // note: no event
clReleaseCommandQueue(queue);
// uh oh, no way to ensure the previous enqueue is complete!
aharon-abramson commented 2 months ago

"any commands that are in-flight (meaning: their execution status is not CL_COMPLETE) may be abnormally terminated when the context is destroyed" - sounds good to me.