1.1 INTRODUCTIONA deadlock is a situation in which two or more competing actions are each waiting for the other to finish, and thus neither ever does. In an operating system, a deadlock is a situation which occurs when a process enters a waiting state because a resource requested by it is being held by another waiting process, which in turn is waiting for another resource. If a process is unable to change its state indefinitely because the resources requested by it are being used by another waiting process, then the system is said to be in a deadlock. [1]. There are two types of deadlock: Communication deadlock and Resource deadlock. Communication deadlock occurs when process A is trying to send a message to process B, which is trying to send a message to process C which is trying to send a message to A. A Resource deadlock occurs when processes are trying to get exclusive access to devices, files, locks, servers, or other resources. We will not differentiate between these types of deadlock since we can consider communication channels to be resources without loss of generality. A deadlock situation can arise if and only if all of the following conditions hold simultaneously in a system. These four conditions are known as the Coffman conditions. In Mutual Exclusion, at least one resource must be non-shareable. Only one process can use the resource at any given instant of time. In Hold and Wait or Resource Holding, a process is currently holding at least one resource and requesting additional resources which are being held by other processes. In No Preemption the operating system must not de-allocate resources once they have been allocated; they must be released by the holding process voluntarily. In Circular Wait, a process must be waiting for a resource which is being held by another process, which in turn is waiting for the first process to release the resource. [2]1.2 RELATED WORK:The various mechanisms are studied by various researchers and each time a more new techniques are developed in order to increase performance and lessen the overhead. Gupta Dhiraj and Gupta V.K. researched Approaches for Deadlock Detection and Deadlock Prevention for Distributed systems. In this paper, they discussed the methods of deadlock detection like creation of wait for graph, Path-pushing algorithms and Edge-chasing algorithms. Deadlock prevention protocols ensure that the system will never enter into a deadlock state. Ashok T. Amin and Mitzi P. Freeman researched about the proof techniques for distributed algorithms for deadlock handling. Basically deadlock handling refers to deadlock detection, resolution, and recovery. In this, we analyse that the distributed algorithms for deadlock detection can be classified based on the technique used for dissemination of dependency information, namely, Top-Down or Bottom-Up. The Top-Down algorithm was presented by Merritt and Mitchell and is widely recognized for its simplicity and elegance of its correctness proof. The Bottom-Up algorithm is a simpler version of one originally presented by Sinha and Natarajan, and later modified to correct errors by Choudhary et.al. . An efficient deadlock prevention approach for service oriented transaction processing is researched by Feilong Tanga, Ilsun Youb, Shui Yuc, Cho-Li Wangd, Minyi Guoa, Wenlong Liu. In this paper, they investigate how to prevent local deadlocks, caused by the resource competition among multiple sub-transactions of a global transaction, and global deadlocks from the competition among different global transactions. They proposed two prevention mechanisms for local deadlocks and global deadlocks, first one is Replication-based local deadlock prevention and the second one is Timestamp-based global deadlock prevention. The Replication based approach help to avoid local deadlocks, and a timestamp based approach to greatly mitigate global deadlocks for SOA environments. These two prevention mechanisms provide higher system performance than traditional resource allocation schemes. Alex G. Olson and Brian L. Evans studied the process networks for deadlock detection. The Process Network (PN) model, which consists of concurrent processes communicating over first in first out unidirectional queues, is useful for modeling and exploiting functional parallelism in streaming data applications. The PN model maps easily onto multi-processor and/or multi-threaded targets. Since the PN model is Turing complete, memory requirements cannot be predicted statically. In general, any bounded-memory scheduling algorithm for this model requires run-time deadlock detection. The few PN implementations that perform deadlock detection detect only global deadlocks. Not all local deadlocks, however, will cause a PN system to reach global deadlock. The first local deadlock detection algorithm for PN models is presented. The proposed algorithm is based on the Mitchell and Merritt algorithm and is suitable for both parallel and distributed PN implementations. K. Mani Chandy and Jayadev Misra are studied distributed deadlock detection for resource and communication models. Distributed deadlock models are presented for resource and communication deadlocks. Simple distributed algorithms for detection of these deadlocks are studied. It is show that all true deadlocks are detected and that no false deadlocks are reported. In the algorithms, no process maintains global information; all messages have an identical short length. The algorithms can be applied in distributed database and other message communication systems. Brain M. Johnston, Ramesh Dutt Javagal, Ajoy Kumar Datta presented a distributed algorithm for resource deadlock detection. A simple algorithm is presented to detect resource deadlocks in distributed databases. The proposed algorithm ensures that only one process in the deadlock cycle will detect it, thus simplifying the resolution problem. All true deadlocks are detected in finite time and no false deadlocks are reported. An informal proof of correctness of the algorithm and an example are also presented.

1.3 APPROACHES FOR DEADLOCK DETECTION AND DEADLOCK PREVENTION FOR DISTRIBUTED SYSTEMS

1.3.1 PROBLEM DEFINITION: In today environment Distributed database is mainly used by large organization for their striking features. When we develop a deadlock detection and prevention approaches for distributed database. A deadlock is a condition in a system where a process cannot proceed because it needs to obtain a resource held by another process but it itself is holding a resource that the other process needs. The same conditions for deadlocks in uniprocessors apply to distributed systems. Unfortunately, as in many other aspects of distributed systems, they are harder to detect, avoid, and prevent. Deadlocks are a fundamental problem in distributed systems. Deadlock detection is more difficult in systems where there is no such central agent and processes may communicate directly with one another. Deadlock detection and resolution is one among the major challenges faced by a Distributed System. Deadlock is a common problem in multiprocessing where many processes share a specific type of mutually exclusive resource known as a software lock or soft lock.1.3.2 SOLUTION:Gupta Dhiraj and Gupta V.K. studied Approaches for Deadlock Detection and Deadlock Prevention for Distributed systems. In this they discussed the deadlock detection techniques and present approaches for detecting deadlocks in Distributed Systems. In the non-distributed case, all the information on resource usage lives on one system and the graph may be constructed on that system. In the distributed1 case, the individual sub-graphs have to be propagated to a central coordinator. A message can be sent each time an arc is added or deleted. If optimization is needed, a list of added or deleted arcs can be sent periodically to reduce the overall number of messages sent. Deadlock detection is more difficult in systems where there is no such central agent and processes may communicate directly with one another. In this paper, we discuss deadlock detection techniques and present approaches for detecting deadlocks in Distributed Systems.Deadlock: A deadlock is a state where a set of processes request resources that are held by other processes in the set. A deadlock is a condition in a system where a process cannot proceed because it needs to obtain a resource held by another process but it itself is holding a resource that the other process needs. In above figure, Deadlock condition is shown, there are two processes P1 and P2 and two resources R1 and R2. Resource R1 is assign by process P1, held by process P2 and R2 is assign by process P2, held by process P1. Deadlock is present when the graph has cycles.Distributed Database system: A distributed database management system ('DDBMS') is a software system that permits the management of a distributed database and makes the distribution transparent to the users. Distributed database management system is software for managing databases stored on multiple computers in a network. A distributed database is a set of databases stored on multiple computers that typically appears to applications on a single database. Consequently, an application can simultaneously access and modify the data in several databases in a network. DDBMS is specially developed for heterogeneous database platforms, focusing mainly on heterogeneous database management systems (HDBMS).A database physically stored in two or more computer systems. Although geographically dispersed, a distributed database system manages and controls the entire database as a single collection of data. If redundant data are stored in separate databases due to performance requirements, updates to one set of data will automatically update the additional sets in a timely manner.

Deadlock for Distributed System: A Distributed system consists of a collection of sites that are interconnected through a communication network each maintaining a local database system. The same conditions for deadlocks in uniprocessors apply to distributed systems. Unfortunately, as in many other aspects of distributed systems, they are harder to detect, avoid, and prevent. Distributed deadlocks can occur in distributed systems when distributed transactions or concurrency control is being used.A system is deadlocked if and only if there exists a directed cycle in the wait-for Graph (WFG). If we have 3 computers 1, 2, and 3, with resources respectively, A, B, and C and D and we have three transactions T1, T2, and T3 that execute as indicate below: In the above WFD that has a directed cycle, thus we have a distributed deadlock. A deadlock is a fundamental problem in distributed systems. A process may request resources in any order, which may not be known a priori and a process can request resource while holding others. If the sequence of the allocations of resources to the processes is not controlled, deadlocks can occur.

Strategies for dealing with distributed deadlocks: Distributed deadlocks can occur in distributed systems when distributed transactions or concurrency control is being used. There are four strategies for dealing with distributed deadlocks:Ignorance: ignore the problem (this is the most common approach).Detection: let deadlocks occur, detect them, and then deal with them.Prevention: make deadlocks impossible.Avoidance: choose resource allocation carefully so that deadlocks will not occur.Approaches for deadlock detection for distributed systems: Deadlock detection requires examination of the status of process-resource interactions for presence of cyclic wait. Deadlock detection in distributed systems seems to be the best approach to handle deadlocks in distributed systems. The basic algorithm for distributed deadlock detection is as follows:Create the local wait for graph (WFG), Add possible edges obtained from other sites that may cause deadlock, The local WFG now also contains locks on remote objects and the sub transaction holding those lock, Determine the cycles, if it is to be found. There is a deadlock.Path-pushing algorithms: The basic idea underlying this class of algorithms is to build some simplified form of global WFG at each site. For this purpose each site sends its local WFG to a number of neighbouring sites every time a deadlock computation is performed. After the local data structure of each site is updated, this updated WFG is then passed along, and the procedure is repeated until some site has sufficiently complete picture of the global situation to announce deadlock or to establish that no deadlocks are present. The main features of this scheme, namely, to send around paths of the global WFG, have led to the term path-pushing algorithms.Edge-chasing algorithms: The presence of a cycle in a distributed graph structure can be verified by propagating special messages called probes along the edges of the graph. Probes are assumed to be distinct from resource request and grant messages. When the initiator of such a probe computation receives a matching probe, it knows that it is in cycle in the graph. A nice feature of this approach is that executing processes can simply discard any probes they receive. Blocked processes propagate the probe along their outgoing edges.Distributed deadlock prevention: Deadlock prevention protocols ensure that the system will never enter into a deadlock state. The basic prevention strategies are:

The strategies require that each transaction lock its entire data item before it begins execution. They impose partial ordering of all data item and require that a transaction can lock data item only in the order specified by the partial order. An alternative to detecting deadlocks is to design a system so that deadlock is impossible. One way of accomplishing this is to obtain a global timestamp for every transaction (so that no two transactions get the same timestamp). When one process is about to block waiting for a resource that another process is using, check which of the two processes has a younger timestamp and give priority to the older process.

If a younger process is using the resource, then the older process (that wants the resource) waits. If an older process is holding the resource, the younger process (that wants the resource) kills itself. This forces the resource utilization graph to be directed from older to younger processes, making cycles impossible. This algorithm is known as the wait-die algorithm. An alternative method by which resource request cycles may be avoided is to have an old process pre-empt (kill) the younger process that holds a resource. If a younger process wants a resource that an older one is using, then it waits until the old process is done. In this case, the graph flows from young to old and cycles are again impossible. This variant is called the wound-wait algorithm.The result indicates that the communication overhead of the deadlock detection procedure is reducing. [3].

1.4 PROOF TECHNIQUES FOR DISTRIBUTED ALGORITHMS FORDEADLOCK HANDLING

1.4.1 PROBLEM DEFINITION:Ashok T. Amin and Mitzi P. Freeman studied a proof techniques for distributed algorithms for deadlock handling. Establishing validity of a distributed algorithm is usually not straight-forward. A number of distributed algorithms for deadlock detection handling have appeared; some of these were later shown to contain errors. One of the problems is that the correctness proof of these algorithms use operational arguments which are cumbersome and error-prone. In order to improve this, they present a review of two distributed algorithms for deadlock handling with emphasis on the proof technique. This includes a new approach to formally validate one of the algorithms.1.4.2 SOLUTION:As a solution of this problem, the various system models and representations have been used in deadlock handling studies. The dependencies among processes at a given time can be conceptually represented by a directed graph G, called Wait-For Graph (WFG). The nodes of G represent the processes and a directed edge from vertex i to vertex j exists in G, if and only for the corresponding processes Pi and Pj, it is the case that Pi is dependent on Pj. The types of directed graphs that result, and hence the conditions that represent deadlock depend on the types of resource request allowed and flexibility of resource allocation scheme. This leads to four models of increasing complexities, namely, Basic, AND, OR, and General.Basic Model: An active process can request at most one resource at a time. Thus, a waiting process depends on exactly one other process. The WFG, in this case, is nominally a collection of rooted directed trees, and existence of deadlock in the system corresponds to existence of a (directed) cycle in the WFG.AND Model: An active process can request multiple resources at a time, and it can remain active if all the requested resources are available to it: otherwise, it becomes dependent on one or more processes holding the resources. The WFG, in this case, is a collection of acyclic directed graphs, and existence of deadlock, as in the BASIC Model, corresponds to existence of a cycle in the WFG.OR Model: An active process can make at most one request at a time as with the Basic Model. Here we assume a resource manager at site is responsible for allocation of a type of resource and that these may be multiple copies of the same type of resource. Thus, a waiting process may be dependent on more than one processes which collectively hold all the copies of the resource; however, it needs only a single copy of the resource. Thus, the WFG is an arbitrary graph. A process P is in a deadlock if in there is no directed path in the WFG from P to an active process. General Model: An active process can request multiple resources at a time; however, such a request can include no more than one copy of a given type of resource. In this case, we use an Extended WFG (EWFG) to represent the dependencies, where there are two types nodes, type P and type R, corresponding to processes and resource managers. An edge in EWFG can exist only between two different types of nodes. A directed edge from a P-node to a R-node indicates an outstanding request from the associated process for one or more copies of the resource managed by the corresponding resource manager. A directed edge from a R-node' to a P-node indicates that corresponding resource manager manages a resource held by the corresponding process. A process P is involved in a deadlock if the corresponding vertex in EWFG has an edge to a R node which is not in any path to a P-node with no outgoing edge.1.4.3 IMPLEMENTATION:The deadlock detection and resolution is quite involved except for the Basic Model. We consider two distributed algorithms for the Basic Model. The algorithms use different approaches to dissemination of dependency information, namely, top-down from root node down, or bottom-up from leaf node up. Both of them are discussed below:

A Top-Down Algorithm:This algorithm was presented by Merritt and Mitchell and is widely recognised for its simplicity and elegance of its correctness proof. Each process in the WFG has two labels, a private label and a public label. The private label of a process is unique to that process, but it can change in non-decreasing manner over time. Only the public label of a process can be read by another process. Initially, each process has its private label equal to its public label. The labels of a process change through execution of any of the following steps. For a process P, by pub(P) and prv(P) we denote public and private labels of P, respectively.Block: When an active process P1 becomes dependent on a process P2, the private and public labels of P1 both are changed to the same new N value which is greater than the values pub(P2), pub(Pl), and prv(P1).Transmit: A waiting process P1 dependent on the process P2 when finds that pub(P2) > pub(Pl), changes its public label to equal pub(P2). Thus, larger public labels migrate to the leaf nodes of the WFG.Activate: When a process P1 terminates, either normally or through Abort, some of the processes waiting on P1 that did not get resource now wait on those processes that hold resources held by P1 and execute Block step.Detect: The deadlock is detected when a process P with pub(P) = prv(P) finds that its public label is the same as that of the process it depends on. There is only one process in the deadlock cycle that will detect the deadlock. The resolution of the deadlock is accomplished by aborting the process which detects the deadlock.Theorem 1: A deadlock cycle will be detected eventually by exactly one process in the cycle.Proof. Let the deadlock cycle form when the active process Pr of a WFG becomes dependent on a process Pq. Then, Pr executes the Block step and we will have pub(Pr) > pub(Pq). Thus, we conclude that not all processes in the cycle have the same public label. One or more processes in the cycle may have the maximum value public label, among processes in the cycle. However, there is exactly one process, say Pd, with maximum public value for which pub(Pd) is greater than that of the process it depends on. Hence, it is the case that pub(Pd) = prv(Pd). this is because the only way the labels set in the Block step are changed is through the Transmit step, and this step will not be executed for Pd. As the maximum public label gets transmitted around the cycle through the execution of Transmit steps, eventually Pd will find that its public label and that of the process it depends on are the same and there by detect the deadlock. In the extension of this algorithm each process is assigned two priorities, public and private, and the deadlock is detected by the lowest priority process in the cycle.A Bottom-Up Algorithm:This algorithm is a simpler version of one originally presented by Sinha and Natarajan, and later modified to correct errors by Choudhary et.al. In this approach, each process P in the system is assigned a unique label pri(P) called priority of P. A probe is a message containing priority of some process in the WFG. Each process P in the system maintains a probe queue Q(P). The probe queue of a process is empty, if no other process depends on it.Block: When a process P1 becomes dependent on a process P2, PI sends to P2 those probes pri(Pi) in its probe queue for which pr(Pi) 2 pr(P2). In addition, if pri(P1) pri(P2) then PI sends the probe pri(P1) to P2.Transmit: A process Pk when receives probe pri(Pi) with pr(Pi) > pr(Pk) from one of its dependent, it appends the probe to its probe queue. The process Pk sends the probe pri(Pi) to the process Pi on which it depends if pri(Pl) latest(i)then beginlatest(i) := m; engager(i) :=j; wait(i) := true;for all processes Pr in Pk's dependent set Ssend query(i, m, k, r);num(i) := number of processes in Sendelse if wait(i) and m = latest(i) then send reply(i, m, k,j) to PjUpon receiving reply(i, m, r, k):if m = latest(i) and wait(i)then beginnum(i) := num(i) - 1;if num(i) = 0then if i = k then declare Pk deadlocked else send reply(i, m, k,j) to Pj where j = engager(i)end [7].

1.8 A DISTRIBUTED ALGORITHM FOR RESOURCE DEADLOCK DETECTION1.8.1 PROBLEM DEFINITION: This paper presents a simple algorithm to detect resource deadlocks in distributed databases. The proposed algorithm ensures that only one process in the deadlock cycle will detect it, thus simplifying the resolution problem. All true deadlocks are detected in finite time and no false deadlocks are reported.1.8.1 SOLUTION: A distributed system can be visualized as a set of sites, each site consisting of a number of independent transactions. No transaction knows the global state of the whole system. The transactions communicate through messages. The communication is asynchronous and a message may take an arbitrary but finite time. Several deadlock detection algorithms have been published, with most of them shown to be incorrect. Messages sent from process A to process B are received by process B in the same order as they were sent. To detect the presence of deadlock in the proposed algorithm we do not use probe messages. Instead update message is used, one of its function being to check for the occurrence of deadlockProposed Algorithm:Each site in the network carries a unique site identifier called Site_ID. Within the network a site maintains a certain portion of the database. Each site owns some data objects and maintains a few transactions. Each data object is identified by a unique identifier denoted by Data-obj. Every data object controlled by a site has a variable called Locked-by. The variable Locked-by determines the current state of the data object. If the data object is not locked by any transaction, Locked-by will store nil, else, it stores the identification of the locking transaction.Each transaction has a unique site identifier denoted by T_ID. A transaction can use data objects within its own site or make explicit requests for a data object in another site. As each site has a unique Site_ID, and every transaction within a site has a unique T_ID, the T_ID can be considered to be unique throughout the network.

Assumption 1: A transaction can have at most one outstanding lock request. In case a transaction needs more than one data object, the second data object can be requested only after the first data object has been granted. A transaction can be in one of two states: active or blocked. A transaction is said to be active if it is executing. It is said to be blocked when it has made a lock request for a specific data object which is currently locked by another transaction.Each transaction Ti at site Si has the following data structure: a variable called Wait-for (Ti), a variable called Held-by (Ti), and a queue of requesting transactions Request-Q(Ti). If the current transaction is not waiting for any other transaction then Wait-for (Ti) is set to nil, else, it denotes which transaction is at the head of the locked data object. If held-by (Ti) is set to nil if the current transaction is executing, else it stores the transaction that is holding the data object required by the current transaction. Request-Q (Ti) contains all outstanding requests for data objects which are being held by the transaction Ti. Each element in the Request-Q(Ti) is a tuple (Tj,Di), where Tj is the requesting transaction and Di is the particular data object held by Ti. The difference between Wait-for (Ti) and Held-by (Ti) can be well understood with an example (Figure 2). As shown in Figure 2, Transaction T2 is waiting for a data object held by transaction Tl, which is further waiting on transaction To. Thus Held-by (T2) is Tl, while Held-by (T1) is To. As described above, Wait-for (T1) and Wait-for (T2) are equal to To.1.8.3 IMPLEMENTATION: Suppose a transaction Ti makes a lock request for a data object Dj. If Dj is free then Dj is granted to T; and Locked-by (Dj) is set to Ti. If Dj is not free then Dj sends a not granted message to T; along with the transaction identifier locking Dj (called Ti). Ti joins the Request-Q (Tj) and sets its Wait-for equal to Wait-for (Tj). Now Ti initiates a update message to modify all the Wait-for variables which are affected by the changes in Locked-by variable of the data objects. Update message is a recursive function call that will continue updating all elements of every Request-Q in the chain. When a transaction Tj receives the update message it checks if its Wait-for value is the same as the new Wait-for value. If it is not the same then the value is modified. Now, a check for deadlock is performed. If a deadlock is not detected then the update message is forwarded, else deadlock is declared and deadlock resolution is initiated. The transaction detecting the deadlock is chosen as the transaction to be aborted. This transaction sends a clear message to the transaction holding its requested data object. It also allocates every data object it held to the first requester in its Request-Q and enqueues remaining requesters to the new transaction. The transaction receiving the clear message purges the tuple in its Request-Q having the aborting transaction as an element.

Algorithm:{Transaction Ti makes a lock request for data object Dj}

Informal Proof of Correctness:This shows the proof of absence of false deadlocks.Theorem 1 : Only true deadlocks are detected in finite time.Proof : Suppose a transaction Ti makes a request which creates a cycle. This transaction Ti will join a Request-Q in the cycle and update its own Wait-for. Upon changing Wait-for, it will propagate this change to every member of its own Request-Q. Propagation will continue to all Request-Q's until all nil queues are found. Since a cycle exists, this propagation will run until this value for Wait-for reaches a queue in which it already is in at which point a deadlock is detected.

Example:Consider a distributed database with seven transactions as shown in Figure 3. The state of each transaction is also shown in the figure. However, it does not necessarily imply that each transaction resides in the same site. Figure 3 shows the state of the system before the occurrence of deadlock.When Transaction To makes a request to Transaction T3, a cycle is created and the state of the above system changes, as shown in Figure 4. To joins the Request-Q of T3. To will update its Wait-for to reflect the current state and will propagate the update message to all elements in its own Request-Q. This continues until T3 discovers that Wait-for (T3) intersected with Request-Q (T3) is not nil. Now, T3 declares deadlock and is chosen as the transaction to be aborted. T3 sends a clear message to T', so that T3 is purged from Request-Q (T2). T3 also releases the data objects it held, thus making transactions T4 and T6 to start executing. [8].

1.9 CONCLUSION:After analysing above research papers, we conclude that Deadlocks are a fundamental problem in distributed systems. Deadlock detection is more difficult in systems where there is no central agent and processes may communicate directly with one another. The approaches of deadlock detection can be classified based on the technique used for dissemination of dependency information, namely, Top-Down or Bottom-Up. The algorithms when presented without details of implementation mechanisms permit proof of correctness which are simpler. Though we have considered algorithms for the Basic Model, the approaches are applicable toother models as well. In the proof techniques for distributed algorithms for deadlock handling, we have presented a replication based approach to avoid local deadlocks, and a timestamp based approach to greatly mitigate global deadlocks for SOA environments. We, then, designed a general algorithm for both local and global deadlock prevention. The experiment results demonstrate the effectiveness and efficiency of our solutions. First, our replication based approach completely eliminates local deadlocks. Next, our timestamp based scheme approach can significantly reduce the incidence of global deadlocks and corresponding global live-locks. And at the same time, it also improves the system performance. For many applications, distributing the Process Network model offers greater (scalable) performance at reduced economic cost over a non-distributed implementation. However, bounded memory execution of Process Networks requires run-time deadlock detection. In the deadlock detection for distributed process network, we illustrate that the Kahn PN network model is really a single-resource model for the purposes of deadlock detection. An original contribution of this paper is the application of a distributed deadlock detection algorithm to the Process Network model. This algorithm detects both local and global deadlock. The communication model is more general than the resource model. . The resource model can be simulated as a communication model. In the distributed algorithm for resource deadlock detection above proposed algorithm, we do not use probe messages to detect deadlock. However, we use the update message whose function is two fold : first to modify the Wait-for variables and second to check the occurrence of deadlock. As compared to many recent algorithms in this field, the proposed algorithm can detect the most frequent deadlocks with minimum message passing. With message complexity defined as the number of messages transmitted between initiating a update message and detect.

REFERENCES:1. http://en.wikipedia.org/wiki/Deadlock2. http://philadelphia.edu.jo/academics/mmaouch/uploads/deadlocks-slides.pdf3. Gupta Dhiraj and Gupta V.K., Approaches for Deadlock Detection and Deadlock Prevention for Distributed systems, Research Journal of Recent Sciences ISSN 2277-2502 Vol. 1 (ISC-2011), 422-425 (2012).4. Ashok T. Amin and Mitzi P. Freeman, Proof techniques for distributed algorithms for deadlock handling, Computer Science Department University of Alabama in Huntsville, Alabama 35899.5. Feilong Tanga, Ilsun Youb, Shui Yuc, Cho-Li Wangd, Minyi Guoa, Wenlong Liu, An efficient deadlock prevention approach for service oriented transaction processing, Department of Computer Science and Engineering, Shanghai Jiao Tong University, Shanghai 200240, China, tang-fl@cs.sjtu.edu.cn (F. Tang).6. Alex G. Olson and Brian L. Evans, The process networks for deadlock detection, Embedded Signal Processing Laboratory The University of Texas at Austin, Austin, TX 78712 USA {aolson,bevans}@ece.utexas.edu.7. K. Mani Chandy and Jayadev Misra, Distributed deadlock detection for resource and communication models, University of Texas, ACM Transactions on Computer System Vol.1., Vol.2. May 1983.AVol ACM Transactions on Computer Systems, Vol. 1, No. 2, Ma8. Brain M. Johnston, Ramesh Dutt Javagal, Ajoy Kumar Datta and Sukumar Ghosh A distributed algorithm for resource deadlock detection, Department of Computer Science University of Nevada, Las Vegas, WV 89154 and Department of Computer Science University of Iowa City, IA 52242.

36