LabVIEW
Does setting Dequeue Element Timeout to a value other than -1 = Polling?
No. If it times out, there is no new value on the queue and you are not polling it. OTOH, the timeout allows other things in the same loop to be polled (e.g. stop button ,etc.).
Still it is typically more efficient to keep the timeout at -1 and do polling operations in their own loop. Make sure you fully understand dataflow principles.
So, what, besides the timeout Boolean = TRUE, happens on a timeout? Does it return default data type value(s) or does it return the last known value(s)? It sure seems like polling if you have a timeout.
Yes, the question is itself a bit weird, because we first need to define what polling really means. Let's start reading here.
Instead of worrying about semantics, we should just define what the needs are and what functionality we should implement. Even if the timeout is infinite, you are "polling it" (by some definition of the term), it just won't answer until something gets put on the queue elsewhere and thus stall the loop until that happens. The "time" element is an important part of it. It is still polling if you set the timeout to 24 hours?
All that said, I don't want to put labels on something. You can call it anything you want as long as you know what it actually does. 😄
It seems rather pointless to spin a loop and poll a queue with a short timeout unless there is other code in the same loop that should run repeatedly and does not depend on the queue value.
The dequeue function itself does not turn into a polling mode or something with TO !=0.
Queues use very low level mechanisms, that go all the way down to OS and CPU provided functionality.
However, if TO is not -1, you will have to poll the queue in your code, if you want to continuously read values.
If TO = 0, the function will simply check if there's an element.
If TO= -1, the function will wait (on OS level) until there's an element, or until the event is cancelled.
If TO>0, the function will wait for the OS level event, with a TO.
Search LabVIEW like a graph! 
@altenbach wrote:
Yes, the question is itself a bit weird, because we first need to define what polling really means.
Well, is just waiting for a queue element technically polling? I would say no because it is relying on an interrupt, which greatly reduces CPU time.
Of course, I feel that I have to through this out for those using RT and FPGA. If you use an RT FIFO or a DMA FIFO on the host side, the read will actually poll for data. They will use 100% of a CPU core while waiting for data to come in. This is done for determinism since polling can react faster than interrupts.
So after thinking about this a little more, I would say that using a timeout for the queue is a form of polling. But is that really bad? I don't think so. Sometimes you need to do something in the loop periodically in the loop with the Dequeue Element. I do this commonly in my Queued Message Handlers where the controller will send a command to start a process and later another command to stop. In the middle, I use the timeout of the queue so I can see if a new message came in and still keep doing whatever it is the loop is supposed to do.
wiebe@CARYA wrote:
The dequeue function itself does not turn into a polling mode or something with TO !=0.
Queues use very low level mechanisms, that go all the way down to OS and CPU provided functionality.
However, if TO is not -1, you will have to poll the queue in your code, if you want to continuously read values.
If TO = 0, the function will simply check if there's an element.
If TO= -1, the function will wait (on OS level) until there's an element, or until the event is cancelled.
If TO>0, the function will wait for the OS level event, with a TO.
That's what I meant by "polling". I guess I got mixed up about just exaclty what was doing the polling. No wonder that I confused Alt.
@crossrulz wrote:
@altenbach wrote:
Yes, the question is itself a bit weird, because we first need to define what polling really means.
Well, is just waiting for a queue element technically polling? I would say no because it is relying on an interrupt, which greatly reduces CPU time.
Of course, I feel that I have to through this out for those using RT and FPGA. If you use an RT FIFO or a DMA FIFO on the host side, the read will actually poll for data. They will use 100% of a CPU core while waiting for data to come in. This is done for determinism since polling can react faster than interrupts.
So after thinking about this a little more, I would say that using a timeout for the queue is a form of polling. But is that really bad? I don't think so. Sometimes you need to do something in the loop periodically in the loop with the Dequeue Element. I do this commonly in my Queued Message Handlers where the controller will send a command to start a process and later another command to stop. In the middle, I use the timeout of the queue so I can see if a new message came in and still keep doing whatever it is the loop is supposed to do.
Yes, I knew I remembered someone who used this to their advantage, and I guess it's you. I've long thought about using this technique but I haven't had a chance to use it yet.
