S emb t12-os

RMR©2012

Maths is not everything

Embedded Systems6 - Operating Systems

SchedulingReal-Time requirements

Inter-Process Communication

Schedulingfilesystem

I/O

Mem. Mgt.

Kernel

hardware

RMR©2012


Operating systems - Anatomy

The operating system controls resources:who gets the CPU;

when I/O takes place;

how much memory is allocated.

RMR©2012


Operating systems - Kernel

The most important resource is the CPU itself.CPU access controlled by the scheduler

Schedule policy executed by the dispatcher (processor queue)

Events handled by interrupt

Basic communication among tasks

dispatcher

interrupt

handling

syn

ch

& c

om

m

RMR©2012


© 2

008

Way

ne W

olf

Process state

A process can be in one of three states:

executing on the CPU;

ready to run;

waiting for data.

executing

ready waiting

gets dataand CPU

needsdata

gets data

needs data

preemptedgetsCPU

RMR©2012


© 2

008

Way

ne W

olf

Operating system structure

OS needs to keep track of:process priorities;

scheduling state;

process activation record.

Processes may be created:statically before system starts;

dynamically during execution.

RMR©2012


Operating Systems

Scheduling

RMR©2012


© 2

008

Way

ne W

olf

Embedded vs. general-purpose scheduling

Workstations try to avoid starving processes of CPU access.

Fairness = access to CPU.

Embedded systems must meet deadlines.Low-priority processes may not run for a long time.

Hardware

Operating

System

User Programs

Typical OS Configuration

Hardware

Including Operating

System Components

User Program

Typical Embedded Configuration

RMR©2012


© 2

008

Way

ne W

olf

Priority-driven scheduling

Each process has a priority.CPU goes to highest-priority process that is ready.Priorities determine scheduling policy:

fixed priority;

time-varying priorities.

RMR©2012


© 2

008

Way

ne W

olf

Priority-driven scheduling example

Rules:each process has a fixed priority (1 highest);

highest-priority ready process gets CPU;

process continues until done.

P1: priority 1, execution time 10



time

P2 ready t=0 P1 ready t=15

P3 ready t=18

0 3010 20 6040 50

P2 P2P1 P3

RMR©2012


© 2

008

Way

ne W

olf

The scheduling problem

Can we meet all deadlines?Must be able to meet deadlines in all cases.

How much CPU horsepower do we need to meet our deadlines?

RMR©2012


© 2

008

Way

ne W

olf

Process initiation disciplines

Periodic process: executes on (almost) every period.Aperiodic process: executes on demand.Analyzing aperiodic process sets is harder---must consider worst-case combinations of process activations.

RMR©2012


© 2

008

Way

ne W

olf

Timing requirements on processes

Period: interval between process activations.Initiation interval: reciprocal of period.Initiation time: time at which process becomes ready.Deadline: time at which process must finish.

RMR©2012


Operating Systems

Real-Time

RMR©2012


What is a real-time system?

A real-time system is any information processing system which has to respond to externally generated input stimuli within a finite and specified period

– the correctness depends not only on the logical result but also the time it was delivered

– failure to respond is as bad as the wrong response!

14

RMR©2012


Example: a simple fluid control system

Pipe

Flow meter

Valve

Interface

ComputerTime

Input flowreading

Processing

Output valveangle

15

RMR©2012


© 2

008

Way

ne W

olf

Timing violations

What happens if a process doesn’t finish by its deadline?

Hard deadline: system fails if missed.

Soft deadline: user may notice, but system doesn’t necessarily fail.

RMR©2012


A Typical Embedded System

Algorithms forDigital Control

Data Logging

Data Retrievaland Display

OperatorInterface

Interface EngineeringSystem

RemoteMonitoring System

Real-TimeClock

Database

Operator’sConsole

Display Devices

Real-Time Computer

17

RMR©2012


Characteristics of a RTS

Large and complexvary from a few hundred lines of assembler or C to 20 million lines of Ada estimated for the Space Station Freedom

Concurrent control of separate system components

devices operate in parallel in the real-world; better to model this parallelism by concurrent entities in the program

Facilities to interact with special purpose hardware

need to be able to program devices in a reliable and abstract way18

RMR©2012


Characteristics of a RTS

Extreme reliability and safeembedded systems typically control the environment in which they operate; failure to control can result in loss of life, damage to environment or economic loss

Guaranteed response timeswe need to be able to predict with confidence the worst case response times for systems; efficiency is important but predictability is essential

19

RMR©2012


Operating Systems

Inter-Process Communication & Synchronization

RMR©2012


Synchronisation and Communication

The correct behaviour of a concurrent program depends on synchronisation and communication between its processes Synchronisation: the satisfaction of constraints on the interleaving of the actions of processes (e.g. an action by one process only occurring after an action by another)

Communication: the passing of information from one process to another

Concepts are l inked since communicat ion requires synchronisation, and synchronisation can be considered as contentless communication.

Data communication is usually based upon either shared variables or message passing.

21

RMR©2012


© 2

008

Way

ne W

olf

Interprocess communication

Interprocess communication (IPC): OS provides mechanisms so that processes can pass data.Two types of semantics:

blocking: sending process waits for response;

non-blocking: sending process continues.

RMR©2012


© 2

008

Way

ne W

olf

IPC styles

Shared memory:processes have some memory in common;

must cooperate to avoid destroying/missing messages.

Message passing:processes send messages along a communication channel---no common address space.

RMR©2012


© 2

008

Way

ne W

olf

Shared memory

Shared memory on a bus:

CPU 1 CPU 2memory

RMR©2012


© 2

008

Way

ne W

olf

Race condition in shared memory

Problem when two CPUs try to write the same location:

CPU 1 reads flag and sees 0.

CPU 2 reads flag and sees 0.

CPU 1 sets flag to one and writes location.

CPU 2 sets flag to one and overwrites location.

RMR©2012


© 2

008

Way

ne W

olf

Atomic test-and-set

Problem can be solved with an atomic test-and-set:

single bus operation reads memory location, tests it, writes it.

ARM test-and-set provided by SWP: ADR r0,SEMAPHORE LDR r1,#1

GETFLAG SWP r1,r1,[r0] BNZ GETFLAG

RMR©2012


© 2

008

Way

ne W

olf

Critical regions

Critical region: section of code that cannot be interrupted by another process.Examples:

writing shared memory;

accessing I/O device.

RMR©2012


© 2

008

Way

ne W

olf

Semaphores

Semaphore: OS primitive for controlling access to critical regions.Protocol:

Get access to semaphore with P().

Perform critical region operations.

Release semaphore with V().

RMR©2012


Semaphores

A semaphore is a non-negative integer variable that apart from initialization can only be acted upon by two procedures P (or WAIT) and V (or SIGNAL)

WAIT(S) If the value of S > 0 then decrement its value by one; otherwise delay the process until S > 0 (and then decrement its value).

SIGNAL(S) Increment the value of S by one.

WAIT and SIGNAL are atomic (indivisible). Two processes both executing WAIT operations on the same semaphore cannot interfere with each other and cannot fail during the execution of a semaphore operation

29

RMR©2012


process P1; (* waiting process *) statement X; wait (consyn) statement Y; end P1;

process P2; (* signalling proc *) statement A; signal (consyn) statement B; end P2;

var consyn : semaphore (* init 0 *)

In what order will the statements execute?

Condition synchronisation

30

RMR©2012


Mutual Exclusion

process P2; statement A; wait (mutex); statement B; signal (mutex); statement C;end P2;

process P1; statement X wait (mutex); statement Y signal (mutex); statement Zend P1;

(* mutual exclusion *)var mutex : semaphore; (* initially 1 *)

In what order will the statements execute?

31

RMR©2012


type Sem is ...;X : Sem := 1; Y : Sem := 1;

task B; task body B isbegin ... Wait(Y); Wait(X); ...end B;

task A; task body A isbegin ... Wait(X); Wait(Y); ...end A;

Deadlock

Two processes are deadlocked if each is holding a resource while waiting for a resource held by the other

32

RMR©2012


Livelock

Two processes are livelocked if each is executing but neither is able to make progress.

type Flag is (Up, Down);Flag1 : Flag := Up;

task B;task body B isbegin ... while Flag1 = Up loop null; end loop; ...end A;

task A;task body A isbegin ... while Flag1 = Up loop null; end loop; ...end A;

33

RMR©2012


Binary and quantity semaphores

A general semaphore is a non-negative integer; its value can rise to any supported positive number

A binary semaphore (MUTEX) only takes the value 0 and 1; the signalling of a semaphore which has the value 1 has no effect - the semaphore retains the value 1

A general semaphore can be implemented by two binary semaphores and an integer.With a quantity semaphore the amount to be decremented by WAIT (and incremented by SIGNAL) is given as a parameter;

e.g. WAIT (S, i) 34

RMR©2012


procedure Append(I : Integer) isbegin Wait(Space_Available); Wait(Mutex; Buf(Top) := I; Top := Top+1 Signal(Mutex; Signal(Item_Available);end Append;

procedure Take(I : out Integer) isbegin Wait(Item_Available); Wait(Mutex); I := BUF(base); Base := Base+1; Signal(Mutex); Signal(Space_Available);end Take;

Example on the use of semaphores: Bounded Buffer

35

RMR©2012


© 2

008

Way

ne W

olf

Process data dependencies

One process may not be a b l e t o s t a r t u n t i l another finishes.D a t a d e p e n d e n c i e s defined in a task graph.

P1 P2

P3

P4

RMR©2012


Message-Based Communication and Synchronisation

Use of a single construct for both synchronisation and communication

Three issues: the model of synchronisation, the method of process naming, the message structure

Process P1 Process P2

send messagereceive message

time time

RMR©2012


Process Synchronisation using messages

Variations in the process synchronisation model arise from the semantics of the send operationAsynchronous (or no-wait) (e.g. POSIX)

Requires buffer space. What happens when the buffer is full?


send message

receive message

message

time time

RMR©2012



Synchronous (e.g. CSP, occam2)No buffer space required

Known as a rendezvous


send message

receive message

time time

blocked M

RMR©2012



Remote invocation (e.g. Ada)Known as an extended rendezvous

The posting of a letter is an asynchronous send

A telephone is a better analogy for synchronous communication


send message

receive message

time time

blocked

M

reply

RMR©2012


Robot Arm Example

typedef enum {xplane, yplane, zplane} dimension;

void move_arm(int D, int P);

#define DEFAULT_NBYTES 4 int nbytes = DEFAULT_NBYTES;

#define MQ_XPLANE "/mq_xplane" -- message queue name #define MQ_YPLANE "/mq_yplane" -- message queue name #define MQ_ZPLANE "/mq_zplane" -- message queue name#define MODE . . . /* mode info for mq_open */ /* names of message queues */

41

RMR©2012


Robot Arm Example

void controller(dimension dim) { int position, setting; mqd_t my_queue; /* message queue */ struct mq_attr ma; /*attributes */ char buf[DEFAULT_NBYTES]; ssiz_t len;

position = 0; switch(dim) { /* open appropriate message queue */ case xplane: my_queue = MQ_OPEN(MQ_XPLANE,O_RDONLY,MODE,&ma); break; case yplane: my_queue = MQ_OPEN(MQ_YPLANE,...); break; case zplane: my_queue = MQ_OPEN(MQ_ZPLANE,...); break; default: return; }

42

while (1) { /* read message */ len = mq_receive(my_queue, &buf[0], nbytes, null); setting = *((int *)(&buf[0])); position = position + setting; move_arm(dim, position); }}

RMR©2012


Robot Arm Example

void (*C)(dimension dim) = &controller;int main(int argc, char **argv) { mqd_t mq_xplane, mq_yplane, mq_zplane; struct mq_attr ma; /* queue attributes */ int xpid, ypid, zpid; char buf[DEFAULT_NBYTES]; /* set message queues attributes*/ ma.mq_flags = 0; /* No special behaviour */ ma.mq_maxmsg = 1; ma.mq_msgsize = nbytes; mq_xplane = MQ_OPEN(MQ_XPLANE, O_CREAT|O_EXCL, MODE, &ma); mq_yplane = ...; mq_zplane = ...;

43

Now the main program which creates the controller processes and passes the appropriate coordinates to them:

RMR©2012


/* Duplicate the process to get three controllers */ switch (xpid = FORK()) { case 0: controller(xplane); exit(0); /* child */ default: /* parent */ switch (ypid = FORK()) { case 0: controller(yplane); exit(0); default: /* parent */ switch (zpid = FORK()) { case 0: controller(zplane); exit(0); default: /* parent */ break; } } } while (1) { /* set up buffer to transmit each co-ordinate to the controllers, for example */ MQ_SEND(mq_xplane, &buf[0], nbytes, 0); }}

44

Robot Arm Example

RMR©2012


© 2

008

Way

ne W

olf

Message passing

Message passing on a network:

CPU 1 CPU 2

message message

message

Documents

S emb t12-os