Concurrency: Deadlock and Starvation Chapter 6 E&CE 354: Processes 1
Deadlock Deadlock = situation in which every process from a set is permanently blocked, i.e. cannot proceed with execution Common cause: processes from the set either compete for system resources or communicate with each other E&CE 354: Processes 2
Reusable Resources Two categories of resources reusable, consumable Reusable resource = resource used by one process at a time and not depleted by that use Processes obtain resources that they later release for use by other processes Examples: processors, I/O channels, main/secondary memory, files, databases, and semaphores Deadlock may occur if a process holds some resources and needs resources held by others to proceed E&CE 354: Processes 3
Example of Deadlock two resources D, T E&CE 354: Processes 4
Consumable Resources Consumable 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 E&CE 354: Processes 5
Conditions for Deadlock 1. Mutual exclusion only one process may use a resource at a time 2. 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 it possible deadlock with these conditions, but might not exist with just these three E&CE 354: Processes 6
Conditions for Deadlock [2] 4. Circular wait A B A, where X Y means X waits for resource held by Y E&CE 354: Processes 7
Deadlock Prevention Alternatives Mutual 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 E&CE 354: Processes 8
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/restored Circular 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 E&CE 354: Processes 9
Deadlock Avoidance A decision is made dynamically whether the current resource allocation request could, if granted, potentially lead to a deadlock Requires knowledge of future process request E&CE 354: Processes 1
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] E&CE 354: Processes 11
Process Initiation Denial consider system with n processes and m different resources: Resource = ( R 1, R 2,, R m ) total amt of each resource in system Available = (V 1, V 2,, V m ) total amt of each resource not allocated E&CE 354: Processes 12
Process Initiation Denial [2] Claim = C C M C 11 21 n1 C C C 12 22 M n2...... M... C C C 1m 2m M nm requirement of each process for each resource Allocation A A = M A 11 21 n1 A A A 12 22 M n2...... M... A A A 1m 2m M nm current allocation E&CE 354: Processes 13
Process Initiation Denial [3] The following relationships hold: R = V + n A i i ki k = 1 for all i. All resources are either available or allocated. C ki R i, for all k, i. No processes can claim more than the total amt of resources in system A ki C ki,for all k, i. No process is allocated more resources of any type than the process originally claimed to need E&CE 354: Processes 14
Process Initiation Denial [4] define a deadlock avoidance policy that does not start a new process if its resource requirements might lead to deadlock start a new process P n+1 only if R i C ( n+ 1) i + n k = 1 C not optimal policy since it assumes the worst case: all processes make their maximum claims together ki for all i E&CE 354: Processes 15
Resource Allocation Denial One 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 E&CE 354: Processes 16
Determination of Safe State Initial state: 2 2 2 1 1 4 2 3 C-A E&CE 354: Processes 17
Determination of a Safe State P2 Runs to Completion 2 2 2 1 4 2 3 C-A E&CE 354: Processes 18
Determination of a Safe State P1 Runs to Completion 1 4 2 3 C-A E&CE 354: Processes 19
Determination of a Safe State P3 Runs to Completion 4 2 C-A E&CE 354: Processes 2
Determination of an Unsafe State E&CE 354: Processes 21
Determination of an Unsafe State 1 1 1 4 2 2 1 2 3 E&CE 354: Processes 22
Deadlock Avoidance Algorithm E&CE 354: Processes 23
Deadlock Avoidance Algorithm [2] E&CE 354: Processes 24
Deadlock Avoidance Summary Every 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 E&CE 354: Processes 25
Deadlock Detection check for deadlock either at each resource request or some longer interval depending on likelihood of deadlock use the Allocation matrix and Available vector as before define matrix Q where q ij is the amt of resources of type j requested by process i. initially all processes are unmarked the following steps performed: E&CE 354: Processes 26
Deadlock Detection Algorithm 1. mark each process with a row in Allocation matrix of all zeros 2. initialize a temp vector W to equal the Available vector 3. find i such that process i is currently unmarked and the i-th row of Q is less or equal to W. Q ik W k, for 1 k m. If no such row found, terminate algorithm 4. if such row found, mark process i and add corresponding row of allocation matrix to W, W k = W k + A ik, for 1 k m. Goto step 3 E&CE 354: Processes 27
Deadlock Detection Algorithm [2] deadlock exists iff there are unmarked processes at the end of the algorithm each unmarked process is deadlocked E&CE 354: Processes 28
Deadlock Detection Example Set W=(1) Q of P3 is less than or equal to W, thus P3 is marked W=W+(1)=(11) No other unmarked process has a row in Q that is less than or equal to W, (Terminate) deadlock E&CE 354: Processes 29
Strategies once Deadlock Detected Abort 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 E&CE 354: Processes 3
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 E&CE 354: Processes 31
Concurrency Mechanisms in OS operating systems considered Unix Solaris Windows 2 E&CE 354: Processes 32
UNIX Concurrency Mechanisms Pipes Messages Shared memory Semaphores Signals E&CE 354: Processes 33
UNIX Pipes circular buffer, allows two processes to communicate when 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 E&CE 354: Processes 34
UNIX Messages message = msg_type + a block of text msgs sent to/received from a message queue (i.e. a mailbox); queues dynamically created sender specifies msg type, receiver retrieves either by msg type or FIFO order process may suspend: on send to full queue on receive from empty queue but not if read of specific msg type fails E&CE 354: Processes 35
UNIX Shared Memory fastest form of IPC cooperating processes share common block of virtual memory each process treats shared block as part of its own virtual memory space no special instructions OS does not provide mutual exclusion facilities, up to processes to supply E&CE 354: Processes 36
UNIX Semaphores a generalization of wait and signal operations semaphore 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 E&CE 354: Processes 37
UNIX Signals software mechanism to inform process of asynchronous event similar to HW interrupt but without priorities sources of signals: processes, kernel signals 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 E&CE 354: Processes 38
Solaris Unix concurrency mechanisms Thread synchronization primitives Mutual exclusion (mutex) locks Semaphores Multiple readers, single writer (readers/writer) locks Condition variables E&CE 354: Processes 39
Solaris Thread Sync Primitives Mutual Exclusion Lock prevents more than one thread from proceeding when the lock is acquired thread that locks mutex must be the one that unlocks default blocking policy is spin lock optional interrupt-based mechanism primitives: 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 E&CE 354: Processes 4
Solaris Thread Sync Primitives [2] Semaphores classical counting semaphores primitives: sema_p() decrement semaphore, potentially block sema_v() increment semaphore, potentially unblock a waiter sema_tryp() decrement semaphore if blocking not needed E&CE 354: Processes 41
Solaris Thread Sync Primitives [3] Readers/Writer Lock allows multiple threads with simultaneous read-only access to protected object allows single thread with exclusive write access to locked object allows held locks to be up/down-graded Condition Variables as seen before, used to wait until some condition becomes true used in conjunction with a mutex lock E&CE 354: Processes 42
Windows NT Synchronization each synchronization object instance can be either in a signaled or unsignaled state thread can suspend on an object in an unsignaled state 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 E&CE 354: Processes 43
E&CE 354: Processes 44
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 processes semaphores can be shared by threads in multiple processes classical counting semaphore waitable timer: timer signals at a specific time and/or periodically E&CE 354: Processes 45