[发明专利]一种基于异步检查点的多线程软件动态升级方法

说明书

技术领域

本发明属于软件可靠性研究中的安全领域，更具体地，涉及一种基于异步检查点的多线程软件动态升级方法。

背景技术

为了针对提供7/24小时服务可靠性，从软件的角度考虑，传统的软件更新方法通常要求停止软件的运行，应用更新后再次重启软件方可完成。这样的停止——重启方式不可避免地破坏了运行服务的执行，降低了软件的可用性。从硬件的角度，有的方案可以在增加服务器镜像的前提下实现动态迁移，待到升级完毕后，将数据重新同步回主服务器，从而保证应用(服务)的可靠性，然而这种方案需要购买额外的冗余硬件，大大的增加了维护成本。综上所述，基于异步检查点的多线程软件动态升级方案将能够很好的提升在线程序(服务)的可靠性，减少宕机时间，增加盈利。为了解决以上问题，动态软件更新(DSU)孕育而生，并且成为目前急切需要的新技术。在动态软件更新当中，多线程支持又是一个新的挑战，因为线程执行相同的函数并试图修改相同的数据，这样很难保证数据的一致性。

一般来讲，很多现存的方法都是基于更新点(待更新的数据和代码当前还未被调用的位置称为更新点)。这样在更新一个运行系统的时候只有在某些特定执行点才能应用，例如待更新的代码没有被执行，数据未被引用的时候，否则系统很容易出现不一致的状态。

基于更新点的方法有几个缺点。首先能够找到安全更新点在很大程度上依赖于编译器或程序员的分析能力。对于像C语言一样灵活的语言，编译器经常很难分析指针和别名。因此，它们不得不做出保守的假设，分析结果中可能产生误报。虽然最近提出的建议有利于转换编译器使程序变得可更新，但是他们的方法仅适用于单线程应用程序，并且无法维持二进制兼容性。所以，它不能用于编译的二进制文件和当前的运行软件。其次，很难在多线程软件中找到更新点，一个繁忙的系统中某些模块甚至可能没有一个安全点。当涉及数据变化时，对于多线程软件无法分析其可更新性。如果不能及时到达或检测到更新点，某些安全更新将会延迟，脆弱的系统可能暴露在外部攻击之下。最后，对于一些基于更新点机制的动态更新系统，操作员可能在动态更新进程中没有任何控制权，在系统到达安全更新点应用更新时，操作员将一无所知。如果操作员无法知晓系统是否已经完成当前更新，另一个处于进展中的更新可能在不经意间应用。

综上所述，现有的动态软件升级系统的方案存在如下不足：

有的方案(例如UpStare)需要依赖特定的编译器，在重新编译源程序时添加相关的动态升级辅助代码，这对于已经部署的应用程序是行不通的；有的方案(例如Polus)无法更新正在执行的函数，需要等待函数调用完毕才能生效，这意味着如果主函数有改动，则直到程序退出应用程序将永远无法动态升级成新的版本；有的方案则只对单线程应用程序有效，显然在多线程应用程序如此流行的今天，这也是不实用的。

发明内容

针对现有技术的以上缺陷或改进需求，本发明提供了一种基于异步检查点的多线程软件动态升级方法，其目的在于，解决现有针对已经部署的多线程应用程序进行动态升级中出现的上述技术问题，确保升级的可行性，使得更新过程不会处于无限期的等待中。

为实现上述目的，按照本发明的一个方面，提供了一种基于异步检查点的多线程软件动态升级方法，包括以下步骤：

(1)获取待升级软件的新旧版本，分别提取新旧版本中的项目源文件，并分别将该新旧版本的项目源文件整合；

(2)对整合后的新版本的项目源文件和旧版本的项目源文件进行对比，以生成初级补丁；

(3)将异步检查点插入初级补丁中，以生成动态升级补丁，其中异步检查点中保存了待升级软件的新旧版本的延续点的映射关系；

(4)将生成的动态升级补丁加载到运行中的待升级软件的旧版本中；

(5)接收用户的初始化请求，并根据该初始化请求使用动态升级补丁中待更新的函数名查找内存中对应的函数体，并将步骤(3)中的异步检查点插入该函数体中；

(6)接收用户的应用请求，并根据该应用请求利用异步检查点算法使待升级软件中的所有线程达到阻塞状态；

(7)对于待升级软件中的线程中未被使用和执行的函数及变量，采用二进制重写的方式实现函数的间接跳转，对于待升级软件中的线程中正在使用和执行的函数及变量，采用堆栈重构的方式进行映射和状态转换；

(8)根据动态升级补丁中异步检查点中保存的新旧版本的延续点的映射关系恢复执行所有线程，过程结束。

优选地，步骤(1)是采用通用中间语言中的合并功能进行项目源文件的整合。