Chapter 5

Real Time Operating Systems

 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
 Types of real time systems
• Hard Real Time System
– Failure to meet deadlines is fatal
– example : Flight Control System
• Soft Real Time System
– Late completion of jobs is undesirable but not fatal.
– System performance degrades as more & more jobs miss
deadlines
– Online Databases
 Operating System
• Provides environment for executing programs

• Process abstraction for multitasking/concurrency

– Scheduling
• Hardware abstraction layer (device drivers)
• Filesystems
• Communication

• We will focus on concurrent, real-time issues

 Cyclic Executive
• Advantages
– Simple implementation
– Low overhead
– Very predictable

• Disadvantages
– Can’t handle sporadic events
– Everything must operate in lockstep
– Code must be scheduled manually
 Interrupts
• Some events can’t wait for next loop iteration
– Communication channels
– Transient events

• A solution: Cyclic executive plus interrupt routines

• Interrupt: environmental event that demands

attention
– Example: “byte arrived” interrupt on serial channel

• Interrupt routine: piece of code executed in response

to an interrupt
 Handling an Interrupt
1. Normal program
execution
3. Processor state
saved 4. Interrupt routine runs
2. Interrupt
occurs

6. Processor state
restored
5. Interrupt routine
terminates
7. Normal
program
execution
resumes
 Interrupt Service Routines
• Most interrupt routines:
• Copy peripheral data into a buffer
• Indicate to other code that data has arrived
• Acknowledge the interrupt (tell hardware)
• Longer reaction to interrupt performed
outside interrupt routine
– E.g., causes a process to start or resume running
 Cyclic Executive Plus Interrupts
• Works fine for many signal processing applications

• 56001 has direct hardware support for this style

• Insanely cheap, predictable interrupt handler:

– When interrupt occurs, execute a single user-specified

instruction
– This typically copies peripheral data into a circular buffer
– No context switch, no environment save, no delay
 Drawbacks of CE + Interrupts
• Main loop still running in lockstep
• Programmer responsible for scheduling
• Scheduling static
• Sporadic events handled slowly
 Role of OS in RTS
• 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
 Features of RTOS’s
• Scheduling.

• Resource Allocation.

• Interrupt Handling.

• Other issues like kernel size.

 Concurrency Provided by OS
• Basic philosophy:
Let the operating system handle scheduling, and let the
programmer handle function

• Scheduling and function usually orthogonal

• Changing the algorithm would require a change in
scheduling

• First, a little history

 Batch Operating Systems
• Original computers ran in batch mode:
– Submit job & its input
– Job runs to completion
– Collect output
– Submit next job

• Processor cycles very expensive at the time

• Jobs involved reading, writing data to/from tapes
• Cycles were being spent waiting for the tape!
 Timesharing Operating Systems
• Solution
– Store multiple batch jobs in memory at once
– When one is waiting for the tape, run the other one

• Basic idea of timesharing systems

• Fairness primary goal of timesharing schedulers

– Let no one process consume all the resources
– Make sure every process gets “equal” running time
 Real-Time Is Not Fair
• Main goal of an RTOS scheduler: meeting
deadlines

• If you have five homework assignments and

only one is due in an hour, you work on that
one

• Fairness does not help you meet deadlines

 Priority-based Scheduling
• Typical RTOS based on fixed-priority
preemptive scheduler

• Assign each process a priority

• At any time, scheduler runs highest
priority process ready to run

• Process runs to completion unless

preempted
 Typical RTOS Task Model
• Each task a triplet: (execution time, period,
deadline)
• Usually, deadline = period
• CanInitiation
be initiated any time
Execution time
during the period
Deadline

Time

Period
 Linux for Real Time Applications
• Scheduling
– Priority Driven Approach
• Optimize average case response time
– Interactive Processes Given Highest Priority
• Aim to reduce response times of processes
– Real Time Processes
• Processes with high priority
• No notion of deadlines
• Resource Allocation
– No support for handling priority inversion
 Interrupt Handling in Linux
• Interrupts are disabled in ISR/critical sections
of the kernel
• No worst case bound on interrupt latency
avaliable
– eg: Disk Drivers may disable interrupt for few
hundred milliseconds
• Not suitable for Real Time Applications
– Interrupts may be missed
 Other Problems with Linux
• Processes are non preemtible in Kernel Mode
– System calls like fork take a lot of time
– High priority thread might wait for a low priority
thread to complete it’s system call
• Processes are heavy weight
– Context switch takes several hundred
microseconds
 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
 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
 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