Using a DLL generated by LV in multithreaded Visual C++ program

[ttte]

I have a VI that controls switches. I made a DLL with the VI to use in my multithreaded Visual C++ program. The function from the DLL works fine and controls the switches when the function is used in main().

But if I try to use the function in other threads, the thread with the function gets stuck. I confirmed that multithreading works fine and that the DLL works well without being included as an additional thread. I started to think something in the original VI doesn't let me use it in multithreaded environment. Not sure what it would be. Has anyone had any similar problem? Please help...

Tom

[ChrisJ]

Hi Tom,

I’m afraid I don’t have an answer offhand. I am curious about a couple of things though. First, were the VIs you created into a DLL reentrant (VI Properties>>Execution)? Second, does the driver for the switch you are controlling support multithreading?  

Regards,

Chris J

[ttte]

I tried with both with and without the reentrant option but it didn't help. Looks like it is something else. Also, I am using the function from DLL only in the second thread (not in main()). Would it matter here whether it is reentrant or not?

The switch is driven with a digital output signal from a DAQ board. The VI I used to build my DLL works fine with the switch.  I am wondering how multithreading can affect the driver or the switch itself. I thought multithreading happens inside a PC; and at the switch- or the driver-level, multithreading has already been taken care of. Well, I may be wrong... Please let me know what you think.

Tom

[ChrisJ]

Hello Tom,

You are correct. Sorry for my sloppy wording. Multithreading is something the PC does. For a driver or program to work in multiple threads it has to be thread safe. I was just wondering, if you were using an non-NI driver if it was threadsafe. Also, could you give us some more information on the following:

OS

DAQ board

Driver version

Traditional DAQ calls or DAQmx

Thanks!

Chris J

[kcaero]

I'm actually seeing something very similar. I'm trying to call a LabVIEW DLL from a windows service (written with VS 6.0, C++),  and the service would always fail to start. After your post, I realized that windows initializes a service by creating another thread which is where I call the LabVIEW DLL.  I used a debugger and it is blocking on NtWaitForMultipleObjects() in winnt.dll. Were you able to call the LabVIEW DLL from another thread?

[ttte]

Here is the info for my set-up:

OS: Windows 2000 Professional

DAQ Board: I am trying with both IOtech's DaqBoard/500 and NI's PCI-MIO-16E-4.

Driver version: Not 100% sure but seems to be NI-DAQ 7.4; I need to go back to the lab to check. I will let you know if it is not correct.

Tranditional DAQ calls or DAQmx: don't understand what you need...

Sounds like a function from a DLL generated by LV may or may not work in my VC program depending on what DAQ board I use. Is it what you mean? I think I don't fully understand why. So, if you can explain the reason, I would appreciate it. If I better understand the reason and how to find which board to use, I can try with some other DAQ board I have. Thanks.

Tom

[Lycangeek]

I think this might be the "UI thread" issue that can happen when using LV DLLs in a MT environment. LV itself can handle an MT environment just fine - it itself is an MT system. For example, if you want the LV DLL to be reentrant, make sure you set the VI property to be reentrant.

But I digress...The quick summary is that the first thread to call into the DLL is taken as LV's UI thread and handles the message pumping for LV. Note that this is required even if you don't do any UI displays with LV - a lot of LV is event based and uses the message pump. Therefore if you want to call LV from multiple threads, just make sure that the first thread to do this pumps threads - otherwise you will deadlock.

I wrote up an explaination of how to fix this for customers trying to use LV DLLs in ASP.NET (http://detritus.blogs.com/lycangeek/2005/05/labview_and_asp.html) and the basic code shown is what you need to do (although moved back into C/C++).

[ttte]

I wanted to see if my problem is simply LV-related or DAQ board-related. So, I made a small VI to create a DLL and tried to use the function from the DLL in my VC++ program as I did with my original DLL with problems.

The DLL worked in both main and second threads. So, I think my problem is directly or indirectly related with the board I try to use or the way I try to use the board.

Tom

[Lycangeek]

I am not so sure - I think the simple case might simply have reduced the chance of the deadlock. I think you need to get the message pump running...

[ttte]

I will try something based on your advice. But one thing is not clear in my mind. As I mentioned, I could make a function from a DLL generated by LV work in both main and second threads. How, then, does the function in the second thread work without doing anything for the "UI thread" issues? How would this DLL be different from the DLL that uses a data acquisition board?

Tom