s emb t12-os
TRANSCRIPT
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
Maths is not everything
Operating systems - Anatomy
The operating system controls resources:who gets the CPU;
when I/O takes place;
how much memory is allocated.
RMR©2012
Maths is not everything
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
Maths is not everything
© 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
Maths is not everything
© 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
Maths is not everything
Operating Systems
Scheduling
RMR©2012
Maths is not everything
© 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
Maths is not everything
© 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
Maths is not everything
© 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
P2: priority 2, execution time 30
P3: priority 3, execution time 20
time
P2 ready t=0 P1 ready t=15
P3 ready t=18
0 3010 20 6040 50
P2 P2P1 P3
RMR©2012
Maths is not everything
© 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
Maths is not everything
© 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
Maths is not everything
© 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
Maths is not everything
Operating Systems
Real-Time
RMR©2012
Maths is not everything
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
Maths is not everything
Example: a simple fluid control system
Pipe
Flow meter
Valve
Interface
ComputerTime
Input flowreading
Processing
Output valveangle
15
RMR©2012
Maths is not everything
© 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
Maths is not everything
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
Maths is not everything
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
Maths is not everything
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
Maths is not everything
Operating Systems
Inter-Process Communication & Synchronization
RMR©2012
Maths is not everything
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
Maths is not everything
© 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
Maths is not everything
© 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
Maths is not everything
© 2
008
Way
ne W
olf
Shared memory
Shared memory on a bus:
CPU 1 CPU 2memory
RMR©2012
Maths is not everything
© 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
Maths is not everything
© 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
Maths is not everything
© 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
Maths is not everything
© 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
Maths is not everything
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
Maths is not everything
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
Maths is not everything
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
Maths is not everything
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
Maths is not everything
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
Maths is not everything
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
Maths is not everything
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
Maths is not everything
© 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
Maths is not everything
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
Maths is not everything
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?
Process P1 Process P2
send message
receive message
message
time time
RMR©2012
Maths is not everything
Process Synchronisation using messages
Synchronous (e.g. CSP, occam2)No buffer space required
Known as a rendezvous
Process P1 Process P2
send message
receive message
time time
blocked M
RMR©2012
Maths is not everything
Process Synchronisation using messages
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
Process P1 Process P2
send message
receive message
time time
blocked
M
reply
RMR©2012
Maths is not everything
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
Maths is not everything
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
Maths is not everything
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
Maths is not everything
/* 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
Maths is not everything
© 2
008
Way
ne W
olf
Message passing
Message passing on a network:
CPU 1 CPU 2
message message
message