[Feature Request] Zero-length queues (a.k.a. rendezvous queues)

[michael-p]

Is your feature request related to a problem? Please describe.
I want to send data from task A to task B, but only if the receiving task B is already waiting for the data. Using a FreeRTOS queue does not work for this use-case because they have require a length greater than zero, meaning 1 data element would be buffered (which I do not want, for reasons of memory usage and latency).

Describe the solution you'd like
Queues should allow for their maximum number of elements to be zero. A zero-length queue does not buffer any elements, but only transfers data when a send and receive call pair up. This is sometimes referred to as a "rendezvous queue". Rust's crossbeam-channel implementation describes this as follows:

A special case is zero-capacity channel, which cannot hold any messages. Instead, send and receive operations must appear at the same time in order to pair up and pass the message over.

In my problem, the receiving task would loop with a blocking call to xQueueReceive(queue, buffer, portMAX_DELAY); when it is done processing the previous data item, the producer A uses xQueueSend(queue, buffer, 0);, that is, non-blocking. This means some data items are not transferred from A to be, which is fine in my use-case.

Describe alternatives you've considered
I tried work-arounds using semaphores but this is very tricky to get right without subtle race conditions. If there is a way to implement this using already available synchronization primitives I'd be happy to hear about that!

[moninom1]

HI @michael-p
Thanks for the detailed feature request!

Would you be interested in implementing this feature yourself? If you're willing to contribute the implementation, we can help guide you through the process.
Otherwise, we'll consider it for future development.

Let us know if you'd like to take this on!

[aggarg]

What do you want to do with the data if the receiver is not waiting? If you have size 1 queue and the sender keeps overwriting the item, it would mean the receiver would always get the latest item whenever it attempts to read. Would that work for you? What problem are you trying to solve? You may also want to use FreeRTOS Forums to discuss the issue.

[michael-p]

@moninom1 Sadly I have zero experience with the FreeRTOS internals, so given the high degree of subtlety of the code involved I fear I'm not able implement this myself, sorry.

@aggarg Some more specific details about my problem: task A (the sender) handles a camera sensor that captures images at 30 hertz. It does some simple preprocessing on the images (downscaling mostly) and sends the resulting heap-allocated image to another task B for CPU-intensive (and long running) processing. Task A must not block, hence I use a queue and send the image with a block time of 0. This CPU-intensive receiving task B can consume images at a rate of about 1 to 10 Hertz, when it is not ready to receive a new image then task A (the camera task) just drops the data (which is fine - it also sends the image to various other tasks for different processing, but I described only task B here to keep things simple).

Using a queue of size 1 and overwriting the item (a "mailbox" I guess) does indeed solve the issue of the receiving task always getting the most recent item. However, it has a few problems that a true rendezvous queue hasn't:

• the items in my case are heap-allocated images, so each one consumes significant amounts of memory. With a rendezvous queue items are "handed over" from sender to receiver, that is, there is always only one copy of the data. With a queue of size 1 and overwrite-behavior, however, there are two items allocated at each point in time: one that the receiving task is currently processing, and another on that sits in the queue and gets overwritten again and again.
• since the data I put in the queue is a pointer to a heap allocation (as described in the previous point) someone has to free the allocation when the item in the queue gets overwritten without consumption. As far as I can tell this is impossible with the current design of FreeRTOS. In fact, my project is actually written in Rust, which has strict ownership rules to prevent memory leaks. The bindings that I use do not include support for overwriting items in a queue for this exact reason: it's pretty much impossible to implement safely for types that are not trivially copyable. A rendezvous queue however has clear ownership semantics and can be used safely.

[aggarg]

Thank you for the detailed explanation. How about having a longer queue where the receiver only processes the most recent item while discarding older ones? This way if the sender sends 6 images before receiver gets a chance to process, the receiver will drop/free the first 5 and only process the most recent one.

[michael-p]

That would work, however the issue is that this keeps 6 images in memory (in your example), which is more than the total RAM available on our MCU (this is the first bullet point I described previously).
The work-around we currently use is similar to what you describe, except we use a queue of length one and before sending something to it the sending task "drains" the queue by calling xQueueReceive(queue, buffer, 0) in a loop till the queue is empty. Then it sends the new image, the receiving task can simply do a blocking receive from the queue. This works, but is somewhat ugly and still consumes twice as much memory as would be needed with a rendezvous queue (at every point in time there are two images im RAM, whereas an optimal solution using a rendezvous queue would require just a single one that the receiver is currently processing).

[aggarg]

That sounds like a good workaround. Would you please create a post on the FreeRTOS forums as well?

[hoxi]

Maybe this is a discussion that can continue on the forum, but I just want to second this feature request. I have numerous times wanted this type of feature, and always had to implement a layer on top of FreeRTOS to achieve the described behavior. Supporting a queue with size 0 feels like a natural extension to the current API. And even if it would is sort of a special case, it still fits very well into the semantics of tasks and queues.

[michael-p]

That sounds like a good workaround. Would you please create a post on the FreeRTOS forums as well?

Well, the main disadvantage for us is the high memory consumption. Forum post is here: https://forums.freertos.org/t/zero-length-queues-a-k-a-rendezvous-queues/23924