This question already has an answer here:
I am programming a game engine as a hobby project, and I would like to separate physics and drawing into two separate threads. The position vectors of entities are subject to modifications by the physics thread, while the drawing thread only requires read access. In pseudocode:
Physics thread: loop ... read entity position compute new position for entity write entity position ... end Drawing thread: loop ... read entity position render entity ... end
Separating the drawing and physics into two threads allows for the decoupling of the physics update rate from the drawing framerate. This enables things like easy slow motion effects and variable frame rates, but also makes it possible for the physics thread to modify a position vector at the exact same time as the drawing thread is reading the same value.
I hope I could get away without using mutexes, locks or other concurrency controls for the position vectors. The validity of the position data is not critical, and small errors resulting from non-atomic access are tolerable. My experience with concurrent programming is however fairly limited, and I fear that there are other issues stemming from asynchronous access that I am not aware of. What are the drawbacks of this approach? What alternatives are there?
I am programming in C++11 (using std::thread), on a multi-core x86 PC.