Skip to content

Maintaining State Information in LabVIEW Applications, Part 4

by Brian on June 5, 2012

Let’s summarize where we are so far…

In part 1, we started talking about VIs that maintain state information from one call to the next.  I want to clarify that there are two different kinds of such VIs.  Sometimes you want global state—no matter where the VI is called anywhere in an application, you want its state to be shared among calls.  This is what a functional global variable is.  FGVs are, in general, not reentrant, to protect against parallel access to the global data.  In part 1, I introduced a different flavor, where you don’t really want to share data across all calls; you wanted each call to have its own state, but you wanted each instance to maintain state between calls.

In part 2, we learned why VIs like this have to use preallocated clones, not shared clones. But what are the downsides of always using preallocated clones? What does “reduces memory usage” mean?


Suppose we have a calling hierarchy like this, where the VIs “B’” and “C” are reentrant with preallocated clones…


There is one clone of B and three clones of C in memory.  (There’s actually a second copy of B and a fourth copy of C in memory—the original VIs, even though they won’t be run in this case.)

What if I want to make a second call to B?  Now my hierarchy looks like this…


We can see here that preallocation is recursive.  Two copies of B means six copies of C.  Imagine that you need to add more calls to B or C in your application, and you can see that the number of VIs starts to grow exponentially…


As this scales to thousands of VI clones, at some point you have to make a time vs. space tradeoff.  Preallocated clones give you the maximum parallelism without spending runtime processing on allocating more clones—but at the cost of memory.  Given that your computer has a small, finite number of cores it can use, is it worth it?

The answer for you depends on your application, but what if you could have the benefits of shared clone reentrancy, and still maintain state per call?  We’ll look at that in the next post.

From → Programming

Leave a Reply

%d bloggers like this: