I would like to get a bit further into the cause of slow down that
Carlo has come across with the current CVS version of OpenThreads.
The current suspect is in OpenThreads/win32_src/Win32Mutex.cpp :
static void _S_nsec_sleep(int __log_nsec) {
if (__log_nsec <= 20) {
SwitchToThread(); //Sleep(0); // adegli replaced it Sleep by
SwitchToThread
} else {
Sleep(1 << (__log_nsec - 20));
}
}
Note the change from Sleep(0) to SwitchToThread(). Now Adrian Adegli
wrote the above change to solve a performance problem, but it looks
like has introduced a new performance problem on other systems.
There is only one place that the _S_nsec_sleep(int) method is called
and that is in Mutex::lock(). I'm not familiar with Windows
threading API so its difficult for me to wade in. One thing I am
suprised by is the need with little loops at the bottom of the
function. Is this really required?
I am wondering if the waiting to aquire a lock shouldn't be
implemented via another means, surely that has to be a better way than
this. It would be interesting to see how other threading API's sit
themselves above the windows thread code.
I would very much appreciate Windows experts have a look over the
Mutex::lock() implementation and come up with a more robust and
efficient version.
Thanks,
Robert.
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
