xQueueSend safety regarding critical section

Does someone know for 100% if xQueueSend should be protected by ENTER/EXIT critical section? Both replies in forums and even examples inside FreeRTOS code are controversial. If it shouldn’t be protected, is it safe if it happens by mistake to be inside critical section or will it cause troubles?

Thank you very much

xQueueSend does not need protection with a critical section, as it uses critical sections inside itself to handle the operations that need protection.

Depending on the port, it may be required that if inside a critical section that the wait time be set to 0. (Some ports will allow blocking inside critical sections, which leave the critical section until that task resumes, but some do not).

1 Like

Would you please point us to the examples you are talking about.

Which FreeRTOS port are you using? As @richard-damon mentioned, it depends on the port but it is best not to call xQueueSend (with non-zero wait time) from a critical section to avoid unexpected behavior. Why do you want to call xQueueSend from a critical section?

Thank you @richard-damon for the reply. First, we searched through online documentation of FreeRTOS and then through the pdf document, there was nowhere stated what you replied here explicitly - if it’s safe or not safe, what consequences to expect if it is placed into critical section block and about the timeout being 0. That’s why it’s very helpful to read this reply here. I searched for some clear statement somewhere in more official docs, besides people discussions, and didn’t find it.

I don’t have a desire to put it into critical section block, but there were issues with the code and I found several places like that which raised this question as potential reason.

Hi Jenny,

here are two more observations that may or may not be helpful:

  1. The critical section (CS) may be looked at as FreeRTOSs “internal” synchronization primitive. By suppressing ALL OS-affected concurrency, it “brute forces” everything running under its control to be uninterrupted.
  2. Queues are the historically first and most basic “high level” synchronization primitives from which all other sync objects such as semaphores, muteces and mailboxes used to derive for a long time. Queues were and are also used heavily inside the FreeRTOS kernel to serialize access to system data structures such as task lists.
    Both observations taken together necessarily enforce that queue accesses are strictly serialized, which for the kernel implies they are always accessed under control of the critical sections