Introduce the main modular simulator interfaces and documentation
This change introduces the two main interfaces for the modulator
simulator approach. It also introduces a new module which will contain
all files introduced for the modular simulator, making differentiation
between legacy code and new implementations easier. It further starts
the documentation of the new approach.
The ISimulatorElement interface is for any element that wants to
take part in the simulator loop. It requires to define a
scheduleRun method, which allows the element to decide whether
it needs to run at a specific time step. If it does, it adds one or more
function pointers to the run queue (registration function is passed
as argument, allowing flexibility in the exact implementation of the
run queue and the number of registered function pointers). The
Simulator can hence pre-compute all run function needed in one or
more future simulation step, allowing it to then run through the
function pointers without the need for branching
The ISignaller interface is used to spread information about upcoming
steps. Signallers are guaranteed to be ran before the elements
get queried about running at a specific step. This allows, for
example, to signal to the element that a neighbor-searching step
or a logging step is about to happen. Elements can register to
signallers they are interested in being notified by.
This commit is part of the commit chain introducing the new modular
simulator. Please see docs/doxygen/lib/modularsimulator.md for details
on the chosen approach. As the elements of the new simulator cannot all
be introduced in one commit, it might be worth to view Iaae1e205 to see
a working prototype of the approach.
Change-Id: Iefc9a0c729223cc5da0b500f0b410027c14d1f68