[osg-users] Threading bug

Mark Sciabica msciabica at itracs.com
Tue Sep 2 19:01:46 PDT 2008


Hello Robert (and other list members),

I have found what may be a bug in multithreaded usage of some objects 
when _OSG_REFERENCED_USE_ATOMIC_OPERATIONS is #defined.

The problem is that osg::Node, osg::Drawable, and osg::StateSet all use 
the getRefMutex() method of osg::Referenced to control addition and 
removal of obects to their _parents lists. This method always returns 
null when _OSG_REFERENCED_USE_ATOMIC_OPERATIONS is #defined. So some 
code that works when not using atomic operations may crash when using 
atomic operations.

My question is whether it is intended to be safe to add a parent to an 
object that is being used in another thread. My first thought was that 
it was, otherwise why bother using the mutex when it is available? 
However, on further examination, there are other usages of the _parents 
list that are unprotected by the mutex, so the intention may have 
changed since the mutex protection code was added.

For context, I ran into this problem creating an osgText::Text object on 
a secondary thread and assigning a font to it. Assigning a font entails 
setting the font's stateset to the osgText::Text object. Even if I don't 
share my fonts between threads, osgText::DefaultFont has a static 
instance that is used by all osgText::Text objects that haven't had 
their fonts set and would cause similar problems.

So my workaround for now is to change my build settings so that the 
mutex is used instead of the atomic operations. Or perhaps I should 
abandon this line of coding and the above mentioned mutex use should be 
deleted from osg.


Regards,

Mark



More information about the osg-users mailing list