Boost logo

Boost :

Subject: Re: [boost] Fw: [atomic] review results
From: Helge Bahmann (hcb_at_[hidden])
Date: 2011-11-08 03:22:29

On Tuesday 08 November 2011 04:42:38 Andrey Semashev wrote:

Peter Dimov <pdimov_at_[hidden]> 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.

I share this sentiment as well -- however a separate library may not be too
bad considering that the spinlock pool is unused if all operations are
natively supported (thus the large majority of users could just "forget"
linking the library and would never notice -- this would include atomic
reference counts)

Tim Blechmann wrote:
> > 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)

> 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.

silently working incorrectly is very very very bad -- failing to compile
and/or link is much better in this 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.

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).

In that case I could play "weak reference" tricks such that the pool is used
when linked in, and for single-threaded applications no mutual exclusion is
done and they work just fine nevertheless.

Too whacky? Maybe piggy-backing into Boost.Thread without weak reference
tricks might also be something to consider?

Best regards

Boost list run by bdawes at, gregod at, cpdaniel at, john at