问题标签 [resource-management]

我实现了一个简单的 ResourceManager - 一切都很好，直到我尝试实现它的析构函数以进行（紧急）清理（例如在致命异常的情况下）。我无法找到一种方法来做到这一点：

显然，我必须遍历所有活动资源......但是如果 ResourceManager 在技术上不是资源的（唯一）所有者，我该如何释放它们？这可能是设计缺陷，如果是这种情况，请提出替代方案。

编辑：为了响应答案，定义“资源管理器”我想象权威缓存 - 存储对资源的引用，可以查找资源（=无重复）并管理它们在内存中的状态（内存中，仅描述（=路径+type) 和 freed)，所有这些都尽可能自动化。（应该有单独的 ResourceLoaders，但这对于这个问题并没有太大变化）

我正在尝试编写一些代码来从名为“TextureList.txt”的配置文件中读取文件名列表，然后使用这些文件为每个纹理创建着色器资源视图。下面的清单显示了我目前拥有的内容：

while 循环底部的调试表明文件被正确读取，它获取所有文件名并计算正确的纹理数量；但是，当它尝试创建第一个资源视图时会失败。

谁能告诉我哪里出错了？

我不知道它是否有帮助，但如果我使用以下行将 for 循环上方的所有内容替换为硬编码文件名，它就会起作用：

常量 LPCSTR 纹理[3] = {"tex1.dds", "tex2.dds", "tex3.dds"};

我的目标：为用户提供一种方法来限制给定进程 (C++) 的 CPU、内存等资源。

所以有人建议我使用看起来像一个理想实用程序的 Cgroups。

在做了一些研究后，我有一个担忧：

当我们利用 memory.limit_in_bytes 来限制给定进程的内存使用时，有没有办法处理进程中的内存不足异常？我看到控制组提供了一个名为“memory.oom_control”的参数，当启用该参数时，它会杀死请求比允许更多内存的进程。禁用时，它只会暂停该过程。

我想要一种方法让进程知道它请求的内存比预期的多，并且应该抛出内存异常。这是为了让进程优雅地退出。

cgroups 是否提供这种行为？

cgroup 也适用于所有版本的 linux 吗？我主要对 RHEL 5+、CENTOS 6+ 和 ubuntu 12+ 机器感兴趣。

任何帮助表示赞赏。

谢谢

如果我将DataContexta设置为Window实现的东西，关闭时IDisposable会是Dispose()d吗？Window

我有我的自定义课程，例如：

和另一个带有我的自定义类列表的类：

列表析构函数应该如何释放内存中所有使用的向量空间：

该代码是正确的、多余的还是错误的？

感谢您的帮助...

我正在开发一个项目，其中地图的各个区域要么是动态生成的，要么是从文件中加载的（如果它已经生成并保存了）。区域仅根据需要加载/生成，并在不再需要时保存和丢弃。有几个不同的任务将使用此地图的一个或多个区域用于各种目的。例如，其中一项任务是绘制所有当前可见的区域（在任何给定时间大约 9 个）。另一个是获取有关区域的信息，甚至修改区域。问题是这些任务可能与其他任务在相同的区域工作，也可能不同。

由于这些区域相当大，并且生成成本很高，因此（出于这些和其他原因）为每个任务使用不同的副本是有问题的。相反，我认为创建和管理当前加载的区域池是个好主意。新任务将首先检查池中的所需区域。然后，如果它存在，他们可以使用它，或者创建一个新的并将其添加到池中。

如果可行，我将如何管理这个池？我如何确定某个区域是否不再需要任何任务并且可以安全地丢弃？我是不是很傻并且过于复杂了？

如果这对任何人都很重要，我正在使用 c#。

编辑：现在我更清醒了，是否就像在每个区域中为每个使用它的地方增加一个计数器一样简单？然后在计数器达到 0 时丢弃它？

我通过将 cpuset 指定为 1 个内核来启动一个 docker 容器：

第二个通过将 cpuset 指定为 4 个核心：

我在每个容器中启动了一个加载过程，并监控了两个容器的 CPU 消耗。

加载过程如下：

我观察到两个容器之间的执行时间没有改善（没有加速）。

你知道为什么没有改进吗？具有 4 个核心的容器应该比 1 个核心容器运行得更快，对吗？

注意：将顶部用于 1core 容器

使用 top 作为 4core 容器，docker 随机选择 4 个核心之一来启动进程。有时它会影响每个核心的 30%

我在我的代码中使用 executor 服务，使用的线程数超过 100 。执行完成后，在执行器服务上调用 shutdown() 方法，然后调用 awaitTermination()。

使用来自 linux 终端的 shell 脚本调用 java 类。我想知道在执行程序服务已启动但未完全关闭的状态下按 ctrl+C 停止执行时会发生什么。

它是否会导致线程被杀死，它们的内存被清理并被释放资源，或者它会导致内存泄漏。

我有这样的代码（简化）：

如何保证 mustBeClosed 被释放？

当对象层次结构复杂时，可能会发生这种情况。覆盖 B 的 finalize 可能不是一个完美的解决方案。

针对这个问题的任何最佳实践或原则？

修改后的版本如下：

然而，这需要太多的代码并且远非优雅。更重要的是，所有权层次结构中的所有类似乎都应该遵循相同的样式，这会导致大量代码。

有什么建议吗？

我在使用 GCC 4.8.4 的 Ubuntu 14.04 上，我的代码类似于以下内容：

WhereMyFunction的签名如下所示：

完整的代码可以在这里找到

但是，我发现 my_object 实际上超出了MyFunction. 我的想法是，my_shared_object只有在超出范围后才会释放其内容，这意味着在MyFunction返回之后。我不确定我是不是误解std::shared_ptr了，或者这可能是一个 GCC 错误。

我想问题归结为：当我取消引用 std::shared_ptr 时，这是否保证std::shared_ptr只要使用取消引用，它就会持续存在？