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

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.