mold 项目内嵌 TBB Flow Graph 的 sender 模板类消息发送方接口与弃用迁移指南【免费下载链接】moldmold: A Modern Linker 项目地址: https://gitcode.com/GitHub_Trending/mo/mold导读senderT是 oneTBB Flow Graph 中定义消息发送方行为的抽象基类也是理解整个 flow graph 数据流方向的起点。本文以 mold 仓库中随附的 oneTBB 官方规范文档 sender_cls.rst 为主体完整梳理该模板类的语法、头文件、成员语义与设计要点并结合仓库内 flow_graph.h 的实际实现说明其底层行为同时给出register_successor已弃用、应改用make_edge/remove_edge的迁移指南。读完本文你将能够准确理解 sender 接口的每个虚函数职责、如何在自定义节点中继承并实现 sender以及如何正确构建和拆除图中的边。说明本文讨论的sender类来自 mold 仓库内嵌的 oneTBBThreading Building Blocks第三方库该库随 mold 一同分发路径位于 third-party/tbb。虽然 mold 是高性能链接器其内嵌 TBB 主要用于自身并行化但 TBB Flow Graph 是完整独立的数据流编程框架本文仅聚焦 flow graph 的 sender 接口这一主题。概述sender 在 Flow Graph 中的角色在 oneTBB Flow Graph 模型中图由**节点node和边edge**组成消息沿着边从生产者流向消费者。senderT就是描述能够向外发送类型为T的消息的节点的抽象基类。与之对应的是receiverT描述能够接收类型为T的消息的节点。根据规范文档的定义An abstract base class for nodes that act as message senders.即sender 是充当消息发送方的节点的抽象基类。它同时提供了若干函数的默认实现default implementations因此派生节点只需实现必要的最小接口即可。从 flow_graph.h 的源码注释可以看到oneTBB 将 sender 描述为 Pure virtual template class that defines a sender of messages of type T——一个定义类型 T 的消息发送方的纯虚模板类。这里的T即节点输出消息的类型。需要特别注意的是规范文档在开头就给出了caution警告This feature is deprecated and will be reworked or removed in the future.也就是说sender类本身已被标记为弃用deprecated未来可能被重构或移除。这一点在使用时应心中有数。语法与头文件模板声明template typename T class sender;sender是一个以消息类型T为模板参数的类模板使用位置如senderint、sendermy_message等。头文件#include oneapi/tbb/flow_graph.h在 mold 仓库中该头文件的真实路径为 third-party/tbb/include/oneapi/tbb/flow_graph.h同目录下还提供了传统路径的兼容头文件 third-party/tbb/include/tbb/flow_graph.h。注意实际实现位于oneapi::tbb::detail::d2命名空间并通过头文件底部的命名空间别名机制暴露到oneapi::tbb::flow这与文档给出的使用命名空间一致namespace oneapi { namespace tbb { namespace flow { // 用户实际使用的 sender 位于此命名空间 } } }完整成员定义规范文档给出了sender的完整成员列表见 sender_cls.rsttemplate typename T class sender { public: typedef T output_type; typedef receiveroutput_type successor_type; virtual ~sender(); virtual bool register_successor( successor_type r ) 0; virtual bool remove_successor( successor_type r ) 0; virtual bool try_get( output_type v ) { return false; } virtual bool try_reserve( output_type v ) { return false; } virtual bool try_release( ) { return false; } virtual bool try_consume( ) { return false; } };与仓库内 flow_graph.h 的实现在成员集合上完全一致仓库版本将output_type与successor_type放在protected区并将两个纯虚函数设为protected以配合register_successor/remove_successor的友元自由函数这是实现细节上的差异接口语义不变。其中类型别名含义output_type本 sender 输出的消息类型即模板参数Tsuccessor_type后继节点类型即receiveroutput_type表示能够接收本节点输出消息的接收方成员函数语义表规范文档用一张表逐项说明了每个成员的语义见 sender_cls.rst整理如下成员说明返回值~sender()虚析构函数—bool register_successor( successor_type r ) 0纯虚方法定义向 sender 的后继集合中添加一个后继节点的接口添加成功返回true否则返回falsebool remove_successor( successor_type r ) 0纯虚方法定义从 sender 的后继集合中移除一个后继节点的接口移除成功返回true否则返回falsebool try_get( output_type v )从 sender 请求一个消息项默认实现返回falsebool try_reserve( output_type v )在 sender 处保留reserve一个消息项默认实现返回falsebool try_release( )释放 sender 上持有的保留reservation默认实现返回falsebool try_consume( )消耗 sender 上持有的保留reservation默认实现返回false两类成员的不同性质理解这张表的关键在于区分两类成员纯虚函数必须实现register_successor与remove_successor是 0的纯虚函数任何直接继承senderT的自定义节点都必须提供实现否则无法实例化。它们负责维护后继节点集合这一核心数据结构是消息转发路径的根基。虚函数可选覆写try_get、try_reserve、try_release、try_consume均有默认实现且默认返回false。这意味着默认情况下sender 既不支持被拉取pull也不支持保留-消耗reserve/consume协议只有覆写它们、返回true并真正实现相应行为的节点才支持这些高级交互方式。try_get / try_reserve / try_release / try_consume 的交互协议规范文档分别描述了这四个函数的功能它们共同构成一个完整的消息保留协议try_get(v)请求一个消息项成功时把消息写入v并返回true。try_reserve(v)请求保留一个消息项成功时写入v并返回true。保留意味着该项暂时锁定不能被其他消费者取走。try_release()释放此前通过try_reserve取得的保留消息项重新变为可获取状态。try_consume()将此前保留的消息项正式消耗掉移除完成消费。典型流程为try_reserve(v)成功后消费者可选择try_consume()真正取走或try_release()放弃。在 flow_graph.h 中limiter_node、buffer_node、queue_node、overwrite_node等缓冲类节点都覆写了这套协议以支持基于保留的消息调度例如reserving_arc形式的边会调用try_reserve决定是否可建立输送。源码实现佐证从 sender 到边核心实现位置mold 仓库内嵌 oneTBB 中 sender 的核心实现位于 flow_graph.h关键点如下类注释明确其为 Pure virtual template class每个虚函数都带有简要注释如//! Request an item from the sender、//! Reserves an item in the sender、//! Releases the reserved item、//! Consumes the reserved item纯虚函数register_successor/remove_successor被声明为protected并分别声明了两个模板友元函数register_successor(senderC, receiverC)与remove_successor(senderC, receiverC)见 flow_graph.h自由函数内部只是简单转发到对应的成员函数。典型实现broadcast_node / buffer_node仓库中许多具体节点都继承自senderT同时继承receiverT例如broadcast_node注释为 Forwards messages of type T to all successors把收到的每个消息转发给所有后继内部用broadcast_cacheinput_type维护后继集合buffer_node同时继承reservable_item_buffer、receiverT与senderT是一个可缓冲、支持保留协议的消息管道节点queue_node、overwrite_node、source_node、multifunction_node、composite_node等同样通过继承 sender/receiver 获得收发能力composite_node的output_ports_type定义为std::tuple senderOutputTypes... 见 flow_graph.h。可以推断一个节点既能收又能发时通常同时继承receiverT与senderT而纯数据源节点如source_node则主要作为 sender 存在。边的构建与拆除make_edge / remove_edge规范文档在 Description 一节给出了第二个caution重要警告The use ofregister_successorto build graphs has been deprecated forflow::graph. Graphs should be constructed withmake_edgeandremove_edge. Replacen1.register_successor(n2)withmake_edge(n1,n2).即使用register_successor构建图已被弃用应改用make_edge和remove_edge构建与拆除边将n1.register_successor(n2)替换为make_edge(n1, n2)。仓库实现印证了这一点flow_graph.h 中make_edge经由internal_make_edge调用register_successor(p, s)再记录 profiling 事件fgt_make_edgeremove_edge 则调用remove_successor(p, s)并记录fgt_remove_edge。也就是说make_edge/remove_edge正是对弃用接口的安全封装内部仍复用后继集合的增删逻辑但对外提供了更干净、更安全的 API并且支持多种重载make_edge(senderT, receiverT)单输入单输出节点之间建边当节点具有output_ports_type/input_ports_type多端口节点如multifunction_node、split_node、indexer_node时自动选取端口 0 建边见 flow_graph.hremove_edge提供完全对称的重载集合见 flow_graph.h。迁移指南从 register_successor 到 make_edge根据规范文档的明确指示把旧式建边代码迁移到新式 API 非常简单迁移前已弃用// 旧式直接操作后继集合 n1.register_successor(n2); n1.remove_successor(n2);迁移后推荐// 新式通过自由函数建边/拆边 make_edge(n1, n2); remove_edge(n1, n2);注意事项make_edge与remove_edge要求两端的消息类型匹配senderT连到receiverT类型不匹配会在编译期报错这也是比直接调用register_successor更安全的原因之一对多端口节点make_edge/remove_edge会自动处理端口 0 的接线无需手动从output_ports()/input_ports()中取端口虽然register_successor/remove_successor仍是纯虚函数、任何 sender 派生类都必须实现但用户代码不应直接调用它们来建图make_edge内部会完成转发与 profiling 记录。自定义 sender 派生类的实践要点若需要在 mold 仓库内嵌的 TBB 中编写自定义节点并使其具备发送能力可以从 sender 的接口设计中得到以下实践要点必须实现register_successor(successor_type)与remove_successor(successor_type)用一个容器如std::vectorsuccessor_type*或 TBB 提供的broadcast_cacheT、round_robin_cacheT等后继缓存类维护后继集合默认即可编译运行不覆写try_get/try_reserve/try_release/try_consume时它们返回false节点表现为只推不拉、不支持保留按需覆写拉取与保留协议需要支持下游拉取pull-based或保留式调度如连接limiter_node时再覆写try_get及 reserve/release/consume 三件套并保证状态机一致reserve 后必须 consume 或 release 二选一建图一律走make_edge/remove_edge不要直接调用register_successor注意弃用风险sender类整体已被标记为 will be reworked or removed若编写面向未来的新代码建议尽量基于高层节点function_node、buffer_node、multifunction_node、composite_node等组合图结构而非直接继承sender。验证与测试mold 仓库内嵌的 oneTBB 自带完整测试套件位于 third-party/tbb/test含test_flow_graph*.cpp等用例以及文档目录 third-party/tbb/doc/main/specification本文主体 sender_cls.rst 即位于其中的uncategorized/flow_graph分类下同目录还收录了receiver_cls.rst等配套规范。如需在本地验证 sender 相关行为可参考 TBB 的构建方式其 CMake 构建入口为 third-party/tbb/CMakeLists.txt编译 flow graph 相关测试或直接阅读头文件中的接口注释与节点实现来确认语义。小结senderT作为 oneTBB Flow Graph 的发送端抽象基类通过两个纯虚函数 四个带默认实现的虚函数的极简接口统一了所有消息发送方节点的行为契约register_successor/remove_successor负责后继集合的维护try_get/try_reserve/try_release/try_consume定义拉取与保留协议。在 mold 仓库内嵌的 flow_graph.h 中broadcast_node、buffer_node、composite_node等节点都以它为基础构建而make_edge/remove_edge则成为取代弃用接口、安全构建数据流图的推荐途径。理解 sender 的接口设计是深入掌握 Flow Graph 消息传递机制、乃至自定义节点行为的关键一步。【免费下载链接】moldmold: A Modern Linker 项目地址: https://gitcode.com/GitHub_Trending/mo/mold创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考