Real-Time Operating Systems: Concepts, Taxonomy, and Predictability, Exercises of Operating Systems

What is an Operating System (OS)?. ▫ A program that acts as an intermediary between a user of a computer and the computer hardware.

Typology: Exercises

2022/2023

Uploaded on 05/11/2023

ameen
ameen 🇺🇸

4.6

(5)

236 documents

1 / 19

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Real-Time Operating Systems
(Working Draft)
Originally Prepared by Sebastian Fischemeister
Modified by Insup Lee
CIS 541, Spring 2010
Spring ‘10 CIS 541 2
What is an Operating System (OS)?
A program that acts as an intermediary between a
user of a computer and the computer hardware
Operating system goals:
oExecute user programs and make solving user problems
easier.
oMake the computer system convenient to use
Use the computer hardware in an efficient manner
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13

Partial preview of the text

Download Real-Time Operating Systems: Concepts, Taxonomy, and Predictability and more Exercises Operating Systems in PDF only on Docsity!

Real-Time Operating Systems

(Working Draft)

Originally Prepared by Sebastian Fischemeister Modified by Insup Lee CIS 541, Spring 2010

What is an Operating System (OS)?

 A program that acts as an intermediary between a user of a computer and the computer hardware  Operating system goals: o Execute user programs and make solving user problems easier. o Make the computer system convenient to use  Use the computer hardware in an efficient manner

Spring ‘10 CIS 541^3

Computer System Components

  1. Hardware – provides basic computing resources (CPU, memory, I/O devices)
  2. Operating system – controls and coordinates the use of the hardware among the various application programs for the various users
  3. Applications programs – define the ways in which the system resources are used to solve the computing problems of the users (compilers, database systems, video games, business programs)
  4. Users (people, machines, other computers)

Abstract View of System Components

Spring ‘10 CIS 541^7

Taxonomy of RTOSs

 Small, fast, proprietary kernels  RT extensions to commercial timesharing systems  Component-based kernels  Monolithic kernels

Small, Fast, Proprietary Kernels

 They come in two varieties: o Homegrown o Commercial offerings  Usually used for small embedded systems  Typically specialized for one particular application  Typically stripped down and optimized versions: o Fast context switch o Small size, limited functionality o Low interrupt latency o Fixed or variable sized partitions for memory management  PICOS18, pSOS, MicroC, …

Spring ‘10 CIS 541^9

RT Extensions

 A common approach is to extend Unix o Linux: RT-Linux, RTLinuxPro, RTAI, o Posix: RT-Posix o MACH: RT-MACH  Also done for Windows based on virtualization.  Generally slower and less predictable.  Richer environment, more functionality.  These systems use familiar interfaces, even standards.  Problems when converting an OS to an RTOS: o Interface problems (nice and setpriority in Linux) o Timers too coarse o Memory management has no bounded execution time o Intolerable overhead, excessive latency

How to do an RT Extension?

 Compliant kernels o Takes an existing RTOS and make it execute other UNIX binaries (see LynxOS). o Interfaces need to be reprogrammed. o Behavior needs to be correctly reimplemented.

Spring ‘10 CIS 541^13

Component-based Kernels

 The source consists of a number of components that can be selectively included to compose the RTOS.  See OS-Kit, Coyote, PURE, 2k, MMLite, Pebble, Chaos, eCos.  eCos o Hardware Abstraction Layer (HAL) o Real-time kernel  Interrupt handling  Exception handling  Choice of schedulers  Thread support  Rich set of synchronization primitives  Timers, counters and alarms  Choice of memory allocators  Debug and instrumentation support Counters -- Count event occurrences Clocks -- Provide system clocks Alarms -- Run an alarm function Mutexes -- Synchronization primitive Condition Variables -- Synchronization primitive Semaphores -- Synchronization primitiveMail boxes -- Synchronization primitive Event Flags -- Synchronization primitive Spinlocks -- Low-level Synchronization Primitive Scheduler Control -- Control the state of the scheduler Interrupt Handling -- Manage interrupt handlers

Component-based Kernels

 eCos o μITRON 3.0 compatible API o POSIX compatible API o ISO C and math libraries o Serial, ethernet, wallclock and watchdog device drivers o USB slave support o TCP/IP networking stacks o GDB debug support  All components can be added through a configuration file that includes and excludes parts of the source code.

Spring ‘10 CIS 541^15

Research Kernels

 Many researchers built a new kernel for one of these reasons: o Challenge basic assumptions made in timesharing OS o Developing real-time process models o Developing real-time synchronization primitives o Developing solutions facilitating timing analysis o Strong emphasis on predictability o Strong emphasis on fault tolerance o Investigate the object-oriented approach o Real-time multiprocessor support o Investigating QoS

What Typically Differs

Spring ‘10 CIS 541^19

Admission Control

 Admission control is a function that decides if new work entering the system should be admitted or not.  To perform this it requires: o A model of the state of system resources o Knowledge about incoming requests o An algorithm to make the admission decision o Policies for actions to take upon admission and rejection  Statically scheduled systems require no admission control.

Admission Control

 The admission algorithm requires preanalyzed tasks  Shared data  Execution time  Precedence information  Importance level  Deadlines  Positive decision assigns time slices to the task  Negative decision has options: o Run a simpler version of the task o Run on a different machine o Reject the task  Admission algorithms can be complex as they have to consider multiple resources (e.g., networked video streaming).

Spring ‘10 CIS 541^21

Resource Reservation

 Resource reservation is the act of actually assigning resources to a task. o Initially no resource reservation, only allocation as the task runs. o Valuable for hard real-time systems. o Introduces an overhead as resources might be unused  => introduction of resource reclaiming strategies  Closely linked to resource kernels that offer interfaces for resource reservation, donation, and reflection.

Task Declaration

 RTOSs tailored to microprocessors often require a static declaration of tasks.  Advantages are: o Simple check that the system has sufficient resources. o No admission control necessary. o No overhead introduced by the admission test. o No thread spawning problems  => but quite static

Spring ‘10 CIS 541^25

Configurability

 Remove unused functions o May be done via linker automatically  Replace functionality o Motor placement comes in three functions:  Calculated  Lookup table (program memory)  Lookup table (EEPROM)  Conditional compilation o Use #if, #ifdef constructs o Needs configuration editor o Example: Linux make config….

Problem with Configurability

 Per (boolean) configuration option, we obtain two new OS versions.  Embedded systems require extensive testing.  The application must be tested with each configuration separately: o 100 configuration options we get around 2^ o Require hardware setup o Require software setup o Require reporting for automated testing

Spring ‘10 CIS 541^27

Embedded RTOS I/O

 I/O normally only through kernel via a system call. o Expensive but provides control  In an RTOS for embedded systems, tasks are allowed to do I/O operations directly o Direct fast access o Direct task to task communication between chips  Problem: Can cause troubles if tasks interfere  Solution: Programmer must do synchronization too

Embedded RTOS: Interrupts

 Normal OS: Interrupts are kernel only o Must be reliable (dropped disk interrupts…) o Costly: Notification via context switch/syscalls  Embedded OS: tasks can use interrupts o Again: only trusted/tested programs o Speed important o Fast task control possible o But: modularity decreases, as tasks may have to share interrupts correctly

Spring ‘10 CIS 541^39

Static Declarations

 PICOS18 requires you to statically declare o Alarms o Resources o Tasks  Let’s have a look.

Tasks Implementation

 At most 16 events.  The task state is encoded in the following variables: o tsk_X_state_ID  Bits 0-3: task identifier  Bit 4: unused  Bit 5-7: task state o tsk_X_active_prio  Bits 0-3: task priority  Bit 5-7: activation counter o Let’s look at some of the functions in pro_man.c

Spring ‘10 CIS 541^42

Event Management

 StatusType SetEvent (TaskType TaskID, EventMaskType Mask) o Posts an event to another task. Causes a scheduling operation.  StatusType ClearEvent (EventMaskType Mask) o Clears the event, otherwise an infinite loop.  StatusType GetEvent (TaskType TaskID, EventMaskRefType Event) o Receives the event value for a specific task.  StatusType WaitEvent (EventMaskType Mask) o Blocks the current task until the event occurs.

Event Implementation

 At most 16 events.  The event status is encoded in these two variables: o EventMaskType event_X  For each task 16 possible events. o EventMaskType wait_X  Each task can listen for 16 possible events.  Let’s have a look at the code.

Sample Application

Let’s look at the sample application that comes with PICOS18.