On Saturday 22 December 2012 16:06:33 Tim Blechmann wrote:
Also, how do people feel about using Boost.Atomic underneath
shared_ptr? (https://svn.boost.org/trac/boost/ticket/5625 - again, I've been using this for a long time and it seems to work.) Maybe as a non-default initially if we're nervous. It might help to find any bugs in Boost.Atomic...
In general I welcome this suggestion. However, shared_ptr probably should not require linking to Boost.Atomic, so some header-only mode should be provided by Boost.Atomic first.
i guess boost.atomic could be extended to work on all platforms that are currently supported by shared_ptr. the required subset could the be header-only ...
I was thinking about splitting the implementation into a guaranteed-to-be- lock-free and the lock pool-based parts (the latter one requires linking to the library). The lock-free part should be accessible through a separate public header, it should not include the lock-based part. boost/atomic.hpp should still include both parts, thus providing the complete atomic<> implementation. It's rather straightforward. Basically, base_atomic<> implementation should be moved from base.hpp into a separate header, and base.hpp should only contain forward declarations. Auto-linking code from config.hpp should be extracted as well and only included when the lock pool-based implementation is included.