Calling a non-threadsafe C DLL from LabVIEW

[David_Staab]

I imagine it'll need a wrapper DLL that makes it threadsafe and works with the LabVIEW memory manager, LabVIEW's implementation of abort signaling, etc. Does anybody know where the documentation for undertaking such a project is? I can't find it searching around the site and the help files.

[0utlaw]

Hello David,

As far as I know, all you should need to do is ensure that the "Call in UI thread" option is selected in the CLFN (this is the default)- this should force single-threaded execution.

Regards,

[JÞB]

For examples of non-thread safe C DLL calls take a look into the XML file functions (DOMUserDefRef.dll is NOT thread safe)

[David_Staab]

0utlaw, I'd rather learn how to wrap a non-threadsafe DLL in a threadsafe one (by either static or dynamic linking) than force it to run in the UI thread. There are lots of DLLs out there that shouldn't get locked up when the UI is busy (or lock up the UI while they run on background tasks). Moreover, I don't think there is a UI thread on LVRT, and I will be needing to compile this DLL to Linux and VxWorks.

Is there no documentation on how LV interacts with DLLs and memory to help someone write a DLL that's safe to call from LV? I know, for example, that LV's Abort button is asynchronous, and you have to connect a callback to that event in your DLL. What other oddities lurk in the LV calling interface?

[nathand]

Are you trying to write a wrapper in C, or a wrapper in LabVIEW? One easy approach in LabVIEW is to wrap all the DLL calls in VIs, and then use a locking mechanism (semaphore, single-element queue) to prevent more than one call to the DLL from executing at a time. You could even do this by having only one VI that calls the DLL, wrapping each function in a separate case in a case structure and passing the parameters in and out using variants, but that seems messier.

[David_Staab]

The wrapper will be written in C. There are lots of pointer-based mechanisms in the core DLL that need to be wrapped up, as well as string realignment and other nastiness I'd rather not expose directly to LV.

[0utlaw]

Hi David,

The question on creating threadsafe C wrappers seems pretty general (more general than calling them from LabVIEW alone; "safe to call in LabVIEW" implies that "safe to call from anywhere" is preferable)- I've never attempted this myself but I imagine that the methods required would be highly situation-dependent. Why is this library non-threadsafe to begin with?  Is the DLL in question a standalone number-crunching or similar, or does it have further dependencies that might be shared? Does it run asynchronously? Does it do any internal checking that a given resource isn't in use?  Do you intend to call it in parallel? 

This document on calling LabWindows/CVI DLLs in LabVIEW RT touches on thread safety; if nothing else it confirms that the "Run in UI Thread" method is valid:

Using LabWindows /CVI DLLs in LabVIEW Real-Time Applications

http://it360.tw/document/an/pdf/an207.pdf

As for the UI Thread on RT- while it is true that there is no UI in a standalone LVRT application, the single-threaded execution system still exists and is used for the same operations it normally would, such as VI/Application properties and methods and registered events.

Hope that helps!