[1] A key characteristic of an RTOS is the level of its consistency concerning the amount of time it takes to accept and complete an application's task; the variability is "jitter".
The chief design goal is not high throughput, but rather a guarantee of a soft or hard performance category.
Scheduler flexibility enables a wider, computer-system orchestration of process priorities, but a real-time OS is more frequently dedicated to a narrow set of applications.
Key factors in a real-time OS are minimal interrupt latency and minimal thread switching latency; a real-time OS is valued more for how quickly or how predictably it can respond than for the amount of work it can perform in a given period of time.
Usually, the data structure of the ready list in the scheduler is designed to minimize the worst-case length of time spent in the scheduler's critical section, during which preemption is inhibited, and, in some cases, all interrupts are disabled, but the choice of data structure depends also on the maximum number of tasks that can be on the ready list.
Some commonly used RTOS scheduling algorithms are:[5] A multitasking operating system like Unix is poor at real-time tasks.
Multitasking systems must manage sharing data and hardware resources among multiple tasks.
Some modern CPUs do not allow user mode code to disable interrupts as such control is considered a key operating system resource.
Many embedded systems and RTOSs, however, allow the application itself to run in kernel mode for greater system call efficiency and also to permit the application to have greater control of the operating environment without requiring OS intervention.
On single-processor systems, an application running in kernel mode and masking interrupts is the lowest overhead method to prevent simultaneous access to a shared resource.
This method is ideal for protecting hardware bit-mapped registers when the bits are controlled by different tasks.
When the shared resource must be reserved without blocking all other tasks (such as waiting for Flash memory to be written), it is better to use mechanisms also available on general-purpose operating systems, such as a mutex and OS-supervised interprocess messaging.
The simplest deadlock scenario occurs when two tasks alternately lock two mutex, but in the opposite order.
This can be done by unblocking a driver task through releasing a semaphore, setting a flag or sending a message.
For this reason, it can be problematic when an interrupt handler calls an OS function while the application is in the act of also doing so.
The OS function called from an interrupt handler could find the object database to be in an inconsistent state because of the application's update.
RTOSs implementing the unified architecture solve the problem by simply disabling interrupts while the internal catalogue is updated.