Any idea that has not received any kudos within a year after posting will be automatically declined.
I am trying to make a sub-VI reentrant. The sub-VI has multiple multilayer sub-VIs in it. Is there away to enable them all at once instead of doing it one-by-one.
Thanks for pointing out the difference. This is my first time using this.
I guess it would become an idea then. I think it will be a nice feature when you enable "reentrant" for a top-layer, it will automatially include all sub_VIs in the hierarchy. Currently, I have to do it mannulay for each sub-VI.
It would be extremely unwise to propagate a setting like reentrancy to all subVIs. You don't know in which other context any subVI will also execute, neither in which execution system, at which priority, how the subVIs states and IO will be affected. To blindly make everything reentrant won't make your code faster. Surprisingly often the contrary.
If these subVIs are system VIs, they should probably not be touched. I also question the idea that everything contained in a reentrant subVI necessarily needs to be reentrant too.
What are you trying to gain by making everything reentrant? You might be on a misguided witch hunt and the problem you are trying to fix is actually elsewhere. 😉
If the top-level is set to be "Reentrant", it seems to me that you want the entire entity to run in its own space (independently). Why would you want the sub-layer VIs to interact with other "Reentrant" entities. If the top-level VI contains many sub-VIs, manually evaluating each sub_VI, and its sub-VIs... could become a big task.
No, you don't necessarily want all subVI's to be reentrant just because a higher level VI is reentrant. What about a functional global variable or action engine? Those cannot be reentrant in order for them to work properly. But you may want to use them in multiple reentrant VI's in order to pass data between them.
Top of my head, I can only think of 2 reasons why you might want to make any VI reentrant.
1. You want to maintain two separate instances of data space.
2. A subVI that takes so long to run, that you don't want to block code when the same subVI needs to be used elsewhere.
There may be other good reasons for setting reentrancy, but in general there is usually no reason to make a subVI reentrant unless you have a specifically thought out reason.
> If the top-level is set to be "Reentrant", it seems to me that you want the entire entity to run in its own space (independently).
Why? If some simple function completes very quickly it can easily be shared. If you duplicate huge hierarchies of code into parallel instances, you significantly increase the memory footprint, possibly lowering performance because of cache thrashing. .... and you still possibly have vi.lib VIs that are not reentrant.
I ask again, what (perceived) problem are you trying to solve with all this.
The reasons I need to use the reentrant are exactly the same as Ravens Fan has stated. In my case, I want to have the reentrant top-level VI (state machine with PID controller, etc...) to run in parallel in order to reduce test time. I agree that functional global variable would be a problem. It will be nice to have this feature as an "option" knowing that you do not use the functional global variable. The other option would be to go through the list of all sub-VIs. It could be a pretty long list.
Are your subVI calls blocking eachother? Most times they aren't, and in most of the rest of cases what you gain in performance by eliminating the block, you lose again by introducing the more VI instances. Sometimes you want some subVIs to be reentrant too, but as Ravens Fan says it must always be a choice made with eyes wide open.
As Stephen would say: such a feature would promote bad code .
Any idea that has not received any kudos within a year after posting will be automatically declined.