LabVIEW
Making Call library function to run in any thread
Well, it seems to work when you set the Call Library Node to reentrant. The problem with that is that only the programmer of the DLL knows if his/her DLL is really thread safe. If it isn't, it may usually work fine but occasionally produce strange results and/or crash.
Most programmers are sufficiently bothered about the Call Library Node to take their hands off from the VIs the moment it starts to work. That often leaves the Call Library Nodes to run in the UI thread (the only safe setting that will always work, safe from real bugs in the DLL or Call Library Node configuration), even though it might be perfectly fine to let them run reentrant.
But! Only someone with access to the source code of the DLL can tell if that is really going to be safe, unless of course the programmer of the DLL was a real Pro and actually mentioned that fact in the accompanying documentation. Without any such mentioning, you have to assume that the programmer actually has himself no clue about if something like thread safety would apply to his DLL and that experimenting with this setting is pretty much playing russian roulette. 😀
The idea about copying your DLL is most likely a dead end however. Most IO ports are protected resources that can't be opened multiple times without a lot of extra measures and from those multiple copies of the DLL, only one (the first one to get there) will be able to open the communication channel to the device.
@charmelony_ wrote:
If I change the thread of call library function to run in any thread, there is no lag in the front panel, everything runs smoothly. Unfortunately, I have no knowledge about dll and call library functions. On the other hand, after some research in the forum, I concluded that that dll should be run in UI thread.
If it works smoothly (tested thoroughly) in run in any thread, why not go with it?
Search LabVIEW like a graph!
@JÞB wrote:
wiebe@CARYA wrote:
@charmelony_ wrote:
If I change the thread of call library function to run in any thread, there is no lag in the front panel, everything runs smoothly. Unfortunately, I have no knowledge about dll and call library functions. On the other hand, after some research in the forum, I concluded that that dll should be run in UI thread.
If it works smoothly (tested thoroughly) in run in any thread, why not go with it?
After opening a dialog with the vendor. Those edge cases that Rolf alluded to are impossible to predict without a thorough investigation of the DLL source since some open pointers to refs may depend on OS garbage collection. "Just do it!" is fine for Nike sneakers but dangerous for Nike missiles.
Well, dlls are not sneakers nor missiles 😊.
I think it is in much harder to make a dll that isn't thread safe. That is, thread unsafe dlls are probably more complex.
Note that you can always set run in any thread if you only call the dll once at a time. So, if you put the dll in a non-reentrant VI, the dll will only be called once at the time, tread safety becomes irrelevant, and the UI thread won't be locked.
@JÞB wrote:
wiebe@CARYA wrote:
@JÞB wrote:
wiebe@CARYA wrote:
@charmelony_ wrote:
If I change the thread of call library function to run in any thread, there is no lag in the front panel, everything runs smoothly. Unfortunately, I have no knowledge about dll and call library functions. On the other hand, after some research in the forum, I concluded that that dll should be run in UI thread.
If it works smoothly (tested thoroughly) in run in any thread, why not go with it?
After opening a dialog with the vendor. Those edge cases that Rolf alluded to are impossible to predict without a thorough investigation of the DLL source since some open pointers to refs may depend on OS garbage collection. "Just do it!" is fine for Nike sneakers but dangerous for Nike missiles.
Well, dlls are not sneakers nor missiles 😊.
On the other hand... I have written algorithms that must differentiate between the Nike footgear worn on the left foot from one worn on the right foot while ambulating on a treadmill. I have also written algorithms to test fusing systems for "Chemical Energetics," for an aerospace company.
There was a different level of confidence required.
Talk to the vendor.
Well, a possible outcome could be the dll isn't thread safe.
In that case (or if vendor doesn't reply), if you do want a responsive UI (who doesn't?), you can still put the dll on "run in any thread", and call the dll in a thread safe manner by forcing sequential calling (one way or another)...
@charmelony_ wrote:
The vendor said they do not know. I let the Vi work enabling call library running in any thread. It has been two days, and so far there is no crash, all data are saved correctly. There is a case structure which makes dll calls are in sequence. That could be the workaround as you suggested.
I will report again couple days later. I conduct long term experiments and cannot risk any crash. That was the reason that I was hesitate running in any thread.
If you test the dll in a sequence structure (why not use the error wire??) you're not testing if the 'run in any thread' is harmful or not.
This means 'run in any thread' might not be safe. At some point, if you (or someone else) start calling the sequence n times (in two threads), crashes might appear.
If you want to be sure 'run in any thread' safe, you have to test in a way that is not safe...
Alternatively, put some comments (large orange or red text warnings) in your code that 'run in any thread' has not been tested for multiple threads...
Commenting these things in code and\or documentation is a good idea in general.
