I was thinking, if the main thread is deleting a shared_ptr, and cause reference count drop to 0, and in the process of deleting the referenced pointer heap memory, and at the same time, another thread is copying a shared_ptr reference (inside the copy constructor already). What would happen then?
Asked
Active
Viewed 83 times
-1
-
hey thanks for the -1 and not leaving any comment – Bryan Fok Apr 02 '18 at 06:16
-
3I didn't downvote the question, but if I had to guess, it was probably done because your question is a single run on sentence which is barely readable and doesn't provide any example of the problem you are trying to solve. – Claies Apr 02 '18 at 06:19
-
1Possible duplicate of - https://stackoverflow.com/questions/9127816/stdshared-ptr-thread-safety-explained ? – badola Apr 02 '18 at 06:26
2 Answers
0
The situation you describe isn't allowed to happen in standard compliant code. In case it does appear in code, you have undefined behavior.
The std::shared_ptr
class isn't thread safe. You aren't allowed to access the same instance from 2 threads without synchronization, as that is a race condition.
So, when the counter is read, if it isn't zero, it is incremented and some pointers are copied over.

Remy Lebeau
- 555,201
- 31
- 458
- 770

JVApen
- 11,008
- 5
- 31
- 67
-
What do you mean by shared_ptr class is not thread safe? i believe they do have atomic or lock inside the implementation right? – Bryan Fok Apr 02 '18 at 06:29
-
You can use multiple instances in multiple threads, you can't use the same instance in multiple threads – JVApen Apr 02 '18 at 06:30
-
-
-
-
-
I am wondering what my example would happen if we really doing referencing of shared_ptr – Bryan Fok Apr 02 '18 at 06:34
-
-
std::shared_ptr
a = std::make_shared – Bryan Fok Apr 02 '18 at 06:39(10); std::thread([&](){ std::shared_ptr b(a); }); -
-
1
-
I dont think you get the point here that you CAN reference the shared_ptr, and from my answer, it would cause the problem potentially (as the answer explained). – Bryan Fok Apr 02 '18 at 06:51
-
1@Bryan Fok Just because something *compiles* does *not* mean that the code is valid. Syntactically valid, yes. But not necessarily free of Undefined Behaviour, implementation defined behaviour, use of languagee extensions, non-portable constructs, logic errors, race conditions, etc etc. – Jesper Juhl Apr 02 '18 at 07:21
-
His original answer was simpler, the code was just showing it is valid syntax Jesper, and it is not the question I was asking anyway – Bryan Fok Apr 02 '18 at 10:23
0
I think this blog did answer my question? I am not sure. So if the shared_ptr is copy to the thread, there are no chance that the problem I mention would happen.
shared_ptr must have at least 2 pointers, so it’s bigger than a raw pointer. It also guarantees thread-safety for all methods as long as each thread has its own copy.

Bryan Fok
- 3,277
- 2
- 31
- 59
-
I think it is very interesting, and it changed the way I always thought about shared_ptr until I try to implement a simple version of it for fun. I think the blog, and the response from Lothar at the below link did answer this question https://stackoverflow.com/questions/9127816/stdshared-ptr-thread-safety-explained – Bryan Fok Apr 02 '18 at 06:48