Real-Time Systems Lecture 8

1. Real-Time SystemsLecture 8 Lärare: Olle Bowallius Telefon: 790 44 42 Email: olleb@isk.kth.se Anders Västberg Telefon: 790 44 55 Email: vastberg@kth.se

2. 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

3. Resources (2) Sequence of events required to use a resource • request the resource • use the resource • release the resource Problems • Failure of a process results in that the resource is unavailable to other resources • Starvation • Deadlock

4. 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

5. 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

6. Four Conditions for Deadlock • Mutual exclusion condition • Hold and wait condition • No preemption condition • Circular wait condition

7. Deadlock (3) Strategies for dealing with Deadlocks • just ignore the problem altogether • Deadlock detection and recovery • Deadlock avoidance • Deadlock prevention

8. Deadlock (4) A B C How deadlock occurs

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

10. 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

11. Deadlock detection

12. Deadlock detection

13. Deadlock detection

14. 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

15. 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

16. Safe and Unsafe States (1) Demonstration that the state in (a) is safe (a) (b) (c) (d) (e)

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

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

19. Deadlock PreventionAttacking 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

20. 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

21. 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 • !!??

22. Circular Wait Condition (1) • Normally ordered resources • A resource graph (a) (b)

23. Deadlock prevention Summary of approaches to deadlock prevention

24. 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

25. 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

26. 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.

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

28. Clocks • Standard clock • Ideal clock

29. Properties of time • Correctness • Bounded drift • Monotonicity • Chronoscopicity

30. 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)

31. ISO-C time interface typedef 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*);

32. 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 */

33. 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

34. 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);

35. Relative delay while(1) { doWork(); delay(100); } 100ms doWork doWork doWork 100ms

36. 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 100ms doWork doWork doWork doWork Can be implemented using POSIX timers

37. 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

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

39. 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