boost::shared_ptr is it safe to use it in multiple

问题:

I was trying to find the answer for some time but I failed.

Lets assume that we have a shared_ptr created from one thread. Then we pass this shared_ptr to another 2 threads (using some queue for example). So from this moment there are 2 copies of the original shared_ptr, pointing to the same raw pointer. Both owner threads will take their copies of this shared_ptr from the queue. Then they will pass it to another thread or will destroy it.

Question is - is it safe? Will the raw pointer destroyed correctly (there will be no race to reference counter?)

回答1:

The boost docs state:

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.)

(emphasis mine)

So the crux here is whether you copy the boost::shared_ptrs between threads or not. If you create copies (the "safe" way to use shared_ptrs) you don't have any worries about thread-safety. If however you pass the shared_ptr by reference or pointer, and hence are using the actual same shared_ptr in different threads, you would have to worry about thread-safety, as described in the docs.

回答2:

The C++ standard has almost no guarantees regarding thread safety. The reference count of std::shared_ptr is the only exception: it’s guaranteed to behave as an atomically accessed variable. I believe this is codified in this phrase in §20.7.2.2/4:

Changes in use_count() do not reflect modifications that can introduce data races.

boost::shared_ptr offers the same guarantees:

shared_ptr objects offer the same level of thread safety as built-in types. A shared_ptr instance can be "read" … simultaneously by multiple threads. Different shared_ptr instances can be "written to"… simultaneosly by multiple threads (even when these instances are copies, and share the same reference count underneath.)

回答3:

I would like to post my comment for the reference counting in the boost shared pointer in the multiple threads use cases. The comment is to answer the question that “is there any race condition in the boost shared pointer reference counting?”

My simple answer is “No” at least after boost 1.35 for most mainstream compiler. The boost implementation called “add_ref_copy” defined in the boost/detail/shared_count.hpp. This function will invoke the corresponding atomic function defined for individual compiler. For example, the windows version will call “BOOST_INTERLOCKED_INCREMENT” to increment the count in the atomic way (see details in detail\sp_counted_base_w32.hpp). And the Linux gcc for X86 will call atomic_increment(… ) (see details in detail\sp_counted_base_gcc_x86.hpp). Each individual compiler implemented the thread-safe mechanism to make sure the reference counting update in an efficient way. Some piece of code are even written in assembly.

Now there is a caveats in my simple answer. You really need to make sure your compiler is included in the boost’s blessed list for multiple thread-safe reference counting. If you are not sure you can define “BOOST_SP_USE_PTHREADS” which drives boost to use the pthread library to make reference count update atomically (by including boost/detail/sp_counted_base_pt.hpp for pthread solution).