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

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
Helge