A year ago I tried to understand configUSETIMESLICING 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 listGETOWNEROFNEXTENTRY which rotates the ready queue.)

I'm not sure configUSETIMESLICING 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

Thanks for the suggestion. You could add this to a feature request tracker in SourceForge so it doesn't get lost as an idea - although I have to be honest and say that, with everything else we have going on at the moment, it would be some time before such a change was considered.

Regards.

I will add it, but I hope you consider it. The implementation is trivial and all changes restricted to the actual use of the new feature.