I'm working on a software application that is being developed
primarily in C++. There is a component of this larger application,
however, that is being developed in LabVIEW (for several reasons that
I won't dive into here). This LabVIEW code is therefore executed
within a C++ wrapper class that calls a LabVIEW built DLL.
All this was fine and dandy, untill we decided to multi-thread our C++
application. As a result, the LabVIEW DLL now gets called from
multiple threads simultaneously. From all of my testing, it appears
that resource locking is occuring such that only one thread has access
to the .dll at a time. If I make the .vi used to define the dll
function prototype as non-reentrant then this is what we see. As an
example, say we have 3 threads all calling the same .dll method call.
Thread 1, 2, and 3 all call the .dll within a few milliseconds of each
other. Thread 1 completes the .dll call after X milliseconds. Thread 2
completes the .dll call after 2X milliseconds, and thread 3 completes
after 3x milliseconds.
Now, changing the vi to reentrant, and running the same test, we see
Thread 1, 2, and 3 all complete the .dll call in 3x milliseconds.
While the fact that they now take the same amount of time to complete
would lead you to believe they are happening in parallel, the fact
that it takes 3x milliseconds as opposed to X milliseconds means they
are not.
Has anyone ever dealt with these issues before? Is it possible that
messing with the "execution system" for the vi will have an affect?
What if different .dll methods but still attached to the same .dll are
called from different threads? Same behavior? Is it a lost cause? Is
there no way to make code within a single LabVIEW built .dll run in
two different threads at the same? From what I understand this is
easily doable with a normal (non-LV built) .dll.
Please, if anyone has any advice in this area, let me know!!!
Much appreciated,
Jesse Hurdus
