LabVIEW built DLL's in a multi-threaded C++ app

[Hurdus]

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 LV code is therefore executed within a C++ wrapper class that calls a LV built DLL.

All this was fine and dandy, untill we decided to multi-thread our C++ application. As a result, the LV 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 LV 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

[Dan DeFriese]

I've never built a DLL in LabVIEW before. However, I'd assume that all the VIs (export functions) that you want parallelism for would have to be reenterant and that any of their common subVIs would have to be reentrant as well.

[Hurdus]

Agreed, and in my tests, to minimize any possibility of confusion I simplified things such that the .dll method has only one top-level VI that multiplies two large matricies together 100 times. I would expect that any common non-reentrant subVIs to result in such resource locking so in this case I made absolutely sure there were none.

Could it be possible that when put in a .dll and run via the run-time engine, that basic labview mathematical functions become inherently non-reentrant? Doesn't seem to make much sense, but I'm scratching for possibilities...

Thanks for the suggestion though, any other ideas?

[Rolf Kalbermatter]

QUOTE (Hurdus @ Dec 10 2008, 05:42 PM)

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 LV code is therefore executed within a C++ wrapper class that calls a LV built DLL.

All this was fine and dandy, untill we decided to multi-thread our C++ application. As a result, the LV 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 LV 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

Seems like a http://forums.ni.com/ni/board/message?board.id=170&message.id=373893&query.id=30448#M373893' target="_blank">cross post. It's considered polite to give a reference to such cross posts so that people are not wasting their time answering you with ideas when the whole problem might already have been solved on another board, which in this case is.

Rolf Kalbermatter

[Hurdus]

QUOTE (rolfk @ Dec 21 2008, 02:14 PM)

Seems like a http://forums.ni.com/ni/board/message?board.id=170&message.id=373893&query.id=30448#M373893' target="_blank">cross post. It's considered polite to give a reference to such cross posts so that people are not wasting their time answering you with ideas when the whole problem might already have been solved on another board, which in this case is.

Rolf Kalbermatter

Well Rolf, if there was someone actively working on this problem on this board, I surely would have given them an update on the situation. Thanks for being the posting police though!