如何判断 cudaFree() 是否安全/必要？答案

【问题标题】：How can I tell whether it's safe/necessary to cudaFree() or not?如何判断 cudaFree() 是否安全/必要？
【发布时间】：2015-12-08 13:47:10
【问题描述】：

我已经用cudaMalloc() 分配了一些GPU 全局内存，比如说，在某个类的构造函数中。现在是时候破坏我构建的实例了，我有了实例的数据指针。问题是，我担心其他地方的一些恶作剧代码可能调用了cudaDeviceReset()，之后我的cudaFree() 可能会失败（我会收到invalid device pointer 错误）。那么，如何判断我的指针是否符合cudaFree()ing 的条件？

【问题讨论】：

标签： memory-management cuda free

【解决方案1】：

我认为您对此无能为力。

您能做的最好的事情是尝试设计对象的生命周期，这些对象将在其析构函数中调用 CUDA API，以便在上下文销毁之前这样做。在实践中，这意味着在上下文被自动或手动拆除之前，让它们以明确定义的方式落入范围。

对于像cudaFree() 这样的调用，无论如何有点“一劳永逸”，最好的办法可能是为调用编写自己的包装器，并显式捕获并优雅地忽略任何明显的错误情况调用是在上下文破坏后进行的-

【讨论】：

“无效指针”错误的其他潜在原因是什么？在那里？如果没有，我确实可以放心地忽略失败。

【解决方案2】：

鉴于says 的特点，人们可能会考虑做相反的事情：

将您的 cudaDeviceReset() 调用包装起来，也将其视为“生成计数器”。
计数器增加将受到锁的保护。
当您锁定时，您重置并递增生成计数器。
包装 cudaMalloc() 以同时保留生成索引（您可能需要一个类/结构） - 在分配期间获得（也锁定）。
包裹 cudaFree() 以锁定，并且只有在重置代没有改变时才真正包裹 cudaFree()。

...现在，您可能会说“所有这些锁定都值得吗？最坏的情况是，您会得到一个错误，这没什么大不了的。”而且，老实说 - 我不确定这是否值得。您可以通过使用Reader-Writer lock 而不是简单的锁来减轻这种痛苦，其中 allocate 和 free 只是可以同时访问的读取器。

【讨论】：