On Tuesday, November 08, 2011 00:02:34 Tim Blechmann wrote:
This is a problem in principle, but requiring all users of shared_ptr to link to a shared library is a non-starter. I wouldn't use such a shared_ptr, and I doubt many others will. And I wouldn't be surprised if this sentiment applies to Boost.Atomic as well.
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.
Just some random thoughts: 1. If boost::atomic<> doesn't support multi-module applications, that is it silently works incorrectly in such environments, sould it really support these platforms? I mean, spinlock pool is used when no native atomic ops are available for the given type. Perhaps, it's better not to compile at all in such a case. 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.