实时协同编程环境下的语义冲突消解方法与流程

本发明涉及计算机支持的协同工作技术领域，尤其涉及一种实时协同编程环境下的语义冲突消解方法。

背景技术：

冲突消解是实时协同编程系统中的重要研究课题，是保证系统正确性和可用性的关键性技术。针对实时协同编程系统的冲突问题解决方法主要分为两大类：冲突消解方法和冲突避免方法。冲突消解方法允许协同编程过程中发生冲突，一旦有冲突发生则使用相应的策略来消除冲突，从而保证共享文档的一致性。近些年，冲突消解方法研究中最常用的一致性维护技术主要分为两大类：基于操作转换ot技术和基于地址转换（addressspacetransformation）ast技术，其中包括ellis和gibbs在文献中提出的dopt算法，sun和ellis在文献中提出的got和goto算法，sun在文献中提出的cot算法以及gu等人在文献中提出的ast算法等。冲突避免方法是指在冲突发生前避免冲突发生，该方法一般采用加锁的方式来避免冲突产生，即当用户对某对象进行操作时需要先申请加锁，只有申请成功的用户才能操作该对象。fan和sun在文献中提出的dal技术,以动态加锁的方式实现实时协同编程环境的语义冲突避免，并采用sharing-lock的方法处理并发加锁的问题。该方法虽有效的避免了语义冲突的发生，但在一定程度上限制了协同编程的效率，且频繁的加锁与解锁会加大对系统资源的开销。针对语义冲突处理这一问题，sun等人在文献提出基于ot技术采用多版本技术解决2d文档模型下垂直交叉的冲突，既维护了所有操作意愿，也维护了文档的一致性；gao等人在文献中提出的crscm策略，实现了参照操作与其它并发操作的语义维持。传统的加锁方法对协同编程的限制较大，在避免冲突的同时限制了对其它代码域的编辑。

技术实现要素：

本发明所要解决的技术问题是提供一种实时协同编程环境下的语义冲突消解方法，本方法克服传统语义冲突消解方式的缺陷，基于并发冲突处理技术实现语义冲突消解，节省系统资源开销，在避免冲突的同时实现对其它代码域的编辑，提高了实时协同编程的效率。

为解决上述技术问题，本发明实时协同编程环境下的语义冲突消解方法包括如下步骤：

步骤一、基本定义，基础域为一系列源代码组成的语义有意义且独立的代码域，开放域为基础域之外的所有代码域；

依赖关系，若基础域a依赖于基础域b,表示为a->b，如存在a->b,b->c,则a->c，将a->b，b->c称为直接依赖关系，a->c称为间接依赖关系；

依赖图，每个基础域对应一个依赖图结点，采用node->node表示依赖图之间的依赖关系，依赖图结点之间的依赖关系与其对应的基础域之间的依赖关系一致，依赖图中记录的信息为对应基础域代码文本内容，基础域之间的依赖关系通过依赖派生机制实时分析,建立或取消基础域之间的依赖关系；

步骤二、对每个基础域添加标识码，标识码为三维向量tag(0,0,0)，其中，左值表示为upstreamtag(ust)、中值表示为downstreamtag(dst)、右值表示为selfareatag(sat)，依赖图结点的标识码为对应基础域的标识码；

标识码tag中，upstreamtag表示对该基础域依赖的其它基础域的编辑操作会导致upstreamtag自加，downstreamtag表示对依赖于该基础域的其他所有基础域的编辑操作会引起downstreamtag自加，selfareatag表示编辑操作当前基础域执行后selfareatag自加，且标识码只有在编辑操作成功执行后才能自加；

标识码相同时表明该结点未被修改，否则可能存在语义冲突的情况；

步骤三、设定基础域工作状态，且每个基础域都有一个相对应的工作状态，基础域工作状态分别为：

editing:基础域处于编辑状态，

resolving:基础域处于等待处理的编辑状态，

completed:基础域处于完成编辑状态；

步骤四、采用版本技术记录编辑操作，并通过版本覆盖的方式恢复代码，多余的版本被删除或保存，代码域版本以基础域为基本单位，每个基础域都有其对应的代码域版本，创建一个新的基础域或者在代码域成功执行的操作都会创建一个新的代码域版本并存储在本地，组成基础域的历史版本，代码域的版本号为其所对应的基础域的selfareatag，若存在代码域版本恢复的情况，该基础域的标识码伴随着代码域版本恢复回退至原先值；

步骤五、将编辑操作请求定义为一个二元组<s,nq>，s(site)表示id,nq(nodequeue)={node0,node1，noden}表示用户完整编辑操作下各个结点的操作集合，

其中node为一个结构体包含以下信息：

id:结点id，用于在对端站点中找到该结点，并进行相应操作，

tag:结点标识码，用于判断语义冲突是否发生，

edittype:基础域的编辑类型，新建一个基础域用1表示，删除基础域用-1表示，编辑基础域表示为0，

rootnode:未编辑前，结点直接依赖的其它结点集合，用于判断依赖图结构是否发生变化，

newdepency:记录新增的依赖结点或减少的依赖结点，新增的结点表示为+nodeid,减少的结点标识为-nodeid，在依赖图结构发生变化时用于判断语义冲突是否发生，

nodeversion:记录当前基础域的版本信息，用于语义冲突发生时，进行代码域版本恢复；

步骤六、设定编辑操作执行许可条件，代码域工作状态为completed，代码域的标识码中除downstreamtag外其它标识码需相等，符合上述两个条件的编辑操作才能成功执行；

步骤七、判断编辑操作落入的代码域，如代码域为一个空白区域，需要新建一个基础域，并将基础域的编辑状态更新为editing，处于编辑状态下的代码域不接受其它站点的编辑操作直到编辑完成，其它站点的编辑操作需等待本地编辑完成后才能执行；

步骤八、对本地的编辑操作进行更新检查，代码域处在editing状态时，收到的远程站点的编辑操作保存在等待队列中等待执行，本地生成的编辑操作在发送之前判断等待队列是否为空，若等待队列为空，本地生成的编辑操作成功发送，否则，编辑操作不发送，将本地上已经执行的编辑操作保存，并撤销这些编辑操作，之后，执行等待队列中的编辑操作；

步骤九、若编辑操作在基础域上成功执行，在本地站点上立即生成一个新的基础域版本，版本号为立即生效后的标识码的值，版本号用于记录代码的编辑历史以及代码的恢复；

步骤十、检查编辑操作的编辑类型，若是创建一个新的基础域，编辑操作立即执行，否则，检查编辑操作请求中编辑队列的各个节点的标识码与本地将要执行该编辑操作的结点标识码是否相同，如果标识码相同，编辑操作执行，如果不同，根据标识码变化类型进行相应处理；

步骤十一、远程站点上编辑操作的执行需检测基础域的依赖情况是否变化，通过判断newdepency是否为空，若为空，编辑操作未导致依赖图结构变化，跳过依赖图动态变化的编辑许可检查，若不为空，依赖图结构发生改变，可能导致语义冲突，进行依赖图语义冲突检查，若增加了新的依赖域,则判断新增加的依赖域的标识码是否发生改变，若标识码改变，则编辑操作被拒绝；如果依赖域减少，减少的依赖域不应该再对编辑操作将要执行的结点标识码产生影响，判断upstreamtag变化的值是否受到减少的依赖域的影响，排除减少的依赖域的影响后，若标识码相同，则表明不存在语义冲突；若upstreamtag的改变不存在语义冲突，再检查其它标识码的变化情况，若其他标识码未改变，则编辑操作成功；

步骤十二、若selfareatag改变，表明存在对相同代码域的并发编辑操作，通过标识码在远程站点中的请求日志找到并发的编辑操作，对比编辑操作之间的优先级，若远程站点编辑操作请求的优先级大于当前站点的编辑操作，则进行版本恢复，并撤销该并发编辑操作对站点标识码的影响；同时检查downstreamtag是否改变，若未改变，更新成功，否则，进行downstreamtag变化检查；

步骤十三、若downstreamtag改变，表明downstreamnode中存在语义冲突的编辑操作，对比站点间的downstreamnode的selfareatag的变化情况确定是哪些代码域的编辑操作导致downstreamtag的变化；若dowmstreamnode的selfareatag不一致则表明语义冲突存在，撤销导致selfareatag变化的编辑操作，消除冲突；其中：downstreamnode表示依赖于当前节点的所有基础域节点集合。

由于本发明实时协同编程环境下的语义冲突消解方法采用了上述技术方案，即本方法通过分析语义冲突可能产生以及动态依赖语义冲突发生的场景，协同编程系统无法判断非编程语言规则错误的编辑操作是否存在语义冲突，若编辑操作为排除关系，只保留一个操作，其它编辑操作将会被拒绝或保存，考虑操作不兼容的问题及减少协同编辑限制，采用复制式结构，结合并发控制技术以及依赖图的动态变化场景实现冲突消解，维护实时协同编程语义的一致性。本方法克服传统语义冲突消解方式的缺陷，基于并发冲突处理技术实现语义冲突消解，节省系统资源开销，在避免冲突的同时实现对其它代码域的编辑，提高了实时协同编程的效率。

附图说明

下面结合附图和实施方式对本发明作进一步的详细说明：

图1为代码依赖关系图；

图2为线性表类的依赖关系图；

图3为情况1的语义冲突示意图；

图4为情况2的语义冲突示意图；

图5为本方法实例论证示意图；

图6为本方法与dal方法对比图；

图7为文档数与站点数的对比图。

具体实施方式

本发明实时协同编程环境下的语义冲突消解方法包括如下步骤：

步骤一、基本定义，基础域为一系列源代码组成的语义有意义且独立的代码域，开放域为基础域之外的所有代码域；

依赖关系，若基础域a依赖于基础域b,表示为a->b，如存在a->b,b->c,则a->c，将a->b，b->c称为直接依赖关系，a->c称为间接依赖关系；

依赖图，每个基础域对应一个依赖图结点，采用node->node表示依赖图之间的依赖关系，依赖图结点之间的依赖关系与其对应的基础域之间的依赖关系一致，依赖图中记录的信息为对应基础域代码文本内容，基础域之间的依赖关系通过依赖派生机制实时分析,建立或取消基础域之间的依赖关系；

步骤二、对每个基础域添加标识码，标识码为三维向量tag(0,0,0)，其中，左值表示为upstreamtag(ust)、中值表示为downstreamtag(dst)、右值表示为selfareatag(sat)，依赖图结点的标识码为对应基础域的标识码；

标识码tag中，upstreamtag表示对该基础域依赖的其它基础域的编辑操作会导致upstreamtag自加，downstreamtag表示对依赖于该基础域的其他所有基础域的编辑操作会引起downstreamtag自加，selfareatag表示编辑操作当前基础域执行后selfareatag自加，且标识码只有在编辑操作成功执行后才能自加；

标识码相同时表明该结点未被修改，否则可能存在语义冲突的情况；

步骤三、设定基础域工作状态，且每个基础域都有一个相对应的工作状态，基础域工作状态分别为：

editing:基础域处于编辑状态，

resolving:基础域处于等待处理的编辑状态，

completed:基础域处于完成编辑状态；

步骤四、采用版本技术记录编辑操作，并通过版本覆盖的方式恢复代码，多余的版本被删除或保存，代码域版本以基础域为基本单位，每个基础域都有其对应的代码域版本，创建一个新的基础域或者在代码域成功执行的操作都会创建一个新的代码域版本并存储在本地，组成基础域的历史版本，代码域的版本号为其所对应的基础域的selfareatag，若存在代码域版本恢复的情况，该基础域的标识码伴随着代码域版本恢复回退至原先值；

步骤五、将编辑操作请求定义为一个二元组<s,nq>，s(site)表示id,nq(nodequeue)={node0,node1，noden}表示用户完整编辑操作下各个结点的操作集合，

其中node为一个结构体包含以下信息：

id:结点id，用于在对端站点中找到该结点，并进行相应操作，

tag:结点标识码，用于判断语义冲突是否发生，

edittype:基础域的编辑类型，新建一个基础域用1表示，删除基础域用-1表示，编辑基础域表示为0，

rootnode:未编辑前，结点直接依赖的其它结点集合，用于判断依赖图结构是否发生变化，

newdepency:记录新增的依赖结点或减少的依赖结点，新增的结点表示为+nodeid,减少的结点标识为-nodeid，在依赖图结构发生变化时用于判断语义冲突是否发生，

nodeversion:记录当前基础域的版本信息，用于语义冲突发生时，进行代码域版本恢复；

步骤六、设定编辑操作执行许可条件，代码域工作状态为completed，代码域的标识码中除downstreamtag外其它标识码需相等，符合上述两个条件的编辑操作才能成功执行；

步骤七、判断编辑操作落入的代码域，如代码域为一个空白区域，需要新建一个基础域，并将基础域的编辑状态更新为editing，处于编辑状态下的代码域不接受其它站点的编辑操作直到编辑完成，其它站点的编辑操作需等待本地编辑完成后才能执行；

步骤八、对本地的编辑操作进行更新检查，代码域处在editing状态时，收到的远程站点的编辑操作保存在等待队列中等待执行，本地生成的编辑操作在发送之前判断等待队列是否为空，若等待队列为空，本地生成的编辑操作成功发送，否则，编辑操作不发送，将本地上已经执行的编辑操作保存，并并撤销这些编辑操作，之后，执行等待队列中的编辑操作；

步骤九、若编辑操作在基础域上成功执行，在本地站点上立即生成一个新的基础域版本，版本号为立即生效后的标识码的值，版本号用于记录代码的编辑历史以及代码的恢复；

步骤十、检查编辑操作的编辑类型，若是创建一个新的基础域，编辑操作立即执行，否则，检查编辑操作请求中编辑队列的各个节点的标识码与本地将要执行该编辑操作的结点标识码是否相同，如果标识码相同，编辑操作执行，如果不同，根据标识码变化类型进行相应处理；

步骤十一、远程站点上编辑操作的执行需检测基础域的依赖情况是否变化，通过判断newdepency是否为空，若为空，编辑操作未导致依赖图结构变化，跳过依赖图动态变化的编辑许可检查，若不为空，依赖图结构发生改变，可能导致语义冲突，进行依赖图语义冲突检查，若增加了新的依赖域,则判断新增加的依赖域的标识码是否发生改变，若标识码改变，则编辑操作被拒绝；如果依赖域减少，减少的依赖域不应该再对编辑操作将要执行的结点标识码产生影响，判断upstreamtag变化的值是否受到减少的依赖域的影响，排除减少的依赖域的影响后，若标识码相同，则表明不存在语义冲突；若upstreamtag的改变不存在语义冲突，再检查其它标识码的变化情况，若其他标识码未改变，则编辑操作成功；

步骤十二、若selfareatag改变，表明存在对相同代码域的并发编辑操作，通过标识码在远程站点中的请求日志找到并发的编辑操作，对比编辑操作之间的优先级，若远程站点编辑操作请求的优先级大于当前站点的编辑操作，则进行版本恢复，并撤销该并发编辑操作对站点标识码的影响；同时检查downstreamtag是否改变，若未改变，更新成功，否则，进行downstreamtag变化检查；

步骤十三、若downstreamtag改变，表明downstreamnode中存在语义冲突的编辑操作，对比站点间的downstreamnode的selfareatag的变化情况确定是哪些代码域的编辑操作导致downstreamtag的变化；若dowmstreamnode的selfareatag不一致则表明语义冲突存在，撤销导致selfareatag变化的编辑操作，消除冲突；其中：downstreamnode表示依赖于当前节点的所有基础域节点集合。

由于代码文档的高复杂性及依赖图结点关系的动态变化，极大的增加语义一致性的维护难度。对于基础域的编辑操作可能产生新的依赖关系,即调用新的方法，或是引用了新的参数，或者取消原有的依赖关系（删除了调用的方法，或是删除了引用）。基于对代码域的编辑，编辑操作对依赖图结构依赖关系的影响可以分为三种情况：

1)编辑操作产生了新的依赖关系，依赖图结构发生改变。

2)编辑操作消除了部分或全部依赖关系，依赖图结构发生变化。

3)编辑操作消除了部分或全部依赖关系，且产生了新的依赖关系，依赖图结构发生改变。

本方法对基础域、开放域以及依赖关系作出定义，如图1所示，图1左侧为三个基础域，右侧为左侧三个基础域所对应的依赖图结点。由图1可知，函数func1中引用了变量str,以及在func2中调用了函数func1,故三个基础域对应的结点间的依赖关系为c->b->a,且结点b为结点c的直接依赖结点，结点a为结点c的间接依赖结点。

代码编辑操作的基本类型如下:

1)insert():向基础域或者开放域插入新的字符；例如：insert(1,1,x)表示在第1行的位置1上插入字符x；

2)delete():删除基础域中的字符；例如:delete(1,1,6)表示删除第1行位置1之后的6个字符；

3)createarea()：创建一个新的基础域，即在开放域中插入新的字符；

4)deletearea()：删除某个基础域，即删除某个基础域中的所有字符；

5)revert()：将代码域恢复到某个代码域版本；

6)save()：保存代码域中的代码内容并生成相应代码域版本；

实际上，createarea和deletearea只是特殊的insert和delete编辑操作。

协同编程环境中语义冲突可能发生的情况如下：

1)协同编程人员对相同的代码域的并发工作；

2)协同编程人员对存在依赖关系的代码域的并发工作；

3)协同编程人员的并发工作存在依赖图结构发生改变。

例如图2所示是一个未完成的c++类，该类用于实现线性表的功能。图左侧为源代码，图右侧是源代码中基础域对应的依赖图结点，每个基础域对应一个依赖图结点，依赖图之间的依赖关系对应基础域中的依赖关系；图中空白的区域代表开放域，当协同人员工作于这个类中时将可能发生以下冲突：

情况1：并发的编辑操作相同基础域导致的语义冲突，如图3所示，在相同时间段，存在两个用户u0和u1并发的编辑图2中的结点b对应的基础域；

1)在站点0上，用户u0将delete函数的返回值类型由int类型修改为void类型；

2)在站点1上，用户u1在delete函数的函数体中添加了returnata[location]。

首先，在工作的站点上，两个用户对结点b的编辑并未引起错误，当两个站点上的操作发送到对端，通过ot算法进行了一致性维护处理后，得到的结果虽然满足了文本内容的一致性，却违背了编程语言的逻辑，经过修改后的delete方法不能有返回值，即通过ot技术处理后得到的代码内容违背了用户的编辑意愿,语义冲突发生。

情况2：并发的编辑操作存在相互依赖的代码域导致语义冲突；

如图4所示，在某一时刻，用户u0和用户u1并发的工作于结点a,与结点d(d->a).

1)在站点0上,用户u0修改变量data的数据类型，将data修改为int型的数组容器；

2)在站点1上,用户u1为指针变量data开辟内存空间。

在这部分代码中，站点0,1上两位用户的编辑操作并未引起错误，当用户的编程操作发送到对端时，语义冲突发生。冲突的原因在于用户u1对结点b的编辑基于结点a的代码,而用户u0修改了结点a中的代码；在代码同步时无法兼容两个用户的编辑操作从而导致语义冲突。

因此本方法对每个基础域添加标识码，标识码用于对比分析基础域的变化情况，通过判断标识码的变化情况，分析编辑操作是否存在语义冲突发生。例如：c->b->a，假设结点a、b、c的标识码都为(0,0,0)。当基础域b完成编辑工作。结点b的标识码sat发生改变,此时的基础域b的标识码为(0,0,1)，由于结点c依赖于结点b，因此结点c的标识码ust发生改变，结点c的标识码更新为（1,0,0）。即结点b的编辑操作执行后，影响selfareatag的同时，影响结点a的downsteamtag,结点b的upsteamtag。

对于相同结点标识码的比较，例如存在两种站点i、j，两个站点上相同结点x的标识码为(1,1,1)，即ti=(1,1,1),tj=(1,1,1)表明站点j和站点i标识码不变，没有影响结点x的编辑操作。如ti=(1,1,1),tj=(1,1,2)表明在站点j上的结点x已经发生变化；如ti=(1,1,1),tj=(2,1,1)表明在站点j上结点x依赖的其它结点发生变化；如ti=(1,1,1),tj=(1,2,1)表明在站点j上依赖于结点x的其它结点发生变化。

标识码相同时，表明该结点未被修改；若标识码不相同，可能存在语义冲突的情况，在依赖图结构不变的前提下，存在语义冲突需要进行冲突消解；若依赖图结构发生改变，需要通过对依赖图结构进行分析后，判断语义冲突是否发生后,再进行相应处理。

本方法设定基础域的工作状态，当用户进入某个基础域，该基础域的工作状态变为editing,当离开该基础域或进入新的基础域，且产生的编辑操作为完整的编辑操作将视为代码编辑完成，基础域的工作状态变为completed。部分情况，该基础域与其它基础域的内容可能存在语义冲突，或是用户的编辑操作导致了其它基础域出现编程语言规则错误及用户离开编辑未完成的基础域，此时工作状态会更新为resolving。

考虑到依赖关系动态变化及语义冲突导致编辑操作不兼容的问题，存在一些不得不撤销的编辑操作。因而很容易想到是采用ot技术的历史缓存进行undo-redo操作，但历史缓存数量较大时，undo-redo不是一个特别高效的方法。为了提高代码文档内容撤销与恢复的效率，本方法采用版本技术记录编辑操作，并通过版本覆盖的方式恢复代码，且多余的版本将被删除或是被保存。本方法提出的代码域版本是指以基础域为基本单位，每个基础域都有其对应的代码版本。在每个站点上，用户创建一个新的基础域,或者在某个代码域成功执行的操作都会创建一个新的代码域版本，存储在本地组成基础域的历史版本。代码域的版本号为其所对应的基础域的selfareatag，若存在代码域版本恢复的情况，该基础域的标识码及相关标识码需伴随着版本恢复回退至原先的值。

基础域的版本存储是有十分有意义的，复杂软件的开发往往具有较长的开发周期及庞大的代码量，可能需要对代码进行反复的修改。存储代码版本，开发人员可以通过历史版本查看代码修改历史，可以直观的判断之前的修改目的，甚至当代码出错时判断出错原因，以及不再需要担心代码内容丢失或是难以恢复。

应用本方法进行实例论证，如图5所示，站点1,2,3上的编辑操作o1,o2,o3分别用于结点a、结点c和结点e。编辑操作o1对结点a进行了修改，编辑操作o2取消了结点c对结点a的依赖，故结点a的任何变化都不再对结点e产生影响。编辑操作o3取消了结点e对结点c的依赖。当编辑操作o1到达站点2、3时，通过判断标识码未发生改变，不存在语义冲突，编辑操作o1成功执行。编辑操作o2到达站点1时检测到结点c的ust发生改变，可能存在语义冲突，由于依赖图结构发生改变，通过处理后回退结点c的标识码，与编辑操作o2的标识码相同，无语义冲突，编辑操作o2成功执行。同理操作o3也成功执行。编辑操作o4、o5和o6分别作用于站点1的结点d，站点2的结点d，站点3的结点a。当编辑操作o4到达站点2时检查到结点d的sat发生改变，此时语义冲突发生，通过处理后，撤销编辑操作o5对结点d的影响，执行编辑操作o4,编辑操作o5到达其他站点时根据定义，编辑操作将会被拒绝，由于编辑操作o6工作于独立的基础域不产生语义冲突，操作成功执行。经过本方法进行语义冲突消解后获得的代码文档满足收敛性。

对本方法进行实验分析，复杂软件的开发往往需要较长的周期，需要较多的开发人员参与，且软件的源代码文档数量较多。实验不考虑开发周期因素，将从开发人员数与源代码文档数两方面着手进行实验分析，将本方法与dal方法应用于协同编程环境进行效率对比分析。dal方法不考虑出现sharing-locking时依赖于用户交流维护代码文档情况的前提下，针对两种方法处理语义一致性维护时间进行对比。针对语义语法一致性维护时间与协同站点数量做了相关的测试，仿真协同编程环境的语义一致性维护实验。

实验1：以共享文档为实验对象，对共享文档划分代码域及依赖关系构建依赖关系表，通过修改表中数据实现本方法中标识码的改变或是dal中基础域锁的状态改变，表中数据的修改即标识相对应的代码域发生变化。从实验结果图6可以看出本方法的处理时间略小于dal方法，但相比于dal方法，本方法采用版本恢复增加了空间复杂度。同时可以看出不论是本方法或是dal方法，在文件数量固定的情况下，随着协同站点数量的增加，语义与语法一致性的维护时间都稍有提高，站点数量对协同编程环境下的语义与语法一致性维护具有一定的影响。同时为了验证代码文件数及站点数对本方法一致性维护时间的影响，进行实验2。

实验2：对三种不同协同站点数在协同文档数量相同情况下验证本方法一致性维护效率，前提条件及实验方法与实验1相同，通过增加协同编辑文件的数量检验协同工作的一致性维护时间。由图7可知，在代码文档相同时，站点数越多一致性维护时间越长。若站点数相同时，语义一致维护时间随着协同编辑的文档个数增加不断减少，且趋于平稳。

通过实验分析，可以推断本方法的实时协同编程环境较为适用于小型团队的系统开发工作。

本方法以并不是所有的并发编辑操作都导致语义冲突为出发点，针对实时协同编程环境的一致维护、不完整的编辑带来编辑错误问题以及代码文档依赖图动态依赖关系，基于cas并发处理方法实现语义冲突消解。cas(compareandswap)方法是一种较为新颖的并发冲突处理技术，其核心思想是通过对目标对象设定期望值，若操作的目标对象的期望值由于某些因素发生变化，则操作不可执行；反之，操作可执行。cas方法虽用于处理线程间资源同步问题，但用于语义冲突消解上同样适用。

本方法深入分析了协同编程环境下语义冲突、动态依赖冲突问题及不完整的编辑操作导致的编辑错误，基于cas(compareandswap)的并发控制方法实现语义冲突消解，维护实时协同编程语义一致性。本方法在windows平台下，基于qt框架及seastar异步通信框架开发了实时协同编程的原型系统,并通过相关实验进一步验证了本方法的可行性和正确性。