Subject: Re: [boost] Fw: [atomic] review results
From: Tim Blechmann (tim_at_[hidden])
Date: 2011-11-08 04:17:20
hi helge,
> > > 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)
not sure:
* 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.
* 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
> 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.
cheers, tim