dequeue element: overhead and underpinnings?

[jccorreu1]

I have written a program with a few main vi's running in parallel, and use a number of queues and notifiers for passing data and commands throughout the code, with practically all my loops waiting on a dequeue element to proceed. 

I need to know how dequeue element primitive functions underneath, and how much overhead is produced, when the timeout is set to never expire.

I am working with a collegue who used Labview back in version 4,5,6 and does not like using queues and notifiers.  What I have found suggests that dequeue element is very efficient and does not "poll", but works on an "interupt" basis. 
http://forums.ni.com/ni/board/message?board.id=170&message.id=144984
He says, after talking to another colleague of his, that this can not be.

We need to have a knowledgeable weigh-in so that we can decide if we need to convert to a different architecture, or if this works well as is.

Thanks all,
James

[James_R]

Queues work very well and I use them to keep code re-usable in the same manner that you describe

if you are worried about contention issues with many loops trying to use the same queues then use semaphores to lock and unlock after each queue operation

If you are using Real-Time applications there is a RT fifo which has a nice feature that you can read and write at the same time.

[mikeporter]

Queues work very well for the kinds of applications you describe. I have run applications with dozens of independent processes wait for data to be enqueued and - despite what this other "colleague" says - if there is no data being enqueued, there is no CPU usage being charted in Task Manager. Queues are very efficient. Admittedly this in not the same things as really zero CPU cycles - but it's close enough.

One thing that I like is that if you have multiple processes monitoring the same queue simultaneously, LV guarantees that only one loop will see each item that gets enqueued.

Mike...

[jccorreu1]

I am not using the RTOS or any real time module, though we are going for the most reliable software timing we can achieve, with as little as 100ms intervals.

There is user interaction sometimes, continual reading of the hardware, and when process are being run (or a user manually sets some control) the writing is performed.  The user interface is hadled by 1 main vi, while the hardware interface is handled by another main vi running in parallel.  Each of these has 3 loops, all controlled by either a notifier or queue call, esxcept the one in the user interface that is the event structure.

His main concern is that this architecture would result in slower, or unreliable performance.  BUt from the sounds of what have been said here, and in the previous post, we should be ok. 

Still, is there someone who can tell us how the dequeue element primitive actually works to achieve this?  I would really appreciate that, as I've not been able to find anything definite and clear as of yet.

Thank you
James

[jccorreu1]

As a slightly different question, but still related...
He has made the statement that this kind of architecture is not used for hard real time programming with labview.  Since I do have experience with that yet, I must ask any of you that do hard real time. 

Do you use queue's and modular coding architecture? Or do you above them, and if so then what do you do? 
Alternatively, is there a more efficient way, and if so what would it be?

James

and, as always, any recommendations for good sources that I can further me knowledge would be greatly appreciated.


Message Edited by jccorreu1 on 04-08-2008 10:48 AM

[Ben]

Adding to Mike's (he sits on the other side on the wall from me) reply...

In early version of LV (prior to LV 6) the queues were implelemented as strings only. This made them slower than Action Engines do to the work required to flatten and un-flatten on the way in and the way out of the queue.

I benchmarked the polymorphic versino of the queues in LV 6.0 and they out performed anything I could write.

Queues are very efficient and provided you are not branching wires (forcing data copies) the queues are capable of passing data "in-place" meaning that the buffer holding the data when queued up are the same buffers used when the data is de-queued.

The Que VI's were developed by Stephen Mercer and he did a wonderful job with them. He does not monitor this forum but he does frequent LAVA, mostly to support LVOOP his most recent brain-child.

I hope this helps!

Ben

[Ben]

JC... wrote

"

What I have found suggests that dequeue element is very efficient and does not "poll", but works on an "interupt" basis. 
http://forums.ni.com/ni/board/message?board.id=170&message.id=144984
He says, after talking to another colleague of his, that this can not be.

"

Although I know and love Shane I have to split hairs when it comes to the interupts. Interupts are hardware dependent and LabVIEW (being cross-platfom) would have to bend over-backwards to use interupts to handle queues. "Softweare Traps", maybe.

Ben

[TWGomez]

---

Ben wrote:

JC... wrote

"

What I have found suggests that dequeue element is very efficient and does not "poll", but works on an "interupt" basis. 
http://forums.ni.com/ni/board/message?board.id=170&message.id=144984
He says, after talking to another colleague of his, that this can not be.

"

Although I know and love Shane I have to split hairs when it comes to the interupts. Interupts are hardware dependent and LabVIEW (being cross-platfom) would have to bend over-backwards to use interupts to handle queues. "Softweare Traps", maybe.

Ben

---

My LabVIEW instructor explained it similarly....as basically a very very low level processor function that acts like an interupt (Software Trap?)