CN118277132A - 一种图形处理器远程调用的双线程池执行方法和系统 - Google Patents

一种图形处理器远程调用的双线程池执行方法和系统 Download PDF

Info

Publication number
CN118277132A
CN118277132A CN202410703257.7A CN202410703257A CN118277132A CN 118277132 A CN118277132 A CN 118277132A CN 202410703257 A CN202410703257 A CN 202410703257A CN 118277132 A CN118277132 A CN 118277132A
Authority
CN
China
Prior art keywords
thread
remote call
api interface
pool
task
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202410703257.7A
Other languages
English (en)
Inventor
华剑峰
高翔
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Zhejiang Lab
Original Assignee
Zhejiang Lab
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Zhejiang Lab filed Critical Zhejiang Lab
Priority to CN202410703257.7A priority Critical patent/CN118277132A/zh
Publication of CN118277132A publication Critical patent/CN118277132A/zh
Pending legal-status Critical Current

Links

Landscapes

  • Debugging And Monitoring (AREA)

Abstract

本申请涉及一种图形处理器远程调用的双线程池执行方法和系统,其中,图形处理器远程调用的双线程池执行方法包括:所述远程调用前端发起远程调用API接口的第一请求报文,并在所述第一请求报文的报文头中注入所述API接口的状态标识;所述远程调用后端接收所述第一请求报文,解析所述第一请求报文的报文头获得所述API接口的状态标识;所述任务分发器根据所述API接口的状态标识,将所述API接口对应的任务分发至所述有状态线程池或所述无状态线程池中执行,本申请最大程度的保证图形处理器远程调用在远程调用框架层面的时延性能,同时又为图形处理器业务提供线程隔离、状态保持的能力,提高了图形处理器远程调用后端执行任务的效率。

Description

一种图形处理器远程调用的双线程池执行方法和系统
技术领域
本申请涉及计算机技术领域,特别是涉及一种图形处理器远程调用的双线程池执行方法和系统。
背景技术
图形处理器(GPU)是一种对于图像和图形进行运算工作的微处理器。在图形处理器的使用过程中,普遍面临着资源使用率不高的问题,导致大量的图形处理器在很多的时间中处于浪费的状态。同时,存在着碎片化资源的问题,也就是在整个集群或者多集群中,还有相当比例的闲置图形处理器,但因为单节点上的资源无法满足图形处理器任务的需求,造成这些碎片化资源长时间处于闲置状态,而一些图形处理器的任务却因为资源缺少而无法运行。
相关技术中,可通过图形处理器的远程调用技术解决在集群的任意节点都可以运行图形处理器的任务的需求,本节点没有图形处理器资源或者资源不够的情况,都可以借助于远程调用的形式完成图形处理器任务的执行。另外一方面,借助于远程调用技术,把各闲散的图形处理器聚合起来,以满足图形处理器任务的资源需求。
目前,对于相关技术中,由于图形处理器任务的特殊性,以CUDA(统一计算设备架构,由NVIDIA推出的运算平台)举例,CUDA的任务API接口存在一些对线程强依赖或者是线程隔离的机制,图形处理器远程调用无法使用业界通用的远程调用框架,业界远程调用框架后端执行,一般为了提高性能,会在线程之上再封装为轻量化的接口,比如grpc(Google远程过程调用)的服务接口调用线程池,或者百度brpc(百度开源的远程过程调用框架)的bthread(是一个n:m的多线程库)等,这些都会屏蔽线程实例,无法满足图形处理器的远程调用时的线程隔离能力的需求,以及线程状态保持的能力。
而如果,远程调用前端和远程调用后端采用1:1的线程模型,等于后端复制了前端的线程环境,虽然能满足图形处理器的处理要求,但会出现线程的极大浪费,造成CPU资源负担过重。
因此,相关技术中远程调用方法都会导致图形处理器的远程调用后端的执行效率低的问题。
发明内容
基于此,有必要针对上述技术问题,提供一种能够提高图形处理器远程调用后端执行效率的图形处理器远程调用的双线程池执行方法、系统和介质。
第一方面,本申请实施例提供了一种图形处理器远程调用的双线程池执行方法,应用于服务器集群,所述服务器集群包括远程调用前端、远程调用后端,所述远程调用后端包括有状态线程池、无状态线程池和任务分发器,所述方法包括:
所述远程调用前端发起远程调用API接口的第一请求报文,并在所述第一请求报文的报文头中注入所述API接口的状态标识;
所述远程调用后端接收所述第一请求报文,解析所述第一请求报文的报文头获得所述API接口的状态标识;
所述任务分发器根据所述API接口的状态标识,将所述API接口对应的任务分发至所述有状态线程池或所述无状态线程池中执行。
在其中一个实施例中,所述有状态线程池包括:已使用线程容器、未使用线程容器;在所述第一请求报文的报文头中注入所述API接口的状态标识还包括:在所述第一请求报文的报文头中注入所述远程调用前端所执行的线程的线程ID;
所述远程调用后端接收所述第一请求报文,解析所述第一请求报文的报文头获得所述线程ID以及所述API接口的状态标识;
当所述API接口的状态标识为有状态时,在所述已使用线程容器中查找是否有所述线程ID对应的线程;
若有,则将所述API接口对应的任务加入到对应线程的任务队列中等待执行;
若无,则将所述未使用线程容器中的一个线程移动到所述已使用线程容器中,并将所述API接口对应的任务加入到该线程的任务队列中等待执行;
当所述API接口的状态标识为无状态时,将所述API接口对应的任务分发到所述无状态线程池中执行。
在其中一个实施例中,将所述未使用线程容器中的一个线程移动到所述已使用线程容器中之后,所述方法还包括:
在所述未使用线程容器中创建一个新的线程。
在其中一个实施例中,所述方法还包括:
当所述远程调用前端执行的线程退出,且所述远程调用前端调用的线程位于所述有状态线程池中时,所述远程调用前端发起远程调用线程销毁的第二API接口的第二请求报文,并在所述第二请求报文的报文头中注入所述远程调用前端所执行的线程的线程ID以及所述线程销毁的第二API接口的状态标识;
所述远程调用后端接收所述第二请求报文,解析所述第二请求报文的报文头,获得所述线程ID和所述线程销毁的第二API接口的状态标识;
所述任务分发器根据所述线程销毁的第二API接口的状态标识,将所述线程销毁的第二API接口对应的线程销毁任务分发到有状态线程池中;
基于所述远程调用前端所执行的线程的线程ID,在所述有状态线程池中查找对应的线程,执行所述线程销毁任务以销毁所述对应的线程。
在其中一个实施例中,所述无状态线程池包括:固定数量的线程容器、全局任务队列,所述方法还包括:
检测所述全局任务队列中任务的数量;
当所述全局任务队列中任务的数量超过第一预设值时,则增加所述固定数量的线程容器中线程的数量;
当所述全局任务队列中任务的数量低于第二预设值,且所述固定数量的线程容器中空闲线程的数量超过第三预设值时,则减少增加所述固定数量的线程容器中空闲线程的数量。
第二方面,本申请实施例还提供了一种图形处理器远程调用的双线程池执行系统,所述系统包括:远程调用前端和远程调用后端,所述远程调用后端包括有状态线程池、无状态线程池和任务分发器,
所述远程调用前端,用于发起远程调用API接口的第一请求报文,并在所述第一请求报文的报文头中注入所述远程调用前端所执行的线程的线程ID以及所述API接口的状态标识;
所述远程调用后端,用于接收所述第一请求报文,解析所述第一请求报文的报文头获得线程ID和所述API接口的状态标识;所述任务分发器根据所述API接口的状态标识,将所述API接口对应的任务分发至所述有状态线程池或所述无状态线程池中执行。
在其中一个实施例中,所述有状态线程池包含:已使用线程容器、未使用线程容器、热启动引擎、线程销毁的第二API接口,
所述已使用线程容器,用于保存正在被所述远程调用前端调用的线程,并通过所述远程调用前端所执行的线程的线程ID与所述已使用线程容器中线程的信息进行关联;
所述未使用线程容器,用于保存未被所述远程调用前端调用的线程;
所述热启动引擎,用于检测到所述未使用线程容器中的一个线程移动到所述已使用线程容器中时,在所述未使用线程容器中创建一个新的线程;
所述线程销毁的第二API接口,用于当所述远程调用前端执行的线程退出时远程调用所述线程销毁的第二API接口,以销毁所述有状态线程池中对应的线程。
在其中一个实施例中,所述无状态线程池包括:固定数量的线程容器、全局任务队列,
所述全局任务队列,用于保存所述任务分发器分发的任务;
所述固定数量的线程容器,用于保存已创建的线程,当存在空闲线程时执行所述全局任务队列中的任务。
在其中一个实施例中,所述无状态线程池还包括弹性伸缩模块,
所述弹性伸缩模块,用于根据所述无状态线程池中全局任务队列中任务的数量,动态调整所述固定数量的线程容器中线程的数量。
第三方面,本申请实施例还提供了一种计算机可读存储介质,所述存储介质中存储有计算机程序,其中,所述计算机程序被处理器执行时实现如上述第一方面所述的方法。
上述图形处理器远程调用的双线程池执行方法、系统和介质,通过远程调用前端发起一次远程调用时,在远程调用API接口的第一请求报文的报文头中注入所调用API接口的状态标识以及远程调用前端所运行线程的线程ID,远程调用后端的任务分发器根据远程调用发送过来的报文头中的状态标识,将远程调用请求分发给有状态线程池或者无状态线程池来执行并返回结果。本申请利用远程调用后端中的有状态线程池处理有状态API接口对应的任务,保障了图形处理器业务对于需要状态保持、线程依赖和需线程隔离的有状态任务的逻辑正确性;利用远程调用后端中的无状态线程池处理无状态API接口对应的任务,保障了图形处理器业务对于无状态API接口对应的任务的处理,能够与线程解耦,将无状态API接口对应的任务统一放入到无状态线程池中,由无状态线程池中的线程执行和返回结果,保障无状态API接口对应的任务的执行效率。本申请通过远程调用后端的有状态线程池和无状态线程池两种线程池的结合使用,最大程度的保证图形处理器远程调用在远程调用框架层面的时延性能,同时又为图形处理器业务提供线程隔离、状态保持的能力,提高了图形处理器远程调用后端执行任务的效率。
本申请的一个或多个实施例的细节在以下附图和描述中提出,以使本申请的其他特征、目的和优点更加简明易懂。
附图说明
此处所说明的附图用来提供对本申请的进一步理解,构成本申请的一部分,本申请的示意性实施例及其说明用于解释本申请,并不构成对本申请的不当限定。在附图中:
图1是一个实施例中图形处理器远程调用的双线程池执行方法的应用环境示意图;
图2是一个实施例中图形处理器远程调用的双线程池执行方法的流程示意图;
图3是另一个实施例中图形处理器远程调用的双线程池执行方法的流程示意图;
图4为一个实施例中有状态线程池中的线程销毁流程示意图;
图5为一个实施例中图形处理器业务为单线程运行时的流程示意图;
图6为一个实施例中图形处理器业务为多线程运行时的流程示意图;
图7为一个实施例中图形处理器远程调用的双线程池执行系统的结构图;
图8为一个实施例中有状态线程池的工作流程示意图;
图9为一个实施例中无状态线程池中弹性伸缩模块的工作流程示意图;
图10为一个实施例中无状态线程池的工作流程示意图。
具体实施方式
为了使本申请的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本申请进行描述和说明。应当理解,此处所描述的具体实施例仅仅用以解释本申请,并不用于限定本申请。
除非另作定义,本申请所涉及的技术术语或者科学术语应当为本申请所属技术领域内具有一般技能的人士所理解的通常意义。本申请所涉及的“一”、“一个”、“一种”、“该”等类似词语并不表示数量限制,可表示单数或复数。本申请所涉及的术语“包括”、“包含”、“具有”以及它们任何变形,意图在于覆盖不排他的包含;例如包含了一系列步骤或模块(单元)的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元,而是可以还包括没有列出的步骤或单元,或可以还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。本申请所涉及的“连接”、“相连”、“耦接”等类似的词语并非限定于物理的或者机械的连接,而是可以包括电气的连接,不管是直接的还是间接的。本申请所涉及的“多个”是指两个或两个以上。“和/或”描述关联对象的关联关系,表示可以存在三种关系,例如,“A和/或B”可以表示:单独存在A,同时存在A和B,单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。本申请所涉及的术语“第一”、“第二”、“第三”等仅仅是区别类似的对象,不代表针对对象的特定排序。
本申请实施例提供的图形处理器远程调用的双线程池执行方法,可以应用于如图1所示的应用环境中。其中,CPU服务器和GPU服务器均支持图像处理器应用,CPU服务器之间、GPU服务器之间以及CPU与GPU服务器之间都是通过一个或多个高速网络交换机进行连通,保证服务器与服务器之间网络可达,具体的网络部署不做限制。其中,服务器可以用独立的服务器或者是多个服务器组成的服务器集群来实现,这些服务器可以组建成一个集群,或者多个集群。其中,在服务器集群中,CPU服务器和GPU服务器可以作为图形处理器远程调用的前端,GPU服务器为图形处理器远程调用的后端。
本申请实施例提供了一种图形处理器远程调用的双线程池执行方法,以该方法应用于图1中的服务器集群为例进行说明,所述服务器集群包括远程调用前端、远程调用后端,所述远程调用后端包括有状态线程池、无状态线程池和任务分发器,如图2所示,该方法包括以下步骤:
S201,所述远程调用前端发起远程调用API接口的第一请求报文,并在所述第一请求报文的报文头中注入所述API接口的状态标识。
具体的,远程调用前端将所支持远程调用的所有API接口进行分类,分为有状态调用和无状态调用,并在发起远程调用的时候在远程调用的报文头中注入状态标识status,状态标识status表征本次调用API接口是有状态调用还是无状态调用,同时需要在报文头中注入远程调用前端所运行线程的线程ID,标识为remote_tid。
其中,状态标识status为有状态的含义是:本次图形处理器相关的API接口调用,是与线程环境强相关的API接口,以cuda API举例来说,通过cuCtxCreate接口在A线程创建的context句柄,只能在A线程可见,在另外一个线程B中无法使用context句柄,表明这类API接口具有线程隔离的能力,是有状态的,这类API接口包括但不限于context、stream、event和thread相关的cuda API。反之,状态标识status为无状态的含义是:对于无状态的API接口来说,API接口对应的任务可以在任意的一个线程环境中执行。本步骤在所述远程调用前端发起远程调用API接口的请求时,远程调用前端会根据所调用的API接口类型确定本次远程调用的API接口是否属于有状态调用。
S202,所述远程调用后端接收所述第一请求报文,解析所述第一请求报文的报文头获得所述API接口的状态标识。
S203,所述任务分发器根据所述API接口的状态标识,将所述API接口对应的任务分发至所述有状态线程池或所述无状态线程池中执行。
上述图形处理器远程调用的双线程池执行方法中,通过远程调用前端发起一次远程调用时,在远程调用API接口的第一请求报文的报文头中注入所调用API接口的状态标识以及远程调用前端所运行线程的线程ID,远程调用后端的任务分发器根据远程调用发送过来的报文头中的状态标识,将所述API接口对应的任务分发至所述有状态线程池或所述无状态线程池中执行。通过远程调用前端发起一次远程调用时,在远程调用API接口的第一请求报文的报文头中注入所调用API接口的状态标识以及远程调用前端所运行线程的线程ID,远程调用后端的任务分发器根据远程调用发送过来的报文头中的状态标识,将远程调用请求分发给有状态线程池或者无状态线程池来执行并返回结果。本申请利用远程调用后端中的有状态线程池处理有状态API接口对应的任务,保障了图形处理器业务对于需要状态保持、线程依赖和需线程隔离的有状态任务的逻辑正确性;利用远程调用后端中的无状态线程池处理无状态API接口对应的任务,保障了图形处理器业务对于无状态API接口对应的任务的处理,能够与线程解耦,即任务对线程环境无强依赖,可以在任意一个线程中执行;将无状态API接口对应的任务统一放入到无状态线程池中,由无状态线程池中的线程执行和返回结果,保障无状态API接口对应的任务的执行效率。
本申请实施例通过有状态线程池和无状态线程池两种线程池的结合使用,最大程度的保证图形处理器远程调用在远程调用框架层面的时延性能,同时又为图形处理器业务提供线程隔离、状态保持的能力,提高了图形处理器远程调用后端执行任务的效率。
在其中一个实施例中,所述有状态线程池包括:已使用线程容器、未使用线程容器。如图3所示,图形处理器远程调用的双线程池执行方法包括以下步骤:
S301,所述远程调用前端发起远程调用API接口的第一请求报文,并在所述第一请求报文的报文头中注入所述API接口的状态标识以及所述远程调用前端所执行的线程的线程ID;
S302,所述远程调用后端接收所述第一请求报文,解析所述第一请求报文的报文头获得所述远程调用前端执行的线程ID以及所述API接口的状态标识;
S303,判断所述状态标识是否为有状态。所述任务分发器根据所述API接口的状态标识,将所述API接口对应的任务分发至所述有状态线程池或所述无状态线程池中执行。
S304,当所述API接口的状态标识为有状态时,在所述已使用线程容器中查找是否有所述线程ID对应的线程;
S305,若有,则将所述API接口对应的任务加入到对应线程的任务队列中等待执行;
S306,若无,则将所述未使用线程容器中的一个线程移动到所述已使用线程容器中,并将所述API接口对应的任务加入到该线程的任务队列中等待执行;
S307,当所述API接口的状态标识为无状态时,将所述API接口对应的任务分发到所述无状态线程池中执行。
在本申请实施例,如果本次调用是有状态调用,则在有状态线程池的已使用线程容器中查找线程ID对应的线程是否存在,如果不存在,就从未使用线程容器中移一个线程到已使用线程容器中,同时将任务加入到该线程的任务队列中,等待任务的执行与返回。如果本次调用是无状态调用,则在无状态线程池中,将任务加入到无状态线程池的全局任务队列中,由空闲线程抢占获得任务,执行并返回结果,有效提高了远程调用后端执行任务的效率。
在其中一个实施例中,所述将所述未使用线程容器中的一个线程移动到所述已使用线程容器中之后,所述方法还包括:在所述未使用线程容器中创建一个新的线程。
在其中一个实施例中,所述方法还包括以下步骤:
S401,当所述远程调用前端执行的线程退出,且所述远程调用前端调用的线程位于所述有状态线程池中时,所述远程调用前端发起远程调用线程销毁的第二API接口的第二请求报文,并在所述第二请求报文的报文头中注入所述远程调用前端所执行的线程的线程ID以及所述线程销毁的第二API接口的状态标识。
S402,所述远程调用后端接收所述第二请求报文,解析所述第二请求报文的报文头,获得所述远程调用前端所执行的线程的线程ID和所述线程销毁的第二API接口的状态标识。
其中,线程销毁的第二API接口是在远程调用前端所执行的线程退出,对远程调用前端提供线程销毁的API接口,在析构函数中调用,所述线程销毁的第二API接口的状态标识为有状态调用。
S403,所述任务分发器根据所述线程销毁的第二API接口的状态标识,将所述线程销毁的第二API接口对应的线程销毁任务分发到有状态线程池中。
S404,基于所述远程调用前端执行的线程ID,在所述有状态线程池中查找对应的线程,执行所述线程销毁任务以销毁所述对应的线程。
可以理解的是,有状态线程池的特点是线程池不会自动销毁线程,而取决于远程调用前端运行情况,当远程调用前端对应的执行线程执行结束了,后端相对应的执行线程跟随着退出。
请参阅图4,图4是远程调用前端调用有状态API接口的线程在退出时,有状态线程池中的线程销毁流程示意图。当远程调用前端某个线程要退出时,需要在析构函数中调用线程销毁的第二API接口的远程调用,一般可以通过重载线程析构函数的方式实现,远程调用前端在远程调用的报文头上同样也需要标注状态标识status为有状态调用,远程调用后端收到前端的远程调用后,任务分发器将对应的销毁线程任务分发给有状态线程池,有状态线程池在已使用线程的容器中查找对应的线程,如果找到,则销毁对应的线程,释放其它内存资源。
本申请实施例中,远程调用前端图形处理器业务的某些线程执行完毕退出时,远程调用后端对应的线程也会退出,保证了有状态线程池中的线程不会出现冗余。当远程调用前端所有线程或者整个进程都退出后,远程调用后端对应的进程也会相应的退出,双线程池都会释放资源。由以上特征表明,有状态线程池是不做线程数量限定的,取决于远程调用前端应用程序的有状态线程数量。
在其中一个实施例中,所述无状态线程池包括:固定数量的线程容器、全局任务队列,所述方法还包括以下步骤:
S501,检测所述全局任务队列中任务的数量;
S502,当所述全局任务队列中任务的数量超过第一预设值时,则增加所述固定数量的线程容器中线程的数量;
示例性的,当检测到全局任务队列中任务的堆积数量超过限制时,例如堆积的任务数量大于无状态线程池中线程数量就开始扩容,增加所述固定数量的线程容器中线程的数量。
S503,当所述全局任务队列中任务的数量低于第二预设值,且所述固定数量的线程容器中空闲线程的数量超过第三预设值时,则减少增加所述固定数量的线程容器中空闲线程的数量。
示例性的,当监测到全局任务队列中的任务为空,并且所述固定数量的线程容器中空闲线程过半,就开始缩容,减少空闲线程的数量。
在一个示例实施例中,根据前端用户图形处理器业务,可以是基于tensorflow、pytorch等框架实现的AI业务,业务进程是单线程模式的,业务包含了若干(通常都是数万甚至数千万级别以上)次cuda API调用,针对每一次调用,首先,远程调用前端会在报文头中注入自己的线程ID,标识为remote_tid和状态标识status。然后,远程调用后端的任务分发器会根据状态标识status,将远程调用前端发起的远程调用API接口对应的任务转发给有状态线程池或者无状态线程池执行。可以理解的是,对于单线程的运行任务,虽然远程调用前端只有一个线程,但是同样可能会有若干个有状态调用和若干个无状态的调用。
针对有状态的API接口的首次调用,有状态线程池接收任务分发器的任务分发,有状态线程池先在已使用线程的容器中检查对应的线程ID(remote_tid)是否有对应的执行线程,发现找不到执行线程,就从未使用线程容器中取出一个线程,放入到已运行线程容器中,并且将任务放入到该线程的任务队列中,该线程就会启动执行该任务;同时,这时有状态线程池检测到未使用线程容器中少了一个线程,它就会创建一个新的线程以及对应的空任务队列补充到未使用容器中。
针对有状态的API接口的后续(非首次)调用,有状态线程池接收到任务分发器的任务分发,有状态线程池在已使用线程的容器中检查对应的线程ID(remote_tid)是否有对应的执行线程,发现已经存在,那么直接就将该任务放入到该执行线程的任务队列中,等待执行。
针对无状态的API接口的首次调用,无状态线程池接收任务分发器的任务分发,将任务放入到全局任务队列中,并通过信号量通知所有线程进行处理,由于所有线程都处于空闲状态,会进行竞争,谁先拿到任务就由该线程进行处理。
针对无状态的API接口的后续调用,跟首次调用同样的处理方式,将任务放入全局队列中等待有空闲线程来获取处理。
针对远程调用前端业务线程退出的情况,会在线程的析构函数中进行线程销毁的远程调用,该调用也被标识为有状态调用,有状态线程池接收到该调用以后,会在已使用线程容器中查找对应的线程ID(remote_tid)映射的线程,并将它销毁,然后从容器中移除。而对于无状态线程池则不需要进行任何处理。可以理解的是,远程调用前端线程如果没有执行过有状态调用,此时,在有状态线程池中也找不到对应的线程ID(remote_tid)映射的线程信息,此时析构函数就不需要执行动作。更进一步的优化,可以在远程调用前端线程中记录该线程是否调用过有状态函数,如果没有调用过,就不需要在线程的析构函数中进行销毁线程的远程调用。
本申请实施例所提供的图形处理器远程调用的双线程池执行方法,适用于图形处理器业务为单线程工作和多线程工作。
在一个实施例中,图5是图形处理器业务为单线程工作时的流程示意图,如图5所示,图形处理器业务可以是基于tensorflow、pytorch等AI应用框架所写的应用程序,也可以是基于图形处理器提供的框架API编写的应用,常见的图形处理器框架API有cuda、opencl等。tensorflow、pytorch等AI应用框架最终执行的也是图形处理器的API,cuda和opencl等。可以理解的是,一个应用是由大量的cuda等API接口组成的,而这些API接口有些是有状态的,有些是无状态的,一般情况下,图形处理器业务单线程工作模式下,同样会同时包含有状态和无状态两种调用。远程调用前端业务线程执行时,每一个调用都会发送给远程调用后端进行处理,有状态调用发送给有状态线程池,而无状态调用则发送给无状态线程池处理。在单线程工作模式下,远程调用后端有状态线程池中最多只有一个线程处理,当该单线程只调用无状态API接口时,有状态线程池就没有处于工作的线程。而对于无状态线程池,这种情况下,由线程池中的线程竞争处理,也并不会触发弹性扩缩容。
在一个实施例中,图6是图形处理器业务为多线程工作时的流程示意图,如图6所示,图形处理器业务为多线程工作模式时,远程调用前端就会有多个线程,这种情况是实际运行是更为普遍现象。单线程工作模式是多线程工作模式的一种特殊类型和简化。对于多线程工作模式下,这些线程中有多少个涉及到有状态调用,在远程调用后端有状态线程池中就会有对应数量个的已使用线程,而无状态线程池中的线程数量始终保持在最小值与最大值之间。举例来说,无状态线程池所配置的线程数量最小值和最大值分别是16和32,对于一个多线程的图形处理器业务工作线程假定有100个,其中有50个会调用到有状态API接口,这种情况下,远程调用后端有状态线程池中的已使用线程数就有50个,而无状态线程池中的线程数量保持在16~32范围内,由这些线程来处理远程调用前端100个线程的所有无状态API接口调用。在图形处理器业务多线程处理模式下,双线程池执行方法,通过有状态线程池来保障有状态调用的业务逻辑、线程隔离能力以及性能,而通过无状态线程来保障无状态API接口调用的最佳性能。
本申请实施例提供了一种图形处理器远程调用的双线程池执行系统,如图7所示,所述系统包括:远程调用前端10和远程调用后端20,所述远程调用后端20包括有状态线程池21、无状态线程池22和任务分发器23。
所述远程调用前端10,用于发起远程调用API接口的第一请求报文,并在所述第一请求报文的报文头中注入所述远程调用前端所执行的线程的线程ID以及所述API接口的状态标识。
所述远程调用后端20,用于接收所述第一请求报文,解析所述第一请求报文的报文头获得线程ID和所述API接口的状态标识;所述任务分发器23根据所述API接口的状态标识,将所述API接口对应的任务分发至所述有状态线程池21或所述无状态线程池中执行。
其中,远程调用前端10是用户执行图形处理器的环境,可以是物理机、虚拟机、容器等任意形式,所在的节点不要求有图形处理器,会通过远程调用的方式发给远程调用后端20执行。图形远程调用的远程调用前端10在远程调用报文头中注入前端所执行的线程的线程ID,标识为remote_tid,同时在报文头中注入状态标识status,状态标识status表征本次调用API接口是有状态调用还是无状态调用。
远程调用后端20是真正执行图形处理任务进程,要求远程调用后端的进程是运行在具有图形处理器的节点上,可以是物理机、虚拟机和容器等。图形处理器远程调用后端20通过双线程池来执行图形处理器的API任务。远程调用后端一个进程对应就有一个双线程池的实例。同时,远程调用前端用户的业务进程也与远程调用后端的执行进程一一对应,前后端进程1:1。
本申请实施例中,远程调用后端20包含了API接口任务执行的具体线程环境,该线程环境是由一个远程调用的双线程池所组成,其中所述双线程池装置包含有状态线程池21、无状态线程池22和任务分发器23。远程调用后端20通过任务分发器23将接收到的远程调用任务请求,根据远程调用API接口的状态标识status,将具体的调用任务分发给有状态线程池21或无状态线程池22执行。
本申请实施例中,利用远程调用的双线程池中的有状态线程池21,图形处理器业务的有状态调用,使远程调用前端业务线程在远程调用后端对应线程中的连续运行,保障了图形处理器业务对于需要状态保持、线程依赖和需线程隔离的有状态任务的逻辑正确性。
本申请实施例中,利用远程调用的双线程池中的无状态线程池22,保障了图形处理器业务对于无状态的任务,能够与线程解耦,统一放入到无状态线程池22中的全局任务队列中,由无状态线程池22中的线程执行和返回结果,保障无状态任务的执行效率。
本申请实施例中,通过有状态线程池21和无状态线程池22两种线程池的结合使用,最大程度的保证图形处理器远程调用在远程调用框架层面的时延性能,同时又为图形处理器业务提供线程隔离、状态保持的能力,提高了图形处理器远程调用后端执行任务的效率。
在其中一个实施例中,所述有状态线程池21包含:已使用线程容器、未使用线程容器、热启动引擎、线程销毁的第二API接口。
图8是一个实施例中图形处理器远程调用的双线程池中的有状态线程池的工作流程示意图,如图8所示,有状态线程池包含了已使用线程容器、未使用线程容器、热启动引擎和线程销毁接口几个关键模块所组成。
所述已使用线程容器,用于保存正在被所述远程调用前端调用的线程,并通过所述远程调用前端所执行的线程的线程ID与所述已使用线程容器中线程的信息进行关联。
具体的,所述已使用线程容器中的线程表示:正在被所述远程调用前端调用,已经开始运行的线程,这些线程与远程调用前端中调用过有状态API接口的所有线程一一对应。可选地,所述已使用线程容器一般选用关联容器,比如c++的map容器或者unorded_map容器进行关键值key-value保存;通过远程调用前端所执行的线程的线程ID与后端中已使用线程容器中线程的线程信息进行关联,线程信息包含了:线程实体、任务队列和线程处理函数等;所述有状态线程池中每一个线程都有自己独立的任务队列。
所述未使用线程容器,用于保存未被所述远程调用前端调用,从未运行过的线程。这些线程初始化状态下,任务队列为空,线程处理函数处于阻塞状态,可理解为处于睡眠之中,这些线程是为将来远程调用前端有新线程进行远程调用有状态API接口所准备的。可选地,未使用线程容器一般是使用动态数组vector等容器进行维护,比如c++的动态数组vector。未使用线程容器中的线程是为远程调用前端调用有状态API接口时提前准备好的线程,远程调用前端一个新的线程首次远程调用到远程调用后端就有线程可使用,避免线程创建所需要的开销。
所述热启动引擎,用于检测到所述未使用线程容器中的一个线程移动到所述已使用线程容器中时,在所述未使用线程容器中创建一个新的线程。
其中,当有状态线程池中的未使用线程容器中的线程被移到已使用线程容器中,热启动引擎监测到该变化,会重新创建一个新的线程,补充到未使用线程容器中。目的就是提前创建好线程,供有状态线程池使用,避免需要使用线程时再创建线程所带来的时延开销。
所述线程销毁的第二API接口,用于当所述远程调用前端执行的线程退出时远程调用所述线程销毁的第二API接口,以销毁所述有状态线程池中对应的线程。
其中,线程销毁的第二API接口则是对远程调用前端提供线程销毁的API接口,在远程调用前端所执行的线程退出,在析构函数中调用。
在其中一个实施例中,所述无状态线程池包括:固定数量的线程容器、全局任务队列,
所述全局任务队列用于保存所述任务分发器分发的任务;不同于有状态线程池中每个线程都有一个任务队列,无状态线程池只有一个任务队列,即全局任务队列,所有的线程都从该任务队列获取任务,由无状态线程池中的空闲线程竞争消费。
所述固定数量的线程容器用于保存已创建的线程,由线程池创建时就准备好了的线程,当存在空闲线程时执行所述全局任务队列中的任务。可选地,线程池的创建可以提供线程数量的选择,指定线程池中最大和最小数量,使所述固定数量的线程容器中线程的数量介于最大和最小数量之间。
在其中一个实施例中,所述无状态线程池还包括弹性伸缩模块,所述弹性伸缩模块,用于根据所述无状态线程池中全局任务队列中任务的数量,动态调整所述固定数量的线程容器中线程的数量。
具体的,弹性伸缩模块所要解决的问题是无状态线程池中的线程数量过多或者过少时,在最大和最小线程数量范围内进行干预。可选的,弹性伸缩模块提供多种伸缩策略,比如:当全局任务队列中未被消费的任务数量超过线程总数时进行线程的弹性扩容,或者全局任务队列中未被消费的任务积留时间大于一定的时间就进行弹性扩容;当无状态线程池中处于空闲无任务处理的线程数量占比达到一定比例时,则进行缩容。具体的伸缩策略可以通过配置文件进行修改。例如:弹性伸缩模块检测到全局任务队列的堆积数量超过限制时,就开始扩容;弹性伸缩模块检测到全局任务队列为空,并且空闲线程过半,就开始缩容。
图9是无状态线程池中弹性伸缩模块的工作示意图,如图9所示,无状态线程池中线程的数量,可以由弹性伸缩模块进行动态的调整。示例性的,当检测到全局任务队列中任务的堆积数量超过限制时,例如堆积的任务数量大于无状态线程池中线程数量就开始扩容,增加所述固定数量的线程容器中线程的数量。当监测到全局任务队列中的任务为空,并且所述固定数量的线程容器中空闲线程过半,就开始缩容,减少空闲线程的数量。
可以理解的是,线程数量的调整也是在最小值和最大值之间这个范围内调整,而不能无限扩容或者缩容。同时,弹性伸缩模块的扩缩容还提供策略的配置功能,举例来说,对于扩容,当全局任务队列中的任务数量大于无状态线程池中线程数量的n(n可设置)倍时,就触发动态扩容功能,扩充部分线程;对于缩容,当无状态线程池中空闲线程的数量占比大于m(m可设置)时,触发缩容功能,回收部分闲置线程。弹性伸缩模块保障无状态线程池中的线程数量保持在一个合理的范围内,既保证远程调用的性能,又避免线程这种宝贵资源的浪费。
在一个实施例中,图10是图形处理器远程调用的双线程中的无状态线程池工作示意图,如图10所示,前面已经有描述,无状态线程池主要有:固定数量的线程、全局任务队列和弹性伸缩模块组成。当无状态线程池收到一个任务,放入全局任务队列后,就有工作线程中的空闲线程去获取任务,并执行返回结果。无状态线程池,所要解决的是快速执行远程调用前端任务,因为它是无状态的,所以可以在任意一个线程中执行,所以执行策略就是谁空闲谁执行,而当多个线程都空闲的时候进行并发抢占,谁先抢到谁执行。考虑到实际执行的效率问题,无状态线程池的线程数量,提供最大数和最小数的配置,在实际配置的时候需要考虑所在节点上CPU实际能并发运行的最大线程数,建议不超过此值,因为超过此值,线程池中的线程也无法同时并发,同时,线程数量过多,频繁的线程切换,也需要开销。
本申请实施例提供的图形处理器远程调用的双线程池执行系统中,有状态线程池保证了图形处理器对于有状态任务能一直运行与固定线程中,保证运行逻辑;另外,有状态线程池是通过已运行线程容器和未运行线程容器两个容器进行维护,结合了热启动引擎,保证未运行线程容器中一直有所配置数量的线程,保证了每次远程调用前端启动了一个新线程,远程调用到远程调用后端,远程调用后端都已经准备好了执行的线程,避免了线程创建的开销时间,从而来保证图形处理器远程调用在远程调用框架层面的性能损耗最小。其中,其中无状态线程池则保证了图形处理器中大量的无状态应用,可以随机分发到无状态线程池的线程中执行,保证了执行的最佳性能。另外由于,无状态线程池提供了弹性伸缩的能力,可以根据无状态线程池的全局任务队列里任务数量情况,动态调整无状态线程池的线程数量,同时还可以结合所在环境上,实际CPU所具备的最大并行线程情况进行线程池的合理调整,以保证任务能在最短时间内执行。通过以上措施,将大大降低图形处理器远程调用在远程调用框架层面的时延,降低远程调用框架的性能损耗。
在一个实施例中,提供了一种计算机可读存储介质,其上存储有计算机程序,计算机程序被处理器执行时实现上述任一项图形处理器远程调用的双线程池执行方法实施例中的步骤。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程,是可以通过计算机程序来指令相关的硬件来完成,所述的计算机程序可存储于一非易失性计算机可读取存储介质中,该计算机程序在执行时,可包括如上述各方法的实施例的流程。其中,本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用,均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(Read-Only Memory,ROM)、磁带、软盘、闪存或光存储器等。易失性存储器可包括随机存取存储器(Random Access Memory,RAM)或外部高速缓冲存储器。作为说明而非局限,RAM可以是多种形式,比如静态随机存取存储器(Static Random Access Memory,SRAM)或动态随机存取存储器(Dynamic Random Access Memory,DRAM)等。
以上所述实施例的各技术特征可以进行任意的组合,为使描述简洁,未对上述实施例中的各个技术特征所有可能的组合都进行描述,然而,只要这些技术特征的组合不存在矛盾,都应当认为是本说明书记载的范围。
以上所述实施例仅表达了本申请的几种实施方式,其描述较为具体和详细,但并不能因此而理解为对发明专利范围的限制。应当指出的是,对于本领域的普通技术人员来说,在不脱离本申请构思的前提下,还可以做出若干变形和改进,这些都属于本申请的保护范围。因此,本申请专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种图形处理器远程调用的双线程池执行方法,应用于服务器集群,所述服务器集群包括远程调用前端、远程调用后端,其特征在于,所述远程调用后端包括有状态线程池、无状态线程池和任务分发器,所述方法包括:
所述远程调用前端发起远程调用API接口的第一请求报文,并在所述第一请求报文的报文头中注入所述API接口的状态标识;
所述远程调用后端接收所述第一请求报文,解析所述第一请求报文的报文头获得所述API接口的状态标识;
所述任务分发器根据所述API接口的状态标识,将所述API接口对应的任务分发至所述有状态线程池或所述无状态线程池中执行。
2.根据权利要求1所述的方法,其特征在于,所述有状态线程池包括:已使用线程容器、未使用线程容器;在所述第一请求报文的报文头中注入所述API接口的状态标识还包括:在所述第一请求报文的报文头中注入所述远程调用前端所执行的线程的线程ID;
所述远程调用后端接收所述第一请求报文,解析所述第一请求报文的报文头获得所述线程ID以及所述API接口的状态标识;
当所述API接口的状态标识为有状态时,在所述已使用线程容器中查找是否有所述线程ID对应的线程;
若有,则将所述API接口对应的任务加入到对应线程的任务队列中等待执行;
若无,则将所述未使用线程容器中的一个线程移动到所述已使用线程容器中,并将所述API接口对应的任务加入到该线程的任务队列中等待执行;
当所述API接口的状态标识为无状态时,将所述API接口对应的任务分发到所述无状态线程池中执行。
3.根据权利要求2所述的方法,其特征在于,将所述未使用线程容器中的一个线程移动到所述已使用线程容器中之后,所述方法还包括:
在所述未使用线程容器中创建一个新的线程。
4.根据权利要求1所述的方法,其特征在于,所述方法还包括:
当所述远程调用前端执行的线程退出,且所述远程调用前端调用的线程位于所述有状态线程池中时,所述远程调用前端发起远程调用线程销毁的第二API接口的第二请求报文,并在所述第二请求报文的报文头中注入所述远程调用前端所执行的线程的线程ID以及所述线程销毁的第二API接口的状态标识;
所述远程调用后端接收所述第二请求报文,解析所述第二请求报文的报文头,获得所述线程ID和所述线程销毁的第二API接口的状态标识;
所述任务分发器根据所述线程销毁的第二API接口的状态标识,将所述线程销毁的第二API接口对应的线程销毁任务分发到有状态线程池中;
基于所述远程调用前端所执行的线程的线程ID,在所述有状态线程池中查找对应的线程,执行所述线程销毁任务以销毁所述对应的线程。
5.根据权利要求1所述的方法,其特征在于,所述无状态线程池包括:固定数量的线程容器、全局任务队列,所述方法还包括:
检测所述全局任务队列中任务的数量;
当所述全局任务队列中任务的数量超过第一预设值时,则增加所述固定数量的线程容器中线程的数量;
当所述全局任务队列中任务的数量低于第二预设值,且所述固定数量的线程容器中空闲线程的数量超过第三预设值时,则减少增加所述固定数量的线程容器中空闲线程的数量。
6.一种图形处理器远程调用的双线程池执行系统,其特征在于,所述系统包括:远程调用前端和远程调用后端,所述远程调用后端包括有状态线程池、无状态线程池和任务分发器,
所述远程调用前端,用于发起远程调用API接口的第一请求报文,并在所述第一请求报文的报文头中注入所述远程调用前端所执行的线程的线程ID以及所述API接口的状态标识;
所述远程调用后端,用于接收所述第一请求报文,解析所述第一请求报文的报文头获得线程ID和所述API接口的状态标识;所述任务分发器根据所述API接口的状态标识,将所述API接口对应的任务分发至所述有状态线程池或所述无状态线程池中执行。
7.根据权利要求6所述的系统,其特征在于,所述有状态线程池包含:已使用线程容器、未使用线程容器、热启动引擎、线程销毁的第二API接口,
所述已使用线程容器,用于保存正在被所述远程调用前端调用的线程,并通过所述远程调用前端所执行的线程的线程ID与所述已使用线程容器中线程的信息进行关联;
所述未使用线程容器,用于保存未被所述远程调用前端调用的线程;
所述热启动引擎,用于检测到所述未使用线程容器中的一个线程移动到所述已使用线程容器中时,在所述未使用线程容器中创建一个新的线程;
所述线程销毁的第二API接口,用于当所述远程调用前端执行的线程退出时远程调用所述线程销毁的第二API接口,以销毁所述有状态线程池中对应的线程。
8.根据权利要求6所述的系统,其特征在于,所述无状态线程池包括:固定数量的线程容器、全局任务队列,
所述全局任务队列,用于保存所述任务分发器分发的任务;
所述固定数量的线程容器,用于保存已创建的线程,当存在空闲线程时执行所述全局任务队列中的任务。
9.根据权利要求8所述的系统,其特征在于,所述无状态线程池还包括弹性伸缩模块,
所述弹性伸缩模块,用于根据所述无状态线程池中全局任务队列中任务的数量,动态调整所述固定数量的线程容器中线程的数量。
10.一种计算机可读存储介质,其上存储有计算机程序,其特征在于,所述计算机程序被处理器执行时实现如权利要求1至权利要求5中任一项所述的方法。
CN202410703257.7A 2024-06-03 2024-06-03 一种图形处理器远程调用的双线程池执行方法和系统 Pending CN118277132A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202410703257.7A CN118277132A (zh) 2024-06-03 2024-06-03 一种图形处理器远程调用的双线程池执行方法和系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202410703257.7A CN118277132A (zh) 2024-06-03 2024-06-03 一种图形处理器远程调用的双线程池执行方法和系统

Publications (1)

Publication Number Publication Date
CN118277132A true CN118277132A (zh) 2024-07-02

Family

ID=91645588

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202410703257.7A Pending CN118277132A (zh) 2024-06-03 2024-06-03 一种图形处理器远程调用的双线程池执行方法和系统

Country Status (1)

Country Link
CN (1) CN118277132A (zh)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180081730A1 (en) * 2016-09-20 2018-03-22 Tata Consultancy Services Limited SYSTEMS AND METHODS FOR PREDICTING PERFORMANCE OF APPLICATIONS ON AN INTERNET OF THINGS (IoT) PLATFORM
CN113504984A (zh) * 2016-07-29 2021-10-15 华为技术有限公司 一种任务处理方法以及网络设备
CN116578404A (zh) * 2023-07-07 2023-08-11 北京趋动智能科技有限公司 线程管理方法、装置、存储介质及电子设备
CN117170842A (zh) * 2023-08-30 2023-12-05 招商银行股份有限公司 线程池管理架构及线程池管理方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113504984A (zh) * 2016-07-29 2021-10-15 华为技术有限公司 一种任务处理方法以及网络设备
US20180081730A1 (en) * 2016-09-20 2018-03-22 Tata Consultancy Services Limited SYSTEMS AND METHODS FOR PREDICTING PERFORMANCE OF APPLICATIONS ON AN INTERNET OF THINGS (IoT) PLATFORM
CN116578404A (zh) * 2023-07-07 2023-08-11 北京趋动智能科技有限公司 线程管理方法、装置、存储介质及电子设备
CN117170842A (zh) * 2023-08-30 2023-12-05 招商银行股份有限公司 线程池管理架构及线程池管理方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
RH CARVER 等: "A stateful approach to testing monitors in multithreaded programs", 《IEEE XPLORE》, 11 November 2010 (2010-11-11) *
刘宇: "Java规则引擎技术研究", 《计算机时代》, 31 July 2011 (2011-07-31) *

Similar Documents

Publication Publication Date Title
US9996401B2 (en) Task processing method and virtual machine
US9454389B2 (en) Abstracting a multithreaded processor core to a single threaded processor core
US7539989B2 (en) Facilitating intra-node data transfer in collective communications
JP4526412B2 (ja) マルチプロセッサシステムにおけるタスク管理方法および装置
WO2015096656A1 (zh) 线程创建方法、业务请求处理方法及相关设备
WO2019218708A1 (zh) 一种任务处理方法及处理装置、计算机系统
WO2021088419A1 (zh) 一种多业务请求进程调用fpga设备的方法及相关装置
US9201689B2 (en) Software emulation of massive hardware threading for tolerating remote memory references
US7661115B2 (en) Method, apparatus and program storage device for preserving locked pages in memory when in user mode
CN101452399B (zh) 任务二级调度模块及方法
US20070143582A1 (en) System and method for grouping execution threads
CN108595282A (zh) 一种高并发消息队列的实现方法
KR20070095376A (ko) 스케쥴링 방법, 장치, 멀티스레딩 시스템 및 제조물
US20140022263A1 (en) Method for urgency-based preemption of a process
JP2561801B2 (ja) プロセス・スケジューリングの管理方法およびシステム
US20230038051A1 (en) Data transmission method and apparatus
KR101900436B1 (ko) 결합된 cpu/gpu 아키텍처 시스템에서의 디바이스의 발견 및 토폴로지 보고
KR101357975B1 (ko) 코루틴을 이용하여 원격 프로시저 호출 서비스를 제공하는 방법 및 장치
CN112346835B (zh) 一种基于协程的调度处理方法及系统
CN118277132A (zh) 一种图形处理器远程调用的双线程池执行方法和系统
US20200097297A1 (en) System and method for dynamic determination of a number of parallel threads for a request
US20130263144A1 (en) System Call Queue Between Visible and Invisible Computing Devices
CN115509704A (zh) 一种任务调度方法、装置、设备及存储介质
CN111736998A (zh) 内存管理方法和相关产品
CN1667573A (zh) 基于服务体/执行流模型的操作系统

Legal Events

Date Code Title Description
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination