Atomic for BsModule

[jonesmz]

No description provided.

[BearishSun]

Earlier on I decided against atomicity for Module. Primarily because it is something you end up paying for on every single call to Module::instance(), and it only really matters during startUp/shutDown calls, which happen once at very specific points.

The memory barriers will prevent the compiler from optimally organizing the code around the relevant call, and can potentially issue a memory barrier instruction (will happen on ARM I believe, but on x86 just guaranteeing the order is enough). Perhaps if the atomicity could be achieved using relaxed memory ordering it would be acceptable but I'm not sure I'd like it even then though.

If we were to go a thread safe route I'd prefer we use a separate version of Module that is thread-safe (perhaps via a policy controlled by a template parameter).

[jonesmz]

Ok, that sounds good.

I'll add a set of bs::StoragePolicy classes that can be given as a template parameter.

Normal, which would just be the normal type being stored.
Thread local, which would be for thread local storage
Atomic, which would wrap the type in std::atomic.

[jonesmz]

Sorry for the long delay on this issue. Busy with other stuff shrug. Still planning to provide a patch as described.