<div dir="ltr"><div>Hi James,</div><div><br></div><div>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().</div><div><br></div><div>The exception is where you have a subgraph that is wholly created and updated within a background thread before being assigned to the viewer.</div><div><br></div><div>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.</div><div><br></div><div>Or simply create a subclass from ParticularSystemUpdater to add a thread safe container within it and custom handling of this during update.<br></div><div><br></div><div>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 :-)</div><div><br></div><div><br></div><div>Robert.<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 9 Sep 2020 at 21:40, OpenSceneGraph Users <<a href="mailto:osg-users@lists.openscenegraph.org">osg-users@lists.openscenegraph.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello, <br>
<br>
We’re seeing some crashes in FlightGear relating to osgParticle, which raised some questions:<br>
<br>
- 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)<br>
<br>
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.<br>
<br>
- what is the expected lifetime model of ParticleSystems/Updaters?<br>
<br>
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)<br>
<br>
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?<br>
<br>
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.<br>
<br>
Kind regards,<br>
James<br>
_______________________________________________<br>
osg-users mailing list<br>
<a href="mailto:osg-users@lists.openscenegraph.org" target="_blank">osg-users@lists.openscenegraph.org</a><br>
<a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" rel="noreferrer" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br>
</blockquote></div>