Multi-Agent Non-Deterministic Counting

The next set of tests was aimed at analysing the effect of non-determinism when the number of agents increases. Similarly to the deterministic test, non-determinism was added to the scenario with two counters, one deterministic to act as a stop condition and the other which non-deterministically increments.

The agents were asked to count to 5, the results are shown in Figure 11.18 showing time and Figure 11.19 showing the number of states. As expected, the rise in time and the number of states increases at an exponential rate until memory was exhausted after

Figure 11.17: Graph showing the the number of states used when an object counts to 1,000 and broadcasts this count to an increasing number of agents

5 agents non-deterministically counting to 5.

The expected results for these tests were that the number of agents would expo- nentially increase the depth of the model (number of states in a trace run through the model) and the size of the count would exponentially increase the amount of branch- ing that occurs in the model. Based on these assumptions it was decided to keep the count small, since adding more agents will also add more non-determinism, i.e., 1 agent counting to 10 would have much less non-determinism than 2 agents counting to 10. The rise in number of states was however far greater than anticipated. We identified in Figure 11.19 that if a task is distributed across multiple agents then the number of states required reduces. This posed a question of whether this would still be the case with multiple agents, e.g., if one agent counts to 800 with a non-deterministic choice at each count, could 5 agents count to 160 with the same non-deterministic choices using fewer states?

To answer this question another simplePROMELA example was created, based on the one used in Section 11.1.3. The simplePROMELAexample uses 3 variables: 1 acts as a deterministic count (variablea) and a variable for each agent (variablesbandc) to non-deterministically increment on each count. There is a process for each agent and a process for the scheduler to synchronise the agents. The scheduler loops 6 times, each time incrementing countera. On each iteration of this loop the scheduler hands control of the cpu using a variableturn to each agent, where they have a choice to increment their counter. Below isPROMELA code for a scheduler of an example model:

int a = 0; /*deterministic counter*/

int b = 0; /*agent 1’s non-deterministic counter*/ int c = 0; /*agent 2’s non-deterministic counter*/ mtype = {Environment, ag1, ag2}

mtype turn = Environment; /*The scheduler*/

active proctype proc_Environment(){ /*Loop through all agents*/

do

/*Agent 1*/ if

::(turn == Environment)-> /*if at start, start agent*/ if

::(a == 0)-> run proc_agent1(); ::else-> skip;

fi;

/*Give agent 1 control of cpu*/ turn = ag1;

fi;

/*Agent 2*/ if

::(turn == Environment)-> /*if at start, start agent*/ if

::(a == 0)-> run proc_agent2(); ::else-> skip;

fi;

/*Give agent 2 control of cpu*/ turn = ag2; fi; :: else-> break; od; } proctype proc_agent1(){ do ::(a < 5)-> if /*Increment counter*/ ::(turn == ag1)-> b = b+1; /*Do not increment counter*/

::(turn == ag1)-> skip; fi;

/*hand control back to environment*/ turn = Environment; :: else-> break; od; } proctype proc_agent2(){ do ::(a < 5)-> if /*Increment counter*/ ::(turn == ag2)-> c = c+1;

/*Do not increment counter*/ ::(turn == ag2)-> skip; fi;

/*hand control back to environment*/ turn = Environment;

:: else-> break; od;

}

Through using this simplified version of the Brahms PROMELA implementation we were able to test if it was a problem with the Brahms implementation or whether

PROMELAhad state reduction techniques for handling large non-determinism on sin- gle variables. The results of this PROMELAtest was that the memory was still being exhausted for small counts, e.g., counting to 5. To further test this hypothesis another simplerPROMELAexample was created that did not reflect the Brahms semantics but performed the same task. This simplified version compressed the agents and scheduler into a single process. This was done by using a do-while loop to increment the deter- ministic counter with nested if-statements to represent the agents’ choice to increment their counters. The code is as follows:

int a = 0; /*deterministic counter*/

int b = 0; /*agent 1’s non-deterministic counter*/ int c = 0; /*agent 2’s non-deterministic counter*/ active proctype proc_Environment(){

do ::(a < 10)-> /*Agent 1*/ if /*Increment counter*/ ::(true)-> b = b+1; /*Do not increment counter*/

::(true)-> skip; fi; /*Agent 2*/ if /*Increment Counter*/ ::(true)-> c = c+1; /*Do not increment counter*/

::(true)-> skip; fi;

/*Increase deterministic counter*/ a = a+1;

:: else-> break; od;

}

This simplified version of the multi-agent non-deterministic count showed that 5 agents could count to 10 before all available memory would be, compared to 5 for the previous version. Overall the results of these tests show that the performance of the Brahms

Figure 11.18: Graph showing the verification time of an increasing number of agents non-deterministically counting to 5

Figure 11.19: Graph showing the number of states used when an increasing number of agents non-deterministically count to 5

implementation is not as poor as first thought but that restructuring the agents into a single process (which is possible) could provide a much needed performance boost.