1.

1 INTRODUCTION
A 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 Replication1

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
2

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.
5

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 FOR DEADLOCK 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 straightforward. 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.
8

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)<pri(Pi) or discards it if Pk is active. Detect: If Pk receives a probe pri(Pi) from one of its dependents with pr(Pi) = pr(Pk), then a deadlock cycle containing Pk is detected. Complete: When an active process terminates. Each of its dependent processes that does not receive the resource it was waiting for becomes dependent on the process now holding the resource by the executing the Block step. Abort: When a process Pk on the deadlock cycle is aborted, first the dependency of Pk to its successor s(Pk) is removed. Then, beginning with s(Pk) each process along the cycle except Pk, in turn, reinitializes its probe queue from that of its dependent. At this point Pk is terminated and its resources are allocated to processes waiting on Pk. Lemma 1: Let P be a process in the WFG, and let P i l , Pi2, . . .,Pik be all the processes in the probe queue of P along a path (in opposite direction of edges) from P to a leaf node Pi , with pri(P)<pri(Pil)<. . . < pri(Pik). Then the followings hold: 1 ) For some j, l<j<k, the priority labels of Pi 1, Pi2, . .,Pij are in the probe queue of P. 2) If j<k, then the priority labels of processes Pi(j+l), . . ,Pik are not in the probe queue of P but are propagated along the path to P. 3) No other process in the path has its priority label in the probe queue of P. The lemma follows from the Block and Transmit steps of the algorithms. We also note that Complete and Abort steps preserve this property. Theorem 2: A deadlock cycle will be eventually detected by the process in the cycle with the highest priority. Proof: Let a deadlock cycle form when the process Pr becomes dependent on a process Pq. Let Ph be the highest priority process in the cycle, and hence along the path from Pr to Pq in WFG just before the formation of the cycle. The label pri(Ph) is the in the probe of queue of Pr or it is in transmission along the path from Ph to Pr. In either case, the label pri(Ph) will eventually be transmitted along the deadlock cycle to Ph and the deadlock cycle will be detected. The result indicates 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 algorithms when presented without details of implementation mechanisms permit proof of correctness which are simpler. Though they have considered algorithms for the Basic Model, the approaches are applicable to other models as well. Of course, the algorithms will be somewhat more complex. [4].

1.5 AN EFFICIENT DEADLOCK PREVENTION APPROACH FOR SERVICE ORIENTED TRANSACTION PROCESSING 1.5.1 PROBLEM DEFINITION: Transaction processing can guarantee the reliability
of business applications. Locking resources is widely used in distributed transaction management (e.g., two phase commit, 2PC) to keep the system consistent. The locking
9

mechanism, however, potentially results in various deadlocks. In service oriented architecture (SOA), the deadlock problem becomes even worse because multiple (sub)transactions try to lock shared resources in the unexpectable way due to the more randomicity of transaction requests, which has not been solved by existing research results 1.5.2 SOLUTION: In this paper, Feilong Tanga et al 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 propose a replication based approach to avoid the local deadlocks, and a timestamp based approach to significantly mitigate the global deadlocks. A general algorithm is designed for both local and global deadlock prevention. The experimental results demonstrate the effectiveness and efficiency of our deadlock prevention approach. Further, it is also proved that their approach provides higher system performance than traditional resource allocation schemes. Business applications have necessitated distributed transaction management technologies. Existing distributed transaction models widely use the resource locking mechanism for keeping the consistency of transaction systems, among which two-phase commit (2PC) [1] is the most representative coordination protocol through requiring sub-transactions to lock resources before the transaction commit. Unfortunately, 2PC-like protocols potentially induce various deadlocks when multiple (sub-)transactions try to lock the same resource at the same time. Service oriented architecture (SOA) presents new requirements and challenges to the transaction management. With the success of SOA, many large-scale information systems have been set up to provide business services simultaneously. In SOA environments, the deadlock problem due to the resource competition among multiple (sub)transactions gets worse because of the randomicity of transaction requests and the uncontrollability of transaction execution order. The deadlock in SOA environments will occur more often than that in traditional distributed systems. As a result, new deadlock prevention approaches are needed for improving the performance of service-oriented systems. An advantage of the deadlock prevention is that it does not need to know details of all resources available and requested. So, the deadlock prevention approach is more suitable for dynamical and open service-oriented environments. In this paper, Feilong Tanga et al propose an algorithm to prevent local deadlocks, caused by the resource competition among multiple sub-transactions of a transaction, and global deadlocks due to the resource competition among different global transactions. In this scheme, they control concurrent resource accesses through the resource manager, which is particularly useful for business transactions in service-oriented environments. They proposed: (1) A replication based approach to avoid local deadlocks. In traditional deadlock prevention schemes, when two or more sub-transactions of a global transaction compete for the same resource, the global transaction will have to be aborted. On the other hand, whenever the global transaction restarts, it will inevitably fail again due to the same resource competition. (2) A timestamp based approach to prevent global deadlocks. In our scheme, the conflicted transactions that compete for the same resource are selectively aborted after a timeout, based

10

on their transaction ID. Consequently, their approach avoids the live-locks due to resource competition among global transactions. (3) A general algorithm is designed for preventing both local and global deadlocks, based on the solutions proposed above. (4) They design an intelligent resource manager by merging the deadlock prevention function with the resource management function. The resource manger can detect and prevent local and global deadlocks and allocate appropriate lock(s) for each transaction.

Deadlock scenarios:
(1) Local deadlock scenario (scenario 1): During the 2PC-based transaction coordination, resource managers must hold the requested resources in the first phase of 2PC. Otherwise, other concurrent transactions may access intermediate results and lead to system inconsistency. For this purpose, resource managers often lock the resources and do not release their locks until the transaction commit. On the other hand, during the first stage, the transaction coordinator waits for all the sub-transactions (participants) to vote for their states. As a result, if two or more sub-transactions request the same resource(s), a local deadlock is inevitable. For example: T1,1 and T1,2 are sub-transactions of a transaction T1, and they both need to access the same resource R, as shown in Fig. 1. Due to 2PC protocol, R will be held by one of the two sub-transactions according to the scheduling rule (e.g., first come first serve). We assume that T1,1 gets the lock on R, and then it votes OK to the coordinator. The coordinator has to wait for T1,2s response. However, T1,2 request to the same resource R will be blocked until T1,1 release the lock on R. If the timeout mechanism is not considered in the first phase, T1,1 will not release its lock because the coordinator cannot make a final conclusion. In this case, a wait-for cycle is formed and the local deadlock happens. On the other hand, if a timeout is merged in the 2PC protocol, T1 can be aborted after the timeout. Unfortunately, T1 will still fail to commit after it restarts again due to the same competition on R. In the above example, each sub-transaction requests only one resource and further all the subtransactions need to access the same resource. We can easily extend it to the scenario where some sub-transaction(s) need to access multiple resources. Fig. 2 illustrates such an extended local deadlock, where T1,3 has locked R2 but it has to wait for R1 locked by T1,1. Further, T1,2 is blocked because R2 has been locked by T1,3. (2) Global deadlock scenario (scenario 2): A global deadlock will occur when multiple concurrent global transactions compete for the same resource(s). Assume that there are two global transactions T1 and T2 in a system. Each transaction consists of two sub-transactions such that T1 = {T1,1, T1,2} and T2 = {T2,1, T2,2}. T1,1 and T2,1 need to access R1 and T1,2 and T2,2 have to access R2, respectively. As a result, a global deadlock is caused when concurrent T1 and T2 request the two resources R1 and R2 in the following order.

11

12

 Transaction managers of T1 and T2 require sub-transactions to prepare corresponding resources, respectively. T1,1 requests the R1 and successfully sets a lock on the R1. T2,2 requests the R2 and successfully sets a lock on the R2. T1,2 begins to request R2, but it has to wait for the lock on R2. T2,1 begins to request R1, but it has to wait for the lock on R1. This resource request flow can be shown in Fig. 3. In this scenario, T1,1 waits for T1s final decision, T1 waits for T1,2s vote, and T1,2 waits for T2,2 to release the R2. Unfortunately, it is true of T2 and its sub-transactions T2,1 and T2,2. So, T1 and T2 will mutually wait for the resource occupied by the other side.

1.5.3 IMPLEMENTATION:
Deadlock prevention approach: In this there are two prevention mechanisms for local deadlocks and global deadlocks in service-oriented environments, respectively, and then propose an algorithm to implement the two mechanisms. 1.Replication-based local deadlock prevention: A local deadlock occurs when some subtransactions (called conflicted sub-transactions) of a global transaction try to lock the same resource, which can be locked by only one of the conflicted sub-transactions in existing 2PCbased transaction models. Consequently, others of the conflicted sub-transactions are blocked unless the global transaction is aborted. On the other hand, once the global transaction restarts, it will enter the deadlock state again due to the same resource competition. As a result, the local deadlock cannot be simply prevented by using traditional resource allocation schemes, in which a resource is locked by only one sub-transaction.

A new replication-based mechanism to prevent local deadlocks, which works based on the following ideas:

13

1. A resource manager replicates a copy of the competed resource when more than one sub-transactions request it through the resource manger. 2. The replicated resource copy is shared (i.e., read and write) by all the conflicted subtransactions. 3. The resource copy will be updated to its original resource once the global transaction commits. Distinguishing from traditional transaction models where each sub-transaction locks a resource separately, these conflicted sub-transactions in our scheme share a lock on the replicated resource before the global commits. Every global transaction has a unique root ID. When a sub-transaction is distributed to a node, its manager keeps the root ID of its parent and generates its own sub-ID. We use ID(Ti) and ID(Ti,j) to denote the IDs of a global transaction Ti and its sub-transaction Ti,j, respectively. In our scheme, the ID(Ti,j) consists of two parts: the ID IDTi,jparent of its parent transaction generated by the Coordinator and the subID IDTi,j sub generated by the corresponding Participant (see Fig. 4), such that ID(Ti,j) = IDTi,jparent + IDTi,j sub = ID(Ti) + IDTi,j sub. So, every resource manager knows the root ID of any sub-transaction, and can distinguish whether any two sub-transactions belong to the same global transaction or not, based on their root IDs (i.e.,ID(Ti)). Fig. 4 illustrates how our scheme prevents local deadlocks, where a global transaction T1 includes two sub-transactions such that T1 = {T1,1, T1,2}. Both T1,1 and T1,2 access the same resource R. Without losing generality, we assume that resource manager RM first receives T1,1 request to the R and then T1,2 request to the R. When RM receives the request from T1,1, it locks the R for T1,2 immediately. However, RM does not reject the request from T1,2 although the R has been locked by T1,1 . Instead, it replicates a copy of the R (marked as R) and from then on, all requests from sub-transactions with the same root ID are shifted to the replicated resource R . Note that RM immediately releases the lock on the original resource R after the replication. The general approach for preventing local deadlocks is described in Fig. 5, where we assume that the resource Rk is locked by the transaction T1 when LRk = 1. So, Ti,j is one sub-transaction of T1 when IDTi,j parent = ID(T1). Our approach not only prevents local deadlocks but also improves the system concurrency through allowing other global transactions to operate on the original resource R concurrently. 2. Timestamp-based global deadlock prevention: This section describes two approaches to prevent global deadlocks, that are: 1. Pre-check based approach for preventing global deadlocks. 2. Timestamp-based restart policy for global live-lock prevention. In Pre-check based approach: The basic idea is that each global transaction has to check and then hold all the necessary resources if they are available at the beginning of the transaction execution. They extend the 2PC protocol through adding a new phase called PreCheck phase. In the Pre-Check stage, the coordinator delivers all the sub-transactions to participants, and then these participants communicate with resource managers to check the state of resources. If these resources are available, the participant will hold them and at the same time return OK to the coordinator. Otherwise, it will return a failed message. After receiving OK messages from all participants, the coordinator will start the standard twophase commit.
14

Our pre-check phase includes the following three steps (see Fig. 6). Step1.Transaction delivery: After receiving a transaction request, transaction manager (TM) produces a unique root transaction ID, which can be a function of current time to
15

distinguish starting time of transactions. Next, TM divides the task into sub-transactions and distributes them to different sites which host specified services. Step2. Resource pre-check: On receiving the pre-check instruction, each participant begins to check all the needed resources through their resource managers. Step3. Pre-check decision: If the coordinator receives OK messages from all participants, it decides to send a ready-for-prepare message to them, and the two-phase commit begins. Otherwise, the coordinator decides to abort the transaction. In our example, T1 gives up and releases its lock on R1. On the other hand, if T2,1 requests the resource R1 after T1 releases R1, it can acquire the lock successfully and finally commit. In Timestamp-based restart policy: Our pre-check mechanism is able to prevent potential global deadlocks by releasing all competed resources when a resource conflict among multiple global transactions is detected; however, a live-lock may happen if these transactions restart and compete for resources simultaneously again. We exemplify a live-lock still using the scenario 2. As shown in Fig. 7, both T1,2 and T2,1 abort to request the resources R2 and R1, respectively, in terms of our precheck policy, which in turn results in T1,1 and T2,2 also release the held resources R1 and R2, respectively. Finally, T1 and T2 fail to commit. After a little while, if T1 and T2 restart simultaneously, they potentially fail again due to the same resource competition. As a result, a live-lock occurs even though the resources R1 and R2 are free. To avoid such live-locks, they improve the Step 2 (i.e., resource pre-check) in our pre-check based deadlock prevention algorithm through introducing a timestamp-based restart policy. The basic idea behind this approach is the first input first lock (FIFL) in which the more early a transaction requests a resource, the more preferentially the transaction can lock the resource. Note that a transaction with an earlier starting time has a bigger transaction ID.

16

PERFORMANCE:
1.Performance evaluation on the replication-based local deadlock prevention mechanism: In this experiment, we measure system performance using a deadlock incidence, which is a ratio of the number of deadlocked transactions to the number of all transactions in the system. They compared their replication-based local deadlock prevention mechanism (called Replica Used) with the traditional local resource allocation algorithm. Fig. 8 indicates that the deadlock incidence in the traditional resource allocation scheme rapidly increases as the number of resources decreases. The result shows that if the number of resources is fewer than the number of participants (i.e., sub-transactions),the transaction is inevitably deadlocked in the traditional resource allocation scheme. Particularly, such transactions will become deadlocked again even though it restarts again. From Fig. 8, they also find that no deadlock happens in their replication-based local deadlock prevention approach. The reason is that if a resource is requested more than once by different sub-transactions of a global transaction, our scheme will duplicate the resource and all the sub-transactions share the replicated resource. As a result, the local deadlock is avoided no matter how many resources can be used.

Fig. 8. Local deadlock incidence. 2.Performance evaluation on the timestamp-based global deadlock prevention mechanism: In this part, we analyzed and compared the deadlock incidence and average transaction processing time in our timestamp based deadlock prevention mechanism and the traditional global resource allocation scheme in which a global transaction Ti will be aborted if its resource request has been locked by another global transaction Tj. For removing the affect of local deadlocks, we replicate a resource copy when multiple subtransactions in a global transaction compete for a resource.
17

(1) Global deadlock incidence: In this experiment, each global transaction includes 5 subtransactions. We tested how the global deadlock incidence varies with the number of available resources as well as with the number of global transactions. According to Fig. 9, we can find that there are less conflicts among global transactions as the number of available resources increases. Also, the global deadlock incidence grows up as the number of global transactions increases. In the worst case, when 4 transactions, each with 5 sub-transactions, compete with each other for only 5 resources, the deadlock incidence goes up to 98%. On the contrary, in the best case, there is only 1 global transaction and no deadlock occurs because replication-based local deadlock prevention mechanism is also used.

Fig. 9. Global deadlock incidence. (2) Global live-lock incidence: They tested how many live-locks will occur if resource managers use the pure restart policy, in which conflicted global transactions that compete for the same resources are aborted immediately. With this policy, these conflicted global transactions potentially form a live-lock even though they restart again. So, we evaluate how much our timestamp-based mechanism can improve the live-lock incidence. In the pure restart policy, we set the restart times as 5, which means each global transaction may restart at most 5 times if it is not able to be ready for a transaction commit. Fig. 10 shows the livelock percentage of the pure restart policy and our timestamp-based scheme. The global livelock incidence in both schemes grows up as the number of concurrent transactions increases. However, our timestamp-based scheme always outperforms over the pure restart policy, and the more a global transaction has sub-transactions, the higher the global live-lock incidence becomes. In particular, when there are only 4 sub-transactions in each global transaction, almost no live-lock occurs in our timestamp-based scheme. On the other hand, our timestamp-based scheme cannot completely avoid live-locks. The reason is that our timestamp-based scheme cannot always guarantee that each transaction gets all the needed resources.

18

In a word, the experiments demonstrate that our timestamp-based restart policy significantly reduces global deadlocks and global live-lock percentage, in spite that it cannot avoid livelock completely.

Fig. 10. Global live-lock incidence. (3) Average processing time: To evaluate how much our solution improves the system performance, we tested average processing time in the two solutions. Fig. 11 illustrates that the average processing time in our timestamp-based scheme is always lower than that in pure restart policy. It means that our scheme can achieve a better system throughput because the lower the average processing time is in a transaction system, the higher throughput the system will achieve.

Fig. 11. Average processing time.

19

The results demonstrates the effectiveness and efficiency of both two solutions. First, the replication based approach completely eliminates local deadlocks. Next, timestamp based scheme approach can significantly reduce the incidence of global deadlocks and corresponding global live-locks. Further, it is also proved that these approaches provides higher system performance than traditional resource allocation schemes. And at the same time, it also improves the system performance. [5].

1.6 DEADLOCK DETECTION FOR DISTRIBUTED PROCESS NETWORKS 1.6.1 PROBLEM DEFINITION:
Kahn, Parks, Geilen and Basten, Allen and Evans studied the Distributed Process Networks, shows that the PN model is Turing complete, deadlock is only detectable at run-time. Only global deadlock detection has been implemented in a few non-distributed PN implementations. 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. Of these, none detects local deadlocks. The proposed algorithm is based on the Mitchell and Merritt algorithm and is suitable for both parallel and distributed PN implementations.

1.6.2 SOLUTION:
Kahns specifies in his PN model that a process may be blocked on at most one other process at a time. From the large body of distributed deadlock detection algorithms, we consider the set commonly known as single-resource algorithms. This class of algorithms assumes that a process is waiting on at most one other process at a time. An important aspect of these algorithms is they are not concerned with actual management of resources, but only the manner in which a process waits on another process. One very simple algorithm was developed by Mitchell and Merrit and was developed for distributed databases. Mitchell and Merritts Algorithm: In this algorithm, each process contains two labels: a public label and a private label. In this context, a label is just an abstraction for a numeric value. Initially, the public labels of all processes are initialized to unique values. Each processs private label is set equal to its corresponding public label. When a process X begins waiting on another process Y, process X sets both its labels to a value greater than the public labels of both X and Y. This step is known as the blocking step and the waiting process, X, is said to be blocked. While some process X is blocked, it periodically polls the public label of the process, Y, for which it is waiting. During this time, if the public label of process Y becomes greater than that of X, X sets only its public label to be equal to that of Y. This action is known as the transmit step. For a cycle of N waiting processes, the transmit step will be invoked at most N 1 times before deadlock is detected. This algorithm also ensures that in a cycle of waiting processes, exactly one process detects deadlock. Furthermore, false deadlock detection is impossible. These two qualities make this algorithm an ideal deadlock detection scheme in the implementation of a PN scheduling algorithm. This algorithm creates larger labels in the system every time a process becomes
20

blocked (during the execution of the blocking step). While a process is blocked, the largest label tends to propagate in the opposite direction of a sequence of waiting processes. Essentially deadlock is detected when a label makes a round-trip. A graphical example is depicted in Figs. 1, 2, and 3. In the following discussion, pn will refer to the process with n as the second component of its private label. Fig. 1 shows the state of the labels at system initialization; each processs public label is unique. Although each label is shown as an ordered pair, the two components may be considered as the high-word and low-word portions of a single integer. The essential requirement is that all private labels remain unique throughout the execution of the algorithm. Fig. 2 shows the state of the system after a cycle of three waiting processes perform the blocking step of the algorithm. To arrive at this state, p1 begins waiting (performs the blocking step) on process p3. Then process p5 begins waiting on p1. Lastly, p3 begins waiting on p5. Finally, Fig. 3 shows the state of the system after two processes have performed the transmit step. This state results after p5 performs the transmit step, followed by p3. Here, only process p3, with private label (7, 3), detects the deadlock. Note, in a real system, some processes may be executing the blocking step while others are concurrently executing the transmit step. This may cause the sequence of label changes to differ. However, the correctness of the algorithm is maintained, mainly due to the fact that label values are non-decreasing.

21

1.6.3 IMPLEMENTATION:
In this implementation, the TCP/IP protocol is used for communication links between two processes. Rather than operating at the token-level, the framework operates at the byte-level. This design choice allows the framework to handle both large and small tokens efficiently. There are two types of channels (relative to each process): input channels and output channels. Input channels are those channels from which a Kahn process reads tokens. Output channels are those channels to which a Kahn process writes tokens. Each channel, input or output, contains a queue. For output channels, the queue aggregates tokens before transmission to better utilize network bandwidth. For input channels, the queue functions as the Kahn channel queue. By explicitly modeling the Kahn channel queue as a real queue, it allow control data to be exchanged over the communication link even when both processes are blocked. The communication between any two processes is fairly simple. When the communication link is first established, the input channel sends the capacity of its queue over the link. The output channel uses this value to maintain a lower bound on the available capacity of the input channels queue. Each time a process consumes a token from its input channel, the channel, after a very small delay, sends a message across the link that indicates how many bytes were consumed. This is essentially a simple sliding window algorithm being used for flow-control. Since we use TCP/IP for the communication link, reliable and FIFO delivery of data is guaranteed. Each process in our framework consists of two threads: a computation thread and a communication thread. The computation thread is implemented by the user and performs the computation, such as FIR filtering. The communication thread is implemented by the framework and manages communication between the TCP/IP link and the queues on each end. The queues provide an interface between the two threads. For reads, the computation thread blocks until a sufficient amount of data is available in the input channels queue. When token data is written to an output channel, the channel decrements its estimate of the available capacity of the input channel. When token data is read from the input channel, the channel sends a message indicating the number of bytes that were consumed. Upon receipt of such a message, the output channel increments its estimate of the capacity of the input channel by that amount. Thus at all times, this count is a lower bound on how much token data (in bytes) can be immediately sent over the link.

22

PN and CPN Support: Channels in this implementation support both Kahn PN semantics (where all read tokens are consumed) as well as CPN semantics (where not all read tokens are consumed). It also provide a zero copy operation for CPNs. That is, a process acquires read and write pointers into the queues rather than copying data in or out. This reduces memory bandwidth requirements in high data-rate applications. Deadlock Detection: When a process blocks for a sufficient amount of time, Mitchell and Merritts algorithm is activated. We currently use a fixed threshold of time. The blocked process sends a Label Request message to the process on which it is blocked. Upon the messages receipt, a process will transmit any queued tokens and then reply with its public label. If the blocked process remains continuously blocked between the request and receipt of the label, it will perform the blocking step of the algorithm. Otherwise, the label is discarded and another request will be sent after some time. The same technique is used for successive executions of the transmit step of the deadlock detection algorithm. Performance and Memory Requirements: The memory requirement of the deadlock detection algorithm is very low and independent of the number of processes or channels in a system. Each process stores only two pairs of labels, which represents as an ordered pair of 32-bit integers. The network and CPU overhead is negligible since the algorithm only activates intermittently and only while a process is blocked. As this algorithm is focused on DPN implementations, but it is equally suitable for parallel PN implementations. In a non-distributed parallel implementation, the communication channel could be a shared block of memory. Events and callbacks could replace the sending of label requests and replies. Any local deadlock would be detected almost instantaneously.

Fig. 4. Structure of implementation. In this Figure, each circle represents a process. Each process contains two threads, for computation and communication. For each channel of each process, a queue provides the interface between the two threads. For many applications, distributed 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. 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

23

deadlock. Finally, it present the design of a DPN implementation that integrates this algorithm with techniques for achieving high performance. [6].

1.7 DISTRIBUTED DEADLOCK DETECTION FOR RESOURCE AND COMMUNICATION MODELS 1.7.1 PROBLEM DEFINITION:
Distributed deadlock models are presented for resource and communication deadlock models. Simple distributed algorithms for detection of deadlocks are given. It shows that all true deadlocks are detected and no false deadlocks are reported. In 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.

1.7.2 SOLUTION:
In a system of processes which communicate only with a single central agent, deadlock can be detected easily because the central agent has complete information about every process. Deadlock detection is more difficult in systems where there is no such central agent and processes may communicate directly with one another. If it is assumed that message communication is instantaneous, or if certain restrictions could be placed on message delays, then deadlock detection would become simpler. However, the only realistic general assumption is that message delays are arbitrary but finite. In this paper, we present deadlock detection algorithms for networks of processes in which there is no single central agent and in which message delays are arbitrary but finite. The only assumption we make is that messages sent by process A to process B are received by B in the order in which they were sent by A. Two deadlock models in message communication systems: resource and communication deadlocks. 1.Resource Model: In the resource model, a process which requests resources must wait until it acquires all the requested resources before it can proceed with its computation. The resource deadlock problem as it arises in distributed databases (DDBs) has been studied. A DDB consists of resources, controllers, and processes. Associated with each controller is a set of resources which it manages and a set of constituent processes. A process can only request resources from its own controller, but this controller may have to communicate with other controllers in order to reserve the particular resource. A process cannot execute unless it acquires all the resources for which it is waiting. A set of processes is said to be deadlocked when no process in the set can execute because each process requires a resource held by some other process in the set. A DDB is implemented by N computers S1, . . . , SN. A local operating system or controller Cj at each computer Sj schedules processes, manages resources, and carries out communication. There are M transactions T1 . . . . . TM running on the DDB. A transaction is implemented by a collection of processes with at most one process per computer. Each

24

process is labelled with a tuple Pij where Ti is the identity of the transaction that the process belongs to and Sj is the computer on which the process runs. 2. Communication Model: The communication model is an abstract description of a network of processes which communicate via messages. There are no explicit controllers (or resources) in this model; controllers must be implemented by processes; requests for resource allocation, cancellation, and release must be implemented by messages. Associated with every idle process is a set of processes called its dependent set. An idle process starts executing upon receiving a message from any process in its dependent set; otherwise, it does not change state or its dependent set. A process is terminated if it is idle and its associated dependent set is empty. a nonempty set S of processes is deadlocked if all processes in S are permanently idle. A process is permanently idle if it never receives a message from any process in its dependent set. It is not possible to detect permanent idleness in the following situation. Process A is waiting for a message from process B; process B is currently executing and will send a message to process A only upon completion of a loop; process A appears to be permanently idle if process B's loop computation is nonterminating. Detection of permanent idleness of this type amounts to solving the halting problem and hence is undecidable. Therefore, in this situation it is assumed that A is not permanently idle since B may send it a message sometime in the future. Therefore, the following operational definition of deadlock is adopted. A nonempty set of processes S is deadlocked if and only if 1. All processes in S are idle; 2. The dependent set of every process in S is a subset of S; and 3. There are no messages in transit between processes in S. A process is deadlocked if it belongs to some deadlocked set. A nonempty set S of processes satisfying the above three conditions must remain idle permanently because (1) an idle process Pi in S can start executing only after receiving a message from some process Pj in its dependent set, (2) every process Pj in Pi's dependent set is also in S and cannot send a message while remaining in the idle state, and (3) there are no messages in transit from Pj to Pi, which implies that Pi will never receive a message from any process in its dependent set.

25

A COMPARISON DEADLOCKS

OF

RESOURCE

AND

COMMUNICATION

Communication Model
1. In the communication model, a process can know the identity of those processes from which it must receive a message before it can continue. If process A needs to receive a message from process B, then A can know that it is waiting for B. Thus, the processes have the necessary information to perform deadlock detection if they act collectively.

Resource Model

1. In the resource model the dependence of one transaction on actions of other transactions is not directly known. All that is known is whether a transaction is waiting for a given resource or whether a transaction holds a given resource. A controller at each site keeps track of its resources and only the controllers can deduce that one transaction is waiting for another. Thus the agent of deadlock detection in the two environments is not the same. 2. In this model, a process cannot proceed 2. In this model, a process cannot proceed with its execution until it can communicate with execution until it receives all the with at least one of the processes for which it resources for which it is waiting. is waiting. 3. Deadlock arises in the communication 3. Deadlock arises in the resource model model there must be a knot1 of (idle) waiting when there is a cycle of (idle) dependent processes. processes. 4. The communication model is more general 4. The resource model can be simulated as a than the resource model. communication model.

1.7.3 IMPLEMENTATION: 1.DEADLOCK DETECTION IN THE RESOURCE MODEL

In order to determine whether an idle process is deadlocked, its controller initiates a probe computation. In a probe computation, controllers send messages called probes to one another. Probes are concerned exclusively with deadlock detection and are distinct from resource requests and replies. Probe computations may be initiated for several processes, and the same process may have several probe computations initiated for it in sequence. A probe is a triple (i, j, k) denoting that it belongs to a probe computation initiated by Pi, and that this probe is being sent from process Pj on one controller to process Pk on another. The intuitive meaning of a probe (i, j, k) is as follows. Pj sends probe i, j, k) to Pk when the following conditions exist: Pi is idle, Pj is waiting for (i.e., waiting to acquire resources from) Pk, and Pj has determined that Pi is dependent on Pj. This probe may be discarded or accepted by Pk; the probe is accepted by Pk if and only if Pk is idle, Pk did not know that Pi was

26

dependent on it, and Pk can now deduce that Pi is dependent on it. It follows that if Pi accepts a probe (i, j, i), for any j, then Pi is deadlocked.

Algorithm:
The controller maintains a Boolean array dependentk for each constituent process Pk, where dependentk (i) is true only if Pk's controller knows that Pi is dependent on Pk. If dependenti (i) is true, then Pi is dependent on itself and hence is deadlocked. Initially, dependenti (j) is set false for all i and j. The detailed algorithm for the probe computation is given below. For initiation of probe computation by a controller for a constituent idle process Pi: if Pi is locally dependent on itself (i.e., Pi belongs to a deadlocked set of processes, all on the same controller) then declare deadlock else for all Pa, Pb such that (i) Pi is locally dependent on Pa, and (ii) Pa is waiting for Pb, and (iii) Pa, Pb are on different controllers, send probe(i, a, b). For a controller on receiving a probe(i, j, k): if (i) Pk is idle, and (ii) dependentk(i) = false, and (iii) Pk has not replied (positively) to all requests of Pj, then begin dependents(i) = true; if k=i then declare that Pi is deadlocked else for all Pa, Pb such that (i) Pk is locally dependent on P,, and (ii) Pa is waiting for Pb, and (iii) Pa and Pb are on different controllers, send probe(i, a, b). end For a controller when a constituent process Pk becomes executing: set dependents (i) = false for all i The proof that a process is actually deadlocked when it is declared to be so follows from the fact (which may be shown by induction) that dependentk (i) is true only if Pi is dependent on Pk and Pk is idle. Conversely, we can prove that Pi will be declared to be deadlocked if a probe computation for Pi begins when there exists a cycle of processes Pi, Pj(I) . . . . . Pj(m), Pi, where each process in the sequence is dependent on the next. The proof follows from the inductive hypothesis: dependentj(k)(i) will be set to true and Pj(k) will send a probe to the next process in the sequence for I k K, for all K.

27

2. DEADLOCK DETECTION IN THE COMMUNICATION MODEL

An idle process can determine whether it is deadlocked by initiating a query computation when it enters the idle state. The query computation is distinct from the underlying computation for which deadlock is being detected. Processes may exchange messages for the query computation even in the idle state. This is because the state is idle only in reference to the underlying computation. The process which initiates a query computation is called the initiator of that query computation. Several processes may initiate query computations and the same process may initiate query computations several times. The messages in a query computation are of the form query(i, m, j, k) and reply(i, m, j, k), denoting that these messages belong to the mth query computation initiated by process Pi and are being sent from Pj to Pk. Pi, m, Pj, and Pk are called the initiator, sequence number, sender, and receiver, respectively. There will be at most one message of the form query (i, m, j, k); there will be at most one reply message of the form reply(i, m, k, j) to the query message query (i,m,j,k). The query computations have the following properties. 1. If process Pi is deadlocked when it initiates its mth query computation, then it will receive reply (i, m, j, i) corresponding to every query (i, m, i, j) that it sent. 2. If the initiator, Pi, has received reply (i, m, j, i) corresponding to every query(i, m, i, j) that it sent, then it is deadlocked. In our algorithm each process Pk maintains four arrays of local variables. The indices of the array range over all processes in the network. The local variables for Pk k = 1, 2, 3 . . . . are described below. Definition 4.1 The variable latest(i) is the largest sequence number m in any query(i, m, j, k) sent or received by Pk. Initially, latest(i) = 0, for all i. Definition 4.2 The variable engager(i), where i ~ k, is the identity, say j, of the process which caused latest(i) to be set to its current value m by sending Pk the message query(i, m, j, k). The initial value is arbitrary. Definition 4.3 The variable num(i) is the total number of messages of the form query(i, m, k, j) sent by Pk, minus the total number of messages of the form reply(i, m, j, k) received by Pk, where m = latest(i) and j is arbitrary. Definition 4.4 The variable wait(i) is true if and only if Pk has been idle continuously since latest(i) was last updated. Initially wait(i) is false, for all i.

Algorithm:
An idle process initiates a query computation by sending queries to processes in its dependent set. The basic idea is that an idle process on receiving a query should propagate the query to its dependent set if it has not done so already. Thus, if there is a sequence of permanently idle processes Pi . . . . . Pj, such that each process in the sequence (except the first) is in the dependent set of the previous process in the sequence, a query initiated by Pi will be propagated to Pi. For the remainder of this discussion we consider the action taken by a process Pk on receiving a query or reply with initiator i, sequence number m, and sender j. Local variables latest(i), engager(i), num(i), and wait(i) refer to the variables of process Pk. If m < latest(i),
28

then Pk discards the message because Pi must have initiated the query computation with sequence number latest(i) after it initiated the mth query computation; hence Pi could not have been deadlocked when it initiated the mth query computation. If wait(i) is false when Pk receives the query/reply, and if m = latest(i), then Pk has been in the executing state since it first participated in the ruth computation initiated by Pi. In this case, we can assert (by Theorem 1 below) that Pi was not deadlocked when it initiated its ruth computation; hence Pk, discards the message. Thus, Pk discards all messages except those in which rn > latest(i) or those received when wait(i) is true and m = latest(i). If m > latest(i), then, Pk must set latest(i) to m, engager(i) to j (where P1 is the sender), and wait(i) to true. If Pk receives a reply in which m = latest(i) and wait(i) is true, then (by Definition 4.3), Pk must decrement num(i) by 1. When Pk receives a query in which m > latest(i), it propagates the query to all processes in its dependent set, sets num(i) to the number of processes in the dependent set and updates other local variables. When Pk initiates a query computation it does so by acting as though it had just received a query in which m > latest(k). Next, we derive the conditions under which Pk sends replies. If wait(i) is true when Pk receives a query in which m -- latest(i), it replies to the query immediately. If wait(i) is false when Pk receives a query in which m = latest(i), or wait(i) is arbitrary and m < latest(i), then Pk discards the query and never replies to this query. The interesting question is when should Pk reply to a query in which m > latest(i)? By Definitions 4.1 and 4.2, such a query must have been sent by engager(i). The answer to this question is derived by extending the conditions in Dijkstra and Scholten [2]; Pk replies to engager(i) only if wait(i) is true and num(i) has been reduced to zero (i.e., Pk has received replies to all queries with initiator Pi and sequence number m that it sent, and Pk has been continuously idle since it first participated in this query computation). This scheme for replying to engagers is necessary for Theorem 2 (given below): if the initiator receives replies to all the queries it sends to its dependent set, then the initiator is deadlocked. The detailed description of the algorithm is given below. For an idle process Pi to initiate a query computation: begin latest(i) := latest(i) + 1; wait(i) = true; send query(i, latest(i), i, j) to all processes Pj in Pi's dependent set S; num(i) := number of elements in S End For an executing process Pk: On becoming executing, set wait(i) = false, for all i. Discard all queries and replies received while in executing state. For an idle process Pk, upon receiving query(i, m, j, k): if m > latest(i) then begin latest(i) := m; engager(i) :=j; wait(i) := true; for all processes Pr in Pk's dependent set S send query(i, m, k, r); num(i) := number of processes in S
29

end else if wait(i) and m = latest(i) then send reply(i, m, k,j) to Pj Upon receiving reply(i, m, r, k): if m = latest(i) and wait(i) then begin num(i) := num(i) - 1; if num(i) = 0 then 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 DETECTION 1.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 deadlock Proposed 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

30

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 RequestQ(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.

31

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

32

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
33

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].

34

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 to other 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.

35

REFERENCES:
1. http://en.wikipedia.org/wiki/Deadlock 2. http://philadelphia.edu.jo/academics/mmaouch/uploads/deadlocks-slides.pdf 3. Gupta Dhiraj and Gupta V.K., Approaches for Deadlock Detection and Deadlock Prevention for Distributed systems, Research Journal of Recent Sciences ISSN 22772502 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, [email protected] (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, Ma 8. 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