117

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?

lysergic-acid
  • 17,990
  • 18
  • 96
  • 194
Goofy
  • 4,637
  • 4
  • 34
  • 55

3 Answers3

93

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

Community
  • 1
  • 1
Nicu Stiurca
  • 8,024
  • 5
  • 37
  • 46
37

  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: http://www.boost.org/doc/libs/1_37_0/boost/shared_ptr.hpp.

seh
  • 14,430
  • 2
  • 48
  • 57
NothingMore
  • 1,101
  • 7
  • 19
  • 3
    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.deshmukhpatil Aug 17 '15 at 08:16
  • @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 Feb 23 '17 at 10:30
  • @Bernard: do you mean it depends upon "compilers std lib shared_ptr" implementation for the platform? – rahul.deshmukhpatil Feb 27 '17 at 07:35
  • 2
    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. – Bernard Feb 27 '17 at 07:54
25

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.

Laura
  • 5,088
  • 3
  • 26
  • 37
Lothar
  • 11,018
  • 5
  • 66
  • 110
  • 7
    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;` – JKovalsky Jun 05 '18 at 10:48
  • 5
    This could be worded better. A `std::shared_ptr` instance is guaranteed thread-safe when always used **by value** (copied/moved) across thread boundaries. All other uses, `std::shared_ptr&` are unsafe across thread boundaries – WhiZTiM Jun 27 '20 at 08:44
  • I don't care how you name it. The main information i give here and that was missing in other answers is that a std::shared_ptr has multiple members. When knowing this everyone who does multithreading programming understand 100%. Using different names makes it IMHO more ambiguous – Lothar Mar 20 '21 at 23:45