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

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