Special case with two tasks at equal priority

I have this case with two tasks at an equal and low priority:
Task1 checks data in an endless loop and never gets blocked or suspended.
Task2 does some short jobs and then gets blocked in waiting for queue input.
Task1 and task2 run at priority 1.
There are more task running up to priority 4 that process shorter jobs and then get blocked again.
Now, will task2 ever run, once task1 has started? Or do I need another priority for task2 right above task1, shifting the others up by 1?
Currently I have:
#define configUSE_PREEMPTION 1
#define configUSE_TIME_SLICING 0
Do I need time slicing active? How will task1 and task2 then get run time?

Thanks for any help

The following is the description of configUSE_TIME_SLICING from this page:

By default (if configUSE_TIME_SLICING is not defined, or if configUSE_TIME_SLICING is defined as 1) FreeRTOS uses prioritised preemptive scheduling with time slicing. That means the RTOS scheduler will always run the highest priority task that is in the Ready state, and will switch between tasks of equal priority on every RTOS tick interrupt. If configUSE_TIME_SLICING is set to 0 then the RTOS scheduler will still run the highest priority task that is in the Ready state, but will not switch between tasks of equal priority just because a tick interrupt has occurred.

  1. configUSE_TIME_SLICING is 0
    Task1 will continue to run until a higher priority task becomes ready. When the higher priority task blocks and the task2 happens to be ready, the scheduler will pick task 2 as it rounds robin the equal priority tasks.

  2. configUSE_TIME_SLICING is 1
    Task1 will for a time slice and then task 2 will run if it is ready. If task2 is not ready, task1 will continue in the next time slice as well.

I recommend this book to understand these concepts in detail - https://www.freertos.org/fr-content-src/uploads/2018/07/161204_Mastering_the_FreeRTOS_Real_Time_Kernel-A_Hands-On_Tutorial_Guide.pdf

Thanks for your answer.
One more question for clarification:
In case 2. configUSE_TIME_SLICING is 1: when a higher priority task was running and gets blocked will this also cause a switch from task 1 to task 2 or vice versa or is it only the timer tick that causes this. In other words: when the higher priority tasks gets blocked the one lower priority task that was running before will continue if there was no timer tick in between. Is that right?
Thanks for your help.

And also a question to case 1. configUSE_TIME_SLICING is 0 :
Say task1 is running and no higher task becomes ready but a timer fires and sends something to the queue that blocks task2. Will then task 2 become the one to run?
Thanks for any help.

No, that is not right. The scheduler will pick up the task that has been waiting the longest. In the example you provided, task2 will be picked up.

If task 2 blocks, it cannot run. Assuming that it is a typo and you meant “unblocks”, the scheduler will pick the task at priority 1 that has been waiting the longest. In this case, it will be T2.

I’ll again suggest to read the book I linked before, especially the chapter on tasks and scheduling.

Ok thanks. I read the tutorial and reference manual and work with FreeRTOS for some years now (and like it very much). Maybe I think I need an update or refresh :wink:
Thanks again for your help.

If the “timer” is a software timer, then a higher priority task DID become ready (the timer task, which normally should be one of the higher priority tasks in the system), and when it goes back to blocking, the system will go to the longest waiting task of the highest priority that is ready,

If the “timer” is a hardware timer, then at the end of the ISR, it will typically test the flag to see if a Higher Priority Task was woken, and since task2 was the same priority as task 1, that isn’t true, so it normally won’t force a scheduler operation, so task 1 will just continue. (The ISR could be programmed to force a scheduler operation if you wanted it to)

Normally you DO want to use TIME SLICING

Thanks for the explanations of aggarg and richard-damon. I have a clearer understanding now and changed the FreeRTOS setting in my project according to your recommendation.