RealTime Operating Systems

1
Real-Time Operating Systems

• Raquel S. Whittlesey-Harris

2
Contents

• What is a real-time OS?
• OS Structures
• OS Basics
• RTOS Basics
• Basic Facilities
• Interrupts
• Memory
• Development Methodologies
• Summary
• References

3
What is a Real-time OS?

• A RTOS (Real-Time Operating System)
• Is an Operating Systems with the necessary
  features to support a Real-Time System
• What is a Real-Time System?
• A system where correctness depends not only on
  the correctness of the logical result of the
  computation, but also on the result delivery time
• A system that responds in a timely, predictable
  way to unpredictable external stimuli arrivals

4
Real-Time OS

• What a Real-Time System is NOT
• A Transactional system
• Average of transactions per second
• A Good RTOS is one that has a bounded
  (predictable) behavior under all system load
  scenarios
• Just a building Block
• Does not guarantee system correctness

5
Type of Real-Time Systems

• Hard Real-Time
• Missing a deadline has catastrophic results for
  the system
• Firm Real-Time
• Missing a deadline causes an unacceptable quality
  reduction

6
Types of Real-Time Systems

• Soft Real-Time
• Reduction in system quality is acceptable
• Deadlines may be missed and can be recovered from
• Non Real-Time
• No deadlines have to be met

7
OS Structures

• Monolithic OS
• OS is composed of one piece of code divided into
  different modules
• Problem Difficult to debug
• Changes may impact other modules substantially
• Corrections may cause other bugs to show up
• Spaghetti Software - many interconnections
  between modules

8
OS Structures
9
OS Structures

• Layered OS
• Better approach than the Monolithic
• However still chaotic
• Example OSI Layer
• Problem OS technology not as orthogonal with its
  layers
• You can skip layers in OS model

10
OS Structures
11
OS Structures
12
OS Structures

• Client-Server OS
• Newer Model
• Limit Basics of OS to a minimum (scheduler and
  synchronization primitive)
• Other functionality is implemented as system
  threads or tasks
• Applications are clients requesting services via
  system calls to these server tasks

13
OS Structures

• Benefits
• Easier to Debug and scale
• Distribution over multiple processors is simpler
• Possible to dynamically load and Unload modules
• Problems
• Overhead is high due to memory protection
• Server processes must be protected
• Increased time to switch from applications to
  servers memory space

14
OS Structures
15
OS Basics

• An OS is a system program that provides an
  interface between application programs and the
  computer system (hardware)
• Primary Functions
• Provide a system that is convenient to use
• Organize efficient and correct us of system
  resources

16
OS Basics

• Four main tasks of OS
• Process Management
• Process creation
• Process loading
• Process execution control
• Interaction of the process with signal events
• Process monitoring
• CPU allocation
• Process termination

17
OS Basics

• Interprocess Communication
• Synchronization and coordination
• Deadlock and Livelock detection
• Process Protection
• Data Exchange Mechanisms
• Memory Management
• Services for file creation, deletion, reposition
  and protection
• Input/Output Management
• Handles requests and release subroutines for a
  variety of peripherals and read, write and
  reposition programs

18
RTOS Basics
19
RTOS Basics

• Central Purpose of a RTOS
• Scheduling of the CPU
• Applications are structured as a set of processes
• Processes consist of
• Code
• State
• Register values
• Memory values

20
RTOS Basics

• At least 3 states are needed to allow the CPU to
  schedule
• Ready waiting to run (in ready list)
• Running process (thread or task) is utilizing
  the processor to execute instructions
• Blocked waiting for resources (I/O, memory,
  critical section, etc.)

21
RTOS Basics
22
RTOS Basics

• Threads are lightweight processes
• Inherits only part of process
• Belongs to the same environment as other threads
  making up the process
• May be stopped, started and resumed
• Tasks are a set of processes with data
  dependencies between them

23
RTOS Basics

• Max number of threads, tasks or processes
• Definition space part of system
• A system parameter
• Definition space part of task
• Available memory

24
Basic Facilities

• Multitasking is required to develop a good
  Real-time application
• Pseudo parallelism - to handle multiple
  external events occurring simultaneously
• Rate Monotonic Scheduling (RMS) - is utilized to
  compute in advance the processor power required
  to handle the simultaneous events

25
Basic Facilities

• Algorithms (scheduling mechanism) are needed to
  decide which task or thread will run at a given
  time
• Function is to switch from one task, thread, or
  process to another (Context Switching)
• Overhead should be completed as quickly as
  possible
• Dispatch time should be independent of the number
  of threads in the ready list
• Ready list should be organized each time an
  element is added to the list

26
Basic Facilities
27
Basic Facilities
28
Basic Facilities

• Types of Scheduling Policies
• Deadline driven ideal but not available
• Cooperative relies on current process to give
  up the CPU
• Pre-emptive priority scheduling higher priority
  tasks may interrupt lower priority tasks
• Static priorities are set before the system
  begins execution
• Dynamic priorities can be redefined at run time

29
Basic Facilities

• Many priorities levels in a RTOS is better to
  have for complex systems with many threads
• At least 128 levels
• A different priority level can be set for each
  task or thread
• Round Robin give each task an equal share of
  the processor
• Implemented when all tasks or threads have the
  same priority level
• May be implemented within a priority range

30
Basic Facilities

• Synchronization and exclusion objects
• Required so that threads and tasks can execute
  critical code and to guarantee access in a
  particular order
• Semaphores synchronization and exclusion
• Mutexes - exclusion
• Conditional variables exclusion based on a
  condition
• Event flags synchronization of multiple events
• Signals asynchronous event processing and
  exception handling

31
Basic Facilities

• Communications
• Data may be exchanged between threads and tasks
  via
• Queues mulitple messages
• Mailboxes single messages
• Most RTOSs pass data by pointer
• Copying data structure would be less efficient
• Pointer must be valid while receiving thread or
  task makes use of it

32
Interrupts

• RT systems respond to external events
• External events are translated by the hardware
  and interrupts are introduced to the system
• Interrupt Service Routines (ISRs) handle system
  interrupts
• May be stand alone or part of a device driver
• RTOSs should allow lower level ISRs to be
  preempted by higher lever ISRs
• ISRs must be completed as quickly as possible

33
Interrupts

• RTOSs vary in model of interrupt handling to task
  run

34
Interrupts

• Interrupt Dispatch Time
• time the hardware needs to bring the interrupt to
  the processor
• Interrupt Routine
• ISR execution time
• Other Interrupt
• Time needed for managing each simultaneous
  pending interrupt
• Pre-emption
• Time needed to execute critical code during which
  no pre-emption may happen

35
Interrupts

• Scheduling
• Time needed to make the decision on which thread
  to run
• Context Switch
• Time to switch from one context to another
• Return from System Call
• Extra time needed when the interrupt occurred
  while a system call was being executed

36
Interrupts

• System calls cause software interrupts (SWIs)
• Portable Operating System Interface (POSIX)
  defines the syntax of many of the library calls
  that execute the SWIs
• Attempts to make applications portable

37
Memory

• RAM
• Holds changing parts of the task control block,
  stack, heap
• Minimum number of RAM required varies by vendor
• Maximum addressable space will vary depending on
  the memory model
• E.g., backward compatibility (x86) will limit to
  64K segments

38
Memory

• Predictability
• The need to make memory access predictable
  (bound) prohibits the use of virtual memory
• Systems should have locking capability prevent
  swapping by locking the process into main memory
• Paging map should be part of the process context
  (loaded onto the processor or MMU)
• Larger page sizes may be required to fit it all
  in 2k

39
Memory

• Segments may be used to avoid 2k limit
• Non-variable segment sizes may be used
• Prohibit deallocation to prevent garbage
  collection (prevents displaced tasks from running
  which leads to unpredictability)

40
Memory

• Static memory allocation
• All memory allocated to each process at system
  startup
• Expensive
• Desirable solution for Hard-RT systems
• Dynamic memory allocation
• Memory requests are made at runtime
• Should know what to do upon allocation failure
• Some RTOSs support a timeout function

41
Development Methodology

• RTOS differ in development configurations
  supported
• Host machine on which the application is
  developed
• Target machine on which the application is to
  execute

42
Development Methodology

• Host Target
• Host and target are on the same machine
• RTOS has its own development environment
  (compiler, debugger, and perhaps IDE)
• Usually of lesser quality
• Host ? Target
• Two different machines linked together (serial,
  LAN, bus, etc.)
• Host generally machine with a proven General
  Purpose Operating System (GPOS)

43
Development Methodology

• Better development environment
• Debugger is on host while application is executed
  on target
• Debug agents are stored on target to communicate
  with host
• Simulator should be provided to execute prototype
  application on the host
• Hybrid
• Host and target on same machine but on different
  OSs
• Communicate via shared memory

44
Development Methodology

• Resource and hardware shared
• May prevents RTOS from predictable behavior
• May prevent GPOS from housekeeping duties
• Multiprocessor environment should improve
  performance

45
Summary

• A RTOS should be predictable regardless of the
  system load and size of queues/lists
• RTOS should always support pre-emptive priority
  scheduling
• The memory model utilized is very important to
  the performance and predictability of your RT
  system

46
Summary
47
Summary
48
Summary
49
Summary
50
Summary
51
Summary
52
Summary
53
References

• What Makes A Good RTOS, RTOS Evaluation
  Program, Real-Time Magazine, Version 2.0, 28
  February 2000.
• Y. Li, M. Potkonjak and W. Wolf, Real-Time
  Operating Systems for Embedded Computing,
  Department of Electrical Engineering, Princeton
  University, Department of Computer Science, UCLA,
  IEEE 1997.
• F. Kolnick, QNX 4 Real-time Operating System
  Programming with Messages in a Distributed
  Environment, Basic Computer Systems Inc., 1998.
• VxWorks Guide, WindRiver Systems.