Hi Rabbi, The OSG doesn't provide such a mechanism, and in the case of scene graph it wouldn't be a case of locking a node and they do the operation, you have to lock the whole scene graph and then do your operation. The need to lock the whole scene graph is that traversals like the cull and draw traversal have the scene graph is a single consistent state during their whole operation, otherwise you'd end up with a tangled mess of state.
To enable multithreading like you are looking for some scene graphs have gone the route of buffering the scene graph so that the update phase works on one copy, while the reading phases (cull and draw) read from another, then the data is synchronized each frame to make sure the buffers are all consistent. This approach is expensive design, implementation and performance wise so if you can avoid it then you typically can have a more efficient and flexible scene graph. The way to handle multi-threaded update with the scene graph would be to either lock the scene graph access at high level - during the dispatch of the various phases of the frame loop, or to implement a command operation scheme where you place operations on the scene graph into a thread safe queue and then read and apply the operations during the update phase of the scene graph. Robert. On Mon, Feb 1, 2010 at 4:36 AM, Rabbi Robinson <[email protected]> wrote: > Hi, > > I have a multithread application which might update an node (add/remove > children etc) at the same time. Is there any locking mechanism for ensuring > only one thread is in a critical session at any time. > > I look at the source code of Group which just use std::vector for children > list. As far as I know, std::vector is not safe for multiple write. > > I also noticed there is a mutex for reference count, which does not protected > the object itself. > > Thank you! > > Cheers, > Rabbi > > ------------------ > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=23462#23462 > > > > > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
