LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

queue function re-enterant

Solved!
Go to solution

I have a producer consumer with multiple consumers. Each consumer has its own queue. Say three consumers. I am using a que library where obtain queue, enqueue, dequeue are all wrapped in upper level functions.My question is should these wrapper VIs needs to be re-enterant? TIA

 

 

*************************************************
CLD
*************************************************
0 Kudos
Message 1 of 11
(3,043 Views)

Yes, the wrappers should be reentrant. Let's say two parts of your code are both waiting for elements in different queues. If the wrapper isn't reentrant, only one part of the code will actually be waiting on the queue; the other will be waiting for the dequeue wrapper VI to be available, which probably isn't what you want. If the wrappers don't store any data between calls (for example in an unitialized shift register) and you're worried about too many copies of the wrapper VIs in memory, use the shared clones option. That way a new instance of the reentrant VI will be created only when needed, regardless of how many times that wrapper appears in the code.

0 Kudos
Message 2 of 11
(3,039 Views)

-------------------------------------------------------------------------------------------------------------------------------------------

If the wrappers don't store any data between calls (for example in an unitialized shift register)

--------------------------------------------------------------------------------------------------------------------------------------------

Wrappers do have variant to pass data between consumers. Can clone still be set and the passed data across loops will be recevied?

 

Should the option be Shared clone reentrant execution or Preallocated clone reentrant execution?

On setting the wrappers to clone each consumer will know its queue function because reference of that queue is passed, is this correct?

*************************************************
CLD
*************************************************
0 Kudos
Message 3 of 11
(3,029 Views)

@lvrat wrote:

Wrappers do have variant to pass data between consumers. Can clone still be set and the passed across loops will be recevied?


Could you try to phrase that question more clearly? "The passed across loops will be received" doesn't make any grammatical sense. It might help if you attach your code, since there's no variants shown in your screenshot. Is the variant stored in a shift register? Are you trying to use the wrapper like a functional global variable, to carry data between loops? If so, a reentrant VI won't work - the data will not be shared across instances. You would need to put a non-reentrant functional global inside the reentrant wrapper to carry the data.


@lvrat wrote:

On setting the wrappers to clone each consumer will know its queue function because reference of that queue is passed, is this correct?


That is correct. Any parameter that you wire directly to the subVI will be passed correctly to the subVI instance regardless of the reentrancy setting.

0 Kudos
Message 4 of 11
(3,020 Views)

 

MainVi.jpg shows how data is passed from UIR loop to other loops.

The image attached as "AnotherThread.jpg" different queue are used to enqueue and send data to other loops.

Can the same wrapper marked as shared clone be used across each queue and can still create separate queues? Or should there be different wrappers created, one for each queue?

 

*************************************************
CLD
*************************************************
Download All
0 Kudos
Message 5 of 11
(3,010 Views)

You are missing the point. What matters is what's inside the wrappers, not how they're used in the larger code.

 

Do you understand how reentrancy works? If not, here are a couple of links that might help:

http://digital.ni.com/public.nsf/allkb/98847B4E4C715E6D86256C59006B57CC?OpenDocument

http://forums.ni.com/t5/LabVIEW/Re-entrant-modes/td-p/2007697

 

A clone operates on the data that's passed into it. It's just like a normal subVI in that way. You can use shared clones with as many different queues as you want, so long as you're passing in the queue reference each time. However, if you store any data in the wrapper between calls, then any type of reentrancy (shared or preallocated) will cause you problems.

Message 6 of 11
(3,001 Views)

Thanks for the explanation. Inside the wrapper are queue functions. Just to confim my understanding after reading the links is that setting the wrapper as "shared clone" should work as queue reference is passed in each time the wrapper is used. Do not need to create separate set of wrappers for each queue and do not need preallocate shared clone either.

*************************************************
CLD
*************************************************
0 Kudos
Message 7 of 11
(2,993 Views)

Yes, you've got it right.

0 Kudos
Message 8 of 11
(2,986 Views)

In the wrapper there is data and state passed for enqueue and dequeue functions, would setting the wrapper as shared clone pass the correct state and data to correct queue reference? Looks like often times a thread would deque a state not set for that thread.

*************************************************
CLD
*************************************************
0 Kudos
Message 9 of 11
(2,969 Views)
Solution
Accepted by topic author lvrat

@lvrat wrote:

Looks like often times a thread would deque a state not set for that thread.


Does "looks like" mean that you're seeing this behavior, which would be a bug in your code (or less likely, in LabVIEW), or does "looks like" mean that what you believe doesn't agree with what I (and others through the links I posted) are telling you?

 

In the screenshot of the wrapper you posted, the VI doesn't save any state information internally. It gets a queue reference as an input and either puts an element on that queue, or takes it off. Threads have nothing to do with this. The reason you need the wrapper to be reentrant is that the timeout on the queue operations is forever, and I assume you want more than one queue to be able to wait at a time in parallel.

Message 10 of 11
(2,955 Views)