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

Subject: Re: [boost] Fw: [atomic] review results
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2011-11-07 22:42:38

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.