"In other words, does the reentrancy get passed up the chain?"
My understanding of reenetrancy says it should.
I never used it like that before, but I created little program that
duplicates the scenario you put in the post, and it worked correctly,
as I expected. I passed data thru terminals to g
The thing you have remember is that even though there are only two
instances of =91S=92 in the code of =91C=92, there are two instances of =91=
C=92
(if set to reentrant) in the code for =91M=92. So each instance of =91C=92
will have its own data space within =91M=92, and as it loads its subVIs,
it
OK - that occurred to me that there could be 4 values of V, but I
wasn't sure. (It's good in my case).
I had always thought about it in terms of callers - there is one V for
each caller instance. But if the caller is reentrant itself, then S
has FOUR callers, EVEN THOUGH there are only two instanc
OK, thanks.
The confusing thing for me is that S would have FOUR callers (and thus
FOUR values of V), even though there are only TWO instances of it in
the code.
This could get confusing quick, but I think I understand how it all
works.
The reentrant property does not affect any callers or callees'. It
strictly on a VI by VI basis.
In your last example, there would be 4 values of 'V', since both C and
S are reentrant, 'M' would call two instances of 'C',
I understand some things about reentrancy:
Say my SubVI "S" has an uninitialized shift register that is supposed
to remember some value "V" from one call to the next.
If S is normal (not re-entrant), and S is called from two or more
places, then there is only one V - each caller would interact wi
