I’m working on an android game with OpenGL, and I have a game update thread and an opengl render thread.
Currently I have them synchronized such update() and render() share a single lock, and I basically ping/pong back and forth between update and render. This is essentially the same as running update and render serially, as one is always waiting on the other.
In my game every object is a renderable, so I was thinking instead of having one global lock, I could let each renderable object have its own lock. That way whenever update is updating some object, the renderer can be rendering any of the other objects and vice versa. If an object is locked when either the render or update thread tries to access it, it can just skip it and push it to the back of the queue (assuming the order of update/render does not matter).
Now this game is my first time I have dealt with synchronization issues, so I was wondering if there would be any serious performance issues with having so many locks constantly locking and unlocking during every frame? Is this a normal way to synchronize update and render threads, or am I overlooking some obvious flaw?
The only flaw I can think of with this is that the renderer could be drawing objects from two different ‘steps’ of the game, as while it’s drawing some objects will be on gamestep N, while others will have been updated and be on step N+1, but I don’t know if that would be noticeable for my particular game.
Thanks for any thoughts you may have.
I’m not a game developer but have come across this post from the maker of Replica island: Rendering With Two Threads
Also this thread on GameDev StackExchange might be helpful: https://gamedev.stackexchange.com/questions/95/how-many-threads-should-an-android-game-use