为何无法从checkpointed状态解锁CUDA进程？

NVIDIA近期在CUDA驱动中引入了进程级GPU状态检查点机制，该机制的基本流程为：先锁定（lock）进程，使其不再接受CUDA API调用；接着对进程执行检查点（checkpoint）操作；最后解锁（unlock）进程以恢复CUDA使用。但解锁函数cuCheckpointProcessUnlock()的文档显示，它仅能用于处于locked状态的进程，无法用于执行检查点操作后进入的checkpointed状态，这一限制的核心原因如下：

• 状态语义的本质差异：
  locked状态是检查点流程的"准备阶段"——此时GPU上下文仍处于活跃但冻结的状态，只是暂停接收新的CUDA调用，进程与GPU资源的关联关系完整。而checkpointed状态是检查点完成后的"快照阶段"，进程的GPU状态已被导出为静态快照，原有的GPU上下文关联已被切断，进程不再持有活跃的GPU资源句柄。cuCheckpointProcessUnlock()的作用是恢复locked状态下被冻结的CUDA调用通路，它依赖活跃GPU上下文的存在，因此无法作用于已失去上下文关联的checkpointed状态。

• 资源一致性的强制保障：
  若允许在checkpointed状态下调用解锁函数，进程会尝试重新关联已被快照导出的GPU资源，这会直接破坏快照的完整性——快照记录的是某个时间点的静态状态，解锁后进程对GPU状态的修改会导致快照与实际状态不一致，后续基于该快照恢复进程时必然出现资源冲突或状态错乱。这种限制是为了强制开发者遵循"锁定→检查点→（恢复/销毁）"的正确流程，避免非法操作损害检查点的可靠性。

• API职责的单一性设计：
  cuCheckpointProcessUnlock()的职责仅对应"取消锁定"这一特定操作，而checkpointed状态的后续操作（基于快照恢复进程、清理快照资源）有专门的API负责，解锁函数不承担跨状态的处理逻辑，保持了API设计的单一性和清晰性，降低了误用风险。

内容的提问来源于stack exchange，提问作者einpoklum