159

I'm reading http://gcc.gnu.org/onlinedocs/libstdc++/manual/shared_ptr.html and some thread safety issues are still not clear for me:

  1. Standard guarantees that reference counting is handled thread safe and it's platform independent, right?
  2. Similar issue - standard guarantees that only one thread (holding last reference) will call delete on shared object, right?
  3. shared_ptr does not guarantee any thread safety for object stored in it?

EDIT:

Pseudo code:

// Thread I
shared_ptr<A> a (new A (1));

// Thread II
shared_ptr<A> b (a);

// Thread III
shared_ptr<A> c (a);

// Thread IV
shared_ptr<A> d (a);

d.reset (new A (10));

Calling reset() in thread IV will delete previous instance of A class created in first thread and replace it with new instance? Moreover after calling reset() in IV thread other threads will see only newly created object?

Improve this question
3
  • 33
    you should use make_shared instead of new Commented May 14, 2013 at 21:16
  • 4
    In answer to all questions (since edit): right, right, right, wrong and wrong. Commented Oct 4, 2020 at 6:18
  • I’ve tried to give the backed answer here Commented Jan 9, 2021 at 9:42

3 Answers 3

Reset to default
120

As others have pointed out, you've got it figured out correctly regarding your original 3 questions.

But the ending part of your edit

Calling reset() in thread IV will delete previous instance of A class created in first thread and replace it with new instance? Moreover after calling reset() in IV thread other threads will see only newly created object?

is incorrect. Only d will point to the new A(10), and a, b, and c will continue to point to the original A(1). This can be seen clearly in the following short example.

#include <memory>
#include <iostream>
using namespace std;

struct A
{
  int a;
  A(int a) : a(a) {}
};

int main(int argc, char **argv)
{
  shared_ptr<A> a(new A(1));
  shared_ptr<A> b(a), c(a), d(a);

  cout << "a: " << a->a << "\tb: " << b->a
     << "\tc: " << c->a << "\td: " << d->a << endl;

  d.reset(new A(10));

  cout << "a: " << a->a << "\tb: " << b->a
     << "\tc: " << c->a << "\td: " << d->a << endl;
                                                                                                                 
  return 0;                                                                                                          
}

(Clearly, I didn't bother with any threading: that doesn't factor into the shared_ptr::reset() behavior.)

The output of this code is

a: 1 b: 1 c: 1 d: 1

a: 1 b: 1 c: 1 d: 10

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

55

  1. Correct, shared_ptrs use atomic increments/decrements of a reference count value.

  2. The standard guarantees only one thread will call the delete operator on a shared object. I am not sure if it specifically specifies the last thread that deletes its copy of the shared pointer will be the one that calls delete (likely in practice this would be the case).

  3. No they do not, the object stored in it can be simultaneously edited by multiple threads.

EDIT: Slight followup, if you want to get an idea of how shared pointers work in general you might want to look at the boost::shared_ptr source: https://www.boost.org/doc/libs/release/boost/smart_ptr/shared_ptr.hpp.

Improve this answer

4 Comments

1. When you say "'shared_ptrs' use atomic increments/decrements of a reference count value." Do you mean they do not use any internal lock for atomic increment/decrement, which does the context switch? In simple language does multiple threads could increment/decrement reference count without using lock? An the atomic increment is done by special atomic_test_and_swap/atomic_test_and_increment instructions?
@rahul the compiler is free to use a mutex/lock, but most good compilers will not use a mutex/lock on platforms where it can be done lock-free.
@Bernard: do you mean it depends upon "compilers std lib shared_ptr" implementation for the platform?
Yes. From my understanding, the standard does not say that it must be lock-free. But in the latest GCC and MSVC, it is lock-free on Intel x86 hardware, and I think other good compilers are likely to do the same when the hardware supports it.
39

std::shared_ptr is not thread safe.

A shared pointer is a pair of two pointers, one to the object and one to a control block (holding the ref counter, links to weak pointers ...).

There can be multiple std::shared_ptr and whenever they access the control block to change the reference counter it's thread-safe but the std::shared_ptr itself is NOT thread-safe or atomic.

If you assign a new object to a std::shared_ptr while another thread uses it, it might end up with the new object pointer but still using a pointer to the control block of the old object => CRASH.

Improve this answer

11 Comments

We could say that single std::shared_ptr instance is not thread safe. From std::shared_ptr reference : If multiple threads of execution access the same shared_ptr without synchronization and any of those accesses uses a non-const member function of shared_ptr then a data race will occur;
This could be worded better. A std::shared_ptr<T> instance is guaranteed thread-safe when always used by value (copied/moved) across thread boundaries. All other uses, std::shared_ptr<T>& are unsafe across thread boundaries
This answer is very misleading and not clear at all. Yes, a single std::shared_ptr instance is not thread safe, but that's not the intended use case nor is is what is asked in the question.
It is not what's being asked, because the OP does not share the share_ptr object across threads, other than for init. Each thread in the OP has it's own shared_ptr object, and all questions AFAICT pertain to these per-thread shared_ptr objects (that point to a shared object).
This answer would be better off if it was not posted at all. It is completely misleading both to OP trying to understand shared_ptr and to the people searching for "is shared_ptr threadsafe".
|

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.