-20

別の質問に答えると、「最適ではない」ライフタイム管理でエラーが発生した自分の古いコードの一部を最適化する可能性があることに気づきました。

オブジェクトへのアクセス/有効期間が shared_ptr で制御されるアプリが少なくとも 1 つあります。この ptr は動的に割り当てられるため、ロックすることなく、別の *shared_ptr (したがって、新しい ptr によって管理される更新されたオブジェクト) に「原子的に」スワップ アウトできます。これは問題なく動作しているように見えますが、最後のスレッドがいつ終了するかわからないため、意図的に古い ptr をリークしています。

管理されている古いオブジェクトの dtor にある古い *shared_ptr を (おそらく) delete() できることに気付きました。作成時に *sharedPtr をマネージド オブジェクトのプライベート データ メンバーにロードして、dtor がそれを削除できるようにします。

誰かがこれを行ったことがありますか、またはなぜそれが安全ではないのかについて意見がありますか? 私はそれを試すことができましたが、非常に多くのマルチスレッドの「最適化」のように、私がそれを提供した後まで「機能しているように見える」のではないかと心配しています:(

4

2 に答える 2

8

何よりもコードに悪い設計上の問題があるようです。まず、なぜ を作成したいのshared_ptr*ですか? それはすでに間違っているようです。

他のスレッドがいつ終了するかわからないので、それをリークしますか? 何？？良くないね。

2つだけ持ってshared_ptr、それらを適切に使用してみませんか？多分それはあなたの人生をずっと楽にするでしょう。

shared_ptr*また、いいえ、所有するオブジェクトのデストラクタでそれ自体を削除することはできません。それはおそらく壊れないサイクルに入るでしょう。shared_ptr はそれが所有するオブジェクトを削除しようとしているからです。次に、所有者を削除しようとします。その結果、所有者が削除されます....おわかりでしょう...それはばかげています。

于 2012-09-20T11:44:26.080 に答える
3

これは悪いです。を変更するときにロックを解除するshared_ptrか、DCASを使用してアトミックにを交換することをお勧めしますshared_ptr。それを実装するのは...楽しいですが、可能です。

あなたの根本的な問題は

  1. アトミックポインタスワッピングが必要です
  2. 参照カウントが必要です
  3. shared_ptr＃1を提供しません。

したがって、それを吸い上げてロックを解除するか、たとえば、boost::shared_ptr＃1を許可するようにのソースコードを変更する必要があります。

つまり、ここでの本当の問題は、なぜグローバル構成を作成したのかということです。それは私には本当の問題のように思えます。

于 2012-09-20T11:50:04.747 に答える