Should Primitive-like Utiltiy VIs be Reentrant?

[Jim Kring]

[cross-post]

At OpenG, we've recently discussed the possibility of setting our small primitive-like utility VIs as subroutine. Now, we're discussing whether we should make these VIs reentrant. Ton Plomp asked;

QUOTE

Since we like to view the OpenG VIs as primitive like functions they need to behave like primitives.

One of my 'OpenG VIs I couldn't live without' is Filter Array. A lot of times I use it on several data-sets inside one VI. Since the VI is not reentrant it is called subsequently, this can be overcome by making the VIs reentrant, and allow the clones to be shared to limit the food-print of the VI.

Are there any problems with this view?

Please respond here:

http://forums.openg.org/index.php?showtopic=833

[Aristos Queue]

I created major problems for LabVIEW when I made the "Trim Whitespace.vi" be reentrant a few versions ago. Just launching LabVIEW's Getting Started Window spawned 150+ copies of that subVI. It was a major memory hog. In LV8.5, that subVI is no longer reentrant. The tradeoffs between the thread synchronization and the memory usage were such that not being reentrant is better.

Now, in LV8.5 we also introduced pooled reentrancy. The LabVIEW R&D team has been seriously debating a recommendation that the vast majority of non-state-maintaining-pure-function VIs should be changed to pooled reentrancy. In the long-term, this may be something we encourage. The "Trim Whitespace.vi" is a prime candidate for this status... we didn't do that in 8.5 because the feature was brand new --- since that subVI could be used in tons of user VIs around the world already, we didn't want any potential bugs in the new feature to impact existing VIs.

[Jim Kring]

QUOTE (Aristos Queue @ Apr 2 2008, 01:59 PM)

I created major problems for LabVIEW when I made the "Trim Whitespace.vi" be reentrant a few versions ago. Just launching LabVIEW's Getting Started Window spawned 150+ copies of that subVI. It was a major memory hog. In LV8.5, that subVI is no longer reentrant. The tradeoffs between the thread synchronization and the memory usage were such that not being reentrant is better.

Now, in LV8.5 we also introduced pooled reentrancy. The LabVIEW R&D team has been seriously debating a recommendation that the vast majority of non-state-maintaining-pure-function VIs should be changed to pooled reentrancy. In the long-term, this may be something we encourage. The "Trim Whitespace.vi" is a prime candidate for this status... we didn't do that in 8.5 because the feature was brand new --- since that subVI could be used in tons of user VIs around the world already, we didn't want any potential bugs in the new feature to impact existing VIs.

I wonder about combining the subroutine and reentrant VI setting. The subroutine setting might greatly limit the memory used by each reentrant instance. Do you have any thoughts on this? Has NI considered making any of it's primitive-like functions subroutines?

[Aristos Queue]

QUOTE (Jim Kring @ Apr 2 2008, 04:18 PM)

I wonder about combining the subroutine and reentrant VI setting. The subroutine setting might greatly limit the memory used by each reentrant instance. Do you have any thoughts on this? Has NI considered making any of it's primitive-like functions subroutines?

Several of them are subroutine. In general we do NOT make anything be subroutine because of the inability of users to debug in such VIs. If you have a need for subroutine priority for something in vi.lib, clone it and make it subroutine. This has been a point of debate in the past, but the explorability of LV has always been given precedence over performance as far as that setting is concerned.

[Jim Kring]

QUOTE (Aristos Queue @ Apr 2 2008, 03:20 PM)

Several of them are subroutine. In general we do NOT make anything be subroutine because of the inability of users to debug in such VIs. If you have a need for subroutine priority for something in vi.lib, clone it and make it subroutine. This has been a point of debate in the past, but the explorability of LV has always been given precedence over performance as far as that setting is concerned.

I'm starting to think that a similar approach might be good for OpenG, too. If a user has a need for extreme performance, they can always optimize by making copies of the OpenG VIs and configuring them with subroutine priority.

Going off on a tangent, this makes me wonder if it might be nice to have a SubVI Node Setup option to make a specific subVI call execute as a subroutine. This would allow users to optimize callers without having extra copies (on disk, in thier project) of OpenG VIs. Another possibility would be to add poly instances that are marked as subroutine, but this would double the number of poly instances, so it's not really feasible.