Troubleshoot reenterant vi

[NutmegPickles]

I inherited code and have come across a vi that is reenterant and called about 8 times.  When I probe the vi, I see a number of values change and not what I would expect, this includes a value that is set right outside the vi and should not change. 

Is this because when I watch the vi I am watching every instance of this reenterant vi?

Thank you for your time,

[Yamaeda]

Basically, yes.

If you place a breakpoint inside the VI you'll get one popup per instance and it'll be named [vi name]:4 or similar in the window title.

While debugging it's common to turn off the reentrancy, though it's not possible in a recursive scenario. I do hope you're not keeping any data internally, that's bound to cause problem in a reentrant VI.

/Y

[billko]

---

@Yamaeda wrote:

Basically, yes.

If you place a breakpoint inside the VI you'll get one popup per instance and it'll be named [vi name]:4 or similar in the window title.

While debugging it's common to turn off the reentrancy, though it's not possible in a recursive scenario. I do hope you're not keeping any data internally, that's bound to cause problem in a reentrant VI.

/Y

---

I think you're safe if the re-entrancy is "pre-allocated clone".  It gets "interesting" if you forget to set that.  😉

[crossrulz]

How are you probing the VI?  You should only be able to effectively probe a clone of the VI.

What type of reentrancy are you using?  If using Shared Clone, then you could just be reusing the same clone at each call.  This would show what you are describing.  If using Preallocated Clone, then I would not expect this.

[prettypwnie]

It sounds from your description like you may be talking about a "non-reentrant" VI - since you said you are able to probe it and you are seeing values from multiple different places where the VI runs (though this could also happen if it is shared clones reentrant and you have a clone open).

Press ctl+i to open VI properties and go to the Execution tab, and tell us which option you see selected there.

[billko]

https://zone.ni.com/reference/en-XX/help/371361R-01/lvconcepts/reentrancy/ Note "Shared Clone Reentrancy".

Usage Considerations	Non-reentrant	Shared Clone Reentrancy	Preallocated Clone Reentrancy
Ability to maintain state, such as in uninitialized shift registers	Maintains a single instance of the data space and uses its state across all call sites.	Does not maintain state—Each call site pulls the data space of a clone randomly from the pool of clones. Call sites may end up sharing state.	Maintains state for each call site—Each call site has its own separate and specific clone.
Determinism for multiple, simultaneous calling VIs	Call sites might wait in line behind other simultaneous callers—The time required for an instance of a subVI to begin executing varies with how many other instances are scheduled to execute before it.	Possible waiting—Call sites may need to wait for LabVIEW to create a new clone if the pool of clones is empty. When the pool is not empty, pulling a clone and returning the clone to the pool can introduce non-deterministic delays.	No waiting—LabVIEW allocates a clone for each call site prior to execution. This allows deterministic memory usage and execution speed.
Call overhead when no simultaneous calling VIs exist	Medium—LabVIEW must check for simultaneous callers.	Highest—LabVIEW must atomically pull clones from and return clones to the pool of clones. Calls may need to wait for LabVIEW to add a clone to the pool.	Lowest—LabVIEW already preallocates a clone to each call site.
Memory usage	Lowest—LabVIEW allocates only a single data space for the subVI.	Medium—LabVIEW must allocate clones only for the maximum number of instances running simultaneously.	Highest—LabVIEW must allocate a clone for each instance of the subVI.

[Bob_Schor]

This is a wonderful example of you, the Poster, asking a question about something you might not completely understand, and "blinding" us to your situation because you do not post your code.  If you had attached your VI, along with enough other code to show us where and how this VI is called, we could probably help you both understand it and fix it.

Attach your VI, please.

Bob Schor

[NutmegPickles]

Thank you for all your input, this helps me out greatly. 

BTW, I am not able to share code as my work does not allow it for security reasons and from all the answers (correct I might add), I don't think anyone was blinded...