Boost Shared Pointer: Simultaneous Read Access Across Multiple Threads

I have a thread A which allocates memory and assigns it to a shared pointer. Then this thread spawns 3 other threads X, Y and Z and passes a copy of the shared pointer to each. When X, Y and Z go out of scope, the memory is freed. But is there a possibility that 2 threads X, Y go out of scope at the exact same point in time and there is a race condition on reference count so instead of decrementing it by 2, it only gets decremented once. So, now the reference count newer drops to 0, so ther开发者_如何学Goe is a memory leak. Note that, X, Y and Z are only reading the memory. Not writing or resetting the shared pointer. To cut a long story short, can there be a race condition on the reference count and can that lead to memory leaks?

boost::shared_ptr uses locks (or lock-free atomic access) to ensure that reference counts are updated atomically (even if this isn't clear from the docs page). You can configure away the use of the locks if you're writing single threaded code by defining the macro BOOST_SP_DISABLE_THREADS.

Note that the documentation examples in http://www.boost.org/doc/libs/1_42_0/libs/smart_ptr/shared_ptr.htm#ThreadSafety that discuss problems with multiple writes from different threads is discussing those threads acting on the same shared_ptr instances (the shared_ptr objects might be globals in the examples), not different shared_ptr copies that point to the same object, which is the usual use case for shared_ptr's. The example you give in the question (acting on copies that point to the shared object) is thread-safe.

No, according to the documentation, these problems cannot occur:

Different shared_ptr instances can be "written to" (accessed using mutable operations such as operator= or reset) simultaneosly by multiple threads (even when these instances are copies, and share the same reference count underneath.)

Several others have already provided links to the documentation explaining that this is safe.

For absolutely irrefutable proof, see how Boost Smartptr actually implements its own mutexes from scratch in boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp (or your platform's corresponding file).

The documentation says:

Different shared_ptr instances can be "written to" (accessed using mutable operations such as operator= or reset) simultaneosly by multiple threads (even when these instances are copies, and share the same reference count underneath.)

So if none of the threads accesses the pointer objects of the other threads, it should be fine. Please have a look at the examples in the documentation and see which one is relevant in your case.

The best thing to do would be to upgrade to a TR1 or C++0x shared_ptr, as opposed to the Boost variety. I believe that it's standardised that those MUST be thread-safe.