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

[AStankov]

Hi!

I am trying to implement an event-driven producer/consumer pattern with queues. The problem is that I have some value change events (e.g. coming from a slider) that I do not want to queue up; I want only the latest value change event to be processed by the consumer loop. This is because the consumer may spend longer time in executing (sometimes multiple seconds) and I want to prevent all intermediate slider events to be queued up in the meantime because I will finally write them to hardware. Therefore, a notifier would be better to use here than a queue. My question is if it is possible to make the same consumer loop wait on the queue as well as on the notifier at the same time? I will be wiring the VISA session and some other data through the consumer, so it want to avoid an extra loop that would wait on the notifier only. Or is there any other possible workaround?

Thanks in advance.

Regards,

Anguel

[Mark_Yedinak]

You can't really want on both. Your execution will be gated by which ever takes the longest. You could use shorter timeouts but then you effectively create a polling loop and not an event driven one. If you do not need the latest value until you get a message in the queue you could just check if you have a notification (using a timeout of 0) after you receive a message in the queue.

[AStankov]

Mark, thank you for the reply. Unfortunately, I did not really understand how it can be done. What I actually need is to just skip all previous messages queued up by this particular event and only process the latest message from this event in the consumer loop, as soon as the consumer loop is ready to process it. Therefore I asked for the additional notifier.

[Jeffrey_Zola]

---

@AStankov wrote:

Mark, thank you for the reply. Unfortunately, I did not really understand how it can be done. What I actually need is to just skip all previous messages queued up by this particular event and only process the latest message from this event in the consumer loop, as soon as the consumer loop is ready to process it. Therefore I asked for the additional notifier.

---

What about having your event structure purge the queue when it detects changes to the slider and queue just the "new" change/command?

Jeff

[Mark_Yedinak]

Can you post your code, or at least a basic version of it so we can see what you are doing.

[Mark_Yedinak]

---

@Jeffrey_Zola wrote:

---

@AStankov wrote:

Mark, thank you for the reply. Unfortunately, I did not really understand how it can be done. What I actually need is to just skip all previous messages queued up by this particular event and only process the latest message from this event in the consumer loop, as soon as the consumer loop is ready to process it. Therefore I asked for the additional notifier.

---

What about having your event structure purge the queue when it detects changes to the slider and queue just the "new" change/command?

Jeff

---

Flushing the queue can be problematic. Is the queue is only used for a slider update then a nofitier would be a better choice. If the queue has other messages you probably don't want to flush them.

[Jeffrey_Zola]

---

@Mark_Yedinak wrote:

---

.......

---

Flushing the queue can be problematic. Is the queue is only used for a slider update then a nofitier would be a better choice. If the queue has other messages you probably don't want to flush them.

---

Good point. I assumed.......

I have a state-machine-based application that I built and tweak to fit specific needs of various projects. My gut told me to use two queues - one for the state machine transitions and one for the data handling. This thread gave me a reason why I "went with my gut"! 😉

Jeff

[crossrulz · Accepted solution]

Does this example make sense?  It is based on Mark's initial suggestion.

[AStankov]

Thank you all for the replies. As Mark stated, the queue cannot be flushed completely, as it also contains other messages from other events. I have no code yet, as I am still in the design phase but my idea is as follows: A consumer loop is going to watch for incomming messages that are pushed from the event-driven UI producer loop to a queue; the consumer will then write the corresponding commands to some acquisition hardware.

Now it may happen that the acquisition hardware is performing a longer acquisition but the user changes the hardware's configuration via the slider multiple times in the meantime (he decides to set it to 5, but then he thinks again and sets it to 10, but finally he sets an 8). This would fire multiple events (also inbetween the values I mentioned) and if I don't do anything special they will all go to the DAQ queue and be written one after the other which is at least unnecessary. I intentionally don't want to put an extra apply button for the slider, as for shorter acquisitions (the ones that don't last long) my app should appear to work in "real time" when moving the slider.

So my basic idea was to make my DAQ loop wait on a queue and on a notifier, but it looks like this is not possible. So I will probably modify the DAQ loop to wait on the queue and if it receives a slider message it will preview the next element. It this next element is still a slider event it will discard the current element, if it is not (e.g. it is a start acquisition command), it will write the latest slider value to the hardware. I actually don't know if this is very efficient. Maybe you experts can tell me.

crossrulz, many thanks for the code example and this is probably exactly what Mark suggested. Unfortunately, I do not really understand the logic behind it, i.e. why wait on the queue and then on the notifier?

[crossrulz]

---

@AStankov wrote:

crossrulz, many thanks for the code example and this is probably exactly what Mark suggested. Unfortunately, I do not really understand the logic behind it, i.e. why wait on the queue and then on the notifier?

---

It isn't really waiting on the notifier.  The wait is set to 0.  So if there is no new data in the notifier, instant timeout and skip the DAQ stuff.

The idea here is to send the set value (from the slider) through the notifier and send the command through the queue.  When the consumer loop gets the command, it will read the notifier for the latest data point and go to work.  Now if the user changes a bunch of stuff while a "long" acquisistion is happening, the notifier will keep being overwritten; it will only keep the last commanded value.  The queue will get multiple commands, but only the last value will be worked on due to the notifier.  The remaining commands will check the notifier, see that there's no new data, and skip to the next command.