deadlock when calling DLL in labview

[hyshys]

Hi,

I want to call a LabView VI from TestStand in a parallel thread but I get some problem when the VI access external DLL.

Here is an explanation of my sequence

1- I want to run the VI in a parallel TS thread (called here "ViThread")
2- My main sequence (in the main TS thread) should continue to run and execute subsequences during execution of the VI...
3- When the main sequence is terminated, it should wait until the end of the "ViThread"
4- Both thread should access the same DLL
5- The access time to the DLL is approximatively 1 to 100 milli seconds
See the attached examples.

The deadlock occured when I clicked in the LabView VI. Example: When I clicked on TitleBar of the VI (or when I tryed to move the VI window), then the VI freezed...

Here are what I tryed to solve my problem:

a) When I remove the DLL call in the VI, no more deadlock occured...

b) I modified the execution options (as the thread priority and the prefered execution system) of the VI, but it didn't seem to work...

c) I added a wait icon of 10 milli seconds in the VI and it works for simple example. When the DLL access are longer, the VI also freeze...

Do you have any idea?

Thanks
Regards.

Vincent

[Caroline Bright]

Hi Vincent,

I was able to recreate your issue here and realized that the problem occurs in LabVIEW even without a call in TestStand. This behavior occurs because the Call Library Function Node is set to Run in UI Thread. This means that you cannot access the library until the last call to the library has finished. This can be fixed in two ways. First, you can add a wait just like you have tried to make sure that LabVIEW finishes accessing the library before calling it again. However, this may create undesirable delays in your program. The other option is to set the call to be Reentrant. Just double-click the Call Library Function Node and select Reentrant from the selection box on the right side. I used this option and ran the TestStand sequence with no trouble. However, depending on your application you may not want to use reentrant. Reentrant actually loads multiple copies of the library into RAM so some changes made by one application may not be "seen" by the other. However, if your TestStand application and LabVIEW application do not depend on the same variables, I would suggest changing the Call Library to be Reentrant.

Thanks,
Caroline
National Instruments

[hyshys]

Hi Caroline,

My dll can't be call with reentrant option enabled because all calls to my dll should be executed in the same thread. Using reentrant option, the execution thread could changes.

I'm not sure, but I think I found a way to use reentrant option.
- I created a sub-vi that contains my dll call
- I specified that my sub-vi should be executed in "other2" execution system
- I setted my dll call reentrant
- I insert my sub-vi in my vi
- I setted the number of thread to "One thread" for the execution system "Other2" in the vi "threadconfig.vi" in:
"c:\program Files\National Instruments\LabVIEW 7.1\vi.lib\Utility\sysinfo.llb"

Do you think it's a good idea?

Vincent

[Caroline Bright]

Hi Vincent,

Unfortunatly, you cannot call the same dll in the same thread at the same time. The dll MUST be reentrant. After LabVIEW calls the dll and then TestStand calls the dll, TestStand automatically starts a new thread. There is just no way to access the same dll by two different applications at the same time. I am sorry that this does not meet your needs but maybe if you explain what you are trying to accomplish overall, we may be able to look into other options.

Thanks,
Caroline
National Instruments

[hyshys]

Hi Caroline,

I don't need to call the DLL at the same time, but necessary in the same thread.

Thanks

Vincent

[Caroline Bright]

Hi Vincent,

If they do not need to access the dll at the same time and they need to be in the same thread, really your only option is to add a wait in the while loop in LV so that you are sure that the program has finished with the dll before trying to access it again. Depending on what the dll is doing, your wait time will vary. However, I would currently set the wait to 100ms so that you will be sure that it is free and you will not crash your program.

Thanks,
Caroline
National Instruments