MultiThread Frame Syncronization

(L) [2007/07/18] [filami] [MultiThread Frame Syncronization] Wayback!

Hello ppl.

I am developing a new tracer, a realtime one.

Right now, I am developing the frame synchronization. I want to use multiple threads, each thread processing different parts of the frame. When a thread does not have nothing to do, it should be locked. When all threads are locked (the frame was terminated), a swap buffer should be done and the thread should be restarted to a new frame. The concept is quite easy...the problem is that implementation is not that easy (I admit, I'm not very good on multi threading [SMILEY stick out tongue])

This is what I have so far:

(L) [2007/07/18] [MishoM] [MultiThread Frame Syncronization] Wayback!

I recommend that you try to approach the problem the other way around. Implement a thread-safe jobs queue and push in it jobs that describe portions of the frame to process. Then have your worker threads wait for jobs to appear in the queue, and have a dispatcher thread (this can be your main thread or another thread) push in the queue the frame portions that must be processed by the worker threads.
_________________
--------

MishoM

(L) [2007/07/18] [greenhybrid] [MultiThread Frame Syncronization] Wayback!

But see that OpenMP is a (young) standard, which IMHO will be adopted by all major compilers (afair ICC has support, and with of version 4.2, gcc has, too; dunno about the evil plans forged somewhere in the town of redmond, as I know them, they will try to pop in their own standards (see IE)).
_________________
[LINK http://greenhybrid.net/ greenhybrid.net]

Real Men code Software Graphics.

(L) [2007/07/18] [Lynx] [MultiThread Frame Syncronization] Wayback!

Btw. a semaphore has atomic operations, just like a mutex. Only difference is that a semaphore blocks when you try to decrease below zero, while a mutex only can be occupied or not, more or less a binary semaphore. A semaphore can be initialized with a negative value i think, e.g. initializing with (-numThreads+1) would block the main thread's decrement until all render threads have incremented so the semaphore value became 1. But i always use mutexes and in the rare case i'm interested in a count i keep track of it myself...at least on older OS X version the pthread semaphores were not available so they all got eliminated long ago...

(L) [2007/07/18] [tbp] [MultiThread Frame Syncronization] Wayback!

There's a bunch of race conditions in that code. It boils down to the fact that code only knows about a particular thread executing a particular statement 'now' you can't assume anything about the past and future of that thread, and even less about other. So the default tactic is to work in locksteps: for every 'transaction' you got to ensure both sides know where they stand; put another way, you need to 2 channels.

Only with additional knowledge you can think about taking some shortcuts; in the case of producer/consumers queue, you may simplify around ie the idea of "write once/read many" if you you can make it through requirements.

Sleep(0) is not only "hugly", it's a sure sign your program is ill defined.

Also you don't have to use heavy handed 'volatile' (which are no magic cure anyway) but you'd have to pay attention to the notion of memory barrier then and tell your good friend the compiler what you're doing (they know about it).

Performance wise, the whole zoo of synchro primitive is mostly useful to interact with the scheduler (read OS), and even if you can build most from one another they each have their own use.

All in all, OpenMP has wide enough support and is good enough for most uses; if you're still feeling adventurous you'll find past threads on this board addressing the problem of correct & fast job queues and more.

[dug some ref]

[LINK http://ompf.org/forum/viewtopic.php?p=1156#1156]

[LINK http://ompf.org/forum/viewtopic.php?t=356]

there was more but...
_________________
May you live in interesting times.

[LINK https://gna.org/projects/radius/ radius] | [LINK http://ompf.org/ ompf] | [LINK http://ompf.org/wiki/ WompfKi]

(L) [2007/08/03] [cignox1] [MultiThread Frame Syncronization] Wayback!

I cannot help you with threading very much, but have you already considered using the Boost::thread library for platform independent threading jobs?

I just tried with it some days ago and the code to start a couple of simple threads is very short and easy...

Apparently it is quite easy to use (I was told that it is in fact much more simple than win32 facilities), only I don't know if it provides all the primitives you need...

(L) [2007/08/20] [Zakalwe] [MultiThread Frame Syncronization] Wayback!

This is some simple pthreads based code I whipped up a while ago. The main thread is the boss and it is responsible for creating jobs. Workers are responsible for doing the jobs. When the worker can't get a job it sleeps until the boss signals it that work is available. The boss sleeps until the workers signal they have their job. If the boss sees that all jobs are done it wakes up fully and does it's own work.

Basically the workers could raytrace separate parts of the image and when they're done, the boss could wake up, blit the image to the screen and create the new jobs.

I've simulated doing work with "sleep()". A job is merely an integer that is decremented, but you could use an array of job structs or something similar. I use a jobs_done variable here to reduce fighting over the jobs queue lock.

I haven't actually used this code or tested it fully, but it looks right enough to me. Of course it can be improved on by having the worker threads render ahead a frame while the boss does it's work etc.

MultiThread Frame Syncronization back