Many native VIs that are currently Non-reentrant should be Preallocated clone

[Petru_Tarabuta]

Problem: Many native VIs use the Non-reentrant execution reentrancy setting.

Solution: The vast majority of native VIs should use the Preallocated clone reentrancy setting.

• The native VIs that need to use Non-reentrant or Shared clone are few and far between - they should be identified on a case-by-case basis. Their Context Help and/or Detailed Help should explain why they need to be set to Non-reentrant or Shared clone.

The following is a selection of vi.lib VIs that should use Preallocated clone. This selection is meant to serve as a starting point and is not comprehensive.

Notes:

• This idea is related to: The reentrancy of new VIs should be "Preallocated clone" . They both argue in favour of using the Preallocated clone setting more.
• A significant number of native VIs are already configured to use Preallocated clone, which is great.
• There are curious cases where closely related VIs are set to different reentrancy settings. For example, Color to RGB.vi is rightly using Preallocated clone, while RGB to Color.vi is Non-reentrant. Similarly, Trim Whitespace.vi is rightly Preallocated clone, while Normalize End Of Line.vi - which lives next to it on the String palette - is Non-reentrant.
  • This suggest that the reentrancy setting of some native VIs was chosen haphazardly. This needs to be rectified.
• The fact that so many native VIs are non-reentrant partly defeats LabVIEW's remarkable ability to create parallel code easily. Loops that are supposed to be parallel and independent are in fact dependent on each other when they use multiple instances of these non-reentrant native VIs. When an application uses multiple instances of these native VIs it is as if there are "hidden semaphores" that are added between the various call locations that call these native VIs. This leads to less performant applications (more CPU cycles, longer execution time, larger EXE compiled code size).

[Mads]

Yes, that is true and the clone *has* to be opened for it to "retain its state"..If  you forget to open it prior to running the caller the reentrant VI will not show its inputs if you open it afterwards (which can be inconvenient at times; you ran and now you want to see its inputs, but you had not opened its front panel so now you have to start over).

So the solution where you get to choose in an efficient way (keyboard shortcut would probably be the most efficient) whether to open clone or original is better.

(This is with preallocated, the shared clones are (even) more difficult creatures 😮 Having a way to temporarily make all shared clones preallocated to aid in debugging, but then switch back to save memory might be an idea...Another side issue here is that if you create VIs out of a section from another VI it inherits the reentrancy...So everytime you do that e.g. in a DQMH cloneable module you get shared reentrancy...is a bit tedious too, maybe it should ask what reentrancy you want on the subVI creation :-O)

[wiebe@CARYA]

I agree it's messy.

Often those clones can't be ran (run is disabled) for no reason (esp. with DD clones it seems, often when stopped with a breakpoint). Shift-dropping the clone from it's icon on a untitled vi should drop the VI with constants containing the current control values, but this fails too. So now you have to manually copy data and paste each input.

I haven't linked this to the panel open or not, I'll have to check. It might be a workaround (if you don't mind a 2nd run).

I wouldn't mind if these bugs and\or workflow issues got fixed...