# configUSE\_TIME\_SLICING and task mutual exclusion

**URL:** <https://forums.freertos.org/t/configuse-time-slicing-and-task-mutual-exclusion/1695>\
**Category:** Kernel\
**Created:** [February 14, 2015, 5:35pm UTC](https://forums.freertos.org/t/configuse-time-slicing-and-task-mutual-exclusion/1695 "2015-02-14T17:35:47Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\
**Post date:** [February 14, 2015, 5:35pm UTC](https://forums.freertos.org/t/configuse-time-slicing-and-task-mutual-exclusion/1695/1 "2015-02-14T17:35:47Z")

</div>

**[dragonflight1](https://sourceforge.net/u/dragonflight1/)** wrote on [Saturday, February 14, 2015](https://sourceforge.net/p/freertos/discussion/382005/thread/49ed2dba/#cd65):

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](https://sourceforge.net/p/freertos/discussion/382005/thread/278999da) ).

I recently came across [https://sourceforge.net/p/freertos/discussion/382005/thread/c5bc7c5e](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

---

<div class="post-metadata">

**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\
**Post date:** [February 14, 2015, 6:09pm UTC](https://forums.freertos.org/t/configuse-time-slicing-and-task-mutual-exclusion/1695/2 "2015-02-14T18:09:17Z")

</div>

**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Saturday, February 14, 2015](https://sourceforge.net/p/freertos/discussion/382005/thread/49ed2dba/#960a):

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.

---

<div class="post-metadata">

**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\
**Post date:** [February 14, 2015, 11:03pm UTC](https://forums.freertos.org/t/configuse-time-slicing-and-task-mutual-exclusion/1695/3 "2015-02-14T23:03:54Z")

</div>

**[dragonflight1](https://sourceforge.net/u/dragonflight1/)** wrote on [Saturday, February 14, 2015](https://sourceforge.net/p/freertos/discussion/382005/thread/49ed2dba/#5c79):

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.