何时不使用 RAII 进行资源管理

Question

谁能给我提供一个或多个具体示例，说明 RAII 不是最有效的资源管理方法，为什么？

Answer 1

我能想到的唯一 RAII 不是解决方案的情况是多线程关键区域锁定管理。一般来说，建议获取关键区域锁（考虑资源）并将其保存在 RAII 对象中：

void push( Element e ) {
   lock l(queue_mutex);  // acquire on constructing, release on destructing
   queue.push(e);
}

但在某些情况下，您不能将 RAII 用于此目的。特别是，如果循环条件中使用的变量由多个线程共享，并且您无法在整个循环执行中持有锁，则必须使用不同的机制获取和释放锁：

void stop_thread() {
   lock l(control_mutex);
   exit = true;
}
void run() {
   control_mutex.acquire();
   while ( !exit ) { // exit is a boolean modified somewhere else
      control_mutex.release();
      // do work
      control_mutex.acquire();
   }
   control_mutex.release();
}

甚至可以使用 RAII通过 (ab)using operator， 现在我想到了，但我从未真正想到过。但我想这并不是很自然：

void run() {
   while ( lock(control_mutex), !exit ) {
      // do work
   }
}

所以我想答案不是我能想象的...

编辑：使用 RAII 针对同一问题的其他解决方案：

@马克·兰塞姆：

bool should_exit() const {
   lock l(mutex);
   return exit;
}
void run() {
   while ( !should_exit() ) {
      // do work
   }
}

@fnieto：

void run() {
   while (true) {
      {  lock l(mutex);
         if (exit) break;
      }
      // do work
   }
}

Answer 2

有时需要两阶段初始化（创建，然后初始化，然后使用）。

甚至是三阶段：在我们的产品中，有一组独立的对象，每个对象运行一个线程，并且能够通过优先级继承队列订阅任意数量的其他对象（包括其本身）。对象及其订阅在启动时从配置文件中读取。在构造时，每个对象 RAII 拥有其所能提供的一切（文件、套接字等），但没有对象可以订阅其他对象，因为它们是以未知的顺序构造的。因此，在构造所有对象之后，将在第二阶段建立所有连接，在第三阶段建立所有连接后，线程将被释放并开始消息传递。同样，关闭也是多阶段的。

Answer 3

GC 可以为程序员处理循环数据结构的内存，而 RAII 则需要程序员在某处手动中断循环。

Answer 4

RAII 意味着资源的所有权是通过语言构造（尤其是但不限于构造函数和析构函数）提供的保证来定义和管理的。

C++ 中 RAII 的要点是资源所有权策略实际上可以由语言强制执行。 RAII 的一个较小的替代方案是 API 建议调用者（例如，通过注释或其他文档）显式执行 ACQUIRE() 和 RELEASE()< /code> 在特定时间进行操作。这种政策不能由语言强制执行。

因此，最初的问题是另一种方式来询问是否存在不可执行的资源管理方法比 RAII 更可取的情况。 我能想到的唯一情况是您故意规避语言中现有的资源管理结构，并编写自己的框架。例如，您正在实现一个垃圾收集脚本语言解释器。原子的“虚拟分配”可能会与内存块玩游戏。类似地，基于池的分配器期望程序最终调用 DESTROY_POOL() 操作，并产生全局后果（即，从该池分配的任何项目都将失效）。

Answer 5

在资源释放可能失败的情况下，RAII 可能不足以管理该资源（因为析构函数不应抛出）。不过，RAII 可能仍然是该解决方案的一部分。