taskYield in cooperative scheduling

Kernel
1

roccoiacchetti wrote on Thursday, August 28, 2008:

I’m running freeRTOS in cooperative scheduling to serve an ultra low-power remote sensor.

Now, if an higher priority task decides to suspend itself for a given amount of time, CPU is correctly given to a lower priority task. Suppose now that the amount of time elapses and the lower priority task is still running, how can the higher priority one be woken up?
The timer interrupt routine just increment ticker. In the function called by this interrupt routine every task that has become ready is moved in ready list, but no taskYield is called. It seems to me that the increment ticker function should return if an higher priority task has been woken up, much like xQueueReceiveFromISR do, for example.
Same problem for xQueueSend (not ISR version). If a lower priority task wakes an higher priority one, there is no way to know if a taskYield should be called or not.

On the other way, simply calling taskYield in the ISR routine or after an xQueueSend works, but it is very inefficient. In fact if the calling task is already the higher one, this will do a useless SAVE/RESTORE context.
Why not provide a function call much like the xxxFromISR version?

Thanks to everyone will help me on this!
Rocco.

2

davedoors wrote on Thursday, August 28, 2008:

Using the cooperative scheduler the tick interrupt will unblock the higher priority task when its delay time expires but will not start it running. The cooperative scheduler will only start the higher task running when the lower task either blocks or calls taskYIELD(). This is why its called cooperative, the switch to a higher priority task will not occur without the say so of the lower priority task. If you want the switch to happen automatically as soon as the higher priority task unblocks then you have to use the preemptive scheduler.

Be careful calling taskYield() from an ISR, some ports allow you to do this directly while other require a bit of special syntax to be used.