Boost logo

Boost :

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

On Monday, November 07, 2011 23:15:43 Peter Dimov wrote:
> Helge Bahmann wrote:
> > 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.

I think, support for multi-module applications is a must for both libraries,
but Boost.SmartPtr is more lucky in that regard since it requires more wide-
spread atomic ops to operate, so the shared spinlock pool is unlikely to
become an issue.

I see other ways to solve the problem, without dynamic linking. One could
store a pointer to the pool in each atomic<> instance. Although this would
effectively have the same drawbacks as having a spinlock per instance... Or,
prehaps, we could initialize a named shared memory with the spinlock pool.
That would involve dynamic initialization which should be protected against
concurrent execution and may potentially fail if system limits are exceeded.

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