Real-Time Systems Lecture 8 Lärare: Olle Bowallius Telefon: 790 44 42 Email: [email protected]...
-
Upload
ashlee-pearson -
Category
Documents
-
view
214 -
download
0
Transcript of Real-Time Systems Lecture 8 Lärare: Olle Bowallius Telefon: 790 44 42 Email: [email protected]...
Real-Time SystemsReal-Time SystemsLecture 8Lecture 8
Lärare: Olle BowalliusTelefon: 790 44 42
Email: [email protected]
Anders VästbergTelefon: 790 44 55
Email: [email protected]
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
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 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)
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)
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);
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