Class that manages updating diligent connections.
Singleton class that manages updating connections that require regular updates (diligent connections). The object is supposed to be updated in a regular interval (defined by get_interval()). Synapses that were not updated for longer than specified by get_acceptable_latency() will by updated. The maximum update latency that may occur can be retrieved through the get_max_latency() method.
Synapses that use the functionality of the update manager should be registered using the register_connector() method. Synapse Models that are instantiated using the DiligentConnectorModel do this automatically.
Initializing the Update Manager
If diligent connections are used the SLI function InitSynapseUpdater must be called before the first call to Connect. This is done automatically when the SPORE module is loaded but must be done manually after the NEST kernel has been reset using ResetKernel or its state has changed using SetKernelStatus. Therefore a line of code
<update_interval> <acceptable_latency> InitSynapseUpdater
is required, where <update_interval> is an integer value (default: 100) that defines the interval (in number of nest time steps) of invoking the update manager and <acceptable_latency> is an integer value (default: 100) defining the acceptable latency for synapses. These parameters can be used to optimize the simulation performance. Long update intervals are likely more time efficient, but require more memory. Equivalently, if using python, add a line
nest.sli_func(
'InitSynapseUpdater',<update_interval>,<acceptable_latency>)
after each call to ResetKernel / SetKernelStatus. InitSynapseUpdater may be called multiple times to change the parameters of the update manager, but must not be invoked again after the first call to Simulate (see: setup()).
Garbage Collection
ConnectionUpdateManager also provides a mechanism to removed synapses that become nonfunctional (garbage collection). The synapse must take care of invoking the garbage collector by calling the trigger_garbage_collector() method. After a call to this the synapse must return true
in its is_degenerated method. The synapse is not deleted immediately. If trigger_garbage_collector() was triggered from within the send function of the synapse the function is guaranteed to be finished before the synapse is removed. The send function may also be triggered again multiple times after a call to trigger_garbage_collector() before the synapse is finally removed. The synapse should in that case not call trigger_garbage_collector() again or change its behavior of returning true
from is_degenerated, as this would lead to undefined behavior.
The garbage collection feature should not be used together with structural plasticity mechanisms of NEST which delete synapses of the same synapse type, since these may interfere with the garbage collector. Using structural plasticity mechanisms which only add synapses is however possible.
- See also
- DiligentConnectorModel, SporeModule::InitSynapseUpdater_i_i_Function