While modifying a simply int will won't crash or deadlock an app, but it can lead to inconstent results of the various traversals that are happening. For instance if you are running multipipe, and one cull traversal hit a node mask of 0xffffffff it'll accept the subgraph and draw whats underneath, but a parallel thread arrives just after and the mask has now changed to 0x0 it'll disgard the subgraph and not draw the subgraph. The result of this would inconsistent results on screen. This is benign example of this, I wouldn't be suprised if more problematic things might happen.
Changing things the such as restructering the scene graph during cull-draw traversal is absolutely asking for trouble. Even if you made each operation on the scene graph thread safe, you'll still end up with iterators broken, and inconsistent traversal results. Again disaster even in a thread safe environment.
So... basically you can't modify the scene graph during cull-draw, only during update and this should be done single threaded. In you case you'd need to queue up the scene graph changing operations till the update phase comes around and do all the modifications together.
The only way to to modify the scene graph during cull-draw would be to multi-buffer it, so the threads reading have a single consisten scene graph, but allow the writing threads to work on their own copy. However, this has enormous consequences for the complexity of the design, and performance of the overall system. With the OSG we have deliberate not gone down this route, and have no plans to.
However, on a small scale one can multi-buffer structures that you know you are going to change. Or run two copies of the scene graph, perhaps in even different apps altogether, and then communicate the changes required, and do the updates during the update single threaded update phase.
Robert.
Helle Robert,
As an example, we have an haptic thread running with the Newton physic engine. When the haptic hand is approaching an object, we want to highlight a bounding box (osg::Box in a geode) around the object. To do so, we initially set the node mask of the bounding box to x00 to make it invisible. When the object is "selected" as we call it, we set the color to the appropriate selection context and put the mask back to xFF.
We also have some events which can come from a network thread like "create object" and "remove object". These events would modify the scene graph hierarchy asynchronously.
Position and orientation are easier to put into a standard format for every module that we have so every node simply request an update during the update callback and apply matrices at the right time. So, there is no problem for that. However, other properties like colors, shapes and hierarchy are more complex to standardize over a network.
I suppose that a state modification like the mask is threadsafe but the scene graph hierarchy modifications are not. Am I right?
Thanks!
Frederic
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 13, 2006 4:05 PM
To: osg users
Subject: Re: [osg-users] Is OSG threadsafe yet?
Hi Fredric,
Pretty well all the examples in the distribtion are capable running multi-threaded multi-pipe out of the box, I run this way on my dual core, dual graphics card system every day. There is also the database pager which is designed from the ground up to work in a background thread.
The design is such that the updating of the main scene graph is all done single threaded, with a thread per camera running cull-draw pairs in parallel. The database pager works on a seperate subgraph, and when ready merges it with the main scene graph during the update phase. All this is done safely with all the criticial parts syncronized to prevent threading issues.
Now if you a question about general thread safety its a different story, the OSG is very much not thread safe in a totally general purpose way, and we'd be made to try and implement such a scheme as it would totally kill performance having to mutex lock practically all ops on the scene graph.
So if you say what type of operations you want to do in parallel and we'll be able to tell you if that'll fit nicely or you'll need to refactor.
Robert.On 9/13/06, Drolet, Frederic (LTI) <[EMAIL PROTECTED]> wrote:
Hello everyone,
I just read a message in the archives from 2004 about how to protect the scene graph from external threads. In my application, all heavy computational work is done in another thread than OSG and I want to modify the scene graph asynchronously. You mentionned two solutions : locking the whole tree between frame() and sync() or having a copy of the tree and apply changes when it is appropriate. While the first approach is really bad for performance since the modifying threads will have to wait the end of each frame for every updates, the second one can also be very expensive if the scene graph is large. The compromise solution would be to keep a copy of the data into each node and only apply changes to a specific node when it is appropriate instead of the whole tree at every frame. I know there is still the problem of hierarchy changes (if the parent or children of a node are changed) but it would be easy to do so for states and attributes. I was wondering if this stuff has been done since 2004. If not, I can still do it on a higher level by keeping 2 copies of each displayed node into a group but I think it would be better if the low level code was doing that itself ! I just wanted to know if it was done before doing it myself.
In fact, all this message was only for a simple question : is OSG has been modified in any way to be threadsafe since 2004 ? Is that a feature you want to include in the future ? I understand that it is not necessary to do so if the application is controlled entirely by OSG but it could be interesting to have a threadsafe scene graph for external modules (and threads) integration.
Thanks for your time !
Best regards,
Frederic Drolet
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
