dragonflight1 wrote on Saturday, February 14, 2015:
A year ago I tried to understand configUSE_TIME_SLICING with the goal of having the scheduler guarantee mutual exclusion rather than use semaphores/mutexes/notifications to share common resources (non-reentrant sprintf, I2C, DSP …) among a set of tasks ( https://sourceforge.net/p/freertos/discussion/382005/thread/278999da ).
I recently came across https://sourceforge.net/p/freertos/discussion/382005/thread/c5bc7c5e in which RTE suggests that a change made for V8.0.0
+ Previously, when a task left the Blocked state, a context switch was
performed if the priority of the unblocked task was greater than or equal
to the priority of the Running task. Now a context switch is only
performed if the priority of the unblocked task is greater than the
priority of the Running task.
made this possible.
Unfortunately this doesn’t help as a task becoming unblocked as a result of a timeout and a priority >= current priority will cause a yield and the ready queue to rotate. (Note: the >= is not the problem, but rather that a task switch calls listGET_OWNER_OF_NEXT_ENTRY which rotates the ready queue.)
I’m not sure configUSE_TIME_SLICING is the right config parameter to use (Richard suggested it had particular meaning in some documentation), but what would be really nice is to use a per priority level flag to control “mutual exclusivity/time slicing within a priority level”. A second flag could be used to force a rotation if a task relinquished control through a portYield() or a vTaskDelay(0).
This would allow the user to user normal preemptive time slicing except in the few cases where it would be beneficial to use cooperative instead.
I believe this would be useful to even non-expert users.
mike