Is it possible to wait on a queue and on a notifier at the same time?

[JÞB]

---

@AStankov wrote:

---

@JÞB wrote:

Good question!  FGV vs Notifier as offered.  To the best of my knowledge the syncronization primitives are slightly higher in performance than a subiv call. So the performance would depend on the sparseness of the queue.  if there are normally few or no elements enqueued the solution offered would be better, if there are a great many elements in the queue two calls to a fgv (and an alternate slider command filter, such as a dedicated single element queue) could be slightly better.  Again, this problem is user interface so CPU optomization is not really the largest problem.  Getting the users desired actions to execute is the goal. 

And yes Tim is Crossrulz, sorry for any confussion.  I tend to refer to my fellow LabVIEW Champions familiarlly out of respect. Just a minor point of forum ettiquette that is probably not written anywhere and I made up in my own head- no worries.

---

Jeff, thank you for the clarifications. I am still thinking if I really need the notifier. If I use a queue that transports messages + data and if I have to dequeue all elements anyway (I think you are actually doing this by calling the flush), I could probably just replace a dequeued "slider" message with my updated "slider" message and get rid of the notifier. All other messages will be just reenqueued. If no "slider" message is found, I will simply enqueue my latest "slider" message at the end. I thought that dequeueing and reenqueueing the complete queue would not be very efficient but his is probably no big problem.

---

Exactly,  You are not abusing the CPU by tasking it with extra actions to forgive your user for being slow and indecisive.  Its a tool to work for the user.  We aren't it's slaves triing to make its job as easy as possible.

[AStankov]

---

@JÞB wrote:

Exactly,  You are not abusing the CPU by tasking it with extra actions to forgive your user for being slow and indecisive.  Its a tool to work for the user.  We aren't it's slaves triing to make its job as easy as possible.

---

Well, when my old notebook starts sounding like a hairdryer I am not sure about that 😉 I will try myself and decide whether to use your solution or Tim's original proposal. Thank you all once again for the help.

[AStankov]

An addition to Jeff's solution:

Looks like one may simply use "Get Queue Status" to get all elements from the queue without removing them. This will speed up things, as there is no need to dequeue and reenqueue everything 🙂

[Mark_Yedinak]

---

@AStankov wrote:

An addition to Jeff's solution:

Looks like one may simply use "Get Queue Status" to get all elements from the queue without removing them. This will speed up things, as there is no need to dequeue and reenqueue everything 🙂

---

This will create a copy of all the elements because it needs to keep the elements in the queue and return a copy of them to you. Also, if you are looking to replace the data of an element already on the quueue you will need to flush the queue and requeue everything. There is no way to modify an element that is on the queue.

[AStankov]

---

@Mark_Yedinak wrote:

---

This will create a copy of all the elements because it needs to keep the elements in the queue and return a copy of them to you. Also, if you are looking to replace the data of an element already on the quueue you will need to flush the queue and requeue everything. There is no way to modify an element that is on the queue.

---

But does Flush Queue not also create a copy when it returns all elements in an array? In Jeff's example no data is replaced, it simply looks if such an element already exists in the queue, if it doesn't the element is enqueued normally, otherwise the queue is not changed at all.

[Mark_Yedinak]

I don't think the flush would need to create a copy. It can simply give you the current set of elements. Also, I thought you had mentioned that you could look for an existing element (slider message) and update its data with the new value. In order to do this the queue must be flushed and everything requeued. If you are simply checking the queue you can use the queue status.

[AStankov]

---

@Mark_Yedinak wrote:

I don't think the flush would need to create a copy. It can simply give you the current set of elements. Also, I thought you had mentioned that you could look for an existing element (slider message) and update its data with the new value. In order to do this the queue must be flushed and everything requeued. If you are simply checking the queue you can use the queue status.

---

Regarding the message update you are right, but in the meantime I think about using a notifier or simply a FGV that will be read in the consumer. This FGV will always hold the latest value and I won't need to requeue.

Regarding the flush that's interesting. Is there any evidence that LabVIEW will just be able to map a complete queue to an array as it is flushed?

[JÞB]

---

@AStankov wrote:

---

@Mark_Yedinak wrote:

I don't think the flush would need to create a copy. It can simply give you the current set of elements. Also, I thought you had mentioned that you could look for an existing element (slider message) and update its data with the new value. In order to do this the queue must be flushed and everything requeued. If you are simply checking the queue you can use the queue status.

---

Regarding the message update you are right, but in the meantime I think about using a notifier or simply a FGV that will be read in the consumer. This FGV will always hold the latest value and I won't need to requeue.

Regarding the flush that's interesting. Is there any evidence that LabVIEW will just be able to map a complete queue to an array as it is flushed?

---

With some of these compiler optomizations we've been seeing I wouldn't be a bit surprised if the flush/requeue operation didn't even move the data in memory and just destroyed a pointer, created a poiner to the same data, detroyed the new pointer and recteated the original. Heck, even that might get recognized as a "no value change" and the operation could be done with no overhead.  It would take a heck of a lot to benchmark it though.

From a stict performance perspective  Its the search array thats the killer queues are fast.

[Mark_Yedinak]

I would opt for the notifier over the FGV.

[crossrulz]

---

@Mark_Yedinak wrote:

I would opt for the notifier over the FGV.

---

Of course, if going Jeff's route, you don't even need the notifier; the data is in the queue.