Real-Time Systems Lecture 8 Lärare: Olle Bowallius Telefon: Anders Västberg Telefon:

Resources 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) Sequence of events required to use a resource 1. 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

Deadlocks 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) 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 Deadlock Mutual exclusion condition Hold and wait condition No preemption condition Circular wait condition

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 C Deadlock (4)

Deadlock (5) How deadlock can be avoided (o) (p) (q)

The 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 detection Deadlock detection

Deadlock 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 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) Demonstration that the state in (a) is safe (a) (b) (c) (d) (e)

Safe and Unsafe States (2) Demonstration that the sate in b is not safe (a) (b) (c) (d)

The Banker's Algorithm Three resource allocation states – safe – unsafe (a) (b) (c)

Deadlock Prevention Attacking 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 Condition 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 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) Normally ordered resources A resource graph (a) (b)

Deadlock prevention Summary of approaches to deadlock prevention

Nonresource 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

Starvation 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

Time 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 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 1 st 1970?) – Real-time? (or monotonic time, cpu time)

Clocks Standard clock Ideal clock

Properties of time Correctness Bounded drift Monotonicity Chronoscopicity

Clocks 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 interface typedef long int time_t; typedef long int clock_t; struct tm { inttm_sec;/* Seconds: 0-59 (K&R says 0-61?) */ inttm_min;/* Minutes: 0-59 */ inttm_hour;/* Hours since midnight: 0-23 */ inttm_mday;/* Day of the month: 1-31 */ inttm_mon;/* Months *since* january: 0-11 */ inttm_year;/* Years since 1900 */ inttm_wday;/* Days since Sunday (0-6) */ inttm_yday;/* Days since Jan. 1: */ inttm_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 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 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 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 delay doWork while(1) { doWork(); delay(100); } doWork 100ms

Absolute delay while(1) { start = rt_clock(…); doWork(); /* does not work as intended delay(100-(rt_clock(…)-start)); } would have to be an atomic action doWork 100ms doWork Can be implemented using POSIX timers

Drift 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

Timeouts Act on non-occurrence of an event. Often implemented in RTOS primitives for message-passing, wait-operations for semaphores or condition variables

Watchdog 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