Real Time Operating Systems

1
Real Time Operating Systems

• Alexandru Andrei
• Embedded Systems Lab.
• Computer and Information Science Dept., Linköping
  University
• alean_at_ida.liu.se

2
The Question - RealTime Nachos

• QNX
• (RealTime)Solaris, (RealTime) NT
• RealTime Java, RealTime Linux

?
Why not RealTime Nachos ? Why not a RT Linux?
3
App Specific RTOS ?

• Build a RTOS from scratch (QNX)
• Better design
• Use an existing OS and add RT functionality
  (Solaris, RT Linux)
• Can use already existing tools (compilers)
• Easy to operate
• But...?

4
RTOS Training Environment?

• Use a special purpose RTOS with its development
  tools (e.g., QNX)
• Same env. as in actual development stage
• Use an existing OS with added RT functionality
• Affordable training equipment (ordinary systems?)
• Use a simulator (e.g., RT-Natchos)
• Runs on all platforms (potentially)
• But....??

5
Focus

• Previous two lectures have shown a few real
  RTOSes
• Can we add real-time support to an operating
  system?
• To a real Linux system?
• To a simulated system as Nachos?

6
Focus

• Things that matter.
• Dispatch time
• Interrupt handling (NT example)
• Scheduling and priority handling(example NT and
  Solaris)
• Memory management
• Program (library) loading
• . and more

7
Recall Dispatch Time
8
Example NT Interrupts
Turn off lower level interrupts...
...perform minimal preparations...
...initiate aDeferred Procedure Call
9
RT NT ? Nope

• NT does not prioritize device interrupts in any
  controllable way and user-level
• applications execute only after device drivers
• The system's devices and drivers (not NT)
  ultimately determine the worst-case delay
• NT cannot deterministically forecast maximum
  delays

10
Example Solaris Priority Classes
11
Rules for Solaris Real-Time Apps

• Runs in the RT scheduling class
• Locks down all the memory in its process address
  space
• Is from a statically-linked program or from a
  program in which all dynamic binding is completed
  early
• Acquires the processor within the guaranteed
  dispatch latency period of becoming runnable
• Continues to run for as long as it remains the
  highest priority runnable process

12
Example NT priority classes
13
Memory Management
Memory locking
(SUN, NT )
to guarantee continuous memory residence to
reduce latency and to prevent paging and
swapping.

• lock specified portions of its virtual address
  space into physical memory
• locked pages are exempt from paging until they
  are unlocked or the process exits
• its applications responsibility to lock a page
  (or all) using a system call

14
Shared Libraries

• Save memory space (dynamic binding)
• but introduces nondeterminism at execution time
• Solution (Solaris) early binding
• dynamic linking to be bound before the program
  begins execution

15
Real-Time Nachos

• Right now - there is no such thing...
• No real-time support built in
• Even the notion of time is fuzzy(how to simulate
  time? In Nachos today? In a RT simulator...?)

16
Nachos Clock Today

• The clock ticks
• When the interrupts are restored (reenabled)
• When the simulator executes one instruction
  (ticksticks1)
• When the ready list is empty tickstickstime_till
  _list_is_not_empty

17
Hmm ...

• What happens when the interrupts are off?
• How much time does it take to execute one
  instruction?
• Other Hot spots
• Scheduler
• Memory management
• Interrupts
• Synchronization
• ...

18
The Project - Scenario

• The Big Corporation is building safety critical
  Real Time systems.......but in order to reduce
  costs
• Can we train RT-programmers in a simulated
  environment based on Nachos?
• Can we use some RT-Linux in real
  projects?(instead of, e.g., QNX?)

19
The Project - Scenario

• Request to all research divisionsInvestigate
  and report!
• Two tracks
• Simulated environment based on Nachos
• Compare two RT-Linuxes for usage in real projects
• Conclude with an open hearing of selected reports
  where other authors acts as opponents
• See also http//www.ida.liu.se/TDDB72/rtproj for
  CFP and details!

20
The Project In parctice

• Pick one of the following two subjects
• Implementing (simulated) real-time on top of
  NachosPossible? Not possible? Good/bad stuff?
  Meaningful?Show what can be done (speculate!)
• Perform a comparison of two alternative
  RT-Linuxes
• Perform literature research and write a technical
  paper (4-6 pages, 5000-6000 words)
• Describe the issues important in a RTOS and how
  they are handled in your system

21
The Project In parctice

• Teams of 2 students
• Decide on topic RT-Nachos or RT-Linux
• RT-Linux teams Select two RT-Linuxes to compare
• Register (sign-up) your topic, and for RT-Linux
  teams, what Linuxes, by sending an email to
  petlo_at_ida.liu.se containing
• the words TDDB72 and RTPROJ in the subject
• name and email of you and your partner in the
  group
• your selected topic (when applicable what
  RT-Linuxes)

22
The Project In parctice

• All reports will be read and commented,(at least
  to some extent)
• Too sloppy, erroneous or technically thin reports
  will be returned for improvement at most once!
• Presentation We will place you in groups of 2-3
  teams with the same topic
• One team will present their work (10min)
• The other team will oppose, comment, and/or
  advocate for their own ideas... (5min)
• And the audience is also invited to ask questions
  and comment...

23
The Project In practice

• Presentation (cont)
• 3 presentations / 45min
• 3 groups active at each presentation
• 2 students 3 groups 3 presentations
  2h-lessons 36 students/lesson
• All 80 groups covered in 5 lessons
• Each student only participate in one 2h-lesson!

24
The Project In practice

• Deadlines
• Sign up v46 (before Monday 17/11 at 13.00)
• Deadline for submissions v48 (Friday 28/11)
• Response at end of v49
• Presentation v50 (detailed schedule later)
• Review Board All staff in this course...
• See names, phones and rooms on the web!

25
Reading Material

• Interval response components in the Solaris
  Operating Environment (Solaris RealTime, SUN
  tech. paper)
• Windows NT as Real-Time OS? (Martin Timmerman)
• Nachos lab compendium
• RT Mach
• Real-Time Systems (Jane Liu) (book)
• Software Engineering for Real-Time Systems(Jim
  Cooling) (book)
• www.ida.liu.se/TDDB72/reading for more
  material!

26

• Good luck !

27
Embedded Systems
General purpose systems
Embedded systems
28
Real-Time System Definition

• "A realtime system is one in which the
  correctness of the computations not only depends
  upon the logical correctness of the computation
  but also upon the time at which the result is
  produced. If the timing constraints of the system
  are not met, system failure is said to have
  occurred."

29
Real-Time System

• A Real-Time System responds in a timely
  predictable way to unpredictable external stimuli
  arrivals.
• Meet deadlines
• Simultaneity

30
RTOS Requirements

• The OS must support fixed-priority preemptive
  scheduling for tasks (both threads and
  processes).
• The OS must provide priority inheritance or
  priority-ceiling emulation for synchronization
  primitives.
• The OS kernel must be preemptible.

31
RTOS Requirements (contd)

• Interrupts must have a fixed upper bound on
  latency.
• nested interrupt support is required.
• Operating-system services must execute at a
  priority determined by the client of the service.
• All services on which it is dependent must
  inherit that priority.
• Priority inversion avoidance must be applied to
  all shared resources used by the service.

32
GPOS vs. RTOS
Predictability
vs.
Fairness
33
Nachos Synchronization

• void SemaphoreP()
• IntStatus oldLevel interrupt-gtSetLevel(IntOf
  f)
• while (value 0)
• queue-gtAppend((void
  )currentThread)
• currentThread-gtSleep()
• value--
• (void) interrupt-gtSetLevel(oldLevel)
  // re-enable interrupts

34
NT Interrupt Handling

• The CPU receives the interrup
• KiInterruptDispatch, raises the CPU's IRQL,
• calls the appropriate ISR
• obtains a spinlock specific to the interrupt and
  holds
• it while the ISR is running.
• lowers the IRQL to its previous value upon
  finishing

35
ISR (Interrupt Service Routine)

• One of NT's goals is to minimize time spent at
  high IRQLs, so NT postpones most interrupt
  servicing until the IRQL decreases.
• In NT, an ISR reads a minimal amount of
  information from the device and acknowledges the
  device

36
Deferred Procedure Call (DPC)

• ISRs request a DPC to inform the I/O Manager that
  they have work to do at a lower IRQL.
• A DPC is another function in the driver that the
  I/O Manager will call after the ISR finishes
• The DPC performs most of the interaction with the
  driver's device (time consuming).