Hi Mathias, 2009/5/29 Mathias Fröhlich <m.froehl...@science-computing.de>: > There is a race between asking the observer_ptr if it is valid and the object > you have no counted reference on being deleted before accessing it. > And there is no atomic way to get a ref_ptr from an observed_ptr without that > race.
I went for a lightweight observer implementation, rather than go the route of requiring ref_ptr<> construction for access like std::weak_ptr requires. The later is more robust in the presence of threading, but slower. To make a thread safe implementation we'd need to add a mutex into the observer to protect access to _ptr and add a ref_ptr<> as the accessors. Right now one should obviously take care of what contexts you use observer_ptr<>. Using the Observer interface doesn't have this problem though, as one could easily manage the thread safe on the observer side. For this particular problem observer_ptr<> isn't appropriate - it's the Camera that owns the RenderStage that needs to be managed correctly. >> The problem is that you can't delete an object whilest another thread >> is still using it. The easiest way to address this is to stop the >> threading. The more complex way is to synchronize the threads in some >> fasion. > So, I wonder how is this solved for models that are being deleted by a Paged > model? > Should this already work? > Just wondering if I can safely use pre/post Cameras in paged models? > What am I missing here in the thread picture? Interesting issue. Normally nodes don't make it into the rendering backend, but in scene graph Camera's are the exception, the StateSet and Drawable are all reference counted in the rendering backend so that aren't effected by the possibility of scene graph elements being deleted which the draw traversal is running. So potentially one could have a Camera node removed during update such as pageing that overlaps with the draw traversal when running in DrawThreadPerContext and CullDrawThreadPerContext. The CullDrawThreadPerContext and SingleThreaded models won't be affected as the draw traversals won't be affected. > Also I thought that in the concrete problem. The event stage (as well as the > update stage) is something that is serialized enough to modify the scenegraph > (may be also throwing away a Camera)? Removing a Camera that is being used in a rendering thread will be unsafe no matter when it's done. Right now the way to avoid problems is use CullDrawThreadPerContext/SingleThreaded or stop threading when removing Cameras. To allow us to remove Camera's from the scene graph whilst the draw thread is still running will require the draw thread to take a reference to Camera while it's being used. It might be possible to tweak the osgViewer::Renderer so that it keeps tabs on what RenderStage and associated Camera's are in action and to take a reference where appropriate. Perhaps RenderStage itself could be tweaked to allow on to increment/decrement the ref count of all associated Camera's under the control of the Renderer. Perhaps another tweak might be to have the whole Rendering backend manage the reference counts for StateSet and Drawables as well as Camera in a high level way, as then we could toggle on/off the reference counting when we need it rather than have it on even when it isn't neccessary - such as in SingleThreaded and CullDrawThreadPerContext threading models. Robert. Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
