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
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
