Context switches & granularity

tns1 wrote on Friday, October 03, 2008:

Assuming scheduler started and tasks are being used with pre-emption on:

It looks like the scheduler is only called a couple of different ways. The first is by the timer tick, which imposes the base scheduler granularity of when a task can be made to run.
The second is by calling taskYIELD/portYIELD, which could possibly cause another task to run a bit sooner that it normally would (it doesn’t have to wait for the next timer tick), but only if it were already made ready by other system events (messages, irqs, mutexes, etc).

Said another way, the highest priority ready task will always begin running at the time of a timer tick, possibly sooner if there has been a call to taskYIELD/portYIELD.

Does this sound right, or is there something missing?

rtel wrote on Friday, October 03, 2008:

Calls to taskYIELD() can also occur within API functions that either cause a task to block, unblock, suspend, unsuspend, as well as API functions that cause a priority to be changed.


tns1 wrote on Friday, October 03, 2008:

I think I see now. taskYIELD is used anyplace the priorities might be changed, so it should make the system more responsive to events in general.