When a thread is executing make_shared, can another thread do something to cause a leak of the object that make_shared creates via new?

Question

From Effective Modern C++, Item 21, I learned that one advantage of std::make_shared over new+std::shared_ptr is that code like this

processWidget(std::shared_ptr<Widget>(new Widget), computePriority());

can result in a leaked Widget if computePriority() throws in between new Widget evaluation and the call to std::shared_ptr constructor, wheras in this alternative code that is not possible:

processWidget(std::make_shared<Widget>(), computePriority());

But std::make_shared is itself implemented in terms of new and std::shared_ptr.

So a friend asked me, can anything else, in multithreaded fallacious code, happen in the middle of std::make_shared's execution causing the same effect?

I know little or zero of multithreading, so my question may actually be dumb or nonsense, even though I don't know why.

My intuition tells me that if one thread t1 is executing the second snippet of code, there's no way for another thread t2 to get there, in the middle of the code that t1 is executing. And if more threads are executing the second snippet of code, well every one of them will be working on its own anyway. But again, I'm not sure I'm saying anything sensible.

Answer 1

So a friend asked me, can anything else, in multithreaded fallacious code, happen in the middle of std::make_shared's execution causing the same effect?

Other things can certainly happen in between std::make_shared allocating memory and creating the std::shared_ptr<Widget>. However, none of those things can cause the pointer to leak, unless something has gone seriously wrong (i.e. the program has UB).

Any exception that occurs in another thread will only interfere with the control flow in that thread and, at worst, bring down the entire process (at which point the operating system will reclaim the memory). In order to make the pointer leak, the other thread would have to corrupt the stack in the thread that is running std::make_shared, which is not possible unless it does something that produces UB.

Answer 2

... can result in a leaked Widget if computePriority() throws in between new Widget evaluation and the call to std::shared_ptr constructor ...

That used to be a real concern in older C++ standards, however that is no longer possible since C++17, as new guarantees were introduced that will make std::shared_ptr<Widget>(new Widget) be fully executed either before or after computePriority() is ever called. They can't be interweaved anymore (see this answer to What are the evaluation order guarantees introduced by C++17?).

"Effective Modern C++" predates C++17, however it is still good advice to always use std::make_shared<T>(...) rather than std::shared_ptr<T>(new T(...)) whenever possible. For instance, std::make_shared() uses a more efficient allocation strategy then the std::shared_ptr constructor does. std::make_shared() allocates the managed object and the control block as a single memory allocation, whereas calling the constructor directly will allocate the managed object and the control block separately.

if one thread t1 is executing the second snippet of code, there's no way for another thread t2 to get there, in the middle of the code that t1 is executing.

That is not true, due to modern OS systems using pre-emptive task-switching between threads. Say, t1 is executing a piece of code on a CPU, using a given piece of memory. The OS's thread scheduler will actively interrupt t1 midway through its work at certain intervals, switching execution to t2 (or any other thread) on the same CPU. t2 (or whichever thread) could then freely modify that same piece of memory that t1 was using (ie, like assigning to a global variable that t1 reads from, etc). The OS scheduler will eventually switch back to executing t1 on the CPU, which would then continue on its work, using the now-modified memory.

This is a completely different scenario than the compiler simply evaluating function arguments in an interweaving order on a single thread.