Scene Graph Multi Thread Advantage?

You won't really see any actual speed gain unless you have multi-core or multi-processor machine. Threading does not magically make anything faster; on a single CPU, you can still execute only a single thread at a time. In this environment, multithreading gives you the "asynchronisity" advantage -- the same advantage that makes it look like I can browse these forums in Opera and compile my game in the background -- the single CPU is doing one thing at a time, it just switched between them so fast that I don't realize it.

As for your actual question, I think putting scene graph updates in a different thread would be vastly more trouble than its worth. You should only render from one thread anyway, and the overhead from the appropriate thread control you'd need to impose to prevent deadlocking and other threading issues would negate whatever speed boost you could potentially see (if any).

In a multithreaded environment, you can generally get the most benefit by splitting unrelated, noncommunicating subsystems (i.e., parrallelizable ones) into isolated threads. A scene graph is not such a system; you'd most likely just be wasting time and overcomplicating things.

I agree with the above poster - its probably more work than its worth.

Something you can do is thread the actual traversal of the "tree" using a workcrew. If you only detect a single proc on the box then the traversal only has a single thread to walk the graph. If they have 2 dual core procs, then there are 4 workcrew threads. Then, at each node where you reach a "fork" (no pun intended...) in the road, you see if you have a free workcrew thread. If you do - you send him down that path.

This would allow your code to be the same with a little extra overhead, and still support threading. This will also avoid having to work out synchronization issues between the whole graph and the rest of the system which would be a real hassle.