I think part of the confusion with reentrancy has to do with its changes through the history of LabVIEW. Before LabVIEW 8.0, you couldn't debug reentrant VIs, which made them much more difficult to use. Also, before LabVIEW 8.0, you couldn't view a reentrant VIs front panel, which made it impossible to use for dynamically spawned dialogs. That also made it difficult to do pseudo-debugging by viewing front panel controls to track the progress of the VI. The workaround in case of dynamically spawned dialogs was to use template VIs.
LabVIEW 8 helped make reentrancy more usable. You can now debug reentrant VIs (except when deployed to RT, I believe) and view their front panels. This makes them a more attractive option for dynamically spawned dialogs than template VIs. When opening a template VI, LabVIEW had to make a copy of the entire VI's data space, code, front panel, etc. With reentrant VIs in LabVIEW 8.x (to the best of my knowledge), LabVIEW only copies what's necessary. It doesn't need to duplicate the code itself, just the data space. And if the front panel isn't open, then LabVIEW doesn't need to copy that either for reentrant copies.
LabVIEW 8.5 added yet another piece to the puzzle for reentrancy. That's the ability to share clones. This might be confusing to some, but very powerful to others. Reentrant VIs allow you to call the same subVI concurrently in multiple places, but the downside is that every instance on the block diagram creates a separate copy of the necessary resources. So if you call your subVI in 100 different places, you'll get 100 copies, even if you only expect a few of those copies to ever execute concurrently.
The Share Clones option tells LabVIEW to only make copies when all the existing copies are in use and another call needs to be made. In other words, if I have 100 different calls to a Share Clones reentrant subVI, then LabVIEW will start off with only 1 copy of that subVI in memory. As soon as that copy is being called by A, and B wants to make a call to it, you'll get your second copy so B doesn't have to wait for A. If A finishes executing its copy, and C tries to call the subVI while B is still calling it, then C can call A's copy, since it's no longer in use. This allows a minimal amount of subVI resources to be loaded, while maintaining the ability to call a subVI concurrently.
The downside here is that you really don't know which copy you'll end up getting. A might get copy 1 now, but copy 2 or 3 later. This means you can't rely on cached data in the subVI, such as uninitialized shift registers that store data from a previous run. You can't be sure that previous run was your previous run, or if this copy has ever had a previous run.
Sorry if this post is more confusing than helpful, but reentrancy is a powerful tool that should be explored.
Jarrod S.
National Instruments
