Synchronization and Deadlocks

Synchronization and Deadlocks
Lecture 4 Synchronization and Deadlocks

Lecture Highlights Introduction to Process Synchronization and Deadlock Handling Synchronization Methods Deadlocks What are deadlocks The four necessary conditions Deadlock Handling

Synchronization and Deadlock Handling An Introduction
Concurrent access to shared data can result in data inconsistency. To ensure orderly execution of processes , the operating system provides mechanisms for job synchronization and communication. A deadlock state is a state of indefinite wait by one or more processes for an event that can be triggered only by one of the waiting processes. Operating system also provides mechanisms to ensure that jobs do not get stuck in a deadlock, forever waiting for each other.

Process Synchronization An Example
Consider two processes P1 and P2: Process P1 increments the counter counter := counter + 1 Process P2 decrements the counter counter := counter – 1 If both are run one after the other, the final value of the counter (counter could be a memory location for example) should remain the same regardless of the order in which they are run. One increments it, the other decrements it. No change. The increment and decrement statements of P1 and P2 translate to machine code as shown on the following slide.

P1 (increment) reg1 := counter reg1 := reg1 +1 counter := reg1 P2 (decrement) 4. reg2 := counter 5. reg2 := reg2 –1 6. counter := reg2

Now consider the two processes run concurrently. Consider the situation in which the statements are run in the following order: 1, 2, 4, 3, 5, 6. The corresponding sequence of code thus, becomes: 1. reg1 := counter 2. reg1 := reg1 + 1 4. reg2 := counter 3. counter := reg1 5. reg2 := reg2 – 1 6. counter := reg2

If we start with the counter value as counter:=5, the above sequence of code with substituted values becomes: 1. reg1 := 5 2. reg1 := 5 + 1 4. reg2 := 5 3. counter := 6 5. reg2 := 5 – 1 6. counter := 4

Thus, we see from the preceding sequence of code that the counter will not be unchanged upon completion but will be rather decremented by 1. The above stated problem arose because both sections of code constitute critical sections and these critical sections interleaved. The critical sections must be run atomically.

Process Synchronization Critical Section and Race Condition
A Critical Section is a part of a process that accesses shared resources. Two processes should not be allowed to enter their critical sections at the same time, thus preventing the above problem. The situation where several processes access and manipulate the same data concurrently, and the outcome of the execution depends on the particular order in which the access takes place, is called a race condition.

Process Synchronization More on Critical Section
Important points to note about critical sections: A critical section must be run atomically. This means that the section is executed either as a whole or not at all. Once the critical section of a process begins, it must be completed or rolled back. Mutual exclusion of more than one critical section must be ensured Mutual exclusion is ensured by using pieces of code to block a process that attempts to run its critical section while the critical section of another process is being executed. The process is unblocked when the other process’s critical section completes execution. This is known as Sleep and Wakeup.

Process Synchronization Synchronization Methods
There are three ways to implement Sleep and Wakeup in order to synchronize processes. The three synchronization methods are: Semaphores Monitors Message Passing

Synchronization Methods Semaphores
The use of Semaphore involves the use of a new variable which keeps track of whether or not a critical section is being executed. Before any process can enter a critical section, they must check this variable and if it determines that a critical section is being executed, the process is put into a sleep state until the variable is reset. Critical Section 1 entry section exit section Critical Section 2 entry section exit section

Each critical section is appended by entry code and exit code (shown below): Entry Code: P(s) { while s<=0 { } // sleep (do noop) s = s-1; } Exit Code: V(s) { s = s + 1; }

The above semaphores are used as following: P1 Critical Section P(s) V(s) P2 Critical Section P(s) V(s) The following slide provides a run through to give a better idea of how semaphores work. We’ll start off with an initial value of s = 1.

Synchronization Methods Semaphores – a sample run through
The sample run-through: s = 1 P1 begins execution – Entry code P(s) is called s = 0 While P1 is executing, P2 attempts to start execution – Entry code P(s) is called Since s = 0, Entry code for P2 goes into a continuous loop, effectively blocking the critical section of P2 P1 completes execution – Exit code V(s) is called Entry code of P2 breaks out of it’s loop, decrements s and begins execution

Semaphores Pre-determining order: Some Examples
We can also employ the above semaphores to pre-determine an order in which certain processes will be executed. For example, consider three processes P1, P2, P3 and we wish their critical sections to be run in the order P1, P2 and then P3. ( )

Semaphores Pre-determining order – Example 1
Critical Section { } V(s) P2 P(s) V(t) P3 P(t) s = 0, t = 0 The above set up implements the order of execution of critical sections in order of P1, P2 and then P3.

The following set up implements the situation where P1 executes first followed by P2 and P3 in no particular order 3 P1 Critical Section { } V(s) P2 P(s) P3 s = 0

The following set up implements the situation where P1 and P2 are to be executed before P3 without imposing a particular order on P1 and P2. 1 3 2 P1 Critical Section P(s) V(s) V(t) P2 P3 P(t) { } s = 1, t = -1

Let’s try: i.e. P1 executes first followed by P2 and P3 without imposing an order. When P1, P2 and P3 are done, P4 executes. 2 3 P1 Critical Section { } V(s) P2 P(s) V(t) s = 0, t = -1 P4 P(t) P3

Let’s try: i.e. P1 and P2 have to execute before P3 and P4 (without imposing an order within the two pairs). One possible implementation is shown below. 1 2 3 4 P1 Critical Section P(s) V(s) V(t) P2 s = 1, t = -1 P4 P(t) P3

Synchronization Methods Monitors
Monitors offer a higher level solution that offer both synchronization and mutual exclusion where semaphores required use of low-level system calls (these involve risk of deadlock). Many programming languages offer built-in structures that serve as monitors. Only one process may execute a function within a monitor at any given time. Hence all critical section are called from within a monitor thus allowing only one critical section to run at any given time.

Synchronization Methods Difference b/w Semaphores & Monitors
A monitor is different from a semaphore because it provides a kind of scheduling queue for critical sections that arrive to be processed. It not only blocks other critical sections while one is already being processed but also puts them in a wait state and processes them in the order in which they arrive.

Synchronization Methods Message Passing
Message-passing is a technique whereby processes communicate. This technique involves moving packets of information between processes by the operating system. Both synchronization and mutual exclusion can be achieved by this method.

Synchronization Methods Comparison at a glance
The following table shows a comparison between the three synchronization methods: Implementation Synchroniza- tion Mutual Exclusion Advantages Disadvantages Semaphores  ·Low-level implementation ·Can cause deadlock Monitors High level implementation · Message Passing

Deadlocks What are deadlocks
A deadlock state is a state of indefinite wait by one or more processes for an event that can be triggered only by one of the waiting processes. Such an event is commonly termed as a resource. The resource could be tangible such as an I/O resource or intangible e.g. shared data.

Deadlock Examples Example1: Deadlock due to semaphore usage
The implementation of a semaphore may result in a deadlock situation where two or more processes are waiting indefinitely for an event that can be caused by only one of the waiting processes. In the scenario below, both P1 and P2 are accessing the two semaphores ‘s’ and ‘t’. Suppose that P1 executes P(s), and then P2 executes P(t). When it executes P(t), it must wait until P2 executes V(t). Similarly, when P2 executes P(s), it must wait until P1 executes V(s). Since these operations cannot be executed, P1 and P2 are deadlocked. S = 1, t = 1 P(s) P(t) P(t) P(s) P1 Critical Section P2 Critical Section V(s) V(t) V(t) V(s)

Deadlock Examples Example2: Deadlock due to use of shared variables
request edge assignment edge Resource 1 Resource 2 P2 assignment edge request edge

Deadlocks The four necessary conditions
The four necessary conditions for a deadlock to occur are: Mutual exclusion of resources Inability of a resource to be used by more than one process Hold-and-wait A process holds a resource while waiting for another one No pre-emption The system is incapable of grabbing a resource from a process Circular Wait

Deadlock Handling Four methods for handling deadlocks
The four method for dealing with the deadlock problem are: Prevention Detection and Recovery Avoidance Ignoring the condition Ignoring deadlocks is by far the most widely used method (it will become obvious from the ensuing discussion why).

Deadlock Handling Prevention
Deadlock prevention is a set of methods for ensuring that atleast one of the necessary conditions cannot hold. Mutual Exclusion – this cannot be stopped since it is the nature of the resource Hold and Wait – this can be stopped by never assigning a resource to a process unless all the other needed resources are available. However, it suffers from possible starvation of processes. Moreover, resource utilization may be low, since many of the resources may be allocated but unused for a long period.

Deadlock Handling Prevention (contd.)
No preemption – If a process that is holding some resources requests another resource that cannot be immediately allocated to it, then all resources currently being held are preempted to stop this condition. As evident, it also suffers from potential starvation. Circular Wait – One way to ensure that the circular-wait condition never holds is to impose a total ordering of all resource types, and to require that each process requests resources in an increasing order of enumeration. The example on the following slide illustrates the same.

Deadlock Handling Prevention (contd.)
Let us assume that the set of resource types R includes tape drives, disk drives, and printers and the function F (for enumeration) is defined as follows: F(tape drive) = 1 F(disk drive) = 5 F(printer) = 12 If any one of the following protocols are used , the circular wait condition cannot hold. Each process can request resources only in an increasing order of enumeration. For example, a process that wants to use the tape drive and printer at the same time must first request the tape drive and then the printer. Whenever, a process requests an instance of resource type Rj, it has released any resources Ri such that F(Ri)  F(Rj).

Deadlock Handling Detection and Recovery
In this environment, the system must provide: An algorithm that examines the state of the system to determine whether a deadlock has occurred An algorithm to recover from the deadlock However, it is important to realize that detection and recovery scheme requires overhead that includes not only the run-time costs of maintaining the necessary information and executing the detection algorithm, but also the potential losses inherent in recovering from deadlock.

Deadlock Handling Detection and Recovery – Steps
A deadlock detection and recovery algorithm involves the following steps: Reduce P-R graph to wait-for graph Find cycles in the graph Determine non-redundant cycles Determine minimum number of preemptions The following example illustrates the above steps.

Deadlock Handling Detection and Recovery – Step 1
Reduce P-R graph to wait-for graph We obtain the wait for graph from the resource allocation graph by removing the nodes of type resource and collapsing the appropriate edges. A cycle in the wait-for graph implies a deadlock state. More precisely, an edge from Pi to Pj in a wait-for graph implies that process Pi is waiting for process Pj to release a resource that Pi needs. An edge Pi  Pj exists in a wait-for graph if and only if the corresponding resource-allocation graph contains two edges Pi  Rq and Rq  Pj for some resource Rq. The following slide shows a visual presentation of this step for an example.

Reduce P-R graph to wait-for graph P1 P3 P2 P1 P3 P2 R2 R1 R3

Deadlock Handling Detection and Recovery – Step 1 Complexity
Suppose, we have m resources n processes For each ordered pair of the processes, we have to check if there exists a wait-for relationship for each resource. Here, the number of ordered pair of resources = nP2 = n!/(n-2)!  n2 I.e. for one resource the order of operations is O(n2)  for m resources the order of operations is O(mn2) Step 1 complexity is O(mn2)

Find cycles in the wait-for graph Cycles in this graph are: 1231 2312 3123 121 212 131 313 P1 P3 P2

The complexity of this step can be better understood by the tree diagram: The tree structure represents the wait-for graph. Each of the yellow nodes has a degree of n-1 where, n is the number of processes. The tree is traversed using the DFS algorithm. Consequently, all of the nodes are visited n times except for the leaf nodes which are visited only once. Thus the number of operation  n (n-1) = O(n2) Step 2 complexity is O(n2)

Determining non-redundant cycles 1231 2312 3123 121 212 131 313 123 12 13 Take out redundant strings

This step can be implemented as part of Step2. In other words, while we are traversing the graph and finding cycles, we can also compare them with previously found cycles and finally take the cycles that are common to the maximum number of cycles. Thus, the complexity of this step is built in to the step2 complexity of O(n2).

Determine the minimum number of preemptions: Here, we need two preemptions. Preempting 12 and 13 will break all the cycles. 123 12 13 P1 P3 P2

Deadlock Handling Detection & Recovery–Summary
As we have seen throughout the discussion, detection and recovery is a very expensive proposition in terms of time complexity. Moreover, there is also the potential of incurring losses inherent in recovering from deadlock.

Deadlock Handling Avoidance
A deadlock avoidance algorithm dynamically examines the resource allocation state to ensure that there can never be a circular-wait condition. The resource allocation state is defined by the number of available and allocated resources, and the maximum demands of the processes.

Deadlock Handling Avoidance – Safe/Unsafe states
A state is safe is the system can allocate resources to each process in some order and still avoid a deadlock. More formally, a system is in a safe state only if there exists a safe sequence. If no safe sequence exists, then the state is said to be unsafe. unsafe deadlock safe

Deadlock Handling Avoidance – An Example
Consider a system with five processes P0 through P4 and three resource types A, B and C. Resource type A has 10 instances, B has 5 instances and C has 7 instances. Suppose that at time T0, the following snapshot of the system has been taken: Allocation Max Available A B C P0 P1 P2 P3 P4

Given the snapshot, the following matrix specifies the need of all the processes: Here, we can claim that the system is currently in a safe state. Indeed, the sequence <P1, P3, P4, P2, P0> satisfies the safety criteria. (The safety sequence basically implies that the resource needs of the processes can be satisfied in the specified sequence such that all resource needs of all the processes are met.) Need A B C P0 P1 P2 P3 P4

Suppose now that process P1 requests one additional instance of resource type A and two instances of resource type C, so Request1 = (1,0,2). To decide whether this request can be immediately granted, we first check that Request1  Available (I.e. (1,0,2) (3,3,2), which is true. We then pretend that this request has been fulfilled, and we arrive at the following new state: Allocation Need Available A B C P0 P1 P2 P3 P4

Now, we must determine whether this new state is safe. To do so, we execute our safety algorithm and find that the sequence <P1, P3, P4, P0, P2> satisfies the safety requirement. Hence, we can immediately grant the request of process P1. You should be able to see, however, that when the system is in this state, a request for (3,3,0) by P4 cannot be granted, since the resources are not available. A request for (0,2,0) by P0 cannot be granted, even though the resources are available, since the resulting state is unsafe.

Deadlock Handling Avoidance – Complexity
If we consider a system with multiple of one resource and n processes, we need n operations to step through the processes while determining the safety sequence provided the processes are sorted in terms of the resource requirements. ( sorted order can be maintained at a cost of O(logn) Thus, if we scale up the system to have m resources, the complexity of the Banker’s algorithm becomes O(mn)

Deadlock Handling Avoidance – Parameters Involved
The parameters worthy of study in this module are: Total number of processes Total number of available resources Maximum number of resources required by the processes

Deadlock Avoidance Effect of Involved Parameters
Effect of total number of processes An increase in the number of processes will increase the number of requests for resources. Effect of total number of available resources More the number of available resources, more requests can be granted since for the same requirement there are more resources available. Effect of maximum number of resources required by the processes This parameter is directly linked to the number of requests and thus, determines the demand for the resources required. More the resources required, there is more probability of declined requests.

Deadlock Avoidance Performance Measures
Performance shall be quantified in terms of: Rejection rate / Denial rate It is the percentage of rejected or denied requests over the total number of requests. A higher rejection rate by all means is a sign of poor system performance.

Deadlock Avoidance Denial Percentage Over Time
When a system starts, initially all requests are granted, as the resources are available and the rejection rate is null at this point. As more resources are allocated, the available resource number lowers and thus process requests are rejected if they lead to an unsafe state. Rejection increases as more and more resources are allocated. Then comes the phase when enough resources have been granted to meet the maximum need of some processes. At this time, these processes whose maximum resource needs have been met start releasing the resources. Thus, the available resources start increasing and consequently the denial rate decreases finally coming back to the state of null rejection. As is evident from the sample data and graph in the following slides, the shape of the rejection rate over time graph closely resembles a normal curve.

Deadlock Avoidance Denial Percentage Over Time (Sample data)
Time Window (5 time units) Rejection Rate (%) 0 to 5 5 to 10 10 to 15 20 15 to 20 60 20 to 25 25 to 30 80 30 to 35 35 to 40

Deadlock Avoidance Denial Percentage Over Time (Sample graph)

Deadlock Handling Methods Implementation
As part of Assignment 2, you’ll implement three deadlock modules: a graph reduction algorithm, a deadlock detection algorithm and a deadlock avoidance module within an operating system satisfying the given requirements. (For complete details refer to Assignment 2) We’ll see a brief explanation of the assignment in the following slides.

Graph Reduction Algorithm Implementation Details
A graph reduction algorithm reduces process-resource allocation graphs into process dependency graphs Input: Processes Resources Relations Output:

Graph Reduction Algorithm Sample Screenshot of Results

Deadlock Detection Algorithm Implementation Details
Input: Process dependency graph (processes & relations), i.e. the output from the last module Output: List of deadlocked processes (print non-redundant cycles only). Bonus: Determine the minimum number of preemptions required to break all the deadlocks in the system and print the requests/assignments to be preempted.

Deadlock Detection Algorithm Sample Screenshot of Results

Deadlock Avoidance Module Implementation Details
Deadlock Avoidance Module (using one resource type): Input: Table of Table of resources, current usage and maximum usage One request Output: Safe or unsafe state determination This should be a dynamic algorithm, I.e., allow user to enter a set of consecutive requests and the algorithm would allow them or not based on safety. Implement an option allowing requests to be generated one at a time from different processes randomly.

Deadlock Avoidance Module Implementation Details
Once you’ve implemented the deadlock avoidance algorithm, analyze and do a statistical analysis for the behavior of the denial percentage (percentage of denied requests) versus some parameters like: Total number of resources Maximum number of needed resources per process Number of processes

Deadlock Avoidance Module Sample Screenshot of Simulation

Deadlock Avoidance Sample Data & Analysis from Simulation
Rejection Rate vs. Total number of resources Total number of processes = 4 Max Resource per Process P MaxR Total # of available resources Rejection Rate 6 33.33 7 28 8 18.18 9 14.28 ANALYSIS: The statistics clearly indicates that as the number of available resources increases, the rejection rate steadily moves down. In other words, more and more requests are granted.

Deadlock Avoidance Conclusions from Sample Simulation
The rejection rate is controlled by the dynamic mix of number of processes, number of available requests as well as maximum resource requirement per process. Another crucial determining factor is the order in which the requests are made. More available resources and less requesting resources improve performance in a linear manner. However, if the number of maximum resource requirement per process exceeds the number of available resources deadlock is inevitable. On the other hand, if the number of resources available is at the least equal to the sum of the maximum resource requirement per process, the system can boast of a null rejection rate.

Lecture Summary Introduction to Process Synchronization and Deadlock Handling Synchronization Methods Deadlocks What are deadlocks The four necessary conditions Deadlock Handling

Preview of next lecture
The following topics shall be covered in the next lecture: Introduction to Memory Management What is memory management Related Problems of Fragmentation, Redundancy and Synchronization Continuous Memory Allocation Scheme Parameters Involved Parameter-Performance Relationships Some Sample Results

Synchronization and Deadlocks

Similar presentations

Presentation on theme: "Synchronization and Deadlocks"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Synchronization and Deadlocks

Similar presentations

Presentation on theme: "Synchronization and Deadlocks"— Presentation transcript:

Similar presentations

About project

Feedback