[osg-users] Threading bug
robert.osfield at gmail.com
Tue Sep 2 23:15:25 PDT 2008
Thanks for uncovering this issue. This is a bug that will need to be
fixed, I'm just heading out to a all day meeting so will have to look
into it further on my return.
On Wed, Sep 3, 2008 at 3:01 AM, Mark Sciabica <msciabica at itracs.com> wrote:
> 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.
> osg-users mailing list
> osg-users at lists.openscenegraph.org
More information about the osg-users