Real-Time Operating System Priority Levels

January 29th, 2018 by

To ensure that every event’s response is generated after tasks are executed within their specified deadlines, the CPU and other core computation resources ought to be allocated to different tasks according to their priority levels. A task or process priority may be static or fixed and is calculated based on the computing time required, deadline or invocation frequency.


Policies that allow dynamic task priority adjustment are considered more efficient because priority is determined by how quickly a task responds to a specific event. The event could be an activity within the task execution process or elapsing of the set amount of time. Tasks belonging to one category are scheduled and dispatched with similar mechanisms. Tasks are categorized into three main priority levels:

Interrupt level

Tasks under the interrupt level require a fast and frequent response that is measured in milliseconds. No scheduler is required because immediate task execution follows an interrupt. To meet task deadlines in a system, the context processing and switching time requirements should be at the bare minimum level and highly predictable to ensure that the entire system behavior remains predictable.

To maintain these high standards, the Interrupt Service Routine (ISR) operates in a special fixed and common context like the common stacks. The ISRs are divided into two parts. One part executes tasks immediately and spawns new tasks for the remaining processing time before returning to the kernel. New tasks get executed as per the set scheduling policy and in the course of time. Task priorities at the interrupt level are mainly ensured through the processor’s software and hardware interrupt policy management system. Some interrupt controllers mask low priority interrupts in the presence of high priority interrupts. The frequency of task executions depends greatly on the period assigned to high priority clock-level tasks.

Transform Windows to Deliver Software-Only Real-Time Performance whitepaper

Hard real-time level

This level handles periodic tasks such as control and sampling tasks and tasks requiring accurate timing. As such, task scheduling at this level is implemented based on a real-time system clock. The real-time system clock device is comprised of a timer queue, an interrupt handler, and counter. The counter indicates the current time while the timer queue indicates pending timers associated with the clock device.

A system clock interrupt under this level is referred to as a tick, and it represents the least time interval recognized by the system. Since most RTOS programs utilize time, virtual software delays and clocks can be formulated by tasks and associated with system clock devices. A system clock device raises interrupts periodically while the kernel updates the software clock as per the current timing. After a few clock cycles, a new task is dispatched as per the adopted scheduling policy requirement.

Soft/Non-Real Time Level

Soft or non-real time level tasks are either allowed a wide margin of error in regards to timing or have no deadlines. Therefore, they are deemed low priority tasks and are executed once all the high priority tasks are completed. Tasks at this level may run at a single priority level or may be allocated priorities. Soft or non-real time level tasks are initiated on demand as opposed to a predetermined time interval. The base level scheduler is the lowest priority clock level task. As such, the priorities of all base-level tasks must be lower than tasks at clock level.

All three priority levels can handle multiple task priorities. For an RTOS to be deemed RT-POSIX standard compliant, it must support at least 32 priority levels. For example, commercial RTOS supports priority levels that are as low as 8 for Windows CE and as high as 256 for VxWorks. Round-robin policy and FIFO policies are applied when scheduling or equal priority threads.

Start a Trial


Leave a Comment

  • eight × 2 =