RE: [Algorithms] Multithreading with Hardware Acceleration

[Tom F. <to...@mu...>]

The Sleep(0) explicitly gives up the rest of the thread's timeslice to other
threads. So even if two threads are at the same priority, the other one will
get most of the CPU time, instead of spending half of it spinning tightly.
It's a way of surrendering time you don't need - sort of manually lowering
your priority, but with very fine-grained control.

Tom Forsyth - Muckyfoot bloke.
Whizzing and pasting and pooting through the day. 
-----Original Message-----
From: Chris Brodie [mailto:Chr...@ma...]
Sent: 21 August 2000 05:50
To: 'gda...@li...'
Subject: RE: [Algorithms] Multithreading with Hardware Acceleration


Thanks guys. I was only planning on about ~3-4 threads(input+networking,
file, video, main, (sound?)) 
Each thread has a threadsafe queue. Then to communicate with it I just send
it a message throught the queue(like a pointer to where the data is it need
to do it's work. 
I was once playing with WildTangets Gamedriver and profiled the 'explore'
sample app to see where all the CPU time went. Just about all of it was
spent in the nVidia driver, so I was betting that they were just doing a
whole bunch of waits as bits were being rendered. 
Tom, while your way is correct (sleep(0) to return control to the OS to
reschedule), and is a nice way of doing it, shouldn't the scheduler still
switch to another thread if one is waiting and is of the same or higher
priority? 
The reason I'm interested in this is that it'll give gains on single
processors as well as the dual's. 
Chris