On Tuesday 08 November 2011 11:22:07 Tim Blechmann wrote:
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.
well gcc certainly follows the recommendation of the standard by making the *lock-free* atomics both address-free and free from process state, I don't read the standard as suggesting (or even requiring) anything for emulated atomics
but what about msvc or clang/libc++?
libc++ atomic is not yet completed, but does not intend to use a per-object lock. As I read it, they do in fact consider mutex (pool?) instead of spinlock. msvc I don't know yet.
* 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.
under what circumstances did the sizes change? Currently I cannot imagine this *not* being an ABI violation
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?
Frankly I don't know the answer yet so have to experiment. Best regards Helge