CN101127644A - 一种大规模协同环境下的因果并发检测方法 - Google Patents

Abstract

本发明属于协同实时组编辑技术领域，具体是一种大规模协同环境下的因果并发检测方法。包括：定义了一种属于协同实时组编辑技术领域的逻辑时间戳，称之为直接因果先序向量时间戳；提出了基于该时间戳解决实时组编辑活动中因果并发检测问题的方法。该方法包括如下三个步骤：判断一个远程操作是否因果就绪、找出与当前远程操作并发的所有历史操作、判断任意两个历史操作间的因果并发关系。本发明可供用户在任意规模的实时组编辑环境中使用，其执行性能与协同参与者的活跃程度，与协同环境的规模、协同参与者的总数无关，所以特别适合并发程度不高的大规模协同环境下的实时组编辑。

Description

一种大规模协同环境下的因果并发检测方法

技术领域

本发明属于协同实时组编辑技术领域，具体涉及一种大规模环境下实时组编辑活动中的因果并发检测方法。

背景技术

单用户的文档编辑系统，包括普通的文本编辑器(如Vi，Notepad)、字处理工具(如Microsoft Word，WordPerfect)、图形编辑器(如Photoshop，MsPaint)以及网站设计工具(如Dreamweaver，Frontpage)、工程图纸设计工具(如AutoCAD)等，在人们的日常生活中都已经应用得十分普遍。

近年来，因特网(Internet)和经济全球化趋势的迅猛发展，将这些单用户的编辑系统移植到多用户的环境下，允许多个用户通过计算机网络同时浏览、编辑一个共享数据对象，使之能够在多用户协同工作时发挥重要的作用，这样的需求也就自然而然地产生了

全复制结构下的并发控制和一致性维护一直是实时组编辑领域最为关注的问题之一。

首先，在实时组编辑系统中，一组并发的操作在不同的协同站点上执行，其执行顺序往往是不同的。操作以不同的顺序在各个协同站点上执行，很难保证最后得到的结果是一致的。其次，实时组编辑系统允许多个用户并发地修改它们各自的文档数据副本，当一个操作在远程站点上执行时，该站点上很可能已经执行过多个与之并发的操作。受到之前执行的与之并发的操作的影响，操作的执行意愿可能会发生扭曲。

近20年来，出现了多种新颖的解决方法，其中最主要的有操作转换(OperationTransformation，简称OT)和地址空间转换(Address Space Transformation，简称AST)。操作转换的主要思想是，在远程操作执行前，先将它以一组预先定义的规则与所有的之前执行过的与之并发的操作进行操作转换，计算出该操作在当前执行环境下的能够确保实时组编辑一致性的正确的执行形式。

关于实时组编辑的其它方面的研究也取得了很大的进展。Telepointer(图形化协同感知系统)、RadarView(协同活动支持感知系统)等工具被发明以帮助协同用户更好地、更准确地感知相互的协同编辑活动，尽可能地避免编辑冲突；SUN等人提出了MVSD(Multi-Version-Single-Display)(多版本单显示)的方法，在冲突发生时，可以帮助用户更好地理解相互的操作意愿偏差，从而提高解决编辑冲突的效率；已有的一些研究也已开始尝试着实现多种异构系统(如Notepad和GVim)间的实时协同、实时组编辑系统和传统异步协同系统(如CVS)间的无缝衔接等。

尽管目前对实时组编辑的研究已经取得了很大的进展，然而，现有的对实时组编辑的研究都还主要局限于小组协同(人数小于10)。在更大规模的协同环境中(人数大于10，甚至成百上千)支持实时组编辑活动会遇到什么样的特殊问题？现有的技术能否很好的解决这些问题、能否很好的适应这样的环境？可以有些怎样的解决方案？关于这些问题，据我们所知，都还没有细致的分析和研究。

和小组协同环境相比，大规模协同有如下一些特点：

1.更多的协同参与者：在小组协同中，协同参与者的人数一般不超过10人，而诸如Enterprise Brainstorming(企业头脑风暴)和Wiki(维基)这样的协同活动，参与者的人数动辄上百人，甚至成千上万。

2.不确定的协同参与者人数：在小组协同中，协同参与者的名单一般可以事先预知，而在很多大规模协同活动中，尤其是在诸如Internet Wiki(互联网维基)这样的开放式协同活动中，谁会参与、有多少人会参与，事先往往都是不知道的。

3.更强的动态性：计算机支持实时协同，不同于面对面的协同活动，用户会中途离开，也会中途加入，协同会话的动态性很强。这点在大规模协同活动中会更为明显，每小时甚至每分钟都会有成百上千人加入离开协同会话，Wikipedia(维基百科)就是一个典型的例子。

4.更高的并发性：在诸如Enterprise Brainstorming的协同活动中，用户的活跃程度很高，协同环境中操作的并发性会随着协同参与者人数的增多而不断提高。

5.不可靠的协同环境：这里我们所说的不可靠，包括网络环境的不可靠，也包括协同用户的不可靠。协同用户通过广域网甚至Internet相互协同，用户间的网络传输具有很强的不确定性；用户会在任何时刻，由于所用的软件发生意外故障或是由于用户直接地关闭其应用进程，突然“消失”在协同会话中。

全复制结构下的实时组编辑系统允许用户并发的编辑修改他们各自的文档数据副本。准确识别操作间的因果并发关系是正确维护实时组编辑一致性的基础。

目前最广泛使用的是基于向量逻辑时间戳的因果并发检测方法——在每个用户操作上附加一个固定大小的向量，向量的大小等同于协同参与者的个数，其中的每个分量对应于一个协同参与者，记录操作生成前协同站点上已经执行过的由该协同参与者触发的操作的个数；只需比较它们的时间戳向量，任意操作间的因果并发关系都可以得到准确的判断。

但这种方法并不适合大规模协同环境，首先，在大规模协同环境下，很多时候都无法预知参与者的人数，也就无法使用这种固定大小的时间戳。其次，向量逻辑时间戳的大小正比于协同参与者的人数，大规模协同环境下，动辄成百上千的协同参与者规模，过于庞大的操作时间戳会对网络传输、本地存储造成难以承受的巨大的额外负担。

M.Singhal、A.Kshemkalyani等人提出，既然大规模分布式环境中，只有极少的一部分参与者处于活跃状态，那么如果在每次发送操作时，都只发送时间戳的变化量，而不是完整的向量逻辑时间戳向量，将有望大大减少进程间操作分发时的时间戳开销。Singhal-Kshemkalyani方法更适合于单机多线程系统，它要求进程到进程的数据传输是先进先出的，这对于网络数据传输，尤其是在广域网或Internet环境下的网络数据传输，是一个十分苛刻的要求。Singhal-Kshemkalyani方法中，并发进程在收到操作后，在进行进一步的处理之前，还是需要根据时间戳变化量信息，复原该操作的完整的向量逻辑时间戳，因此，Singhal-Kshemkalyani方法只是降低了进程间操作分发时的时间戳开销，如果在实时组编辑系统中使用，由于大规模分布式环境下向量逻辑时间戳膨胀而引起的本地存储负担加重、计算效率下降等问题依旧存在。

D.Ratner等人提出的方法，其思想是用索引表改造向量逻辑时间戳为动态时间戳；并使用两阶段控制算法，定期的对每个操作，先启动第一阶段过程，判断它是否已经在所有的协同进程上都已经完成了同步，如果是，就启动第二阶段过程，通知所有的协同进程，将相应的状态向量分量减1，如果一个状态向量项变为0，就将它回收。Ratner方法的缺点在于，即使只有一个协同进程出现故障，无法与其它协同进程正常通讯，也会严重阻碍算法的执行，如果故障在很长时间内无法恢复，那么就很难保证操作的时间戳大小还能一直维持在一个合适的范围内。

除了基于向量逻辑时间戳的因果并发关系检测方法，已有的实时组编辑研究中也提出过一些其它的检测操作间因果关系的方法。但是这些方法也都有这样那样的缺陷，使之不能很好的适应大规模协同环境。实时组编辑并发控制算法NICE(《Flexible notification forcollaborative systems》(H.Shen and C.Sun.))通过引入一个中央服务器控制操作的分发与同步，确保每个被发往站点i的操作都已经与所有站点i上之前收到的与之并发的操作进行了操作转换，消除了它们对它的执行意愿的影响。通过这种方法，NICE彻底抛弃了对操作时间戳的使用，然而这种方法显然具有单点故障的风险。实时组编辑并发控制算法SOCK4采取了另一种方法，它为系统中产生的每一个操作根据它们的生成顺序赋予一个连续的序号，并规定，一个本地操作生成后不能立即被分发除非它已经和所有序号小于它的并发操作进行了操作转换。操作分发时，操作的序号作为时间戳被附在操作上一起被发送，这是一个标量的时间戳，其大小不会随协同环境规模的增大而无限膨胀。然而SOCK4方法不适合在不稳定的网络环境中使用，在不稳定的网络环境下使用SOCK4方法，用户的协同感知性能会很差；SOCK4也限制了用户的协同模式，它不支持局部协同。Li Du等人提出的TIBOT(《A time interval based consistency control algorithm for interactive groupwareapplications》(D.Li，R.Li，and C.Sun.))其思想与SOCK4类似，因而也存在同样的问题。此外，上述的这些方法，与之前提到的Sun-Cai方法一样，也都存在意外隐藏用户的操作意愿冲突的可能。

相比，本发明没有对网络传输特性、网络连接的可靠性作出太多的假设和限制。网络故障对我们的方法的影响，仅仅体现在当网络连接恢复时，新生成的操作的时间戳(直接因果先序向量时间戳)可能会出现暂时的膨胀，但一旦网络故障的双方文档数据副本的状态趋于同步，一切又将恢复正常。因此，我们只要求相对稳定的网络环境，并不需要确保每个协同站点间都有着绝对稳定可靠的网络连接。局部的少数站点发生网络连接故障，这是可以忍受的，并不会影响算法的性能。此外，我们的方法能比较全面地帮助解决大规模协同环境下实时组编辑活动中的各种因果并发检测相关的性能问题。

发明内容

本发明的目的在于提出一种新的，适用于大规模协同环境下的，实时组编辑活动中因果并发检测方法。

和背景介绍中的传统方法相比，本发明没有对网络传输特性、网络连接的可靠性作出太多的假设和限制。网络故障对本发明方法的影响，仅仅体现在当网络连接恢复时，新生成的操作的时间戳(直接因果先序向量时间戳)可能会出现暂时的膨胀，但一旦网络故障的双方文档数据副本的状态趋于同步，一切又将恢复正常。因此，本发明只要求相对稳定的网络环境，并不需要确保每个协同站点间都有着绝对稳定可靠的网络连接。局部的少数站点发生网络连接故障，这是可以忍受的，并不会影响算法的性能。此外，本发明方法能比较全面地帮助解决大规模协同环境下实时组编辑活动中的各种因果并发检测相关的性能问题。

实时组编辑系统中，判断一个远程操作是否因果就绪、找出与当前远程操作并发的所有历史操作、判断任意两个历史操作间的因果并发关系，这是维护多副本一致性必须解决的三个因果并发检测问题，也是本发明进行因果并发检测的三个步骤。

相关定义和基本概念：

对因果先序关系的严格定义最早出现在Lamport在1978年发表的一篇著作中，在本发明中我们延用相同的表述方式，根据操作的生成顺序与执行顺序，定义操作间的因果关系和顺序。

(1)给定两个任意的操作O_a和O_b，O_a和O_b分别产生于协同站点i和j，O_a和O_b是因果先序关系的操作，记为O_a→O_b，当且仅当(1)i＝j，并且O_a在O_b之前生成，或者(2)i≠j，但是O_b生成前，O_a已经在站点j上被执行，或者(3)存在一个操作序列O_x1，O_x2，O_x3，...，O_xn，满足O_a→O_x1，O_x1→O_x2，O_x2→O_x3，...，O_xn→O_b。

(2)对于两个操作O_a和O_b，如果O_a→O_b，我们称O_a因果先序于O_b，或者O_b因果依赖于O_a；如果两个操作间不存在任何因果先序关系，我们就称这两个操作是并发的，记为O_a||O_b，更准确地，O_a||O_b当且仅当O_a与O_b之间的关系既不满足O_a→O_b，也不满足O_b→O_a。

为了解决因果并发检测问题，本发明首先给出了如下定义：

(1)直接因果先序关系()给定两个任意的操作O_a和O_b，O_a直接因果先序于O_b，记为O_aO_b，当且仅当(1)O_a→O_b并且(2)不存在一个操作O_c，满足O_a→O_c且O_c→O_b。

(2)直接因果先序向量时间戳(Direct Causal Vector，简称DCV)给定一个操作O，假设O₁，O₂，...，O_k是所有直接因果先序于O的操作，O₁是站点S₁上产生的第N₁个操作，O₂是站点S₂上产生的第N₂个操作，....，O_k是站点S_k上产生的第N_k个操作，我们定义操作0的直接因果先序向量时间戳为[(S₁，N₁)，(S₂，N₂)，...，(S_k，N_k)]，记为DCV(0)。

根据直接因果先序向量时间戳(DCV)的定义，向量DCV(O)中的每一个分量都对应于一个直接因果先序于O的操作，所有直接因果先序于O的操作在DCV(O)中都有一个对应的分量。给定两个任意的操作O_a，O_b以及它们的直接因果先序向量时间戳DCV(O_a)和DCV(O_b)，O_aO_b当且仅当DCV(O_b)中存在一个对应于操作O_a分量，反之O_bO_a当且仅当DCV(O_a)中存在一个对应于操作O_b分量。因此，给定它们的直接因果先序向量时间戳，可以准确高效地判断出任意两个操作间的直接因果先序关系。

在直接因果先序向量时间戳(DCV)等定义的基础上，本发明提出的大规模协同环境下的因果并发检测方法的具体步骤如下：

1、判断一个远程操作是否因果就绪

目前被最广泛接受的实时组编辑一致性模型是CCI模型，它对实时组编辑系统的一致性定义如下：

(1)结果一致，亦称为CCI结果一致性要求(Convergence)：同一操作集合在所有的站点上执行后，这些站点上的文档状态应当是一致的；

(2)因果一致，亦称为CCI因果一致性要求(Causality Preservation)：对于任意两个操作O_a和O_b，如果在O_b的初始站点上，O_a在O_b生成前已被生成或执行，则在所有站点上O_a都应早于O_b被执行；

(3)意图一致，亦称为CCI意图一致性要求(Intention Preservation)：对于任意操作O，其在所有站点上的执行效果都应保持操作O的原有意图，同时操作O的执行效果不能影响那些与操作O并发的操作的执行效果。

给定一个尚未执行的远程操作O_R，如果协同站点上之前每执行一个操作都严格地遵循CCI因果一致性要求，即O_R之前的每个操作都是在因果就绪后才在本地共享文档数据副本上执行的，那么，要判断O_R是否已经因果就绪，只需检查它所直接因果依赖于的那些操作。O_R是因果就绪的，当且仅当，所有直接因果先序于O_R的操作都已经在协同站点上得到了执行。

我们在每一个协同站点S上维护一个状态向量SVs。对于每一个曾经活跃过的参与修改编辑共享文档数据的协同站点St，SVs中都有一个对应的分量SVs[St]，记录着站点S上已经执行过的由站点St产生的操作的个数。显然，给定一个操作Ox，假设它是站点Sx上产生的第Nx个操作，如果Nx＜SVs[Sx]，则可以断定Ox已经在站点S上执行过了。

综上，对于站点S上一个尚未执行的远程操作Or，我们给出如何判断一个远程操作是否因果就绪的具体步骤为：、

(1)找出所有它的直接因果依赖于的那些操作；

(2)对于每一个这样的操作，判断是否已经在站点S上得到了执行，操作Or是因果就绪的，当且仅当对于DCV(Or)中的每一个分量(Si，Ni)都有SVs[Si]＞Ni，(其中，i为协同站点编号)。

以上就是基于直接因果先序向量时间戳判断操作是否因果就绪的算法。算法十分简单，就不再给出形式化的描述了。

2、找出与当前远程操作并发的所有历史操作

本发明采用并发历史操作查找算法(FindConcurrentHistoryOperations)找出与当前远程操作并发的所有历史操作。

在具体介绍这个算法之前，我们先引入一些新的概念。

直接因果先序历史操作列表(Direct Causal History，简称DCH)DCH是历史操作列表(HB)的一个子集，是由所有在HB中没有因果后继的历史操作组成的集合。

直接因果后继计数器(Direct Successor Counter，简称DSC)DSC是一个二维映射表。它为每个历史操作O记录着HB中直接因果依赖于它的操作的数目，记为DSC[O]

是历史记录中所有有待同步的远程操作并发的操作组成的集合，初始置为空(NULL)，

是一个以操作序列号(ID)为索引的索引表，对于每一个历史操作O，

[O]都初始为0。

算法FindConcurrentHistoryOperations的执行步骤：

(1)该算法的输入为待同步的因果就绪的远程操作，输出为历史记录中与该操作并发的操作组成的集合。算法同时还实现了对DCH和DSC这两个自定义数据结构的调整。算法中，候选并发操作集(candidates)是一个操作集合，它初始包含DCH中的所有操作。我们就从这些操作开始，以因果顺序相反的顺序检查历史操作缓存(HB)中的历史操作。

(2)算法对candidates中的每个操作O_H检查它是否直接因果先序于O_R。如果O_HO_R，则检查O_H是否是DCH中的元素，如果是，就将它从DCH中移除。同时算法根据DSC的定义调整DSC记录，将DSC[O_H]的值增1。

(3)如果

根据前面的分析，O_H必然与O_R并发，于是，我们将O_H加入

同时算法调整数据结构，算法对每一个满足O_xO_H的操作O_x调整 ${\hat{C}}_R\mathrm{Successor}\left[O_x\right]:={\hat{C}}_R\mathrm{Successor}\left[O_x\right]+1,$ 其间可以发现一些新的满足条件的历史操作O_t。不难看出，对于一个历史操作O’，每发现一个直接因果依赖于操作O’且与操作O_R并发的操作，算法就会就把

Successor[O’]加1，如果

Successor[O’]等于DSC[O’]，就把这些操作都被放入candidates。

以下是FindConcurrentHistoryOperations算法的伪代码描述：

并发历史操作查找算法

(FindConcurrentHistoryOperations)

输入：O_R-待同步的因果就绪的远程操作

输出：

-HB中所有与O_R并发的操作组成的集合

算法：

1： ${\hat{C}}_R:=\mathrm{NULL}$

2：candidates：＝DCH

3： ${\hat{C}}_R\mathrm{Successor}:=\mathrm{NULL}$

4：将O_R加入DCH

5：repeat

6：    examinee：＝candidates

7：    candidates：＝NULL

8：    for all O_H in examinee do

9：         if O_HO_R then

10：             if O_H∈DCH then

11：                  将O_H从DCH中删除

12：             endif

13：             DSC[O_H]：＝DSC[O_H]+1

14：        else

15：            将O_H添加进

16：            for all OO_H do

17：                 if ${\hat{C}}_R\mathrm{Successor}\left[O\right]=\mathrm{NULLthen}$

18： ${\hat{C}}_R\mathrm{Successor}\left[O\right]:=1$

19：                 else

20： ${\hat{C}}_R\mathrm{Successor}\left[O\right]:={\hat{C}}_R\mathrm{Successor}\left[O\right]+1$

21：                 end if

22： $\mathrm{if}{\hat{C}}_R\mathrm{Successor}\left[O\right]=\mathrm{DSC}\left[O\right]\mathrm{then}$

23：                    将O加入candidates集合

24：                 end if

25：           end for

26：         end if

27：    end for

28：until ca ndidates为空

29：

3判断任意两个历史操作间的因果并发关系

由于每个远程操作执行前，都会找出所有之前执行过的与之并发的操作，在这一过程中，事实上已经“算”出了该操作与所有之前执行的操作间的因果并发关系。本发明的想法是，将这一结果以合适的方式缓存下来。利用因果关系缓存，任意历史操作间的因果并发关系判断，其过程可以得到大大的简化，有可能实现较为高效的解决方案。

基于上述分析，我们提出了构造因果关系缓存(Build_Cache)方法，和任意历史操作间的因果并发关系判断(CausalityDetection)方法。

Build_Cache过程以一个操作O_R的历史并发操作集

为输入，对它做压缩，删除冗余，并返回压缩后的版本

算法中，函数SITE(O)的返回值是操作O的生成站点，函数GEN_SEQ(O)的返回值是操作O的生成序号。

具体步骤如下：

(1)算法遍历史并发操作集

中的每一个操作O_H，

(2)如果[SITE(O_H)]为空集(NULL)，这意味着操作O_H是

中遍历到的第一个由站点SITE(O_H)生成的与操作O_R并发的操作，则用O_H的生成序号初始化

[SITE(O_H)]，

(3)如果

[SITE(O_H)]不为NULL，我们比较GEN_SEQ(O_H)与

[SITE(O_H)]，用MIN(GEN_SEQ(O_H)，

[SITE(O_H)])更新[SITE(O_H)]。

Build_Cache的伪代码描述如下：

构造因果关系缓存(Build_Cache)

输入：

-操作O_R的历史并发操作集

输出：

-操作O_R的历史并发操作集被压缩后的结果

算法：

1： $C\widehat{C:}=\mathrm{NULL}$

2：for all O_H in

do

3： $\mathrm{ifC}\hat{C}\left[\mathrm{SITE}\left(O_H\right)\right]=\mathrm{NULLthen}$

4： $C\hat{C}\left[\mathrm{SITE}\left(O_H\right)\right]:=\mathrm{GEN}\_\mathrm{SEQ}\left(O_H\right)$

5： $\mathrm{elseifC}\hat{C}\left[\mathrm{SITE}\left(O_H\right)\right]>\mathrm{GEN}\_\mathrm{SEQ}\left(O_H\right)\mathrm{then}$

6： $C\hat{C}\left[\mathrm{SITE}\left(O_H\right)\right]:=\mathrm{GEN}\_\mathrm{SEQ}\left(O_H\right)$

7：    end if

8：end for

9：return

基于这种因果关系缓存的任意历史操作间因果并发关系判断算法(CausalityDetection)的具体步骤如下：

(1)比较它们的执行序号；

(2)假定本地站点上O_a在O_b之前被执行，于是只可能有O_a→O_b或O_a||O_b；如果O_b是本地操作，那么必然有O_a→O_b。

(3)如果O_b是远程操作，则检查因果关系缓存，如果 $C{\hat{C}}_b\left[\mathrm{SITE}\left(O_a\right)\right]=\mathrm{NULL}$ 或 $C{\hat{C}}_b\left[\mathrm{SITE}\left(O_a\right)\right]>\mathrm{GEN}\_\mathrm{SEQ}\left(O_a\right),$ 则说明O_a→O_b，不然，可以断定O_a||O_b。

CausalityDetection的伪代码描述如下：

任意历史操作间的因果并发关系判断

(CausalityDetection)

输入：O_a，O_b-两个任意的历史操作

输出：relation-O_a与O_b之间的因果并发关系

算法：

1：if EXEC_SEQ(O_a)＜EXEC_SEQ(O_b)then

2：     if O_b是本地操作then

3：          return(O_a→O_b)

4： $\mathrm{elseifC}{\hat{C}}_b\left[\mathrm{SITE}\left(O_a\right)\right]=\mathrm{NULLorC}{\hat{C}}_b\left[\mathrm{SITE}\left(O_a\right)\right]>\mathrm{GEN}\_\mathrm{SEQ}\left(O_a\right)\mathrm{then}$

5：          return(O_a→O_b)

6：     else

7：          return(O_a||O_b)

8：     end if

9：else

10：    if O_a是本地操作then

11：         return(O_b→O_a)

12： $\mathrm{elseifC}{\hat{C}}_a\left[\mathrm{SITE}\left(O_b\right)\right]=\mathrm{NULLorC}{\hat{C}}_a\left[\mathrm{SITE}\left(O_b\right)\right]>\mathrm{GEN}\_\mathrm{SEQ}\left(O_b\right)\mathrm{then}$

13：         return(O_b→O_a)

14：    else

15：         return(O_b||O_a)

16：    end if

17：end if

本发明能很好的适应一类特殊的大规模协同环境，在这种环境中，可能会有大量的成百上千甚至更多的协同参与者，用户不断地动态地加入或离开协同环境，没有任何通知或警告，然而协同参与者的活跃程度并不高。本发明可供用户在任意规模的实时组编辑环境中使用，其执行性能与协同参与者的活跃程度，与协同环境的规模、协同参与者的总数无关，所以特别适合并发程度不高的大规模协同环境下的实时组编辑。

附图说明

，图1为实例1操作流程图示。

具体实施方式

下面结合两个例子来详细介绍因果并发检测过程。

例子1说明基于直接因果先序向量时间戳判断操作是否因果就绪的详细过程，通过分析我们发现其中的一个操作不是因果就绪的，而另一个操作是因果就绪的。

例子2是对FindConcurrentHistoryOperations执行过程的一个详细演示，通过该过程我们可以找出历史记录中所有与当前操作并发的操作。

例子1

如图1所示，考虑操作O₁₂在站点2上的执行：

1.当操作O₁₂刚到达站点2时：此时，站点2上已经执行过的操作有O₁₁，O₂₁，O₃₁，O₂₂和O₃₂，其状态向量为SV_s2＝[(1，1)，(2，2)，(3，2)]。操作O₁₂的直接因果先序向量时间戳中存在一个分量(4，1)，而此时的SV_S2[S₄]＝0，由此可以推断，操作O₁₂直接因果依赖于的操作O₄₁还没有在站点2上执行过，O₁₂不是因果就绪的。

2.当站点2上执行完远程操作O₄₁之后：此时，站点2上已经执行过的操作有O₁₁，O₂₁，O₃₁，O₂₂，O₃₂和O₄₁，其状态向量为SV_s2＝[(1，1)，(2，2)，(3，2)，(4，1)]。操作O₁₂的直接因果先序向量时间戳为DCV(O₁₂)＝[(1，1)，(4，1)]，对于DCV(O₁₂)中的每一个分量(S_i，N_i)都有SV_S2[S_i]＞N_i，由此可以推断，操作O₁₂已经因果就绪，可以在站点2上安全地执行。

例子2

还是考虑图1中的实时组编辑场景，假设在站点4上，当操作O₃₂执行过后，又收到一个新的远程操作O₅₁，它的直接因果先序向量时间戳为[(3，2)，(4，1)]。显然O₅₁是因果就绪的。考虑FindConcurrentHistoryOperations(O₅₁)的执行过程。

开始时，FindConcurrentHistoryOperations将集合变量candidates根据DCH初始化为{O₁₂，O₃₂，O₄₂}。FindConcurrentHistoryOperations比较操作O₁₂与O₅₁之间的因果并发关系，由于O₅₁中不存在与操作O₁₂相对应的分量，O₁₂不可能直接因果先序于O₅₁，因此O₁₂||O₅₁，于是，O₁₂被加入

索引表变量Successor也作了相应的调整，调整后 ${\hat{C}}_R\mathrm{Successor}=\left[(O_{11},1)(O_{41},1)\right],$ 由于DSC[O₁₁]＝3，DSC[O₄₁]＝2，没有新的操作被加入到candidates。FindConcurrentHistoryOperations随后比较O₃₂与O₅₁之间的因果并发关系，根据O₅₁的直接因果先序向量时间戳，可以判断O₃₂O₅₁，FindConcurrentHistoryOperations将O₃₂从DCH列表中移除，并调整DSC[O₃₂]的值为1，这一过程中，不会有新的操作被加入到candidates。之后，FindConcurrentHistoryOperations继续比较O₄₂与O₅₁之间的因果并发关系，类似的，根据O₅₁的直接因果先序向量时间戳，可以判断于是O₄₂||O₅₁，O₄₂被加入

Successor被调整，调整后的 ${\hat{C}}_R\mathrm{Successor}=\left[(O_{11},1)(O_{41},2)(O_{22},1)\right],$ 由于DSC[O₄₁]＝2，DSC[O₂₂]＝1，即 ${\hat{C}}_R\mathrm{Successor}\left(O_{41}\right)=\mathrm{DSC}\left[O_{41}\right],$ ${\hat{C}}_R\mathrm{Successor}\left(O_{22}\right)=\mathrm{DSC}\left[O_{22}\right],$ 我们知道HB中所有因果先序依赖于O₄₁和O₂₂的操作都已被证明与O₅₁并发，这两个操作被加入candidates。果先序于O₅₁，因此O₁₂||O₅₁，于是，O₁₂被加入

索引表变量Successor也作了相应的调整，调整后 ${\hat{C}}_R\mathrm{Successor}=\left[(O_{11},1)(O_{41},1)\right],$ 由于DSC[O₁₁]＝3，DSC[O₄₁]＝2，没有新的操作被加入到candidates。FindConcurrentHistoryOperations随后比较O₃₂与O₅₁之间的因果并发关系，根据O₅₁的直接因果先序向量时间戳，可以判断O₃₂O₅₁，FindConcurrentHistoryOperations将O₃₂从DCH列表中移除，并调整DSC[O₃₂]的值为1，这一过程中，不会有新的操作被加入到candidates。之后，FindConcurrentHistoryOperations继续比较O₄₂与O₅₁之间的因果并发关系，类似的，根据O₅₁的直接因果先序向量时间戳，可以判断，于是O₄₂||O₅₁，O₄₂被加入 Successor被调整，调整后的 ${\hat{C}}_R\mathrm{Successor}=\left[(O_{11},1)(O_{41},2)(O_{22},1)\right],$ 由于DSC[O₄₁]＝2，DSC[O₂₂]＝1，即 ${\hat{C}}_R\mathrm{Successor}\left(O_{41}\right)=\mathrm{DSC}\left[\left(O_{41}\right)\right],$ ${\hat{C}}_R\mathrm{Successor}\left(O_{22}\right)=\mathrm{DSC}\left[O_{22}\right],$ 我们知道HB中所有因果先序依赖于O₄₁和O₂₂的操作都已被证明与O₅₁并发，这两个操作被加入candidates。第1轮循环结束时，操作集合candidates的状态变为{O₄₁，O₂₂}。在第2轮的循环中，类似的，FindConcurrentHistoryOperations分别检查O₄₁，O₂₂与O₅₁的因果并发关系，O₄₁直接因果先序于O₅₁而O₂₂与O₅₁互为并发操作。第2轮循环结束时，记数值DSC[O₄₁]被调整为3，

的状态为{O₁₂，O₄₂，O₂₂}，Successor的状态为[(O₁₁，2)，(O₄₁，2)，(O₂₂，1)，(O₂₁，1)，(O₃₁，1)]，由于DSC[O₁₁]＝3，DSC[O₂₁]＝3，DSC[O₃₁]＝3，在这一轮检查中，没有新的操作被加入candidates，candidates操作集合的状态变为φ。检测到candidates操作集合的状态变为空，算法到此也就自然终止了，集合 ${\hat{C}}_{51}=\{O_{12},O_{42},O_{22}\}$ 作为执行结果被返回。

Claims (1)

1.一种大规模协同环境下的因果并发检测方法，其特征在于具体步骤如下：

1)判断一个远程操作是否因果就绪，其步骤为：对于站点S上一个尚未执行的远程操作Or，

(1)找出所有它的直接因果依赖于的那些操作；

(2)对于每一个这样的操作，判断是否已经在站点S上得到了执行，操作Or是因果就绪的，当且仅当对于DCV(Or)中的每一个分量(Si，Ni)都有SVs[Si]＞Ni，其中，i为协同站点编号；SVs站点S上的状态向量；

2)找出与当前远程操作并发的所有历史操作，采用并发历史操作查找算法，找出与当前远程操作并发的所有历史操作，其步骤为：

(1)该算法的输入为待同步的因果就绪的远程操作，输出为历史记录中与该操作并发的操作组成的集合；设candidates是一个操作集合，它初始包含DCH中的所有操作，从这些操作开始，以因果顺序相反的顺序检查历史操作缓存中的历史操作，这里，candidates为候选并发操作集；

(2)对candidates中的每个操作OH，检查它是否直接因果先序于Or，如果OHOr，则检查OH是否是DCH中的元素，如果是，就将它从DCH中移除，同时根据DSC的定义调整DSC记录，将DSC[OH]的值增1；

(3)如果

则将OH加入

同时调整

数据结构，算法对每一个满足OxOH的操作Ox调整 ${\hat{C}}_R\mathrm{Successor}\left[\mathrm{Ox}\right]:={\hat{C}}_R\mathrm{Successor}\left[\mathrm{Ox}\right]+1,$ 其间可以发现一些新的满足条件的历史操作Ot，对于一个历史操作O’，每发现一个直接因果依赖于操作O’且与操作Or并发的操作，就把

加1，如果

等于DSC[O’]，就把这些操作都被放入candidates；

3)判断任意两个历史操作间的因果并发关系，

(1)构造因果关系缓存过程：以一个操作O_R的历史并发操作集为输入，对它做压缩，删除冗余，并返回压缩后的版本

算法中，函数SITE(O)的返回值是操作O的生成站点，函数GEN_SEQ(O)的返回值是操作O的生成序号；

具体步骤如下：

1)算法遍历史并发操作集

中的每一个操作O_H；

2)如果

为空集，意味着操作O_H是中遍历到的第一个由站点SITE(O_H)生成的与操作O_R并发的操作，则用O_H的生成序号初始化

3)如果

不为空，则比较GEN_SEQ(O_H)与

用MIN(GEN_SEQ(O_H)，

更新

(2)任意历史操作间因果关系判断方法的步骤为：

①比较它们的执行序号；

②假定本地站点上O_a在O_b之前被执行，于是只可能有O_a→O_b或O_a||O_b；如果O_b是本地操作，那么必然有O_a→O_b：

③如果O_b是远程操作，则检查因果关系缓存，如果

或 $C{\hat{C}}_b\left[\mathrm{SITE}\left(\mathrm{Oa}\right)\right]>\mathrm{GEN}\_\mathrm{SEQ}\left(\mathrm{Oa}\right),$ 则说明O_a→O_b，不然，可以断定O_a||O_b；

其中，相关定义如下：

(1)直接因果先序关系()，给定两个任意的操作O_a和O_b，O_a直接因果先序于O_b，记为O_aO_b，当且仅当(1)O_a→O_b并且(2)不存在一个操作O_c，满足O_a→O_c且O_c→O_b；

(2)直接因果先序向量时间戳，简称DCV，给定一个操作O，假设O₁，O₂，...，O_k是所有直接因果先序于O的操作，O₁是站点S₁上产生的第N₁个操作，O₂是站点S₂上产生的第N₂个操作，....，O_k是站点S_k上产生的第N_k个操作，定义操作O的直接因果先序向量时间戳为[(S₁，N₁)，(S₂，N₂)，...，(S_k，N_k)]，记为DCV(O)；

(3)DCH为直接因果先序历史操作表；DSC为直接因果后继计数器，是一个二维映射表，它为每个历史操作O记录着HB中直接因果依赖于它的操作数目，记为DSC(O)：HB为历中操作表；

是历史记录中所有有待同步的远程操作并发的操作组成的集合，初始置为空(NULL)，

是一个以操作序列号为索引的索引表，对于每一个历史操作O，

都初始为O。

Images