6.5 Agent Update Order
6 SCL Design Notes
6.3 2D Space/2D Agents
It is in the nature of the SCL model that agents (particles) are created and destroyed on an on-going basis during the simulation. This led to two separate problems.
Firstly, there is a general problem with Swarm that the application will crash if any object which is being probed (with a probeDisplay) is dropped. I have not attempted to provide any fix for this. It can be worked around, as already explained, by taking care to ensure that probeDisplay windows on particles are created only while the simulation is stopped, and are dropped before the simulation is continued. It would probably be possible to enforce this restriction from within the program; but, since this will probably be fixed ``properly'' in a future Swarm release, I did not consider that the effort was justified.
Secondly--and more seriously--the scheduling of model execution can be disrupted, leading to a crash, if agents are dropped during the simulation. This arises where a list of agents is being traversed (via a ForEach: method), and, within that traversal, an object is removed from the list. This is a consequence of the way lists are currently implemented in Swarm. Again, the restriction should be removed in a future Swarm release. However, since this behaviour was essential to SCL it was absolutely necessary to develop a workaround.
The strategy adopted is to have a ``manager'' object for the agents. This accepts requests to create or drop agents and effectively puts these requests into a queue. A certain amount of processing of the request can be (indeed, must be) done immediately; but the list of agents which is potentially being traversed by ForEach: is not immediately updated. Instead, that final update is deferred until some time later, when it is known to be safe.
This mechanism is implemented in SCL via a generic AgentManager class; this is separately instantiated to handle each of the different classes of agent required (one for bonds, and one each for the different particle classes, including holes).
This mechanism works, but is quite cumbersome and somewhat error prone (care is required in ensuring that the various queues are processed when necessary but also when safe). It should probably be dispensed with as soon as Swarm can handle agent dropping safely. On the other hand, this mechanism does offer an interesting potential (not currently exploited) for improving performance. The AgentManager could quite easily arrange to cache dropped agents, and recycle them in response to new creation requests. This might significantly reduce the overhead associated with creating and/or dropping agents. However, some care would be required to ensure that this ``pseudo'' creation was equivalent to ``genuine'' creation. This latter issue is potentially complicated by Swarm's powerful, but complex, ``create phase protocol''.
6.5 Agent Update Order
6 SCL Design Notes
6.3 2D Space/2D Agents
Copyright © 1997 All Rights Reserved.
Timestamp: Tue Dec 31 19:40:38 GMT 1996