Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Overhead and implementation of using shared_ptr

Short introduction: I am working on multithread code and I have to share dynamically allocated objects between two threads. To make my code cleaner (and less error-prone) I want to explicitly "delete" objects in each thread and that's why I want to use shared_ptr.

First question:

I want to know if implementation of -> operator in shared_ptr has some extra overhead (e.g. larger then unique_ptr) during run time. Objects I am talking about are usually longlife instances copied only once after creation (when i distribute them between threads), then I only access these objects' methods and fields.

I am aware, that shared_ptr only protect reference counting.

Second question:

How well are shared_ptr optimized in libstdc++? Does it always use mutex or take advantage of atomic operations (I focus on x86 and ARM platforms)?

like image 489
Goofy Avatar asked Jun 05 '12 17:06

Goofy


People also ask

What is the use of shared_ptr?

shared_ptr is also helpful in C++ Standard Library containers when you're using algorithms that copy elements. You can wrap elements in a shared_ptr , and then copy it into other containers with the understanding that the underlying memory is valid as long as you need it, and no longer.

Why would you choose shared_ptr instead of unique_ptr?

In short: Use unique_ptr when you want a single pointer to an object that will be reclaimed when that single pointer is destroyed. Use shared_ptr when you want multiple pointers to the same resource.

Should I use shared_ptr or unique_ptr?

Use unique_ptr when you want to have single ownership(Exclusive) of the resource. Only one unique_ptr can point to one resource. Since there can be one unique_ptr for single resource its not possible to copy one unique_ptr to another. A shared_ptr is a container for raw pointers.

Does unique pointer have overhead?

std::unique_ptr has no memory or performance overhead compared to the explicit usage of new and delete. That is very great because std::unique_ptr offers a great benefit by automatically managing the lifetime of its resource without any additional cost. My conclusion to std::shared_ptr is not so easy.


1 Answers

First question: using operator->

All the implementations I have seen have a local cache of T* right in the shared_ptr<T> class so that the field is on the stack, operator-> has thus a comparable cost to using a stack local T*: no overhead at all.

Second question: mutex/atomics

I expect libstdc++ to use atomics on x86 platform, whether through standard facilities or specific g++ intrinsics (in the older versions). I believe the Boost implementation already did so.

I cannot, however, comment on ARM.

Note: C++11 introducing move semantics, many copies are naturally avoided in the usage of shared_ptr.

Note: read about correct usage of shared_ptr here, you can use references to shared_ptr (const or not) to avoid most of the copies/destruction in general, so the performance of those is not too important.

like image 74
Matthieu M. Avatar answered Sep 20 '22 17:09

Matthieu M.