An Approach to Distributed Collaboration Problem with Conflictive Tasks

Transcription

1 An Approach to Distributed Collaboration Problem with Conflictive Tasks Jingping Bi, Qi Wu, Zhongcheng Li Institute of Computing Technology, Chinese Academy of Sciences, Beijing , P. R. China {jpingbi, abewu, Abstract. Distributed collaboration problem (DCP) is a kind of distributed resource allocation problem. Previous works give the solution of DCP with non-conflictive tasks. In this paper, we present a completely distributed algorithm (CDA) to solve DCP with conflictive tasks where each task requires exactly two resources. We call this the measurement collaboration problem (MCP). We prove the aliveness and correctness of CDA and give the run-time performance of CDA by simulation. To provide a baseline of performance parameters, we design a simple single-wait-state algorithm (SWSA). The simulation indicates CDA gradually has higher efficiency than SWSA, especially when the tasks are highly conflictive. CDA can also be utilized in many aspects, such as disaster rescue, distributed agent collaboration, objects position and so on. 1 Introduction Distributed resource allocation problem (DRAP) is a pervasive problem. The basic model for this problem is many distributed processes competing for limited resources. Different assumptions and restrictions lead to distinct solutions and algorithms for the problem. When the resource number is 1, DRAP becomes distributed mutual exclusion problem (DMEP) where only one process can be permitted to use the resource at any time. The solutions for DMEP can be divided into token-based [1] and non-token based [2]. A non-token-based distributed algorithm is generally called a completely distributed algorithm. The dinning philosophers problem (DHP) by E. W. Dijkstra is another classic problem for resource allocation problem [3]. K. M. Chandy et al extend the problem and call it the drinking philosophers problem [4]. By introducing dynamic priority between neighboring philosophers, Chandy et al present a determinate, symmetric solution for this problem under a completely distributed environment. With the flourishing of agent technology, another kind of DRAP is presented during the collaboration of agents under the distributed environment, which is called distributed collaboration problem (DCP). Compared with the philosopher problem, the agent is the resource (chopsticks), and the task is the philosopher. The main difference lies in This work has been supported through funding by National Natural Science Foundation of China Grant No and Hi-Tech Research and Development Program of China (the 863 Project) Grant No. 2001AA and 2001AA

2 that it is the resource, not the task, has consciousness. That is to say, the chopsticks will think and negotiate which philosopher can use them. According to the variance property of tasks and the power of conflicts, P. J. Modi et al divide DCP into 4 classes from easy to difficult and mapped DCP to dynamic distributed constraint satisfaction problem (DDCSP) and give out the solution for the former 3 classes [5][6]. In the former 3 classes, there are no conflicts among tasks at all. But the real world is full of conflictive tasks. The distributed collaboration problem with conflictive is called the 5-th class DCP (DCP5). In this paper, we give a distributed algorithm for special case of DCP5 where the execution of each task just needs 2 nodes (agents). We call this special case the Measurement Collaboration Problem (MCP) because it origins from the measurement of one-way metrics where a measurement task needs to be performed by the two ends. Our previous paper has given the solution of MCP in arbitrator-based environment [7]. In spite of one-way measurement, the solution of MCP can also be utilized in many aspects, such as disaster rescue, distributed agent collaboration, objects position and so on [8][9]. 1.1 Measurement Collaboration Problem Suppose that there are n nodes and every node can act as either a requester (when the node is the sender in measurement) or a collaborator (when it is a receiver). A measurement task should be collaboratively completed by a requester and a collaborator. So this task can be performed only after the two nodes establish concurrence. A node randomly generates a task and acts as a requester. That is to say, the requester selects collaborator from the other n-1 nodes and negotiates with it to perform the task. A task can be generated only when a node is not executing the task or negotiating with other nodes. At any time, a node cannot execute multiple tasks, but it may negotiate with more than one node to choose which task will be executed. Information exchange among nodes is performed by sending and receiving messages. Suppose that the messages are transferred as follows: messages are transferred in sequence without errors or losses; messages can reach the destination within T trans ; messages are transferred asynchronously. Other assumptions include: each node runs continuously without any interruption; each measurement task can be finished within T exec. 2 Algorithm Specification 2.1 Messages definition Req Request message. It is used by one node to apply to another for executing tasks. We term the sender of the Req message as requester and the receiver as collaborator.

3 SU Rst Ack LD Speed up message. A requester uses it to indicate that no node requests to itself. A SU message can t be sent unless the Req message is sent. Reset message. A requester uses this message to cancel its own request and a collaborator uses it to reject the request. Acknowledgement message. This message can only be sent by a collaborator to accept a request. Loop detection message. The message is used by a node to report topology to its requester in loop detection. 2.2 Node states idle busy wait1 wait2 wait3 wait4 indicating that a node is neither executing a task nor negotiating with other nodes. indicating that a node is executing a task. indicating that a node has just received one or more Req messages from other nodes. indicating that a node has sent a Req message just now. indicating that no other node requests to itself. indicating that a node receives one or more Req messages after it has sent out one. 2.3 Variables in a node requests priority distance nodes storing the received Req messages which have not been responded. storing the highest priority of nodes in the loop detection. storing the distance (in hops) between the latest found node and the highest priority node. storing the topology a node knows but has not reported yet. 2.4 The state transition of a node 1) Public operations Basic operations. When a node sends a Req message, it records the sequence number of the node to the first variable of the nodes array. If the node doesn t reply immediately to a Req message, the message will be added to requests. Default operations. When a node receives a message that it does not know how to handle, it takes the following default operations. If the message type is Req or SU, Rst message is used as a response. Otherwise the node just keeps silent. 2) In busy state The node uses default operation in all received messages. After the task finished, the node returns to idle automatically. 3) In idle state A node may send a Req message to any other nodes and set the timer to T trans and

4 switch to wait2 state. If a node receives a Req message, it sets the timer to T trans T send and switches to wait1 state, where T send is the sending moment of the Req message. 4) In wait1 state If a node receives a Req message before the timer times out, it chooses the public operations. Otherwise, it takes the default operations. If a node receives a Rst message from its requesters, it removes the corresponding Req from requests. If the requests array is empty after the remove, the node switches to idle. If a correct SU message is received (the sender of SU has just sent a Req message), the node uses an Ack message as a response and reject all other requests. 5) In wait2 state If a Rst message from it collaborator is received, the node switches to idle. If a Req message is received, the node switches to wait4. If the timer of the node times out, the node sends a SU message to its collaborator and switches to wait3. 6) In wait3 state If a node receives a Rst message from its collaborator, it switches to idle. If a node receives an Ack message from its collaborator, it switches to busy. 7) In wait4 state If a node receives a Req message before the timer times out, it chooses the public operations. Otherwise it takes the default operations. If a node receives a Rst message from its collaborator, it switches to wait1. If a node receives a Rst message from its requesters, it removes the corresponding Req from requests. If the requests array becomes empty after this, the node sends SU to its collaborator and switches to wait3. If a node receives a SU message from its requesters, the node takes the following 4 steps: replying an Ack message, rejecting all other requests, canceling its request, and switching to busy. If the timer of the node times out and the node has only one requester, it executes the loop detection operations. (See the next sub-section). Figure 1 shows the finite state machine of a node, where interrogation mark? means sending and exclamatory mark! means receiving. Events which trigger states change and the corresponding actions are divided by solidus /. Some details which do not affect states change are ignored for simplification. (Such as the timeout in wait1 and wait4) 2.5 Loop detection and dismantlement Definition 1 (measurement request graph). Measurement request graph G=(V, E) is a directed graph where V is the node set and each task matches a directed edge in E. Definition 2 (isolated loop). An isolated loop L = ( V L, EL ) is a connection set of G, where V L = { v 1, L, v k } and EL = { v1v2, v2v3, L, vk 1vk, vkv1} and E EL don t inter-

5 sect E L. wait1!ld /?Rst!Rst wait4!su /?(Ack) 1 (Rst) * busy!(rst) k!(req) k!ack!(rst) k /?SU!(Req) k!ld /?(SU)(Rst)!Rst wait3 Timeout /?SU idle idle?req!rst!ld /?(Rst) 2 wait2 wait4 Fig. 1. States transition of a node If it exists an isolated loop L in G and the timers of all nodes in V L have timed out, all nodes in V L reject new requests and wait for their requesters actions. Unfortunately, their requesters (which are themselves) are also waiting, which causes a deadlock. When a node is in an isolated loop, it matches the following three cases. The state of the node is wait4. The timer of the node has timed out. The length of requests array in the node is 1. If a node meets these cases, we call it a potential trouble (PT) node. Otherwise we call it a healthy (HE) node. A PT-node must have one and only one requester, which is defined as its superior. The operations of loop detection and dismantlement are defined as follows. 1) When a node wants to send out a LD message, it creates a LD message, copying the nodes array to the message body. Next it sends the message to its superior and empties the nodes array. 2) If a HE-node changes to a PT-node, it updates its priority and distance variables according to their definitions. Next, it checks the nodes array and executes the following operations. If the node itself appears in the nodes array, we can get that the node is in an isolated loop and it is the only one who knows the existence of the loop because it has never spread LD messages before. Therefore, the mission of breaking the deadlock falls on the node. It sends a SU message to its collaborator and a Rst message to its superior and switches to wait3, which dismantles the loop. Otherwise, the node sends a LD message to its superior. 3) If a node receives a LD message from its collaborator, it concatenates its nodes array and the array carried in the LD message and updates the priority and distance. Next, if the node is a PT-node, it does the following operations. If the node finds itself in the received LD message, which indicates that a directed

6 loop has been found, it begins to dismantle the loop. Because the node has sent LD messages before, it is not impossible that other nodes in the loop have detected the loop. At this time, these nodes must have consistent actions. Let s define the matching rules by dismantling from the node with the highest priority. That is, the node chooses one of the following three actions according to its relative position to the highest priority (HP) node. If the distance variable is an odd number, the node sends a Rst message to its collaborator and a LD message to its superior and switch to wait1. If distance is an even number and the node s collaborator is not the highest priority node, the node sends a SU message to its collaborator and a Rst message to its superior and switches to wait3. Otherwise, the node sends a Rst message to its collaborator and a LD message to its superior and switches to idle. Otherwise, it sends a LD message to its superior. 3 Feasibility Analysis Lemma 1. To any node s in CDA, if it is not in a loop, it will switch to idle in finite time. Proof. We defer the proof for an extended version of this paper. Definition 3 (the requesters operator). Let the operator Asc (s) be the requester set of node s. To the node set S, we let U Asc( S) = Asc( s). Theorem 1 (Aliveness). Any node in CDA will return to idle state in finite time. Proof (by contradiction). Suppose that s0 s1 K sk 1 sk = s0 compose a directed loop and s 0 never switches to idle. If some nodes in { s1, L, s k 1} switch to idle in finite time, the loop will be dismantled and s 0 will switch to idle according to lemma 1. Accordingly, any node in the loop will never be in idle state. Let S = { s0, L, sk 1} and U = Asc( S) S. Suppose a node t 0 U is in a loop t0 t1 K tm 1 tm = t0. Because the out-degree of t 0 is 1, we get t 1 S. Finally, we can get t m = t 0 S in the same way, which disobeys t0 U = Asc( S) S. Therefore, all the nodes in U are not in a loop and all of them will switch to idle in finite time, s0 s1 K s k 1 sk becomes an isolated loop. According to the state transition of a node, these nodes will detect the isolated loop. The messages transfer correctly and losslessly, so the loop will be detected by some nodes in k Ttrans. No matter which one of the three actions the node takes, either it or its superior will break the loop. Therefore, s 0 will switch to idle in a finite time because it is not in the loop, which conflicts with the hypothesis. As a result, any node in CDA will return to idle state in finite time. s S

7 Theorem 2 (Correctness). CDA is correct. Proof. CDA is correct means that no node takes more than one measurement task at any time. This can be divided into three cases: Firstly, as a requester, a node can not take collaborative measurements with two nodes simultaneously. Secondly, as a collaborator, a node can not take collaborative measurements with two nodes at the same time. Thirdly, a node can not take collaborative measurements with one node as a requester and with another node as a collaborator concurrently. The collaborative measurement begins with an Ack message. The receiving (or the sending) of an Ack message means the beginning of a collaborative measurement. Ack messages can only be the response to SU messages, so the first case equals to proving that a node at most sends one SU message before it returns to idle. A node in wait3 can only have two cases of state transition: wait3 idle and wait3 busy idle, so a node at most passes by wait3 once. Because only when a node switches to wait3 can it send a SU message, the first case is tenable. Because a node must switch to busy once it sends an Ack message and the busy node doesn t respond Ack to any messages, the second case is tenable. A node must switch to wait3 once it sends a SU message and the node does not send Ack messages in the following two possible state transfer ways: wait3 idle and wait3 busy idle, so the third case is tenable. As a result, CDA is correct. 4 Simulation In this section, we will give the average performance of CDA by simulation. To provide the baseline of performance parameters, we design a Single-Wait State Algorithm (SWSA). 4.1 Single-Wait State Algorithm Message Types. Req Request the collaborative measurement; Ack Agree to the collaborative measurement; NAK Refuse the collaborative measurement. States. A node has three states: busy, idle and wait, where busy and idle have the same meaning as those in CDA. A node in wait state indicates that the Req message sent from the node hasn t been responded yet. State transition. A node generates tasks in idle state and switches to wait at once after it sends a Req message. If a node in idle state receives a Req message, it uses an Ack message as a response. If a node in wait or busy state receives a Req message, it uses a NAK message as a response. If a node receives an Ack message in wait state, it switches to busy. If a node receives a NAK message in wait state, it switches to idle.

8 4.2 Experiment results In the simulation, a task is created at random time and with random requester-collaborator pairs. We implement SWSA and CDA by event driven, which guarantees the time order of events strictly. The parameters in the simulation are given in table 1. We change the values in Table 1 and find the results are similar. Table 1. Parameters of the simulation F exec F gen the distribution function of tasks running time the distribution function of tasks generating intervals in each node parameter comments value n the number of nodes in the system 100 F trans the distribution function of message revised negative exponential transit time distribution 1, mean 2 is 0.3 seconds, upper limit is 2 seconds revised negative exponential distribution, mean is 60 seconds, upper limit is 300 seconds corrected negative exponential distribution, mean is 90 seconds, upper limit is 500 seconds c number of concurrent tasks the number of tasks created at the same time The experiment focuses on discussing the performance of the two algorithms when given different number of concurrent tasks. We create tasks for each simulation. To different c, we run 100 simulations for each algorithm, and the results are shown in figure 2 and 3. Figure 2 compares CDA with SWSA about the proportions in executing tasks, where tasks execution proportion P exec is defined as the number of tasks that are excuted successfully P exec = (1) the number of generated tasks X-axis in figure 5 is the number of tasks created concurrently, and y-axis is P exec. We can see, in the case of c being small, the difference of P exec between CDA and SWSA is not large. With the increase of c, P exec of the two algorithms tends to decrease but the decreasing speed of SWSA is larger than that of CDA. As a result, we draw the conclusions, when the number of concurrent tasks is large, CDA has better task execution ability than SWSA. Figure 3 gives the efficiency in handling conflictive tasks of the two algorithms, where the confliction handling efficiency P eff is termed as: 1 The revised negative exponent distribution is to add the maximum limitation on the basis of negative distribution where all values greater than the maximum are taken as the maximum. 2 The mean is the mean of negative exponent distribution (before revising).

9 the number of conflict tasks that can be executed P eff = (2) the number of conflicting tasks 35.0% 32.5% 30.0% 27.5% 25.0% 22.5% 20.0% 17.5% 15.0% P_exec CDA SWSA % 27.5% 25.0% 22.5% 20.0% 17.5% 15.0% 12.5% 10.0% 7.5% 5.0% P_eff CDA SWSA Fig. 2. Tasks execution proportion Fig. 3. Efficiency of handling conflictive tasks A SWSA node in wait state refuses requests from other nodes, so the ability of confliction handling efficiency of SWSA is poor. From the figure we can see, with both tasks confliction proportion and concurrent tasks number increasing, the confliction handling efficiency of SWSA becomes worse, while that of CDA slightly increases. Thus we get that CDA has good ability to handle conflictive tasks. 5 Conclusions Measurement collaboration problem is a kind of distributed collaboration problem with conflictive tasks. In this paper, we give the completely distributed algorithm CDA of measurement collaboration problem, which avoids the deadlock by isolated loop detection and dismantlement. The aliveness and correctness of the CDA is proven in the paper. By simulation, we validate the efficiency of the CDA and draw the following conclusions: in the case of the number of concurrent tasks created randomly being small, the efficiency of the CDA is not higher than that of SWSA. With the increase of the number of concurrent tasks, the high efficiency of CDA gradually becomes remarkable. The characteristics of the CDA also indicate that CDA is more applicable to the cases with higher concurrency such as disaster rescue and objects position. References 1. Naimi, M., Trehel, M., Arnold, A.: A log(n) Distributed Mutual Exclusion Algorithm Based on Path Reversal. Journal of Parallel and Distributed Computing, Vol. 34, No. 1. (1996)

10 Lodha, S., Kshemkalyani, A.: A Fair Distributed Mutual Exclusion Algorithm. IEEE Transaction on Parallel and Distributed Systems, Vol. 11, No. 6. (2000) Dijkstra, E.W.: Two starvation free solutions to a general exclusion problem. EWD 625, Plataanstraat 5, 5671 AL Nuenen, The Netherlands. 4. Chandy, K.M., Misra, J.: The Drinking Philosophers Problem. ACM Transactions on Programming Languages and Systems, Vol. 6, No. 4. (1984) Modi, P.J., Jung, H., Tambe, M., Shen, W.M., Kulkarni, S.: Dynamic Distributed Resource Allocation: A Distributed Constraint Satisfaction Approach. Proceedings of ATAL 01(Agent Theories, Architectures, and Languages). Seattle, WA, U.S.A. (2001) Yokoo, M., Durfee, E.H., Ishida, T., Kuwabara, K.: The Distributed Constraint Satisfaction Problem: Formalization and Algorithms. Journal of Knowledge and Data Engineering, Vol. 10, No. 5. (1998) Wu, Q., Huang, J., Bi, J.: Arbitrator-based Algorithm for Measurement Collaboration Problem. Proceedings of the 2003 International Conference on Computer Networks and Mobile Computing (ICCNMC 2003). Shanghai, China. (2003) Decker, K., Li, J.: Coordinated hospital patient scheduling. Proceedings of the 3rd International Conference on Multi-Agent Systems (ICMAS 98). Paris, France. (1998) Kitano, H.: RoboCup Rescue: A Grand Challenge for Multi-Agent Systems. Proceedings of ICMAS 00. Boston, Massachusetts, U.S.A. July (2000) 5-12