Would this make btAlignedAllocator thread-safe?

[Jonathan]

I am in a situation where I need multiple dynamics worlds to run at once on separate threads. The only discussion I could find on the subject was here:
http://www.bulletphysics.org/Bullet/php ... 64&p=18373

After reading that, I did some looking at the btAlignedAllocator... the only code I could see that wouldn't be thread-safe would be the following:

Code: Select all

#include "btAlignedAllocator.h"

int gNumAlignedAllocs = 0;
int gNumAlignedFree = 0;
int gTotalBytesAlignedAllocs = 0;//detect memory leaks

...

So, I thought of a simple change that uses C++11's atomics (Note, I'm not making a recommendation to officially include this, just asking if this will work for my purposes.):

Code: Select all

#include "btAlignedAllocator.h"
#include <atomic>

std::atomic<int> gNumAlignedAllocs = 0;
std::atomic<int> gNumAlignedFree = 0;
std::atomic<int> gTotalBytesAlignedAllocs = 0;//detect memory leaks

...

Would this succeed in making btAlignedAllocator thread-safe? The 'malloc' and 'free' operations called should automatically be thread-safe with the right modern compiler options enabled.

Is there anything else under the hood that would prevent multiple instances of btDiscreteDynamicsWorld from working in parallel? (Each one has its own dispatcher, broadphase, solver, and collision configuration instance)

Thanks for any help and/or advice anyone can offer!

[Jonathan]

I don't mean to waste anyone's time... even a simple "no" will suffice if this problem is much deeper than I'm naively looking at it.

[aigamedev]

Not sure I can help much, but anyway...

I'm trying to make contactTest() thread-safe, and generally haven't managed yet. I'm not exactly sure what's causing the problem, but the allocator comes up often in the stack traces when crashes happen.


That said, the variables you point out don't seem to be used for much except statistics in my version (2.80).

Alex

[Jonathan]

Not sure I can help much, but anyway...

I'm trying to make contactTest() thread-safe, and generally haven't managed yet. I'm not exactly sure what's causing the problem, but the allocator comes up often in the stack traces when crashes happen.


That said, the variables you point out don't seem to be used for much except statistics in my version (2.80).

Alex

Are you trying to run contactTest() on the same dynamics world from multiple threads? If so, I could see that being a problem.

[aigamedev]

Are you trying to run contactTest() on the same dynamics world from multiple threads? If so, I could see that being a problem.

Yes, it's the same collision world and I'm hoping to have it used in a read-only way, as opposed to using a ghost object which requires protecting the add()/remove() operations with a lock to be thread-safe. For the contactTest(), apparently some of the broad-phase algorithms are not "const" operations? It hangs most often in the allocator currently, or in one of the stack accesses of btDbvt.

Any advice?

Alex

[Jonathan]

Are you trying to run contactTest() on the same dynamics world from multiple threads? If so, I could see that being a problem.

Yes, it's the same collision world and I'm hoping to have it used in a read-only way, as opposed to using a ghost object which requires protecting the add()/remove() operations with a lock to be thread-safe. For the contactTest(), apparently some of the broad-phase algorithms are not "const" operations? It hangs most often in the allocator currently, or in one of the stack accesses of btDbvt.

Any advice?

Alex

Ah, that's tricky because you'd have to really inspect all of the internal code that contactTest() touches. You also have to be sure that you're not stepping the world in one thread while you call your 'const' functions in another thread, because obviously a lot of internal state is changing at that point. I believe there is a demo source file that shows a bit of multi-threading bullet internally, but it's limited to certain areas of bullet that Erwin has confirmed thread-safe.

I'm very much a novice to the bullet physics engine, so I'm sorry I cannot be of more help.

To reiterate, if Erwin happens to read through this, I am still curious about the thread-safety of SEPARATE dynamic worlds running in parallel.

[aigamedev]

Even if you have separate dynaimcs worlds, the underlying thread-safety issues in the code will be the same. For instance, I just bumped into problems with the allocation and de-allocation of manifolds in btCollisionAlgorithm.cpp, and there's another global/static used there:

Code: Select all

int gNumManifold = 0;

Trying to figure out if that's the cause of my problem. Either way, if it's a problem in my case it will be in yours too!

[Jonathan]

Even if you have separate dynaimcs worlds, the underlying thread-safety issues in the code will be the same. For instance, I just bumped into problems with the allocation and de-allocation of manifolds in btCollisionAlgorithm.cpp, and there's another global/static used there:

Code: Select all

int gNumManifold = 0;

Trying to figure out if that's the cause of my problem. Either way, if it's a problem in my case it will be in yours too!

If there are more global variables other than btAlignedAllocator, then yes, I will have problems too. Although, specifically in btCollisionAlgorithm.cpp I'm not seeing gNumManifold. This is the file I'm looking at:
https://code.google.com/p/bullet/source ... orithm.cpp

Am I looking in the wrong place?

[aigamedev]

The file was btCollisionDispatcher.cpp, sorry I got the name wrong!

I eventually managed to get contactTest() working in parallel by short-circuiting some logic, wrapping mutexes around other code, and manually injecting different allocators/configurations for the code running in each thread. It is possible but I have mutex locks around collision algorithm creation routines, in particular because of the btCollisionDispatcher and the way it creates manifolds.

You may have to do a similar audit of all of the code to be able to entire simulations in parallel.

[Jonathan]

For what it's worth, I ran across this post: http://bulletphysics.org/Bullet/phpBB3/ ... w=previous

I disabled the profiling using

Code: Select all

#define BT_NO_PROFILE 1

aigamedev, I think you're right about the thread-unsafe code being statistics and profiling. After disabling the profiling Worlds seem to be running in parallel okay, but if there are any issues in the future I'll update this thread with any further findings.