Subject: Re: [boost] Fw: [atomic] review results
From: Tim Blechmann (tim_at_[hidden])
Date: 2011-11-08 04:17:20
> > > this could be avoided by using boost::interprocess::atomic<>, which
> > > will associate a spinlock with each instance ... or by using
> > > std::atomic on c++11 compilers.
> While this problem is definitely an argument in favour of embedding the
> spinlock into each atomic, I am still concerned as this introduces
> incompatibility with std::atomic implementations which may eventually bite
> someone hard (data structure size, expectations -- changing boost to "using
> std::atomic" might have grave consequences, and it's a transition path I
> would like to keep open)
* compilers are not required to implement atomics so that sizeof(atomic<T>) ==
sizeof (T). so the size of a data structure may change when switching
* compilers do change the size of a data structure depending on compiler
flags. some compilers have a notion of `packed' structs, that ensure the
memory layout. however gcc and icc seem to require that all struct members are
PODs, while clang++ seems to accept non-POD members ...
* 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.
> > 2. If (1) is true then boost::atomic<> usefullness is greatly reduced.
> > Most of the time one would use boost::interprocess::atomic<>, even in
> > a single process.
> yes, agreed
> Another option that I have considered would be "piggy-backing" the
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk