Hello osg-processors,
Upon my investigation of paging issues on a dual-core windows machine, here
is the thread flow I see:
Paging thread
requestNodeFile(){
run(){
deleteRemovedSubgraphs
readNextNode
compileOrMergeNode
}
}
Graphics thread (main process)
run(){
update{
pager->removeExpiredSubgraphs
pager->addLoadedDataToSceneGraph
}
cull{
pager->requestNodeFile
}
draw{
check if enough time{
pager->compileGLObjects
pager->flushDeletedObjects
}
}
}
I seem to be having the hitches when the graphics thread calls the pager
functions in update.
Mutex locks
pager->removeExpiredSubgraphs
{
_childrenToDeleteListMutex
}
pager->addLoadedDataToSceneGraph
{
_dataToMergeListMutex
}
pager->compileGLObjects
{
_dataToCompileListMutex
_childrenToDeleteListMutex
_dataToCompileListMutex
_dataToMergeListMutex
}
pager->requestNodeFile
{
_dataToCompileListMutex
_dataToMergeListMutex
_fileRequestListMutex
_run_mutex
}
pager->run
{
_childrenToDeleteListMutex
_fileRequestListMutex
s_serialize_readNodeFile_mutex
_fileRequestListMutex
_dataToCompileListMutex
_dataToMergeListMutex
}
>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?
Wouldn't that mean that the graphics thread could potentially reach a mutex
that has already been locked by the paging thread?
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?
Zach
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
