Real-Time Kernels and Operating Systems

Operating System:

Software that coordinates multiple tasks in processor, including peripheral interfacing

Types of task activities:data exchange / sharingsynchronizationschedulingresource sharing

Real-time OS (RTOS): one or more tasks must execute within specified time constraints

fig_11_00

Example: tasks in meal preparation cannot all be completed in a strict sequence

Single process/task: required resources:

Process stackMemory address spaceRegisters (in CPU)PC I/O ports and network connectionsFile descriptors…

Process state: PC value, register contents, etc. at a given time

Which must be shared with other processes?How can this sharing be managed efficiently?

fig_11_01

In embedded systems we can think of the CPU as a resource for the current task: CPU is a shared resource

Multitasking: more than one task needs to execute, in a seamless manner

CPU, other resources must be shared

fig_11_02

Multiple processes, typically running concurrentlyQ: what are some typical processes?

fig_11_03

Tasks switch from “running” to “ready/waiting” and back according to a scheduleQ: what should be length of turn? Who gets priority?

Common sharing strategies:

Multiprogramming: task runs until it needs to wait on an external event (e.g., I/O)

Real-time: certain tasks have deadlines that must be met

Time-sharing: each process gets a time slice; processes are preempted when time slice is up, must wait for next turn

fig_11_04

Task context: what is the state of task—e.g., register contents; when tasks are swapped, contexts must also be swapped and task that is not running must have its information saved

Task statesIn simple system

Thread: smallest set of resources a task needs (PC and stack, e.g.—if not running, must have copy of register contents)

Terminology:

Process= “heavyweight thread”

Smallest set of resources = “lightweight thread”

fig_11_05

Single-thread design: one process

fig_11_05

Multiple threads

fig_11_07

Process privilege levels affect operations it can carry out without assistance from other processes:

Child process: shares codespace, has own data space, data,status, stack

Multiple threads: each has itsown stack, status information

Process: separate addressspace

Reentrant code: child process can use same code, needs different local variables

fig_11_07

Foreground tasks: initiated by interrupt or real-time constraint—higher priority levels

Background tasks—not interrupt-driven—lower priority levels—e.g. monitoring tasks, intensive processing tasks

fig_11_07

Operating system:

Kernel—portion of OS providing basic functions:

Scheduler: Schedule tasks for execution

Dispatcher: Choose (“dispatch”) task to run

Intertask and interprocess communication: Ensure tasks can communicate as needed and are synchronized as needed

fig_11_07

Necessary services to carry out these jobs:

Manage processes and tasks, deal with “deadlocks”

Manage memory, I/O system, file system

RTOS: make sure deadlines are met; make sure behavior is DETERMINISTIC (not necessarily “fast”)

Hard real-time; system delays are known or at least bounded

Soft real-time: critical tasks have priority and are allowed to run to completion

fig_11_08

OS architecture:Virtual machine model:Very modular but may not match real machine

fig_11_09

OS architecture:Typical architecture

fig_11_10

TCB: task control block—required for each task or process to be executed

Task states:ReadyExecutedormant

fig_11_11

Code for a task control block:

fig_11_12

Example: simple system, 3 asynchronous tasks sharing a common data buffer--get data--perform computation--display dataTask queue implemented as arrayWill run “forever”No preemption (each task runs to completion)

fig_11_13b

Kernel example

fig_11_14a

Same tasks—using task control blocks

fig_11_12

Some problems with this system;

Can get stuck in one taskEx: user does not input data so we are stuck in the “get” taskSolution: use interrupts, break task into prompt and task to get data when it is available

Shared data bufferIn this example, only 1 task is active at a time so there is no conflict

fig_11_15

Typical function to set address to correct interrupt:

fig_11_17a

Modification to allow interruptsPart 1 of 3):

fig_11_17b

Modification to allow interruptsPart 2 of 3):

fig_11_17c

Modification to allow interruptsPart 3 of 3):

fig_11_18

Registers:Can organize as multiple contexts

fig_11_19

Registers:Can organize as overlapping contexts—saves overhead on variable passing

fig_11_20

Stack: typical stack frame organization

fig_11_21

Runtime stack: multiple task information must be stored