[SYCL] Fix static destruction order issue in OpenCL extension fptr cache #9254
Conversation
OpenCL plugin uses several static maps for caching extension function pointers retrieved from the backend. If a user application has a static variable that indirectly calls one of those functions in its destructor, the corresponding map might have already been destroyed. This patch fixes the problem by tying the lifetime of those maps to piTeardown.
| FuncPtrCache<clHostMemAllocINTEL_fn> clHostMemAllocINTELCache; | ||
| FuncPtrCache<clDeviceMemAllocINTEL_fn> clDeviceMemAllocINTELCache; |
There was a problem hiding this comment.
Can we use an std::tuple here so that a particular cache could be accessed via
tuple.get<FuncPtrCache<ExtFuncTy>>()
?
There might be a minor issue with the fact that C++'s using Ty = doesn't create a new type, so we might need to change the typedefs above to something like
Struct ExtFuncNameTy {
using FnPtr = /* current typedef */;
};
in order to introduce a unique type alias, but I think it will be worth it.
There was a problem hiding this comment.
That's exactly the issue, to go this route we would need to provide unique type aliases for all functions used including the ones defined in the OpenCL headers. I think it will end up being just as verbose as the current version.
|
@aelovikov-intel Do you mind if I address the rest of your comments in a follow-up PR? I'd rather leave those out of this one (especially the ones touching already existing code) to avoid delaying the fix. |
- Replace typedef with using - Change pi_context to cl_context to reduce casting Applies comments from intel#9254
OpenCL plugin uses several static maps for caching extension function pointers retrieved from the backend. If a user application has a static variable that indirectly calls one of those functions in its destructor, the corresponding map might have already been destroyed.
This patch fixes the problem by tying the lifetime of those maps to piTearDown.