What is the most economical way to handle queues in FreeRTOS?

Question

I am working with FreeRTOS and I am using xQueueReceive() within a task that I created with xTaskCreate(). The task does only handle received network packets. Here's the task's implementation:

while(1) {
    if(sys_link_recv_queue != NULL) {
        mb32_packet_t packet;
        if(xQueueReceive(sys_link_recv_queue, &packet, portMAX_DELAY)==pdPASS) {
            // process packet ...
        }
    }
}

When using portMAX_DELAY, the queue waits indefinitely until a queue item gets available. My question is now whether I loose valuable CPU time during this wait state or if this is the recommended way of doing this. If it's not the most economical way of doing this, what's the alternative?

What do you mean with "loose valuable CPU time"? The scheduler will schedule another task to run, I assume, which will use this "valuable CPU time" so it is used efficiently. — Paul Ogilvie
That means that it will check once whether there's an item in the queue and if not the scheduler will immediately run another task? I mean I don't want to waste a bunch of CPU cycles by "waiting" for queue as long as the task is ran by the scheduler. — salocinx
That means that if there is nothing in the queue, it will schedule another task. At some point in time an interrupt of the I/O interface occurs and the interrupt handler will place an item in the queue and marks the waiting taks as "runnable" and the scheduler will now place the task in the "runnable scheduler queue and will run it in the very near future. Anyway, that is how a scheduler of a (real time) OS normally works. — Paul Ogilvie
portMAX_DELAY probably is a constant indicating a maximum time before the I/O system determines there is a time-out. It then resumes the task, which now returns an indication "nothing received within the time-out time". — Paul Ogilvie
portMAX_DELAY depends on the port. It may mean indefinitelly or not. You need to check your port documentation / source code. Some ports ignore additional checks if this delay may mean many months. — 0___________

0___________ 0___________ · Accepted Answer · 2020-03-18T13:55:46

you do not. it is not polling. Your task is going to the blocked state and does not "consume" any CPU time. When something will place something in that queue your task status will be changed to "waiting" or "runnable" and eventually executed.

What is the most economical way to handle queues in FreeRTOS?

1 Answers