[ANN] Multithreaded Newton demo

[OneSadCookie]

http://onesadcookie.com/svn/repos/ThreadedNewton

It's a simple GLUT app showing a way to run physics in a separate thread from graphics. That way, when the graphics bog down the physics doesn't suffer, and when the physics bogs down, the graphics don't suffer. I'm not claiming it's the best way, or the only way to do things, but it's working for me :)

Performance is great on MP machines, and good with vsync turned on on single-proc machines.

[willThimbleby]

It also works for me. :) --cheers. I will have to play with the code tomorrow.

[Puzzler183]

On a side note, why GLUT? I found GLUT to be very limitting in what it allowed me to do and so I switched to SDL...

[ThemsAllTook]

GLUT is fantastic for small demo applications like this. It's simple and easy to use, and very lightweight. Obviously it's not suited for full-scale applications, but that's not what this is.

- Alex Diener

[Puzzler183]

I suppose... I found it to be restrictive even for small stuff. And stupid quirks like having to use exit() were kind of annoying.

[kelvin]

Do you have anonymous SVN access?

[OneSadCookie]

yes, just

svn checkout http://onesadcookie.com/svn/repos OSCsCode

it will make a folder called OSCsCode with all my stuff in it

If you just want one module, you can check them out individually, too --

svn checkout http://onesadcookie.com/svn/repos/ThreadedNewton

[kelvin]

yep, I tried the latter and it had problems connecting. I guess I'll try again.

[OneSadCookie]

my router crashed recently, maybe you happened to try whilst it was out :(

[kodex]

Thats a pretty good idea OSC, thanks for the code!

[kelvin]

There it goes... seems to be working now.

[OneSadCookie]

I've been asked for an explanation of how this demo works in this thread: http://www.idevgames.com/forum/showthread.php?t=9159

At the core of the demo is the idea of a complete physics state of the world. In this demo's case it's just a matrix for each block, but in general you'll probably want to store other information, such as whether engines are firing, tires are skidding, etc.

There are three physics state buffers in the demo. At any given moment, one is owned by the graphics thread, one by the physics thread, and one is "shared" in the middle. Whenever either thread is done with the one it owns, it swaps it with the one in the middle. You can think of the three buffers moving around in a figure-of-8 if you like.

The physics thread is the simpler of the threads; it simply runs the physics constantly. At the end of each physics frame, it fills its buffer and swaps it out to the shared buffer, getting a different buffer in exchange. The contents of this buffer is irrelevant, it only ever writes to the buffers.

The graphics thread is a little more complex; when it receives a buffer it needs to know whether that buffer is actually newer than the last one it saw. For that purpose, it uses a physics-frame counter. Other than that little caveat though, it's pretty simple. When it receives a new buffer, it updates the state of the graphical objects to match the values stored in the buffer.

That's the core of the system. Notice that the framerates of the two threads are entirely independent -- the graphics thread could hang whilst drawing a frame and the physics thread would continue oblivious, and the physics thread could hang whilst updating the physics and the graphics thread would continue forever, drawing the last frame received.

There are a couple of other things worth mentioning:

The "event queue" for passing information other than state from the physics thread to the graphics thread is the vector through which I communicate the creation and deletion of boxes. This information could equally well be stored in the physics buffer, but I found the queue convenient. YMMV.

I don't use mutexes anywhere. Instead, I use an atomic exchange of pointers with the OS-provided CompareAndSwap routine. Clearly, this is system-specific, but you should find an equivalent on every OS. Compare and swap is conceptually this operaton:

bool compare_and_swap(void *old, void *new, void **pointer)
{
if (*pointer == old)
{
*pointer = new;
return true;
}
else
{
return false;
}
}


But it is atomic, that is, no other thread can interrupt that operation. Notice that because it can fail (due to another thread modifying *pointer since you read the value of old), every use of the function must be contained in a loop, which constantly reads old, attempts the CAS, and retrys if it fails.

This technique is very efficient if there is "low contention" between the threads, that is, the chance of another thread modifying *pointer and making you go round your loop again is low. Note that on a single-processor system, contention is always low, since the chance of you being preempted in the crucial window is very low, and the chance of it happening a second time is virtually nil. If you have high contention, a proper mutex may do a better job, though.

Finally, this demo puts the graphics thread in the main thread, and the physics thread in a secondary. This is due to the limitations of GLUT. In general, you'd put the physics in the main thread and the graphics in a a secondary thread, since you want user input to be supplied to the physics thread.

[Duane]

I have no f***ing SVN! damnit! it's such a pain having to download the files individually...

[OneSadCookie]

FFS. GIYF. http://www.codingmonkeys.de/mbo/

[kelvin]

FFS. GIYF. http://www.codingmonkeys.de/mbo/
WTF? I think OSC uses TMDA. FTLOG!

If you are going to insist on using your abbreviations, please back them with links to a dictionary. After a certain threshold, they become counter-productive. And no, it doesn't matter if half the people here know what 90% of them mean.

:p

[OneSadCookie]

In response to someone with enough time to post complaining they don't have an SVN client, but not enough to do a simple google search, no, I won't waste time explaining acronyms, or typing them out in full.

In any case, Ryan's heard them often enough to know what they mean by now :p

[AnotherJake]

And no, it doesn't matter if half the people here know what 90% of them mean.
GIYF is the Rosetta stone of the Web, if you can't figger that one out, you're SOL. It has been well observed here over many months that Nayr has Googaphobia -the fear of making any effort to look something up. While there are many others with this disease, it appears that his case may be terminal and so such radical therapy may indeed be called for.