Real-Time SystemsReal-Time SystemsLecture 8Lecture 8

Lärare: Olle BowalliusTelefon: 790 44 42

Email: olleb@isk.kth.se

Anders VästbergTelefon: 790 44 55

Email: vastberg@kth.se

ResourcesResources

Examples of computer resources– printers– tape drives– Tables

Preemptable resources– can be taken away from a process with no ill effects

Nonpreemptable resources– will cause the process to fail if taken away

Control agent– Passive: Protected or synchronized– Active: Server

Resources (2)Resources (2)

Sequence of events required to use a resource1. request the resource

2. use the resource

3. release the resource

Problems Failure of a process results in that the resource is unavailable

to other resources Starvation Deadlock

DeadlocksDeadlocks

Formal definition :A set of processes is deadlocked if each process in the set is waiting for an event that only another process in the set can cause

Usually the event is release of a currently held resource None of the processes can …

– run– release resources– be awakened

Similar problem is where a collection of processes are not proceeding but are still executing. That is, they are in livelock

Deadlock (2)Deadlock (2)

Modeled with directed graphs

– resource R assigned to process A– process B is requesting/waiting for resource S– process C and D are in deadlock over resources T and U

Four Conditions for DeadlockFour Conditions for Deadlock

Mutual exclusion condition Hold and wait condition No preemption condition Circular wait condition

Deadlock (3)Deadlock (3)

Strategies for dealing with Deadlocks just ignore the problem altogether Deadlock detection and recovery Deadlock avoidance Deadlock prevention

How deadlock occurs

A B CDeadlock (4)Deadlock (4)

Deadlock (5)Deadlock (5)

How deadlock can be avoided

(o) (p) (q)

The Ostrich AlgorithmThe Ostrich Algorithm

Pretend there is no problem Reasonable if

– deadlocks occur very rarely – cost of prevention is high

UNIX and Windows takes this approach It is a trade off between

– convenience– correctness

Deadlock detectionDeadlock detection

Deadlock detectionDeadlock detection

Deadlock detectionDeadlock detection

Deadlock recoveryDeadlock recovery

Recovery through preemption– take a resource from some other process– depends on nature of the resource

Recovery through rollback– checkpoint a process periodically– use this saved state – restart the process if it is found deadlocked

Deadlock recoveryDeadlock recovery

Recovery through killing processes– crudest but simplest way to break a deadlock– kill one of the processes in the deadlock cycle– the other processes get its resources – choose process that can be rerun from the beginning

Safe and Unsafe States (1)Safe and Unsafe States (1)

Demonstration that the state in (a) is safe

(a) (b) (c) (d) (e)

Safe and Unsafe States (2)Safe and Unsafe States (2)

Demonstration that the sate in b is not safe

(a) (b) (c) (d)

The Banker's AlgorithmThe Banker's Algorithm

Three resource allocation states– safe– safe– unsafe

(a) (b) (c)

Deadlock PreventionDeadlock PreventionAttacking the Mutual Exclusion ConditionAttacking the Mutual Exclusion Condition

Some devices (such as printer) can be spooled– only the printer daemon uses printer resource– thus deadlock for printer eliminated

Not all devices can be spooled Principle:

– avoid assigning resource when not absolutely necessary– as few processes as possible actually claim the resource

Attacking the Hold and Wait Attacking the Hold and Wait ConditionCondition

Require processes to request resources before starting– a process never has to wait for what it needs

Problems– may not know required resources at start of run– also ties up resources other processes could be using

Variation: – process must give up all resources– then request all immediately needed

Attacking the No Preemption ConditionAttacking the No Preemption Condition

This is not a viable option Consider a process given the printer

– halfway through its job– now forcibly take away printer– !!??

Circular Wait Condition (1)Circular Wait Condition (1)

Normally ordered resources A resource graph

(a) (b)

Deadlock preventionDeadlock prevention

Summary of approaches to deadlock prevention

Nonresource DeadlocksNonresource Deadlocks

Possible for two processes to deadlock– each is waiting for the other to do some task

Can happen with semaphores– each process required to do a down() on two

semaphores (mutex and another)– if done in wrong order, deadlock results

StarvationStarvation Algorithm to allocate a resource

– may be to give to shortest job first

Works great for multiple short jobs in a system

May cause long job to be postponed indefinitely– even though not blocked

Solution:– First-come, first-serve policy

TimeTime

Frequency of vibration of the Cs 133 atom– One second is defined 9,192,631,770 periods of Cs 133.– Also defines the length of a meter by using the speed of

light.– International Atomic Time (TAI) is maintained in Paris

by averaging a number of atomic clocks from around the world.

Access to a ClockAccess to a Clock

by having direct access to the environment's time frame (e.g. GPS also provides a UTC service)

by using an internal hardware clock that gives an adequate approximation to the passage of time in the environment

Several alternatives:– Unit (seconds, milliseconds, clock ticks?)– Since when? (program start, Jan 1st 1970?)– Real-time? (or monotonic time, cpu time)

ClocksClocks

Standard clock

ttC )(

ttCs )(

Ideal clock

TimeClockTimeRealCLOCK :

Properties of timeProperties of time

Correctness

Bounded drift

Monotonicity

Chronoscopicity

)()( tCtC s

1)(

dt

tdC

2

2 )(

dt

tCd

)()(:, 212121 tCtCtttt

Clocks in C and POSIXClocks in C and POSIX ANSI C has a standard library for interfacing to “calendar”

time This defines a basic time type time_t and several

routines for manipulating objects of type time POSIX allows many clocks to be supported by an

implementation POSIX requires at least one clock of minimum resolution

50 Hz (20ms)

ISO-C time interfaceISO-C time interfacetypedef long int time_t;typedef long int clock_t;

struct tm{

int tm_sec; /* Seconds: 0-59 (K&R says 0-61?) */int tm_min; /* Minutes: 0-59 */int tm_hour; /* Hours since midnight: 0-23 */int tm_mday; /* Day of the month: 1-31 */int tm_mon; /* Months *since* january: 0-11 */int tm_year; /* Years since 1900 */int tm_wday; /* Days since Sunday (0-6) */int tm_yday; /* Days since Jan. 1: 0-365 */int tm_isdst; /* +1 Daylight Savings Time, 0 No DST,

* -1 don't know */};

clock_t clock (void);time_t time (time_t*);double difftime (time_t, time_t);time_t mktime (struct tm*);

POSIX Real-Time ClocksPOSIX Real-Time Clocks#define CLOCK_REALTIME ...; // clockid_t type

struct timespec { time_t tv_sec; /* number of seconds */ long tv_nsec; /* number of nanoseconds */};typedef ... clockid_t;

int clock_gettime(clockid_t clock_id, struct timespec *tp);int clock_settime(clockid_t clock_id, const struct timespec *tp);int clock_getres(clockid_t clock_id, struct timespec *res);

int clock_getcpuclockid(pid_t pid, clockid_t *clock_id);int clock_getcpuclockid(pthread_t thread_id, clockid_t *clock_id);

int nanosleep(const struct timespec *rqtp, struct timespec *rmtp);/* nanosleep return -1 if the sleep is interrupted by a *//* signal. In this case, rmtp has the remaining sleep time */

Relative and Absolute delaysRelative and Absolute delays Wake me in 2 hours (relative) Wake me at 12:00 (absolute) Relative time delay implies the given time plus some time

reference. Absolute time implies a point in a commonly agreed time

scale. To avoid busy-wait loops we need a delay primitive

– sleep or delay statement

Delay statements in POSIXDelay statements in POSIX

Sleep for seconds:– sleep(3);

Sleep for milliseconds:– delay(3);

Sleep for nanoseconds:struct timespec t;

t.tv_sec = 0;

t.tv_nsec = 40;

nanosleep(&t, NULL);

Relative delayRelative delay

doWork

while(1){ doWork(); delay(100);}

doWork doWork

100ms

100ms

Absolute delayAbsolute delay

while(1){ start = rt_clock(…); doWork(); /* does not work as intended delay(100-(rt_clock(…)-start));}

would have tobe an atomic action

doWork doWork doWork

100ms

doWork

Can be implemented using POSIX timers

DriftDrift

The time over-run associated with both relative and absolute delays is called the local drift and it it cannot be eliminated

It is possible, however, to eliminate the cumulative drift that could arise if local drifts were allowed to superimpose

TimeoutsTimeouts

Act on non-occurrence of an event. Often implemented in RTOS primitives for

message-passing, wait-operations for semaphores or condition variables

Watchdog Timer ProcessWatchdog Timer Process

If the watchdog timer process is not reset within a certain period by a component, it assumes that the component is in error.

The software component must continually reset the timer to indicate that it is functioning correctly