LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Does wiring a finite queue timeout allow parallelism?

Solved!
Go to solution

I have multiple loops (11) all running in parallel implemented with a producer->multiple consumer->multiple consumer architecture.

 

In each of the consumer loops, I've wired timeout values on the order of 1 second to each of the the 'dequeue element' vi's that feed each loop. However, the overall performance of the entire vi is very slugish.  I don't have any wait vi's in the consumer loops, I assumed that the queue timout takes care of that functionality and allows labview to work it's parallelism magic. Is this assumption correct? 

 

For what it's worth, the producer loop synchronously reads large double arrays from shared memory which represents data acquired and post processed in RT via virtualization (hypervisor). The producer loop does implement a wait element. This producer loop distributes the data to various queues based on a data type meta code embedded in the recevied data. Then, the first level of consumer loops examine the data, update some PLC tags accordingly (via datasocket binding) and, under certain conditions, send nicely formated waveforms to the next level consumer loops which handle TDMS storage. 

 

Philip
CLD
0 Kudos
Message 1 of 3
(2,620 Views)

iS there one queue for each consumer?

 

Multiple consumers will rob queue entries based on who gets it first.

 

THe VI's waiting on an entry in a queue will be in (speculation invoked) a resource wait queue (OS scheduler queue for threads waiting on something). When the enty becomes available the thread is moved to the executable queue to fecth the data.

 

Multiple consumers waiting on the same queue is nothing I can speak for since I have never encountered a use case for "Who cares which thread get it" yet.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 2 of 3
(2,618 Views)
Solution
Accepted by topic author p-rose

Each consumer does have a dedicated queue and each of them are fed from multiple producers up the pipeline. I put wait vi's in each consumer loop with a value of about half the period that I expect data to arrive and it didn't help at all. However, the performance problem was solved by configuring the execution properties of almost every sub vi as subroutine priority, reentrant with dedicated memory allocation. I know that's basic stuff that I should have checked before hand but everything is running smoothly now. 

 

Thanks for the help anyway!

0 Kudos
Message 3 of 3
(2,599 Views)