[ANN] Multithreaded Newton demo

Luminary
Posts: 5,143
Joined: 2002.04
Post: #1
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 Smile

Performance is great on MP machines, and good with vsync turned on on single-proc machines.
Quote this message in a reply
Member
Posts: 78
Joined: 2002.06
Post: #2
It also works for me. Smile --cheers. I will have to play with the code tomorrow.
Quote this message in a reply
Puzzler183
Unregistered
 
Post: #3
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...
Quote this message in a reply
Moderator
Posts: 1,560
Joined: 2003.10
Post: #4
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
Quote this message in a reply
Puzzler183
Unregistered
 
Post: #5
I suppose... I found it to be restrictive even for small stuff. And stupid quirks like having to use exit() were kind of annoying.
Quote this message in a reply
Member
Posts: 469
Joined: 2002.10
Post: #6
Do you have anonymous SVN access?

---Kelvin--
15.4" MacBook Pro revA
1.83GHz/2GB/250GB
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #7
yes, just

Code:
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 --

Code:
svn checkout http://onesadcookie.com/svn/repos/ThreadedNewton
Quote this message in a reply
Member
Posts: 469
Joined: 2002.10
Post: #8
yep, I tried the latter and it had problems connecting. I guess I'll try again.

---Kelvin--
15.4" MacBook Pro revA
1.83GHz/2GB/250GB
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #9
my router crashed recently, maybe you happened to try whilst it was out Sad
Quote this message in a reply
Moderator
Posts: 613
Joined: 2004.09
Post: #10
Thats a pretty good idea OSC, thanks for the code!

Kyle Richter
DragonForged.com
Twitter: @kylerichter
Quote this message in a reply
Member
Posts: 469
Joined: 2002.10
Post: #11
There it goes... seems to be working now.

---Kelvin--
15.4" MacBook Pro revA
1.83GHz/2GB/250GB
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #12
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:

Code:
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.
Quote this message in a reply
Member
Posts: 567
Joined: 2004.07
Post: #13
I have no f***ing SVN! damnit! it's such a pain having to download the files individually...

It's not magic, it's Ruby.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #14
Quote this message in a reply
Member
Posts: 469
Joined: 2002.10
Post: #15
OneSadCookie Wrote: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.

Rasp

---Kelvin--
15.4" MacBook Pro revA
1.83GHz/2GB/250GB
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Strange Newton Error Nick 19 8,523 Jul 17, 2005 01:49 AM
Last Post: OneSadCookie
  Squirrel Physics Kit vs. Newton blobbo 3 4,097 Apr 22, 2005 06:22 AM
Last Post: blobbo
  Newton weirdness IBethune 3 3,608 Mar 25, 2005 06:24 AM
Last Post: IBethune