Re: RasterMan on linux and threads

Dan Kegel (dank@alumni.caltech.edu)
Sun, 19 Dec 1999 14:55:09 -0800


Raster wrote:
> On 17 Dec, Alan Cox scribbled:
> -> > hmm - so if i do short bursted threads ( approx < 0.1 seconds each on
> -> > average i guess ) will he get scheduled across spuc or be weighted to
> ->
> -> If the other cpus are idle they will get cross scheduled yes. The mm affinity
> -> weighting doesn't beat idle processors. Also keep the threads around rather
> -> than killing them all the time as its faster not to keep creating new threads
> -> even though that is fast
>
> excellent - so i coudl get a speedup on smp boxes... tiem to write and
> benchmark... now i just have the problm of keping threads around...
> sinbce it's meant to be transparent to the calling process (the callign
> process need not know anything about threads.. the lib figures the best
> number of threads and handles creating them etc.) ... i'll porbabl;y
> have to adda flush_threads(); call to delete any idle threads if the
> callign process ownt need to do any rendering for a while...

Sounds like you're heading for a very complex design with lots of
threads. That's a good way to run into deadlock issues. The best
way to avoid deadlock IMHO is to introduce the absolute minimum
number of threads, and put a well-understood interface between each
thread and the rest of the world.

For instance, what if all your API functions did was queue drawing
requests, and you had a single long-lived worker thread taking requests
off the queue and executing them? (Or maybe two worker threads, if
you like.) That way, you'll allow the user's app to run in parallel with
your rendering, and you'll only have a single interface across which
to worry about thread safety.

The cost would be that the caller would not be allowed to change
stuff he passed pointers to until your API was done with it.
And therein lies the design challenge.
- Dan

-- 
(The above is just my personal opinion; I don't speak for my employer,
 except on the occasional talk show.)

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/