Re: RasterMan on linux and threads

raster@rasterman.com
Sun, 19 Dec 1999 23:00:53 -0800 (PST)

On 19 Dec, Dan Kegel scribbled:
-> 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.

I actually thought abotu thread a logn way back and its not hard...
just split image to blend/scale/render into N sections vertically (N
equal sized strips) ands have each thread handle each strip. all
ttherad wait till busy count > 0 - onec its < 1 all threads are done
and function can actually return to application control.

-> 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.

not how it works at the lib api - it's all immediate mode
design/implimentation. any queued drawing shoudl/would happen at a much
higher level in the calling application or toolkit. thats how i'd doign
it now ahyway with queueing happinign at the visual objedt/widget
stage. the aim is to spend as little time inside an api call as
possible and long-lived crunching calls like blending an 800x600 RGBA
image onto another woudl do well with being split into threads for
multiple cpu boxes :)

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

-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler)    raster@rasterman.com     raster@valinux.com
                                    raster@enlightenment.org raster@linux.com
				    raster@zip.com.au




-
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/