Re: [simspark-devel] Countdown for Atlanta

[Markus R. <rol...@un...>]

Hi all,

Yuan Xu wrote:
[...]
> The fact is that, all the threads should be executed in the right
> order. There are only one scene in the server, the agent-manager
> thread and monitor-manager thread often have to wait the physic
> thread. On the other hand, the physic thread can not run before the
> other thread finish their loops. I think if we want to make them
> running simultaneously, a copy of scene is needed. I draw a graphic
> to explain my idea, please see 
> http://picasaweb.google.com/xuyuan.cn/C75/photo#5065569456434569362 
> And the cached scene and the action queue can make some delay to the 
> perception and action, the delay is the factor the real robot should 
> face. However the scene copying is costing, so I can not make sure
> this will be better.

I think we already have a full copy of the scene state that is relevant 
to physics: The ODE library itself holds all relevant state ;-)

Therefore it should be possible to run the physics thread in parallel. 
Possible conflicts only arise when the new ODE state is written back to 
the scene graph. At this point we have to wait for other threads to 
become ready.

The point from which the physics thread could run in parallel lies 
within the SceneServer::Update() method _after_ the call to 
PrePhysicsUpdate(). From this point on the collision handling and 
stepping of the world relies entirely on the internal ODE state. 
Therefore both steps could be run in parallel to e.g. the OpenGL thread.

The collision handling runs mostly within ODE code. Excpetions are the 
collision callbacks that may modify the scene in turn. The most common 
Collisionhandler nodes are the ContactJointHandler. This nodes calls the 
  dJointAttach ODE function and should therefore be no problem.

Other collision handler nodes are derived from the recorder handler that 
collects collision events for further processing within the node itself. 
The collected information is ususally only referenced after the physics 
update, e.g. from the SoccerRuleAspect or some sensor implementation.

If other threads don't modify the ODE state while the physics thread 
runs, there should be no problem. However as ODE is quite stack hungry, 
we might have to increase the stack size manually in the pyhsics thread 
[1,2].

Cheers,
Markus

[1] http://thread.gmane.org/gmane.comp.lib.ode/12094/focus=12095
[2] 
http://news.gmane.org/find-root.php?message_id=%3c7dfa3e5505081812185ce79b97%40mail.gmail.com%3e