The reentrancy of new VIs should be "Preallocated clone"

[Petru_Tarabuta]

Problem: When creating a new VI using File >> New VI (Ctrl + N) its reentrancy setting is Non-reentrant execution.

Solution: The reentrancy setting of new VIs should be Preallocated clone reentrant execution.

Background:

In most applications the vast majority of VIs could and should be set to "Preallocated clone reentrant execution". In a nutshell, Preallocated clone ensures that each instance of a given VI is completely independent of all other instances. This is desirable in the vast majority of cases.

We should encourage best practices by changing the default reentrancy setting to the setting that is desireable in most cases, namely to Preallocated clone.

The other two options - Non-reentrant execution and Shared clone reentrant execution - are the best choice in specialised cases only.

• Non-reentrant is necessary when needing to guarantee that multiple instances of a VI block each other from executing at the same time and/or when wishing to use uninitialised shift registers as a means of asynchronous data communication (e.g. FGV or Action Engine).
• Shared clone is best when aiming to reduce memory usage. Shared clone can help on memory-scarce targets such as cRIOs or sbRIOs, or when dealing with massive amounts of data (arrays of millions or billions of elements). Worrying about memory usage is not a concern for the vast majority of VIs, especially when working on modern desktop systems that have 8, 16, or more GB of RAM memory, and when dealing with reasonable amounts of data (arrays with up to a few million elements).

New VIs set to Preallocated clone would be in good company, as detailed below.

• The vast majority of LabVIEW nodes rightly execute as if they were set to Preallocated clone. This enables us to use many instances of each node freely without worrying that it will create timing dependencies between vastly different caller VIs.
  • For example, one can use the Add node inside as many DQMH modules or Actor Framework actors as they wish, without creating any timing dependency between those callers, which is great.
  • As far as I am aware, the only nodes that execute as if they were set to Non-reentrant are those that require the UI thread. These nodes execute in a sequential, blocking manner.
• Many of the VIs that ship with LabVIEW are rightly set to Preallocated clone.
  • I believe that most VIs that ship with LabVIEW and are set to something other than Preallocated clone should be set to Preallocated clone, but this should be addressed in a separate idea.
• All inlined VIs (and therefore, all VIMs, which must be inlined) execute as if they were set to Preallocated clone.

Further notes:

• If Non-reentrant was chosen as the default because it was judged to be the friendliest to new users (an argument that I believe does not outweigh the arguments in favour of Preallocated clone), then at least there should be a Tools >> Settings option to enable people to change the default reentrancy setting.
• The fact that new VIs are by default Non-reentrant defeats the benefit that LabVIEW offers in terms of ease of creating parallel threads. Many of these threads will in fact not be truly parallel, because of the undesired one-instance-running-at-a-time blocking effect of Non-reentrant instances that execute in vastly different areas of an application.
• I have never tested this, but EXEs are likely to be smaller (perhaps by a few KB, or even a few hundred KB) when the vast majority of VIs are set to Preallocated clone. When using multiple instances of Non-reentrant VIs LabVIEW must add some kind of mutex'es (mutually exclusive locks) in the compiled code. When VIs are set to Preallocated clone these mutex'es disappear, leaving behind smaller, cleaner compiled code.
• The disappearance of mutexes might help enable the LabVIEW compiler to perform optimisations that are not possible when non-reentrant boundaries are present.

Reentrancy resources:

• Reentrancy: Allowing Simultaneous Calls to the Same SubVI
• Got Bitten: VI Reentrancy

[OneOfTheDans]

Strongly, strongly disagree with this.

It's great that you've "leveled up" in LabVIEW such that your code would benefit from Preallocated Clones everywhere. But clones are much harder to work with and harder to troubleshoot. This change would not serve the bulk of beginner and intermediate LabVIEW users. The advanced users (such as yourself) can already easily identify if/when such feature should be used.

Expanding on the ideology a bit, LabVIEW is a physical representation of code. That's why it's visual, and why 1 file = 1 Virtual Instrument. This is what makes it more approachable for engineers with limited to no software background. In the most intuitive sense, if you want a 2nd virtual instrument, you would duplicate the VI (file). But if you call the same VI (function) twice, it should be *the same* VI (function), not 1 of N different clones.

Practically speaking, I've LabVIEW-mentored coworkers with a range skill levels at a couple companies & industries over the years. None of their problems have ever been caused by non-reentrant VIs. On the other hand, many have sworn off the entire Actor Framework because it seems to behave erratically and is difficult to troubleshoot <-- because Actor Core is a shared clone!

[Petru_Tarabuta]

Hi OneOfTheDans,

Thanks for your detailed and thoughtful reply.

"...such that your code would benefit from Preallocated Clones everywhere." - It is not just the code of advanced users (such as you and me) that would benefit. My argument is that the vast majority of VIs, be them created by a beginner or by a guru, benefit from using the Preallocated clone setting. Or, to be more precise, it is the application that benefits. It is the application - the "orchestra" of VIs - that suffers due to so many VIs being set to Non-reentrant.

"But clones are much harder to work with and harder to troubleshoot. This change would not serve the bulk of beginner and intermediate LabVIEW users." - I agree that clones are harder to work with, and by this I think we both refer specifically to debugging/troubleshooting them. This is unfortunate, and it would be great if future versions of LabVIEW reduce this barrier. Having said this, debugging Preallocated clone VIs is possible (it is possible to put down probes and breakpoints). Moreover, the reentrancy setting makes no difference in terms of the ease of creating Unit Tests for that VI - a practice that is rightly becoming more and more popular in the LabVIEW community.

"Expanding on the ideology a bit, LabVIEW is a physical representation of code." - I fully agree. Non-reentrant VIs are in fact betraying this! Imagine a beginner or intermediate user who has not yet appreciated the subtleties of the different reentrancy settings creating a Main VI that consists of two parallel while loops. The first loop calls VIs A.vi, B.vi, and C.vi. The second loop calls VIs D.vi, B.vi, and E.vi (notice that B.vi is used inside both loops). In the beginning all these VIs (A.vi to E.vi) are Non-reentrant. To the user it seems that the loops are executing perfectly in parallel, completely independently of one another. This is confirmed by what the user sees: There are no wires between the loops. However, the fact that both loops call B.vi puts a timing dependency between the loops. The loops execute partly in parallel, but partly by waiting on one another. The code is equivalent to the user having surrounded the B.vi call with an Acquire Semaphore and Release Semaphore pair of VIs. If the semaphores were in place the user would notice: there is a semaphore reference wire being shared by both loops. This means the loops use a shared resource, therefore they are not truly independent.

This is the betrayal of non-reentrant VIs. They make it seem like things run in parallel even when they don't.

Now, imagine that the user realises all the above and changes the VIs to use Preallocated clone. Now their two loops are truly independent of one another, just like the visual representation of the code suggests. There are no "hidden semaphores" lying around.

"None of their problems have ever been caused by non-reentrant VIs" - I fully agree that the results produced by most VIs are identical regardless of the VI's reentrancy setting. In other words, the reentrancy setting rarely affects the correctness of the code (the ability to produce correct results). I agree that avoiding to use Preallocated clone will not cause bugs in people's code. However, not using Preallocated clone does affect the code, namely the performance or computational efficiency of the code. An application that reuses non-reentrant VIs in multiple locations (a practice that is rightly common) is in fact an application that is teeming with "hidden semaphores". These "hidden semaphores" make the code use more CPU cycles (and electricity) than needed, slow down the code (in some cases significantly when one or more of the non-reentrant VIs are slow to execute), and bloat the EXE (more bytes in the compiled code to account for all the mutex'ing).

The original post mentions "...then at least there should be a Tools >> Settings option to enable people to change the default reentrancy setting." - this would be a valuable improvement in its own right.

An anecdote: I recently interacted with an experienced LabVIEW programmer (I believe he has been programming in LabVIEW for around 10 years, and has been programming in other languages for more than 20 years) who was aware of the three reentrancy settings, but was preferring to use non-reentrant because he didn't like the way that, when double-clicking a cloneable subVI on the block diagram, it sometimes opens in "Run mode". Whenever a cloneable VI opened in "Run mode" he would navigate to the Project Explorer window to open the VI from there in Edit mode. I pointed out that he can simply press Ctrl + M to change to edit mode. This pain point was removed and he became less apprehensive about using clones. I guess this shows that we as a community need more awareness of working with clones?

[Petru_Tarabuta]

A couple of additions to the original post:

• Another valid reason for using Shared clone re-entrancy is in Dynamic Dispatch VIs. DD VI's are not allowed to use the Preallocated clone setting (the VI will have a broken arrow).
• An interesting observation is that all three re-entrancy settings are equivalent to each other when only one instance of a VI is being called in an application (i.e. when a subVI has a single call location). For example, an application may consist of ten loops running in parallel. If only one of these loops calls a single instance of a VI named A.vi, it doesn't matter which re-entrancy setting A.vi uses. The application would behave identically regardless of A.vi's re-entrancy setting. However, the application may start to behave differently as soon as A.vi is called in two or more code locations. These code locations could be distributed inside the same loop or across different loops.

[fefepeto_kb]

I think this is a very deep rabbit hole of debates, and will be very hard to draw conclusive agreement, but here are my counter arguments:

• Many time it is not the VI itself, but the underling memory/file/hardware management that is stopping the call from being parallel anyways, like TCP calls on the same LAN adapter, or file calls on the same file, etc.
• Comparing some of the "nodes" on the screenshot to VIs is not fair, since operators like +, -, <, etc. are actually very low level commands supported by the CPU, and described in the instruction set. Also they are implemented for each core independently.
• For very small code and large VIs parallel execution is actually worse then non-reentrant execution. The reason is that preallocated execution means the compiler will come up with an estimation on how many clones to open at the start of the application. Any time a clone has to be called the application has to check whether a clone is available or all of them are executing, yes, here is a mutexing as well. If no available clones exist in memory, then the VI is opened again, which means memory allocation, and having both the code and data (variables or wire in LV) in the RAM, that has to move trough the cache, and yes, clone 1 might run on CPU 1 in the first iteration, but then might be scheduled to run on CPU 7. That's why FGVs shall never be reentrant, because the sate in memory cannot be guaranteed. Also, large complex VIs are not recommended to be inlined, since it will clutter the memory, but would rarely benefit the execution.
• Data integrity is a big problem with parallelism and is always handled  for RT applications in different ways, which are either processor or memory dependent to solve the issue.
• Another perspective is the parallelism in other languages. Most of the languages are not parallelizing the execution by default, and understanding parallelism when coming from other languages would be very confusing. In C# for example parallel executions need the definition of new thread, or explicitly defined parallel loops.

Summing it up, parallelism helps our code to perform better, but it is not a universal solution and shall be understood well to be used effectively. LabVIEW hides some of this, but if you have 10 loops that do enough processing in the background and all call A.VI you can check with DETT or a similar tool that it can achieve this feat with only 3 clones of VI A.

[wiebe@CARYA]

Personally, I only make VIs reentrant if I have to. I never like that I have to.

As most of my code is in classes and most of my reentrant methods are DD, I'd wouldn't like preallocate to be the default.

I suppose it wouldn't hurt to have the default new VI reentrancy (non\shared\prealloc) as an option. Then we can of course debate the default. I'm pretty sure mine will be set to how it is, at least most of the time.

[GregRichardson]

As has been pointed out elsewhere, there are reasons to select all 3 reentrancy choices.

• Non-reentrant - Easiest to develop and debug, lowest memory usage, required for patterns like functional globals and serializing access to singleton resources.
• Preallocated reentrant - Allows reentrancy with maximal performance at the possible expense of excessive memory usage.
• Shared reentrant - Required for recursion, can reduce memory usage in deep hierarchies compared to preallocated.

Best results for both execution and development require active management of reentrancy regardless of which setting is the default. Sticking with the existing default makes sense to me. If you still want to change that, learn more about the "lv_new_vi.vi" plugin which can be used to customize new VIs when they are created.

[Christina_R]

See comment from GregRichardson

[Petru_Tarabuta]

For anyone that may be interested: The idea above and this idea sparked a long discussion about non-reentrant vs preallocated clone in the #water-cooler channel of the LabVIEW Discord Server. Screenshots of this discussion were attached as comments to the other idea (since this idea has been declined, and the other idea is still active).