SubVI's of reentrant VI's - super basic question

[PaulOfElora]

A nagging question occurred to me this morning.  I have several (preallocated) clones of reentrant VI's running.  I understand that each reentrant clone gets its own data space.  But what about the 20 or 30 subVI's of these reentrant clones?  Does the compiler know that I need for all subVI's to have their own data spaces as well?  Or do I have to go thru and set all the subVI's to reentrant as well?  Thanks guys, paul

[Worle]

All the Sub VI's will behave as per the settings in the VI Excecution tab of the VI properties window.

If you Non-reentrant set in the sub-vi it will occupy the same memory space as all the other instances of this VI, even though it is been called by a reentrant VI (Shared or preallocated)

This means that if you are setting reentrancy to try and speed up excecution it will not see the maximum speed improvements unless all of the sub-vi's are rentrant as well.

You may find that some VI's that ship with labview aren't reentrant and are password protected so you can't change their properties (I have come accross this with alot of the picture functions)

[crossrulz]

Here's the start of a good blog series that will give you more details than you probably care to know: https://stravaro.com/lvjournal/2012/02/maintaining-state-1/ 

[billko]

I think it's safe to summarize that if anything in the re-entrant subVI is not re-entrant, itself, then the subVI itself behaves as if it is not re-entrant.  (It's not technically true, but for all intents and purposes, it feels the same.)

[PaulOfElora]

Thanks crossrulz, you're always helpful to us newbs - paul

[PaulOfElora]

Thanks Billko, I was somewhat intuitively afraid of that.  All my nice shiny top-level VI's need some more work!

[RavensFan]

You probably don't need to go any make every sub-sub-VI call re-entrant.

Let's say you have a subVI that does a lot of work that takes some time.  You want to run multiple instances of it to share the load.  Inside of it, you have a subVI that you use a lot, but doesn't take a long time to run.  Perhaps milliseconds to do something like a comparison or round off a numeric value.  It's percentage of time executing is very small compared to the time of the larger subVI running.  There is no need to make that re-entrant, the likelihood of multiple larger subVI's hitting that same non-reentrant small subVI at the same time is low.  And if it does happen, then the 2nd big subVI to get to it will wait at the call, but only for a very short period of time since that subVI is so fast.

You might also be able to Inline that small subVI which will effective make it an integral part of the large subVI.

I have not come across any situation where I needed to do this, so I don't know if there are any gotcha's.

[billko]

---

@RavensFan wrote:

You probably don't need to go any make every sub-sub-VI call re-entrant.

Let's say you have a subVI that does a lot of work that takes some time.  You want to run multiple instances of it to share the load.  Inside of it, you have a subVI that you use a lot, but doesn't take a long time to run.  Perhaps milliseconds to do something like a comparison or round off a numeric value.  It's percentage of time executing is very small compared to the time of the larger subVI running.  There is no need to make that re-entrant, the likelihood of multiple larger subVI's hitting that same non-reentrant small subVI at the same time is low.  And if it does happen, then the 2nd big subVI to get to it will wait at the call, but only for a very short period of time since that subVI is so fast.

You might also be able to Inline that small subVI which will effective make it an integral part of the large subVI.

I have not come across any situation where I needed to do this, so I don't know if there are any gotcha's.

---

I think that encapsulates it better than my general rule.  I guess what I said made sense to me because it's always when I have a "slow" subVI that I notice the issue.

[PaulOfElora]

I like the in-lining approach, might get a little speed boost out of it.

[wiebe@CARYA]

---

@PaulOfElora wrote:

I like the in-lining approach, might get a little speed boost out of it.

---

At the expense of extra compile time.

And you'll loose the ability to debug the VI (probes, FP values, breakpoints, etc.).

You can't inline everything. VIs containing property nodes, invoke nodes, expression nodes (probably not a complete list) can't be inlined.

You can't put anything in a clone either. Pre-allocated clones don't allow application events, IIRC. A rarity, but recently ran into this.