Maintaining State Information in LabVIEW Applications, Part 3 (More on Shared Clones)
In part 2 of this series, I showed how shared clones can’t be used for VIs that maintain internal state. I want to explain a few more details about how shared clones work by answering a few common questions…
- When are shared clones allocated? How many are allocated?
- When are shared clones deallocated?
- How do shared clones behave inside timed loops?
- How do shared clones work with the VI Server?
1. When are shared clones allocated? How many are allocated?
When you set a VI’s properties to be reentrant with shared clones…
LabVIEW creates a “clone pool” with a couple of clones that can run the VI when it’s called from various diagrams. When a diagram wants to execute this subVI, it checks out a clone from the pool and uses it to run the VI. When the subVI call finishes, the clone is checked back in.
If more than two calls are needed at the same time, the next call will create a new clone, and after the call completes, this new clone will be added to the clone pool. So basically, the clone pool grows to the right size to accommodate the maximum number of calls that actually happen in parallel.
2. When are shared clones deallocated?
Clones aren’t deallocated until the VI they are associated with is unloaded from memory. LabVIEW makes the assumption that the calling profile doesn’t change much over the course of the application. It’s also somewhat time-consuming to create a new clone, so we err on the side of keeping the clone in memory for future use.
3. How do shared clones behave inside timed loops?
Timed loops are generally used when you want more deterministic timing, so we actually preallocate reentrant VIs inside timed loops. By preallocating, we eliminate the possibility of having to spend time inside the loop allocating a new clone. So even if you set the VI to use shared clones, calls inside the timed loop will preallocate their clones, while calls outside timed loops will share clones.
4. How do shared clones work with the VI Server?
By default, when you open a VI reference with the VI Server, the reference won’t be marked as reentrant. This is true even if the VI’s properties are set for it to be reentrant. So even if you forked the reference wire and tried to call the VI with the VI Server multiple times in parallel, they would execute in a serial fashion.
You can change the default by wiring the numeric value 0x40 to the “options” input of the Open VI Reference function. If the referenced VI is set to reentrant execution in the VI Properties, then with the 0x40 option, the reference can then be used to call the VI in parallel through the VI Server.
Read the help documentation for Open VI Reference for all the details on the “options” input.
What other questions do you have? I still owe you an explanation on the potential memory savings between shared and preallocated clones. Keep reading in part 4.