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