hi helge,
I think that there is value in trying to maintain sizeof(boost::atomic<T>) == sizeof(std::atomic<T>) whatever this is going to mean per platform, and part of the thing I have in my mind is indeed interprocess-safety. I also don't think that Boost.Atomic it is in that state currently, but I am a bit reluctant to make a decision that might shut down this path forever.
then how do other compilers/library implementations behave? you said that gcc doesn't follow the suggestion of the standard to avoid per-process states. but what about msvc or clang/libc++?
* i could imagine that c++11 compilers may be smart enough to pad adjacent std::atomic<> to ensure that they are placed in separate cache lines. uhh, I hope they *don't* do that as it has grave implications on the ABI (currently the compiler would not be allowed to "fill" the hole with other data members), and cacheline sizes vary by processor generation
cacheline sizes vary, but a compiler might optimize for a commonly used value. however i've been hit more than once by compilers, which are changing the size of structs.
Another option that I have considered would be "piggy-backing" the spinlock pool into Boost.Thread -- the idea is that an application is either single-threaded, or if it is multi-threaded it is expected to link with Boost.Thread (even if nothing from Boost.Thread is used indeed, yes makes me feel uneasy as well).
this would imply that boost.thread cannot be used as static library any more.
That would indeed be bad, but I don't understand why this would be in conflict, could you explain a bit further?
don't you need a shared library to resolve the spinlock pool? cheers, tim