[shared_ptr] Is reference counting thread safe in boost 1.38

Hello, I am trying to replace a home grown shared pointer which uses expensive lock (mutex) to make the increment and decrement thread safe. I went through the boost code and see it uses atomic operations. I am not able to figure out if the following case is handled: 1. Thread 1 has a shared_ptr and hence the reference is 1 2. Thread 1 is in the process of decrementing the reference and thread 2 is in the process of incrementing the the reference 3. If thread 1 succeeds in decrementing, the reference will become 0 and hence 'destroy' will get called. 4. Can thread 2 increment after when thread 1 is in a call to destroy? The reference count variable is itself protected but is the call to destroy and reference count variable synchronized? -dhruva Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/

I am not able to figure out if the following case is handled:
1. Thread 1 has a shared_ptr and hence the reference is 1
Why do you conclude that the reference is 1? If both thread 1 and thread 2 have access to the underlying object, the reference should be at least 2.
2. Thread 1 is in the process of decrementing the reference and thread 2 is in the process of incrementing the the reference 3. If thread 1 succeeds in decrementing, the reference will become 0 and hence 'destroy' will get called.
So it looks like thread 1 gave thread 2 a reference to its shared_ptr instead of a copy of its shared_ptr. Later on, it "invalidated" the reference, by letting the shared_ptr go out of scope. So the "thread safety" problem seems to be in the code that uses shared_ptr, not in shared_ptr.
4. Can thread 2 increment after when thread 1 is in a call to destroy?
No, it can't. But this is not a bug of shared_ptr, as explained above.
participants (2)
-
dhruva
-
Thomas Klimpel