LabVIEW
LabVIEW & MVTec Halcon
Solved!
MTrivedi
Great news for you! 
After I have done some tests on Halcon 13, I've re-read the manuals and saw this:
HALCON Programmer's Guide:
3.2 Terminate HALCON Library
In applications where DLLs are unloaded in a thread-exclusive context (such as applications using COM), the HALCON library will not terminate properly if the thread pool is still active, except when using the HALCON/COM interface.
A possible scenario where the problem may occur is, e.g., when using HALCON/C++ to implement an ATL control.
To overcome this problem, it is necessary to call the function FinalizeHALCONLibrary() before unloading the DLL. Make sure that the call to FinalizeHALCONLibrary() is not from within any other DLL’s DllMain function. Please note that once FinalizeHALCONLibrary() has been called, no further HALCON functions may be called.
And here's the quote from Release Notes for HALCON 13.0.1:
Since HALCON 12.0.2, the mechanism to terminate the HALCON library has been changed by introducing a new function FinalizeHALCONLibrary(). Now, the correct way to close all HALCON threads and free resources is to call the function FinalizeHALCONLibrary() before unloading halcon.dll. The Programmer's Guide missed this information. This problem has been fixed.
So, sometimes it's worth reading manuals and developer's notes to know the way our software works flawlessly. 
@dadreamer wrote:
MTrivedi wrote:
I have one another question it that , when I am call this dll multiple times parallel , it takes more process time , so I try to set my dll as a reentrant but it can't work
Well, I'm not sure for 100% but I think, you should move to 64-bit LabVIEW, Halcon and write 64-bit DLL. If you set CLFN as running in any thread and you're sure that your code is able to run reentrantly (no global vars etc.) it likely goes to threading issues. Because you work in 32-bit environment, you don't have "real" parallelization between the threads. Your program uses one processor core and all the threads run sequentially by interruption. To have all the cores involved into the task you definitely should try 64-bit software.
That doesn't quite sound right. 32 bit processes can just as well use parallel threads that get distributed on multiple cores if the software in question allows that. 64 bit processes mainly profit from a linear virtual address space that goes beyond 4GB if that much physical memory is available. For processing large images that could be a significant benefit.
However I guess the problem here might be the Halcon library which might or might not contain some specific code that makes it single core executable. If that is the case, there is not much you can do from within LabVIEW but you might have to call additional Halcon functions in your DLL to inform the Halcon kernel that it should use multiple cores.
@MTrivedi wrote:
Hello dadreamer
I tried this operators , but reentrant and parallelize_operators are by default true . So is it necessary to set it? I tried this but can't show it's effect. I set LabVIEW vi execution in preallocated clone reentrant execution and my CLFN in >>>UI thread<<<.
That's the serialization problem then! The UI thread is single threaded and anything that goes through it has to compete for this tread together with other protected operations in LabVIEW such as UI drawing and code sections that NI knows can't be made multi-threading safe without an enormous overhead.
But setting it to any thread, while allowing parallel execution can be a tricky setting. You have to be absolutely sure that the external code you call is fully multi-threading safe. That means among a few other things: no global variables or other global resources (like hardware or other IO devices) being called from anywhere in that external code that can be called in parallel, unless these resources are properly protected through a semaphore or similar. That includes your self written code as well as any other function you may call from any third party library. If the documentation to a library or particular function doesn't state that it is safe to call it in parallel with itself or other functions from the library it is usually a dangerous thing to assume that you can!
