I use a queue to handle GETs and POSTs from multiple tasks (xQueueSendToBack). The cloud interface peeks (xQueuePeek) at the queue to (1) wait for work to do and to (2) perform the request. If the system is ready to perform the request, it does so and then dequeues the request (xQueueReceive). Works very well so far.
Now I need to send a high priority request, which I can do by pacing it at the front of the queue (xQueueSendToFront). If I do that after peeking at the queue, will the item at the front get replaced? If so, when I dequeue the item just processed, it could be the high priority item I inserted at the front. Should I just set up a separate high-priority queue, or is there an elegant way to avoid that?
While you could use peek to see if there is work, you want to actually xQueueReceive the item when you are going to process it. You could even do the xQueueReceive with a zero wait time and check the error flag to see if you got something. The way you are describing doing a peek to get the data, and then later a xQueueReceive has the problem you are thinking about if anyone does a xQueueSendToFront.
If the issue is getting data when not ready to process, maybe waiting to be ready, or if not ready push the data back onto the front of the queue.
Thanks, Richard, I like the idea of pushing it back on the queue at the front. I was trying to make sure the high-priority request got the best chance of being serviced immediately, but was probably overthinking it (I get that criticism a lot). At some point, processing will start for a queued request and a higher priority request will just have to wait.
Yes, there is a VERY short interval between getting the message off the queue, and seeing you are busy and putting it back that will push a “high priority” message back a slot.
One other thing to warn about, if the queue might get full, the push-back will fail, so the code needs to be able to remember it still has “live” data to handle