real time operating systems n.
Skip this Video
Download Presentation
Real-Time Operating Systems

Loading in 2 Seconds...

play fullscreen
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

Download Now 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.