我正在使用 OpenGL 开发一款安卓游戏，我有一个游戏更新线程和一个 opengl 渲染线程。
目前我让它们同步，例如 update() 和 render() 共享一个锁，我基本上在更新和渲染之间来回 ping/pong。这与连续运行更新和渲染本质上是一样的，因为一个总是在等待另一个。
在我的游戏中，每个对象都是一个可渲染对象，所以我想与其拥有一个全局锁，不如让每个可渲染对象拥有自己的锁。这样，每当更新正在更新某个对象时，渲染器就可以渲染任何其他对象，反之亦然。如果一个对象在渲染或更新线程试图访问它时被锁定，它可以跳过它并将它推到队列的后面(假设更新/渲染的顺序无关紧要)。
现在这个游戏是我第一次处理同步问题，所以我想知道在每一帧中有这么多锁不断地锁定和解锁是否会有任何严重的性能问题？这是同步更新和渲染线程的正常方式，还是我忽略了一些明显的缺陷？
我能想到的唯一缺陷是渲染器可能从游戏的两个不同“步骤”绘制对象，因为当它绘制时，一些对象将在游戏步骤 N 上，而其他对象将被更新并成为在第 N+1 步，但我不知道这对我的特定游戏是否会很明显。
感谢您的任何想法。
最佳答案
我不是游戏开发者，但从 Replica island 的制造者那里看到了这篇帖子:Rendering With Two Threads
GameDev StackExchange 上的这个帖子也可能有帮助:https://gamedev.stackexchange.com/questions/95/how-many-threads-should-an-android-game-use
关于android - 渲染/更新同步 : One Lock Per Renderable?，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9563806/