[osg-users] ParticleSystem lifetime, race conditions

[OpenSceneGraph Users]

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