11-12-2008 12:17 PM
Hi all,
I’m trying to find / create a concise list of design rules that should be applied when creating LabVIEW modules for TestStand sequences that will be run in parallel using the parallel batch process model. Areas of interest include: un-initialised shift registers, regular LabVIEW globals, re-entrant Vis.
Using LabVIEW 8.5 & TestStand 4
TIA
-Martin
12-03-2008 11:42 AM - edited 12-03-2008 11:45 AM
HI Martin,
When using either the batch or parallel process model with more than 1 test socket, we ensure a multithreaded domain. This can also exist when using a parallel testing architecture (ie. running sequences in their own threads or executions) with the sequential process model. So with any process model it is important to realize that it is possible to be in a multithreaded domain that provides shared access to resources. Without writing a dissertation on the advantages and caveats of multithreading, it should suffice to say that anytime shared access to resources is available we must synchronize the access to those resources to avoid deadlocks and race conditions.
The abstract answer to your question:
During the design of multithreaded modules (your LabVIEW code that will be called in a possibly multithreaded domain) you should realize that at any point during execution of your code the operating system may give up the current time-slice in which a thread is executing and give it up to another thread that could possibly enter execution anywhere. This awareness should lead to identifying certain critical sections of code that should be run atomically (no chance of half-completion). These critical sections are the pieces of code that should be synchronized. LabVIEW provides synchronization mechanisms designed to manage resource protection and sharing among multiple threads.
Some of the key resources requiring syncronization to keep in mind are (in decreasing order of locality): application resources (ie. any global data accessed in your LabVIEW code modules or parallel instances of one module if re-entrant), resources shared among processes (ie. file access), and system level resources (ie. instruments, communication ports, etc.).
More specifically:
While this is not an all inclusive list of recommendations for successful multithreaded module development, hopefully this will spark anyone else to put their two cents in and will also help get you started in forming of a list of design best practices. If any of the points I've mentioned above remind anyone of lessons they have learned in the course of thier development, it would be very helpful to post explanations of your specific examples to give everyone a feel for how these recommendations and concepts might actually apply to them.
Evan Prothro
RF Systems Engineer | NI
12-03-2008 03:55 PM
Thank you for such a detailed answer to this question Evan. This information is very much appreciated.
-Martin
01-04-2012 02:32 PM
Does anyone know if it is possible to share Functional Globals across test sockets when executing using the Parallel Process Model?
What I'm seeing is that, even if the VI housing the Functional Globals is re-entrant, each test socket will open up a unique version of the VI.
Is there a way to force them to use the same copy?
Thanks,
Tom
01-05-2012 03:57 AM
Tom,
FGVs must not be reentrant. So please check the setting of the FGV itself.
hope this helps,
Norbert
01-05-2012 05:18 AM
Hi Tom,
If you would like a more comprehensive reply to your question please create a new thread. The initial question in this thread has already been answered so you will get a better response from the community by making a new question.
Many thanks,
01-05-2012 10:23 AM
Thanks Norbert,
I thought that would be the case too, but it appears that seperate teststand executions do not share the same copy of the re-entrant VI.
01-09-2012 02:38 AM
Re-entrant VIs are never shared. Not in LV, not in TS.....
The FGV MUST NOT BE RE-ENTRANT.
Norbert
01-09-2012 10:05 AM
It looks like I misunderstood your first post. Can you explain how to make a FGV without making it re-entrant?
01-11-2012 02:57 PM
@twilson1111 wrote:
It looks like I misunderstood your first post. Can you explain how to make a FGV without making it re-entrant?
Thats like asking how to make apples that are oranges. If the vi is re-entreant it is not a FGV since a FGV is defined as a vi with a USR that has only one copy of itself in memory. By making it places at least TWO clones in memory and there is no way to share the data on both shift registers.
There are two methods. With Pre-allocate clones each call in each test socket will have its own clone
With Share Clones Clones are spawned as needed so that no calls are ever blocked. Your test step module loading/unloading options will determine when the clone "cloud" spawns new clones (as they are reserved not as they are called from the sequence)