OpenCL* for CPU
Ask questions and share information on Intel® SDK for OpenCL™ Applications and OpenCL™ implementations for Intel® CPU.
This forum covers OpenCL* for CPU only. OpenCL* for GPU questions can be asked in the GPU Compute Software forum. Intel® FPGA SDK for OpenCL™ questions can be ask in the FPGA Intel® High Level Design forum.
1687 Discussions

Problem with clRelease functions



I have an issue with clRelease functions (clReleaseContext, ...). I developped a C++ library to manage easily OpenCL functions and a test application to control its working.

This application works fine and all clRelease functions are call with success.

Then I developped an other library that uses the first lib to use OpenCL and a test application to control its working.

This application stops when I try to enter in the first clRelease functions namely clReleaseContext.

The same problem appears with Intel and NVidia OpenCL driver. So this is not a driver problem but a usage problem.

To summarize:

OpenCL -> LIB_A -> TEST_APP_A : OK

OpenCL -> LIB_A -> LIB_B -> TEST_APP_B : not OK

Is someone could help me to find the problem?


0 Kudos
3 Replies
I found a solution but I still don't understand the problem. Here is the architecture: class A is a singleton and creates the context. class B is a singleton and have the member static A* instance. If I remove the static member of A* in class B and I give the instantiation of A to other functions calls to clRelease functions work fine. So this is the only way to avoid the issue, but I don't understand why I can't have a static instantiation of a singleton in a class. Thanks.
I don't know how did you implement your singletons but assuming the implementation using static objects: 1. C++ defines static objects constructors and destructors execution order only for the objects that instatiated in the same CPP file. Relative order of executon of contructors and destructors between different CPP files is not defined. 2. On Linux relative execution order between DLL constructors/destructors (process attach/detach on Windows) and static objects contructors/destructors is also not defined. 3. On Linux relative order of different shared objects (DLL) contructors/destructors not defined. On Windows the same picture for dynamically loaded DLLs (and OpenCL drivers are dynamically loaded) As a result it is not a good C++ practice to create static objects that either: 1. depend on each another (as in your example) 2. depend on other DLLs (as in your example they depend on OpenCL drivers) As far as I know in most cases this problem is solved by using static pointers instead of static objects and never deleting this objects after initial allocation or by using some "shutdown" function that must be called from the process "main" function or one of it descendants.
Ok thank you for the explanation!