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

Subject: Re: [boost] Fw: [atomic] review results
From: Tim Blechmann (tim_at_[hidden])
Date: 2011-11-07 18:02:34

> > yes makes sense -- there was a concern raised by Andrey Semashev that
> > the
> > spinlock pool as implemented and used by shared_ptr presently may fail
> > on
> > Windows due to the pool being non-unique (not had a chance to test this
> > yet),
> > and I have found a way to produce a similar failure using dlopen,
> > atomics
> > private to shared libraries and RTLD_LOCAL -- currently I am therefore
> > leaning on creating a shared library just for the spinlock pool, but
> > since you wrote the initial implementation maybe you could comment as
> > well?
> 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.

btw, when reworking the spinlock pool, it might make sense to try two changes:

* add some padding to ensure that every spinlock is in a separate cache line
* use test-test-and-set lock

cheers, tim