当‘`cudaEventDestroy`’从异步启动返回错误代码时，如何正确响应？

Question

我假设我们希望像在这个答案中描述的那样进行错误处理，在这里我们测试返回代码，如果不成功的话抛出一个异常。

现在，假设cudaEventDestroy从上一次异步启动中返回一个错误，文档可能会这样做。

在这种情况下，事件是否已被成功摧毁？更普遍地说，如果运行时函数从以前的异步启动中返回错误，那么它们是否能够成功地完成它们的功能呢？

如果这发生在代码中实际处理错误(例如析构函数)不方便的地方，我能做什么？

看起来，如果我不希望我的程序随机终止或丢失错误，我就必须实现一个重复的错误记录系统，在这个系统中，我可以记录在不能真正处理错误的地方发生的错误，并更改运行时API调用的样板，以检查返回状态和重复错误记录系统。这看起来相当尴尬和不太理想，我希望我错过了一些简单的东西。

Answer 1

更普遍地说，如果运行时函数从以前的异步启动中返回错误，那么它们是否能够成功地完成它们的功能呢？

一般情况下，不。以前异步启动导致的许多类型的错误都是使CUDA上下文失效的类型。一旦数据自动化系统的内容失效，就不可能再使用任何形式的操作，除非销毁它。有鉴于此，您关于假设的cudaEvent的状态的问题是没有意义的。

如果这发生在代码中实际处理错误(例如析构函数)不方便的地方，我能做什么？

许多类型的CUDA错误是持久的，特别是那些反映失效的CUDA context1的错误。这些类型的错误无法清除，并将在任何后续的错误检查活动中重新出现.您可能有一个适当的错误控制水平与全面的错误检查，除非在那些地方是不方便这样做。如果您对析构函数活动中的错误检查的关注是专门在应用程序拆卸期间进行的，那么这是否是一个问题还不清楚。

1:对于示例：

cudaErrorIllegalAddress= 77设备在无效的内存地址上遇到了加载或存储指令。无法使用上下文，因此必须销毁上下文(并创建一个新的)。来自此上下文的所有现有设备内存分配都是无效的，如果程序要继续使用CUDA，则必须进行重构。

补充说明：

要以异步启动示例返回的错误为例，应该立即报告不使cuda上下文失效的错误(例如无效的启动配置)，并在内核启动时被正确的CUDA错误检查所捕获，而且我不希望这些错误的类型仅在稍后才会出现，可能是在析构函数操作期间。大多数在内核执行开始后的一段时间后发生的错误都是导致CUDA上下文失效的类型，并且是持久化的，无法清除。