Preemption, Time Slicing, and Interrupts

While an RTOS allows concurrent tasks to remain relatively ignorant of each other, it doesnt allow the programmer to remain ignorant of the very tricky technical issues associated with concurrency. The facilities within the RTOS can be quite forgiving , but it is up to the developer to know how to use the facilities properly. It is very possible for a firmware developer to write code that brings a highly regarded RTOS to its knees.

For example, if I have three tasks in my system and each task does whatever it wants to do, then chances are good that only the task at the highest priority level will ever run. To avoid this and other potential problems, the code for each task should be written so that if the task is not performing any useful work, it returns to the scheduler and lets another task do some work. A task can surrender the processor synchronously or asynchronously. To surrender control synchronously, the task should make some system call, in essence telling the OS that the task is waiting for something. If the OS knows the current task is just waiting, it can schedule some other task to do some real work. Calling the OS to wait on something is commonly called blocking, and it should be the goal of every task to do whatever has to be done as quickly as possible, then block.

Alternatively, if a task is not written for blocking, some other mechanism is needed to cause the context switch to occur. Enter interrupts. Interrupts cause an asynchronous break in the currently running code. This asynchronous break can result in the current task being preempted by some other higher priority task.

An interrupt handler written for an RTOS is usually wrapped with RTOS-specific code at the beginning and end. The closing portion of these wrappers calls the scheduler. Those system calls that are legal within an interrupt handler can detect when they are being called from within an interrupt. The code within the system call knows that if it is in an interrupt handler, it should not call the scheduler, as it normally would, but rather depend on that call happening when the interrupt handler exits. When the interrupt handler has finished, it invokes the scheduler, and, if a higher priority task is now ready to run, the switch is performed. The interrupt handler returns, but to a different task.

What if there is no system call in the interrupt handler that causes this context switch? If multiple tasks are configured with the same priority and all of the tasks refuse to block, a simple tick-driven time-slicing system can still keep the system moving. Time-slicing by the RTOS is the ability to have multiple tasks with the same priority be given a slice of the CPUs time. If your system has three tasks (all of equal priority) that all want to own the processor, the RTOSs ability to time-slice allows each task to receive some fixed number of system ticks of runtime. When the tick count is reached (a time slice), then the scheduler automatically changes context to the next task of the same priority. This approach is commonly called round- robin time-slicing.