Transcript CSCI1412 - Introduction & Overview
phones off
(please)
CSCI2413 Lecture 10
Operating Systems (OS) Inter-process communication
Lecture Outline
Concurrency Resources Deadlocks conditions for deadlock deadlock modeling Deadlock strategies deadlock avoidance deadlock prevention deadlock detection & recovery the ostrich algorithm © De Montfort University, 2004/5 csci2413 - L11
2
Concurrency issues
Communication among processes Sharing resources Synchronization of multiple processes Allocation of processor time Difficulties with Concurrency Facilitate sharing of global resources Management of allocation of resources Programming errors difficult to locate © De Montfort University, 2004/5 csci2413 - L11
3
Shared Resources
Physical resources processor, memory, I/O devices, disks, etc.
Logical resources message queues, inodes, records in a d-base system, etc.
Different resources that can be acquired several identical instances may be available e.g. multiple printers or tape drives the OS may choose any of them to satisfy a request A resource is anything that can only be used by a single process at any instant of time © De Montfort University, 2004/5 csci2413 - L11
4
Deadlocks
All operating systems have the ability to grant (temporary) exclusive access to certain resources Often exclusive access is needed to more than 1 resource Suppose there are two processes, A and B, and two shared resources,
printer
and
tape
A allocates the printer B allocates the tape then A requests the tape and blocks until B releases it and then B requests the printer and blocks until A releases it both processes block forever - this is a
deadlock
© De Montfort University, 2004/5 csci2413 - L11
5
Bridge Crossing Example
Traffic only in one direction.
Each section of a bridge can be viewed as a resource.
If a deadlock occurs, it can be resolved if one car backs up (preempt resources and rollback).
Several cars may have to be backed up if a deadlock occurs.
Starvation is possible.
© De Montfort University, 2004/5 csci2413 - L11
6
Resource Classification
Pre-emptable resources such a resource can be temporarily taken away from the process owning it with no ill effects e.g. processor, memory Non-pre-emptable resources once allocated to a process, removing such a resource (even temporarily) could cause the computation to fail e.g. printers Deadlocks occur with non-preemptable resources pre-emptable resources can be reallocated to avoid DL © De Montfort University, 2004/5 csci2413 - L11
7
Resource Allocation
Sequence of events needed to use a resource is
request the resource use the resource release the resource
If the resource is not available when it’s requested, the requesting process is forced to wait
in some systems, the process is automatically blocked in others, the allocation fails and returns an error the process decides whether to wait some time and try again in most cases the process will sit in a tight loop requesting the resource until it is available (as no other work can be done) in which case, the process is effectively blocked © De Montfort University, 2004/5 csci2413 - L11
8
Deadlock Definition
Deadlock can be defined formally as
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
In most cases, the event that each process is waiting for is the release of a resource currently held by another member of the set
e.g. suppose there are three processes
A
,
B
&
C
one form of deadlock is
A
waits for
B
,
B
waits for
C
,
C
waits for
A
another may be
A
waits for © De Montfort University,
B
,
B
2004/5 waits for
A
,
C
waits for
B
csci2413 - L11
9
Addressing Deadlock
Prevention
: Design the system so that deadlock is impossible
Avoidance
: Construct a model of system states, then choose a strategy that, when resources are assigned to processes, will not allow the system to go to a deadlock state
Detection & Recovery
: Check for deadlock (periodically or sporadically), then recover
Manual intervention
: Have the operator reboot the machine if it seems too slow © De Montfort University, 2004/5 csci2413 - L11
10
Conditions for Deadlock
A deadlock can only occur if the following four conditions hold simultaneously in a system
mutual exclusion hold and wait no pre-emption circular wait © De Montfort University, 2004/5 csci2413 - L11
11
“Mutual exclusion” condition
only one process may use a resource at a time
To prevent deadlock
do not require “mutual exclusion”
If this is a resource constraint, then mutual exclusion must hold at all times.
(i.e. you can’t do anything about it!) © De Montfort University, 2004/5 csci2413 - L11
12
“Hold and Wait” condition
To prevent deadlock
avoid hold and wait!
Need to be sure a process does not hold one resource while requesting another Approach 1: Force a process to request all resources it needs at one time Approach 2: If a process needs to acquire a new resource, it must first release all resources it holds, then reacquire all it needs © De Montfort University, 2004/5 csci2413 - L11
13
“No preemption”
condition
To prevent deadlock
allow preemption!
If a process holding certain resources is denied a further request, that process must release its original resources ( inefficiency in resource use) If a process requests a resource that is held by another process, the OS may preempt the second process and require it to release its resources ( waste of CPU and other resources) © De Montfort University, 2004/5 csci2413 - L11 Can only be used in certain cases
14
“Circular wait” condition
To prevent deadlock
don’t go into a circular wait situation!
© De Montfort University, 2004/5 csci2413 - L11
15
Deadlock!
P2 have resource A and need resource B to get its job done.
P1 have resource B and need resource A to get its job done.
© De Montfort University, 2004/5 csci2413 - L11
16
Example Scenario
Imagine there are three processes:
A
,
B
&
C
and three resources:
R
,
S
, &
T
The resource allocations are as follows process A request R request S release R release S process B request S request T release S release T process C request T request R release T release R
If the operating system runs the processes to completion in order A, B then C
all requests can be satisfied: no deadlock occurs
But, suppose there is pre-emptive multi-tasking
© De Montfort University, csci2413 - L11 2004/5
17
Unpredictable Results?
A
&
C
run in round-robin, then
B
A B C R S T
A
,
B
, &
C
all run in round-robin A B C R © De Montfort University, 2004/5 S T csci2413 - L11 A requests R C requests T A requests S C requests R A releases R C releases T A releases S C releases R B requests S B requests T B releases S B releases T A requests R B requests S C requests T A requests S B requests T C requests R DEADLOCK!
18
© De Montfort University, 2004/5 csci2413 - L11
19
Potential Deadlock Example
As a potential deadlock example in UNIX UNIX has a finite maximum size to its process table usually around 32,000 processes if a fork fails (because the process table is full), then a reasonable strategy (used in practice by most UNIX programmers) is to wait a short time and try again Suppose there are 100 slots free in process table ten processes run, each creates 12 (sub-)processes each loops 12 times, forking and / or waiting the scheduler starts them all running in round-robin each forks 9 child processes - the process table is full all ten processes wait forever to create the required children © De Montfort University, 2004/5 csci2413 - L11
20
Deadlock Prevention
Necessary conditions for deadlock
Mutual exclusion
Hold and wait
No preemption
Circular waiting
Ensure that at least one of the necessary conditions is false at all times © De Montfort University, 2004/5 csci2413 - L11
21
Deadlock Avoidance
Define a model of system states, then choose a strategy that will guarantee that the system will not go to a deadlock state Requires extra information, e.g., the
maximum claim
for each process Resource manager tries to see the worst case that could happen. It does not grant an incremental resource request to a process if this allocation might lead to deadlock © De Montfort University, 2004/5 csci2413 - L11
22
Resource Allocation Denial
Referred to as the
Banker’s algorithm
State of the system is the current allocation of resources to processes
Safe state
is where there is at least one sequence that does not result in deadlock © De Montfort University, 2004/5 csci2413 - L11
23
The Banker’s Algorithm The banker’s algorithm initialise an array with the number of each resource for each process keep an array of resources in use and resources still needed whenever a resource request is made by a process look for a process that can run to completion resources still needed are less than the available number assume this process runs and frees it’s resources continue, until all processes are verified to be runnable if all processes can complete: safe, grant the request else: unsafe, deny the request Unfortunately, this depends on future knowledge!
and so is ‘impossible’ in practice csci2413 - L11 2004/5
24
Deadlock Detection
In the detection and recovery approach, the system does not try to prevent deadlock occurring it simply detects when a deadlock has occurred and then (automatically) takes some action to recover The first step is, obviously, to detect the deadlock if there is a single instance of each resource type a resource allocation graph can be constructed there are many published algorithms for finding cycles (deadlocks) in such directed graphs if there are multiple instances of resource types an algorithm very similar to the banker’s algorithm is used (but it does not require future knowledge to detect deadlock) © De Montfort University, 2004/5 csci2413 - L11
25
Deadlock Recovery
Deadlock recovery methods include recovery through pre-emption a deadlocked resource is taken away again this causes big problems for resources such as printers may be possible to carefully choose the pre-emption to make this work recovery through rollback each resource allocation causes some form of checkpoint for the process to be saved by the operating system similar to a process table entry for a pre-empted process on deadlock, processes ‘rewound’ to free required resources may be very difficult & costly, if e.g. files have been written to recovery through process termination crudest method is to kill one or more deadlocked processes with luck the deadlock with cease, if not kill more processes!
but how can processes be killed without causing ‘damage’?
© De Montfort University, 2004/5 csci2413 - L11
26
The Ostrich Algorithm Surprisingly, perhaps, ignoring the problem altogether is a popular choice of algorithm!
this is the ‘ostrich algorithm’: stick your head in the sand and pretend that there is no problem at all Is this acceptable?
mathematicians say ‘no’ engineers say ‘calculate how often it’s likely to occur, and if that is infrequent enough, then it’s tolerable’ computer scientists say ‘sure ... everyone expects a computer to hang or crash occasionally’!
Most contemporary OS’s, including both UNIX and Windows NT, use the ostrich algorithm © De Montfort University, 2004/5 csci2413 - L11
27
The following slides are supplements, not covered in the lecture session Also see chapter 6 pages 275 – 279, Stallings © De Montfort University, 2004/5 csci2413 - L11
28
Dining Philosophers Problem
© De Montfort University, 2004/5 csci2413 - L11
29
Dining Philosophers Problem
5 Philosophers 5 forks Each philosopher needs two forks to eat with Devise a deadlock free strategy © De Montfort University, 2004/5 csci2413 - L11
30
Dining Philosophers Problem
3.
4.
5.
6.
1.
2.
Each Philosopher picks up L fork then R, eats and replaces forks – possible starvation.
Each philosopher picks up L fork. If R fork available takes it and eats; else puts L fork back ?
Buy 5 more forks !
Teach philosophers to eat spaghetti with 1 fork !
Allow only four philosophers at a time into the room.
Have at least one philosopher who is left handed in (2) above (R fork first).
© De Montfort University, 2004/5 csci2413 - L11
31
UNIX Signals
UNIX uses
signals
for IPC synchronisation A UNIX signal is similar to a software interrupt a process may send a signal to another process when a signal arrives, the receiving process stops what it is doing and immediately services the signal A signal is sent by using the kill system call kill(process_id, signal_number); © De Montfort University, 2004/5 csci2413 - L11
32
Signals …
The action taken when a signal is received by a process is specified by the signal system call it can (usually) be ignored it can terminate the process it can be ‘caught’ by a special signal handling function © De Montfort University, 2004/5 csci2413 - L11
33
Signal List
Signal Name Cause SIGHUP hangup on controlling terminal or death of control process SIGINT SIGQUIT interrupt from keyboard (usually CTRL-C) quit from keyboard (usually CTRL-\) SIGILL illegal instruction Signal Name SIGPIPE SIGALRM SIGCHLD SIGTERM Cause broken pipe: write to pipe with no readers timer signal from alarm system call child process stopped or terminated used to request that a process terminates gracefully SIGUSR1 user-defined signal 1 SIGABRT abort signal from debugger SIGFPE SIGKILL SIGSEGV floating point exception kill signal (cannot be caught or ignored) segmentation violation SIGUSR2 SIGPWR SIGWINCH user-defined signal 2 power failure window resize signal © De Montfort University, 2004/5 csci2413 - L11
34
Signal Examples SIGKILL
sent to a process to immediately kill it this signal cannot be caught or ignored typically used by the system to stop processes at shutdown or by root to kill runaway processes via the ‘kill’ command
SIGFPE
floating point error
SIGSEGV
illegal or invalid memory reference these can be caught by a program, to take appropriate action © De Montfort University, 2004/5 csci2413 - L11
35
Signal ….
SIGPIPE
write on a pipe with no readers can be caught to allow the ‘earlier’ processes in a pipe line to exit when a ‘later’ process has exited abnormally
SIGINT/QUIT
two levels of keyboard interrupt SIGINT is ‘gentler’: interpreted as a request to stop SIGQUIT is ‘harder’: an instruction to stop © De Montfort University, 2004/5 csci2413 - L11
36
Effect of a signal on a process
A program should be terminated, either normally exit executed, or abnormally - abort executed, depending on the signal received.
Other options : ignore the signal; the arrival of the signal has no effect.
catch the signal; an exception routine called.
© De Montfort University, 2004/5 csci2413 - L11
37
To ignore or catch a signal
A system call signal is used. e.g. to ignore signals : #include
38