static variable use in btMLCPSolver.cpp prevents independent solving in multithreaded environments

[CodeMatias]

Several variables in btMLCPSolver::createMLCPFast and btMLCPSolver::createMLCP are defined as static, which prevents independent simulations within the same process from properly executing with MLCP solvers.

Tests done by moving the variables to non-static with class scope allows safe behavior, but is there a performance or other reason for those variables to be static?

[lunkhound]

Those are static to avoid dynamic memory allocations on every call, so performance is the reason. Moving them to class scope should do just as well. A nicer alternative would be making them thread_local instead of static. This would be cleaner code since you wouldn't be cluttering up the class with a bunch of data members that don't contain any data. But thread_local is a C++11 thing, so we might need to create a BT_THREAD_LOCAL macro for compatibility.

[edit] On second thoughts, it looks like thread_local isn't well supported for objects with contructors/destructors. It isn't supported in the latest MSVC for example. Given that, I think simply moving them into class scope is a better option.

[erwincoumans]

I'm not planning to depend on C++11 just yet, so moving the memory as a class member should be fine. Do you mind creating a patch? Otherwise I'll do it later.

[lunkhound]

Someone on the Bullet forums (Basroil), have said they are making a patch for this.

[http://bulletphysics.org/Bullet/phpBB3/viewtopic.php?f=9&t=10232&sid=c266427de1e84e2b153b5de6f98dfdad&start=45]

[erwincoumans]

Would it be fixed by this large pull request?
#303
I still have to review if all those changes are acceptable (rather not break the API etc)

[lunkhound]

No, I was waiting for Basroil to submit his patch, otherwise I would have included it in that pull request.

If it would help, I can try to condense the number of commits in #303, there were a few dead-end lines of development that I ended up backing off of.