簡単な紹介：私はマルチスレッドコードに取り組んでおり、動的に割り当てられたオブジェクトを2つのスレッド間で共有する必要があります。コードをよりクリーンにする（そしてエラーが発生しにくい）ために、各スレッドのオブジェクトを明示的に「削除」したいので、を使用したいと思いますshared_ptr。
最初の質問：
-> operatorinの実装に、実行時にshared_ptr余分なオーバーヘッド（たとえば、より大きい）があるかどうかを知りたいです。unique_ptr私が話しているオブジェクトは通常、作成後に一度だけコピーされた長寿命のインスタンスであり（スレッド間でそれらを分散する場合）、これらのオブジェクトのメソッドとフィールドにのみアクセスします。
私は、shared_ptr参照カウントのみを保護することを認識しています。
2番目の質問：
shared_ptrlibstdc ++でどの程度最適化されていますか？常にミューテックスを使用しますか、それともアトミック操作を利用しますか（私はx86およびARMプラットフォームに焦点を合わせています）？
最初の質問：使用
operator->
私が見たすべての実装はT*、クラス内に右のローカルキャッシュを持ってshared_ptr<T>いるため、フィールドはスタック上にoperator->あり、したがって、ローカルスタックを使用するのと同等のコストがかかりますT*。オーバーヘッドはまったくありません。
2番目の質問：ミューテックス/アトミック
libstdc ++は、標準機能または特定のg ++組み込み関数（古いバージョン）を介して、x86プラットフォームでアトミックを使用することを期待しています。Boostの実装はすでにそうしていると思います。
ただし、ARMについてはコメントできません。
注：C ++ 11は移動セマンティクスを導入しているため、の使用では当然多くのコピーが回避されますshared_ptr。
注：shared_ptr ここshared_ptrでの正しい使用法について読んでください。一般的にコピー/破壊のほとんどを回避するために（またはそうでない）への参照を使用できるconstため、それらのパフォーマンスはそれほど重要ではありません。
GCCのshared_ptrは、シングルスレッドコードでロックやアトミックを使用しません。マルチスレッドコードでは、アトミックコンペアアンドスワップ命令がCPUでサポートされている場合はアトミック操作を使用します。サポートされていない場合、参照カウントはミューテックスによって保護されます。i486以降では、アトミックを使用しますが、i386はcmpxchgをサポートしていないため、ミューテックスベースの実装を使用します。ARMはARMv7アーキテクチャ以降にアトミックを使用していると思います。
std::shared_ptr（同じことがとの両方に当てはまりますstd::tr1::shared_ptr。）