[IEEE 2006 Eighth International Symposium on Symbolic and Numeric Algorithms for Scientific...

Implementation and evaluation model for the asynchronous search techniques:from a synchronously distributed system to a asynchronous distributed system

Ionel MuscalagiuThe Faculty of Engineering of Hunedoara,The University ”Politehnica” of Timisoara.

Hunedoara, str. Revolutiei, nr. 5,[email protected]

Hong JiangComputer Science and Engineering,

University of South Carolina,Columbia, SC 29208, USA

[email protected]

Popa Horia EmilThe Faculty of Mathematics and Informatics,

The University of the West, TimisoaraTimisoara, V.Parvan 4, Romania

[email protected]

Abstract

The implementation of asynchronous search techniquescan be done in any programming language allowing a dis-tributed programming. Nevertheless, for the study of suchtechniques and for their evaluation, it is easier and more ef-ficient to implement the techniques under certain distributedenvironments, which offer various facilities, such as NetL-ogo.

The aim of this article is to introduce an as general aspossible model of implementation and evaluation for theasynchronous search techniques in the two possible cases:synchronous and asynchronous. In the case of the syn-chronous model, a synchronization of the agents’ executionis done after each computing cycle. This model, we believe,will allow the use of the NetLogo environment as a basicsimulator for the study of asynchronous search techniques.This model can be used in the study of agents behavior inseveral situations, like the priority order of the agents, thebehavior in the synchronous and asynchronous case and,therefore, leading to identify possible enhancements in theperformances of asynchronous search techniques. A firstset of experiments for two large families: the ABT familyand the AWCS family, based on the two proposed models ispresented in this article.

1. Introduction

The constraint programming is a model of the softwaretechnologies, used to describe and solve large classes of

problems as, for instance, search problems, combinatorialproblems, planning problems, etc. Lately, the A.I commu-nity showed a great interest for the distributed problem solv-ing using constraints and agents. The idea of sharing var-ious parts of the problem between agents that act indepen-dently and that collaborate by exchanging messages, in theperspective of reaching the solution, proved useful in itself,as it conducted to obtaining a new modelling type calledDistributed Constraint Satisfaction Problem(DCSP) [7].

There are more complete or incomplete asynchronoussearching techniques available, for the DCSP modeling[1],[3],[4],[6],[7], which allow the solving of a problemin this constraints network. The implementation of asyn-chronous search techniques based on distributed constraintscan be done in any programming language allowing a dis-tributed programming, such as Java, C, C++ or other. Nev-ertheless, for the study of such techniques, for their analysisand evaluation, it is easier and more efficient to implementthe techniques under certain distributed environment, whichoffer various facilities, such as NetLogo [8], [9], [10].

NetLogo, is a programmable modeling environment,which could be used for simulating certain natural and so-cial phenomena. It offers a collection of complex modellingsystems, developed in time. The models could give instruc-tions to hundreds or thousands of independent agents whichcould all operate in parallel. NetLogo is the next generationin a series of modeling languages with agents that beganwith StarLogo [8]. It is a medium written entirely in Java,therefore it can be installed and activated on most of theimportant platforms.

The aim of this article is to introduce an as general as

Proceedings of the Eighth International Symposium onSymbolic and Numeric Algorithms for Scientific Computing (SYNASC'06)0-7695-2740-X/06 $20.00 © 2006

possible model of implementation and evaluation for theasynchronous search techniques, in two possible cases: syn-chronous and asynchronous. In the case of the synchronousmodel, a synchronization of the agents’ execution is doneafter each computing cycle. This model can be used in thestudy of agents behavior in several situations, like the prior-ity order of the agents, the synchronous and asynchronouscase, leading, therefore, to identifying possible enhance-ments of the performances of asynchronous search tech-niques. Also, this model can be used in creating some ed-ucational software to be used in the study of asynchronoussearch techniques with agents by the students. For this pur-pose we have chosen the NetLogo environment, which is aprogrammable environment [8].

Based on the two models, the techniques from two largefamilies: the ABT family (which uses a static order for theagents) and the AWCS family (based on a dynamic orderingof the agents) were implemented. The experiments showthat the techniques have different behaviors, for the two im-plementation models.

2. The implementation of applications withagents in NetLogo

We are going to introduce the way of implementing, us-ing as a support Yokoo’s ABT algorithm [7], applied to theproblem of graphs coloring. Starting from this frameworkwe could implement, in a similar manner, any asynchronoustechnique, like AWCS [7], DisDB [1], DIBT [3], AAS [6].Mainly, the differences occur only in the procedures of ma-nipulating the messages, which could be adapted fluently.Also, starting from this framework, there could be made im-plementations for various versions of asynchronous searchtechniques, in the form of educational software that couldbe used for the purpose of studying the asynchronous searchtechniques by the students. Examples of implementationsfor these techniques are to be found on the site [9], [10].

2.1. The Implementation of the ABT familyalgorithms in NetLogo

The NetLogo world is made up of agents. Each agentis carrying out a task, all the agents are executing simul-taneously and concurrently. The NetLogo language allowsthree types of agents: turtles, patches and the observer. Theturtle type objects are agents that can move on in the NetL-ogo world, which is bidimensional and is divided in a gridof patches. Each patch is a square piece that represents thesupport on which turtle objects can move. The observerdoesn’t have a fixed location, it can be imagined as beingsituated above the world of turtles and patches objects. Net-Logo uses commands and reporters to tell the agents what

breeds [vertices ];edges is a list of lists: a 2D array indexed by who.;The value is 1 if there is a link, 0 otherwise.;domain is the list of allowed colors;globals [edges domain no-more-messages ...done];the-neighbors is a list of the initial neighbors nodes;extendend-neighbors is a list of the ’who’ of all;vertices that have a constraint with me;message-queue contains the incoming;messages. We take new ones out from the head.;nogoods is a list of inconsistent positions [0 1 1 0 ... ];where 0 is good and 1 is nogood.vertices-own [message-queue ...]

Figure 1. The NetLogo agents for the problemof graph colouring

to do (the commands and the reporters are NetLogo prim-itives). The commands are actions for the agents, but thereporters return certain values. The commands and the re-porters can be grouped in user procedures (the constructionto procedurename is used).

There are two aspects we will analyze. The first refers tothe way in which we will program the asynchronous searchtechnique and the way of representation in NetLogo. Thisis going to be approached using, generally, objects of theturtle type. The second aspect is more closely connected tothe problem to be solved and it refers to the way of inter-acting with the user. For this aspect, NetLogo offers objectsof the patch type, as well as various graphical controls. Inany case, the patch type objects will allow us to build theinterface of the application.

First, the agents will be represented by calling the breedtype objects. For our example, we will create the agentsby using the breeds [vertices] construction. This will allowus the programming of each DCSP agent according to theABT algorithm or any other technique. More exactly, wewill implement the three routines of the ABT algorithm, us-ing the NetLogo. These routines will be applied for eachasynchronous agent. We are further introducing the initialcode for the problem of graph coloring (fig. 1).

One can notice the way the agents called vertices arebuilt ( fig. 1). For each agent we declare the variables andthe structures of property data, which will be global vari-ables for the agents. Note a queue-type structure existingfor each agent. This queue (called message-queue) will con-tain all the ok and nogood type messages received by therespective agent. These queues have a very important rolein detecting the algorithm’s end. As we know, the ABT al-gorithm (as most asynchronous algorithms) ends at the mo-ment a pause appears in message sending.

Another important fact is the possibility of defining thevariable owner of each turtle type object. These owner vari-


to updateset no-more-messages trueask vertices [

if (not empty? message-queue)[set no-more-messages false]]

if (no-more-messages) [stop]ask vertices [handle-message]. . .

end

Figure 2. The NetLogo update procedure

ables allow the complete and correct construction of thesimulated agents. There is a very interesting thing, an agentsimulated by a turtle that could access owner variables foranother agent, so that the agents could cooperate and nego-tiate between them. This thing allows a possible simulatorto inspect the agents values by other agents.

As to the interface aspect, we will use for the graphicalrepresentation of the nodes positions a patch for each. Itis recommendable to create a procedure of initializing thedisplay surface for the agent values. [9],[10].

In order to start running the algorithm we can build a goor update type button to which we attach a NetLogo proce-dure (fig. 2), representing some kind of ”main program”, acommand center. Within such a procedure, which is sup-posed to run continuously (until the queues run empty ofmessages), the message queue is checked for each agent.For standardizing reasons, we defined another procedure,called handle-message (fig. 3), in charge with handling themessages that are specific to the ABT algorithm and to anyother asynchronous technique. For another technique onecan adapt this procedure in order to handle such messages.We introduce hereinafter the two procedures, maybe themost important ones from the point of vue of the way ofimplementing in NetLogo the asynchronous way of work-ing with messages, which is characteristic for asynchronoussearch techniques (fig. 2 and fig. 3/fig. 4).

One can notice the call ”ask vertices”, which allows theasynchronous execution of the next calculations for eachagent, with a synchronization after each activation of theagents. This feature of the ask command will allow usto build a synchronously distributed system. The messagehandling procedure is presented in fig. 3 and fig. 4.

The main target is to take a message from the messagequeue, identify the type of message and then call the pro-cedure for processing the respective message. The two pro-cessing procedures for the ok or nogood messages can beimplemented according to the algorithm for which they areused. The message manipulation procedure which is exe-cuted by each agent can extract and treat a single message orcan extract all the messages treating them globally. In fig. 3is presented the treating routine for a single message, and

to handle-messageif (empty? message-queue) [stop]set msg retrieve-messageif (first msg = ”ok”)[

set messages-received-ok messages-received-ok + 1handle-ok-message msg]

if (first msg = ”nogood”)[handle-nogood-message msgset messages-received-nd messages-received-nd + 1]

end

Figure 3. The message handling procedure

to handle-message [msize]set n 0while [not empty? message-queue and n < msize][ set msg retrieve-message

if (first msg = ”stop”)[stop ]

if (first msg = ”ok”)[set messages-received-ok messages-received-ok + 1handle-ok-message msg ]

if (first msg = ”nogood”)[handle-nogood-message msgset messages-received-nd messages-received-nd + 1]

set n n + 1]check-agent-view

end

Figure 4. The message handling procedure(message-management)

in fig. 4 the variant for complete treating of messages. Thevariant for complete treating of messages can be adapted soit would treat only partially the messages, in packets of adimension given by the value of the message-size variable.

2.2. The evaluation of the asynchronoussearch techniques

Another important thing that can be achieved in NetL-ogo is related to the evaluation of the asynchronous algo-rithms. To evaluate these techniques there are many waysof measuring that ensure a certain independence from theprogramming languages used to implement them. Thesemeasurement units allow the evaluation of asynchronoussearch techniques according to many criteria, such as lo-cal and global effort of the agents, network loading due tothe message exchange.


2.2.1 Costs due to the communication

The first criterion is that of the costs due to the communi-cation of information between different parts of the algo-rithm. The asynchronous behavior that we’ve met in theasynchronous searching techniques is influencing in a sub-stantial way the communication costs. The asynchronousalgorithms are characterized by the usage of messages fromthe agents during the solution seeking time. The monitor-ing of the received messages allows the evaluation of globalcharging of the network.

The model presented within this paper allows the mon-itoring of the various types of messages used by the asyn-chronous search techniques. This can be done by using afew global variables that are attached to agents. For in-stance, for the model presented, it can be used a variableproprietary to each agent messages-received-ok, variablethat must be incremented when generating and sending amessage. This variable is incremented in the routine of ma-nipulation of the messages of the type handle message.

2.2.2 Time costs

The time complexity is given by the time that is necessaryfor calculating, and it is expressed in the terms of the mes-sage with the longest treating time that the computationinvolves. This time complexity is comparable to the timecomplexity of the algorithm for the sequential classic case,but this is not really a time measurement.

The asynchronous search techniques are evaluated bycertain authors [7], using for the time complexity, as a mea-surement unit, the cycle. A cycle consists in the necessaryactivities that all the agents need in order to read the incom-ing messages, to execute their local calculations and sendmessages to the corresponding agents. This measurementunit assures a certain independence to the local conditionsand the ones existing in the distributed environment, impos-sible to be influenced by the delays that occur. This is a verygood measurement unit for the environments that simulate areal distributed environment. For the model featured in thisstudy, the number of cycles can be determined by using aglobal NetLogo variable. This variable will be incrementedin the update routine.

The time complexity can be also evaluated by using thetotal number of constraints verified by each agent. There isa measurement of the global time consumed by the agentsinvolved. It allows the evaluation of the local effort of eachagent. The number of constraints verified by each agentcan be monitored using the variables proprietary to eachagent (nr-constraintc). A counter like that is incrementedwithin the routines check-agent-view, for verifying the con-sistency of agent’s value. The counting of the concurrentconstraints induced in [5] is a more complicated problem.This can be done by introducing a variable proprietary to

each agent, called AgentC-Cost. This will hold the numberof the constraints concurrent for the agent. This value issent to the agents to which it is connected through the mes-sages. Each agent, when receiving a message that containsa value SenderC-Cost, will update its own monitor AgentC-Cost with the new value according to the algorithm in [5].

2.3. Implementation and evaluation schemefor asynchronous search techniques

In brief, starting from the previous analysis and takinginto account the particularities of the various asynchronoussearch techniques, we give hereinafter a diagram of asyn-chronous algorithm implementation for NetLogo.

P1. Identifying the objects of DCSP application.

Model examples can be used breeds [queens] (formodeling the agents associated to queens from theproblem of the n queens) or breeds [vertices] (for mod-eling the agents in the problem of graph coloring).

P2. The messages manipulation.

The simulation of message queues for each agent canbe done using NetLogo lists, for which we define treat-ing routines appropriate for the FIFO principles. Thosestructures store the messages received by each agent.

P3. Initializing the application and each agent. The initial-ization of the application supposes the construction ofagents and the workspace for them. Along with thecreating of the agents the required initializations arealso done. Usually the working context of each agentis initialized (current view), the message queues, thevariables that count the effort made by each agent.


P4. The ”Main program” of the application. For run-ning the application we propose the introduction of agraphic object of the button type and setting it’s foreverproperty. That way, the attached code, in the form ofa NetLogo procedure (which is applied to each agent)will run continuously, until the emptying of the mesagequeues and reaching the stop command. The solutionpresented is based on the usage of the ask command.

Another important observation is regarding the attachmentof the graphic object to the observer. The usage of this so-lution allows us to obtain a implemention solution with thesynchronization of the agents’ execution. In that case, theobserver will be the one initiating the stopping of the exe-cution of the DCSP application.

2.4. Detection of termination for asyn-chronous algorithms

For most of the asynchronous search techniques, the so-lution is generally detected only after a break period insending messages (this means there is no message beingtransmitted, state called quiescence). More CSP distributedtechniques detect silence in the transmission of messagesby using the general techniques in [2].

When solution exists: it’s based, in NetLogo on the de-tection of a break in messages sending process. This situa-tion could be solved by verifying the message queues whichshould be empty. Also a difference should be made betweentwo cases:

• The synchronous case, in which a synchronization ofagents’ execution is done. After such synchronizationone could verify if all the message queues are empty.This allows the break-up of the execution and the print-ing of the solution.

to updatehandle-messageif (sum (values-from vertices [gt]) = num-vertices)

[stop]end

Figure 5. The new update procedure

• The asynchronous case in which each agent executesconcurrently its calculations under no existing syn-chronization. This situation is solvable by introducingcertain indicators, which could keep, in any moment,the state of communication channels for each agent(true, if there are no messages and false if there aremessages). If in a certain moment all indicators aretrue, we could stop the execution of the programs.

Regarding the case in which there is no solution, an agentwill detect this situation through the occurrence of an emptynogood.

2.5. The extension of NetLogo environmentfor allowing the asynchronous work

Usually, most of the simulators are active with more ex-ecution threads on the same computation system, each withan execution thread for each agent. The application is ac-tive in more cycles, a cycle consisting in that needed periodfor each agent to receive messages, execute the local calcu-lations and send messages. Practically, after each cycle, asynchronization of agents takes place, being expected thateach one would finish its cycle. It goes the same with Net-Logo. The main procedure of activation that we’ve calledupdate, when active, it corresponds to the cycle notion. Forthis routine to be active until the determination of the solu-tion or solution’s inexistence, it is attached to an observer-type button with the ”forever-button” property set. Basi-cally it requests, through the ask command, the manipula-tion of the messages from the message queues. Each con-current and asynchronous agent extracts, sends messagesand executes its local calculations, but the ask commandmakes, in the end, a synchronization. This mechanism al-lows the definition of a system behavior synchronously dis-tributed.

We ask how could our model be adapted in order to func-tion as asynchronous as possible. We further present a so-lution based on the usage of NetLogo elements. The solu-tion is given by the usage of turtle forever-buttons, buttonsthat aren’t attached to the observer anymore. Meanwhilethe usage of ask command is given up in order to executethe routine of manipulating the messages, this routine beingexecuted for each agent (by the turtle-type ”forever-button”,as we can see in fig. 5.

One can notice we renounced to use the ask command.


to handle-messageif not empty? message-queue[ set msg retrieve-message

set gt 0if (first msg = ”ok?”)[ handle-ok-message msg]

if (first msg = ”nogood”)[ handle-nogood-message msg ] ]

if (empty? message-queue)[ set gt 1

stop ]end

Figure 6. The new handle-message proced.

In such a situation, the detection of algorithm’s ending ismade through indicators (called gt in the upper sequence),attached to each agent. These indicators memorize in anymoment the state of the message queue attached to thatagent. The stopping condition is that, simultaneously, allindicators (for all agents) to be true. We present in fig. 6the manipulating messages routine that we’ve adapted forthe asynchronous case. We notice the fact that if the mes-sage queue is not empty, the gt indicator becomes 0, and ifthe queue is empty it becomes 1. This is needed becausethe agents send messages asynchronously and concurrentlyto other agents, in that way at various time moments themessages queue passes through different states.

3. The architectures of the two models pro-posed in NetLogo

Starting from what we have presented in the previ-ous paragraphs, we may conclude by presenting two dis-tributed systems architectures, applicable to the asyn-chronous search techniques (fig. 7 and fig. 8 ).

The two models are defined by a few common elements.At first, the agents’ simulation is realized in the same way,each agent being simulated by using breed type objects. Af-ter that, the agents may have attached a general routine oftreating messages (in fig. 7 and fig. 8 handle-message pro-cedure). Finally, the procedures of treating the messages areimplemented the same way for the two systems. The maindifference between the two systems consists in the detectionof each implemented technique.

3.1. The architecture of a synchronouslydistributed system

The first implementation model is different from theasynchronous one by using the observer in identifying thebreak when messages are sent. This is performed by attach-ing the update routine to a button attached to the observer.

The second element that differes in the two models is thatof using the ask command for executing the handle message

routing each agent has. This solution will lead to synchro-nizing the execution of the agents.

Figure 7. The architecture of a synchronouslydistributed system

3.2. The architecture of an asynchronouslydistributed system

The second one is remarkable by giving up the observerand attaching the update routine to each agent. This way theexecution of the handle message routine is not done throughthe ask command anymore, being executed for each agent(turtle) by the turtle type button with the forever-buttonproperty set.

Figure 8. The architecture of an asyn-chronously distributed system

3.3. The difference between the two models

Usually most of the simulators run more executionthreads on a single computing system, an execution threadfor each agent. The application runs in several cycles, acycle being the period needed for each agent to receive


messages, to execute the local calculations and send mes-sages. We encounter this situation in NetLogo too. A callof the main procedure named here update, is correspond-ing to the notion of cycle. For this routine, to run until thesolution is found, it is attached to an observer type button,with the forever-button property set. Each agent, concurrentand asynchronous extracts, sends messages and executes itslocal calculations, but the ask command does, at the end, asynchronization. The mechanism allows the defining of asynchronously distributed system behavior.

This model can be transformed in a model that couldfunction as asynchronous as possible. The solution is givenby using the second solution of detecting the end of the al-gorithm and using the forever turtle type buttons, buttonsthat are no longer attached to the observer. At the sametime the usage of the ask command for performing the mes-sage manipulation routine is given up, this being executedfor each agent by the forever turtle type button (fig.8).

4 Experimental results

In this paragraph we will present our experimental re-sults, obtained by implementing and evaluating the asyn-chronous search techniques we introduced. In order to makesuch estimation, these techniques have been implemented inNetLogo 3.0 [8], [9], [10]. The evaluation was done usingthe two models proposed in this article.

The asynchronous search techniques were applied to aclassical problem: the problem of coloring a graph. Wetook into consideration two types of problems (we kept inmind the parameters n-number of knots/agents, k=3 coloursand m-the number of connections between the agents). Weevaluated three types of graphs: graphs with few connec-tions (sparse problems, having m=n x 2 connections) andgraphs with a special number of connections (m=n x 2.3and m=n x 2.7 connections, called difficult problems). Foreach version we carried out a number of 100 trials, retainingthe average of the measured values (for each class 10 graphsare generated randomly, for each graph being generated 10initial values, a total of 100 runs).

In order to make the evaluation of the asynchronoussearch techniques, the message flow was counted, the num-ber of verified constraints (that means the local effort madeby each agent) and the number of concurrent constraintsverified (defined in [5]], noted with c-ccks) necessary forobtaining of the solution.

4.1 AWCS family

In the AWCS family there are many variants that arebased on building of efficient nogoods (nogood learning)or on storing and using those nogoods in the process of se-lecting the values (nogood processor). In this article was

n=30 n=40m=nx2 m=nx2.3 m=nx2.7 m=nx2 m=nx2.3 m=nx2.7

AWCS1

Nogood 575 1244 3639 713 7664 24652Ok 1864 3440 7624 2403 19894 51132

Constr. 2913 6231 14482 3747 32492 102388c-ccks 802 1545 4351 824 6849 21888

AWCS2

Nogood 502 1443 12181 733 13029 93259Ok 1625 3943 23964 2422 33499 185845

Constr. 2628 6972 45813 4163 52007 387355c-ccks 662 1606 12512 793 10115 73099

Table 1. The results for AWCS versions

implemented the basic variant proposed in [7] to which wasapplied the nogood learning technique from [4] obtainingan improved version. For this variant were implemented aversion in which each agent treats entirely the existing mes-sages in its message queue (noted AWCSk). For that vari-ant were implemented two versions corresponding to thetwo models proposed in this article: a version based on themodel with synchronization (AWCS1) and a version basedon the asynchronous model (AWCS2).

In table 1 are presented the values obtained for theAWCS versions analyzed. Analyzing the results from ta-ble 1, we can remark the fact that synchronization ofthe agents execution reduced the local effort made by theagents. But, as the dimension of the problems increases,the asynchronous variants AWCS2 required much greaterefforts compared to the variant with synchronization. Bigdifferences in the local effort occur especially for the diffi-cult problems. Still we remark that for problems of sparsedensity (m= n x 2.0) the asynchronous variants had almostequal costs to the synchronous variants, even lower efforts.

In the case of the message flow, the behavior remarkedregarding the computing effort has maintained almost thesame, synchronous variant requiring a message flow lowerthat the asynchronous variants. The message flow increasedfor the synchronous variant together with the increase ofdimension for the solved problems.

4.2 The ABT Family

Starting from the ABT kernel, by eliminating the out-dated information we can obtain two important techniques:the Asynchronous Backtracking and the Distributed Dy-namic Backtracking [1]. Those two techniques based ona static order are analyzed in order to see the effect of syn-chronizing the agents. Unlike the AWCS technique, herewere implemented the versions in which each agent treatsat each cycle just one message from its message queue. Foreach of the ABT and DisDB techniques were done two im-plementations corresponding to the two models obtained:

• a version based on the model with synchronization:noted with ABT1 and DisDB1.

• a version based on the asynchronous model: notedwith ABT2 and DisDB2.


(a) ABT


ABT1

Nogood 336.2 399.6 481.8 3883.1 3910.8 3936.2Ok 580.4 1231.2 1615.4 8578.2 9881.6 12343.8

Constr. 23176 61287 80834 957934 968618 938790c-ccks 6543 9543 16572 147128 151290 123501

ABT2

Nogood 203.1 225.7 366.9 3181.5 3369.3 2196.5Ok 343.7 886.5 1438.4 6518.7 7619.6 9943.5

Constr. 17417 43436 69332 763992 796723 698240c-ccks 4468 6108 7593 90601 91034 45264

(b) DisDB


DisDB1

Nogood 138.7 158.6 316.9 2803.3 2926.6 3104.4Ok 300.0 528.1 722.8 6855.1 6998.2 7235.8

Constr. 18548 22969 40841 603288 667576 778016c-ccks 4526.5 5281.7 8112.3 124728 329981 154409

DisDB2

Nogood 83.1 109.6 216.4 2785.6 2801.7 2983.6Ok 213.7 331.8 556.0 6518.7 6645.2 6878.0

Constr. 12117 16549 29850 585992 602376 655243c-ccks 2468.4 2997.2 3963.0 70605 76541 82785

Table 2. The results for ABT and DisDB versions

In table 2(a) are presented the values obtained for theABT versions, and in table 2(b) those for the versionsDisDB. The two techniques based on a static order behaveddifferent from the AWCS technique. The lower local effortwas obtained for the asynchronous variant, the variant withsynchronization required the checking of a much greaternumber of constraints. Also, the lowest message flow wasobtained for the synchronous variant.

5. Conclusions

The NetLogo environment is good for building softwarepackages (simulators) meant for testing and evaluating theasynchronous search techniques. The environment and thelanguage backing it have enough resources to implementany DCSP technique, for any problem that has to be solved.

The model we suggested supposed the identification ofthe NetLogo objects needed for the implementation of theasynchronous search techniques (agents, messages, mes-sage queues,etc), as well as of the user interface. Also, wetried to measure the costs of obtaining the solution, usingdifferent measurements, in order to estimate and assess theperformances of the asynchronous search techniques.

The two models, one synchronously distributed and theother asynchronously distributed allow the correct evalua-tion of the asynchronous search techniques performances.It is possible to make comparisons with the asynchronoussearch techniques in order to see which implementationversion is preferable: synchronous or completely asyn-chronous. We could also study the agents’ behavior inseveral situations and the identification of certain enhance-ments for the performances of asynchronous search tech-niques.

We remark two types of behavior and, as a consequence,two classes of asynchronous search techniques (amongthose we have evaluated). The techniques from the AWCSfamily, based on a dynamic order for the agents, requiredlower costs for obtaining the solution in the case of syn-chronization of the agents’ execution. The second categoryof techniques, those from the ABT family behaved differ-ent, requiring lower costs in the asynchronous case than inthe case of the synchronization of the agents’ execution. All

these techniques have used a static order for the agents.The analysis of two large families of asynchronous

search techniques shows that there are different behaviorsfor the agents, which can influence in a good or in a badmanner the costs for obtaining the solution. Thus, an anal-ysis in a preprocessing phase is required. Such an analysiscould be done through the implementation of these tech-niques in NetLogo and by identifying those techniques thatrequire lower costs, for the desired situations.

As a general conclusion, we think that the model weachieved can be used for the study and analysis of the asyn-chronous search techniques.

References

[1] C. Bessiere, I. Brito, A. Maestre,P. Meseguer, AsynchronousBacktracking without Adding Links: A New Member in theABT Family. Artificial Intelligence, 161:7-24, 2005.

[2] K. M. Chandy, L. Lamport. Distributed snapshots: Determin-ing global states of distributed systems, ACM Transactions onComputer Systems, 3(1), 63-75, 1985.

[3] Y. Hamadi, C. Bessiere, J. Quinqueton.Backtracking in Dis-tributed Constraint Networks. In Proceedings of the 13th,ECAI , Brighton, UK, pag. 219-223, 1998.

[4] K. Hirayama, M. Yokoo.The Effect of Nogood Learning inDistributed Constraint Satisfaction. In Proceedings of the20th IEEE International Conference on Distributed Comput-ing Systems, 169-177, 2000.

[5] A. Meisels, E. Kaplansky, I. Razgon, and R. Zivan. Compar-ing performance of distributed constraints processing algo-rithms. Notes of the AAMAS’02 workshop on DistributedConstraint Reasoning, pages 86-93, Bologna, Italy, 2002.

[6] Silaghi M.C., D. Sam-Haroud, B. Faltings. AsynchronousSearch with Aggregations.In Proceedings AAAI’00, 917-922.

[7] M. Yokoo, E. H. Durfee, T. Ishida, K. Kuwabara. The dis-tributed constraint satisfaction problem: formalization andalgorithms. IEEE Transactions on Knowledge and Data En-gineering 10(5), page. 673-685, 1998.

[8] U. Wilensky. NetLogo itself: NetLogo. Available:http://ccl.northwestern.edu/netlogo/. Center for ConnectedLearning and Computer-Based Modeling, NorthwesternUniversity. Evanston, 1999.

[9] MAS NetLogo Models-a. Available:http://jmvidal.cse.sc.edu/netlogomas/.

[10] MAS NetLogo Models-b. Available:http://ccl.northwestern.edu/netlogo/models/community.


[IEEE 2006 Eighth International Symposium on Symbolic and Numeric Algorithms for Scientific...

Documents

Transcript of [IEEE 2006 Eighth International Symposium on Symbolic and Numeric Algorithms for Scientific...