title: Taking advantage of multithreading with openGL
body: <p>Talking in context of a game based on openGL renderer :</p>
  
  <p>Lets assume there are two threads :</p>
  
  <ol>
  <li><p>that updates the gameLogic and physics etc. for the in game objects</p></li>
  <li><p>that makes openGL draw calls for each game object based on data in the game objects (that thread 1 keeps updating)</p></li>
  </ol>
  
  <p>Unless you have two copies of each game object in the current state of the game you'll have to pause Thread 1 while Thread 2 makes the draw calls otherwise the game objects will get updated in the middle of a draw call for that object ! which is undesirable!</p>
  
  <p>but stopping thread 1 to safely make draw calls from thread 2 kills the whole purpose of multithreading/cocurrency</p>
  
  <p><strong>Is there a better approach for this other than using hundreds or thousands or sync objects/fences so that the multicore architecture can be exploited for performance?</strong></p>
  
  <p>I know I can still use multiThreading for loading texture and compiling shaders <strong>for the objects which are yet to be the part of the current game state</strong> but how do I do it for the active/visible objects without causing conflict with draw and update?</p>