Observation on direct task notifications

os21doug wrote on Wednesday, 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!

Cheers,

Doug

rtel wrote on Wednesday, 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.

os21doug wrote on Wednesday, 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 :slight_smile: ), 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