十年匠心定制 · 商业建站与技术教学双线并行 咨询热线:400-886-1026 service@lmnt.cn
ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

CANN opbase 中 aclDestroyIntArray 详解:aclIntArray 资源释放接口的原型、源码实现与最佳实践

CANN opbase 中 aclDestroyIntArray 详解:aclIntArray 资源释放接口的原型、源码实现与最佳实践 CANN opbase 中 aclDestroyIntArray 详解aclIntArray 资源释放接口的原型、源码实现与最佳实践【免费下载链接】opbase本项目是CANN算子库的基础框架库为算子提供公共依赖文件和基础调度能力。项目地址: https://gitcode.com/cann/opbase在 CANN 算子库基础框架opbase的 aclnn 单算子执行接口中aclIntArray是承载整型序列如 shape 维度、padding、strides 等的核心参数容器。本篇以 aclDestroyIntArray 官方文档 为主体完整继承其原型、参数与返回值说明并结合 opbase 仓库源码acl_op_api.cpp、acl_meta.h深入剖析该接口的空指针处理、双重释放防护机制与返回码体系帮助读者掌握 aclIntArray 的完整“创建—使用—销毁”生命周期管理写出无内存泄漏、无悬垂指针的算子调用代码。功能定位根据官方文档aclDestroyIntArray的功能是销毁通过 aclCreateIntArray 接口创建的aclIntArray。从源码结构看aclIntArray是一个不透明类型opaque type。acl_meta.h 中仅定义了typedef struct aclIntArray aclIntArray;即调用方只能持有指向它的指针无法也无需访问其内部成员。这与 aclCreateIntArray 文档 的表述一致它是“框架定义的数组结构用于管理和存储整型数据使用时无需了解其内部实现”。正因为内存由框架内部分配创建时把宿主侧int64_t数组拷贝进aclIntArray销毁也必须且只能通过aclDestroyIntArray完成二者构成严格配对的资源生命周期 API。函数原型aclnnStatus aclDestroyIntArray(const aclIntArray *array)接口声明位于公共头文件 acl_meta.hACL_FUNC_VISIBILITY aclnnStatus aclDestroyIntArray(const aclIntArray* array);原型要点入参为const aclIntArray *指针。注意这里传的是“指向常量的指针”表示销毁操作不会修改对象内容而非const aclIntArray **即该接口不会将传入指针置空调用方无需也不能依赖“销毁后指针自动变 nullptr”的行为返回类型为aclnnStatus取值 0ACLNN_SUCCESS表示成功非 0 表示失败具体返回码参见 公共接口返回码。参数说明参数名输入/输出说明array输入需要销毁的aclIntArray。该指针应来自此前aclCreateIntArray的成功返回使用前提约束来自配对接口 aclCreateIntArray 的 Restrictions 章节对销毁侧同样成立本接口必须与aclCreateIntArray成对使用分别负责aclIntArray的创建与销毁若需查询数组长度应使用 aclGetIntArraySize 接口且必须在销毁前调用——销毁后指针即失效任何再访问包括aclGetIntArraySize都属于未定义行为。返回值说明返回 0 表示成功返回其他值表示失败。opbase aclnn 公共接口的完整返回码定义见 common_api_return_codes.md错误码值说明ACLNN_SUCCESS0成功ACLNN_ERR_PARAM_NULLPTR161001参数校验失败参数中包含非法nullptrACLNN_ERR_PARAM_INVALID161002参数校验失败例如输入数据类型不满足推导要求ACLNN_ERR_RUNTIME_ERROR361001调用 NPU Runtime API 时发生异常ACLNN_ERR_INNER_XXX561xxx内部 API 异常常见内部异常场景561101ACLNN_ERR_INNER_CREATE_EXECUTOR创建aclOpExecutor失败561102ACLNN_ERR_INNER_NOT_TRANS_EXECUTOR内部未调用uniqueExecutor的ReleaseTo561103ACLNN_ERR_INNER_NULLPTRaclnn API 中出现空指针错误需要获取可读错误消息时文档建议调用 Runtime APIs 中的aclGetRecentErrMsg获取错误描述再据此排查。约束说明官方文档标注本接口无额外约束None即对调用频率、线程环境等没有额外限制。但从源码实现可以读出两条隐含的使用规则见下节工程上应遵守只销毁由aclCreateIntArray成功返回的指针不要传入野指针同一个aclIntArray只销毁一次。源码实现剖析aclDestroyIntArray的完整实现位于 acl_op_api.cppaclnnStatus aclDestroyIntArray(const aclIntArray* array) { if (array nullptr) { return OK; } if (unlikely(op::internal::IsAclnnDebugEnabled()) op::internal::CheckDoubleFree(const_castaclIntArray*(array))) { OP_LOGW(Possible double-free at addr %p., static_castconst void*(array)); } delete array; return OK; }这段实现比“原型 返回码表格”多透露了三个重要事实1. 空指针是安全的且直接返回成功。array nullptr时函数直接return OK。也就是说aclDestroyIntArray(nullptr)返回 0不会触发ACLNN_ERR_PARAM_NULLPTR。这一行为与销毁族其他接口aclDestroyFloatArray、aclDestroyBoolArray 等完全一致使得“先判空再销毁”可以简化为“无条件调用销毁”是典型的幂等式资源释放设计。2. 双重释放检测受调试开关控制。当op::internal::IsAclnnDebugEnabled()为真时该开关由 op_dfx.cpp 中的原子标志g_aclnnDebugEnabled承载可从源码结构看由调试配置打开接口会调用 CheckDoubleFree声明于 bridge_pool.h检查该地址是否仍处于活跃内存块状态。若检测到“已被释放过一次”的地址再次被销毁仅打印Possible double-free at addr %p.警告日志并不阻断后续delete——这是一个诊断性检查而非运行时防护。因此生产代码中仍必须自行保证“只销毁一次”该机制只是在调试期帮你定位问题。3. 当前实现恒返回 0。从源码路径看aclDestroyIntArray无论入参是否为空最终都执行return OK不会返回 161001/161002 等错误码。文档中“返回其他值表示失败”是 aclnn 公共接口返回码的通用契约描述对当前版本的该接口而言只要调用不崩溃返回值恒为 0。工程上仍建议按契约检查返回值以便兼容后续实现变化。调用示例官方文档的示例指引参见 aclCreateIntArray 的调用示例。将其完整继承并补充注释如下展示aclIntArray从创建到销毁的完整生命周期示例仅供参考非直接可运行代码aclxxXxx为具体算子的 aclnn 接口占位// 1. 准备宿主侧整型数据例如 shape 维度 {1, 1, 2, 3} std::vectorint64_t sizeData {1, 1, 2, 3}; // 2. 创建 aclIntArrayvalue 为宿主侧 int64_t 指针内容会被拷贝进 aclIntArray // 因此创建成功后 sizeData 可独立于 aclIntArray 释放 aclIntArray *size aclCreateIntArray(sizeData.data(), sizeData.size()); // 3. 作为单算子 API 的输入参数使用以获取 workspace size 并执行算子为例 auto ret aclxxXxxGetWorkspaceSize(srcTensor, size, ..., outTensor, ..., workspaceSize, executor); ret aclxxXxx(...); // ... // 4. 销毁 aclIntArray与创建配对调用销毁后 size 指针立即失效 ret aclDestroyIntArray(size);要点提示aclCreateIntArray返回nullptr时例如创建过程异常参见 acl_op_api.cpp 中失败分支打印aclCreateIntArray error.日志后返回nullptr后续直接使用会崩溃应先判空而aclDestroyIntArray(nullptr)本身安全可放心兜底调用销毁时机应在最后一次使用该数组之后典型位置是算子执行完成、workspace 释放附近若同时创建了aclTensor、aclScalar、aclFloatArray等多种参数容器销毁顺序无强制要求但建议按“谁创建后使用、谁先释放”的原则统一收口避免遗漏。相关接口与测试佐证同族销毁接口行为一致可对照阅读aclDestroyFloatArray、aclDestroyBoolArray、aclDestroyTensor、aclDestroyScalar实现均在 acl_op_api.cpp 中数组尺寸查询aclGetIntArraySize接口总览与分类aclnn API 列表、common_api_list.md单元测试中大量用例会创建并销毁aclIntArray等参数容器例如 test_acl_op_api.cpp、test_tilingctx_builder.cpp 与集成测试 st/composite_op/test_acl_op_api.cpp可作为“创建—使用—销毁”闭环的参考实现中文文档版本见 aclDestroyIntArray.md。小结aclDestroyIntArray是 aclnn 单算子执行链路上aclIntArray资源的生命周期终点原型为aclnnStatus aclDestroyIntArray(const aclIntArray *array)参数仅一个待销毁的aclIntArray指针返回 0 表示成功无额外调用约束。结合 acl_op_api.cpp 源码可以确认空指针入参安全且返回成功、销毁时恒返回OK、调试模式下具备双重释放告警能力。将其与 aclCreateIntArray 严格配对使用、并在销毁前完成最后一次数据访问如aclGetIntArraySize即可在保证内存安全的前提下完成整型参数容器的完整管理。【免费下载链接】opbase本项目是CANN算子库的基础框架库为算子提供公共依赖文件和基础调度能力。项目地址: https://gitcode.com/cann/opbase创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表