CN108345561A - 一种队列通信控制方法 - Google Patents

Abstract

本发明涉及一种队列通信控制方法，采用新单生产者单消费者无锁队列，在数据传输速率较低的情况下，能够压缩队列的长度以提高资源利用率，在数据传输速率较高的情况下，能够扩展队列的长度以防止数据资源的丢失。直接解决了现有技术中因为数据传输速率无法一直保持平衡状态而导致的系统性能极大下降以及数据丢失的问题。实验和理论结果表明，本发明在10Gbps网卡下的多核处理器间进行数据传输，本发明需要少于50个CPU周期来完成入队/出队操作，比FastForward和MCRingBuffer（两种最有名的解决方案）要高3和2倍。

Description

一种队列通信控制方法

技术领域

本发明涉及一种队列通信控制方法，属于多处理器/多核间数据通信技术领域。

背景技术

核间通信机制是多核处理器有效使用的至关重要的基石之一。目前，无锁的单生产者单消费者队列被认为是最为高效的核间通信机制。如今已经有许多队列算法被提出以实现无锁的单生产者单消费者队列，但是这些队列算法的设计目标大都旨在提高系统吞吐量，为了达到这个目标，批处理技术在现有队列算法中被广泛采用。然而，批处理技术从根本上要求数据传输速率达到一个平衡状态才能最大化发挥其性能，但是在实际的高性能系统中，数据传输速率通常含有抖动，不可能达到平衡这一理想状态，因而现有队列算法在大规模并行应用程序中性能遭到极大限制。

发明内容

本发明所要解决的技术问题是提供一种队列通信控制方法，能够明显提高多处理核间的信息传输效率，并且基于当前信息速率的大小合理分配队列大小，既能防止速率低时占用大量内存空间，又可以防止数据到达速率高时信息的丢失。

本发明为了解决上述技术问题采用以下技术方案：本发明设计了一种队列通信控制方法，用于实现发送端基于无锁单生产者单消费者队列，向接收端发送数据的控制，包括基于发送端向队列加载数据速度大于接收端由队列提取数据速度情况下，发送端向队列加载单个数据的控制方法，如下步骤所示：

步骤A1. 判断队列中生产者指针所指向的队列单元是否为空，是则进入步骤A2；否则针对全局性失败参数量traffic进行加1更新，并提示发送端向队列加载该数据失败；

步骤A2. 将队列中的生产者指针向前移动一个队列单元，并判断此时生产者指针是否指向队列的队尾，是则进入步骤A3；否则进入步骤A6；

步骤A3. 判断全局性失败参数量traffic是否达到预设数据加载失败次数阈值，是则进入步骤A4；否则进入步骤A5；

步骤A4. 由发送端针对队列长度扩大n1倍，并进入步骤A6；其中，n1大于0；

步骤A5. 将队列中的生产者指针移回队列的队首，并进入步骤A6；

步骤A6. 由发送端根据生产者指针的指向，向队列加载该数据。

作为本发明的一种优选技术方案：所述n1等于2。

作为本发明的一种优选技术方案：还包括基于发送端向队列加载数据速度小于接收端由队列提取数据速度情况下，接收端由队列中提取单个数据的控制方法，如下步骤所示：

步骤B1. 判断队列中消费者指针所指向的队列单元是否为空，是则针对全局性失败参数量traffic进行减1更新，并提示接收端由队列中提取数据失败；否则进入步骤B2；

步骤B2. 将队列中的消费者指针向前移动一个队列单元，并判断此时消费者指针是否指向队列的队尾，是则进入步骤B3；否则进入步骤B7；

步骤B3. 判断全局性失败参数量traffic是否达到预设数据提取失败次数阈值，是则进入步骤B4；否则进入步骤B6；

步骤B4. 判断队列中生产者指针是否越过队列的中间位置，是则返回步骤B3；否则进入步骤B5；

步骤B5. 由发送端针对队列长度缩小n2倍，并进入步骤B7；其中，0<n2<1；

步骤B6. 将队列中的消费者指针移回队列的队首，并进入步骤B7；

步骤B7. 由接收端根据消费者指针所指向的队列单元，提取该队列单元中的数据,并针对该队列单元进行置空操作。

作为本发明的一种优选技术方案：所述n2等于0.5。

本发明所述一种队列通信控制方法采用以上技术方案与现有技术相比，具有以下技术效果：本发明设计的队列通信控制方法，因为采用新单生产者单消费者无锁队列，在数据传输速率较低的情况下，能够压缩队列的长度以提高资源利用率，在数据传输速率较高的情况下，能够扩展队列的长度以防止数据资源的丢失。直接解决了现有技术中因为数据传输速率无法一直保持平衡状态而导致的系统性能极大下降的问题。并且实验和理论结果表明，本发明在10Gbps网卡下的多核处理器间进行数据传输，本发明需要少于50个CPU周期来完成入队/出队操作，比FastForward和MCRingBuffer（两种最有名的解决方案）要高3和2倍。

附图说明

图1是队列三种不同元素数量情况下队列长度变化的队列结构改变框架图；

图2是针对安全和不安全两种情况下扩展队列长度示意图；

图3是队列元素趋于满情况下扩展队列长度的操作流程图；

图4是针对安全和不安全两种情况下压缩队列长度示意图；

图5是队列元素趋于空情况下压缩队列长度的操作流程图。

具体实施方式

下面结合说明书附图对本发明的具体实施方式作进一步详细的说明。

如图1所示，示出了队列三种不同元素数量情况下队列长度变化的队列结构改变框架图，该发明主要针对队列内元素数量趋于满和趋于空的两种情况。

首先针对理想情况下的队列101，元素数量在队列总长度的一般左右，在这种情况下，不需要对队列长度进行调整，即队列102与队列101相同。而针对元素数量趋于空的队列103，由于数据传输速率较低，队列中大部分空间未被使用，从而导致了系统资源的浪费，所以对于此队列要将队列长度缩为原来的一半，即得到长度为Length/2的队列104。最后针对元素数量趋于满的队列105，队列中几乎所有的空间均被占用，而考虑到实际情况中生产者Producer的生产速度会大于消费者Consumer的速度，以及一系列类似情况的影响，队列中的元素数量会相应增加，此时很有可能会超过原有队列的长度，这样将会导致数据丢失等一系列不可预知的错误，同时增加系统负荷，所以在元素数量趋于满的情况，本发明会自动扩展队列长度，即得到长度为Length*2的队列106。

基于上述针对队列的扩展，如图2所示，出示了针对安全和不安全两种情况下扩展队列长度示意图。在不安全状况下（生产者Producer尚未到达队尾），队列201若想直接扩展队列长度，必然会对原有数据产生不可逆的影响，破坏传输信息。在安全状况下（生产者Producer到达队尾），则可以扩展队列长度，此状况下由于Producer后面没有其他元素，所以扩展队列大小时不会影响到队列中的其他元素。

本发明所设计队列通信控制方法中，用于实现发送端基于无锁单生产者单消费者队列，向接收端发送数据的控制，在安全情况下由生产者Producer来实现队列长度扩展的操作，Producer的操作实际上就是元素进入队列的一个过程，所以Producer进行扩展队列长度的操作实质上是在入队函数Enqueue()中得以实现。具体地，如图3所示，出示了队列元素趋于满情况下扩展队列长度的操作流程图，即基于发送端向队列加载数据速度大于接收端由队列提取数据速度情况下，发送端向队列加载单个数据的控制方法，本发明的入队函数Enqueue()可以包括以下步骤：

步骤A1. 判断队列中生产者指针所指向的队列单元是否为空，是则进入步骤A2；否则针对全局性失败参数量traffic进行加1更新，并提示发送端向队列加载该数据失败。

生产者指针是待插入元素的位置，即生产者Producer所指的位置，用32位int型变量来表示。若指向生产者指针的指针为空，即代表队列未满，存在空间分配给待入队的元素value;反之，则表示队列已满。

对于针对全局性失败参数量traffic进行加1更新，并提示发送端向队列加载该数据失败，traffic是自定义的一个计数器，针对入队操作时，其是用来记录队列为满这种情况发生的次数。若步骤A1结果发现队列已满，此时无法执行入队的操作，每发生一次这种情况就将计数器traffic加一，并返回值BUFFER_FULL，提示队列元素已满，入队失败。

步骤A2. 将队列中的生产者指针向前移动一个队列单元，并判断此时生产者指针是否指向队列的队尾，是则进入步骤A3；否则进入步骤A6。

上述步骤A2是在步骤A1判断为空的结果后所执行的操作，生产者指针永远指的是当前元素的下一位置，在满足插入条件后，生产者指针自然需要向后移动，而具体的实施时则先将生产者指针赋值给本地temp变量记录当前值，再将生产者指针进行自加操作即可。

基于上述将队列中的生产者指针向前移动一个队列单元，并判断此时生产者指针是否指向队列的队尾，每当元素入队生产者指针就会加一，虽然本发明是一种循环队列，但如果想要对队列长度size做改变，必须要有指向队尾的指针。若生产者指针小于等于队列的长度size,即表示生产者Producer还没有到达队尾位置，这种情况下入队Enqueue()操作只需要按普通队列的入队函数执行，生产者指针向后移动一个单位，并插入元素value。此情况正如如图2中队列201所示，不可以扩展队列长度，否则会出现错误。反之，若生产者指针大于对列的长度size，即表示Producer移动到了队尾，这种情况下，生产者Producer可以去对队列的长度进行变化。

步骤A3. 判断全局性失败参数量traffic是否达到预设数据加载失败次数阈值，是则进入步骤A4；否则进入步骤A5。

上述步骤A3是在上述步骤A2判断结果为生产者指针到达队尾之后执行的判断语句。traffic在上文中有说明其是记录进行入队操作时发现队列为满这一状态的次数的计数器，本发明在队列趋于满的情况下会扩展队列的长度，但是对于趋于满这一情况必须有一个定量的指标来判断当前队列中元素数量的的情况，而在本发明中，traffic这一计数器值得大小可以反应出这一情况。如果队列趋于满，那元素因队列已满而无法入队的情况出现的概率会很大，因而traffic自加的次数也就会越多，所以其值越大就表示当前队列更趋于满。这里需要设定一个常量ENLARGE_THRESHOLD来与traffic进行比较，若traffic大于等于ENLARGE_THRESHOLD，即表示此时的队列满足“趋于满”这一定义，需要对队列的长度进行调整；反之，则说明队列能够满足生产者Producer的生产速度，不需要调整队列长度。

步骤A4. 由发送端针对队列长度扩大n1倍，并进入步骤A6；实际应用中，设计n1等于2。

上述步骤A4是在步骤A3判断结果为traffic达到预设数据加载失败次数阈值之后执行的操作，即需要改变队列的大小size。此时满足了扩展队列长度的两个要求：1)生产者Producer位于队尾2)队列“趋于满”，所以使用赋值语句将本发明中结构体info中记录队列大小的size变为原来的两倍，得到队列202。此时head≤2*size有意义，表示下一元素的位置，同时扩展后需要将表示队列元素相对数量的变量traffic置为0。最后与步骤A5一样，通过temp插入value的值，即步骤A6。

步骤A5. 将队列中的生产者指针移回队列的队首，并进入步骤A6。

上述步骤A5是在步骤A3判断结果为traffic未达到预设数据加载失败次数阈值之后执行的操作，即不需要改变队列的大小size。此时只需要基于循环队列的性质将生产者指针移回队列的头位置即可，最后在原来生产者指针的位置插入元素value就最终实现入队Enqueue()的操作。不过，由于生产者指针的值先是进行了加一，后又被置为0（移至队首），value不可以赋值给生产者指针所指的队列位置的值，在步骤A2中用变量temp保存了变换前的生产者指针值，所以这里使用temp确定最终value插入的位置，即步骤A6。

步骤A6. 由发送端根据生产者指针的指向，向队列加载该数据。

如图4所示，出示了针对安全和不安全两种情况下压缩队列长度示意图。在不安全状况下（生产者Producer已经越过队列长度的一半），即使消费者Consumer位于队尾，队列401也不可以直接压缩队列长度，因为此时直接将队列压缩为一半，那么越过一半的部分会被影响，产生不可预知的错误。在安全状况下（生产者Producer未越过队列长度的一半），可以对队列长度进行压缩，由于压缩的部分没有元素，所以此过程是安全的。

本发明在此情况下由消费者Consumer来实现队列长度压缩的操作，Consumer的操作实际上就是元素出队列的一个过程，所以Consumer进行压缩队列长度的操作实质上是在出队函数Dequeue()中得以实现。具体地，即基于发送端向队列加载数据速度小于接收端由队列提取数据速度情况下，接收端由队列中提取单个数据的控制方法，本发明队列的出队函数Dnqueue()包括以下步骤：

步骤B1. 判断队列中消费者指针所指向的队列单元是否为空，是则针对全局性失败参数量traffic进行减1更新，并提示接收端由队列中提取数据失败；否则进入步骤B2。

上述步骤B1中，消费者指针是队列中末尾元素的位置，用32位int型变量来表示。若指向消费者指针的指针为空，即代表队列为空队列，没有元素；反之，则表示队列中至少存在一个元素以执行出队Dnqueue()操作。

并且上述步骤B1中，针对全局性失败参数量traffic进行减1更新，并提示接收端由队列中提取数据失败，其中，traffic为一个计数器，在Enqueue()函数中有说明，但此时有一些细微的不同：针对出队操作，则是用来记录队列为空这种情况发生的次数。若步骤B1结果发现队列为空队列，此时无法执行出队操作，每发生一次这种情况计数器traffic相应变成减一，并返回值BUFFER_EMPTY，提示队列中没有元素，无法执行出队操作。

步骤B2. 将队列中的消费者指针向前移动一个队列单元，并判断此时消费者指针是否指向队列的队尾，是则进入步骤B3；否则进入步骤B7。

上述步骤B2中，将队列中的消费者指针向前移动一个队列单元，消费者指针永远指的是当前Consumer所指的位置，当前元素成功出队后，消费者指针则需要向后移动，而具体的实施时则先将消费者指针赋值给本地temp变量记录当前值，再将消费者指针进行自加操作即可。

并且基于上述步骤B2中消费者指针的移动操作后，判断此时消费者指针是否指向队列的队尾，每当元素出队消费者指针就会加一，与入队相同，想要对队列长度size做改变，必须要有指向队尾的指针。若消费者指针小于队列的长度size,即表示消费者Consumer还没有到达队尾位置，这种情况下出队Dequeue()只需要将指向当前元素指针置为空，并将消费者指针向后移动一个单位。反之，若消费者指针大于等于对列的长度size，即表示Consumer移动到了队尾，这种情况下，消费者Consumer可以去对队列的长度进行变化。

步骤B3. 判断全局性失败参数量traffic是否达到预设数据提取失败次数阈值，是则进入步骤B4；否则进入步骤B6。

上述步骤B3的执行中，traffic在上文中有说明其是记录进行出队操作时发现队列为空队列这一状态的次数的计数器，本发明在队列趋于空的情况下会压缩队列的长度，与Enqueue()相同使用traffic来判断当前队列中元素数量的的情况。如果队列趋于空，那元素因队列中无元素而无法执行出队的情况出现的概率会很大，因而traffic自减的次数也就会越多，所以其值越小就表示当前队列更趋于空。这里同样需要设定一个常量预设数据提取失败次数阈值来与traffic进行比较，若traffic达到预设数据提取失败次数阈值，即表示此时的队列满足“趋于空”这一定义，需要对队列的长度进行调整；反之，则说明传输速率处于平衡状态，不需要调整队列长度。

步骤B4. 判断队列中生产者指针是否越过队列的中间位置，是则返回步骤B3；否则进入步骤B5。

上述步骤B4的操作，是在步骤B3判断结果traffic达到预设数据提取失败次数阈值之后执行的操作，即需要压缩队列的大小size。消费者Consumer想要压缩队列长度时并不像扩展队列长度那样直接将size乘2就可以的，扩展队列长度操作本身不会对原来队列产生影响，所以实现起来较为容易；而压缩队列（压缩为原队列长度的一半）时，如果队列后一半上存在元素，如图4中队列401所示，则就不能进行压缩队列长度的操作，因为这样会导致原有数据遭到破坏等问题，甚至会导致系统的崩溃。所以，为了预防这种情况的发生，在消费者Consumer进行压缩队列长度操作之前，必须确保队列中记录待插入元素位置的生产者指针不能越过half of length这一临界线。

判断生产者指针是否越过队列一半的具体实现方法如下：1)首先直接比较生产者指针的值和info.size/2的值，自然必须使得生产者指针小于size的一半。2)由于上一步的判断语句并不是原子操作（所谓原子操作是指不会被线程调度机制打断的操作；这种操作一旦开始，就一直运行到结束，中间不会有任何 context switch （换到另一个线程）），所以存在以下可能的情况：判断生产者指针数值大小是确实满足小于队列长度的一半，但在进行压缩操作时，生产者Producer正好移动了（有元素入队），此时生产者指针恰好越过了队列长度的一半，若消费者Consumer继续执行压缩队列长度的操作，不可避免地会发生上述一系列的问题。所以在满足生产者指针的值小于size/2的条件下，使用CAS操作来判断队列是否发生了改变（有无入队），如果未发生变化，则直接进行压缩队列长度的操作。由于CAS是原子的，所以消费者在压缩队列长度时，不会执行其他操作，保证了当前生产者指针没有发生变化，即生产者指针没有越过原队列长度的一半。

判断结果若生产者指针没有越过队列长度的一半，接下来消费者Consumer就可以压缩队列长度；若判断生产者指针值的时候已经大于size/2或者CAS发现队列发生了变化，则需要重新进行判定操作，知道判定成功或循环达到嵌套上限终止压缩队列长度的操作。

步骤B5. 由发送端针对队列长度缩小n2倍，并进入步骤B7；实际应用中，设计n2等于0.5。

上述步骤B5，是在是在步骤B3判断结果traffic未达到预设数据提取失败次数阈值之后执行的操作，即需要压缩队列的大小size。使用赋值语句将本发明中结构体info中记录队列大小的size变为原来的二分之一，得到队列402。最后将指向temp位置的指针置为空，并将消费者指针赋为0，表示消费者Consumer回到队首位置，即步骤B6。

步骤B6. 将队列中的消费者指针移回队列的队首，并进入步骤B7。

上述步骤B6，即此时只需要基于循环队列的性质将消费者指针移回队列的头位置即可，最后将指向temp的指针置为空。

步骤B7. 由接收端根据消费者指针所指向的队列单元，提取该队列单元中的数据,并针对该队列单元进行置空操作。

上述技术方案所设计的队列通信控制方法，因为采用新单生产者单消费者无锁队列，在数据传输速率较低的情况下，能够压缩队列的长度以提高资源利用率，在数据传输速率较高的情况下，能够扩展队列的长度以防止数据资源的丢失。直接解决了现有技术中因为数据传输速率无法一直保持平衡状态而导致的系统性能极大下降的问题。并且实验和理论结果表明，本发明在10Gbps网卡下的多核处理器间进行数据传输，本发明需要少于50个CPU周期来完成入队/出队操作，比FastForward和MCRingBuffer（两种最有名的解决方案）要高3和2倍。

上面结合附图对本发明的实施方式作了详细说明，但是本发明并不限于上述实施方式，在本领域普通技术人员所具备的知识范围内，还可以在不脱离本发明宗旨的前提下做出各种变化。

Claims (4)

1.一种核间队列通信控制方法，用于实现发送端基于无锁单生产者单消费者队列，向接收端发送数据的控制，其特征在于：包括基于发送端向队列加载数据速度大于接收端由队列提取数据速度情况下，发送端向队列加载单个数据的控制方法，如下步骤所示：

步骤A1. 判断队列中生产者指针所指向的队列单元是否为空，是则进入步骤A2；否则针对全局性失败参数量traffic进行加1更新，并提示发送端向队列加载该数据失败；

步骤A2. 将队列中的生产者指针向前移动一个队列单元，并判断此时生产者指针是否指向队列的队尾，是则进入步骤A3；否则进入步骤A6；

步骤A3. 判断全局性失败参数量traffic是否达到预设数据加载失败次数阈值，是则进入步骤A4；否则进入步骤A5；

步骤A4. 由发送端针对队列长度扩大n1倍，并进入步骤A6；其中，n1大于0；

步骤A5. 将队列中的生产者指针移回队列的队首，并进入步骤A6；

步骤A6. 由发送端根据生产者指针的指向，向队列加载该数据。

2.根据权利要求1所述一种队列通信控制方法，其特征在于：所述n1等于2。

3.根据权利要求1所述一种队列通信控制方法，其特征在于：还包括基于发送端向队列加载数据速度小于接收端由队列提取数据速度情况下，接收端由队列中提取单个数据的控制方法，如下步骤所示：

步骤B1. 判断队列中消费者指针所指向的队列单元是否为空，是则针对全局性失败参数量traffic进行减1更新，并提示接收端由队列中提取数据失败；否则进入步骤B2；

步骤B2. 将队列中的消费者指针向前移动一个队列单元，并判断此时消费者指针是否指向队列的队尾，是则进入步骤B3；否则进入步骤B7；

步骤B3. 判断全局性失败参数量traffic是否达到预设数据提取失败次数阈值，是则进入步骤B4；否则进入步骤B6；

步骤B4. 判断队列中生产者指针是否越过队列的中间位置，是则返回步骤B3；否则进入步骤B5；

步骤B5. 由发送端针对队列长度缩小n2倍，并进入步骤B7；其中，0<n2<1；

步骤B6. 将队列中的消费者指针移回队列的队首，并进入步骤B7；

步骤B7. 由接收端根据消费者指针所指向的队列单元，提取该队列单元中的数据,并针对该队列单元进行置空操作。

4.根据权利要求1所述一种队列通信控制方法，其特征在于：所述n2等于0.5。