reentrant execution of controls

[mrbean]

I'm seeing some strange behavior in a reentrant VI that I'm calling.  I'm going through now and verifying that all its subVIs are also reentrant.  However, I'm wondering about the numerous LabVIEW strict type defs (.ctl) that I use.  Is there a need (or even a way) to make those reentrant?  I would think that they too would need this?

[smercurio_fc]

Why would you think a typedef needs to be re-entrant? It's just a definition of a type - it holds no data. Therefore, it cannot be made re-entrant.

Exactly what kind of "strange behavior" are you seeing? Care to post some code so others can diagnose it?

[mrbean]

I'm not sure what the proper non-object-oriented term is, but in OO, when I instantiate a class, there is memory used.  So I'm not sure how, when I drop a .ctl onto a front panel, and it has a number of controls (i.e. numeric/string controls) that I eventually populate, that this isn't requiring memory.  It's like a variable, isn't it?

[tbob]

Whether it is a type def or not, a control is simply a variable.  It does not have re-entrant properties.  It can be written to from any subvi that has access to its memory space (control reference).  It can be the subject of race conditions also (writng to its memory space from several subvi's at one time).

[mrbean]

OK.  Here's a related question. 

In the Execution drop down of the VI Properties, the Help says "Note  The Reentrant execution option must be the same in a parent dynamic dispatch member VI and a child dynamic dispatch member VI" I'm trying to understand who they are referring to as the 'Parent'.  I have an upper level VI that only gets called once, but the subVIs it calls may have upto 16 instances.  That note, however, makes it sound like the Parent (in my case, the top-level VI) also needs to have that 'Reentrant' checkbox checked.  Is this true?

[tbob]

If you are using Dynamic Dispatch VIs, yes the parent vi must match the children.  If one child is re-entrant, all the children and the parent must also be re-entrant. 

The parent is the main instance that was originally created.  That does not necesarily mean your top level vi.  The parent is the main instance of a class and the children are created from this main instance.  Not sure about my terminology, I hope its right.  I understand the concept, just hard to explain.  There are some good examples on Dynamic Dispatch VIs.  Use "Find Examples" and search for Dynamic Dispatch.

[mrbean]

I'm not actually coding any LVOO.  I was just trying to borrow some terminology.  I really just have an exe (only one exists), and it calls upto 16 instances of a pretty mammoth VI, that itself contains numerous subVIs.  So far, only the VI (top-level) that eventually becomes the .exe is not reentrant.

[smercurio_fc]

You still haven't described what this "strange behavior" is that you are seeing.

[tst]

1. Don't overcomplicate things. It would just serve to confuse you. The default should be to let LV handle everything for you.
2. If you're not using LVOOP, don't look at LVOOP documentation. Dynamic dispatch refers specifically to LVOOP and if you had used it, you would definitely know what the "child" VIs are (those are the DD VIs in the child classes).
3. Reentrancy is not some magic performance enhancing pill and cannot be enabled on controls or data in any case. Reentrancy refers to allowing a VI to have multiple copies of itself in memory at the same time, so that if you want to run it in parallel, you won't have to wait on a single copy. This actually hurts performance (it requires allocations, etc.) and will only help you if the VI is actually blocking the execution. Shared reentrancy (in 8.5 and later) allows you to minimize those allocations by reusing the clones, but has its own set of issues.
4. As smfc said, you'd better describe the actual issue you're having. If you have problems with not having enough RAM, you may be running into common issues which are more or less easily fixed, or you may need to modify your architecture to better suit the requirements (or get a stronger computer).

[mrbean]

As a recap, I have 16 instances of my app (but in VIT form) running.  I can tab around and they're all there.  However, two things I've identified (thus far) are the (1) my ActiveX Browser won't communicate when I type in the IP address of the Radio in question.  If I bring up the app VI by itself (outside of the factory), I can login to and communicate.  Also, there is a UserInfo area where I keep the user upto date on what's happening.  Normally, I can click the "Clear User Info" button, and it does.  While in the Factory, unless I'm seeing things, not only did it not clear the UserInfo assigned to Radio1 (the one where I clicked), but instead it cleared the userInfo for Radio12.  Not even sure where to begin.