(Description of the synchronization between real-time, physics simulation and controller-threads)

The probably most intuitive way of realizing the simulation woul dbe to have one thread that regularly performs time-steps (synchronized with the real time) of the physics engine and every controller running in an extra thread accessing the simulated world. Ensuring the thread-safety of the simulation access with mutexes would probably give good results. However, it should also be possible to stop and continue the simulation from outside without effecting the controllers. With the given method it's difficult or even impossible to stop all threads with the ability to continue them at the same place.
For this reason (and some others) SimulatorBOB uses another strategy: There exists a single instance per simulation of RCSimSyncHandler. Every thread that wants to interfer with the simulated world has to request an access (RCSimSyncHandler::RequestAccess) specifying the desired time stamp and - provided that the access is possible to be granted (i.e. the requested time has not already passed) - has to wait for this access to be granted and - after completion the interaction with the simulation - free the access again so the simulation can continue either by giving acces to another accessor or performing a new time stamp if required the next access request if the difference between requested and current time is greater than a time step.
This methods would allow the simulation to adapt the time stamps in such a way that every accessor can access the simulation at exactly the desired time. However, since a constant time step is important for stability of the physics engine, every time request is effectively rounded internally.
The synchronization with the real time takes place in the SimulationView since the view - or actually the human user looking at the view - is the onlyone interested in such a synchronization. Internally every component uses the simulation time and doesn't care about the real time. The SimulationView simply waits with freeing the world access until the real time is synchronized with the simulation time. If the simulatin time is already behind it frees immediatly - in this case the computer is not fast enough and the simulation runs slower (as displayed in the status bar).