Real time operating systems
1 / 53

Real-Time Operating Systems - PowerPoint PPT Presentation

  • Uploaded on

Real-Time Operating Systems. Raquel S. Whittlesey-Harris. Contents. What is a real-time OS? OS Structures OS Basics RTOS Basics Basic Facilities Interrupts Memory Development Methodologies Summary References. What is a Real-time OS?. A RTOS (Real-Time Operating System)

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Real-Time Operating Systems' - nissim-johnston

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Real time operating systems

Real-Time Operating Systems

Raquel S. Whittlesey-Harris


  • What is a real-time OS?

  • OS Structures

  • OS Basics

  • RTOS Basics

  • Basic Facilities

  • Interrupts

  • Memory

  • Development Methodologies

  • Summary

  • References

What is a real time os
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

Real time os
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

Type of real time systems
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

Types of real time systems
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

Os structures
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

Os structures2
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

Os structures5
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

Os structures6
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 application’s to server’s memory space

Os basics
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

Os basics1
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

Os basics2
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

Rtos basics1
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

Rtos basics2
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.)

Rtos basics4
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

Rtos basics5
RTOS Basics

Max number of threads, tasks or processes

  • Definition space part of system

    • A system parameter

  • Definition space part of task

    • Available memory

Basic facilities
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

Basic facilities1
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

Basic facilities4
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

Basic facilities5
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

  • Basic facilities6
    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

    Basic facilities7
    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


    • 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


    • RTOSs vary in model of interrupt handling to task run


    • 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


    • 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


    • 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


    • 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


    • 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


    • 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)


    • 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

    Development methodology
    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

    Development methodology1
    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)

    Development methodology2
    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

  • Development methodology3
    Development Methodology

    • Resource and hardware shared

      • May prevents RTOS from predictable behavior

      • May prevent GPOS from housekeeping duties

      • Multiprocessor environment should improve performance


    • 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


    • “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.