pxHigherPriorityTaskWoken usage clarification

rsgrimes wrote on Thursday, August 11, 2016:

Three questions, with a bit of background.

Many of the functions that may be safely called from an ISR have a pointer parameter often named pxHigherPriorityTaskWoken. My understanding is that if this is not NULL, and the associated call causes a higher priority task to unblock, then *pxHigherPriorityTaskWoken will be set true, and the calling ISR should call portYIELD_FROM_ISR() prior to returning to activate the unblocked, higher priority task.

  1. Is this a correct understanding?
  2. If portYIELD_FROM_ISR isn’t called, then the task will eventually be unblocked, but not until some other event causes the scheduler to reevalute the ready tasks; is that correct?

Finally, I’ve noticed that the online API documentation (example: http://www.freertos.org/a00119.html) has changed to add this note to the pxHigherPriorityTaskWoken parameter:

“From FreeRTOS V7.3.0 pxHigherPriorityTaskWoken is an optional parameter and can be set to NULL.”

  1. If you don’t supply this parameter, then you won’t be notified of a higher-priority task being woken, so it won’t get scheduled as soon as possible; is that the sole effect of not using this parameter?

richard_damon wrote on Friday, August 12, 2016:

  1. Yes.
  2. Yes, for example, the tick interrupt.
  3. Yes, It isn’t quite ‘optional’, as you have to provide something, but if you pass a NULL (or a 0) then you just don’t get the indication that someone has woken. In effect, when/if it is time to set the flag true, that operation is skipped if you pass a null pointer.