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

Robert Osfield robert.osfield at gmail.com
Sun Sep 16 00:48:24 PDT 2007


HI Adam,

I would recommend updating to the SVN version of the OSG.  I have
removed the use of the DeleteHandler replacing it with use of
ref_ptr<> in the osgUtil rendering backend.  Performance wise this
results in a small hit on cull performance, but does make the clean up
my cleaner.  If you are using ref_ptr<>'s in your own subclassing
properly then everything should just clean up without need to any
special ordering.

As for timing, changing for STATIC to DYNAMIC can potentially cause
problems. One should wait till all the objects have been dispatched
before changing, alas as yet there isn't a convenient way provide for
this.  If you plan on changing things to DYNAMIC in your app just set
them to DYNAMIC to begin with.

W.r.t deleting/adding this should not be any issue as ref_ptr<> will
ensure things hold together (especially in the SVN version of the OSG
with the above change).

Robert.

On 9/15/07, Adam Coates <acoates at stanford.edu> wrote:
> 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
> >
> _______________________________________________
> 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