Jump to content

Should Primitive-like Utiltiy VIs be Reentrant?


Recommended Posts

[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

Link to comment

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.

Link to comment

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?

Link to comment
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.
Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.