What happened if i check the property called Reentrant in SubVI's?

[subbu]

I am calling the SubVI called "Addition.Vi" from the Main VI two times. In first case i haven't checked the property Reentrant and i am executing the main program. So only one instance will be created and the SubVi's will be executed sequentially. In second case i checked the property Reentrant in SubVI. So multiple instance will be created and the subVI's will execute simultaneously. Here my question is is there any difference in memory usage for both the cases?

[Mads]

Yes, you can pretty much multiply the memory footprint of the reentrant VI with the number of instances you have. In other words having 50 instances of a 300K VI will cost you quite a bit of memory...if the VI is smaller it's not that much a worry though.

[rolfk]

Mads wrote:

> Yes, you can pretty much multiply the memory footprint of the
> reentrant VI with the number of instances you have. In other words
> having 50 instances of a 300K VI will cost you quite a bit of
> memory...if the VI is smaller it's not that much a worry though.

It is not as bad as that 😉 If you look in VI properties you can see a
VI consists of Frontpanel, Diagram, Data and Code Space. Reentrant VIs
will mostly duplicate the Data Space part plus maybe some extra
management space but that shouold mostly be it. Both the Frontpanel and
Diagram Space as well as the code itself are certainly NOT duplicated.

Rolf Kalbermatter

[Greg_McKaskle2]

> I am calling the SubVI called "Addition.Vi" from the Main VI two
> times. In first case i haven't checked the property Reentrant and i am
> executing the main program. So only one instance will be created and
> the SubVi's will be executed sequentially. In second case i checked
> the property Reentrant in SubVI. So multiple instance will be created
> and the subVI's will execute simultaneously. Here my question is is
> there any difference in memory usage for both the cases?

Rolf accurately summed up what is duplicated and what isn't. But the
bigger issue is when to use reentrancy.

As usual, the first issue to deal with is correctness. Memory versus
performance tradeoffs are one thing, but making your program produce
incorrect results is a bigger issue.

One way to characterize a VI is -- functional or nonfunctional.
Functional VIs are of the form y= f(x). For the same x, they will
always produce the same y. Nonfunctional VIs such as a running average
or a DSP filter do not do this, the history of previous calls will
affect the result of a given call. Nonfunctional VIs can be represented
as y= f(x,state), and can be implemented functionally so that state is a
parameter, either the state info or a reference to the state. Or they
can be implemented so that the block on the diagram "holds" the state.

With a functional VI, you can change reentrancy without affecting
anything but the memory/versus parallelism tradeoff. If you change
reentrancy on a nonfunctional VI, you just made a big change to the
behavior. Take a LV2 style global for example. Nonreentrant, and every
reader sees the last writer. Make it reentrant, and nobody talks to
anybody else, all readers get the initial value, and the writers send
the data to their own copy. This VI works as intended only when
nonreentrant.

Now lets look at a running average. If reentrant, each call drops off
new points for a channel and returns the running average for that
channel. Drop a second and it works independently on a separate channel
of data. Make the running average nonreentrant, and you are now
combining the channels into one and returning the average of that data
stream, which will probably produce very odd results. This VI works as
intended only when reentrant.

So the point is, before worrying about perfomance and parallelism, make
sure your VI is functional first. If it is nonfunctional, the
reentrancy only makes sense one way, and the compiler can't tell which
makes sense, only the designer of the VI.

Greg Mckaskle