Sufficient and necessary conditions for deadlock, deadlock prevention, deadlock avoidance, deadlock detection and removal

2.19.2 Conditions for deadlock

• Requirements
• Mutually exclusive: only one process can use one resource at a time
• Occupy and wait: continue to occupy existing resources while the process is waiting for other resources
• Non-preemption: A process cannot force a process occupied by another process
• Sufficient conditions
• Circular waiting: There is a closed process chain, and each process occupies at least one resource required by the next process in the chain

2.19.3 Resolution of deadlock

• Deadlock prevention: one of the four conditions to prevent deadlock
• Deadlock avoidance: prevent the emergence of loop waiting
• Deadlock detection and removal

2.20 Deadlock Prevention

• Indirect method: one of the three necessary conditions to prevent deadlock
• Prevent mutual exclusion: cannot prevent
• Prevent possession and waiting: require the process to request all required resources at one time (low efficiency, need to estimate the required resources)
• Prevent non-preemption: a process that occupies resources requests resources, but then releases occupied resources or the operating system requires another process to release resources (a structure that can easily save the resource state is required)
• Direct method: prevent the emergence of loop waiting
• Prevent cyclic waiting: define an order for requesting resources, all processes' requests for resources must be made strictly in the order of increasing resource number (inefficient)

2.21 Deadlock avoidance

• Avoid entering an unsafe state
• Compared with deadlock prevention: allow three necessary conditions
• Dynamic check: Check whether the result of the process applying for resources is safe during the running process, if it will deadlock, it will be blocked, otherwise it will be allocated
• Two ways to avoid deadlock
• Resource allocation rejection: if a process increases the resource request causing a deadlock, the request is rejected
• Process start rejection: if a process request causes a deadlock, refuse to start the process

2.21.1 Banker's Algorithm

It is a resource allocation rejection strategy, proposed by Dijkstra in 1965

thought

When a user applies for a group of resources, the system judges whether it is still in a safe state after the allocation, if so, the allocation is allowed, otherwise it is not allocated, blocking the user process

Safe state

There is at least one security sequence for resource allocation. Allocating resources according to this sequence can end without causing deadlock. Correspondingly, the absence of a security sequence means an insecure state.

Determination of the safe state

1. Claim matrix (hereinafter referred to as C matrix): the number of resources each process claims
2. Allocation matrix (hereinafter referred to as A matrix): the number of resources that have been allocated to each process
3. CA matrix: also known as Request matrix: the number of resources needed for each process
4. Resource vector (hereinafter referred to as R vector): the initial total amount of various resources
5. Available vector (hereinafter referred to as A vector): the remaining available amount of various resources

method:

1. Check whether the current A vector can satisfy one row of CA
2. If satisfied, add the corresponding row of the A matrix to the A vector, continue with 3, otherwise it is not safe
3. Repeat 1
4. CA is 0 to get the security sequence

Illustration:

Get the security sequence as P2, P1, P3, P4

• The security sequence is not unique, multiple sequences can be tried when the A vector satisfies the CA multi-line
• The safe state is not necessarily deadlocked. In the safe state, it will deadlock if the allocation is not in accordance with the safety sequence.
• Not all unsafe states are deadlock states

//全局数据结构
struct state {
    
    
	int resource [ m ] ;
	int available [ m ];
	int claim [ n ][m ] ;
	int alloc [ n ][m ] ;
}

//资源分配算法主体
if (alloc [ i,* ] + request [*]> claim [ i,* 〕)
	<error >;					/*total request > claim* /
else if (request [ * ] > available [ * ])
	<suspend process >;
else {						/*simulate alloc */
	<define newstate by :
	alloc [ i,* ]= alloc [ i,* ]+request [ * ];
	available [*] = available [ * ] - request [* ] >;
}
if (safe ( newstate ) )
	< carry out allocation >;
else {
    
    
	<restore original state >;
	<suspend process >;
}

//银行家算法测试安全性
boolean safe (state s) {
    
    
	int currentavail[m];
	process rest [<number of processes>];
	currentavail = available;
	rest = {
    
    all processes};
	possible = true;
	while (possible) {
    
    
		<find a process Pk in rest such that
			claim [k,* ] - alloc [k,* ] <= currentavail;>
		if (found) {
    
    		/*simulate execution of Pk */
		currentavail = currentavail + alloc [ k,*];
		rest = rest - {
    
    Pk};
		}
		else possible = false;
	}
	return ( rest ==null );
}

2.21.2 Evaluation of deadlock avoidance

• advantage
• No need for preemption and rollback in deadlock prevention
• Less restrictive than deadlock prevention
• Disadvantage
• Must first get the resources requested by each process declaration, that is, there must be a Claim matrix
• The order of execution of the process must be unrequired, otherwise it cannot follow the safe sequence
• The number of allocated resources must be fixed
• The process that holds the resource cannot exit

2.22 Deadlock detection and release

2.22.1 Algorithm steps

1. Mark all zero rows in A matrix
2. Initialize W vector = A vector
3. Find the process row with subscript i in the CA matrix. It is not marked and this row<=W vector. If it is not found, terminate the algorithm
4. If you find such a row, mark the process i, add the corresponding row in the A matrix to the W vector, and return 3.
5. If and only when 3 is terminated, there are still unmarked processes, and there is a deadlock. Unmarked processes are deadlocked.

2.22.1 Resource allocation map detection method

Simplification of resource allocation diagram

1. Find the node Pi that satisfies all the requests, eliminate all its request and distribution edges, and make it an isolated node
2. Repeat 1 until it cannot be simplified
   

Example

If it can be completely simplified, there is no deadlock. If it
cannot be completely simplified, there is a deadlock (as shown below)

2.22.2 Deadlock Release

1. Undo the deadlock process until the deadlock no longer exists
2. Rollback, fall back to certain checkpoints defined previously, restart all processes
3. Preemption, continuous preemption until there is no more deadlock

So which processes are withdrawn? Which process resources should be seized?
Selection principle: less output, long remaining time, low priority, less CPU time consumption so far

2.22.3 Comparison of three strategies