Going through the manual for Free RTOS, I encountered a sentence where it mentions
It is important to note that the end of a time slice is not the only place that the scheduler can select a new task to run; as will be demonstrated throughout this book, the scheduler will also select a new task to run immediately after the currently executing task enters the Blocked state, or when an interrupt moves a higher priority task into the Ready state.
I am confused with the way preemption works in Free RTOS. Consider a task A with priority 1 is in RUNNING state. Also consider task B with higher priority 2 enters READY state when the task A is in the middle of the time slice.
Q1: What type of interrupt is the manual talking about?
Q2: Is the interrupt only way to take the task B to READY state while the task A is in RUNNING state?
Q3: If answer to Q2 is no, when would the task switching occur if it is not interrupt driven? Is it after the time slot ends or is it immediately at the middle of the time slice without waiting for the end of time slice?
You describe the following situation where you have two tasks with different priorities:
In this situation, it's important to ask yourself a question - what would be the possible scenarios that would lead to this situation?
The general rule of a thumb when dealing with tasks of different priorities in FreeRTOS is that the higher priority task will be given all the available time, unless it cannot run due to being SUSPENDED, BLOCKED (waiting for queue, semaphore, mutex) or put in a delay (this also falls into BLOCKED state). Therefore in your case - task A would never enter RUNNING state unless task B was previously either SUSPENDED or BLOCKED.
To answer your questions:
Q1: What type of interrupt is the manual talking about?
I'd assume they're talking about a situation where task B is in a blocked state due to waiting for semaphore/queue and you "give a semaphore" / "send to quque" from an interrupt. Examples of this happening: IO level interrupt giving a semaphore, UART interrupt pushing received byte into a queue.
Q2: Is the interrupt only way to take the task B to READY state while the task A is in RUNNING state?
I'd say no. Other examples that come to mind (apart from the interrupt cases mentioned above):
Task B is SUSPENDED and task A decides to resume task B. When you do so, task B should resume execution immediately and take all the available time from this point on, unless it again enters SUSPENDED or BLOCKED state.
Task B is waiting for a mutex held by task A and task A releases it.
Task B is waiting on a semaphore/queue and task A "gives semaphore", "sends to queue".
Task B was in a delay and that delay ended.
Q3: If answer to Q2 is no, when would the task switching occur if it is not interrupt driven? Is it after the time slot ends or is it immediately at the middle of the time slice without waiting for the end of time slice?
I already listed possible examples above. To mention it again - when you have two tasks with different priorities, then unless the higher priority task gets into BLOCKED or SUSPENDED state, it'll take all available time from the lower priority task. While technically you can still speak of "time slices" in this case, all of the slices will be assigned/consumed by higher priority task. Therefore, speaking of "time slicing" only really makes sense when you have two or more tasks running with same priority, in which case time should be split between them evenly (unless they get BLOCKED or SUSPENDED).