Using postStepCallback for async thread?

[arshad]

Hi there,

First wanted to publicly thank you for all of the effort you've put into this package and your support on the forums .. you've done an amazing job! Thank you!

Question:

I have a thread that runs asynchronously to the main thread handling the physics stepping. This async thread adds/removes shapes, and occasionally I get the semaphore error that I'm trying to add or remove while its performing the step. To get around this, I'm adding a postStepCallback from the async thread. I know this is intended for collision handlers, but is it safe to do it in this manner as well?

[arshad]

Hmm, I think the answer to this is no. Seems to run perfectly fine in the simulator, but hangs when processing the postStepCallback's on the device.

Should this work? If not, is there a better way to do this?

[slembcke]

Chipmunk is not thread safe. Individual Chipmunk spaces can be run on separate threads without causing any problems however.

If you really want to access a space from multiple threads you will have to put locks on accessing the space, or probably better, a queue of objects to add/remove. Is there some performance reason to be using this second thread? If you add locks and continue using multiple threads it will probably not only be far more complicated but also slower. Threads in games are generally a lose/lose situation unless you can implement things with minimal or no locking.

[slembcke]

Not to completely discourage you from using threads (although I'm trying pretty hard). Having written a lot of threaded code myself, I would be irresponsible not to share the best advice I know:

"If you think you have a problem that can be solved with threads, now you probably have two problems."

[arshad]

Haha, ok thanks Is there a flag I can check in the space itself to see if it's locked?

The reason for the async thread is that it depends on paging in data which is largely DMA'ing in the background while I can continue on with game code in the main thread without stalling for the load. Once the background thread has loaded up the needed data, it attempts to add and remove some stuff from the space from that async thread. I was hoping that the postStep function would help, but it seems to behave differently on single core vs multi-core.

ie in the simulator it only works correctly if I do the add/removal in a postStep callback, but on the device, it only works if I don't. I understand why the callback is necessary in multicore, but not sure why it would fail on single core.

One issue is that with the A5 in the iPad2, and in the upcoming iPhone5 there's 2 cores, so I may have to do some runtime detection if I want to continue using this method. It's probably just easiest and most performant if I implement the queueing method as you suggested. Thanks for the insight!

[slembcke]

Not in the public API. The "lock" is to prevent modification of data structures while iterating them. It's not a mutex lock. That will not really help you. Also, I think you are just getting lucky that postStep() callbacks are working for you. I can guarantee that you will run into issues later if you keep doing this.

I think what you should do is to load up the data in a second thread like you are to avoid the file I/O blocking, then pass the data back to the main thread using [NSObject performSelectorOnMainThread:withObject:waitUntilDone:] (or whatever) and add the physics objects there. You simply can't be simulating on one thread and adding objects on another. It's 100% not safe to do, and adding the locking necessary to make it work would probably just end up being slower than a single thread anyway.

You could always amortize the addition cost if you get hiccups when adding large amounts of physics objects in one step. Keep a queue of objects to add and only add X amount per frame or something.

[arshad]

Thanks Scott. I'll follow your advice and get rid of the postStepCallback's and use some other mechanism to only add/remove from the main thread. Thanks for the suggestions!