DLL, thread, and parallelism

[MarcDub]

I think that one of the great benefit of LabVIEW for general programming is its ability to relatively easily execute multiple processes truly in parallel.

That said, I realized that when using a dll that is configured to run in the UI thread, my LabVIEW code is not being executed while the dll is executing, and the dll is not executing (or prevented from executing) when I have some CPU-extensive code being executed, even when the code and the dll are in separate loops (or separate VIs).

This problem can be solved by configuring the dll to run in any thread. This works great and significantly improves performance but my dll requires some initialization in a separate call to the same dll.

My impression is that if separate calls to a dll are made when configured to use "any thread", each call might be in a separate memory space, not having access to the memory space of each others. If I make one dll call using "UI thread", and another one using "any thread", I get an error from LabVIEW that memory might have been corrupted. However, using "any thread" for all calls does not generate the error.

So far, I was careful to use "any thread" for a dll call only if the called function is "self-contained" (no need for references outside the function itself).

My question is: Is it just luckly that LabVIEW used the same thread for all my dll calls when using "any thread" and that it is possible (or even likely) that at some point LabVIEW might use different threads, creating a problem?

Other question: Any way to configure a dll to run in another thread than the UI thread while making sure that all calls are in the same thread?

Any information about threads in LabVIEW would be appreciated. The only reference I found is: How Many Threads Does LabVIEW Allocate? 

[Ben]

You could put the dll calls in a sub-VI (a wrapper) with diffreent cases for the various function calls.

Configure the sub-VI to run in the thread you want it to run in.

As long as the sub-VI is NOT reentrant, the wrapper should ensure only one call ot the dll is active at a time.

Ben

[MarcDub]

Thanks Ben, I had never noticed the Preferred Execution System option in VI properties. I was already using a sub-VI wrapper, so testing was easy.

However, my problem (or question) remains the same. Even if I make the Preferred Execution Systems of my wrapper and of my calculations subVI different (other 1 and other 2 for example), the execution of the dll is not in parallel unless the dll calls are configured to "run in any thread".

How likely is it that different calls to the same dll will be in different threads if configured to "run in any thread" when the calls are all made using the same subVI?

[Ben]

I will have to defer to someone that knows more to answer that question.

If I could, I would.

Ben