OpenSceneGraph Forum Forum Index OpenSceneGraph Forum
Official forum which mirrors the existent OSG mailing lists. Messages posted here are forwarded to the mailing list and vice versa.
 
   FAQFAQ    SearchSearch    MemberlistMemberlist    RulesRules    UsergroupsUsergroups    RegisterRegister 
 Mail2Forum SettingsMail2Forum Settings  ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
   AlbumAlbum  OpenSceneGraph IRC ChatOpenSceneGraph IRC Chat   SmartFeedSmartFeed 

OSG Multi-threading questions [new problem with multiple Views]


 
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General
View previous topic :: View next topic  
Author Message
bekos
User


Joined: 03 Dec 2010
Posts: 31

PostPosted: Thu Oct 06, 2011 12:17 pm    Post subject:
OSG Multi-threading questions [new problem with multiple Views]
Reply with quote

Hello there OSGers! Smile

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?
Note: I don't use osg::ProxyNode for my reasons.
Thanks a lot for your time guys!

Cheers,
George


Last edited by bekos on Fri Oct 14, 2011 11:51 am; edited 2 times in total
Back to top
View user's profile Send private message
Chris 'Xenon' Hanson
Guest





PostPosted: Thu Oct 06, 2011 12:32 pm    Post subject:
OSG Multi-threading questions
Reply with quote

On 10/6/2011 6:17 AM, George Bekos wrote:
Quote:
Add/remove them just before you call viewer::frame() or using some UpdateCallback?

Either should be fine.

Quote:
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().

Quote:
Cheers,
George



--
Chris 'Xenon' Hanson, omo sanza lettere. 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


------------------
Post generated by Mail2Forum
Back to top
bekos
User


Joined: 03 Dec 2010
Posts: 31

PostPosted: Thu Oct 06, 2011 12:47 pm    Post subject:
Reply with quote

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? Or let me ask it differently: Why would someone want to call viewer::start/stopThreading()?

Thanks a lot!

Cheers,
George
Back to top
View user's profile Send private message
Skylark (Jean-S├ębastien Guay)
Professional


Joined: 05 Jan 2009
Posts: 2249

PostPosted: Thu Oct 06, 2011 2:13 pm    Post subject:
OSG Multi-threading questions
Reply with quote

Hi George,

Quote:
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.

Quote:
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 Guay
http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
bekos
User


Joined: 03 Dec 2010
Posts: 31

PostPosted: Thu Oct 06, 2011 2:48 pm    Post subject:
Reply with quote

Thanks so much guys. I think I have a much better understanding now.
Thanks a lot!

Cheers,
George
Back to top
View user's profile Send private message
bekos
User


Joined: 03 Dec 2010
Posts: 31

PostPosted: Fri Oct 14, 2011 11:50 am    Post subject:
Reply with quote

Hello again! Smile

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!

EDIT: The problem mostly appears when I try to add the views for second time (app_startup->addViews->removeViews->addViews(freezes here)). Although sometimes it might freeze from the first try or 3rd, 4th etc. Keep in mind that the main view is added once at the start and stays there until the termination of the application.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum

Similar Topics
Topic Author Forum Replies Posted
No new posts Issues with rendering two views of th... Patrik Andersson General 6 Tue Apr 22, 2014 7:26 am View latest post
No new posts osgAnimation Ragdoll Problem maxxar General 0 Fri Apr 18, 2014 8:33 am View latest post
No new posts multi-threading troubles with 2 graph... ThierryPebayle General 3 Tue Apr 15, 2014 1:29 pm View latest post
No new posts osgCompute Questions [or... osgComput... sholmes osgCompute [osgCompute] 0 Wed Apr 09, 2014 2:10 pm View latest post
No new posts osg 3.2.0 rendering problem vs osg 3.1.2 kornerr General 4 Wed Apr 09, 2014 7:51 am View latest post


Board Security Anti Bot Question MOD - phpBB MOD against Spam Bots
Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP