Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


Observation on direct task notifications

Posted by os21doug on October 21, 2015

I've just noticed an unexpected behaviour of direct task notificiations:

  1. task blocks, waiting on a direct notification.
  2. during this wait, another task decides to temporarily suspend some tasks (including the one above).
  3. an ISR fires, which delivers the task notification being waited on in step 1.
  4. the task wakes up and runs, despite having been suspended.

This is not what I would have expected. The task is suspended, and should remain suspended until it is explicitly resumed (at which point the pending notification should be noted, and the task run). IMHO. It doesn't seem right that delivering the notification does an implicit resume on the task.

Opinions please!



Observation on direct task notifications

Posted by rtel on October 21, 2015

I think you are right, it is documneted that the only way out of the suspended state is for another task to unsuspend it, so the behaviour would be unexpected. I will look at what is needed to change the behaviour - although it might not be as efficient as would be hoped as there is also the posibility for a task to be suspended while waiting for a notification, and then resumed again, when the notification has not been given (the opposite case to the one you highlight). Queues and semaphores behave as you would expect in that scenario because they contain loops that that recheck the queue/semaphore condition. Adding the equivalent loop in the task notification code might not be desirable as it would be detremental to the functionalities speed characteristics. So another alternative would be to keep the code as it is now, but document the behaviour, with the recommendation that a semaphore (or whatever) is used in place of the task notification if there is a possibility that the task could be suspended. [it is actually very rare to use the suspended state]


Observation on direct task notifications

Posted by os21doug on October 21, 2015


I agree with you. I would leave the behaviour as is, and just document it. The performance of direct notifications is their desirable feature, and compromising that for what is arguably 'an API corner case' would not be a good trade off. Personally I don't normally use suspend/resume (I happened to be in 'hack mode' when I spotted this :-) ), and suspect most people don't either. I don't like the asymmetry that it introduces (i.e. suspend & resume not being balanced), but on reflection I think that just documenting it with a recommendation not to do it sounds best to me.



[ Back to the top ]    [ About FreeRTOS ]    [ Privacy ]    [ Sitemap ]    [ ]

Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

Version 10.1.0 of the FreeRTOS kernel is available for immediate download. MIT licensed.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


FreeRTOS and other embedded software careers at AWS.

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers


STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner