Is xTaskNotifyGive expected to unblock xMessageBufferReceive with xTicksToWait set to portMAX_DELAY?


The title pretty much says it all. I have a system with at least two tasks. Task A calls xMessageBufferReceive with xTicksToWait set to portMax_DELAY. Based on the API Reference this should wait indefinitely until data is sent to the MessageBuffer. Task B calls xTaskNotify with the TaskHandle of Task A. When doing this xMessageBufferReceive of Task A returns 0 and Task A starts to run. The questions I want answered are:

  • Is xTaskNotify expected to unblock xMessageBufferReceive?
  • Is calling xTaskNotify without calling ulTaskNotifyTake wrong?

Thanks in advance for any help.

~ Andrew

  • Yes, using the basic, non-indexed notifications unblocks stream- and message buffers as side effect caused by the (very lean) implementation.
    Application writers need to take care about the return code to handle this ambiguity.
    See also this thread for further details.
    Indexed notifications were introduced with FreeRTOS 10.4.0.
  • It’s not wrong, but usually xTaskNotify is paired with ulTaskNotifyTake to be useful.
1 Like

Adding to hs2’s answers - this is a side effect of stream buffers using task notifications in their internal implementation. Since FreeRTOS V10.4.0 each task has an array of task notifications (previously they just had one), and stream buffers always use the task notification at array index 0. So if you want to send a notification to the task that just remains pending rather than unblocks the task that is waiting on a stream buffer use a task notification any any array index other than 0. See for info on the V10.4.x behaviour.


I really appreciate the responses. This was exactly the information I was looking for.