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
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.
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.
You can use this implementation Atomic Reference Counting Pointers to at least implement the Reference Counting mechanism.
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.)
This may not be exactly what you want, but the boost::atomic
documentation provides an example on how to use an atomic counter with intrusive_ptr
. intrusive_ptr
is one of the Boost smart pointers, it does "intrusive reference counting", which means the counter is "embedded" in the target instead of providing by the smart pointer.
Boost atomic
Usage Examples:
http://www.boost.org/doc/html/atomic/usage_examples.html
In my opinion, the easiest solution is to use an intrusive_ptr
with a few minor (but necessary) modifications.
I shared my implementation below:
http://www.philten.com/boost-smartptr-mt/