CN108647134B - 一种面向多核架构的任务监测、跟踪及识别方法 - Google Patents
一种面向多核架构的任务监测、跟踪及识别方法 Download PDFInfo
- Publication number
- CN108647134B CN108647134B CN201810421646.5A CN201810421646A CN108647134B CN 108647134 B CN108647134 B CN 108647134B CN 201810421646 A CN201810421646 A CN 201810421646A CN 108647134 B CN108647134 B CN 108647134B
- Authority
- CN
- China
- Prior art keywords
- task
- monitoring
- instances
- information
- scheduling
- 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.)
- Active
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3466—Performance evaluation by tracing or monitoring
Landscapes
- Engineering & Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
本发明提供了面向多核架构的任务监测、跟踪及识别方法，包括如下步骤：（1）建立任务监测模型Task Monitoring Model,TMM，TMM模型包括：（1‑1）面向任务模式的运行时模型；（1‑2）任务监测机制；以及（1‑3）采用关系描述图的方式将任务运行及关联信息进行展示，从而自动识别；（2）将任务监测模型应用于多核编程模型中，实现基于包装库技术的监测跟踪方法，包括：分析GCC OpenMP运行时库的任务执行机制；基于模拟调度的OpenMP任务监测机制；以及基于附加信息的OpenMP任务监测机制。此方法使性能工具可以监测新增加的执行维度，即任务，为性能分析人员提供必要的性能信息从而识别程序行为，发现性能瓶颈，进而优化程序，提高运行效率。
Description
技术领域
本发明涉及一种信息技术领域的性能监测分析领域，特别是涉及一种面向多核架构的任务监测、跟踪及识别方法。
背景技术
随着信息技术的飞速发展，计算机已经由传统的单一结构转变为多核异构组成的混合结构，软、硬件都发生着巨大的变化。然而，当前多核计算的基本单元是线程，通过线程来完成并行的计算任务，线程的创建和销毁所产生的开销较大，程序实现结构单调，不够灵活，既不能适应不规则结构的应用需求，又无法充分利用多核架构的计算资源。传统并行计算的应用范围主要是规则结构程序的运算，而应用多样化需求的发展趋势，造成不规则和动态结构(比如递归)的需求日益增大。这些应用也希望充分利用多核结构的并发操作带来性能上的飞跃。多核时代需要的是应用范围更为广阔、更易编程且效率更高的并行编程模型。在这种背景下，出现了任务模式，任务模式的出现扩展了并行编程的处理范围，增强了多核并行处理的效率，多核CPU架构同时成为了当前混合结构的主体部分。为了更有效地管理CPU核间的并行性和竞争，充分利用计算资源，扩展应用范围，任务计算模式应运而生。任务模式的出现，对性能监测分析技术的发展提出了新的挑战，主要表现为传统的监测、跟踪和识别方法无法适应任务特殊的执行行为。任务的行为主要可分为两个部分，一个是任务的创建，另一个则是任务的执行。这两个部分可能执行于不同的维度，即时间和空间。也就是说，它们根据运行时环境的需求，可以不是连续的，可以在不同的空间(空间在这里指运行任务的线程，即处于不同线程)和时间分别运行。另外，任务结构可以互相嵌套，但嵌套的任务之间不存在包含的关系。这些都与传统程序代码块(函数)的运行机理完全不同，必须对现有的性能监测、跟踪及识别技术加以修改，才可以准确地对并行程序进行监测。另外，性能监测虽然是程序优化的必要过程，但并不是程序运行的基本组成，对源码、编译器和运行时系统的改变本质上都是对正常运行流程的破坏。况且在很多情况下，无法获得应用程序源码，改变编译器和运行时系统也是不允许的，现有技术存在如下不足：
(1)现有技术大部分研究的监测方法都是使用源码直接插桩或采样的方法，这些监测机制由于其自身的不足，影响测量的应用范围和结果的准确性；
(2)系统对于任务的监测，通常是在原有监测对象的基础上，重点关注任务的创建和执行操作，而常常忽略了任务之间复杂的父子或约束依赖关系，性能信息的表现方式单一，通常在原有描述图中增加任务的元素，缺乏任务行为和关系的详细表达，而这些对于深入理解程序和任务行为有着重要的作用；
(3)缺乏专门针对多核任务模式并适用于多数编译环境和运行时系统的监测方法，而这些监测方法对性能监测的研究起到指导性作用。
发明内容
为了解决这些问题，本发明提出了一种面向多核架构的任务监测、跟踪及识别方法，此方法使性能工具可以监测新增加的执行维度，即任务，为性能分析人员提供必要的性能信息从而识别程序行为，发现性能瓶颈，进而优化程序，提高运行效率。
本发明的目的在于提供一种面向多核架构的任务监测、跟踪及识别方法，包括如下步骤：
(1)建立任务监测模型(Task Monitoring Model,TMM)；
(2)将任务监测模型应用于多核编程模型中，实现基于包装库技术的监测跟踪方法。
优选的，所述步骤(1)中TMM模型包括：
(1-1)面向任务模式的运行时模型；
(1-2)任务监测机制；以及
(1-3)采用关系描述图的方式将任务运行及关联信息进行展示，从而自动识别。
优选的，所述面向任务模式的运行时模型(1-1)包括六个组件，分别为：
任务实例，表示为taskIns，是程序运行中的基本执行单元，任务实例拥有静态属性和操作行为，其中静态属性描述taskIns内在固有属性，表示任务实例的固有特性，形式化表达为taskIns.ID＝XXX；操作行为包括执行行为和行为状态，所述执行行为描述taskIns在其生命周期内的执行行为(相关操作)，形式化表达为taskIns.execute(；所述行为状态本质是一项静态属性，描述taskIns执行过程中各个阶段所处的状态，形式化表达为taskIns.state＝XXX；
任务池，以一定组织形式放置产生的taskIns，并囊括了其相关信息，包括数据环境和必要的静态属性，所述任务池在系统内存开辟部分空间存放所述相关信息，以链表的形式维持taskIns之间的关系；
线程池：任务调度的过程在线程池中寻找空闲线程，根据调度规则完成任务与执行线程的匹配，所述线程为任务的执行载体，是程序的实际执行单元，线程可以是操作系统概念中的用户级线程或系统线程中的一个或多个；
调度引擎：任务模式运行时系统的调度控制中心，其中调度单元就是任务实例taskIns，所述调度引擎实时关注任务池和线程池的情况，根据调度策略、上下文环境以及限制条件来调度匹配任务实例taskIns和线程，使两者结合执行，所述调度策略依赖编译器和运行时系统的实现机制；
任务控制引擎：负责任务实例taskIns预处理操作，进行数据环境的处理，并将任务实例放入任务池等待调度执行；
执行池：用来执行任务实例，一旦有任务实例进入执行池，此任务实例的计算操作就会被立即执行。
优选的，所述(1-2)的任务监测机制包括面向任务实例的状态转换监测以及基于任务的应用程序的监测，所述面向任务实例的状态转换监测包括：在taskIns状态变换前后记录相应的度量值，taskIns在“WAIT”状态和“PEND”状态可能会发生时间延迟和空间维度处于不同线程的转换，监测机制需要完成任务实例的识别过程，并将任务实例与监测度量匹配，完整记录各个taskIns执行周期的行为，在进入这两个状态之前对任务实例进行预处理，当其状态从“WAIT”和“PEND”转换到“RUN”时，先进行任务实例的解析，从而识别并正确反映任务实例的执行行为；所述基于任务的应用程序监测包括：所述监测所使用的监测系统处于应用程序与运行时系统之间并以共享库的形式存在，包括函数跟踪、信息测量、信息记录，所述监测分别依赖关联的静态信息，所述静态信息包括监测函数列表、踪迹和/或轮廓的测量方式、通信协议和存储格式中的一个或多个。
优选的，所述(1-2)任务监测机制包括监测系统的任务识别，所述监测系统的任务识别方法包括：基于模拟调度的任务跟踪识别方法和基于附加信息的任务跟踪识别方法，其中，所述基于模拟调度的任务跟踪识别方法包括：在监测系统中模拟运行时系统模型构建一个调度引擎，与运行时系统的调度策略一致，当任务实例放入任务池中时，包括初始分配或者中途挂起两种情形，监测系统也将任务实例连同需要记录的度量，即任务实例的部分静态属性保存在一个模拟任务池中，运行时系统的调度引擎根据调度策略、上下文环境以及限制条件来调度执行的任务实例时，监测系统同时调用模拟调度引擎，使用同样的机制在模拟任务池中选择任务实例，从而监测系统就可监测运行时系统中任务实例的执行行为，并将模拟任务池中调出的任务实例对应的属性信息与之匹配，从而完成任务实例执行生命周期中的识别和信息记录工作；所述基于附加信息的任务跟踪识别方法包括：监测系统在任务实例进入运行时系统的任务池之前，将识别信息，即关联的静态属性作为附加的信息放入任务实例之中，随着任务实例在任务池中等待直至被调度执行，此时监测系统首先解析此任务实例，获取识别信息，然后开始执行，同时记录运行状态，并与解析出的识别信息相关联，从而完成监测工作。
优选的，所述(1-3)采用关系描述图的方式将任务运行及关联信息进行展示包括两种描述图，即任务时间线图与动态任务关系图，所述任务时间线图表示为TTG，伴随着时间维度的推进，不同线程及其上运行的任务实例在空间维度上的执行行为，包括运行次序、运行间隔、交互关系，交互关系表示在任务时间图中表现任务实例之间的父子创建关系；所述动态任务关系图表示为DTRG，用于描述程序运行中任务实例之间的关系，其中父子关系和依赖关系在图中使用不同的形状加以区分，使用不同颜色来表示不同的线程，并附加相关的轮廓信息。
优选的，所述步骤(2)将任务性能监测模型应用于OpenMP规范中，实现基于包装库技术的性能监测分析方法包括：分析GCC OpenMP运行时库的任务执行机制；基于模拟调度的OpenMP任务监测机制；以及基于附加信息的OpenMP任务监测机制。
优选的，所述GCC OpenMP运行时库的任务执行机制包括：任务调度层和执行层包含于OpenMP运行时库，在GNU实现中，任务队列是由两个双向链表来维护的，分别是队列和树形链表，同时同步原语、if语句都将被调度引擎读取，所述调度引擎实时监测线程池，可调度的任务、可用的线程以及调度策略共同决定了任务实例的执行顺序，一旦一个任务实例被调度，其执行实体将被放入执行池中运行。
优选的，所述基于模拟调度的OpenMP任务监测机制包括：在监测库中仿照运行时系统中的调度引擎研制一个模拟调度引擎，并维持一个任务队列组成模拟任务池，模拟任务池的组织方式由两个双向链表组成，分别以任务队列和树形父子关系的方式来加以组织，其中每个任务实例都附加相关性能信息，所述任务监测的流程为：当显式任务实例被创建后，监测系统除记录创建信息并生成任务ID之外，就使用模拟任务控制引擎将产生的任务实例放入模拟任务池中，同时放入模拟任务池的还有塑封在任务实例之中属性信息，属性信息包括任务ID、创建线程ID以及父任务实例ID；然后将此任务实例放入OpenMP运行时库中的任务控制引擎,进而进入任务池开始正常的执行流程；在这个过程中，实际执行的函数体指针也被监测库包装，在程序执行中，当任务实例被调度引擎调度运行，其实际执行函数被调用时，执行指针指向监测库的包装函数，包装函数实际启动的是监测包装库中的模拟调度引擎，依据调度策略、限制条件和上下文环境来调度模拟任务池中保存的任务实例，调度策略即先来先服务和宽度优先的树状调度策略，由于调度条件一致，模拟调度引擎与运行时系统中的调度结果一致，模拟调度引擎所附加的静态属性信息就会被监测系统记录，匹配此任务实例的执行行为，最后调用任务实例的真正执行函数，运行于执行层，与此同时，记录执行函数的入口和出口信息，并将附加的属性信息记录以区别任务实例，对于挂起操作的任务行为，GCC是使用栈的方式调度的，运行时系统运行完新调度的任务之后将会自动返回当前任务的执行状态。
优选的，所述基于附加信息的OpenMP任务监测机制包括：在显式任务实例被创建之后，监测库中同名的包装库函数将其截取，进行预处理操作，流程包括：通过函数参数解析和处理原始数据，对数据的处理操作是与运行时系统相一致的；监测系统根据预定义的规则产生任务标识；监测系统使用一个命名为TaskData的自定义的结构体类型，结构体类型包括数据指针、函数指针、任务标示和父任务标示，监测系统将前面处理完毕的原始数据放入这个结构体中，并调用系统动态库库中的函数，将其中的数据参数改为结构体TaskData，并将与数据处理相关的参数置空，使附加识别信息的任务实例参与到运行时系统的正常流程。
根据下文结合附图对本发明具体实施例的详细描述，本领域技术人员将会更加明了本发明的上述以及其他目的、优点和特征。
附图说明
后文将参照附图以示例性而非限制性的方式详细描述本发明的一些具体实施例。附图中相同的附图标记标示了相同或类似的部件或部分。本领域技术人员应该理解，这些附图未必是按比例绘制的。本发明的目标及特征考虑到如下结合附图的描述将更加明显，附图中：
图1为根据本发明一个实施例的任务模式的运行时系统模型示意图。
图2为根据本发明一个实施例的描述任务实例的状态转换图。
图3为根据本发明一个实施例的基于任务实例的状态转换的监测原理示意图。
图4为根据本发明一个实施例的基于任务的应用程序的监测模型示意图。
图5为根据本发明一个实施例的动态任务关系示意图。
图6为根据本发明一个实施例的GCC OpenMP运行时库的任务执行机制示意图。
图7为根据本发明一个实施例的基于模拟调度的任务监测机制运行原理图。
图8为根据本发明一个实施例的基于附加信息的任务监测机制原理示意图。
图9为根据本发明一个实施例的GCC OpenMP任务实例调用示意图。
图10为根据本发明一个实施例的监测GCC OpenMP运行时系统对应的监测调用方式示意图。
具体实施方式
为了使得本发明能够针对其发明要点更加明显易懂，下面将结合附图和实例对本发明作进一步的说明。在下面的描述中阐述了很多细节和具体实例，提供这些实例是为了能够更透彻地理解本发明，并且能够将本发明完整形象地传达给本领域的技术人员。虽然本发明能够以很多不同于此描述的其它方式实施，但是本领域技术人员可以在不违背本发明内涵的情况下做相应的推广，因此本发明不受下面公开的具体实例及具体附图所限制。
传统并行计算的应用范围主要是规则结构程序的运算，应用多样化需求的发展趋势，造成不规则和动态结构(比如递归)的需求日益增大，这些应用也希望充分利用多核结构的并发操作带来性能上的飞跃。另外，当前多核计算的基本单元是线程，通过线程来完成并行的计算任务，线程的创建和销毁所产生的开销较大，应尽量避免，这样就致使程序实现结构单调，不够灵活。既不能适应不规则结构的应用需求，又无法充分利用多核架构的计算资源。多核时代需要的是应用范围更为广阔、更易编程且效率更高的并行编程模型。在这种背景下，出现多核架构下的任务模式。任务模式的出现扩展了并行编程的处理范围，增强了多核并行处理的效率，主要表现为：
1)任务模式在原有规则结构的基础上，加入适用于不规则结构的处理方法，将多核并行处理的优势扩展到更宽广的范围；
2)任务模式增加了除线程之外新的逻辑处理单元：任务。任务与线程相互分离，用户只需关注任务的逻辑处理，而不必再关心处理器核的数目、线程数目等因素，极大地提高了程序的可编程性和透明性；
3)程序运行中可以出现大量的任务来参与计算，增加了并行性，减少了线程的创建与销毁次数，提高了程序的执行效率。同时，由于任务可由运行时系统根据系统状态动态调度，有助于实现系统的负载均衡。
上述优势使任务模式成为多核时代高效编程一个重要发展方向。任务模式的出现，对性能监测分析技术的发展提出了新的挑战，主要表现为传统的监测、跟踪及识别方法无法适应任务特殊的执行行为。任务的行为主要可分为两个部分，一个是任务的创建，另一个则是任务的执行。这两个部分可能执行于不同的维度，即时间和空间。也就是说，它们根据运行时环境的需求，可以不是连续的，可以在不同的空间位置(空间位置在这里指运行任务的线程)和时间分别运行。另外，任务结构可以互相嵌套，但嵌套的任务之间不存在包含的关系。这些都与传统程序代码块(函数)的运行机理完全不同，必须对现有的监测、跟踪及识别技术加以修改，才可以准确地对并行程序进行监测。另外，性能监测虽然是程序优化的必要过程，但并不是程序运行的基本组成，对源码、编译器和运行时系统的改变本质上都是对正常运行流程的破坏，应尽量避免。况且在很多情况下，无法获得应用程序源码，改变编译器和运行时系统也是不允许的。为了解决这些问题，提出了一种面向多核架构下的任务监测、跟踪及识别方法，此方法使性能工具可以监测新增加的执行维度(任务)，为性能分析人员提供必要的性能信息从而识别程序行为，发现性能瓶颈，进而优化程序，提高运行效率。
一、建立任务监测模型
任务监测模型(Task Monitoring Model,TMM)由三部分组成：面向任务模式运行时模型、任务监测机制以及采用关系描述图的方式将任务及关联信息进行展示。本实施例首先抽象化任务模式运行机制，在此基础上说明任务性能监测问题，并引入两种描述图，从不同的角度揭示运行于线程之上的任务之间的关系及执行状态。
(一)面向任务模式运行时模型
由于任务模式是多核编程的一种规范，并没有实现细节的统一规定，允许开发厂商或研究人员按照自己的理解加以实现，因此，不同的编译器有着自己特定的实现方式。本实施例首先需要抽象化任务运行的共性特性，使用一种通用模型来描述任务的执行流程，并在此基础上研究监测机制。其中面向任务模式的运行时模型由六个组件组成，分别定义如下。
定义1任务实例(Task Instance)：任务实例，表示为taskIns，是程序运行中的基本执行单元。使用任务实例表示具体执行的任务，程序中通常会说明一个任务结构，任务结构遇到执行线程就成为任务实例，而任务实例执行的动态指令称为任务区域。任务区域可以相互嵌套，但语义上并不相互包含。任务实例拥有一系列静态属性和操作行为，描述如下。
(a)静态属性：描述taskIns内在固有属性，表示任务实例的固有特性。形式化表达为taskIns.ID＝XXX。常见的属性列举如表所示。
表1任务实例静态属性列表
(b)执行行为：描述taskIns在其生命周期内的执行行为(相关操作)。形式化表达为taskIns.execute()。常见行为列举如表2所示。
表2任务实例执行行为列表
| 行为 | 含义描述 |
| execute | 表示taskIns的计算操作，完成主要功能 |
| create | 表示创建新的taskIns |
| synchronize | 表示同步操作 |
| resume | 表示先前被挂起的taskIns(延迟执行)的恢复操作 |
(c)行为状态：本质就是一项静态属性，描述taskIns执行过程中各个阶段所处的状态。形式化表达为taskIns.state＝XXX。常见状态列举如表3所示。
表3任务实例执行状态列表
定义2任务池(Task Pool)：以一定组织形式放置产生的taskIns，并囊括了其相关信息，比如数据环境和必要的静态属性。任务池通常是在系统内存开辟部分空间存放这些任务信息，组织形式依据具体实现，常以链表的形式维持taskIns之间的关系。
定义3线程池(Thread Pool)：线程，在这里指的是程序的实际执行单元，可以是操作系统概念中的用户级线程，也可以是系统线程，是任务的执行载体。任务调度的过程通常在线程池中寻找空闲线程，根据调度规则完成任务与执行线程的匹配。
定义4调度引擎(Scheduling Engine)：是任务模式运行时系统的调度控制中心。调度单元就是taskIns。调度引擎需要实时关注任务池和线程池的情况，根据调度策略、上下文环境以及限制条件来调度匹配taskIns和线程，使其结合执行。具体调度策略依赖于编译器和运行时系统的实现机制。
定义5任务控制引擎(Task Control Engine)：负责taskIns预处理操作，主要进行数据环境的处理，并将任务实例放入任务池等待调度执行。
定义6执行池(Execution Pool)：用来执行任务实例。一旦有任务实例进入执行池，此任务实例的计算操作就会被立即执行。
基于上述组件定义，任务模式的运行时系统模型如图1所示，taskIns进入运行时系统之后，任务控制引擎对其进行预处理，进而放入任务池之中等待调度。调度引擎则根据调度策略、上下文环境和限定条件，匹配线程与taskIns，taskIns就在此线程上执行计算任务。如果taskIns在执行中被挂起，运行其他的taskIns，则先前的任务实例就会被放入任务池中，等待再次调度执行。在实际实现中，限定条件若引起任务实例立即执行(比如OpenMP规范中if条件设定为false)，也可将任务实例不放到任务池之中而直接运行，但是这里为了使模型描述更清晰，将所有任务实例的执行统一于调度引擎管理的框架之内，也将其抽象到任务池中，只不过调度引擎会立即调度让其执行，不会影响程序中任务执行语义的描述。执行池中的线程不会脱离线程池，它的状况随时可在线程池中查询，直到此线程终止为止。比如某线程执行完前面的任务，调度引擎可从线程池查询到它处于空闲状态，因而根据调度策略再次调度任务实例和此线程(比如Cilk和TBB中的窃取机制)，保持线程的忙碌。任务模式的运行时系统负责多个任务实例的执行与调度，最终有效地运行于底层多核架构。
除此之外，还可以使用另外一种方式来描述任务实例的工作流程，那就是状态转换图，如图2所示。图中元素都是模型中任务实例的行为状态。转换图从“START”开始，到“END”结束。在一个taskIns的执行生命周期中，不同的限制条件(比如OpenMP标准中的if子句)和上下文环境，都会引起其在多种状态之间不断转换。taskIns在被创建的过程中，运行时系统会处理数据环境、产生任务逻辑，此任务实例处于EMERGING(EMER)状态，然后根据taskIns的限制条件以及类型来判定是否立即执行。如果立即执行则转换到RUNNING(RUN)状态；否则就将其放入任务池，等待系统调度，这时处于WAITING(WAIT)状态。调度引擎依据调度策略、上下文环境以及限制条件选择任务池中的任务实例和线程池中的线程匹配，完成调度。一旦确定此任务实例被调度执行，其状态就会转换为RUN。taskIns在运行过程中也会产生两次状态变换，一次是由于创建其他任务实例，状态转换为CREATING(CREAT)，创建完毕后通常是转回RUN状态的。若新创建的任务实例根据限制条件立即实行，taskIns就会直接转换为SUSPENDING(PEND)状态；另一次则是在任务调度点，比如进行同步操作时，若当前任务实例根据调度策略被运行时系统挂起而使系统执行其他任务实例，则状态转变为PEND直到taskIns重新启动执行。最后，当taskIns完成运算工作，状态转换到结束状态，状态转换图结束，这就是任务实例的整个生命周期的状态变化。
(二)任务监测机制
抽象任务运行时系统模型，就是为完成任务实例的性能监测提供前提条件，本实施例监测机制不影响程序正常转换和运行流程，不会改变程序源码、编译器和运行时系统，从而要求监测程序对应用程序和运行时系统都是透明的。若想准确详细地记录任务实例的执行行为，一个重要的前提就是能够识别taskIns并记录其在各个转换状态的性能度量值。图3描述了基于任务实例的状态转换的监测原理。方框部分表示监测系统执行的操作。在taskIns状态变换前后记录相应的度量值(最常见的是时间戳)。其中，taskIns在“WAIT”状态和“PEND”可能会发生时间(延迟)和空间(处于不同的线程)的转换，在其前后状态监测系统要先完成任务实例识别操作，并将任务实例与监测度量相匹配，从而可完整记录各个taskIns执行周期的行为。运行时系统的内部数据结构和调度策略又是不允许监测系统直接访问的，所以需要在进入这两个状态之前对任务实例进行预处理，而当其状态从“WAIT”和“PEND”转换到“RUN”时，又要先进行任务实例的解析，从而能够加以识别，正确反映任务实例的执行行为。
图4对基于任务的应用程序的监测模型进行描述。在监测模型中，监测系统处于应用程序与运行时系统之间(通常以共享库的形式存在)，主要包括函数跟踪、信息测量、信息记录等几个部分，分别依赖关联的静态信息，比如监测函数列表、测量方式(踪迹和/或轮廓)、通信协议、存储格式等。另外，本实施例提出了两种方法来应对任务的机动性和异步性带来的性能监测的问题，包括：
1)基于模拟调度的任务识别与跟踪方法
任务实例运行中它的空间和时间的变化规律是由运行时模型中的调度引擎所决定的。作为监测系统，在无法访问运行时系统内部数据结构的情况下，一个可行的方法就是在监测系统中模拟运行时系统模型构建一个调度引擎，与运行时系统的调度策略一致。当任务实例放入任务池中(包括初始分配或者中途挂起两种情形)时，监测系统也将任务实例连同需要记录的度量(包括任务实例的部分静态属性)保存在一个模拟任务池中。运行时系统的调度引擎根据调度策略、上下文环境以及限制条件来调度执行的任务实例的时候，监测系统也会调用模拟调度引擎，使用同样的机制在模拟任务池中选择任务实例。这样监测系统就可监测运行时系统中任务实例的执行行为，并将模拟任务池中调出的任务实例对应的属性信息与之匹配，从而完成任务实例在其执行生命周期中的识别和信息记录工作。
2)基于附加信息的任务识别与跟踪方法
第二种方法，则是监测系统在任务实例进入运行时系统的任务池之前，将识别信息(关联的静态属性)作为附加的数据后缀放入任务实例之中，任务实例进入任务池开始起正常流程，当它被调度执行时，监测系统首先解析此任务实例，获取识别信息，然后开始执行，同时记录运行状态，并与解析出的识别信息相关联，从而完成监测工作。
监测模型的实现首选第二种方法，在第二种方法难以实现的情况下，可以考虑使用第一种方法。
(三)任务信息的描述方法
获得任务信息之后，使用合理的方法将其描述出来以供用户理解，从而可进一步寻找性能瓶颈。本实施例提出了两类新的描述图，定义如下。
(1)任务时间线图(Task Timeline Graph)：简写为TTG。伴随着时间维度的推进，不同线程及其上运行的任务实例在空间维度上的执行行为，包括运行次序、运行间隔、交互关系，这些都可清晰表现于此类图中，交换关系表示在任务时间线图中表现任务实例之间的父子创建关系。这类图使用基于任务模式执行行为来取代函数(代码块)，并可表现任务实例之间的父子调用关系。
(2)动态任务关系图(Dynamic Task Relationship Graph)：动态任务关系图，表示为DTRG，用于描述程序运行中任务实例之间的关系，并行程序P的动态任务关系图定义为一个有向流图G＝{T，Ep，Ed，F}，T为结点集合，Ep和Ed为边的集合。结点t∈T表示任务实例在对应的线程上执行(可用不同颜色表示不同的线程并将其作为t的属性。如果不同的任务实例在相同的线程上执行，则可将这些任务实例标注为相同的颜色)，结点中可注明此任务实例的类型、名称、执行时间轮廓信息。边<t1，t2>∈Ep表示结点对t1，t2∈T，其中t2是t1的一个孩子，而t1是t2唯一的父亲，此结点对描述了任务实例之间的父子关系；同样，<t3，t4>∈Ed表示结点对t3，t4∈T，其中t4依赖于t3，此结点对描述了任务实例之间的依赖关系。不同集合中的边在图中可使用不同的形状加以区分。并行程序P中第i个并行区域的第一个任务实例定义为fi∈F。如果Ed是一个空集并且并行区域的数目是1，此图就会变为一个表示任务实例之间父子关系的树状结构，可定义为动态任务关系树(Dynamic Task Relationship Tree,DTRT)。
TTG图重点强调附加于线程的任务执行流的行为，而DTRG图则重点强调任务实例之间的关系，它们从不同的角度描述了任务的运行特征，从而有助于深入理解程序，发现性能问题。
此外，DTRG准确地描述了程序运行中任务实例之间的关系，并附加相关的轮廓信息。然而，对于Ed，可能会存在冗余边交织在图中，从而会影响分析的效率和效果。为了解决这个问题，提出另外两个定义，描述如下。
(3)依赖关系路径集(Dependency Relationship Path Set)：依赖关系路径集可表示为DRPS，是由DTRG中的Ed的边组成的顺序依赖关系，表示为DRPS＝(tr1→tr2→tr3→…→trn)(n＞2)，n为自然数，此关系栈开始于结点tr1，接着是依赖于tr1的tr2，然后是依赖于tr2的tr3，依次递进。从定义中可以看出同样的结点可能会出现于不同的DRPS中。另外，DRPS中的依赖关系具有可传递性，比如
(4)冗余依赖关系路径(Redundant Dependency Relationship Path):冗余依赖关系路径，可表示为RDRP。若edp＝<trs，tre>为DTRG中Ed的一个边，而DRPSq＝(tr1→tr2→...trn)(n＞2)为DRPS的一个实例。edp成为冗余依赖关系路径的充分必要条件是当且仅当满足下列条件：
(i)trs＝tr1 and tre＝tan；
而反之不可。
本实施例中，将并行区域设置成只有一个线程执行，本实施例的动态任务关系图DTRG如图5所示，首先任务实例Task0创建了两个子任务实例Task1和Task2，这两个任务实例进而又分别创建自己的子任务实例。Task1的两个子任务实例是：Task3和Task4，而Task2的两个子任务实例则分别是Task5和Task6。其中，Task0依赖于它所有的子孙任务实例，Task1依赖于它的子任务实例。依据DRPS以及RDRP的定义，可以推出下列结论：(Task3→Task1→Task0)以及(Task4→Task1→Task0)是DRPS的实例，而<Task3，Task0>(⑤),<Task4，Task0>(⑥)都是RDRP的实例，在图中使用符号来标识，是此图中可以移除的边。
基于上述定义，可以使用一个冗余剪裁算法(Redundancy Pruning Method，RPM)来有效移除图5中的RDRP。遍历图中所有的结点和边来寻找RDRP实例会造成巨大的开销，不太实际。因此，可以在理解具体编译器和运行时系统实现机制的基础上，依据产生冗余边的原因来使用相应的方法，通常可有效减少算法开销。OpenMP3.0标准中引起这种冗余边的原因通常是由于barrier和taskwait两种原语产生的同步依赖关系造成的，依据这个原因，可以将冗余剪裁算法实现如算法1如下：
(二)将任务性能监测模型应用于OpenMP规范中，实现基于包装库技术的性能监测分析
本实施例将前面所述的TMM模型应用到OpenMP具体实现规范之中，完成监测模型的实例化工作，探索性能监测模型的具体实现方法。并行编程模型充当了连接高性能计算机硬件系统和用户实际应用需求的桥梁。OpenMP作为多线程共享内存编程的事实上的标准，非常适合目前的多核架构，成为主要的编程规范。OpenMP 3.0引入任务结构来提高程序的运行效率并扩展应用范围，任务结构指的是通过task编译指导定义任务的功能与数据环境，它封装了可运行的代码及所需数据，从而增加了一个新的并行执行维度来完成计算。执行线程遇到任务结构时，就会生成一个显示任务，而遇到OpenMP传统规则结构块部分，则生成隐式任务。程序的功能单元都会以任务的形式出现。任务生成之后，会在线程上立即执行或者延迟执行，由调度机制与限制条件来决定。任务的执行还可以通过同步操作来加以控制。这样，OpenMP编程模型就从以线程为中心的模式转换为以任务为中心。以任务为中心的工作模式则可以方便地构造任意形式的计算单元，并且该单元不依赖于任何特定的线程。两者合理的匹配有效地改进了计算效率和应用范围，可以将其推广到主流的编译器和运行时系统之中，使任务模式在多核编程中迅速发展。
任务计算模式，将计算单元分为隐式和显式两种。显式任务又进一步包含两种类型，分别是绑定(tied)和非绑定(untied)两种类型，本实施例主要基于绑定类型的任务进行的。
TMM模型的另一个要求是监测系统不会影响源程序、编译器和运行时系统，包装库技术是一种较好的选择。包装库技术，又称为干涉(Interposition)技术，可以有效地收集与性能相关的信息而不依赖于源代码、特定的编译和链接。该技术的原理就是在应用程序和其关联的库函数之间放置一个新的或者不同的库函数。在具体实现中，中间的库函数也叫做包装库函数，往往与真实的库函数同名，从而达到包装真实函数的目的。并行程序并行操作通常以共享库的方式存在，使用包装库技术，可以跟踪函数调用，准确识别程序行为。另外，由于不在程序本身增加额外的处理操作，监测开销会比较小。
实现基于包装库技术的监测机制的过程首先深入理解和分析运行时系统和编译环境的运行机理，与前面的抽象模型相结合，进而完成TMM模型的实例化。OpenMP存在多种并行区域，任务又分为显式和隐式，隐式任务表现为传统的并行计算单元，而显式任务更多地表现为TMM模型中的任务特征，任务一旦被创建，OpenMP运行时系统将会面临两种选择：这些任务将被立即执行，或者放入任务池以待过后执行(这些都是由运行时系统的调度策略和源代码中的相关条件原语来确定的)。由于这两种类型的任务的执行方式不同，造成监测系统必须使用不同的监测方法。然而，作为系统整体，命名规则、采集的性能信息结构等，应该是一致且相互兼容的。另外，命名规则在形式表达上应具有实际意义。
(一)任务监测实现原理
OpenMP作为一种编程模型规范，并没有公布其实现细节，允许开发厂商或者研究人员自行实现。不同的编译器有其自己特定的具体实现方式。本实施例以典型编译器GUNCC作为实施例展开，来验证上述方法，包括1)分析GCC运行时库libgomp的任务执行机制，2)描述TMM模型中任务监测机制的实现原理。
(1)GCC OpenMP运行时库的任务执行机制
GCC运行时库的任务执行机制，如图6所示。图中使用了TMM模型中定义的一些组件从而有助于清晰简单地描述。整个系统分为三层：应用层、调度层和执行层，后两层包含于OpenMP运行时库。传统的OpenMP 2.5指导原语、环境变量独立于调度引擎，其工作单元(也就是隐式任务实例)绑定于线程池中线程组的特定线程并立即执行。而显示任务实例被创建之后，它将会进入任务控制引擎，处理相关数据并进入任务池中的任务队列。事实上，在GNU实现中，任务队列是由两个双向链表来维护的，分别是队列和树形链表。与此同时，同步原语、if语句都将被调度引擎读取。调度引擎还实时监测线程池。可调度的任务、可用的线程以及调度策略共同决定了任务实例的执行顺序。一旦一个任务实例被调度，其执行实体将被放入执行池中运行。GCC运行时系统的调度，只是实现了任务的绑定类型，任务调度会发生在显式任务的创建点、任务区域的最后一条指令后、taskwait区域以及隐式或显式barrier区域。调度又分为基于栈的方式(主要是处理当前执行任务在运行中的挂起操作，比如当前任务实例执行过程中遇到if条件为false的显式任务实例，显式任务实例立即执行，则当前任务实例放入线程栈中，等待新生成的任务实例运行完毕，又会将当前任务实例恢复并继续执行。再比如程序在任务调度点发生任务切换的操作，先前任务实例也会暂时放到线程栈中保存(挂起))和基于堆的方式(通过链表关系，选择需要执行的任务，根据调度策略由调度引擎确定，其中taskwait同步点根据树状链表调度当前任务实例的子任务，从最新创建的子任务实例开始，使用宽度优先的调度策略，而barrier同步点和空闲线程则利用队列链表使用先来先服务的调度策略)。由此可以推知任务挂起调度遵循的是栈的方式，利用线程的栈可以实现它的挂起和执行，这种行为使用传统方法就可完成监测工作。而显式任务在任务池中的等待执行调度则常使用堆的方法来完成，，任务实例的创建和其所指计算函数的执行是相分离的，这一部分是本发明方法的新颖性所在。
(2)基于模拟调度的任务监测机制
基于前述TMM模型中模拟调度的任务识别与跟踪方法，在监测库中仿照运行时库中的调度引擎研制一个模拟引擎，并维持一个任务队列组成模拟任务池。模拟任务池的组织方式也是与GCC运行时系统中的任务池相同，由两个双向链表组成，分别以任务队列和树形父子关系的方式来加以组织。其中每个任务实例都附加相关性能信息。运行原理如图7所示，关于任务实例监测流程描述如下：当显式任务实例被创建后，监测系统除记录创建信息并生成任务ID之外，就使用模拟任务控制引擎将产生的任务实例放入模拟任务池中，同时放入模拟任务池的还有封装在任务实例之中属性信息，属性信息包括任务ID，创建线程ID，父任务实例ID。然后将此任务实例放入OpenMP运行时库中的任务控制引擎,进而进入任务池开始正常的执行流程。在这个过程中，任务实际执行的函数体指针也被监测库包装。因此，在程序执行中，当任务实例被调度引擎调度运行，其实际执行函数被调用时，执行指针指向监测库的包装函数(这也是任务控制引擎完成的)。包装函数实际启动的是监测库中的模拟调度引擎，依据调度策略(基于先来先服务或宽度优先的树状调度策略)、限制条件和上下文环境来调度模拟任务池中保存的任务实例，由于调度条件一致，模拟调度引擎就与运行时系统中的调度结果一致。然后调用任务实例的执行函数，运行于执行层。与此同时，记录执行函数的入口和出口信息，并将附加的属性信息记录以区别任务实例。对于挂起操作的任务行为，GCC是使用栈的方式调度的，运行时系统运行完新调度的任务之后将会自动返回当前任务的执行状态。这种方法原理清晰，在理论上是可行的。但是由于GCC运行时的任务池使用锁的机制加以控制，如果再加入一个此类的模拟任务池，会加大系统开销，造成结果不准确，甚至影响系统运行。
(3)基于附加信息的任务监测机制
为了改进监测效率，减少开销，使用基于附加信息的任务识别与跟踪方法。通常，需要跟踪的任务实例的标识信息量很小，所以在监测库中将其附加于任务实例并置于运行时系统之中不会对系统运行造成明显的扰动。这种方法的实现原理如图8所示。在显式任务实例被创建之后(表现为GOMP_task函数被调用)，这时候监测库中同名的包装库函数将其截取，进行预处理操作，流程如下：
(1)通过函数参数解析和处理原始数据，这里对数据的处理操作是与运行时系统相一致的，从而保证任务实例所需数据的正确性，这样做的目的就是把运行时系统中对数据的操作转移至监测系统中，从而可以完成信息附加和解析的操作，而不影响程序的正确运行。
(2)监测系统根据预定义的规则产生任务标识，也就是任务ID，监测库中的任务标识与运行时系统内部使用的ID是不相同的，它体现出此任务所在的上下文环境。
(3)监测系统使用一个命名为TaskData的自定义的结构体类型，包括数据指针、函数指针、任务标识、父任务标识数据项。其中数据指针指向的就是前面预处理的数据，函数指针指向的是任务实例的运算函数体，父任务指的是调用GOMP_task函数并产生显式任务实例的工作单元。监测系统将前面处理完毕的原始数据放入这个结构体中，并调用libgomp库中函数GOMP_Task()，将其中的数据参数改为结构体TaskData，并将与数据处理相关的参数置空，这样就可以避免运行时系统再对任务实例的数据进行处理，使附加识别信息的任务实例参与到运行时系统的正常流程。
GCC运行时系统，仍旧遵循正常流程，任务实例需要被调度引擎调度执行。这时，真实运行函数仍然会被包装库中的函数所包装，将GOMP_Task()函数的第1个参数，即任务实例运行函数指针，设定为监测系统中的包装函数，监测系统截取任务的调用函数，解析数据获得识别信息，从而能够识别任务实例，并记录其相关行为操作。然后，实际执行函数体的原始数据环境被恢复并调用，在运行时系统执行层运行。具体流程描述如下：
(1)当GCC运行时系统调度任务实例运行，则其运行函数被调用，直接跳转至监测系统中对应的包装函数。
(2)包装函数首先解析数据环境，将结构体中的数据项分别提出来，这样就会获得原始的任务实例运行所需数据、运行函数的地址、任务ID以及其他相关信息。
(3)监测系统记录任务实例的运行信息，包括上下文环境信息、任务运行函数的开始和结束点的度量值。
(4)通过解析出来的运行函数地址以及原始数据，执行真正任务实例运行函数，在运行时系统执行层中完成任务实例的计算工作。
为了使监测流程更加清晰，这里再通过图9和图10来表现其调用关系。图9表明正常的任务实例调用方式，而图10则表现了对应的监测调用方式。这种方法使用起来对用户透明，充分利用任务创建函数的参数的特性，可以推断出其开销较小，是一种理想的适用于GCC运行时系统的任务识别与跟踪方法。
通过上述任务监测实现方法，既可以获得任务关联的度量信息，同时还可以测量传统的OpenMP运行信息，主要度量如表4所示。这些信息完全可以表现程序中任务的执行行为和相互关系，这样将这些信息使用TMM中的描述图表示，就可以更加清晰地展现性能信息，使用户更加深入地理解程序，从而展开下一步的程序优化工作。
表4基于任务监测的主要踪迹度量
本实施例提出的TMM模型，提炼出多核任务模型的共性特征，来研究性能监测问题。研究目标是不依赖源码、编译器和运行时环境，具有较强的适用范围。同时在较小的开销下可以详细测量任务运行信息，并通过任务描述图的方法来清晰展示任务实例的执行行为以及相互依赖关系，为并行程序的深刻理解提供支持。
虽然本发明已经参考特定的说明性实施例进行了描述，但是不会受到这些实施例的限定而仅仅受到附加权利要求的限定。本领域技术人员应当理解可以在不偏离本发明的保护范围和精神的情况下对本发明的实施例能够进行改动和修改。
Claims (4)
1.一种面向多核架构的任务监测、跟踪及识别方法，其特征在于包括如下步骤：
(1)建立任务监测模型Task Monitoring Model,TMM；
(2)将任务监测模型应用于多核编程模型中，实现基于包装库技术的监测跟踪方法；
所述步骤(1)中TMM模型包括：
(1-1)面向任务模式的运行时模型；
(1-2)任务监测机制；以及 (1-3)采用关系描述图的方式将任务运行及关联信息进行展示，从而自动识别；
所述面向任务模式的运行时模型(1-1)包括六个组件，分别为：
任务实例，表示为taskIns，是程序运行中的基本执行单元，任务实例拥有静态属性和操作行为，其中静态属性描述taskIns内在固有属性，表示任务实例的固有特性，形式化表达为taskIns.ID＝XXX；操作行为包括执行行为和行为状态，所述执行行为描述taskIns在其生命周期内的执行行为，形式化表达为taskIns.execute()；所述行为状态本质是一项静态属性，描述taskIns执行过程中各个阶段所处的状态，形式化表达为taskIns.state＝XXX；
任务池，以一定组织形式放置产生的taskIns，并囊括了其相关信息，包括数据环境和必要的静态属性，所述任务池在系统内存开辟部分空间存放所述相关信息，以链表的形式维持taskIns之间的关系；
线程池：任务调度的过程在线程池中寻找空闲线程，根据调度规则完成任务与执行线程的匹配，所述线程为任务的执行载体，是程序的实际执行单元，线程可以是操作系统概念中的用户级线程或系统线程中的一个或多个；
调度引擎：任务模式运行时系统的调度控制中心，其中调度单元就是任务实例taskIns，所述调度引擎实时关注任务池和线程池的情况，根据调度策略、上下文环境以及限制条件来调度匹配任务实例taskIns和线程，使两者结合执行，所述调度策略依赖编译器和运行时系统的实现机制；
任务控制引擎：负责任务实例taskIns预处理操作，进行数据环境的处理，并将任务实例放入任务池等待调度执行；
执行池：用来执行任务实例，一旦有任务实例进入执行池，此任务实例的计算操作就会被立即执行；
所述步骤(2)将任务监测模型应用于多核编程模型中，实现基于包装库技术的监测跟踪方法包括：分析GCC OpenMP运行时库的任务执行机制；基于模拟调度的OpenMP任务监测机制；以及基于附加信息的OpenMP任务监测机制，其中所述GCC OpenMP运行时库的任务执行机制包括：任务调度层和执行层包含于OpenMP运行时库，在GNU实现中，任务队列是由两个双向链表来维护的，分别是队列和树形链表，同时同步原语、if语句都将被调度引擎读取，所述调度引擎实时监测线程池，可调度的任务、可用的线程以及调度策略共同决定了任务实例的执行顺序，一旦一个任务实例被调度，其执行实体将被放入执行池中运行；所述基于模拟调度的OpenMP任务监测机制包括：在监测库中仿照运行时系统中的调度引擎研制一个模拟调度引擎，并维持一个任务队列组成模拟任务池，模拟任务池的组织方式由两个双向链表组成，分别以任务队列和树形父子关系的方式来加以组织，其中每个任务实例都附加相关性能信息，所述任务监测的流程为：当显式任务实例被创建后，监测系统除记录创建信息并生成任务ID之外，就使用模拟任务控制引擎将产生的任务实例放入模拟任务池中，同时放入模拟任务池的还有塑封在任务实例之中属性信息，属性信息包括任务ID、创建线程ID以及父任务实例ID；然后将此任务实例放入OpenMP运行时库中的任务控制引擎,进而进入任务池开始正常的执行流程，在这个过程中，实际执行的函数体指针也被监测库包装，在程序执行中，当任务实例被调度引擎调度运行，其实际执行函数被调用时，执行指针指向监测库的包装函数，包装函数实际启动的是监测包装库中的模拟调度引擎，依据调度策略、限制条件和上下文环境来调度模拟任务池中保存的任务实例，调度策略即先来先服务和宽度优先的树状调度策略，由于调度条件一致，模拟调度引擎与运行时系统中的调度结果一致，模拟调度引擎所附加的静态属性信息就会被监测系统记录，匹配此任务实例的执行行为，最后调用任务实例的真正执行函数，运行于执行层，与此同时，记录执行函数的入口和出口信息，并将附加的属性信息记录以区别任务实例，对于挂起操作的任务行为，GCC是使用栈的方式调度的，运行时系统运行完新调度的任务之后将会自动返回当前任务的执行状态；所述基于附加信息的OpenMP任务监测机制包括：在显式任务实例被创建之后，监测库中同名的包装库函数将其截取，进行预处理操作，流程包括：通过函数参数解析和处理原始数据，对数据的处理操作是与运行时系统相一致的；监测系统根据预定义的规则产生任务标识；监测系统使用一个命名为TaskData的自定义的结构体类型，结构体类型包括数据指针、函数指针、任务标识和父任务标识，监测系统将前面处理完毕的原始数据放入这个结构体中，并调用系统动态库中的函数，将其中的数据参数改为结构体TaskData，并将与数据处理相关的参数置空，使附加识别信息的任务实例参与到运行时系统的正常流程。
2.根据权利要求1所述的一种面向多核架构的任务监测、跟踪及识别方法，其特征在于所述(1-2)的任务监测机制包括面向任务实例的状态转换监测以及基于任务的应用程序的监测，所述面向任务实例的状态转换监测包括：在taskIns状态变换前后记录相应的度量值，taskIns在“WAIT”状态和“PEND”状态可能会发生时间延迟和空间维度处于不同线程的转换，监测机制需要完成任务实例的识别过程，并将任务实例与监测度量匹配，完整记录各个taskIns执行周期的行为，在进入这两个状态之前对任务实例进行预处理，当其状态从“WAIT”和“PEND”转换到“RUN”时，先进行任务实例的解析，从而识别并正确反映任务实例的执行行为；所述基于任务的应用程序监测包括：所述监测所使用的监测系统处于应用程序与运行时系统之间并以共享库的形式存在，包括函数跟踪、信息测量、信息记录，所述监测分别依赖关联的静态信息，所述静态信息包括监测函数列表、踪迹和/或轮廓的测量方式、通信协议和存储格式中的一个或多个。
3.根据权利要求2所述的一种面向多核架构的任务监测、跟踪 及识别方法，其特征在于所述(1-2)任务监测机制包括监测系统的任务识别，所述监测系统的任务识别方法包括：基于模拟调度的任务跟踪识别方法和基于附加信息的任务跟踪识别方法，其中，所述基于模拟调度的任务跟踪识别方法包括：在监测系统中模拟运行时系统模型构建一个调度引擎，与运行时系统的调度策略一致，当任务实例放入任务池中时，包括初始分配或者中途挂起两种情形，监测系统也将任务实例连同需要记录的度量，即任务实例的部分静态属性保存在一个模拟任务池中，运行时系统的调度引擎根据调度策略、上下文环境以及限制条件来调度执行的任务实例时，监测系统同时调用模拟调度引擎，使用同样的机制在模拟任务池中选择任务实例，从而监测系统就可监测运行时系统中任务实例的执行行为，并将模拟任务池中调出的任务实例对应的属性信息与之匹配，从而完成任务实例执行生命周期中的识别和信息记录工作；所述基于附加信息的任务跟踪识别方法包括：监测系统在任务实例进入运行时系统的任务池之前，将识别信息，即关联的静态属性作为附加的信息放入任务实例之中，随着任务实例在任务池中等待直至被调度执行，此时监测系统首先解析此任务实例，获取识别信息，然后开始执行，同时记录运行状态，并与解析出的识别信息相关联，从而完成监测工作。
4.根据权利要求1所述的一种面向多核架构的任务监测、跟踪及识别方法，其特征在于所述(1-3)采用关系描述图的方式将任务运行及关联信息进行展示包括两种描述图，即任务时间线图与动态任务关系图，所述任务时间线图表示为TTG，伴随着时间维度的推进，不同线程及其上运行的任务实例在空间维度上的执行行为，包括运行次序、运行间隔、交互关系，交互关系表示在任务时间线图中表现任务实例之间的父子创建关系；所述动态任务关系图表示为DTRG，用于描述程序运行中任务实例之间的关系，其中，父子关系和依赖关系在图中使用不同的形状加以区分，使用不同颜色表示不同的线程，并附加相关的轮廓信息。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810421646.5A CN108647134B (zh) | 2018-05-04 | 2018-05-04 | 一种面向多核架构的任务监测、跟踪及识别方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810421646.5A CN108647134B (zh) | 2018-05-04 | 2018-05-04 | 一种面向多核架构的任务监测、跟踪及识别方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN108647134A CN108647134A (zh) | 2018-10-12 |
| CN108647134B true CN108647134B (zh) | 2019-04-12 |
Family
ID=63749391
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201810421646.5A Active CN108647134B (zh) | 2018-05-04 | 2018-05-04 | 一种面向多核架构的任务监测、跟踪及识别方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN108647134B (zh) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109753354B (zh) * | 2018-11-26 | 2024-07-05 | 平安科技（深圳）有限公司 | 基于多线程的流媒体任务的处理方法、装置及计算机设备 |
| CN112486502A (zh) * | 2020-11-30 | 2021-03-12 | 京东方科技集团股份有限公司 | 分布式任务的部署方法、装置、计算机设备和存储介质 |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5978583A (en) * | 1995-08-07 | 1999-11-02 | International Business Machines Corp. | Method for resource control in parallel environments using program organization and run-time support |
| US8850404B2 (en) * | 2009-12-23 | 2014-09-30 | Intel Corporation | Relational modeling for performance analysis of multi-core processors using virtual tasks |
| CN101887367B (zh) * | 2010-06-22 | 2013-06-19 | 天津大学 | 一种多级并行化编程方法 |
| CN103051509B (zh) * | 2012-08-03 | 2015-04-22 | 北京航空航天大学 | 一种基于树状架构的初始化方法 |
| CN104765613B (zh) * | 2015-04-21 | 2017-09-12 | 华中科技大学 | 一种虚拟化环境下面向任务并行编程模型的优化方法 |
-
2018
- 2018-05-04 CN CN201810421646.5A patent/CN108647134B/zh active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN108647134A (zh) | 2018-10-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP3465424B1 (en) | Systems and methods for creating model adaptors | |
| Abbott et al. | Model-based software synthesis | |
| Barbacci et al. | Programming at the processor-memory-switch level | |
| CN108647134B (zh) | 一种面向多核架构的任务监测、跟踪及识别方法 | |
| Lutati et al. | Agentzero: A framework for simulating and evaluating multi-agent algorithms | |
| Liu | Simulus: easy breezy simulation in python | |
| Halstead Jr | An assessment of Multilisp: Lessons from experience | |
| Schlatte et al. | Release the beasts: When formal methods meet real world data | |
| CN115983047A (zh) | 一种适用于多图形接口的跨平台的仿真系统 | |
| Björklund et al. | Towards efficient code synthesis from statecharts | |
| Sampson | Process-oriented patterns for concurrent software engineering | |
| Yang et al. | Multi-task Ada code generation from synchronous dataflow programs on multi-core: Approach and industrial study | |
| Fornaia et al. | An ao system for oo-gpu programming | |
| Kocı et al. | Modeling System Requirements Using Use Cases and Petri Nets | |
| Tanwar | Hands-On Parallel Programming with C# 8 and. NET Core 3: Build solid enterprise software using task parallelism and multithreading | |
| Björklund et al. | A unified approach to code generation from behavioral diagrams | |
| Evans | Verifying QThreads: Is model checking viable for user level tasking runtimes? | |
| Wulf | Efficient Engineering and Execution of Pipe-and-Filter Architectures | |
| Penczek et al. | A data-flow based coordination approach to concurrent software engineering | |
| Moreno et al. | Petri nets and Java. Real-Time Control of a flexible manufacturing cell | |
| Mohan et al. | Temporal analysis for adapting concurrent applications to embedded systems | |
| Kim | Parallax: an implementation of ELGDF (Extended Large Grain Data Flow) | |
| Serbânescu | Software development by abstract behavioural specification | |
| Batko et al. | Actor Model of a New Functional Language-Anemone | |
| CN118051296A (zh) | 一种实现Modelica模型并行或并发仿真的方法、装置及设备 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |