Messages in this thread | | | Date | Sun, 19 Dec 1999 23:00:53 -0800 (PST) | From | raster@rasterma ... | Subject | Re: RasterMan on linux and threads |
| |
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/
| |