Re: [boost] Fw: [atomic] review results

Subject: Re: [boost] Fw: [atomic] review results
From: Tim Blechmann (tim_at_[hidden])
Date: 2011-11-08 05:22:07

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