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

Adam Coates acoates at stanford.edu
Sun Sep 16 04:28:06 PDT 2007


Cool - I'll give the update a shot.

Thanks for your help,
AC

On 9/16/07, Robert Osfield <robert.osfield at gmail.com> wrote:
> 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
> >
> _______________________________________________
> 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