[ODE] Ode And Threads

[Patrick Enoch]

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:

ODE_do_collide
{
	// 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 );
	}
}

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

		if (o1==0 && o2==0)
		{
			suicide;
		}

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

		global_lock_acquire( world);
		// create contacts
		global_lock_release(world);
	}
}


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).

best,
Patrick

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