LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Two instances of SystemExec in parallel - weirdness

Solved!
Go to solution

Hi, Everyone:

 

I was hoping you could help me out here.  I have to instances of SystemExec in parallel.  They run in parallel from source, but run serially in a dll.  Any ideas?

why does SystemExec VIs run in parallel in source but serially in dll.png

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 1 of 3
(228 Views)
Solution
Accepted by topic author billko

Your caller only can use one thread to call a single C function (which a DLL function is in principle) and therefore everything has to be serialized. The LabVIEW runtime executing that VI inside the DLL could attempt to parallelize it anyways by spinning up extra threads but that comes with a lot of effort, is slow and nullifies in many cases a lot of the performance gain. Add to that extra overhead to synchronize all threads at the end before returning and managing them across multiple calls and things get a nightmare to implement and test.

 

LabVIEWs multithreading is not dynamic. The execution system starts up a number of threads on starting and then distributes the code chunks across them during execution. Starting up snd tearing down threads is relatively expensive, so not something you want to do continuously. But a DLL boundary is pretty much a black box. The caller can assume pretty much nothing about the DLL and vice versa beyond the declared interface.

 

While LabVIEW as caller can detect if a DLL is also a LabVIEW DLL and executes it in its own runtime system if the version matches instead of having the DLL startup its own runtime system and then having to marshall data between the two, that’s a convenience shortcut for debugging. After all where is the real benefit of creating a DLL from LabVIEW code to then call it from LabVIEW? Even with that, scheduling threads across DLL boundaries is not something you want to do since the caller has no control of what happens inside the DLL.

Rolf Kalbermatter
Averna BV
Message 2 of 3
(177 Views)

@rolfk wrote:

Your caller only can use one thread to call a single C function (which a DLL function is in principle) and therefore everything has to be serialized. The LabVIEW runtime executing that VI inside the DLL could attempt to parallelize it anyways by spinning up extra threads but that comes with a lot of effort, is slow and nullifies in many cases a lot of the performance gain. Add to that extra overhead to synchronize all threads at the end before returning and managing them across multiple calls and things get a nightmare to implement and test.

 

LabVIEWs multithreading is not dynamic. The execution system starts up a number of threads on starting and then distributes the code chunks across them during execution. Starting up snd tearing down threads is relatively expensive, so not something you want to do continuously. But a DLL boundary is pretty much a black box. The caller can assume pretty much nothing about the DLL and vice versa beyond the declared interface.

 

While LabVIEW as caller can detect if a DLL is also a LabVIEW DLL and executes it in its own runtime system if the version matches instead of having the DLL startup its own runtime system and then having to marshall data between the two, that’s a convenience shortcut for debugging. After all where is the real benefit of creating a DLL from LabVIEW code to then call it from LabVIEW? Even with that, scheduling threads across DLL boundaries is not something you want to do since the caller has no control of what happens inside the DLL.


Ah, the dll expert speaks!  Good info, and it does explain what I am seeing.  FYI, I didn't state how exactly the dll was used.  It is actually being called by a test executive (but not TestStand).

 

Thank you!

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 3 of 3
(136 Views)