dispatcher in real time operating system

Question

I am reading about real time concepts at following link

http://www.embeddedlinux.org.cn/RTConforEmbSys/5107final/LiB0024.html

Here in section 4.4.4 it is mentioned has

The dispatcher is the part of the scheduler that performs context switching and changes the flow of execution. At any time an RTOS is running, the flow of execution, also known as flow of control, is passing through one of three areas: through an application task, through an ISR, or through the kernel. When a task or ISR makes a system call, the flow of control passes to the kernel to execute one of the system routines provided by the kernel. When it is time to leave the kernel, the dispatcher is responsible for passing control to one of the tasks in the user's application. It will not necessarily be the same task that made the system call.

It is the scheduling algorithms (to be discussed shortly) of the scheduler that determines which task executes next. It is the dispatcher that does the actual work of context switching and passing execution control.

Depending on how the kernel is first entered, dispatching can happen differently. When a task makes system calls, the dispatcher is used to exit the kernel after every system call completes. In this case, the dispatcher is used on a call-by-call basis so that it can coordinate task-state transitions that any of the system calls might have caused. (One or more tasks may have become ready to run, for example.)

On the other hand, if an ISR makes system calls, the dispatcher is bypassed until the ISR fully completes its execution. This process is true even if some resources have been freed that would normally trigger a context switch between tasks. These context switches do not take place because the ISR must complete without being interrupted by tasks. After the ISR completes execution, the kernel exits through the dispatcher so that it can then dispatch the correct task

.

My question on above text is

1. What does author mean by "When a task makes system calls, the dispatcher is used to exit the kernel after every system call completes. In this case, the dispatcher is used on a call-by-call basis so that it can coordinate task-state transitions that any of the system calls might have caused.". Specifically Here what does author mean by dispatcher is used to exit the kernel.

Thanks!

Answer 1

The author is presenting a simplified explanation of a real-time system architecture where a thread of control can be in one of three states - kernel mode (system calls), application mode (TASK), or interrupt service routine (ISR) mode.

The dispatcher in this example is a kernel routine that decides the application TASK that is to receive control after exiting each system call made by one of the application TASKs. This could be the TASK that issued the system call or it could be a different TASK depending on the dispatching algorithms and rules that are being followed.

There are many variations of dispatching rules and algorithms based on the planned usage of the system; As an example you might think of giving each TASK an equal amount of CPU time per minute - so if 3 application TASKS are being executed each one is supposed to receive 20 seconds of CPU time every minute. The dispatcher in this case could decide the next TASK to receive control is the TASK with the smallest accumulated CPU time during the last minute in an attempt to equally distribute the CPU time per minute across the TASKS.

After deciding which TASK is to next receive control the dispatcher will exit the mode of a system call and transfer control to the application TASK so invoking the dispatcher is the equivalent of "exiting" the kernel and transferring control to an eligible application TASK.

The author states that this is real-time system which means emphasis will be given to the quick processing of interrupts (via ISRs) over the processing of applications (TASKS). To minimize the amount of time consumed by each interrupt when an ISR issues a system call the kernel will directly returns to that ISR and not "exit via the dispatcher" which would allow control is to be given to an application TASK.

When the ISR has completed its processing, its exit will be performed in a manner that causes the kernel to invoke the dispatcher (hence it will exit via the dispatcher) so an application TASK can once again use the CPU.

As an additional note: one of the hidden assumptions in this explanation is that the same kernel routines (system calls) can be invoked by application TASKS and interrupt service routines (ISR). This is very common but security and performance issues might require different sets of kernel routines (system calls) for ISRs and TASKS.

Answer 2

After the system call finishes executing control has to be passed back to a user space task. There likely are many user space tasks waiting to be run and they all might have different priorities. The dispatcher uses it's algorithm to evaluate waiting tasks based on priority and other criteria (how long have they been waiting? How long do I anticipate they need?) and then starts one of them.

For example you might have an application that needs to read input from the command line. So your application calls the read() system call which passes control to the kernel. After the read() is complete, the dispatcher evaluates the tasks waiting to run and may decide another task should be run other than the one that called the read()