Open VI Reference prevents execution of other parallel threads

Question

I am using splash screen to start an application. I use dynamic loading of the Main.vi and an animation during the loading, both in parallel threads (see image below). However, when the Open VI reference VI is called everything else stops executing (the animation stops running) until the Open VI reference is done. I must call the Main.vi dynamically, because it takes some time to load and I want to notify a user that the application is loading (using animation). Is there an option to prevent the Open VI reference to block the execution of other threads? Or should I use some other approach?

Answer 1

andrej wrote:
But the problem is not in the Run.VI method because the Open VI Reference blocks the execution of the top loop and I need the Open VI Reference to call the Get VI Dependencies method. Other approach could be to create a static array of dependencies and then to use this array to load VIs from bottom up.
The only question now is if the Get VI Dependencies method returns dependencies in top to bottom order? If it does then I can just load VIs in reverse order from the array.
Well the problem is the Open VI Reference! This executes in the UI thread, as several people have explained already (and really can't be made to do otherwise without causing a number of possible and nasty race conditions, some of them even related to the underlaying OS and not just LabVIEW itself), just as your two Property Nodes in the upper loop have to use the UI thread too.
Once Open VI starts it only returns if it has loaded the required VI fully into memory (and that includes any dependencies that aren't already in memory) and linked them all properly together or runs into an error during loading. For this duration, NO UI Property Node can execute, which is what stalls your upper loop. If you would use local variables or terminals instead the upper loop would happily run along while Run VI loads the entire VI hierarchy but it would still not show on the UI, because in order to draw the new data from the diagram passed to locals and terminals LabVIEW has to catch the UI thread to do the UI drawing.
So first fix is to kick out any property nodes from the upper loop and the second part of the solution is to load your VI hierarchy in chunks instead of simply loading only the top level VI directly. It would be nice if Open VI had an option to allow UI thread release between loading of chunks of VIs, but the implications are not that nice. It would be quite easy for an uncareful LabVIEW programmer to create a lockout situtation then, where two functions are in fact waiting on each other to release some locks so that the program gets hang up. And a simple warning in the documentation to watchout as this option can allow to create such lockout situations is not very useful as nobody reads them anyhow.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions