UNIT-II

Introduction to Real-Time Operating Systems

• RTOS – Real Time Operating System
• Application S/W – System H/W tightly coupled together – No
Portability
• OS interface between Application code and system H/W – creates
abstraction – Hence Portability
• GPOS – General Purpose OS – UNIX, Windows …
• UNIX – was first GPOS – targeted for research – Command line
interface
• Windows – GPOS – Personal computer – Graphical system Interface
Introduction to Real-Time Operating Systems
• For Embedded Computing – RTOS – VxWorks
• Common Functionality of GPOS and RTOS
• Multitasking
• Resource management (S/W & H/W)

• OS services to Application

• Abstracting the hardware from the software application

Introduction to Real-Time Operating Systems
• Functional differences b/w GPOS and RTOS
• Reliability in embedded application
• Ability to scale up or down to meet application needs
• Faster performance
• Reduced memory requirements
• Scheduling policies tailored for real-time embedded systems
• Support for diskless embedded systems by allowing executables to boot and run
from ROM or RAM, and
• Better portability to different hardware platforms
Introduction to Real-Time Operating Systems

• GPOS – used in personal computers, workstations, and mainframes

• GPOS – can also run embedded systems – having large memory and
soft real time systems

• RTOS – suited for low memory, hard real time systems, high
performance required
Defining an RTOS

• RTOS is a program that schedules execution in a timely manner,

manages system resources, and provides a consistent foundation for
developing application code.

• RTOS ranges from small application to complex application

• RTOS has Kernel (core S/W module and other modules)

Defining an RTOS
Defining an RTOS
• RTOS Kernel Components:
• Scheduler- is a set of algorithms – schedules which task executes when
• EX: Round-Robin and Pre-emptive scheduling algorithms

• Objects – its special kernel constructs – helps to develop applications for Real time
embedded systems
• EX: Tasks, Semaphores, and Message queues

• Services-are operations that the kernel performs on an object or, generally

operations such as timing, interrupt handling, and resource management.
Defining an RTOS
The Scheduler
• A scheduler provides the algorithms needed to determine which task
executes when
• To understand how scheduling works,
• schedulable entities,
• multitasking,
• context switching,
• dispatcher, and
• scheduling algorithms.
The Scheduler
• Schedulable Entities
• A schedulable entity is a kernel object that can compete with other kernel
objects for system execution time based on a predefined scheduling
algorithm
• Examples of schedulable entities: Tasks and processes
• Task: A task is an independent thread of execution that contains a
sequence of independently schedulable instructions
• Process: Processes are similar to tasks in that they can independently
compete for CPU execution time.
The Scheduler

• Processes differ from tasks in that they provide better memory

protection features, at the expense of performance and memory
overhead.

• So, how exactly does a scheduler handle multiple schedulable entities

that need to run simultaneously?
• Ans: By multitasking
The Scheduler
• Multitasking
• Multitasking is the ability of the operating system to handle multiple activities
within set deadlines.

• A real-time kernel might have multiple tasks that it has to schedule to run
The Scheduler
The Scheduler

• In the above scenario, the kernel multitasks in such a way that many
threads of execution appear to be running concurrently;

• The kernel is actually interleaving executions sequentially, based on a

preset scheduling algorithm

• The scheduler must ensure that the appropriate task runs at the right
time
The Scheduler

• The tasks follow the kernels scheduling algorithm

• If interrupt service routines (ISR) are triggered to run because of

hardware interrupts, that also need to be considered another task

• As the number of tasks to schedule increases…Multi tasking is to be

done by context switching.
The Scheduler
• Context Switch
• Each task has its own context
• which is the state of the CPU registers required each time it is scheduled to run

• A context switch occurs when the scheduler switches from one task to another
• Every time a new task is created, the kernel also creates and maintains an associated task
control block (TCB).
• TCBs are system data structures that the kernel uses to maintain task-specific information.
• When a task is running, its context is highly dynamic
The Scheduler
• This dynamic context is maintained in the TCB.
• When the task is not running, its context is frozen within the TCB, to
be restored the next time the task runs
The Scheduler
The Scheduler
• When the kernel s scheduler determines that it needs to stop running task
1 and start running task 2, it takes the following steps:
1. The kernel saves task 1’s context information in its TCB.
2. It loads task 2’s context information from its TCB, which becomes the current
thread of execution.
3. The context of task 1 is frozen while task 2 executes, but if the scheduler needs to
run task 1 again, task 1 continues from where it left off just before the context
switch.
The Scheduler

• The time it takes for the scheduler to switch from one task to another
is the context switch time.

• It is relatively insignificant

• If an application design includes frequent context switching, the

application can incur unnecessary performance overhead.
The Scheduler

• When the scheduler determines a context switch is necessary, it needs an

associated module, called the dispatcher, to make that switch happen

• The Dispatcher
• The dispatcher is the part of the scheduler that performs context switching and
changes the flow of execution

• The dispatcher that does the actual work of context switching and passing execution
control
The Scheduler
• The Dispatcher working
• 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, or
• 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.
The Scheduler

• The Dispatcher working

• 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 of the scheduler that determines which

task executes next.
The Scheduler
• The Dispatcher working
• 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.
• 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
The Scheduler
• The Dispatcher working
• 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.
The Scheduler

• Scheduling Algorithms
• The scheduler determines which task runs by following a scheduling
algorithm - also known as scheduling policy

• Two common scheduling algorithms:

• Pre-emptive priority-based scheduling

• Round-robin scheduling

• Developers can create and define their own scheduling algorithms

The Scheduler
• Pre-emptive priority-based scheduling
• Most often used algorithm
• The task that gets to run at any point is the task with the highest priority
among all other tasks ready to run in the system.
The Scheduler
• Pre-emptive priority-based scheduling
• Real-time kernels generally support 256 priority levels
• 0 is the highest and 255 the lowest
• Some kernels have the priorities in reverse order, where 255 is the highest and 0 the lowest
• With a preemptive priority-based scheduler, each task has a priority, and the highest-priority
task runs first
• If a task with a priority higher than the current task becomes ready to run, the kernel
immediately saves the current task’s context in its TCB and switches to the higher-priority
task
The Scheduler
• Pre-emptive priority-based scheduling
• Although tasks are assigned a priority when they are created, a task’s priority
can be changed dynamically using kernel-provided calls
• The ability to change task priorities dynamically allows an embedded
application the flexibility to adjust to external events as they occur, creating a
true real-time, responsive system
• Misuse of this capability can lead to priority inversions, deadlock, and
eventual system failure
The Scheduler
• Round-Robin Scheduling
• Round-robin scheduling provides each task an equal share of the CPU
execution time

• Pure round-robin scheduling cannot satisfy real-time system requirements

• Round-robin scheduling, which uses time slicing to achieve an equal

allocation of the CPU for tasks of the same priority, can be added to
preemptive priority-based scheduling.
The Scheduler
• Round-Robin Scheduling
The Scheduler
• Round-Robin Scheduling
• With time slicing, each task executes for a defined interval, or time slice, in an
ongoing cycle, which is the round robin
• A run-time counter tracks the time slice for each task, incrementing on every clock
tick.
• When one task s time slice completes, the counter is cleared, and the task is placed
at the end of the cycle.
• Newly added tasks of the same priority are placed at the end of the cycle, with their
run-time counters initialized to 0.
The Scheduler
• Round-Robin Scheduling
• If a task in a round-robin cycle is preempted by a higher-priority task, its run-
time count is saved and then restored when the interrupted task is again
eligible for execution.
• From below fig. in which task 1 is preempted by a higher-priority task 4 but
resumes where it left off when task 4 completes.
Objects
• Kernel objects are special constructs that serve as the foundation for
developing applications for real-time embedded systems.
• The most common RTOS kernel objects
• Tasks: Tasks are execution threads that run concurrently and independently
and compete for CPU time.
• Semaphores: are token-like objects that can be incremented or decremented
by tasks for synchronization or mutual exclusion.
• Message Queues: are buffer-like data structures that can be used for
synchronization, mutual exclusion, and data exchange by passing messages
between tasks.
Services
• Services that help developers create applications for real-time
embedded systems
• These services comprise sets of API calls that can be used to perform
operations on kernel objects or can be used in general to facilitate
timer management, interrupt handling, device I/O, and memory
management.
Key Characteristics of an RTOS
• Some of the more common characteristics of an RTOS
• Reliability,

• Predictability,

• Performance,

• Compactness,

• Scalability.
Key Characteristics of an RTOS - Reliability
• Embedded systems must be reliable
• Depending on the application, the system might need to operate for
long periods without human intervention
• Degrees of reliability
• Ex: Solar Calculator and Telecom Switch
• While RTOS’s must be reliable, note that the RTOS by itself is not what
is measured to determine system reliability
• It is the combination of all system elements-including the hardware,
BSP, RTOS, and application-that determines the reliability of a system
Key Characteristics of an RTOS - Reliability
• Acceptable Down Time
Number of 9s Downtime per year Typical application
3 Nines (99.9%) ~9 hours Desktop
4 Nines (99.99%) ~1 hour Enterprise Server
5 Nines (99.999%) ~5 minutes Carrier-class Server
6 Nines (99.9999%) ~31 seconds Carrier Switch Equipment
Key Characteristics of an RTOS - Predictability
• Many embedded systems are also real-time systems, meeting time
requirements is key for proper operation
• The RTOS used in this case needs to be predictable to a certain
degree.
• For this, operating system calls occurs within known timeframes.
• Developers can write simple benchmark programs to validate the
determinism of an RTOS
• In a good deterministic RTOS, the variance of the response times for
each type of system call is very small.
Key Characteristics of an RTOS - Performance
• This requirement dictates that an embedded system must perform
fast enough to fulfill its timing requirements
• The more deadlines to be met-and the shorter the time between
them-the faster the system's CPU must be.
• Underlying hardware can dictate a system's processing power, its
software can also contribute to system performance
• Typically, the processor's performance is expressed in million
instructions per second (MIPS).
Key Characteristics of an RTOS - Performance
• Throughput also measures the overall performance of a system, with
hardware and software combined
• Throughput : The rate at which a system can generate output based on the
inputs coming in. (or)
• Amount of data transferred divided by the time taken to transfer it
• Data transfer throughput is typically measured in multiples of bits per second
(bps)
• Sometimes developers measure RTOS performance on a call-by-call
basis
• Benchmarks are written by producing timestamps when a system call
starts and when it completes - helpful in the analysis stages of design
Key Characteristics of an RTOS - Compactness
• Application design constraints and cost constraints help determine how
compact an embedded system can be
• Ex: A cell phone clearly must be small, portable, and low cost.
• These design requirements limit system memory, which in turn limits the size of the
application and operating system
• In such embedded systems, where hardware real estate is limited due to
size and costs, the RTOS clearly must be small and efficient
• In these cases, the RTOS memory footprint can be an important factor.
• To meet total system designers must understand both the static and
dynamic memory consumption of the RTOS and the application that will
run on it.
Key Characteristics of an RTOS - Scalability
• RTOSes can be used in a wide variety of embedded systems, they
must be able to scale up or down to meet application-specific
requirements
• Depending on how much functionality is required, an RTOS should be
capable of adding or deleting modular components, including file
systems and protocol stacks.
• If an RTOS does not scale up well, development teams might have to
buy or build the missing pieces.
Key Characteristics of an RTOS - Scalability
• Suppose that a development team wants to use an RTOS for the
design of a cellular phone project and a base station project.
• If an RTOS scales well, the same RTOS can be used in both projects,
instead of two different RTOSes, which saves considerable time and
money.