[ODE] Ode And Threads

Patrick Enoch Hendrix_ at gmx.net
Fri Jun 8 12:02:51 MST 2007

This might be a good place to share my expericence with multi- 
threading ODE:

Right now I the collisions are running in parallel in ODE without any  
changes in ODE itself.
I am using the near-callback. Here is how:

- create "worker threads" (I have about 20). Basically, they are the  
nearcallback function waiting on a multithreaded-shared-message queue  
for the two object IDs
- a near-callback stub, being called from dSpaceCollide, that sends  
the objectIDs to the queue
- after dCollide we need to wait until the message-queue is empty

It looks like this:

	// create  worker threads
	for (i=0;i<20;i++) create_thread( ODE_nearcallback );

	// create msgq
	create msgq;

	// call AABB collider
	dSpaceCollide(world, ODE_nearcallback_stub);

	// wait for empty q
	while (!msgq.isempty()) {};

	// send "kill" message
	for (i=0;i<20;i++) msgq.sendmsg( 0,0 );

ODE_nearcallback_stub( o1, o2 )
	// can collide at all??
	if ( can_collide(o1,o2) )
		// send "collide" message
		msgq.sendmsg( o1, o2 );

	while (1)
		objectID o1,o2;
		msgq.getmessage( o1,o2 );

		if (o1==0 && o2==0)

		global_lock_acquire( o1, o2 );
		global_lock_release( o1, o2 );

		global_lock_acquire( world);
		// create contacts

You see, you need a lot of workers, because the messages sent to the  
queue will have lots of objects in common, e.g.

- collide A,B (received by thread 1)
- collide A,C (received by thread 2, has to wait until A,B is done)
- ...
- collide D,E (received by thread N, can proceed right away)

You need to lock the world, because only 1 thread can add contacts to  
the world at a time.

If you want to use trimeshes, there is extrawork, because the  
colliders use static data (for speedup purposes). So you could only  
collide 1 trimesh, never parallel in its current version of ODE.

The collision time is about halved on my dual-core. I guess the  
indentation i messed up when I send the above code to the list.


my next plan is to parallelize the handling of the islands. the data  
structures do not overlap, which is great. however, this cannot be  
done without changing ODE (like a process_islands_callback).


On 08.06.2007, at 20:33, Jon Watte (ODE) wrote:

> Vic Ulis wrote:
>> iget a suspicius "invalid operation for locked space".
>> i suspect this is an error produced by threading in my app.
>> are ode thread safe?
> ODE is documented as explicitly not thread safe.
> What I do when I thread ODE apps is to create a single thread that  
> calls
> ODE, and farm out all requests to that thread. For initial level  
> set-up
> and final tear-down, it might be convenient to do that from another
> thread, but if so, you have to make sure the worker thread won't
> suddenly wake up while you're in the middle.
> Cheers,
>           / h+
> _______________________________________________
> ODE mailing list
> ODE at ode.org
> http://ode.org/mailman/listinfo/ode

More information about the ODE mailing list