What are you going to sync? Are you going to stop the render thread to wait on other stuff?
No of course not. When I say sync, I simply mean make sure the game logic doesnt run faster than the game rendering, as it is pointless (again please correct me if im wrong, I might be missing something).
You want all of your threads to run as fast as they can. One of the hardest things for people new to concurrent programming to leave behind is this thing with worrying about what other threads are doing. Don't. Each thread should care less.
I would suggest that you want your physics world to simulate as fast as possible, for the highest precision, rather than have it waiting around because the rendering thread might not be "ready" for it yet. If the rendering thread is not ready, go ahead and do another iteration; when the rendering thread is ready to start another frame, it will get the data from the latest iteration of whatever thread it might be (game logic, physics, whatever) -- it doesn't really matter. There is absolutely no point in slowing down any one thread because of concerns in another.
There is absolutely nothing wrong with updating the position of an object N times before it is rendered again. I don't really see what you are syncing on here.
Akk how can you say that? What if you have a thousand objects, each requiring a intense physics calculation to determine their position? Why on earth would you run all those calculations 30 times, when you might only be able to DISPLAY 10 of those 'positions'? You could use that cpu time to help your other threads along.
First, I am talking in general terms -- allocation of computing resources is not the issue in this discussion. Think abstract for now; don't limit yourself on the basis of a single architecture. Assume for the sake of argument that you have 6 very fast processors that can each do a thread all by themselves (yes, the machine I have in mind begins and ends with "x", or maybe "P" and "3").
To answer: because you are getting the highest possible precision from your physics loop, which I find to be more desirable than stalling because some other thread is slower. Update the object positions (even replace them in a priority queue if you like), let the rendering thread deal with them in its own time.
Are you upset that your 60fps (rendered) game doesnt do 120fps worth of physic calculations? Of course not. What happens between frames doesnt matter (as long as each frame is accurate of course).
It's also a mistake to think in terms of "frames" for things like physics; physics doesn't have "frames", it has "time" and it likes to run with the smallest timestep possible for the highest level of accuracy.
But what about my thesis? Is that not the best scenario (for a game at least)?
Also curious to hear anyones thoughts on...
Maybe 'double buffering' in this sense should be a part of Ogre (or any graphics engine for that matter). Why shouldnt we be able to 'work' on the NEXT frame, while we wait for the cpu/drivers/gpu/fillrate to render the CURRENT frame?
Double-buffering is something done by the drivers, since it's a hardware-level facility. You could say Ogre already does this; it uses whatever the drivers make available. What you are describing in fact is precisely how GPUs operate; they couldn't work any other way, in fact.