multi threaded updates about morphologica HOT 2 CLOSED

Yes, up to the user. In the applications that have been written to date (ABRG-Models/BarrelEmerge, sebjameswml/RetinoTectal, ABRG-Models/Tesselations, stuartwilson/SelfOrganisingMaps) the usual approach is to compute a timestep of a simulation or model in each iteration of a main loop and then to update/render the visual model at every Nth loop. Depending on the sim, that might be every single loop, every 10th, 100th or whatever suits. We haven't used multithreading to run a simulation/model in one thread with a second thread used for visualisation. I personally make use of multithreading within my simulations, using OpenMP pragmas - I find that's the best way to get the most out of multi-core CPUs.

What makes you think that the Vector class is not thread safe?

from morphologica.

Yes, keeping threading external makes sense. In my case it's a real-time visualization of high frequency data so keeping a separate render loop is more appropriate.
-The underlying data structure of the Vector class is a std::array which if misaligned is subject to write tearing.
(Further the atomic read/write assumption (guaranteed on x86/x64 for the fundamental datatypes, int, double..) should probably be asserted if the Vector was to be used in a multi threaded context)

from morphologica.