HI Mikhail, Thanks for the example. I've reproduced the crash using the example and been reviewing the osg::State handling if the _appliedProgramObjectSet and can see the mechanism by which the container gets accessed inappropriately by the draw thread when a Program::PerContextProgram object gets destructed in a separate thread. The simple solution would to put a mutex around access of this container, however, this would have a serious impact on performance as each time a Program is applied in the draw traversal a mutex would have to be locked/unlocked.
I am currently looking it to how to address the threading bug whilst avoiding the overhead of mutex lock. Currently this container is only being used to enable a reset of state, but as this doesn't happen by default for the OSG it's shame that we are paying this ovehead and threading bug for the privilidge of offering the ability to do a State::reset(). Robert. On 15 July 2014 13:40, Mikhail Izmestev <izmmish...@gmail.com> wrote: > Hi, > > There is corruption of osg::State::_appliedProgramObjectSet caused by not > thread safe access. > osg::State::objectDeleted handler can be invoked from different threads. > > Attached example based on osgsimpleshaders. > > Thanks, > Mikhail. > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > >
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
