Fully thread-safe shared_ptr implementation

Question

Does anybody know of a fully thread-safe shared_ptr implementation? E.g. boost implementation of shared_ptr is thread-safe for the targets (refcounting) and also safe for simultaneous shared_ptr instance reads, but not writes or for read/write.

(see Boost docs, examples 3, 4 and 5).

Is there a shared_ptr implementation that is fully thread-safe for shared_ptr instances?

Strange that boost docs say that:

shared_ptr objects offer the same level of thread safety as built-in types.

But if you compare an ordinary pointer (built-in type) to smart_ptr, then simultaneous write of an ordinary pointer is thread-safe, but simultaneous write to a smart_ptr isn't.

EDIT: I mean a lock-free implementation on x86 architecture.

EDIT2: An example use case for such a smart pointer would be where there are a number of worker threads which update a global shared_ptr with a their current work item and a monitor thread that takes random samples of the work items. The shared-ptr would own the work item until another work item pointer is assigned to it (thereby destroying the previous work item). The monitor would get ownership of the work item (thereby preventing the work item to be destroyed) by assigning it to its own shared-ptr. It can be done with XCHG and manual deletion, but would be nice if a shared-ptr could do it.

Another example is where the global shared-ptr holds a "processor", and is assigned by some thread, and used by some other thread. When the "user" thread sees that the processor shard-ptr is NULL, it uses some alternative logic to do the processing. If it's not NULL, it prevents the processor from being destroyed by assigning it to its own shared-ptr.

Answer 1

Simultaneous write to a built-in pointer is certainly not thread safe. Consider the implications of writing to the same value with respect to memory barriers if you really want to drive yourself crazy (for instance, you could have two threads thinking the same pointer had different values).

RE: Comment - the reason built-ins aren't double deleting is because they aren't deleting at all (and the implementation of boost::shared_ptr I use wouldn't double delete, since it uses a special atomic increment and decrement, so it would only single delete, but then the result would could have the pointer from one and the ref count of the other. Or pretty much any combination of the two. It would be bad.). The statement in the boost docs is correct as it is, you get the same guarantees as you do with a built-in.

RE: EDIT2 - The first situation you are describing are very different between using built-ins and shared_ptrs. In one (XCHG and manual delete) there's no reference count; you are assuming you are the one and only owner when you do this. If using shared pointers, you are saying other threads might have ownership, which makes things far more complex. I believe it is possible with a compare-and-swap, but this would be very non-portable.

C++0x is coming out with an atomics library, which should make it much easier to write generic multi-threaded code. You'll probably have to wait till that comes out to see good cross-platform reference implementations of thread-safe smart pointers.

Answer 2

I don't know of such a smart pointer implementation, though I have to ask: how could this behaviour be useful? The only scenarios I can think of where you would find simultaneous pointer updates are race conditions (i.e. bugs).

This is not a criticism -- there may well be a legitimate use case, I just can't think of it. Please let me know!

Re: EDIT2 Thanks for providing a couple of scenarios. It does sound like atomic pointer writes would be useful in those situations. (One little thing: for the second example, when you wrote "If it's not NULL, it prevents the processor from being destroyed by assigning it to its own shared-ptr", I hope you meant that you assign the global shared pointer to the local shared pointer first then check whether the local shared pointer is NULL -- the way you described it is prone to a race condition where the global shared pointer becomes NULL after you test for it and before you assign it to the local one.)

Answer 3

Your compiler may already provide the thread safe smart pointers in the newer C++ Standards. I believe TBB is planning on adding a smart pointer, but I don't think it's been included yet. You may be able to use one of TBB's thread-safe containers, though.

Answer 4

Adding the necessary barriers for such a fully thread-safe shared_ptr implementation would likely impact performance. Consider the following race (note: pseudocode abounds):

Thread 1: global_ptr = A;

Thread 2: global_ptr = B;

Thread 3: local_ptr = global_ptr;

If we break this down into its constituent operations:

Thread 1:

A.refcnt++;
tmp_ptr = exchange(global_ptr, A);
if (!--tmp_ptr.refcnt) delete tmp_ptr;

Thread 2:

B.refcnt++;
tmp_ptr = exchange(global_ptr, B);
if (!--tmp_ptr.refcnt) delete tmp_ptr;

Thread 3:

local_ptr = global_ptr;
local_ptr.refcnt++;

Clearly, if thread 3 reads the pointer after A's swap, then B goes and deletes it before the reference count can be incremented, bad things will happen.

To handle this, we need a dummy value to be used while thread 3 is doing the refcnt update: (note: compare_exchange(variable, expected, new) atomically replaces the value in variable with new if it's currently equal to new, then returns true if it did so successfully)

Thread 1:

A.refcnt++;
tmp_ptr = global_ptr;
while (tmp_ptr == BAD_PTR || !compare_exchange(global_ptr, tmp_ptr, A))
    tmp_ptr = global_ptr;
if (!--tmp_ptr.refcnt) delete tmp_ptr;

Thread 2:

B.refcnt++;
while (tmp_ptr == BAD_PTR || !compare_exchange(global_ptr, tmp_ptr, A))
    tmp_ptr = global_ptr;
if (!--tmp_ptr.refcnt) delete tmp_ptr;

Thread 3:

tmp_ptr = global_ptr;
while (tmp_ptr == BAD_PTR || !compare_exchange(global_ptr, tmp_ptr, BAD_PTR))
    tmp_ptr = global_ptr;
local_ptr = tmp_ptr;
local_ptr.refcnt++;
global_ptr = tmp_ptr;

You've now had to add a loop, with atomics in it in the middle of your /read/ operation. This is not a good thing - it can be extremely expensive on some CPUs. What's more, you're busy-waiting as well. You can start to get clever with futexes and whatnot - but by that point you've reinvented the lock.

This cost, which has to be borne by every operation, and is very similar in nature to what a lock would give you anyway, is why you generally don't see such thread-safe shared_ptr implementations. If you need such a thing, I would recommend wrapping a mutex and shared_ptr into a convenience class to automate locking.

Answer 5

You can easily do this by including a mutex object with every shared pointer, and wrapping increment/decrement commands with the lock.

Answer 6

I dont think this so easy, it is not enough to wrap your sh_ptr classes with a CS. It is true that if you maintain one single CS for all shared pointers it can ensure to avoid mutual the access and deletion of sh_ptr objects among different threads. But this would be terrible, one CS object for every shared pointer would be a real bottleneck. It would be suitable if every wrappable new ptr -s have different CS s' but this way we should create our CS dinamically, and ensure the copy ctors of sh_ptr classes to transmit this shared Cs. Now we arrived to the same problem: who quaranties that this Cs ptr is already deleted or not. We can be a little more smarty with volatile m_bReleased flags per instance but this way we cannot stuck the safety gaps between checking the flag and using the shared Cs. I can't see completely safe resolution for this problem. Maybe that terrible global Cs would be the minor bad as killing the app. (sorry for my english)

Answer 7

You can use this implementation Atomic Reference Counting Pointers to at least implement the Reference Counting mechanism.