CN102467415A - 一种业务面任务处理方法及设备 - Google Patents

Abstract

本发明公开了一种业务面任务处理方法及设备，包括：确定需处理的业务面任务；将所述业务面任务分拆为若干任务块；按所述业务面任务的执行流程确定各任务块的执行顺序；为各任务块分配标识，各任务块标识顺序与各任务块的执行顺序一致；将各任务块分配给CPU；根据各任务块的标识顺序在相应的CPU上执行任务块。本发明符合现代软件开发的模块化设计理念，且相对于传统子任务的方法而言，功能更加明确而具体，便于开发、管理、以及后期维护。

Description

一种业务面任务处理方法及设备

技术领域

本发明涉及移动通信处理技术，特别涉及一种业务面任务处理方法及设备。

背景技术

随着信息时代的到来，各种复杂多样的应用需求对处理器的性能要求也越来越高。传统的通过纯粹提升频率来提升处理器性能的方法，由于遭遇功耗和散热问题而陷入绝境。与单核处理器相比，多核处理器能够在较低的频率下完成更高的工作负载，具有高性能、低功耗的明显优势，正逐渐取代传统的单核处理器成为市场的主流。

在这种背景下，如何充分利用多核处理器的并发处理特性，提高***整体性能，最大程度地发挥多核处理器的多个核在业务处理方面的效能，就成为了多核软件开发过程中一个迫切需要解决的问题。

现有多核开发理论认为：针对多核处理器具有天然的并行特性，在软件架构上需要彻底打破原有的串行编程思想，完成从传统的单核处理器架构下的串行编程到并行编程的转变，尽量避免互斥，减少串行处理，均衡地在多个核之间分配任务，避免对共享资源的争夺，尽可能地并行工作。

图1为单核CPU下的任务拆分到多核CPU下的多个子任务的示意图，现代多核开发技术的基本方法，一般采用如图1所示的任务拆分方法，即：将单核处理器下的报文处理任务按照任务的特性，拆分成一个或多个子任务，每个子任务完成整个任务中一部分功能。

按照这一开发思想，在实际编码设计中，如何合理的拆解任务，则成为了多核开发首先要解决的问题。对软件设计者而言，这就要求其在设计伊始就充分地了解任务的特点，把握分解出的各个子任务的任务特性是什么、任务量有多大，以便在多个核之间均衡的分配任务，实现多核性能的最大化。考虑到理想与现实的差别，以及对新兴技术的把握程度，这一拆解要求对软件设计者来说往往过于苛刻。

现有技术至少有以下不足：

1、在设计伊始，软件设计者首先需将一个完整的任务拆分为多个子任务，每个子任务按照一定规则部署在不同的核上；但对于如何来拆分这些子任务没有一个参考标准。

2、软件设计者必须对上述每个子任务的性能有充分的把握，例如：子任务有何特点，任务量有多大，等等；这对于某些软件设计者来说要求太过苛刻。

3、当根据最初设计的子任务部署完成代码开发后，一旦出现某个或某类核成为性能瓶颈，此时必然要重新调整任务部署，甚至可能重新拆分子任务，修改函数调用关系，重新进行整合测试，存在诸多的重复劳动。经验表明，这种后期引入的设计调整代价巨大。

4、子任务内的模块之间采用函数调用，对栈的深度需求较大，可能引起单核的内存资源紧张。

发明内容

本发明所解决的技术问题在于提供了一种业务面任务在多核情况下的处理方法及设备。

本发明实施例中提供了一种业务面任务处理方法，包括如下步骤：

确定需处理的业务面任务；

将所述业务面任务分拆为若干任务块；

按所述业务面任务的执行流程确定各任务块的执行顺序；

为各任务块分配标识，各任务块标识顺序与各任务块的执行顺序一致；

将各任务块分配给CPU；

根据各任务块的标识顺序在相应的CPU上执行任务块。

本发明实施例中提供了一种业务面任务处理设备，包括：

任务确定单元，用于确定需处理的业务面任务；

拆分单元，用于将所述业务面任务分拆为若干任务块；

顺序确定单元，用于按所述业务面任务的执行流程确定各任务块的执行顺序；

标识单元，用于为各任务块分配标识，各任务块标识顺序与各任务块的执行顺序一致；

分配单元，用于将各任务块分配给CPU；

执行单元，用于根据各任务块的标识顺序在相应的CPU上执行任务块。

本发明的有益效果如下：

由于采用了BID(即任务块标识BlockID，后文均采用该简称)的手段，因此本发明实施例提供的技术方案符合现代软件开发的模块化设计理念，且相对于传统子任务的方法而言，BID模块的功能更加明确而具体，便于开发、管理、以及后期维护。

附图说明

图1为背景技术中单核CPU下的任务拆分到多核CPU下的多个子任务的示意图；

图2为本发明实施例中业务面任务处理方法实施流程示意图；

图3为本发明实施例中多核下的控制面与业务面分离示意图；

图4为本发明实施例中单核CPU下的任务拆分到多核CPU下的多个BID示意图；

图5为本发明实施例中BID处理模块在核间的配置调整示意图；

图6为本发明实施例中BID与功能单元组的关系示意图；

图7为本发明实施例中调整后的BID与功能单元组的关系示意图；

图8为本发明实施例中功能单元组模块示意图；

图9为本发明实施例中业务面任务处理设备结构示意图。

具体实施方式

下面结合附图对本发明的具体实施方式进行说明。

图2为业务面任务处理方法实施流程示意图，如图所示，可以包括如下步骤：

步骤201、确定需处理的业务面任务；

步骤202、将所述业务面任务分拆为若干任务块；

步骤203、按所述业务面任务的执行流程确定各任务块的执行顺序；

步骤204、为各任务块分配标识，各任务块标识顺序与各任务块的执行顺序一致；

步骤205、将各任务块分配给CPU；

步骤206、根据各任务块的标识顺序在相应的CPU上执行任务块。

实施中，在某些多核处理器上对应的是虚拟处理器VCPU，本申请在描述时对此不进行区分。

在现代高速网络设备中，为了确保业务面的数据流不影响控制面的处理，一般对控制面与业务面的处理进行分离。在单核处理器时代，这体现为控制面与业务面分别采用各自的任务独立运行；在多核处理器时代，则通过分配一个或多个专用控制核来实现控制面与业务面的分离。并采用这些专用控制核来完成控制面的所有处理，如芯片管理、各种数据表的配置、流量查询等。

图3为多核下的控制面与业务面分离示意图，如图3所示，控制面的所有核联合起来构成控制单元组。控制单元组的每个核均独立完成一项完整的任务，处理相对简单。本发明实施例提供的技术方案将以业务面的处理来进行说明。

实施中，可以将业务面任务分拆为若干任务块。图4为单核CPU下的任务拆分到多核CPU下的多个BID示意图，如图所示，与传统多核开发技术中将业务面的处理划分成多个子任务的方式不同，本发明实施例中将根据业务面处理的流水线特性，将该流水线作业划分成粒度更细的、按序作业的多个BID处理模块(Block ID，简称BID)，这些BID之间采用报文消息句柄的方式进行报文传输。

具体的，Block也即分拆后的任务块，在分拆任务块时，任务块的划分依据可以是：一个任务块是能自成模块的一段处理代码，一个任务块可以主要包括：负责对输入的报文进行解包/封包等处理，然后再输出报文及其相关句柄等信息。

实施中，在将各任务块分配给CPU时，可以根据CPU的处理能力确定分配给该CPU的任务块数量。图5为BID处理模块在核间的配置调整示意图，如图所示，在流水线上任意相邻的多个BID模块可以根据性能需要随意组合到同一个核上，也可以分别部署在相邻的不同核上。如图5所示，图5.a配置中的核1上顺序包含了BID1模块和BID2模块，当该配置下的核1的性能不足引起瓶颈时，可以灵活的将核1中BID2模块后移到下一级处理核(即核2)上，如图5.b所示。对于其他的核若存在瓶颈问题，可采用类似处理。如此类推。

实施中，在将各任务块分配给CPU时，还可以进一步包括：将CPU分组，同一组的CPU并行执行同样的任务块。

具体的，在实际的多核软件设计中，为了进一步提升并发处理能力，可以将业务流水线的完整作业通过BID模块的方式，划分成多个功能单元组，每个功能单元组中可包含一个或多个核；同一个功能单元组中的多个核之间是完全并发处理，这意味着这些核均包含相同的BID模块，并完成相同的处理功能。

图6为BID与功能单元组的关系示意图，如图6所示，将完整的处理任务划分成了m个BID处理模块，然后以这m个BID处理模块作为划分粒度，进一步划分成M个阶段，每个阶段对应一个子任务，每个子任务由一个或多个BID处理模块组成；而完成同一个子任务的多个核则构成一个功能单元组。

图7为调整后的BID与功能单元组的关系示意图，实施中还可以通过调整BID模块的部署来调整各级功能单元组的功能，如图7所示，将原来的M级单元组调整成N级单元组(N≥1)。特别地，当N＝1时，所有核均执行同一个任务。

实施中，还可以使同一组的CPU在同一时间内访问不同的共享资源。为了充分利用多核的并行特性，功能单元组内的多个核之间不能同时访问共享资源，可以通过一些分发策略设计等方法来实现。例如，如果在用户业务报文的处理过程中，要对用户的某个特有资源进行修改操作，则可在上一级功能单元组的分发模块或者报文分发引擎中通过一定的配置或算法实现，来确保同一个用户的数据报文始终进入同一个核，这样，既避免了资源竞争的发生，实现了真正的核间并行处理，同时也有报文保序的效果。

实施中，对于相邻的功能单元组之间的通信，一般有共享内存FIFO(FirstIn First Out，先进先出)、RING(环)或者其他硬件机制的等多种方式，软件设计者可以自由选择一种或多种方式的组合。

实施中，根据各任务块的标识顺序在相应的CPU上执行任务块，可以包括：

1、在CPU接收到执行任务块的指示时，确定任务块标识；

2、在任务块标识与CPU对应时执行任务块，并且在每一任务块执行结束前将需要执行的下一任务块的标识添加进任务块；

3、在CPU执行完与该CPU标识对应的任务块后，按标识顺序将相应的任务块发送给执行下一任务块的CPU。

实施中，在第2步，在任务块执行结束前，在任务块内部设置NextBID；因为按照业务面任务的执行流程，在一个任务块执行完后，其下一个任务块可能存在多个分支，即：NextBID可能是BID3，也可能是BID4。这样就需要将标识添加进去以便作为执行依据。

对于一个CPU来说，其执行的依据是任务块的标识是否与自己对应，也即是否是需要自己执行的，这样在第3步，执行完与该CPU标识对应的任务块后就需将相应的任务块发送到相应的CPU去执行。

以图8的模块为例，SOURCE模块是每个CPU上的接收模块；SINK模块是每个CPU上的发送模块；每个CPU通过SOURCE模块接收数据，然后交给BID(m-2)--＞BID(m-1)--＞BIDm，然后当目标CPU ID(即NextVcpuID)不是本CPU ID时，就通过SINK模块发给NextVcpuID。

具体实施中，以分组的实施方式为例，为了接收来自前一级功能单元组的报文，并在处理完后发送给下一级功能单元组中的某个核，以及应对报文处理过程中的异常，在每个功能单元组所对应的子任务中还可以进一步包含三个处理模块：SOURCE模块(即流入模块)、SINK模块(即流出模块)和BID_DROP模块(即报文丢弃模块)。图8为功能单元组模块示意图，如图所示，其中：

1、SOURCE模块可以主要负责接收来自入接口或前一级功能单元组的报文，接收策略可以有：调度算法扫描、中断通知等。此时，SOURCE模块可以根据接收到的报文附属信息设置相关属性参数；实施中，可以方便的扩展SOURCE模块的功能，例如实现定时器是否超时等状态驱动功能，并根据检查结果设置相应的NextBID(即：下一个BID)等；

2、SINK模块可以主要负责将当前核处理后的报文发送给下一级功能单元组的某个核(该目标核的选择算法可以由用户根据一定的规则进行设置，如对下一级功能单元组中的核进行轮选，也可以根据报文中、或配置表中的某个特征字段进行计算来选择)，或者丢弃发现有错误的报文。SINK模块还可以负责将本报文相关的属性参数随报文传递给下一级功能单元组的核。具体实施中，可以将出接口作为一个特殊功能单元组中的特殊核来处理。因为(N-1)级功能单元组在处理完后，将报文向后传递给“N级功能单元组”，如果N级功能单元组处理完后，将发给“出接口”(即从网口发出去)，此时，为了与相邻级功能单元组的SINK概念相同，因而将”出接口“视为一个特殊的功能单元组的特殊核”。

3、BID_DROP模块可以主要负责对当前核处理过程中发现有异常的报文进行丢弃处理，涉及资源的释放等问题。一旦报文进入BID_DROP模块，则意味着当前报文将被丢弃，不会再SINK到后续处理核了。

4、BID_NULL空处理模块，可以用于出口为空的处理。例如，在当前报文处理过程结束时，如果报文暂时缓存起来，既不传给下一级模块，也没有被丢弃，例如接收到未能完成IP重组的分片报文，则此时出口就是一个空处理。实施中设置空处理的目的在于：在IP分片报文到达时，需要等到多个分片均到达，且重组完成之后，才会向后续SINK报文。

综上，本发明实施例提供的技术方案中提出这样一种技术构思：每个核上的代码，采用NextBID机制来驱动，即由前一级BID处理模块的实现中显示指定下一级BID处理模块，Next也即是指按业务面任务的执行流程确定各任务块的执行顺序，在将各任务块分配给CPU后，根据各任务块的标识顺序在相应的CPU上执行任务块的过程。

为了便于描述，下面以C语言的伪代码形式进行说明：

首先，对所有模块的BID值进行规划。形式不限，为描述方便，以C语言的枚举类型来进行示例：

enum e_bid_type    /*枚举所有的BID列表*/

{

      BID_NULL

      ，BID_DROP

      ，BID1

      ，BID2

      ，BID3

      ...

      ，BID_MAX

}；

然后，在每个核初始化过程中，需要进行BID相关初始化，BID相关初始化的C语言伪代码描述如下：

定义BID处理函数所使用的函数指针类型，形式可以如下：

typedef int (*BID_PROC_FP)(struct PACKET_HANDLER*vpstPacketHandler)；

定义各BID使用的函数指针数组，各BID处理函数需要注册到此数组才能使用，形式可以如下：

BID_PROC_FP g_afpBidFuncPt[BID_MAX]；

STATUS bid_proc_register(const e_bid_type vBid，

                         BID_PROC_FP vfpBidFunc

                        )

{

   ...

   g_afpBidFuncPt[vBid]＝vfpBidFunc；

   ...

}

void bid_proc_init()

{

     STEP1.为所有BID的处理设置初始状态，类似如下：

         for(idx＝BID_NULL；idx＜＝BID_MAX；idx++)

         {

               g_afpBidFuncPt[idx]＝NULL；

         }

    STEP2.为BID注册相应处理函数，类似如下：

        bid_proc_register(BID_NULL，(BID_PROC_FP)bid_null_proc)；

        bid_proc_register(BID_DROP，(BID_PROC_FP)bid_drop_proc)；

        bid_proc_register(BID1，(BID_PROC_FP)bid1_proc        )；

        bid_proc_register(BID2，(BID_PROC_FP)bid2_proc        )；

        ......

    return；

}

其次，定义一个报文消息句柄，可以支持在BID之间、甚至不同核间传输报文处理的基本信息。该报文消息句柄需要至少包含如下信息：

struct PACKET_HANDLER

{

     报文缓存；

     报文长度；

     NextVcpuID；/*用于指定下一个处理核的CPU ID，

                   特别的，出接口也有一个特殊的“CPU ID”

                 */

     NextBID；

     ......

}；

每个BID模块在处理完成后，在模块内需要设置NextBID和NextVcpuID。特别地，如果设置NextVcpuID＝DEFAULT_NEXT_VCPU_ID(该值用户可任意指定，但注意必须不能与合法的VCPUID重号，例如取0xFF)。当设置的NextVcpuID既非本核ID，也非DEFAULT_NEXT_VCPU_ID时，则意味着NextBID模块将不在本核上处理，而是在NextVcpuID核上处理，通过这种方式可以灵活调整BID部署。

在报文消息句柄中设置NextBID和NextVcpuID的方式，伪码描述如下：

void nextbid_set(struct PACKET_HANDLER    *vpstPacketHandler，

                 e_bid_type vNextBid，

                 int vNextVcpuID

                 )

{

     ...

     vpstPacketHandler-＞NextBID  ＝vNextBid；

     if(DEFAULT_NEXT_VCPU_ID！＝vNextVcpuID)

     {

         vpstPacketHandler-＞NextVcpuID＝vNextVcpuID；

     }

}

void bid1_proc(struct PACKET_HANDLER    *vpstPacketHandler)

{

   ......

   if(...)

   {

      nextbid_set(vpstPacketHandler，BID2，DEFAULT_NEXT_VCPU_ID)；

   }

   ......

   根据用户定制的规则计算NextVcpuID(即：下一个处理核的CPU ID)；

   nextbid_set(vpstPacketHandler，BID3，NextVcpuID)；

   return；

}

最后，每个核上通过调用一个核心处理函数，该处理函数每次接收一个报文，并以NextBID机制来驱动完成本核的报文流处理功能。该核心处理函数的流程，用C语言伪代码描述如下：

STATUS  flow_proc()

{

    struct PACKET_HANDLER  *pstPacketHandler；

    STEP1.SOURCE处理：

          STEP 1.1根据预设的接收策略，接收来自入接口或前一级功能单

                  元组的报文；其中，pstPacketHandler用于记录接收到的

                  报文消息句柄；

          STEP 1.2判断是否接收到报文：

              STEP 1.2.1否，则：返回相应的错误码；结束。

              STEP 1.2.2是，则：在报文句柄pstPacketHandler中构造并

                   存储报文相关信息，此时需判断接收来源：

                   STEP 1.2.2.1如果接收报文来自入接口，则

                             pstPacketHandler-＞NextBID ＝BID1；

                             pstPacketHandler-＞NextVcpuID＝当前CPU ID；

                             跳转到STEP2.

                   STEP 1.2.2.2否则，接收报文是来自上一级功能单元组

                            的某个核，此时，pstPacketHandler-＞NextBID

                            和pstPacketHandler-＞NextVcpuID的值有效；

                            直接跳转到STEP2.

             (为方便计，下文的NextBID和NextVcpuID均是指

pstPacketHandler消息句柄中的同名成员变量)

STEP2.BID循环处理，按照如下步骤完成所有需要在本核上完成的处理：

     STEP 2.1判断当前核CPU ID与NextVcpuID的关系：

             STEP 2.1.1不相等，则跳转至STEP3；

             STEP 2.1.2相等，则：继续；

     STEP 2.2检查NextBID的合法性

             STEP 2.2.1不合法，则返回错误码；结束。

             STEP 2.2.2合法，则判断NextBID与BID_NULL的关系：

                       STEP 2.2.2.1相等，则返回成功，结束。

                       STEP 2.2.2.2不等，则：继续；

     STEP 2.3检查NextBID是否已在当前核上注册处理函数：

             STEP 2.3.1未注册，则：置NextBID为BID_DROP，

                                   跳转至STEP2.4；

             STEP 2.3.2已注册，则继续。

     STEP 2.4判断NextBID是否为BID_DROP，或是否BID重复使用：

             STEP 2.4.1满足上述任一条件，则：

                       直接调用BID_DROP的处理函数；

                       返回错误码；结束。

             STEP 2.4.2否则，继续；

     STEP 2.5执行BID处理，并判断执行结果是否成功：

             STEP 2.5.1成功，则：跳转至STEP 2.6；

             STEP 2.5.2失败，则：设置NextBID为BID_DROP，继续；

     STEP2.6跳转至STEP2.1；

    STEP3.SINK处理(进入此步骤，意味着NextVcpuID不是当前核CPU)：

          STEP 3.1将pstPacketHandler发给下一级功能单元组；结束。

          STEP 3.2返回SINK处理结果；结束。

    STEP4.结束。

}

基于同一发明构思，本发明实施例中还提供了一种业务面任务处理设备，由于该设备解决问题的原理与一种业务面任务处理方法相似，因此该设备的实施可以参见方法的实施，重复之处不再赘述。

图9为业务面任务处理设备结构示意图，如图所示，设备中可以包括：

任务确定单元901，用于确定需处理的业务面任务；

拆分单元902，用于将所述业务面任务分拆为若干任务块；

顺序确定单元903，用于按所述业务面任务的执行流程确定各任务块的执行顺序；

标识单元904，用于为各任务块分配标识，各任务块标识顺序与各任务块的执行顺序一致；

分配单元905，用于将各任务块分配给CPU；

执行单元906，用于根据各任务块的标识顺序在相应的CPU上执行任务块。

实施中，分配单元还可以进一步用于在将各任务块分配给CPU时，根据CPU的处理能力确定分配给该CPU的任务块数量。

实施中，分配单元还可以进一步用于在将各任务块分配给CPU时，将CPU分组，同一组的CPU并行执行同样的任务块。

实施中，执行单元还可以进一步用于使同一组的CPU在同一时间内访问不同的共享资源。

实施中，执行单元可以包括：

接收子单元，用于在CPU接收到执行任务块的指示时，确定任务块标识；

执行子单元，用于在任务块标识与CPU对应时执行任务块，并且在每一任务块执行结束后将需要执行的下一任务块的标识添加进任务块；

发送子单元，用于在CPU执行完与该CPU标识对应的任务块后，按标识顺序将相应的任务块发送给执行下一任务块的CPU。

为了描述的方便，以上所述装置的各部分以功能分为各种模块或单元分别描述。当然，在实施本发明时可以把各模块或单元的功能在同一个或多个软件或硬件中实现。

由上述实施可见，在本发明实施例提供的技术方案中，在多核软件设计过程中，采用划分BID处理模块的方式来完成对完整任务的拆分；并采用NextBID机制来驱动报文的处理；

还采用报文消息句柄的方式，在BID之间、多核之间传递报文及其管理信息；

还通过更新NextVcpuID的方式来调整BID在不同功能核间的部署关系，来实现负载均衡的目的。

由于采用BID来划分任务的不同子模块，符合现代软件开发的模块化设计理念，且相对于传统子任务的方法而言，BID模块的功能更加明确而具体，便于开发、管理、以及后期维护；

由于采用NextBID驱动机制，仅需极少量的代码修改就可以将相应BID模块功能转移到不同的核上，使得BID功能模块在不同核上的布局调整与优化可以非常地灵活；这既避免了在局部性能方面对***架构师的苛刻要求，同时对后期的核功能部署调整、消除性能瓶颈等提供了便利；为更均衡地利用多核处理器的每个核，实现整体性能的提升提供了可能。

由于采用BID模块平铺架构，BID模块间不存在直接调用关系，因而任务栈很浅，对每个核上的栈的深度要求很低，有利减小了对***资源的需求。

本领域内的技术人员应明白，本发明的实施例可提供为方法、***、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(***)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (10)

1.一种业务面任务处理方法，其特征在于，包括如下步骤：

确定需处理的业务面任务；

将所述业务面任务分拆为若干任务块；

按所述业务面任务的执行流程确定各任务块的执行顺序；

为各任务块分配标识，各任务块标识顺序与各任务块的执行顺序一致；

将各任务块分配给CPU；

根据各任务块的标识顺序在相应的CPU上执行任务块。

2.如权利要求1所述的方法，其特征在于，在将各任务块分配给CPU时，根据CPU的处理能力确定分配给该CPU的任务块数量。

3.如权利要求1所述的方法，其特征在于，在将各任务块分配给CPU时，进一步包括：

将CPU分组，同一组的CPU并行执行同样的任务块。

4.如权利要求3所述的方法，其特征在于，同一组的CPU在同一时间内访问不同的共享资源。

5.如权利要求1至4任一所述的方法，其特征在于，根据各任务块的标识顺序在相应的CPU上执行任务块，包括：

在CPU接收到执行任务块的指示时，确定任务块标识；

在任务块标识与CPU对应时执行任务块，并且在每一任务块执行结束后将需要执行的下一任务块的标识添加进任务块；

在CPU执行完与该CPU标识对应的任务块后，按标识顺序将相应的任务块发送给执行下一任务块的CPU。

6.一种业务面任务处理设备，其特征在于，包括：

任务确定单元，用于确定需处理的业务面任务；

拆分单元，用于将所述业务面任务分拆为若干任务块；

顺序确定单元，用于按所述业务面任务的执行流程确定各任务块的执行顺序；

标识单元，用于为各任务块分配标识，各任务块标识顺序与各任务块的执行顺序一致；

分配单元，用于将各任务块分配给CPU；

执行单元，用于根据各任务块的标识顺序在相应的CPU上执行任务块。

7.如权利要求6所述的设备，其特征在于，分配单元进一步用于在将各任务块分配给CPU时，根据CPU的处理能力确定分配给该CPU的任务块数量。

8.如权利要求6所述的设备，其特征在于，分配单元进一步用于在将各任务块分配给CPU时，将CPU分组，同一组的CPU并行执行同样的任务块。

9.如权利要求8所述的设备，其特征在于，执行单元进一步用于使同一组的CPU在同一时间内访问不同的共享资源。

10.如权利要求6至9任一所述的设备，其特征在于，执行单元包括：

接收子单元，用于在CPU接收到执行任务块的指示时，确定任务块标识；

执行子单元，用于在任务块标识与CPU对应时执行任务块，并且在每一任务块执行结束后将需要执行的下一任务块的标识添加进任务块；

发送子单元，用于在CPU执行完与该CPU标识对应的任务块后，按标识顺序将相应的任务块发送给执行下一任务块的CPU。

Images