Download 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
 the
detection & recovery
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


Logical resources


processor, memory, I/O devices, disks, etc.
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.
© DeStarvation
is possible.
Montfort University,

2004/5
csci2413 - L11
6
Resource Classification

Pre-emptable resources


Non-pre-emptable resources


such a resource can be temporarily taken away from the process
owning it with no ill effects
 e.g. processor, memory
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
© De Montfort University,
2004/5
resources can be reallocated to avoid DL
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 B, B waits for A, C waits for B
© De Montfort University,
2004/5
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
© De Montfort University,
2004/5
wait
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
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 B
process C
request R
request S
request T
request S
request T
request R
release R
release S
release T
release S
release T
release R
If the operating system runs the processes to
completion in order A, B then C
 all

process A
requests can be satisfied: no deadlock occurs
But, suppose there is pre-emptive multi-tasking
© De Montfort University,
2004/5
csci2413 - L11
17
Unpredictable Results?


A & C run in round-robin, then B
A
B
C
R
S
T
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, B, & C all run in round-robin
A
B
C
R
S
T
A requests R
B requests S
C requests T
A requests S
B requests T
C requests R
DEADLOCK!
© De Montfort University,
2004/5
csci2413 - L11
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
© De Montfort
University,

2004/5
csci2413 - L11
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!


Is this acceptable?




this is the ‘ostrich algorithm’: stick your head in the sand and pretend
that there is no problem at all
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
1.
2.
3.
4.
5.
6.
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
Signal Name
Cause
hangup on controlling terminal
or death of control process
interrupt from keyboard
(usually CTRL-C)
quit from keyboard
(usually CTRL-\)
SIGALRM
SIGILL
illegal instruction
SIGTERM
SIGABRT
abort signal from debugger
SIGUSR1
user-defined signal 1
SIGFPE
floating point exception
SIGUSR2
user-defined signal 2
SIGKILL
kill signal
(cannot be caught or ignored)
SIGPWR
power failure
SIGSEGV
segmentation violation
SIGWINCH
window resize signal
SIGHUP
SIGINT
SIGQUIT
© De Montfort University,
2004/5
SIGPIPE
SIGCHLD
csci2413 - L11
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
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
SIGSEGV
floating point error
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 <signal.h>

signal(SIGINT, SIG_IGN); /* to ignore SIGINT */

signal(SIGINT, SIG_DFL); /* to change back to

default */
© De Montfort University,
2004/5
csci2413 - L11
38