add, remove, "warp" functions; are they thread safe?

[liquidslade]

Greetings all.

I was curious if removing/adding objects to a btDynamicsWorld, and also the "warp" functions, would be thread safe? I currently have one PPU thread doing stepSimulation on its own, and I am planning to implement an LFQ to add/sub/transfer objects (coming from a different thread). I was wondering if this is necessary.

[Erwin Coumans]

You cannot add/remove/move objects while the stepSimulation is executing. Also you cannot perform multiple add/remove/move operations simulateously, you have to queue them.

If you have a good lock-free-queue implementation that you can share, please consider contributing it.
Thanks,
Erwin

[liquidslade]

Thanks for the heads up.

I can't share the actual source, since this LFQ comes from Sony's SDK. But I can describe my implementation.

I think this can work with any LFQ library out there (are there any? POSIX? Not sure.)

Basically, I got two threads, one thread that does btDynamicsWorld->stepSimulation(), and another "event producer thread". Between these threads is an LFQ. Physics thread consumes, and event producing threads push stuff on the LFQ.

Whenever I wanna do add/remove/warp operations, I make the event producing thread push "events" into the LFQ.

The physics thread will pop things of the LFQ, and read the "event", depending on what type of event it is, perform the needed function. I am hoping this allows stepSimulation to work smoothly, even if I am constantly adding and removing objects from the simulation. (and trying to swim around 60 FPS)

So, before stepSimulation(), the physics thread loop will pop at least one thing from the LFQ and then perform the needed add/remove/warp function.

I haven't tested this thoroughly. And I'm sure the lead devs here have something more complex. This is my first stab at an LFQ and bullet. Any advice on what I have so far?

[liquidslade]

On another note, I'm curious if these btRigidBody functions will be thread safe while stepSimulation is running :

clearForces()
applyForce()
setLinearVelocity()
setAngularVelocity()


As a background, our game engine is being implemented with threads in mind, and is being deployed on the PS3. We're working on a vanilla bullet 2.75 (all on the PPU).

[S.Lundmark]

I think that any method that modifies any of the data is not "thread safe". There are no threading mechanisms in the single-threaded version of bullet. All of those methods modifies the state of the object and thus should be executed at a time where bullet is not reading from them (Between two stepSimulations).

If you're going to implement your game engine with threads in mind on the Ps3, perhaps you should consider the SPU version of bullet. It is available on sony's dev network.

Simon

[liquidslade]

I think that any method that modifies any of the data is not "thread safe". There are no threading mechanisms in the single-threaded version of bullet. All of those methods modifies the state of the object and thus should be executed at a time where bullet is not reading from them (Between two stepSimulations).

If you're going to implement your game engine with threads in mind on the Ps3, perhaps you should consider the SPU version of bullet. It is available on sony's dev network.

Simon

Thanks for the hat tip

We are on the PS3 academic program, unfortunately Sony does not let us have scedevnet access (we have our own version of devnet, but it is still being constructed). We do have source for the SPU version of Bullet (bullet-spu-2.75beta, given to us by our contact at Sony), but there's a few hiccups on the build. We are still investigating it.

For now we are sticking with the single threaded version, and well ramp up to the SPU version once we get the damn thing to compile.