[osg-users] ParticleSystem lifetime, race conditions

[OpenSceneGraph Users]

Hi James,

Almost all the updating of the scene graph is not threadsafe and meant to
be updated from a single threaded update section/traversal. Normally this
would be invoked in the main loop like the viewer.updateTraversal() or in
custom update osg::Operation assigned to the viewer, or through subclassing
of Viewer::updateTraversal().

The exception is where you have a subgraph that is wholly created and
updated within a background thread before being assigned to the viewer.

>From your description it'll be the ParticularSystemUpdater that is causing
problems.  Caching all the required particle addition in a thread safe
container and applying them as a batch in the updateTraversal would be how
I'd do it.  An update callback assigned to the ParticuleSystemUpdater could
probably do this.  This callback would be the thread safe container or
"have a" thread safe container then the loaders also know about.

Or simply create a subclass from ParticularSystemUpdater to add a thread
safe container within it and custom handling of this during update.

I had to add, I haven't tried this with type of usage with osgPairicle, and
I'm rather rusty as my focus has been on the VSG for the past two years :-)


Robert.


On Wed, 9 Sep 2020 at 21:40, OpenSceneGraph Users <
osg-users at lists.openscenegraph.org> wrote:

> Hello,
>
> We’re seeing some crashes in FlightGear relating to osgParticle, which
> raised some questions:
>
> - what is the thread-safety / expected thread calling restrictions on
> ParticleSystemUpdater addPS/removePS? I’m asking because none of the method
> which modify the PSU’s list of particle-systems, seem to lock any kind of
> mutex before making changes. (there is locking internal to each PS, but
> that doesn’t protect the std::vector inside the PSU)
>
> In FlightGear, we create ParticleSystems in some custom osgDB loaders, and
> therefore our ParticleSytems are created, and added to our global
> ParticleSystemUpdater, in those osgDB threads. We suspect this might be a
> race condition given the lack of locking in
> ParticleSystemUpdater::addParticleSystem and others. I wondered if it was
> expected to only touch the PSU from the main thread, for example. Eg by
> deferring adding to the PSU to an UpdateCallback.
>
> - what is the expected lifetime model of ParticleSystems/Updaters?
>
> We have a single global PSU, but since the PSU takes an owning ref_ptr to
> each added ParticleSystem, I suspect we are in practice never freeing any
> particle systems, even once the node which owns them in the scene, is
> unloaded/removed. (By the scenery tile expiring in our cache)
>
> I would have expected the PSU to use a weak-ref / osg::Observer onto the
> ParticleSystem, but maybe having a single global PSU is not the intended
> design here, perhaps we should be having one PSU per scenery tile (covers a
> few square km), or something else again? Or maybe I need to add an Observer
> on the parent Node, to call PSU::removeParticleSystem?
>
> Any pointers on best practice for this would be welcome. Maybe this is the
> wrong design for managing the creation and destruction of ParticleSystems
> in a long-lived scene such as a flight simulator.
>
> Kind regards,
> James
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20200910/9ffb16e8/attachment.html>