Hi Zach, On 3/14/07, Zach Deedler <[EMAIL PROTECTED]> wrote:
From what I can tell, The cull traversal of the graphics thread (main process), kicks off the database pager in the cull traversal. I believe that the only function that is running in the pager threadspace is pager->run(). Correct?
The cull traversal sets calls the DatabasePager via NodeVisitor::DatabaseRequestHandler::requestNodeFile, that in term generates a DatabaseRequest within the DatabasePager. This DatabasePager has to be put into/refreshed within a set of list of DatabaseRequests. This does hit a mutex, but should lock and unlock it quickly. On the DatabasePager side it also locks and unlocks the various lists with a short as possible time frame. Times when the database pager and the cull traversal sit on the same lock shoudl be very rare. You add timer code around the locks/unlocks to double check this.
Wouldn't that mean that the graphics thread could potentially reach a mutex that has already been locked by the paging thread?
Yes, but the use of the mutexes is done so that the amount of time that a single mutexed locked in minimized.
If there were a mutex buried deep down in readNodeFile, that each thread accessed, and that mutex code took a long time; that could account for the drop in frame rate. Any suggestions on how to see the states of all mutexes while running to see if one is locked for a long period? Or do you think I should just give up, and call it a windows dual-core problem?
Any mutexes within the readNodeFile themselves won't be hit by the cull traversal, its only the DatabasePager mutexes that we have to worry about w.r.t stalling the graphics thread. Robert. _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
