Follow+Star Public Account Number, don’t miss exciting content
Arrangement | strongerHuang
WeChat Public Account | Embedded Column
Operating systems are divided into preemptive kernels and non-preemptive kernels, so,RTOS belongs to which type?
Let’s talk about the content of preemptive kernels and non-preemptive kernels.
Non-preemptive kernels require each task (thread) to do something to explicitly relinquish control of the CPU. To maintain the illusion of multitasking concurrency, this step must be taken.
Non-preemptive scheduling is also known as cooperative multitasking, where tasks cooperate to share the CPU, and asynchronous events are still handled by ISR. ISR can make higher priority tasks ready to run, but ISR always returns to the interrupted task.
A new higher priority task can only gain control of the CPU when the current task relinquishes it.
One of the advantages of non-preemptive kernels is lower interrupt latency; at the task level, non-preemptive kernels can also use non-reentrant functions. Each task can use non-reentrant functions without worrying about being disrupted by another task. This is because each task can run to completion before relinquishing the CPU. However, non-reentrant functions should not be allowed to relinquish control of the CPU.
The task-level response of tasks using non-preemptive kernels may be much lower than that of foreground/background systems since task-level response is now determined by the longest task’s time.
Another advantage of non-preemptive kernels is the reduced need to protect shared data using semaphores. Each task owns the CPU, so you don’t have to worry about task preemption. Of course, this is not absolute; in some cases, semaphores should still be used. Shared I/O devices may still require the use of mutex semaphores; for example, tasks may still need exclusive access to a printer.
(1) A task is executing but is interrupted.
(2) If interrupts are enabled, the CPU vectors (jumps) to the ISR.
(3) The ISR handles the event and prepares a higher priority task to run.
(4) After the ISR completes, the execution returns instruction, and the CPU returns to the interrupted task.
(5) The task code resumes at the instruction after the interrupt instruction.
(6) When the task code completes, it calls the kernel-provided service to hand over the CPU to another task.
(7) The kernel sees that a higher priority task is ready to run, so it performs a context switch to run (i.e., execute) the higher priority task to handle the event signaled by the ISR.
The most significant disadvantage of non-preemptive kernels is responsiveness: A higher priority task that is ready to run may have to wait a long time to run because the current task should relinquish the CPU in a timely manner.
Similar to background execution in a foreground/background system, the task-level response time in non-preemptive kernels is uncertain; you never know when the highest priority task will gain control of the CPU. This operation is determined by your application on when to relinquish control of the CPU.
In summary, non-preemptive kernels allow each task to run until it voluntarily relinquishes control of the CPU. Interrupts preempt tasks, and after the ISR completes, it returns to the interrupted task. Task-level responses are much better than in foreground/background systems, but they are still uncertain, which is why few commercial kernels are non-preemptive.
Most real-time kernels like μC/OS-II, RTT, etc., are preemptive, where the highest priority task that is ready to run is always given control of the CPU.
When a task makes a higher priority task ready to run, the current task is preempted (suspended) and the higher priority task immediately gains control of the CPU.
If the ISR makes a higher priority task ready, when the ISR completes, the interrupted task is suspended and the new higher priority task is resumed.
(1) A task is executing but is interrupted.
(2) If interrupts are enabled, the CPU vectors (jumps) to the ISR.
(3) The ISR handles the event and prepares a higher priority task to run. After the ISR completes, it calls the kernel-provided service (i.e., calls the function provided by the kernel).
(4) & (5) The function knows that a more important task is ready to run, so the kernel performs a context switch and executes the more important code instead of returning to the interrupted task. When the more important task is completed, another kernel-provided function is called to put the task into a sleep state, waiting for an event (i.e., ISR) to occur.
(6) & (7) The kernel then “sees” that a lower priority task needs to be executed and completes another context switch to resume the execution of the interrupted task.
With preemptive kernels, the execution of the highest priority task is deterministic; you can determine when it can control the CPU. Therefore, using preemptive kernels can minimize task-level response time.
Application code using preemptive kernels should not use non-reentrant functions, unless exclusive access to these functions is ensured through the use of mutex semaphores, since both low-priority and high-priority tasks can use common functions. If a higher priority task preempts a lower priority task that is using that function, data corruption may occur.
In summary, preemptive kernels always execute the highest priority task that is ready to run. Interrupts preempt tasks, and after the ISR completes, the kernel continues to execute the highest priority task that is ready to run (instead of the interrupted task). Task-level responses are optimal and deterministic, when system responsiveness is critical, it is recommended to use preemptive kernels.
● Column “Embedded Tools“
● Column “Embedded Development”
● Selected Tutorials from Embedded Column
Follow the public account reply “Join Group” to join the technical exchange group according to the rules, reply “1024” to see more content.
Click “Read Original” to see more shares.
