sdleiF | ||
int isolation0 .. 1 (false/true) default=1 | slave isolationSlave simulator access is filtered to exclude object references across simulator boundaries and ensure a safe multithreaded operation. 1. Slave simulations objects can't be accessed from master while the slave simulator is running (except for Simulator.stop/start/running). 2. Master simulator objects can't be passed to slave simulators 3. Data objects (Vectors and Dictionaries) are passed by value rather than by reference (to make sure that no simulator contains a reference to another simulator's data). Setting isolation=0 disables these restrictions, which can lead to unpredictable results or crashes, but is sometimes useful for inspecting true object relationships. Sample cases: Simulator.slaves[0].stop(); - always permitted Simulator.slaves[0].expdef="prime"; - permitted if the slave simulator is not running var vec=[1,2,3]; Simulator.slaves[0].user=vec; vec.clear(); - vec has changed, user field is still [1,2,3] var vec=[1,2,GenePools[0]]; Simulator.slaves[0].user=vec; - user field becomes [1,2,null] (because master's GenePool object can't be passed to the slave) var g=Simulator.slaves[0].genepools[0][0].genotype; - but the slave's GenePool can be accessed from master (if the slave is not running at the moment) | |
int running RO | number of slaves runningNote that if running>0 then the number of running simulations can be outdated in the very moment you read this field, because the expdef can stop itself anytime. If running==0, then it is guaranteed to stay 0 until someone calls start() on some of the slave simulator objects. | |
int size0 .. 50 | number of slavesChanging this value will create/remove slave simulator objects as needed. | |
snoitcnuF | ||
function cancelAllEvents() | see cancelEventsFromSlave() | |
function cancelEventsFromSlave(Simulator)doesn't return a value | If the onSlaveStop() event is used to schedule work to a simulator, then you might want to cancel pending events when the experiment is aborted - otherwise it may be difficult to distinguish between self-stop events (called internally from the slave simulator to signal the job was completed) from abort-stop events (requested by the supervising simulator). Calling Simulator.slaves.stopAll(); Simulator.slaves.cancelAllEvents(); makes sure that no old events will be detected after that time point. Without cancelling, the old onSlaveStop() notification (the consequence of the abort-stop) might arrive after the next start() which may confuse the expdef code (slave events are asynchronous). | |
function create()returns Simulator | create a slaveIf you need to create AND store the reference to a newly created simulator object, then this function may be more readable than var s=Simulator.slaves[Simulator.slaves.size++]; | |
function get(int index)returns Simulator | getAccess the slave simulator object (Simulator.slaves[index] works, too). Important: Do not operate on a simulator that is currently running, always stop() it first. | |
function remove(untyped slave_index_or_slave_Simulator_object_reference)doesn't return a value | remove single slaveAlso calls stop() if the simulator is running. Events assocated with the simulator being deleted are cancelled, so the expdef will not see the usual onSlaveStop. | |
function removeAll() | remove all slavesSame as Simulator.slaves=0; | |
function startAll() | start all slaves | |
function stopAll() | stop all slaves |
Global context |