RTS: Why use a RTOS?

™ For many years small embedded RTS have

not used a RTOS
™ Profound (but not immediately apparent)
effects of using an RTOS - major impact on
software:
– dependability
– productivity
– maintainability
™ Significantly simplifies development of
medium/large RTS
Basic OS features required by RTS
™ Must support multiple task structure of RT
programs - hence
– scheduling of multiple tasks
– concurrency of multiple tasks
– (memory management between tasks)

™ Also support programming with minimal

hardware knowledge
 General Purpose Operating
Systems
™ Make the hardware usable
™ Convenience and Efficiency

™ Resource Management

™ Multitasking

™ Large Real Time Systems benefit from an

OS - but have particular requirements - so
there are special purpose RTOS
 Implementing
MultiTasking/TimeSharing
™ Issues
– Manage access of jobs to the CPU
• Scheduling
• When to switch jobs
– Prevent jobs from interfering with each other
• Resource ownership (memory, I/O)
• Stored in a separate area of memory
• Access to I/O devices
™ Concept of a Process enables a systematic
approach
 Process Dispatching
Two-State Process Model
Dispatch

Enter Not Exit

Running
Running

Pause
(a) State transition diagram

Queue
Enter Dispatch Exit
Processor

Pause

(a) Queuing diagram

 More Process States
™ Running
™ Ready
– ready to execute
™ Blocked
– waiting for I/O
™ New/Exit
™ Dispatcher cannot just select the process
that has been in the queue the longest
because it may be blocked
 Five-State Process Model
Dispatch Release
Admit
New Ready Running Exit

Time-out

Event Event
Occurs Wait

Blocked
 Process Resource Management
™ Memory
™ I/O

™ Tables are constructed for each entity the

operating system manages
 Memory Tables
™ Allocation of memory to processes
– Both primary and secondary memory
™ Protection attributes for access to shared
memory regions
™ Information necessary to manage virtual
memory
 I/O Tables
™ I/O device is available or assigned
™ Status of I/O operation

™ Location in main memory being used as the

source or destination of the I/O transfer
 Process Control Information
™ Additional information needed by the operating
system to control and coordinate the various active
processes
– scheduling and state information
– data structuring
– interprocess communication
– process privileges
– memory management
– resource ownership and utilization
 Context Switch
™ Save the full process state when the OS
switches processes
– On the stack
– Disruptive – heavy context switch overhead
™ When to switch
– Clock (scheduler time slice) interrupt
– I/O interrupt
– ISR (part of kernel) manages the switch
 CPU State Information
™ Contents of processor registers
– User-visible registers
– Control and status registers
– Stack pointers
™ Program status word (PSW)
– Contains status information
– Example: the EFLAGS register on Pentium
machines
 Scheduling
™ Algorithm to chose a replacement process
when there is a switch
™ Up to the scheduler – various possibilities
– General Purpose OS
• Round Robin, FIFO
– RTOS have special requirements on schedulers
 Scheduling in RTOS
™ RTOS don’t necessarily have to be fast, but:
– Flexible scheduling policy
– Able to quickly schedule new jobs

™ General purpose OS methods inadequate

™ RTOS typically have a preemptive,
priority driven scheduler
What’s wrong with RR, priority FIFO?
Preemptive, Priority Driven
 RT Scheduler
™ Preemptive
– When does scheduler get called?
• Process completion
• Process release (an interrupt, either clock or device)
• Process blocked for I/O
• No (RR-like) time slicing
• “Event driven” scheduling
™ Priority Driven
– How does it decide who gets the CPU?
• Highest priority - not FIFO
• Flexibility lies in how priorities are assigned
 Note: Preempting the Kernel
™ Many OS (including most UNIX) allow
user processes to be preempted, but not
kernel level processes such as system calls
™ This is to protect kernel data that is in the
middle of being accessed
™ In this case, response can be slow

™ Some OS use synchronization mechanisms

to protect kernel data so the kernel itself is
preemptible (eg Solaris 2)
 Greedy Scheduling
™ Locally optimal, if jobs have been released,
they are allowed to run immediately
™ Not always best
– will see later with multiprocessors
– compromises response for soft aperiodic jobs in
background of periodic jobs
 Scheduling Policies

all Policies

No Priority Priority Based

Non Preemptive Preemptive Non Preemptive Preemptive

FIFO Cooperative RR SJF Off-line On-line

RMS Heuristic EDF

 Choosing Priorities
™ Off-line (static)
– Periodic jobs
• Fixed Priorities (Most practical schemes)
• Can use a sophisticated algorithm to fix priorities and
guarantee schedulability
– Aperiodic soft jobs in background
• slack stealing
™ On-line (dynamic)
• Attempt to schedule new jobs as they arrive
• rare in practice - schedulability guarantee?
 Static/Dynamic Scheduling
™ Note - can mean different things:
™ Off-line vs On-line
– compile-time vs run-time
™ Fixed priority vs dynamic priorities
– do the priorities themselves change?
™ For multi CPU
– does a particular job always go to the same
processor
 Fixed Priority Schemes
™ Choose priorities (eg RM) and use a
preemptive priority driven RTOS scheduler
™ Flexible and maintainable

™ Used to worry whether deadlines would be

met – now rigorous theorems to test this
™ Most systems are like this - possibly with
additional soft non-periodic jobs stealing
slack
 Heuristic Choice
™ Algorithms to decide priorities on the basis
of deadline, period, execution time
™ What about
– dependent jobs
– critical importance of job
™ May have to adjust priorities to take account
of these issues
 Aperiodic/Sporadic jobs
™ How to fit these into a scheme where most
jobs are periodic with fixed priorities?
™ Use idle times - low priority
– hard (sporadic): meet deadlines?
– soft (aperiodic): good response time?
™ Slack stealing for soft aperiodic jobs
™ Base priority level often use RR
 Dynamic Scheduling Policies
™ Make on-line decisions based on actual
system state
™ Deadline scheduling - tell the scheduler
what the deadlines are rather than work out
priorities
™ In principle good - but not sufficiently
reliable in practice
™ Earliest Deadline First Algorithm (see later)
 Priority Assignment Algorithms
™ Assume independent periodic processes
™ Often deadline=period

™ Determine the priority of each task

statically

– Rate Monotonic (RM)

– Deadline Monotonic (DM)
 Rate Monotonic (RM)
™ Assign priorities according to period
– Shortest period – highest priority
– Highest rate (rate = 1/period) – highest priority
™ Examples, notes pg 8
 Schedulability tests
™ Utilisation tests
Processor utilisation U = C/T

™ Response analysis (for RM)

– Determine worst case response
– Compare with deadlines
 Utilisation Test for RM
™ Total Utilisation (sum all jobs)
™ Schedulable provided:
Number of Maximum
Ci
U = ∑ ≤ N ⎜ 2 N − 1⎞⎟
⎛ 1 Processes Utilisation
1 1.0

Ti ⎝ ⎠ 2 0.828

3 0.779

™ Sufficient 4

5
0.756

0.743

™ NOT necessary 6 0.734

∞ 0.693

™ Example on handout
 Response Analysis for RM
™ Highest priority process
R1 = C1
™ Next highest priority process could get
preempted by highest ⎡ R ⎤ times
2
⎢ ⎥
⎢ T1 ⎥

™ Ceiling function
⎡ 1 ⎤ ⎡ 15 ⎤
⎢⎢ 2 ⎥⎥ = 1, ⎢⎢ 7 ⎥⎥ = 3
 Response Analysis cont I
™ Second highest priority process could be
delayed (at worst) by:
⎡ R2 ⎤
R2 = C 2 + ⎢ ⎥C1
⎢ T1 ⎥
 Response Analysis cont II
™ General priority process i, could get
preempted by any higher priority process j
™ Worst case response

⎡ Ri ⎤
Ri = C i + ∑ ⎢ ⎥C j
j ⎢T j ⎥

™ See examples for how to calculate R using

this equation
 Deadline Monotonic (DM)
™ Assign fixed priorities according to relative
deadline
– Shortest relative deadline – highest priority
™ Outperforms RM if arbitrary relative
deadlines
– treat aperiodic tasks using periodic polling
 Priority Inversion
™ If the processes are not independent
– Sharing a resource
™ A high priority process may be blocked by a
lower priority process that holds the lock to
some shared resource
™ Performance degradation - appears that
priorities are inverted
™ Eg Mars Pathfinder
 Solutions to Priority Inversion
™ Temporary increase in task priority
™ Priority Inheritance
– temporary priority depends on priorities of
other running tasks
™ Priority Ceiling Protocol
– temporary priority depends on a priority
associated with the locked resource
 Priority Inheritance
™ Common solution is priority inheritance,
the process holding the lock is temporarily
given the same priority as the high priority
process
™ Overhead incurred since system must
– keep track of all task suspensions
– keep track of all locked resources
– dynamically change (and reset) priorities
 Dynamic Scheduling
™ Accept all new jobs (with priority
determined by importance) and abort jobs
that fail to meet deadlines
™ Do a new run-time schedulability test every
time a new job arrives. Only process the job
if deadlines will be met. Overhead of test!
 Earliest Deadline First (EDF)
™ Job with the closest absolute deadline gets
scheduled first
™ Can implement directly in scheduler or
translate deadlines to priorities
™ In this case the priorities are dynamic, but
typically consumes too much overhead
 Memory Management
™ Prevent one process from writing/reading
memory associated with another process
™ Check that all addresses issued by the
process fall within bounds
™ Supported by hardware for speed

™ MS-DOS, Macintosh OS do not use this

facility and one erroneous program can
affect others or the OS itself
 Preventing Crashes
™ If a user mode process attempts to execute a
privileged instruction or to access memory
outside its address space
™ Detected by the hardware which sends a
software interrupt (trap) to alert the OS
™ The OS will terminate the program and put
up a message
 System Calls
™ Instructions for I/O are privileged and can
only be executed by the OS
™ For an ordinary process (in user mode) to
perform I/O, it must request the OS to work
on its behalf
™ A system call is treated as a software
interrupt (trap)
 System call trap
™ Software interrupt
– Control passes through interrupt vector to an ISR
– The ISR is part of the OS - and kernel mode is set
– Parameters indicate exactly what the user process
is requesting
– Executed or passed on to some other part of the OS
by the ISR
– Return to user mode and pass control to user
process
 Threads
™ Distinguish between the two aspects of
processes
– Resource management
– Execution
™ Several threads may execute within one
process – sharing its resources
™ Lightweight context switch
 Processes/Threads
™ Resource ownership - process is allocated a
virtual address space to hold the process image
™ Dispatched - execution may be interleaved with
other processes
™ These two characteristics are treated
independently by the operating system
– Dispatching is referred to as a thread
– Resource of ownership is referred to as a process or
task
 Multithreading
™ Operating system supports multiple threads
of execution within a single process
™ MS-DOS only supports a single thread

™ Traditional UNIX supports multiple user

processes but only supports one thread per
process
™ Windows NT supports multiple threads
 Threads and Processes

one process one process

one thread multiple threads

multiple processes multiple processes

one thread per process multiple threads per process
 A Thread
™ Has an execution state (running, ready, etc.)
™ Saves thread context when not running

™ Has an execution stack

™ Has some per-thread static storage for local

variables
™ Has access to the memory and resources of
its process
– all threads of a process share these resources
Single Threaded and Multithreaded
Process Models
Single-Threaded Multithreaded
Process Model Process Model
Thread Thread Thread
Thread Thread Thread
Process User Control Control Control
Control Stack Block Block Block
Block

Process User User User

User Kernel
Control Stack Stack Stack
Address Stack
Block
Space

User Kernel Kernel Kernel

Address Stack Stack Stack
Space
 Benefits of Threads
™ Takes less time to create a new thread than a
process
™ Less time to terminate a thread than a process

™ Less time to switch between two threads

within the same process
™ Since threads within the same process share
memory and files, they can communicate with
each other without invoking the kernel
 User-Level Threads
™ All thread management is done by the
application through a library
™ The kernel is not aware of the existence of
threads
™ Thread switching does not require kernel
mode privileges
™ Scheduling is application specific

™ Eg Pthreads package in UNIX

 Kernel-Level Threads
™ Kernel maintains context information for
the process and the threads
™ Switching between threads requires
intervention from the kernel
™ Windows NT and OS/2 are examples of this
approach
 User vs Kernel Threads
™ User level
– fast (no kernel involvement)
– unable to use multiple CPU’s
– problem of blocking system calls
™ Kernel level
– slightly slower
– resolve problems of user threads
 Real-Time and OS
™ RTS often want an OS
– For convenience
– Multitasking and threads
– Cheaper to develop large RT systems
™ But - don’t want to loose ability to meet
deadlines
 RTOS requirements
™ Determinism
™ Responsiveness (quoted by vendors)
– Fast process/thread switch
– Fast interrupt response
™ User control over OS policies
– Mainly scheduling, many priority levels
– Memory support (especially embedded)
™ Reliability
 What makes an OS a RTOS?
™ MultiThreaded and preemptible
™ Thread priorities
– (no deadline driven systems exist)
™ Predictable thread synchronization
mechanisms
™ Priority inheritance

™ Known OS behaviour
 RTOS Responsiveness
™ An OS provides a uniform interface to the
hardware - including interrupts
™ When a hardware interrupt occurs, the low-
level interrupt handler is part of the OS
kernel which must then start the ISR
™ On certain occasions this overhead is
excessive and want interrupt to completely
bypass OS (“fast interrupt response”) - eg
exception conditions
 Interrupt response latency
™ Time between kernel receiving interrupt and
start of first instruction of ISR
™ Hardware interrupt latency itself is small

™ Minimum, average and maximum figures

™ Typically less than 1ms (can be 10’s-100’s

ms for general purpose OS)
How quickly does a new task get
serviced?
™ Depends on task priorities
– Task control is handled by scheduler
– On event/interrupt - kernel starts ISR which
places new task in queue and wakes scheduler
– Scheduler may replace running job with new one
™ Process dispatch latency
– Time to respond to an external interrupt and
produce a task reschedule
– Assume new task is higher priority
 RTOS Performance Metrics
™ Interrupt response latency
™ Process dispatch latency

™ Context Switch time

– equal priority tasks
™ Preemption time
– higher priority preempting lower priority
™ Inter-task message latency
™ Semaphore shuffle time
Memory: Typical structure (small RTS)
64kB EPROM chip for code 64kB RAM chip
FFFF 1FFFF
OS code OS RAM

global RAM
task 3 code
A000 1A000
task 3 RAM
task 2 code
8000 18000
task 2 RAM

task 1 code

initialization code task 1 RAM

0 10000
 Memory Management
™ Code from one task can write over the
RAM area of another task (or even OS)
™ Prevent this interference
– Check the addresses - ensure within bounds
– Often supported in hardware (MMU)
– Standard part of process control in general
purpose OS
 Memory Allocation
™ How to choose the address bounds
™ Simple static system
– Programmer or compiler decides
™ Dynamic systems
– Economise on memory chips
– Problems of fragmentation and leakage
– Best to avoid in RTS (never in critical apps.)
– Standard in general purpose OS - paging to disk
and virtual memory - excess overhead for RTS
 Variety of RTOS
™ Embedded systems are very diverse
– small, cost sensitive, automobile
– large, complex, control system
™ Hence no “standard” RTOS
– Size: 1kB to several MB
– Functionality: basic kernel ops only to full
internet compatibility
 Spectrum of RTOS
™ No RTOS: multitasking via interrupts
™ Nanokernel

™ Microkernel

™ General Purpose RTOS

™ (no standard nomenclature, note technical

sense of “microkernel architecture”)
 Multitasking via Interrupts
™ Home grown “tasking” design
™ Tasks written as ISR’s started by interrupts
– interrupt code (before and after)
– subroutine call to application code
– possibly prioritized
™ Initialization
™ Explicit hardware interfacing code
 Nanokernel
™ Real time executive
™ Provides
– task creation
– scheduling and dispatching
– timing and interrupt management
™ Hardware Abstraction Layer (HAL)
– responsibility of programmer
– contains all code to operate board hardware
– provides an abstract interface to application and
kernel
 Microkernel
™ Improvements over Nanokernel
– Increased kernel functionality
• task scheduling and control
• mutual exclusion (semaphores/monitors)
• synchronization and data transfer
• dynamic memory allocation
– Use of a board support package (BSP)
• part of the microkernel package
• board initialization
• device and peripheral interfacing
• interrupt handling operations
 General Purpose RTOS
™ Improvements over microkernel
– Networking facilities
• CAN, Ethernet
– Graphics based user interfaces
– Long term persistent storage
• disk, RAMdisk
™ Generally designed as a microkernel with
various attached modules that communicate
through the kernel. Flexible.
 QNX RTOS
™ QNX microkernel supports
– message passing
– process scheduling
– low-level network communication
– hardware interrupts
™ All other services are provided by standard
processes running in user mode
 Symbian
™ Special RTOS for mobile phones (2.0-3.0G)
™ Developed by industry consortium
™ Compact, supports
– OBEX
– Browsing (WAP stack)
– Messaging (SMS, email)
– Multimedia
– Communications (TCP,IrDA,Bluetooth)
– Mobile Telephony (GSM,CDMA)
– Security
– Software (C++, Java)
 Survey of RTOS
™ LynxOS www.lynx.com Microkernel and plug in
modules. UNIX compatible.
™ pSOSystem www.windriver.com Iridium satellites.
™ VxWorks www.windriver.com Mars Pathfinder
™ QNX www.qnx.com Suitable for multiprocessors
on big (shared memory) machines.
™ VRTX www.mentor.com Certified by the FAA.
™ Symbian www.symbian.com Mobile phones