LabView hangs when calling a dll entry point

[Porras]

Hi there.

I'm having a problem with a call to a dll which mission is to communicate with a serial device and retrieve data from it.

First of all, LabView calls a dll entry point ("Connect") that opens the serial port and creates a thread that runs in parallel. This thread reads and converts continuously data from the device. From time to time (periodically), LabView calls another entry point ("Measure"), that reads the current measure from the independent thread and displays it on the front panel. Everything works fine until LabView hangs up, sometimes earlier, sometimes later (at the 2nd measure, at the 17th...). The debugging shows that LabView keeps waiting for the result from "Measure", but it never comes. The only way to stop it is killing LabView using Windows Task Manager.

When calling the dll function "Measure", I need to use the option "Run in any thread", but if I set "Run in UI thread", everything works ok. Although this is not the behaviour I want.

Could you please give some advice or way to work around this?

Thanks in advance,
Francisco

[Alex.T]

Hi Francisco,

The problem that you're having will be because the DLL that you're calling isn't 'Thread Safe'.

It's analogous to the reentrancy of VIs.

DLLs are Thread Safe when:

• It does not access any hardware.
• It is only be called by a non-reentrant VI.
  
• It doesn't call any thread unsafe DLLs.
• It does not write to any form of globally shared data.

This means that the DLL that you are using can't be configured for Run in any Thread, due to its specific reservation of hardware resources.

The only work around I can think of in this instance is perhaps decoupling the elements of the DLL which rely on hardware interaction into a separate DLL. Essentially, this would mean making use of a DLL which possess only the thread safe elements of the current thread unsafe DLL.

Kind Regards,

[DFGray]

Another option is to use semaphores in all instances of your DLL access VIs.  Before you access the DLL, acquire the semaphore.  When done with the DLL, release the semaphore.  This will serialize accesss to the DLL and allow you to run the DLL in a thread other than the user interface thread.

You can use data value references and single-element queues to do the same thing in a more efficient manner, but their use is a bit non-intuitive.  Let us know if semaphores are too slow and we can look at faster implementations.