LabVIEW
A plane English guide to reentrancy settings? Considerations, impact, consequences, pros/cons.
Every time I File>New VI knowing that the VI I’m about to make can or may be must, be reentrant, I find myself hemming and hawing over what to do at the selection screen in the vi properties. I understand the basics between non-reentrant and reentrant, and even the basic gist between shared and pre-allocated, but I definitely don’t know which is best to pick each time or all the detailed consequences of each.
For instance, let’s say a certain subvi is a very simple concatenation, array operation, or mathematical operations. And suppose this will be needed in numerous places all over the program, called by various non-reentrant parents. My first instinct would be to preallocate and check the inline box too. There might even be a good argument against reentrancy if performance is not critical.
Now let’s say the vi I wish to make reentrant is something I want to call via Run vi, call asynchronous, etc. Here’s where things break down for me. There are numerous combinations of reentrant call options and I think they matter depending on which reentrant box you’ve checked but I don’t know all the particulars. I generally choose shared clone when I don’t know how many clones to expect at runtime. Is that the ultimate criteria? What are the consequences of preallocated clones called in this way? Which prepare reentrant calls work for which reentrancy type? Is it possible for a calling vi to access a specific clone via its reference with both types?
would also love some rules of thumb for when and why to inline a subvi.
@DoctorAutomatic wrote:
Every time I File>New VI knowing that the VI I’m about to make can or may be must, be reentrant, I find myself hemming and hawing over what to do at the selection screen in the vi properties. I understand the basics between non-reentrant and reentrant, and even the basic gist between shared and pre-allocated, but I definitely don’t know which is best to pick each time or all the detailed consequences of each.
For instance, let’s say a certain subvi is a very simple concatenation, array operation, or mathematical operations. And suppose this will be needed in numerous places all over the program, called by various non-reentrant parents. My first instinct would be to preallocate and check the inline box too. There might even be a good argument against reentrancy if performance is not critical.
Now let’s say the vi I wish to make reentrant is something I want to call via Run vi, call asynchronous, etc. Here’s where things break down for me. There are numerous combinations of reentrant call options and I think they matter depending on which reentrant box you’ve checked but I don’t know all the particulars. I generally choose shared clone when I don’t know how many clones to expect at runtime. Is that the ultimate criteria? What are the consequences of preallocated clones called in this way? Which prepare reentrant calls work for which reentrancy type? Is it possible for a calling vi to access a specific clone via its reference with both types?
would also love some rules of thumb for when and why to inline a subvi.
Good questions! I am going to participate in this topic as a learner.
The following is a screenshot of the excellent summary table included in the Reentrancy: Allowing Simultaneous Calls to the Same SubVI LabVIEW User Manual article that Yndigegn shared above.
@Yndigegn wrote:
I prefer the older CHM versions. They look better.
Definitely agree, they looked comprehensive, easier to get an overview at a glance, typographically easier on the eyes, and much better organized on a page. The new format may be flow design compatible but as a consequence displays neither well on a big screen nor normal screen, a tablet or a mobile phone. I guess it’s democratic at least, everybody gets a messy looking page layout.
it also seems nearly impossible to add any graphics to such documents, at least they were pretty much all pruned from the documents when porting them to the new format.
I was just notified that there was a response to this old topic which brought to mind a related idea that I have been mulling in my head over the years. So here it is:
Let's say you have a need for a reentrant vi that will be called by many other VIs, let's say you make it shared clone reentrant. It seems critical, in my mind, that all sub functions, subvis, or calls made within this VI are reentrant also. Otherwise, all clones will still wait at whatever subvi is not reentrant, sort of cancelling this advantage of reentrant behavior. I'm particularly thinking of this in terms of say a VI used for database transactions. It is my understanding that the way in which the DB connectivity module is ultimately non-reentrant at the point of interaction with the database drivers. So if your reentrant clone vi was supposed to aid many modules of your application in accessing a database, they will still block each other at some point when trying to call the database drivers and you will be hardly better off than just having a nonreentrant vi. Am i thinking about this the wrong way? Am I incorrect on certain facts here?
