-20

在回答另一个问题时，我突然想到我可能会优化我自己的一些旧代码，这些代码有错误......“不是最佳”生命周期管理。

我至少有一个应用程序，其中对象的访问/生命周期由 shared_ptr 控制。这个ptr是动态分配的，因此它可以“原子地”换出另一个*shared_ptr，（因此是一个由新ptr管理的更新对象），没有任何锁定。这似乎工作正常，但我故意泄漏旧的 ptr，因为我不知道最后一个线程何时完成。

现在我突然想到，我可以（也许）删除（）正在管理的旧对象的 dtor 中的旧 *shared_ptr。我会在创建时将 *sharedPtr 加载到托管对象的私有数据成员中，以便 dtor 可以将其删除。

有没有人这样做过，或者对为什么它可能不安全有任何看法？我可以尝试一下，但我担心，就像许多多线程“优化”一样，它可能只是“看起来有效”，直到我交付它之后:(

4

2 回答 2

8

听起来您的代码中有一个糟糕的设计问题比其他任何事情都多。首先，你为什么要创建一个shared_ptr*？这似乎已经错了。

然后因为不知道其他线程什么时候用完就泄露了？什么？？那很糟。

为什么不只拥有两个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's 的源代码以允许 #1。

我的意思是，这里真正的问题是，你到底为什么要进行全局配置？这对我来说似乎是真正的问题。

于 2012-09-20T11:50:04.747 回答