Hi Robert,
It has some example of the use of osg::Operation and osg::OperationQueue?
Thanks,
Ronald.
> Hi Ronald,
>
> On 8/6/07, ronaldss <[EMAIL PROTECTED]> wrote:
> > I need to up to date the scene of graph through several threads, therefore
> > he would like to know if the OSG implements some type of synchronization of
> > threads.
> > Where I can find examples?
>
> The OSG is designed to support single threaded update, and
> multi-threaded rendering. It does not support multi-threaded update.
>
> Supporting general multi-threaded update would requires mutexing of
> most operations on the scene graph, this would utterly destroy
> performance. It'd also make it a really awkward to write, extended
> and use. All in all it would be a pretty crappy scene graph, all for
> a type of usage that is very specialized.
>
> So.. where does leave you... we'll not totally high and dry, one can
> implement high level control over access to the scene graph, this is
> non longer a scene graph control though, rather an application centric
> control. What you'll need to do is have a single mutex that each
> thread acquires before it can do any read/write ops on the scene
> graph. The main frame loop will have to use this mutex too, so that
> when it runs the frame() it aquires the lock so that no one else can
> modifiy it which its doing its update and rendering traversals.
>
> Now if you write you code carefully, acquire the lock before writing,
> and release it, then you should be able to get multi-thread update
> working safely. Performance won't be ideal, but it at least should
> work.
>
> Another way to tackle it is rather than using a mutex and let each
> thread acquire it and the modify the scene graph itself, is to do all
> the operations via an subclassing from osg::Operation, then placing
> these operations into a osg::OperationQueue that gets flushed on each
> new frame. The osg::OperationQueue itself can be read/written to
> multi-threaded so can happily handle the usage model you are looking
> for. The upside is that performance will be good, no long waits to
> acquire mutexes, the downside is that the operations are no longer
> synchronous w.r.t calling threads.
>
> Robert.
> _______________________________________________
> 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
