Tom Pearce wrote:
Hello all,
I'm working on project where a viewer is running in one thread, and user
input/physics simulations/external devices/etc. are happening in one or more
other threads, but need to modify the scene graph. Currently, we use mutexes
which the other threads modify, and update callbacks access the appropriate
mutex to find out if anything has changed. I was reading some older forum
topics which said the OSG doesn't natively support asynchronous updating, so
this seemed like a good way to accomplish our goal - right now it does
everything we need it to.
However, I was thinking it might be possible to eliminate the "middle man" by
having my update callback itself derive from OpenThreads::Mutex, and creating two methods
(one for updateData() and one called by operator()) which lock the mutex, act on the
data, and unlock it. I'm wondering if anyone with more experience sees anything wrong
with this approach, either conceptually or because of performance issues.
Thanks for any input!
Cheers,
Tom
Seems possible, but I don't see that it would buy you anything with respect to
efficiency.
You might want to take a look at osgbullet.googlecode.com. It supports physics
and rendering in separate threads using a triple buffer mechanism. The triple
buffer mechanism allows the mutex to be held only as long as it takes to swap a
pointer. Reading and writing of the data is then done asynchronously. There's
never a need for one thread to wait for another thread to finish its IO operations.
--
-Paul Martz Skew Matrix Software
http://www.skew-matrix.com/
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
