[osg-users] Dos, Don'ts and DOH's of Drawables with threading?

Adam Coates acoates at stanford.edu
Sat Sep 15 13:02:14 PDT 2007


Hi, Robert,

I drive the viewer myself via osgViewer::frame(), so all of my updates
happen outside the traversals.  Thus, anything set to STATIC was
off-limits, even up to the point that my osgViewer was deleted by the
destructor of the object containing it.  I destroyed some internal
data belonging to my own Drawable subclass before this point, not
realizing that it could still be getting called while the Viewer was
living.  What I meant by the "hang" was that the Viewer was sitting in
a loop waiting for the OperationsThread to cancel because it was
calling my Drawable, which already had its data destroyed, thus
causing a crash.

So, the final solution was to set the dataVariance on most of my
objects to DYNAMIC, and then to delete the viewer explicitly _before_
deleting the data for any of those objects that were STATIC to
guarantee that all of the previous rendering loops had finished and it
was safe to do this.

Out of curiosity, in general, when is it otherwise safe to
modify/remove/add things to a STATIC node?  i.e., if the Viewer's loop
could be running at pretty much any time, is the only way to set
dataVariance to DYNAMIC, wait a few frames, and then make the changes?

Cheers,
Adam

On 9/15/07, Robert Osfield <robert.osfield at gmail.com> wrote:
> Hi Adam,
>
> Paul did a nice explanation so I have little to add.  For future
> reference what was the change that fixed the problem you were seeing?
>
> Robert.
>
> On 9/15/07, Adam Coates <acoates at stanford.edu> wrote:
> > Excellent - that was all the explanation I needed.  Everything is
> > humming along just fine now.
> >
> > Thanks, Paul!
> >
> > AC
> >
> > On 9/14/07, Paul Martz <pmartz at skew-matrix.com> wrote:
> > > I'm not sure why you have a thread hung in drawImplementation() after
> > > Viewer's destructor has been called. But I can explain some of the other
> > > stuff you have questions on, and hopefully that'll help.
> > >
> > > > My question is, how do you guys
> > > > normally deal with data (scene graph, geometry, text,
> > > > whatever) being modified on the main thread while Viewer is
> > > > apparently busy rendering the same data?
> > >
> > > Mark the Node or Drawable as DYNAMIC DataVariance, and only modify it during
> > > the update traversal (or outside the rendering traversals).
> > >
> > > > Having looked at a lot of the other drawables included in
> > > > OSG, I don't see how the "double buffering" scheme works --
> > > > how is that any of the scene graph or other geometry data get
> > > > updated without creating a race condition like this?
> > >
> > > OSG operates on a gentleman's agreement under which you can do whatever you
> > > want to DYNAMIC nodes during the update traversal, and OSG's possibly
> > > multiple threads can perform read-only operations during the cull/draw
> > > traversals.
> > >
> > > With osgViewer-based apps, marking nodes that you intend to modify as
> > > DYNAMIC is critical, otherwise OSG might let the update traversal start (or
> > > return from frame()) before it has finished processing the node that you're
> > > going to modify.
> > >
> > > > What's the trick here?  What
> > > > can/can't one do from with the drawImplementation() method in
> > > > order to remain thread safe?
> > >
> > > drawImplementation() should be const, so as long as you don't modify it or
> > > anything else in the scene graph, you should be OK.
> > >
> > > Hope that helps.
> > >
> > > Paul Martz
> > > Skew Matrix Software LLC
> > > http://www.skew-matrix.com
> > > 303 859 9466
> > >
> > > _______________________________________________
> > > osg-users mailing list
> > > osg-users at lists.openscenegraph.org
> > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> > >
> > _______________________________________________
> > osg-users mailing list
> > osg-users at lists.openscenegraph.org
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> >
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



More information about the osg-users mailing list