Herb Sutter はブログで次のように書いています。
[...]スマート ポインター参照カウント のインクリメントは、通常、最適化された実装での通常のインクリメントと同じになるように最適化できる
shared_ptrためです。ただし、デクリメントはアトミック デクリメントまたは同等のものである必要があります。これは、それ自体がより高価な特別なプロセッサ メモリ命令を生成し、その上、周囲のコードの最適化にメモリ フェンスの制限を引き起こします。
テキストはの実装に関するものでshared_ptrあり、彼の発言がこれにのみ当てはまるのか、それとも一般的に当てはまるのかはわかりません。彼の定式化から私が収集したのは、一般的に.
if(counter==0)しかし、考えてみると、 が直後に続く場合の「より高価な減少」しか思い浮かびません。これはおそらく の場合shared_ptrです。
したがって、アトミック操作++counterは (通常)よりも常に高速なのか--counter、それとも単に?if(--counter==0)...shared_ptr
彼はこれについてどこかでより詳細に議論しています。基本的には、アトミック インクリメントとデクリメントの固有のプロパティではなく、shared_ptr ユース ケースでメモリ フェンスが必要な場所がすべてです。
その理由は、見逃さない限り、参照カウントスマートポインターを使用したインクリメントの正確な順序についてはあまり気にしないためですが、デクリメントでは、最終的なデクリメントでメモリバリアを配置することが重要ですこれにより、別のスレッドからスマート ポインターが所有するオブジェクトへの以前のメモリ アクセスが、メモリが解放された後に並べ替えられる可能性がない削除がトリガーされます。
インクリメントを「非表示」にすることができ、「デクリメントとチェック」を1つの操作として実行する必要があるという事実を指していると思います。
--counter(or counter--、int、char などの単純なデータ型について話していると仮定すると) が++counterorよりも遅いアーキテクチャを認識していませんcounter++。
Sutter が話している問題は、参照カウントのインクリメントが正しいことを確認するためのフォローアップ アクションを必要としないという事実です。ゼロ以外の参照カウントを別のゼロ以外のカウントに取得しているため、これ以上のアクションは必要ありません。ただし、デクリメントには、正確性を確保するためのフォローアップ アクションが必要です。デクリメントは、ゼロ以外の参照カウントを非ゼロまたはゼロの参照カウントに取ります。参照カウントのデクリメントがゼロになった場合は、アクションを実行する必要があります。具体的には、参照されたオブジェクトの割り当てを解除します。このデクリメント アンド アクト ダイナミクスには、フェンス レベル (CPU のメモリ/キャッシュ管理ロジックが並べ替えた別のコア上の他の読み取り/書き込みで割り当て解除が並べ替えられないようにするため) と、コンパイラ レベル (したがって、コンパイラは'
したがって、Sutter が説明したシナリオでは、インクリメントとデクリメントのコストの違いは、基本的な操作自体にあるのではなく、デクリメントの実際の使用 (具体的には、デクリメント自体に作用する) に課される一貫性の制約にあります。増分に適用されます。