You are missing my point, single threaded, a general game loop is something like:

1. Game Logic & Handling Player Input
2. AI
3. Collision / Hit Testing / Physics
4. Update Screen. (either directly draw, or update the 3D engine's render pipeline)

Of course that is very simplified but generally that is the sequence of events.

What the OP tried to do is pull out the physics calculations and then poll the physics thread each frame to see if its calculations have been completed. This introduces that wierd latency lag and syncing issues between the physics game state and the rest of the game state.

I..e he tried to do this:

 Thread 1                                                 Thread 2
1. Game Logic & Handling Player Input         Physics Calculated
2. AI
3. Poll Physics Thread ------------------------>
4. Update Screen.  

What I am saying is that surely a simpler approach, although far from optimal for many reasons would be this:

   Main Thread                          Thread 2
1. Game Logic                          Physics Calculated
2. AI
          -------- Blocking Sync -------                   
4. Update Screen.  

Then he doesnt need to bother with polling or latency issues. Worst case scenario is that Its just as slow as the single theaded version with a small overhead for spawning the additional thread.

This of course is completely not optimal, because in best case scenario the physics thead would complete and be idle far more quickly than the duration of the frame and you end up not utilising the full capability CPU.

Also this design has all the disadantages and issues associated wtih multi threaded processes, including lock contention deadlocks, shared mutable state etc.

This is why I prefer using a threadpool and queueing work items (i.e. parallising individiual functions/calculations) , passing data via messages as opposed to mutating shared state.