Hi Robert, DatabasePager::run() executes readNodeFile. Thus, the readNodeFile is being called within the paging thread. So, don't we have to worry about mutexes that are in here?
I noticed the use of mutexes keeps the locking to a minimum, but I didn't trace through all of readNodeFile. This would happen in a single proc case though anyways. So, I'm just gonna drop trying to figure this out. I just hate to leave a problem unsolved. I'll just have to accept the short-term solution of running single proc, and move to the long-term of linux (assuming I don't get the same problem). Zach -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Wednesday, March 14, 2007 16:28 To: osg users Subject: Re: [osg-users] Thread flow 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/ _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
