reentrancy

[AQ1]

I'm using LabVIEW 2014.

Reading through the many posts on VI Reentrancy, I am still left with one fairly basic question about VI reentrancy:

Let's say I have a VI which i want to set to 'Reentrant' (Shared or Preallocated), in order to execute several copies simultaneously.

Let's say this VI is typical, containing numerous subVIs (which themselves call numerous subVIs and so on).

If I want to see maximum-performance parallel execution of all copies of my VI (avoiding bottlenecks of multiple instances waiting to use the same subVI), am I required to visit every one of the subVIs in the calling heirarchy, and manually set its execution state to reentrant? And its subVIs too, and so on? 

OnceI get down to the level of the built-in LabVIEW functions, I assume multiple instances of the same (built-in LabVIEW) function will execute within each reentrant VI in parallel (e.g. as inline code) without causing bottlenecks? Is this true for every built-in function offered by LabVIEW (e.g. signal processing, datacommunications etc)?

[mikeporter]

In theory what you say is true. In the real-world however, it is seldom necessary to go so far. In the first place, there are often initialization VIs that only execute once, so there is typically little benefit in making them reentrant. Then there are things like FGVs that making them reentrant will break them. Finally, there may be subVIs that because of the application's overall logic are precluded from even trying to execute in more than one location at a time.

If you haven't already you might want to check out this post and the two following it for more info on reentrancy.

http://www.notatamelion.com/2015/03/09/taking-flexibility-to-the-next-level-dynamic-linking/

Mike...

[AQ1]

Thanks Mike, you have created some good content there.

[tst]

---

@AQ1 wrote:

If I want to see maximum-performance parallel execution of all copies of my VI (avoiding bottlenecks of multiple instances waiting to use the same subVI)...

---

It's also worth pointing out that this is not as clear cut as more reentrant=better performance. Running multiple VIs has costs (memory allocation, thread switching, etc.) and those could be higher than the gains.

Generally, you should consider making a VI reentrant if:

1. It's long running and you need multiple copies to run in parallel.
2. The VI has state (like uninitialized shift registers) and you want each call to have its own state. Note that for this you need preallocation and there are some cases where LV would use the same instance where you might expect multiple instances.
3. You have a performance problem and your benchmarking or experience tell you that it's because non-reentrant VIs are waiting on each other. This is a variation on 1.

There may be others, but the point is that the decision on making a VI reentrant should be based either on functionality or on actual data. Don't just go and make all the VIs reentrant hoping for a performance increase. In my case I almost always need the reentrancy for functionality, because I want state in multiple copies.

[Current_93]

Keep in mind that if a VI uses shift register to store values, so its execution mode needs to be set to non-reentrant.

[stevem181]

> Keep in mind that if a VI uses shift register to store values, so its execution mode needs to be set to non-reentrant.

This can be done, if you keep in mind the limitations.

For example, the following code works in a pre-allocated reentrant vi.

This vi gets the Control Index of an indicator on First Call, and returns it in subsequent calls.

[Get/Set by Control Index - the best thing for large systems since the cluster (IMHO).]

I was recently reading a 2009 post on Darren's blog about removing the while loop by using Feedback Nodes.

Here is a no-loop version:

steve

[mikeporter]

The only thing to be aware of is that every time the "no loop" version runs you have code that is executed whether or not it is needed. You need to be careful in considering whether this redundant code will be detrimental to performance.

In the example you showed, the difference in performance is not likely to significant -- unless the arrays are HUGE, but it can happen.

All I'm saying is that you need to be careful.

Mike...

[stevem181]

You are right Mike - that "no loop" code doesn't avoid the calculation each iteration.

This version works as intended:

steve