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.