LabVIEW
is it feature or bug with reference?
I assumed to get 2 different references but LabVIEW gave the same reference (address 0x9949999B) and values in clusters are the same.
Is it feature or bug?
P.s. if Connect.vi will be reentrant than LabVIEW will give 2 different references.
Hi Vasilich,
it's a feature…
When a VI is not reentrant then only one instance is in memory and will give you the same reference to the very same object.
As soon as you set it reentrant multiple copies of that VI will be in memory, eachone providing a reference to its own object…
A Control/Indicator reference is a reference to the front panel object. If you only have 1 object (even though you use it twice), you only have 1 reference.
Two different ones, usually, but not necessarily, unless you execute both really in parallel. Shared reentrant is still reentrant. The difference is how the reentrant clones are managed.
For shared, LabVIEW maintains a pool of clones and whenever the pool is empty it creates a new clone when a new instance is needed. When that instance goes idle (waiting to get called) LabVIEW adds it back to the pool.
For fully reentrant, each location gets a copy of a clone allocated at load time.
This mean that shared clones can use significantly less memory as LabVIEW only allocates as many as at any moment are really used in parallel. But execution performance can be less predictable as LabVIEW has to check the pool and possibly instantiate a new clone at runtime. Also shared clones can cause data leakage (uninitiated shift register) between executions as an actual instance is not always used in the same spot.
@Vasilich2004 wrote:
There 3 Reentrancy options. Middle option is "Shared clone reentrant execution". What would be LabVIEW behavior in this case?
This blog entry is a decade old, but still quite revalent (only linking to part 1 of 5): https://stravaro.com/lvjournal/2012/02/maintaining-state-1/
@JÞB wrote:
@GerdW wrote:
Hi Vasilich,
it's a feature…
When a VI is not reentrant then only one instance is in memory and will give you the same reference to the very same object.
And I will expand on why this FEATURE helps you. How many hairs would you loose if the integer value of a reference wire output from a VI changed each time you called the same vi on the same target in the same context from the same application instance?
Not sure about your or my hairs in respect to this. 😁 But it would be a major memory hog for sure and a total pitta as you would have to Close each of these references explicitly to not create a huge memory leaker!
Saying that either of these is incorrect is factually incorrect. 😀
It actually works exactly as intended! That it is not what you want is another matter. For what you want, shared clones is simply the wrong choice.
Shared clones still can work in parallel when this is possible according to dataflow rules, but you don’t get an exclusive copy for every possible call site. As long as there is no effective parallelism, LabVIEW will happily use the same clone for each call site.
