Hello, I’m a newcomer according to FreeRTOS. As I read, tasks of the same priority a scheduled by round robin with time slicing. Is there a way to schedule tasks of the same priority by round robin WITHOUT time slicing? That means, that tasks of the same priority get processing time in a cooperative way in the order they enter the ready state. Best regards Stefan

So you want a yield to be performed when a task goes to sleep, calls Yield, or is woken by an event, but you don’t want an automatic yield to be performed during a tick interrupt just because a tick has occurred. I think you can do this by simply setting configUSE_PREEMPTION to 0 in FreeRTOSConfig.h.  This will still allow interrupts to preempt the running task if they wake a task that has a priority higher than the running task if you write your interrupts to do this.  But it will prevent the tick from cycling between tasks of equal priority.

Hello, the answer is saidly not satisfying to me, due to my circumstances. Therefore I must explain more my intentions. I need a real-time operating system on a Windows PC. This real-time operating system shall be preemptive and for task of same priority it shall use FIFO. On a Windows PC I don’t use interrupts, so your suggestions doesn’t work in my situation. Best regards Stefan

Windows and real time do not go together.

Hello, you absolutely right, but I don’t take care about response times. What I must take care is, that the scheduler doesn’t change the priorities of the tasks like Windows. Thus I need a real-time operating system on top of Windows. Best regards Stefan

Stefan, I am confused about which you want. First you said tasks of the same priority must work in a "cooperative" way. To FreeRTOS that means "not preemptive". In that case, you do not want preemption because you want cooperative, or in other words a task does not get interrupted until it is ready, and calls yield. Later you said you must have preemption. Seems to contradict. I believe "time slicing" simply means that only one task runs at a time. Hence, tasks of the same priority take their slices as they come. The only way to NOT have time slicing then is to have multiple CPU running simultaneously (like dual core). I don’t see why FreeRTOS would not have what you need. Whether preemptive or cooperative mode, when tasks are the same priority, they run in the order they were scheduled. One does not get skipped because anotherone wanted it to… why would it?

Hi Everyone, It appears that in FreeRTOS you can only disable time-slicing by disabling preemption.  Why can’t we disable time-slicing but leave preemption running?  We might want to design a system where a bunch of tasks at the same high priority don’t share the CPU via time-slicing.  Where is it written that tasks of the same priority must always share the CPU equally? Thanks

pshubel,
It is by design. Imagine the scheduler works on a queue of tasks of same priority. Also assume that the scheduler is wholly responsible for switching tasks, i.e. the tasks can’t tell the scheduler to switch to an arbitrary task, the decision is wholly on the scheduler. The scheduler takes a task and lets it run for 1 tick (several thousand of clock cycles, possibly) then puts it into the back of the queue and lets the current top-of-queue task run, for 1 tick. The result will be round-robin, time-slicing.

Thanks.  Maybe this feature can be added in a future revision.

Just so you know – tasks of equal priority may not necessarily share CPU time equally.  Whether they do or not will depend on whether they just run continuously or block/delay for anything.  You can see that two tasks of equal priority will not share CPU time equally if one spends most of its time blocked and the other never blocks. You can add a feature request in the SourceForge tracker for the option to turn time slicing off. Regards.

Hello Richard, yes, I should have mentioned that, but it seemed so obvious :)
This is wholly defined by (sorry if inaccurate) quote : ‘run the highest priority task that is ready to run (i.e. is not blocked or sleeping)’ (mind wandering) A vague idea of non-equal time sharing would be : - add a counter to the task control block
- add a reload value to the task control block
- decide to run the task, if the counter is less or equal to reload-value and the task is at the head of queue
- decrease the counter at each decision to run the task
- when zero, send the task to the back of queue unconditionally
- and reload the counter with reload-value
–  (and only the above would add to the hot path)
- also add an OS call to manipulate this reload-value from inside the task (upon creation, the reload-value would automatically be set to 1) Also some sanity checks (is there another task with same priority? how many tasks altogether? Is it sane comparing to others? possibly, find a lowest common multiplier/denominator and sanitize all of them accordingly?) could be introduced there. This is only useful if somebody needs a few separate tasks to run all-the-time (non-blocking/sleeping), with some arbitrary capping of the CPU usage. I wouldn’t rather expect them to be running at ‘highest’ OS priority though… quite the opposite. Because the weighed-round-robin taks would totally cut off everything below their priority, i.e. the idle task. (/mind wandering)

Oh and another thing adding to the ‘mind wandering’: - if the task decides to block itself, preserve its counter while sending it to the back of the queue. This will ensure it will get its share later.

> Why can’t we disable time-slicing but
> leave preemption running? Because that would be like saying “Why can’t we take the motor out of the car but drive it anyway?” Time-slicing is the mechanism that enables preemption. Unless an interrupt causes a task switch, how else is a task ever going to be preempted? The interrupt that does this can be the timer tick interrupt, your own interrupt(s) or both. Or have I missed something?

incrediball, actually, if you didn’t need timeout (i.e. all event waits could be wait forever for the event) and didn’t need to check for the current tick count, a program could very well run with no tick interrupt. Tasks could be preempted by an interrupt signaling data available for a higher priority task, and task would also yield when they wait for a queue that doesn’t have the needed data. Time slicing needs preemption, but preemption does not inherently need time slicing. I suppose disabling time slicing might allow you to optimize your program a bit better, as you would only need to guard data (with critical sections or mutexes) that you share with tasks of different priorities, but not with those of your same priority (but this could be a bit hazard prone as this optimization needs to know a lot about overall program structure). I could even imagine situations where this might make sense to do, if you are in a network of processors and have two data sources providing you data, it might make sense to finish your processing on one data chunk so  you can forward it to the next processor before switching to the next chunk rather than time slicing between the two of them so the first result out gets delayed. I suppose that the TCB could have added to it a field for how many time slices a given task should be given at a time, and another for how many time slices it has used this time already.

Mr. nobody could just set the Tick period to some large number and get
pretty much what he is asking for I think.