Maintaining State Information in LabVIEW Applications, Part 2

In the first part of this discussion, I ended with homework that asked questions about shared clones and whether they would work for the running average I was trying to compute per channel. I included a graph showing that the filters worked correctly when set to use shared clones.

As answered in the comments, using shared clones is wrong in this case.  But why was the graph right?

LabVIEW allocates more than one clone to handle the VIs wanting to run in parallel.  Further, since I didn’t have anything else happening in my system, LabVIEW reused the respective instances for each call, as opposed to swapping clones all the time. The top subVI happened to use clone “A” every iteration, and the bottom subVI used clone “B”.  (“A” and “B” aren’t official LabVIEW terminology; I’m just using it for this blog post.)

With shared clones, LabVIEW doesn’t guarantee this behavior.  If I had run the VI longer, there’s a reasonable chance that LabVIEW would swap the clones while executing, or introduce a clone “C” to help out.  If that happens, then we’ll start computing incorrect values in the filter, and the data might look like this…

For this particular application, if we want the Running Average VI to be reentrant, then we should set it to use preallocated clones. In the VI Properties dialog box, that’s what we mean by “maintains state for each instance”.

Next up in part 3, more on shared clones and when they’re a good idea.