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

Adam Coates acoates at stanford.edu
Fri Sep 14 13:34:01 PDT 2007


Hello, everyone,

I've been using OSG for a little bit for some in-house tools.  I'm
trying to add a new Drawable subclass, but am having trouble
understanding how the osgViewer's multithreading works (I'm using the
default threading model, which appears to create one background thread
for rendering).

In short, when osgViewer gets destructed at the end of my program (or
rather, at the end of the life of the object that contains it), the
OSG debug printouts claim:

"Waiting for OperationsThread to cancel 0x5f6580"

This thread is busy calling the drawImplementation of my drawable
(which, as it happens, has already been deleted by this point!)
Presumably, this was set in motion by a previous call to
Viewer::frame().  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?

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?  Viewer seems to include some reference to a
"double buffering" object -- but none of the other drawables appear to
have any code to handle threading.  What's the trick here?  What
can/can't one do from with the drawImplementation() method in order to
remain thread safe?

Thanks in advance for any tips,
Adam C.



More information about the osg-users mailing list