Learn Software Development » Deadlock

Overview Of Mutual Exclusions in Operating Systems

ashish — Tue, 25 Aug 2009 14:29:40 +0000

A way of making sure that if one process is using a shared modifiable data, the other processes will be excluded from doing the same thing.
Formally, while one process executes the shared variable, all other processes desiring to do so at the same time moment should be kept waiting; when that process has finished executing the shared variable, one of the processes waiting; while that process has finished executing the shared variable, one of the processes waiting to do so should be allowed to proceed. In this fashion, each process executing the shared data (variables) excludes all others from doing so simultaneously. This is called Mutual Exclusion.
Mutual exclusion (often abbreviated to mutex) algorithms are used in concurrent programming to avoid the simultaneous use of a common resource, such as a global variable, by pieces of computer code called critical sections. A critical section is a piece of code where a process or thread accesses a common resource. The critical section by itself is not a mechanism or algorithm for mutual exclusion. A program, process, or thread can have critical section in it without any mechanism or algorithm, which implements mutual exclusion.
Examples of such resources are fine-grained flags, counters or queues, used to communicate between code that runs concurrently, such as an application and its interrupt handlers. The problem is acute because a thread can be stopped or started at any time.

How Mutual Exclusion is Done ?
We need to stop the two threads from working on the same data at the same time. The most common way to do this today is by using locks. A lock can be either locked or unlocked. As long as you do not forget to lock or unlock the door, this algorithms guarantees mutual exclusion and protects the so called critical region.
C:
1. omp_set_lock (&my_lock);
2. i++;
3. omp_unset_lock (&my_lock);
Actually, the lock needs to be initialized beforehand and destroyed sometime afterwards as well, but that’s not too difficult either.
C:
1. #pragma omp critical
2. {
3. i++;
4. }
Or even simpler, like this:
C:
1. #pragma omp atomic
2. i++;
This basically does the same thing, except you do not need to worry about initialization and destruction of the lock and you cannot forget to unlock the mutex accidentally.

Overview of Race Conditions in Operating Systems

ashish — Tue, 25 Aug 2009 14:02:51 +0000

A race condition happens when a system depends on something being done outside of its control before the system reaches a point where it needs to use the results of that something, and there’s no way to guarantee that that something will actually be finished when the system needs it.
For example, suppose there’s a person who runs a program every morning that prints letters that have been queued throughout the previous day. There’s another person in another department who runs a program that queues a letter, and then offers to let the person modify it while it’s sitting in the printing queue. If the person runs this program too early in the day (before the printing program gets run), they’re essentially in a “race” to finish their work before the printing program runs.

Symptoms Of Race Condition :

The most common symptom of a race condition is unpredictable values of variables that are shared between multiple threads. This results from the unpredictability of the order in which the threads execute. Sometime one thread wins, and sometime the other thread wins. At other times, execution works correctly. Also, if each thread is executed separately, the variable value behaves correctly.
While many different devices are configured to allow multitasking, there is still an internal process that creates a hierarchy of functions. In order for certain functions to take place, other functions must occur beforehand. While the end user perceives that all the functions may appear to be taking place at the same time, this is not necessarily the case.
One common example of a race condition has to do with the processing of data. If a system receives commands to read existing data while writing new data, this can lead to a conflict that causes the system to shut down in some manner. The system may display some type of error message if the amount of data being processed placed an undue strain on available resources, or the system may simply shut down. When this happens, it is usually a good idea to reboot the system and begin the sequence again. If the amount of data being processed is considerable, it may be better to allow the assimilation of the new data to be completed before attempting to read any of the currently stored data.

Deadlock – Algorithms

ashish — Sun, 25 May 2008 05:12:41 +0000

BANKER’S ALGORITHM

Consider an example:

There are four customers: A, B, C and D, which are analogous to four processes.
The credit unit is like the resource
The banker himself is the OS
Assume each credit unit = Rs. 1000.

Not all customers need their maximum credit immediately. Hence only 10 credit units are reserved.
Process Current Max. Free = 10
A 0 6 B 0 5 C 0 4 D 0 7

How does the Algorithm Work?

When a new process (customer) enters the system, it (he) must declare the maximum number of instances of each resource type (credit units) that it (he) may need. This number may not exceed the total number of resources (credit units) in the system. When a user (customer) requests a set of resources (credit unit), the system must determine whether the allocation of these resources will leave the system in a safe state. If it will,
the resources are allocated; otherwise, the process must wait until some other process releases enough resources. Consider current allocation to various processes is as shown below.
Process Current Max. Free = 2
A 1 6 B 1 5 C 2 4 D 4 7
Would the System be in a Safe State?
‘C’ requests 2 additional units and gets them. It then runs to completion and frees all the resources it has.
Process Current Max. Free = 4
A 1 6 B 1 5 C 0 – D 4 7
Now either ‘B’ or ‘D’ can request and run to completion. Assume ‘B’ requests 4 additional units and gets them. It then runs to completion and frees all its resources. Process Current Max. Free = 5
A 1 6 B 0 – C 0 – D 4 7
Now ‘D’ runs and requests 3 additional resources and gets them. It then runs to completion and releases all its resources.Process Current Max. Free = 9
A 1 6 B 0 – C 0 – D 0 -
Finally ‘A’ runs and requests 5 additional resources and gets them. It then runs to completion and releases all its resources. Process Current Max. Free = 10
A 0 – B 0 – C 0 – D 0 -
Here is the complete banker’s algorithm:

Several data structures must be maintained to implement banker’s algorithm. Let n be the number of processes and m be the number of resource types. The data structures needed are:
• Available : A vector of length m indicates number of available resources of each type. If Available[j] = k, there are k instances of resource type Rj available.
• Max : A n*m matrix defines the maximum demand of each process. If Max[i,j]=k, then Pi may request at most k instances of resource type Rj.
• Allocation : An n*m matrix defines the number of resources of each type currently allocated to each process. If Allocation[i,j]=k, then process Pi is currently allocated k instances of resource type rj.
• Need : An n*m matrix indicates the remaining resource need of each process. If Need[i,j]=k, then Pi may need k more instances of resource type Rj to complete its task. Need[i,j]=Max[I,j] – Allocation[I,j].

After defining the data structures, algorithm moves into two phases :
• Safety Algorithm
• Resource Request Algorithm

SAFETY ALGORITHM

The safety algorithm is for finding out whether or not a system is in a safe state. It is described below:

1. Let work and finish be vectors of length m and n
respectively. Initialize work = Available and Finish[I] = false for all I = 1, 2, …, n.
2. Find an I such that both
• Finish[I] = false
• Needi <= work
If no such I exists, go to step 4.
3. Work = work + allocationi
finish[I] = true
go to step 2

4. If finish[I] = true for all I, then the system is in a safe state. This algorithm may require an order of m * n2 operations to decide whether a state is safe.

RESOURCE – REQUEST ALGORITHM

Having determined that the system is safe, this algorithm grants the requested resources to the process. Let Request i be the request vector for process Pi. If Request[j] = k, then process Pi wants k instances of resource type Rj. When this request is made, the following actions are taken:

1. If request I <= need I, then go to step 2. Otherwise raise an error condition because the process has exceeded its maximum claim.
2. If request I <= available, go to step 3. Otherwise, Pi must wait since the resources are not available.
3. Have the system pretend to have allocated the requested resources to process Pi by modifying the state as follows:
a. Available = available – request I
b. Allocation = allocation + request I
c. Need I = Need I – request I
4. Call the Safety algorithm. If the state is safe, then transaction is completed and process Pi is allocated the resources. If the new state is unsafe, then Pi must wait and the old resource allocation state is restored.

Deadlock avoidance and prevention

ashish — Sun, 25 May 2008 05:11:58 +0000

Deadlock Prevention

In order to prevent deadlock, the system is built in such a way that no deadlock occurs. Make sure that at least one of the four conditions in which deadlock can occur does not exist.

Attacking Hold and wait : In order to ensure that hold and wait condition never occurs, two protocols can be used:
• Make all the requests in the beginning. All or nothing policy.
• A process should request a resource only when it has none.

Attacking Pre-emption : To avoid this situation, the protocol that can be used is if a process that is holding some resources requests another resource that cannot be allocated immediately, then all the resources currently held are released. These released resources gets added to the list of resources for which process is waiting.

Or, if process requests a resource, check their availability, if available allocate them. If not, check if they are allocated to other process that is waiting for additional resources. If so, preempt the desired resources from waiting process and allocate to requesting process. If not available, requesting process should wait.

Attacking Mutual Exclusion : This condition holds for nonsharable resources e.g printer. Sharable resources do not require a mutually exclusive access, and thus cannot be involved in a deadlock.

Attacking Circular Wait Condition : To prevent this condition, use the following protocol:
• Order all the resources.
• Make sure that the requests are issued in such a way so that there are no cycles present in the graph.
• Resources can be requested only in an increasing order i.e. we cannot request a resource whose number is less than any you may be holding.

Deadlock Avoidance

It turns out that there are algorithms you can use to avoid deadlock. The principle is as follows: Whenever you are about to make an allocation, you can run this algorithm and see if making that allocation would lead to a deadlock.This seems like
the ideal method but has some important drawbacks.Let us see what these drawbacks are:
1. The algorithms are not that fast and there is a lot of overhead in running them before every resource allocation. The OS might be allocating resources hundreds of times a second.
2. The algorithms assume that processes know their maximum resource needs a priority. But this is often not the case.
3. They (processes) assume that they know what resources are available in the system. Hardware can go down and resources can become unavailable. This could lead to unpredictable deadlock situations.
In short, in deadlock avoidance method, the OS must be given in advance additional information concerning which resources a process will request and use during its lifetime.

Here are some salient points of the algorithm working nature:
• The deadlock avoidance algorithm dynamically examines the resource allocation state to ensure that there can never be a circular-wait condition.
• A state is safe if the system can allocate resources to each process (up to its maximum) in some order and still avoid deadlock.
• A system is in a safe state only if there exists a safe sequence.
• A safe state is not a deadlocked state but a deadlocked state is an unsafe state.
• An unsafe state may lead to a deadlock.

Safe State

A state is safe if the system can allocate resources to each process in some order and avoid deadlock. A safe sequence is a sequence of processes
for the current allocation state if for each Pi, the resources that Pi can still request can be satisfied by the currently available resources plus the resources held by all Pj with j <= i . In this situation, if the resources that process Pi needs are not immediately available, then Pi can wait until all Pj have finished. When they have finished, Pi can obtain all its needed resources, complete its designated task, return its allocated resources, and terminate. When Pi terminates, Pi+1 can obtain its needed resources and so on. If no such sequence exists, then the system state is said to be unsafe.

Resource Allocation Graph Algorithm

Deadlocks can be described more precisely in terms of directed graphs called a system resource allocation graph. A directed edge Pi -> Rj is called request edge which signifies that process Pi requested an instance of resource Rj. A directed edge Rj->Pi is called assignment edge which signifies that resource Rj is allocated to process Pi. A directed edge Pi–>Rj is called a claim edge which indicates that process Pi can request resource Rj at some time in future. When process Pi requests resource Rj the claim edge becomes a request edge. Similarly, when a resource Rj is released by Pi, the assignment edge is converted to a claim edge.

Suppose process P1 requests resource Rj. Request is granted only if this request edge is converted to an assignment edge, hence not resulting in the formation of a cycle in resource allocation graph. Hence the process has to wait for the resource.

Deadlock situation

ashish — Sun, 25 May 2008 05:11:06 +0000

A deadlock is a situation wherein two or more competing actions are waiting for the other to finish, and thus neither ever does. In the computing world deadlock refers to a specific condition when two or more processes are each waiting for another to release a resource, or more than two processes are waiting for resources in a circular chain.

Under the normal mode of operation, a process may utilize a resource in the following sequence:

Request – when a process needs some resource, it requests for it. Process has to wait if resource is busy.
Use – The process should operate on the resource.
Release – After using, process should release the resource.

Conditions In Which Deadlock Can Arise

• Hold and Wait : As the name suggests, a process is holding a resource and also waiting for some other resources that are held by other process.
• No Preemption : A resource can be released only voluntarily by the process holding it, after that process has completed the task.
• Mutual Exclusion : It means only one process can use the resource at a time. If some other process requests that resource, the requesting process has to wait until the resource is released.
• Circular Condition : There must exist a state of waiting processes in which process P0 is waiting for a resource that is held by P1, P1 waiting for resource held by P2, Pn-1 waiting for resource held by Pn an Pn is waiting for resource held by P0.