Re: [osg-users] OSG Multi-threading questions
Hello again! :) Looks like I am having some multi-threading issues with my application but to be honest I am not sure what is going on. Initialy, I though that the problem had something to do with the fact I load my model in a separate thread and then I add it to the scene from the main thread or using an update callback. But it turns out that the problem might appear even if I do not load my model in a separate thread. The problem arises when I try to add extra views to my composite viewer. At the startup of the application I create a composite viewer, a main view and N extra views. I only add the main view to the composite viewer and everything runs fine. The other three views may have their contexts sharing the resources with main view context or may not. May share the same scene with main view or may not (viewer::setSceneData(NULL)). It doesn't matter, the problem appears in all cases. Here is the problem now: When I try to add the views to the composite viewer the application freezes. I tried to stop threading before adding a view and start threading again after adding them, but I still have the same problem. The threading mode composite viewer uses is CullThreadPerCameraDrawThreadPerContext. The problem won't appear if: I stop the threading and not restart it again or use one of the following modes: DrawThreadPerContext, SingleThreaded. Looks like I have some deadlock in my application. Using the debugger I can see that when my application freezes a lot of threads are waiting blocked: The main thread blocks at OpenThreads::cooperateveWait() in Win32Thread.cpp line 55. If I move backwards on the stack, looks like the whole problem starts at the line 846 of ViewerBase.cpp: _endDynamicDrawBlock-block(); If I check the member variables of the _endDynamicDrawBlock pointer I see that: _blockCount = number of total views attached to the composite viewer _currentCount = always 1 Using the debugger I can also see that other N + 1 threads are blocked (again, where N the number of views attached to the composite viewer): The N threads (I guess these are the rendering theads, one for each viewer) are blocked at OpenThreads::cooperateveWait in Win32Thread.cpp line 50. If I walk the call stack backwards the problem starts at OperationThread::run() in OperationThread.cpp line 426: (*operation)(_parent.get()); The extra (+1) thread (no idea what this thread is for) is blocked at OpenThreads::cooperateveWait in Win32Thread.cpp line 50. If I walk the call stack backwards the problem starts at Renderer::draw() in Renderer.cpp line 649: osgUtil::SceneView* sceneView = _drawQueue.takeFront(); * Any idea what may be causing these deadlocks? * What is the right way of adding/removing extra views to a composite viewer who is already running? Btw: I am using OSG version 3.0.0 Thanks a lot for your time and sorry for the long post! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43415#43415 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSG Multi-threading questions
Hello there OSGers! :) Apologies if what I am asking here is already answered in some other thread of this forum, but I couldn't find everything I was looking for. I have some questions regarding multi-threading and run-time scene-graph hierarchy changes. What is the right/safe way to change something in a scenegraph during the runtime(mostly add and remove nodes)? Add/remove them just before you call viewer::frame() or using some UpdateCallback? If I understand correctly, the rendering threads of OSG are called continuously after you realize the viewer. Even if you are not calling viewer::frame() right? Does this mean that I have to viewer::start/stopThreading every time I want to update a part of the scene hierarchy (load, compile and add a node, remove another node etc)? Is there anything else that I should be aware of when I load nodes in the background and then add/remove them to/from the scenegraph on runtime? Node: I don't use osg::ProxyNode for my reasons. Thanks a lot for your time guys! Cheers, George -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43230#43230 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG Multi-threading questions
On 10/6/2011 6:17 AM, George Bekos wrote: Add/remove them just before you call viewer::frame() or using some UpdateCallback? Either should be fine. If I understand correctly, the rendering threads of OSG are called continuously after you realize the viewer. Even if you are not calling viewer::frame() right? No. They are dispatched by frame(). Cheers, George -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Digital Imaging. OpenGL. Scene Graphs. GIS. GPS. Training. Consulting. Contracting. There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG Multi-threading questions
Thank you for the quick response my friend! Can I also assume that after viewer::frame() returns, it is guaranteed that no OSG threads related to rendering or scene traversal are running? Can I ask what is the use of viewer::start/stopThreading() then? Thanks a lot! Cheers, George -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43232#43232 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG Multi-threading questions
Hi George, Can I also assume that after viewer::frame() returns, it is guaranteed that no OSG threads related to rendering or scene traversal are running? Rendering : no you can't assume this. Scene traversal : yes you can assume this. The explanation: In some multithreading modes (see osgViewer::ViewerBase::setThreadingModel) frame() will return when the DYNAMIC drawables / state have been dispatched. So if you're modifying drawables / state in the update phase (before calling frame() or in an update callback) you need to mark those as DYNAMIC (see osg::Object::setDataVariance). osgText::Text objects are perfect examples of this - if you modify one such object by calling setText() on it, you need to mark it as DYNAMIC. However, at that point (between calls to frame()), the graph structure is not needed anymore by the draw threads, so you're free to modify the structure as you want. Just make sure, if you modify the graph structure in the update traversal, that you only do it for your children, otherwise you'll be invalidating iterators and will get crashes. Can I ask what is the use of viewer::start/stopThreading() then? Things that affect the draw traversals sometimes need draw threads to be stopped completely. Things like adding views to a CompositeViewer, or changing the graphics context on a camera, or things like that. It's pretty rare you need to do this. It's also pretty costly, because stopThreading() will only return once the draw threads have been stopped and deleted, and startThreading() only returns once new draw threads have been created and started. Hope this helps, J-S -- __ Jean-Sébastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG Multi-threading questions
Thanks so much guys. I think I have a much better understanding now. Thanks a lot! Cheers, George -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43234#43234 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
