reentrant vi copies whole VI structure (subVI's) when called?

[Tukan]

Hi Everyone,

I would like to ask all of you regarding the Reentrant VI's.

I have a VI (Thread.vi) that is set to reentrant (Preallocated clone reentrant execution) which is called from the main vi using Run VI method. Reference of the vi is opened with the 0x8 option set.

When I call the Thread.vi, clone of the original vi is created.

My question is, when the clone of the top-level vi (Thread.vi) is created, all subVI's the Thread.vi contains are also clones of the original subVI's?

I am passing named queue to the Thread.vi when called using Control Value property node, and using that queue within Thread.vi (in subVI's) to control the Thread.vi.

My problem is that when two clones are created, I can run, stop and close both together. But when I want to close the second clone, the Dequeue function has queue reference of the first clone. I do not understand this as the queue has been obtained with the name in the main vi and passed into the Thread.vi clone. When I want to close the first clone, it works as it has correct queue reference.

I thought that LabVIEW creates whole hierarchy of the subVI's of the Reentrant VI as well when called.

Thank you for your replies and help.

Tukan

I am using LabVIEW 2014 32b, Windows 7

[nathand]

A reentrant clone is only a copy of that specific VI. Any subVIs that it calls follow the reentrancy settings of that subVI. This makes it possible for several clones to share data by calling a single, non-reentrant subVI, which is often useful. If you need data, such as a queue reference, to stay associated with a specific clone instance, then it should be saved in that VI, and not in a subVI.

Also, do you need to use Run VI and Set Control Value? You might want to consider an asynchronous call by reference instead.

[Bob_Schor · Accepted solution]

You are using Named Queues, so unless you are calling your clones repeatedly (rather than, say, calling a clone and having it run code in a loop for a "long time"), I'd recommend not bothering to pass a Queue reference to the Clone, but rather the Queue Name.  Have the Clone do its own Obtain Queue -- if the Main has already done this, the Clone's Obtain Queue will not allocate a new Queue, but will return the reference to the already-created Queue.

Sub-VIs that are used by Clones can either be "clone-specific" (if they are, themselves, marked as Reentrant) or "universal" and shared by all of the Clones.  There's really nothing wrong with this, as long as you realize that while Clone A is using sub-VI X, Clone B will be "blocked" when it tries to use the sub-VI, so you want to make the sub-VI execute in an "in-and-out" fashion, without blocking.  In particular, do not put any function, such as a Dequeue, that needs to wait in a common sub-VI.

Bob (who learned the above "rule" through sad experience) Schor

[mikeporter]

The last couple versions of LabVIEW have a nice feature that will helps to maintain reentrancy. If you have a VI that is reentrant and you turn part of it into a subVI, the new subVI will also be automatically marked as reentrant.

Also, are you aware of the difference between the two types of reentrancy that LabVIEW supports?

Mike...

[Tukan]

Hi Everyone, thank you for your replies.

---

@Bob_Schor wrote:

Sub-VIs that are used by Clones can either be "clone-specific" (if they are, themselves, marked as Reentrant) or "universal" and shared by all of the Clones.  There's really nothing wrong with this, as long as you realize that while Clone A is using sub-VI X, Clone B will be "blocked" when it tries to use the sub-VI, so you want to make the sub-VI execute in an "in-and-out" fashion, without blocking.  In particular, do not put any function, such as a Dequeue, that needs to wait in a common sub-VI.

Bob (who learned the above "rule" through sad experience) Schor

---

I set the subVI and all the subVI's in hierarchy ( with the Dequeue function ) to be Reentrant, and now it works as it has been intended.  I thought that it will be done automatically as the top-level VI is set to be Reentrant. Will more carefull next time.

Regarding the position of the Dequeue function, lesson learned 😉

Thank you all again.

Duri