任务调度方法及装置与流程

本公开涉及计算机任务调度领域，尤其涉及任务调度方法及装置。

背景技术：

现有软件设计中，为了实现某种功能，通常会将软件流程从整体上划分为多个任务，各个任务之间顺序或并发执行。当多个任务并发共同完成一个任务时，整个流程运转起来之后，整个流程的执行时长取决于耗时最长的任务的执行时间。在这种情况下，如果某一个任务耗时很长，则会导致整个系统运行速度慢。

另外，在上述流程中，前一个任务的输出结果是后一个任务的输入数据，现在通常的做法是：针对相邻的两个任务分别开启一个线程，前一个线程的输出结果放入一个队列中，然后，通知后一个线程对这些数据进行获取，其基本模型可参照图1。但是，上述处理方式会使得整体处理流程的流畅性不佳，原因是：两个线程对同一个队列进行操作，一个进入数据的写入，一个进行数据的读取，但是由于队列本身的特性，队列会在每个线程访问过程中加锁，也就是，前一个线程和后一个线程并不能同时操作队列，因此，数据的写入和读取不能同时进行。

技术实现要素：

本公开实施例提供一种任务调度方法及装置，本公开能够解决本公开能够解决某一个任务耗时很长，会导致整个系统运行速度慢的问题。所述技术方案如下：

根据本公开实施例的第一方面，提供一种任务调度方法，该方法包括：

检测当前任务的执行时长，判断当前任务的执行时长是否超过预设阈值；

如果当前任务的执行时长超过预设阈值，则将所述当前任务拆分为多个子任务；

按照流水线方式依次调度所述多个子任务；其中，每个子任务的执行时长小于所示所述当前任务的执行时长。

在一个实施例中，将所述当前任务拆分为多个子任务包括：

按照当前任务的属性信息将所述当前任务拆分为多个子任务；其中所述属性信息包括多个子功能信息，所述多个子任务和所述多个子功能一一对应。

在一个实施例中，将所述当前任务拆分为多个子任务之后，所述方法还包括：

在相邻的两个子任务之间生成任务队列，使得相邻的两个子任务中的前一个子任务对该任务队列进行写操作，后一个子任务对该任务队列进行读操作。

在一个实施例中，多个子任务通过多线程完成，所述按照流水线方式依次调度所述多个子任务包括：

调度前一个子任务的线程输出作为后一个子任务的线程输入。

在一个实施例中，当前任务为图像处理任务，所述多个子任务包括：分包子任务、协议封装子任务和加密子任务。

根据本公开实施例的第二方面，提供一种任务调度装置，该装置包括：

判断模块，用于检测当前任务的执行时长，判断当前任务的执行时长是否超过预设阈值；

拆分模块，用于如果当前任务的执行时长超过预设阈值，则将所述当前任务拆分为多个子任务；

调度模块，用于按照流水线方式依次调度所述多个子任务；其中，每个子任务的执行时长小于所示所述当前任务的执行时长。

在一个实施例中，拆分模块具体用于：

按照当前任务的属性信息将所述当前任务拆分为多个子任务；其中所述属性信息包括多个子功能信息，所述多个子任务和所述多个子功能一一对应。

在一个实施例中，上述装置还包括生成模块，用于在所述将所述当前任务拆分为多个子任务之后，在相邻的两个子任务之间生成任务队列，使得相邻的两个子任务中的前一个子任务对该任务队列进行写操作，后一个子任务对该任务队列进行读操作。

在一个实施例中，多个子任务通过多线程完成，所述调度模块具体用于：

调度前一个子任务的线程输出作为后一个子任务的线程输入。

在一个实施例中，当前任务为图像处理任务，所述多个子任务包括：分包子任务、协议封装子任务和加密子任务。

本公开提出了一种流水线式的任务调度方案，一方面能够将处理时长超过预设阈值的任务拆分为多个子任务，从而使得整个任务的执行时长满足系统需求，另一方面，由于能够在拆分后相邻的两个子任务之间添加能够同时进行读写操作的队列，这使得各个子任务之间执行时的流畅程度大幅度提高，从而进一步缩短任务执行时的时长。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

图1是本公开实施例提供的背景技术数据队列示意图；

图2是本公开实施例提供的一种任务调度方法的流程图；

图3是本公开实施例提供的一种任务调度方法的流程图；

图4是本公开实施例提供的一种数据队列示意图；

图5是本公开实施例提供的一种数据队列示意图；

图6是本公开实施例提供的一种任务调度装置结构图；

图7是本公开实施例提供的一种任务调度装置结构图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

图2是本公开实施例提供的一种任务调度方法，如图2所示的任务调度方法包括以下步骤：

步骤201、检测当前任务的执行时长，判断当前任务的执行时长是否超过预设阈值；

在任务执行过程中，可以对当前任务的执行时间进行监测，以确定当前任务的执行时长是否超过预设阈值；该预设阈值可以是根据需要所设置的满足系统性能需求的一个时间值，实际应用中，该值可以在系统中进行设置和修改。

步骤202、如果当前任务的执行时长超过预设阈值，则将所述当前任务拆分为多个子任务；

一般的一个任务可划分为多个子任务。当一个任务执行时间过长，不满足系统性能要求时，可对任务进行拆分，拆分成一道道工序，使用多线程完成。

在一个实施例中，将所述当前任务拆分为多个子任务包括：按照当前任务的属性信息将所述当前任务拆分为多个子任务；其中所述属性信息包括多个子功能信息，所述多个子任务和所述多个子功能一一对应。

具体的，对于任务的拆分根据处理逻辑上的关联性来进行拆分。一个子任务对应一个子功能，其中，子功能的划分是按照逻辑关联性划分的。

另外，对于任务的拆分可以进行多次，具体按照如下方式进行：

按照处理逻辑对任务进行第一次拆分；

判断拆分后的各个子任务的运行时长是否都小于等于系统预设时长阈值；

如果有大于预设时长阈值的子任务，则对这些子任务进行第二次拆分，并在拆分后，判断第二次拆分后得到的各个子任务是否都小于等于系统预设时长阈值；如果没有，则结束拆分；

如果是，则继续拆分直到拆分得到的每一个子任务的运行时长都小于等于系统预设时长阈值。而最终系统的运行时长则可以认为等于拆分后得到的各个子任务的运行时长中的最大值。

比如，以图像处理来说，假设一个图像处理任务按照子功能分为：分包、协议封装、加密这三个步骤，约需要30ms。此时，由于系统需求是将该任务的处理时长保证在15s之内，则经统计以上三个步骤的执行的平均时间依次为8ms、10ms、12ms。则可以将该图像处理任务拆分为：分包、协议封装和加密这三个子任务。则当这三个子任务组成的流水线运行起来后，该任务的运行总时长约为12ms左右完成，从而，大大缩减了处理时长，并满足了系统需求。

步骤203、按照流水线方式依次调度所述多个子任务；其中，每个子任务的执行时长小于所示所述当前任务的执行时长。

在一个实施例中，多个子任务通过多线程完成。

所述按照流水线方式依次调度所述多个子任务包括：

调度前一个子任务的线程输出作为后一个子任务的线程输入。

比如，将一个任务拆分为n个子任务，各个子任务之间以流水线方式运作，当整个流水线运作起来后，该任务的处理时间t变为：

t＝max{t1，t2，…tn}；

其中，tn为所拆分的子任务n(即工序n)的执行时间。

按照上述方式拆分后，若t仍不满足系统要求，则选出其中任务执行时间最长的子任务继续拆分，直到满足系统要求为止。

在上述实施例中，所述当前任务可以为图像处理任务，所述多个子任务包括：分包子任务、协议封装子任务和加密子任务。

图2是本公开实施例提供的一种任务调度方法，如图2所示的任务调度方法包括以下步骤：

步骤301、检测当前任务的执行时长，判断当前任务的执行时长是否超过预设阈值；

步骤302、如果当前任务的执行时长超过预设阈值，则将所述当前任务拆分为多个子任务；

步骤303、在相邻的两个子任务之间生成任务队列，使得相邻的两个子任务中的前一个子任务对该任务队列进行写操作，后一个子任务对该任务队列进行读操作；

优选的，在本公开实施例中，将任务拆分为多个子任务之后，为了提高相邻的两个子任务之间执行时的流畅性，本公开实施例还设计实现了一种可以同时进行写入和读取操作的任务队列；并在任务拆分后，在相邻的两个子任务之间生成这样一个任务队列，使得相邻的两个子任务中的前一个子任务对该任务队列进行写操作，后一个子任务对该任务队列进行读操作。

下面对本公开实施例设计实现的这种可以同时进行写入和读取的任务队列xqueue进行介绍。该任务队列的基本结构图可参照图4。

xqueue为一个循环缓冲队列，其原理图可参照图5，图5中有两个游标，分别指示r端读，w端写。如下图所示：

xqueue设计遵循以下原则：

a、当写入n个数据时，在游标w位置后写入n个数据，写入后，游标w后移n个位置。游标w不能超过游标r。写入函数后返回实际写入的数据个数。

b、当读出n个数据时，在游标r位置后读出n个数据，读出后，游标r后移n个位置。游标r不能超过游标w。读取函数返回实际读出的数据个数。

c、当r<w时，触发可读事件。

子任务实现具体如下：

为了节省内存空间，xqueue中并不放任务数据，而是存放的任务数据的地址，这样每个数据占用一个地址的大小空间。

当有数据需要处理时，将数据转化为上述实施例中的dataobject结构，向xqueue写入dataobject结构地址。

当xqueue中有数据时，触发可读事件，任务处理线程从xqueue中读取数据。如可一次读取8个数据，这样就可以控制每次处理数据的最大数量为8，防止某个线程占用cpu的时间过长。读出数据后依次对数据进行处理。

使用该方式可以无锁的将任务从一个线程投放到另一个线程中。

比如拆包工序中，添加数据线程将音视频帧数据的dataobject结构体放入xqueue中，处理数据线程会收到xqueue读信号，然后读出数据地址，进行处理。

步骤304、按照流水线方式依次调度所述多个子任务；其中，每个子任务的执行时长小于所示所述当前任务的执行时长。

步骤301、302和步骤304和上一实施例相同，在此不再赘述。

本设计特别适用于视频图像处理这种高重复性的任务，下面以以具体的工序(即上述实施例中的子任务)设计为例对本公开实施例做详细的说明。

首先是数据实现可以如下：

数据在不同工序里字段的描述不同，以分包工序为例，处理前数据序列号为音视频帧的序列号，处理后为包序列号。处理前数据和数据长度分别为音视频帧数据和数据长度，处理后为包数据和包数据长度。一般的视频帧比较长，为了网络传输一个视频帧会被拆分成多个包，送入到下一道工序中。

然后，工序实现可以如下：

其中，数据输入函数taskinput为该道工序的数据送入函数。数据为异步处理。将数据送入任务队列通知处理线程然后返回。处理线程收到通知后由数据处理函数dealtask对数据进行处理，区别于由具体工序实现的函数taskprocess。

上述类为工序的基类，每个具体的工序需要由其派生，并且实现其对应工序具体的数据处理函数taskprocess和数据结果输出函数taskoutput。在工序具体的数据处理函数中会对dataobject进行改写。当数据处理完毕，由数据结果输出函数taskoutput送出。若设置了下一道工序会自动送入下一道工序。若没有，则可以通过数据结果输出函数taskoutput获取最终的处理结果。

如分包工序可以做如下设计：

分包工序类packetpipeline继承pipeline，用户可以根据自身需求实现具体的分包处理函数和结果输出函数。

classpacketpipeline:publicpipeline

{

public:

inttaskprocess(dataobject*object)override；//分包处理

inttaskoutput(dataobject*object)override；//结果输出

}

本设计可以很容易实现工序的扩展，只需要派生pipeline即可实现一道工序，通过setnextpipeline函数即可实现工序的串联，易于扩展使用，代码复用性高。如需要在分包工序后再添加协议封装工序，只需要继承实现相应的协议封装函数和结果输出函数，然后将分包工序的下一个工序设置成协议封装工序即可。

本公开实施例提供一种任务调度装置，如图6所示的任务调度装置60包括判断模块601、拆分模块602和调度模块603，其中，判断模块601用于检测当前任务的执行时长，判断当前任务的执行时长是否超过预设阈值；拆分模块602用于如果当前任务的执行时长超过预设阈值，则将所述当前任务拆分为多个子任务；调度模块603用于按照流水线方式依次调度所述多个子任务；其中，每个子任务的执行时长小于所示所述当前任务的执行时长。

在一个实施例中，拆分模块602具体用于按照当前任务的功能子模块将所述当前任务拆分为多个子任务；其中每个子任务对应多个功能子模块。

在一个实施例中，所述多个子任务通过多线程完成，调度模块603具体用于：调度前一个子任务的线程输出作为后一个子任务的线程输入。

在一个实施例中，当前任务为图像处理任务，所述多个子任务包括：分包子任务、协议封装子任务和加密子任务。

本公开实施例提供一种任务调度装置，如图7所示的任务调度装置70包括判断模块701、拆分模块702、生成模块703和调度模块703，其中生成模块703用于在所述将所述当前任务拆分为多个子任务之后，在相邻的两个子任务之间生成任务队列，使得相邻的两个子任务中的前一个子任务对该任务队列进行写操作，而后一个子任务对该任务队列进行读操作。

基于上述图2和图3对应的实施例中所描述的任务调度方法，本公开实施例还提供一种计算机可读存储介质，例如，非临时性计算机可读存储介质可以是只读存储器(英文：readonlymemory，rom)、随机存取存储器(英文：randomaccessmemory，ram)、cd-rom、磁带、软盘和光数据存储装置等。该存储介质上存储有计算机指令，用于执行上述图2和图3对应的实施例中所描述的任务调度方法，此处不再赘述。

本领域技术人员在考虑说明书及实践这里公开的公开后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。