vTaskNotifyGiveFromISR(xTaskToNotify, *pxHigherPriorityTaskWoken) and xYieldPending

Kernel
1

dragonflight1 wrote on Sunday, February 21, 2016:

In December (r2397), the bug that xYieldPending was not set was fixed by setting it only if pxHigherPriorityTaskWoken was not null. I didn’t check all the references, but in the past xYieldPending was set regardless of pxHigherPriorityTaskWoken in other primitives that woke tasks.
The cost is trivial and while it may seem unreasonable to get the flag and then ignore it, there may be reasons.
It seems at least as unreasonable to single out vTaskNotifyGiveFromISR to enforce the user not to ignore the flag
IMHO
mike

2

woops_ wrote on Sunday, February 21, 2016:

How is vTaskNotifyGiveFromISR different to teh others ? I think its the same now ?

3

rtel wrote on Monday, February 22, 2016:

Hi Mike,

I don’t understand your post 100%, so let me know if I have this wrong:

I’ve compared the two cases of unblocking a task by writing to a queue
from an ISR and unblocking a task by sending a notification from an ISR.
In both cases xYieldPending is set to pdTRUE, but when using a queue
it is always set to true, whereas when using a notification it is only
set to pdTRUE if pxHigherPriorityTaskWoken is NULL - which would seem
inconsistent, so I think you are saying it would be better to always set
it to pdTRUE when using a notification too - which is now the case (not
checked in yet).

Regards.

4

dragonflight1 wrote on Monday, February 22, 2016:

As “they” say (at least somebody has) - You got it in one!
thanks
mike

5

rtel wrote on Thursday, February 25, 2016:

Looking at this again, I think the only reason the queues/semaphores were always setting the xYieldPending variable was because they didn’t have access to the pxHigherPriorityTaskWoken variable (one function calls another in a different file) - so that would really be the best way of doing both. However, that is not possible, and consistency is best, so I will leave the change in.