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