Skip to content

Maintaining State Information in LabVIEW Applications, Part 3 (More on Shared Clones)

by Brian on May 29, 2012

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…

  1. When are shared clones allocated?  How many are allocated?
  2. When are shared clones deallocated?
  3. How do shared clones behave inside timed loops?
  4. 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.

2 Comments Leave one →
  1. Bob Schor permalink

    Nice discussion. I recently worked on a project using a video camera to monitor animal behavior, taking a 10″ video when “something interesting happens”. We have 24 “stations” set up, each with their own video camera.

    I wrote a “Capture Event” VI that handled a single station, with the idea of making it reentrant and having VI Server call as many (up to 24) clones as I had animals to study. The event-driven nature of this task (the “something interesting” triggers occur about once/minute for each station, asynchronously).

    I converted the VI to a VIT, and “invoked” it from VI Server. I did not do anything special such as wiring 0x40 to the Options input. Am I fooling myself, thinking that I have (up to 24) clones running in parallel?

    A discussion of VI vs VIT for parallel execution of tasks would be welcome.

    BS

  2. Ah yes, the old “instantiate a template” trick. This is doing what you think it’s doing, so you’re not fooling yourself.

    However, my understanding is that it’s not as efficient as the newer method of using the 0x40 option. You are instantiating a whole new VI each time, not just a clone of the data space and panel. For some applications, the performance difference matters.

Leave a Reply

Note: HTML is allowed. Your email address will not be published.

Subscribe to this comment feed via RSS

This site uses Akismet to reduce spam. Learn how your comment data is processed.