Concurrency: Deadlock and Starvationpami.uwaterloo.ca/~basir/ece354/chpt6cw-web.pdf · Concurrency: Deadlock and Starvation Chapter 6. Dr. Otman Basir Winter 2006 E&CE 354: Processes

Dr. Otman Basir Winter 2006

E&CE 354: Processes 1

Concurrency: Deadlock and Starvation

Chapter 6



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



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



Example of Deadlock

two resources D, T



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



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



Conditions for Deadlock [2]4. Circular wait

A →B→A, where X →Y means X waits for resource held by Y



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



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



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



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]



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



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



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



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



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



Determination of Safe State

Initial state:

024301100222

C-A



Determination of a Safe StateP2 Runs to Completion

024301000222

C-A




024301000000

C-A




024000000000

C-A



Determination of an Unsafe State



Determination of an Unsafe State

024301201121



Deadlock Avoidance Algorithm



Deadlock Avoidance Algorithm [2]



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



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:



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



Deadlock Detection Algorithm [2]deadlock exists iff there are unmarked processes at the end of the algorithm

each unmarked process is deadlocked



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



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



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



Concurrency Mechanisms in OS

operating systems considered– Unix– Solaris– Windows 2000



UNIX Concurrency MechanismsPipes

Messages

Shared memory

Semaphores

Signals



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



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



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



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



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



Solaris

Unix concurrency mechanismsThread synchronization primitives– Mutual exclusion (mutex) locks– Semaphores– Multiple readers, single writer (readers/writer)

locks– Condition variables



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



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



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



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





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

Documents

Concurrency: Deadlock and Starvationpami.uwaterloo.ca/~basir/ece354/chpt6cw-web.pdf · Concurrency: Deadlock and Starvation Chapter 6. Dr. Otman Basir Winter 2006 E&CE 354: Processes