do all the sub VIs in a reentrant VI need to be reentrant?

[sumitrishi]

specially the user defined subVIs.
Please assist and also if possible direct me to a good reading on this.

[EdDickens]

It depends on how you want your sub-vis to behave.

Any sub-vi will follow what is set in its execution properties. So if it�s set for reentrant operation, it will run that way. If it�s not set for reentrant operation, the same instance of the VI will be used regardless of what is calling it. So reentrant VI�s can call the same instance of sub-vis and they will share data within the non reentrant sub-vis.

So you�ll need to decide how you want the sub-vis to work and set them appropriately.

Ed

[sumitrishi]

Thanks Ed!
I wasnt sure I thought a VI that was made reentrant actually would with every instance will have its own copies of all the subVIs in it which it would not share with anything else.

This mean for my main VI to be renentraant I have to look at each subVI(basically most of them are from database connectivity add-on toolkit)and see how they are suppose to behave and set them accordingly.

Have you tested out anything like this yourself?

-Sumit

[EdDickens]

I haven't gone through any real testing of this, it's just the way VI's work.

If you're going to be changing the properties of any vi.lib files, be sure to save them with a different name into your user.lib directory. If you just change and save them, any other VI's that use them may not work anymore as they would be expecting them to be in their original state.

Ed

[Feroz]

Hi Sumitrishi,

When a VI is made reentrant, this property does not affect any of the subVIs and does not make seperate copies of the subVI. In other words, it does not make the subVIs of the reentrant VIs reentrant. There are many reasons for this, some of which are

Not all VIs can be safely considered reentrant.

You may not be able to modify all subVIs in the hierarchy (if, for example, they were supplied by NI or some other VI vendor).

Essentially all vi.lib VIs would have to be reentrant since all user VIs could potentially call these.

I hope this helps.

Feroz
National Instruments

[Greg_McKaskle2]

> I wasnt sure I thought a VI that was made reentrant actually would
> with every instance will have its own copies of all the subVIs in it
> which it would not share with anything else.
>

As others have pointed out, the reentrant option doesn't automatically
apply to subVIs. A reentrant VI can allow all callers to start
executing, without having to wait for the current one to finish before
another can begin. This means that the built-in nodes, and in
particular, the generated code for the VI will allow for this. If the
VI calls a subVI, this subVI may be reentrant, in which case the same
rules apply, or it might not be. If it is not, then the callers will
take turns in the subVI. There are also some built-in objects such as
property nodes to the UI, that are not reentrant and must take turns
making OS calls for UI.

So, as you have stated, you may want to make some of your subVIs
reentrant too. If you are doing this to speed up your application's
execution, then here are a few things to keep in mind. Reentrancy
speeds things up because the VIs waiting for VIs weren't queued up for
execution. If nothing is queued up, then when the CPU goes idle, it
really goes idle since there are no other tasks to swap to while
waiting. Making reentrant VIs means that while one task waits on I/O or
another resource other than the CPU, the CPU can get to work on the other.

There is of course a limit to how much this helps, and if you look at
the task manager and see that the CPU usage is low, reentrancy may allow
it to go higher by listing other things the CPU can do while waiting.
When it pegs, your CPU is no longer waiting for things to do, and giving
it more tasks won't speed things up, it will just mean that instead of
finishing something and starting another, the CPU will swap back and
forth making progress in little steps.

So, my rule of thumb is, if your app has low CPU usage and you want to
speed it up, look to see if you have a VI used multiple places in your
app that can be made reentrant.

Also, keep in mind that some VIs are meant to serialize things.
Instruments and other devices can get confused if multiple commands are
being sent for multiple tasks. LV2 style globals are another case where
it makes no sense to make them reentrant.

Greg McKaskle

[Marce]

Hi everybody,

Let me get back to the reentrant issue by making an inocent comment.

I thought that the reentrant property was used when i had a SubVi that was called a few times from parallel processes (i.e.; while loops) in the same Vi. If the SubVi was defined reentrant, then it's instances could run in parallel. If it wasn't reentrant, then, when running in parallel, the several instances would use the same meomry and the variables would be mixed up between the instances, leading to wrong results.

I'd appreciate your comment. Thanks,

Marce

[KileenC]

Hi Marce,

You are correct. If you have a subVI that is non-reentrant and stores information, the data will not be correct. For any subVIs that store data, you will want to use reentrant execution to make sure that each call to the subVI uses independent dataspace. 

Hope this helps.

Kileen

[Marce]

Hello Kileen,

Your response sure helps. Thanks.

But it sounds a completely different thing than the previous messages on this thread. Did you read them?

Now, after the principle of reentrant seems to be clear to me, let me ask the main question.

I have four Vis: A, B, C and D. A calls B from two different While loops, B calls C and C calls D. According to your message B should be reentrant because it can run two times in parallel. What about C and D? Should they be reentrant too? They can run twice at the same time but called from different processes.

Thanks,

Marce

[Ben]

Hi Marce and Kileen,

I have used Re-Entrant VI's to call Non-Re-entrant VI's. to implement mupltiple PID loops (Re-Entrant VI's) tht called non-Re-entrant VI's (Action Engine).

The attached llb demonstrates that re-entrnat VI's can call non-Re-entrant VI's.

The Example is demonstrates that the index for each non-re-entrant instance is stored in unique memory locations but share a common storage function.

Watch it in execution highlighting.

Ben