CSCI2413 Lecture 10
Operating Systems (OS)
Inter-process communication
phones off (please)
csci2413 - L11 2© De Montfort University, 2004/5
Lecture Outline Concurrency Resources Deadlocks
conditions for deadlock deadlock modeling
Deadlock strategies deadlock avoidance deadlock prevention deadlock detection & recovery the ostrich algorithm
csci2413 - L11 3© De Montfort University, 2004/5
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
csci2413 - L11 4© De Montfort University, 2004/5
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 acquiredseveral 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
csci2413 - L11 5© De Montfort University, 2004/5
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
csci2413 - L11 6© De Montfort University, 2004/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.
csci2413 - L11 7© De Montfort University, 2004/5
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
csci2413 - L11 8© De Montfort University, 2004/5
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
csci2413 - L11 9© De Montfort University, 2004/5
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 B, B waits for A, C waits for B
csci2413 - L11 10© De Montfort University, 2004/5
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
csci2413 - L11 11© De Montfort University, 2004/5
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
csci2413 - L11 12© De Montfort University, 2004/5
“Mutual exclusion” conditiononly 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!)
csci2413 - L11 13© De Montfort University, 2004/5
“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
csci2413 - L11 14© De Montfort University, 2004/5
“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)
Can only be used in certain cases
csci2413 - L11 15© De Montfort University, 2004/5
“Circular wait” condition
To prevent deadlock
don’t go into a circular wait situation!
csci2413 - L11 16© De Montfort University, 2004/5
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.
csci2413 - L11 17© De Montfort University, 2004/5
Example Scenario Imagine there are three processes: A, B & C
and three resources: R, S, & T The resource allocations are as follows
process Arequest R
request S
release R
release S
process Brequest S
request T
release S
release T
process Crequest 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
csci2413 - L11 18© De Montfort University, 2004/5
Unpredictable Results? A & C run in round-robin, then B
A B C
R S T
A requests RC requests TA requests SC requests RA releases RC releases TA releases SC releases RB requests SB requests TB releases SB releases T
A, B, & C all run in round-robin
A B C
R S T
A requests RB requests SC requests TA requests SB requests TC requests R
DEADLOCK!
csci2413 - L11 19© De Montfort University, 2004/5
csci2413 - L11 20© De Montfort University, 2004/5
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
csci2413 - L11 21© De Montfort University, 2004/5
Deadlock Prevention
Necessary conditions for deadlockMutual exclusionHold and waitNo preemption Circular waiting
Ensure that at least one of the necessary conditions is false at all times
csci2413 - L11 22© De Montfort University, 2004/5
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
csci2413 - L11 23© De Montfort University, 2004/5
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
csci2413 - L11 24© De Montfort University, 2004/5
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 25© De Montfort University, 2004/5
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)
csci2413 - L11 26© De Montfort University, 2004/5
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’?
csci2413 - L11 27© De Montfort University, 2004/5
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
csci2413 - L11 28© De Montfort University, 2004/5
The following slides are supplements, not covered in the lecture session
Also see chapter 6 pages 275 – 279, Stallings
csci2413 - L11 29© De Montfort University, 2004/5
Dining Philosophers Problem
csci2413 - L11 30© De Montfort University, 2004/5
Dining Philosophers Problem
5 Philosophers 5 forks Each philosopher needs two forks to eat with Devise a deadlock free strategy
csci2413 - L11 31© De Montfort University, 2004/5
Dining Philosophers Problem
1. Each Philosopher picks up L fork then R, eats and replaces forks – possible starvation.
2. Each philosopher picks up L fork. If R fork available takes it and eats; else puts L fork back ?
3. Buy 5 more forks !
4. Teach philosophers to eat spaghetti with 1 fork !
5. Allow only four philosophers at a time into the room.
6. Have at least one philosopher who is left handed in (2) above (R fork first).
csci2413 - L11 32© De Montfort University, 2004/5
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 processwhen 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);
csci2413 - L11 33© De Montfort University, 2004/5
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
csci2413 - L11 34© De Montfort University, 2004/5
Signal ListSignal Name Cause Signal Name Cause
SIGHUPhangup on controlling terminal
or death of control process
SIGINTinterrupt from keyboard
(usually CTRL-C)
SIGQUITquit from keyboard(usually CTRL-\)
SIGILL illegal instruction
SIGABRT abort signal from debugger
SIGFPE floating point exception
SIGKILLkill signal
(cannot be caught or ignored)
SIGSEGV segmentation violation
SIGPIPEbroken pipe: write to pipe
with no readers
SIGALRMtimer signal from alarm
system call
SIGCHLDchild process stopped
or terminated
SIGTERMused to request that a process
terminates gracefully
SIGUSR1 user-defined signal 1
SIGUSR2 user-defined signal 2
SIGPWR power failure
SIGWINCH window resize signal
csci2413 - L11 35© De Montfort University, 2004/5
Signal ExamplesSIGKILL 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
csci2413 - L11 36© De Montfort University, 2004/5
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 interruptSIGINT is ‘gentler’: interpreted as a request to
stop SIGQUIT is ‘harder’: an instruction to stop
csci2413 - L11 37© De Montfort University, 2004/5
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.
csci2413 - L11 38© De Montfort University, 2004/5
To ignore or catch a signal
A system call signal is used. e.g. to ignore signals :- #include <signal.h> signal(SIGINT, SIG_IGN); /* to ignore SIGINT */
signal(SIGINT, SIG_DFL); /* to change back to default */