concurrency: deadlock and starvationpami.uwaterloo.ca/~basir/ece354/chpt6cw-web.pdf · concurrency:...
TRANSCRIPT
Dr. Otman Basir Winter 2006
E&CE 354: Processes 1
Concurrency: Deadlock and Starvation
Chapter 6
Dr. Otman Basir Winter 2006
E&CE 354: Processes 2
DeadlockDeadlock = situation in which every process from a set is permanently blocked, i.e. cannot proceed with executionCommon cause: processes from the set either compete for system resources or communicate with each other
Dr. Otman Basir Winter 2006
E&CE 354: Processes 3
Reusable ResourcesTwo categories of resources– reusable, consumable
Reusable resource = resource used by one process at a time and not depleted by that useProcesses obtain resources that they later release for use by other processesExamples: processors, I/O channels, main/secondary memory, files, databases, and semaphoresDeadlock may occur if a process holds some resources and needs resources held by others to proceed
Dr. Otman Basir Winter 2006
E&CE 354: Processes 4
Example of Deadlock
two resources D, T
Dr. Otman Basir Winter 2006
E&CE 354: Processes 5
Consumable ResourcesConsumable resource = resource which is created (produced) and destroyed (consumed)
Example: interrupts, signals, messages, and information in I/O buffers
Deadlock may occur if receive is blocking
It may take a rare combination of events to cause deadlock
Dr. Otman Basir Winter 2006
E&CE 354: Processes 6
Conditions for Deadlock1. Mutual exclusion
– only one process may use a resource at a time2. Hold-and-wait
– a process holds allocated resources while awaiting assignment of others
3. No preemption– no resource can be forcibly removed from a
process holding itpossible deadlock with these conditions, but might not exist with just these three
Dr. Otman Basir Winter 2006
E&CE 354: Processes 7
Conditions for Deadlock [2]4. Circular wait
A →B→A, where X →Y means X waits for resource held by Y
Dr. Otman Basir Winter 2006
E&CE 354: Processes 8
Deadlock Prevention AlternativesMutual exclusion– cannot be discarded; if mutual exclusion is
required for a resource access, then it must be provided
Hold and Wait– force process to acquire all resources at one time
• block process until all requests can be granted simultaneously
– problem: inefficiency• might slow down process• allocated resources may remain unused for a
long time– resource needs may be difficult to predict
Dr. Otman Basir Winter 2006
E&CE 354: Processes 9
Deadlock Prevention Alternatives [2]No preemption– If a process requests a resource currently held by
another process, the operating system could preempt the second process and require it to release its resources
– practical if resource state can be saved/restoredCircular wait– define linear ordering of resource types– processes must request resources in the order
given by this ordering– may be inefficient, slowing down processes and
possibly denying resource access unnecessarily
Dr. Otman Basir Winter 2006
E&CE 354: Processes 10
Deadlock AvoidanceA decision is made dynamically whether the current resource allocation request could, if granted, potentially lead to a deadlock
Requires knowledge of future process request
Dr. Otman Basir Winter 2006
E&CE 354: Processes 11
Two Approaches to Deadlock Avoidance
Do not start a process if its demands might possibly lead to deadlock [process initiation denial]
Do not grant an incremental resource request to a process if this allocation might lead to deadlock [resource allocation denial]
Dr. Otman Basir Winter 2006
E&CE 354: Processes 12
Process Initiation Denialconsider system with n processes and m different resources:
Resource = ( R1, R2, … , Rm)– total amt of each resource in system
Available = (V1, V2, … , Vm)– total amt of each resource not allocated
Dr. Otman Basir Winter 2006
E&CE 354: Processes 13
Process Initiation Denial [2]
⎟⎟⎟⎟⎟
⎠
⎞
⎜⎜⎜⎜⎜
⎝
⎛
=
nmnn
m
m
CCC
CCCCCC
Claim
...
...
...
21
22221
11211
MMMM
⎟⎟⎟⎟⎟
⎠
⎞
⎜⎜⎜⎜⎜
⎝
⎛
=
nmnn
m
m
AAA
AAAAAA
Allocation
...
...
...
21
22221
11211
MMMM
requirement of each process for
each resource
current allocation
Dr. Otman Basir Winter 2006
E&CE 354: Processes 14
Process Initiation Denial [3]The following relationships hold:
for all i. All resources are either available or allocated.
Cki ≤ Ri , for all k, i. No processes can claim more than the total amt of resources in system
Aki ≤ Cki ,for all k, i. No process is allocated more resources of any type than the process originally claimed to need
∑=
+=n
kkiii AVR
1
Dr. Otman Basir Winter 2006
E&CE 354: Processes 15
Process Initiation Denial [4]define a deadlock avoidance policy that does not start a new process if its resource requirements “might” lead to deadlockstart a new process Pn+1 only if
not optimal policy since it assumes the worst case: all processes make their maximum claims together
∑=
+ +≥n
kkiini iCCR
1)1( allfor
Dr. Otman Basir Winter 2006
E&CE 354: Processes 16
Resource Allocation DenialOne strategy: 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 execution sequence that does not result in deadlock (i.e. in which processes can be run to completion)
Unsafe state is a state that is not safe
Dr. Otman Basir Winter 2006
E&CE 354: Processes 17
Determination of Safe State
Initial state:
024301100222
C-A
Dr. Otman Basir Winter 2006
E&CE 354: Processes 18
Determination of a Safe StateP2 Runs to Completion
024301000222
C-A
Dr. Otman Basir Winter 2006
E&CE 354: Processes 19
Determination of a Safe StateP1 Runs to Completion
024301000000
C-A
Dr. Otman Basir Winter 2006
E&CE 354: Processes 20
Determination of a Safe StateP3 Runs to Completion
024000000000
C-A
Dr. Otman Basir Winter 2006
E&CE 354: Processes 21
Determination of an Unsafe State
Dr. Otman Basir Winter 2006
E&CE 354: Processes 22
Determination of an Unsafe State
024301201121
Dr. Otman Basir Winter 2006
E&CE 354: Processes 23
Deadlock Avoidance Algorithm
Dr. Otman Basir Winter 2006
E&CE 354: Processes 24
Deadlock Avoidance Algorithm [2]
Dr. Otman Basir Winter 2006
E&CE 354: Processes 25
Deadlock Avoidance SummaryEvery process must state its maximum resource requirement in advance
Processes under consideration must be entirely independent; no synchronization requirements
There must be a fixed number of resources to allocate
No process may exit while holding resources
Dr. Otman Basir Winter 2006
E&CE 354: Processes 26
Deadlock Detectioncheck for deadlock either at each resource request or some longer interval depending on likelihood of deadlockuse the Allocation matrix and Available vector as beforedefine matrix Q where qij is the amt of resources of type j requested by process i.initially all processes are unmarked the following steps performed:
Dr. Otman Basir Winter 2006
E&CE 354: Processes 27
Deadlock Detection Algorithm1. mark each process with a row in Allocation matrix of
all zeros2. initialize a temp vector W to equal the Available
vector3. find i such that process i is currently unmarked and
the i-th row of Q is less or equal to W.– Qik ≤ Wk, for 1 ≤ k ≤ m. If no such row found,
terminate algorithm4. if such row found, mark process i and add
corresponding row of allocation matrix to W,– Wk = Wk + Aik, for 1 ≤ k ≤ m. Goto step 3
Dr. Otman Basir Winter 2006
E&CE 354: Processes 28
Deadlock Detection Algorithm [2]deadlock exists iff there are unmarked processes at the end of the algorithm
each unmarked process is deadlocked
Dr. Otman Basir Winter 2006
E&CE 354: Processes 29
Deadlock Detection Example
Set W=(00001)Q of P3 is less than or equal to W, thus P3 is marked W=W+(00010)=(00011)No other unmarked process has a row in Q that is less than or equal to W, (Terminate) deadlock
Dr. Otman Basir Winter 2006
E&CE 354: Processes 30
Strategies once Deadlock DetectedAbort all deadlocked processes
Back up each deadlocked process to some previously defined checkpoint, and restart all process
– original deadlock may occur
Successively abort individual deadlocked processes until deadlock no longer exists
Successively preempt resources until deadlock no longer exists
Dr. Otman Basir Winter 2006
E&CE 354: Processes 31
Selection Criteria for Abort
Least amount of processor time consumed so far
Least number of lines of output produced so far
Most estimated time remaining
Least total resources allocated so far
Lowest priority
Dr. Otman Basir Winter 2006
E&CE 354: Processes 32
Concurrency Mechanisms in OS
operating systems considered– Unix– Solaris– Windows 2000
Dr. Otman Basir Winter 2006
E&CE 354: Processes 33
UNIX Concurrency MechanismsPipes
Messages
Shared memory
Semaphores
Signals
Dr. Otman Basir Winter 2006
E&CE 354: Processes 34
UNIX Pipescircular buffer, allows two processes to communicatewhen process tries to write:– if sufficient space, request executed immedistely– otherwise process blocks
when a process tries to read:– blocks if tries to read more bytes than currently in
buffer– otherwise read request immediately executed
mutual exclusion enforced by OS
Dr. Otman Basir Winter 2006
E&CE 354: Processes 35
UNIX Messagesmessage = msg_type + a block of text msgs sent to/received from a message queue (i.e. a mailbox); queues dynamically createdsender specifies msg type, receiver retrieves either by msg type or FIFO orderprocess may suspend:– on send to full queue– on receive from empty queue– but not if read of specific msg type fails
Dr. Otman Basir Winter 2006
E&CE 354: Processes 36
UNIX Shared Memoryfastest form of IPCcooperating processes share common block of virtual memoryeach process treats shared block as part of its own virtual memory space – no special instructionsOS does not provide mutual exclusion facilities, up to processes to supply
Dr. Otman Basir Winter 2006
E&CE 354: Processes 37
UNIX Semaphores
a generalization of wait and signal operationssemaphore components:– value of semaphore– process ID of last process to operate it– number of processes waiting on value to greater
than current value– number of processes waiting on value to be zero
Dr. Otman Basir Winter 2006
E&CE 354: Processes 38
UNIX Signalssoftware mechanism to inform process of asynchronous eventsimilar to HW interrupt but without prioritiessources of signals: processes, kernelsignals recognized– just after process wakes up to run– process is preparing to return from a system call
process response:– perform some default action (i.e.termination)– execute a signal handler– ignore the signal
Dr. Otman Basir Winter 2006
E&CE 354: Processes 39
Solaris
Unix concurrency mechanismsThread synchronization primitives– Mutual exclusion (mutex) locks– Semaphores– Multiple readers, single writer (readers/writer)
locks– Condition variables
Dr. Otman Basir Winter 2006
E&CE 354: Processes 40
Solaris Thread Sync Primitives
Mutual Exclusion Lockprevents more than one thread from proceeding when the lock is acquiredthread that locks mutex must be the one that unlocksdefault blocking policy is spin lockoptional interrupt-based mechanismprimitives:– mutex_enter() → acquire lock, potentially block– mutex_exit() → release lock, might unblock a
waiter– mutex_tryenter() → acquire lock if not held
already; allows busy-wait approach
Dr. Otman Basir Winter 2006
E&CE 354: Processes 41
Solaris Thread Sync Primitives [2]
Semaphoresclassical counting semaphoresprimitives:– sema_p() → decrement semaphore, potentially
block– sema_v() → increment semaphore, potentially
unblock a waiter– sema_tryp() → decrement semaphore if blocking
not needed
Dr. Otman Basir Winter 2006
E&CE 354: Processes 42
Solaris Thread Sync Primitives [3]
Readers/Writer Lockallows multiple threads with simultaneous read-only access to protected objectallows single thread with exclusive write access to locked objectallows held locks to be up/down-graded
Condition Variablesas seen before, used to wait until some condition becomes trueused in conjunction with a mutex lock
Dr. Otman Basir Winter 2006
E&CE 354: Processes 43
Windows NT Synchronizationeach synchronization object instance can be either in a signaled or unsignaled statethread can suspend on an object in an unsignaledstate– thread released when object enters signaled state
mechanism:– thread issues wait request to NT executive– uses handle of synchronization object– when object enters signaled state
• NT executive releases all thread objects waiting on that synchronized object
Dr. Otman Basir Winter 2006
E&CE 354: Processes 44
Dr. Otman Basir Winter 2006
E&CE 354: Processes 45
Windows NT Synchronization [2]mutex object functions as binary semaphore– when mutex object enters signaled state, only
one of the waiting threads is released– can be used to synchronize threads running in
different processessemaphores can be shared by threads in multiple processes – classical counting semaphorewaitable timer:– timer signals at a specific time and/or periodically