FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [October 2015 Threads] Observation on direct task notificationsPosted by os21doug on October 21, 2015 I've just noticed an unexpected behaviour of direct task notificiations:
- task blocks, waiting on a direct notification.
- during this wait, another task decides to temporarily suspend some tasks (including the one above).
- an ISR fires, which delivers the task notification being waited on in step 1.
- 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!
Cheers,
Doug
Observation on direct task notificationsPosted 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]
Regards.
Observation on direct task notificationsPosted by os21doug on October 21, 2015 Hi,
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.
Cheers,
Doug
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|