[osg-users] osgViewer Threading Model problem.

[Robert Osfield]

HI Dario,

On 1 July 2016 at 14:26, Dario Minieri <paradox at cheapnet.it> wrote:
> All data change on osg tree are made inside callback, so theoretically we have no "parallel" change during frame. However there are a lot of visitors that I have to check, may be could do data alteration. In my test, actually, there is osgHimmel and osgOcean also inside scene.
>
> This type of problem, anyway, is generated by osg tree alteration parallel to frame only?

The DrawThreadPerContext threading model enables the draw thread of
one frame to run in parallel with the update, event and cull
traversals of the next frame.  This means that if you modify Drawable
or StateSet/Texture etc. state within the update, event or cull
traversals then you'll end up with a race condition.

The OSG uses a osg::Object::setDataVariance(osg::Object::STATIC |
osg::Object::DYNAMIC) hint to tell the draw traversal whether it's
safe the next frame proceed.  The way it works is the draw traversal
holds back the next frame till all the Drawable and StateSet's marked
with DYNAMIC DataVariance are dispatched.

My best guess is that you're modifying some state or drawable in the
update or event traversal (via callback for instance) without marking
the Drawable's or StateSet that encloses the dynamic state with a
DataVaraince of DYNAMIC.

Robert.