General Purpose Operating System
Background: What’s a “Real Time” System?
What makes an OS Real-Time?
Predictable (possibly deterministic
behavior), that’s all
By product: mediocre throughputs
How do they work?
Tasks are scheduled by OS according to
fixed priority (typically)
Tasks can’t directly interact; they use
messages or shared memory & semaphores
to communicate
Real Time System
A system is said to be Real Time if it is
required to complete it’s work & deliver it’s
services on time.
Example – Flight Control System
All tasks in that system must execute on time.
Non Example – PC system
Non-Real-Time systems
Fire alarm system: an example
Central server
TCP/IP over radio
Controllers: ARM based
Low bandwidth radio links
Sensors: microcontroller based
Fire Alarm System
Problem
Hundreds of sensors, each fitted with Low Range Wireless
Sensor information to be logged in a server & appropriate action
initiated
Possible Solution
Collaborative Action
Routing
Dynamic – Sensors/controllers may go down
Auto Configurable – No/easy human intervention.
Less Collision/Link Clogging
Less no of intermediate nodes
Fast Response Time
Secure
What is a RTOS ??
Designing an RTOS: End Goal
Have known switching & scheduling
overhead
Avoid common problems like priority
inversion and deadlock
Designing an RTOS:
Common Problems
Priority inversion
High-level task stalled due to low-level using
shared resources, then a medium-level task
holding up the low-level one
Solution: Priority inheritance – give low-level
task high-level priority
Designing an RTOS: Common Problems
(con’t)
Deadlock
Two semaphores locked out of order by two tasks
and circularly block each other
Solution: “Instant Inheritance” implementation of
Priority Ceiling Protocol – semaphores possibly
needed by higher processes become priority tokens
Designing with an RTOS: What do you
need?
Task information
Priorities for each task
Worst-case runtime
Best-case period
Solving Problems
Logs
Time Machines
Memory Conservation
Types of RTOS
Soft Real-Time system
Hard Real-Time system
Soft Real-Time system
Hard Real-Time system
Hard and Soft Real Time Systems
(Operational Definition)
Hard Real Time System
Validation by provably correct procedures or extensive
simulation that the system always meets the timings
constraints
Soft Real Time System
Demonstration of jobs meeting some statistical
constraints suffices.
Example – Multimedia System
25 frames per second on an average
Role of an OS in Real Time Systems
Standalone Applications
Often no OS involved
Micro controller based Embedded Systems
Some Real Time Applications are huge &
complex
Multiple threads
Complicated Synchronization Requirements
Filesystem / Network / Windowing support
OS primitives reduce the software design time
Basic functions of RTOS kernel
Task Management
Task States
Interrupt handling
Interrupt handling
Memory management
Exception handling
Exception handling
Task Synchronization
Task Synchronization
Task scheduling
Task scheduling
Task scheduling
Task scheduling
Task scheduling
Example of Task scheduling (RR
Time management
Time interrupt : A high resolution hardware timer is
programmed to interrupt the processor at fixed rate
Each time interrupt is called a system tick
The tick may be chosen according to the given task
parameters
Resource Allocation in RTOS
Resource Allocation
The issues with scheduling applicable here.
Resources can be allocated in
Round Robin
Priority Based
Some resources are non preemptible
Example : semaphores
Priority Inversion if priority scheduling is used
Priority Inversion
Solutions to Priority Inversion
Non Blocking Critical Section
Higher priority Thread may get blocked by unrelated
low priority thread
Priority Ceiling
Each resource has an assigned priority
Priority of thread is the highest of all priorities of the
resources it’s holding
Priority Inheritance
The thread holding a resource inherits the priority of the
thread blocked on that resource
Other RTOS issues
Interrupt Latency should be very small
Kernel has to respond to real time events
Interrupts should be disabled for minimum possible
time
For embedded applications Kernel Size should be
small
Should fit in ROM
Sophisticated features can be removed
No Virtual Memory
No Protection
Existing RTOS categories
RT Linux: an example
RT-Linux is an operating system, in which a
small real-time kernel co-exists with standard
Linux kernel
RT Linux Kernel
Why Linux
Coexistence of Real Time Applications with
non Real Time Ones
Example http server
Device Driver Base
Stability
RTLinux
Real Time Kernel at the lowest level
Linux Kernel is a low priority thread
Executed only when no real time tasks
Interrupts trapped by the Real Time Kernel
and passed onto Linux Kernel
Software emulation to hardware interrupts
Interrupts are queued by RTLinux
Software emulation to disable_interrupt()
RTLinux (contd)
Real Time Tasks
Statically allocate memory
No address space protection
Non Real Time Tasks are developed in
Linux
Communication
Queues
Shared memory
RTLinux Framework
rtker – Our RTOS
Motivation
Our own OS
Full grasp over source code – Easily modifiable, portable
Features
Modular Design
Isolation of Architecture/CPU dependent and independent code
– Easy to Port
Pluggable Scheduler
Two level Interrupt Handling
Small footprint
Oskit’s Device Driver Framework
Pluggable Scheduler
Scheduler - part of the Application
Kernel interacts with the scheduler through
an API
Application developer needs to implement
the scheduler API
Can optimize on Data Structures & Algorithms
for implementing the scheduler
rtker – Block Diagram
Two Level Interrupt Handling
Two level Interrupt Handling
Top Half Interrupt Handler
Called Immediately – Kernel never disables interrupts
Cannot invoke thread library functions - Race Conditions
Bottom Half Interrupt Handler
Invoked when kernel not in Critical Section
Can invoke thread library functions
Very Low Response time (as compared to Linux)
Two Level Interrupt Handling
Other Features
Footprint
Small footprint (~50kb)
Oskit’s Device Driver Framework
Allows direct porting of existing drivers from
Linux.
Example – Ethernet Driver of Linux
Other RTOS’s
LynxOS
Microkernel Architecture
Kernel provides scheduling/interrupt handling
Additional features through Kernel Plug Ins(KPIs)
TCP/IP stack , Filesystem
KPI’s are multithreaded
Memory Protection/ Demand Paging Optional
Development and Deployment on the same host
OS support for compilers/debuggers
Other RTOS’s (contd)
VxWorks
Monolithic Architecture
Real Time Posix compliant
Cross development System
pSOS
Object Oriented OS
Peripheral devices and protocols
• Interfacing
Serial/parallel ports, USB, I2C, PCMCIA, IDE
• Communication
Serial, Ethernet, Low bandwidth radio, IrDA,
802.11b based devices
• User Interface
LCD, Keyboard, Touch sensors, Sound, Digital
pads, Webcams
• Sensors
A variety of sensors using fire, temperature,
pressure, water level, seismic, sound, vision
Conclusion
Scheduling in RTOS
More information about the tasks are known
No of tasks
Resource Requirements
Release Time
Execution time
Deadlines
Being a more deterministic system better
scheduling algorithms can be devised.
Scheduling Algorithms in RTOS
Clock Driven Scheduling
Weighted Round Robin Scheduling
Priority Scheduling
(Greedy / List / Event Driven)
Scheduling Algorithms in RTOS (contd)
Clock Driven
All parameters about jobs (release time/
execution time/deadline) known in advance.
Schedule can be computed offline or at some
regular time instances.
Minimal runtime overhead.
Not suitable for many applications.
Scheduling Algorithms in RTOS (contd)
Weighted Round Robin
Jobs scheduled in FIFO manner
Time quantum given to jobs is proportional to it’s
weight
Example use : High speed switching network
QOS guarantee.
Not suitable for precedence constrained jobs.
Job A can run only after Job B. No point in giving time
quantum to Job B before Job A.
Scheduling Algorithms in RTOS (contd)
Priority Scheduling
(Greedy/List/Event Driven)
Processor never left idle when there are ready
tasks
Processor allocated to processes according to
priorities
Priorities
static - at design time
Dynamic - at runtime
Priority Scheduling
Earliest Deadline First (EDF)
Process with earliest deadline given highest priority
Least Slack Time First (LSF)
slack = relative deadline – execution left
Rate Monotonic Scheduling (RMS)
For periodic tasks
Tasks priority inversely proportional to it’s period
