Skip to content
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

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

Open
aharon-abramson opened this issue Aug 28, 2024 · 2 comments
Open

Comments

@aharon-abramson
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor Author

"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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Next Spec Release
Development

No branches or pull requests

2 participants