CN100465899C - 基于虚拟内核对象的Linux程序检查点用户级实现方法 - Google Patents

Abstract

本发明公开了一种基于虚拟内核对象的Linux程序检查点用户级实现方法，在应用层与系统API层之间插入检查点层，其中检查点层包括应用线程检查点控制层和内核对象状态跟踪记录与对象引用映射层，应用层对系统API的调用被重定向到检查点层；对应用线程设置执行位置标志；控制应用线程的检查点不落入内核对象状态跟踪记录与对象引用映射层、系统API层和内核层中。本发明在用户级为Linux应用程序进程在不同机器之间的迁移，为进程在动态环境下基于检查点的正确恢复提供支持，以实现负载平衡、系统容错和高效软件排错。

Description

基于虚拟内核对象的Linux程序检查点用户级实现方法

技术领域

本发明涉及一种捕获Linux应用程序进程状态，以及恢复进程状态使其继续执行的方法，具体是一种基于虚拟内核对象的Linux程序检查点用户级实现方法。

背景技术

进程检查点可以分别在操作系统级、用户级或者应用级实现，各有其特点。操作系统级实现的进程检查点对用户程序透明，容易得到进程的内核数据结构，但需要修改系统内核，其可配置性和移植性差，检查点开销也大。用户级的进程检查点将检查点功能实现部分编译为一个库并链接到应用程序，可以实现对应用程序透明，具有易于配置且开销较小的特点。不过其实现机制与操作系统平台相关，平台移植性较差。应用级检查点的优点是能够实现平台无关性，可在不同的操作系统间移植，其不足之处是对应用的限定多，只能对部分应用程序有效。

由于用户级的进程检查点具有对应用程序透明、易于配置、开销较小且实用等特点，因此很多检查点系统都选择在用户级实现。Unix、Windows、Linux是目前使用最广的操作系统，在用户级实现进程检查点都已有一些方法。

进程状态包括用户空间状态和内核空间状态。用户空间状态在进程用户地址空间和CPU寄存器中，在用户级可以直接对其进行访问。内核空间状态是指与目标进程相关的系统内核对象及其状态。内核空间由操作系统管理，在用户级不能对其直接进行访问。现有获取内核空间状态的方法是跟踪进程对系统API的调用，然后基于跟踪信息来判定内核空间状态。

进程用户空间状态和内核空间状态存在耦合关系，即用户空间状态中存有内核空间中相关对象的引用。在用户级对系统内核对象进行访问操作，要求通过调用系统API来实现。在用户级通过调用系统API来创建(打开)系统内核对象时，操作系统返回一个对象引用。随后应用程序对内核对象的访问都是使用对象引用作为标识参数调用相应系统API来完成。在恢复时，系统重启，使用检查点信息来恢复进程状态，使进程从检查点状态继续执行。现有内核空间状态恢复方法是使用检查点信息通过系统API调用来完成。这种内核空间状态恢复方法不能实现严格一致的恢复，恢复后的用户空间状态和内核空间状态的耦合关系有可能被打破。具体来说，就是恢复时操作系统所给的对象引用与保存在用户空间状态中的对象引用不一定相同。这种对象引用不重现特性给进程恢复执行带来问题。故障恢复后的执行中，应用程序会使用恢复前的对象引用去访问恢复后所创建的内核对象，导致应用程序恢复执行失败。

针对该问题，现有解决方法包括对象引用复制方法和虚拟对象方法。在对象引用复制方法中，恢复时反复调用对象引用复制函数，直至系统返回一个相同的引用值。该方法的问题是有可能复制不出一个相同的引用值而使恢复失败。在虚拟对象方法中，应用程序使用虚拟对象引用访问内核对象，检查点系统负责管理虚拟对象引用和真实对象引用，在应用程序访问内核对象时负责把虚拟对象引用转换成真实对象引用。做检查点时，在用户级对应用线程的控制是一种异步操作，应用线程的检查点位置具有不确定性。当应用线程检查点位于系统API调用代码、系统API代码或者内核代码中时，检查点中记录的内核对象状态可能与真实的内核对象状态不一致。虚拟对象方法依然存在恢复不成功的隐患。图1为恢复不成功的例子。我们知道，程序可看作由计算、系统API调用这样的单元串接而成。图1中假定应用线程检查点落在设置文件指针这个系统API代码中。重启恢复执行会有如下两个问题：1)使用原来的文件引用(h＝1)去访问恢复后的内核文件对象(由于不能严格一致恢复，文件引用已变为h＝3)，执行失败；2)即使恢复后没有引用问题，恢复时使用检查点信息把文件指针恢复为p＝5，设置文件指针API调用返回后，p＝8，而实际应该等于5，产生逻辑错误。

发明内容

针对现有技术存在的上述缺陷，本发明旨在提供一种基于虚拟内核对象的Linux程序检查点用户级实现方法，改变程序执行中的函数调用关系，使得原有的不可控耦合关系变成可控的耦合关系，控制应用线程检查点不落在系统API调用代码、系统API代码或者内核代码中；本发明是一种捕获Linux应用程序进程状态，以及恢复进程状态使其继续执行的方法，在用户级为Linux应用程序进程在不同机器之间的迁移，为进程在动态环境下基于检查点的正确恢复提供支持，以实现负载平衡、系统容错和高效软件排错。

为达到上述发明目的，本发明的技术方案是：一种基于虚拟内核对象的Linux程序检查点用户级实现方法，在应用层与系统API层之间插入检查点层，其中检查点层包括应用线程检查点控制层和内核对象状态跟踪记录与对象引用映射层，应用层对系统API的调用被重定向到检查点层；对应用线程设置执行位置标志：当应用线程的执行从应用层移入检查点层时，置位其执行位置标志，当应用线程的执行从应用线程检查点控制层返回应用层时复位其执行位置标志；控制应用线程的检查点不落入内核对象状态跟踪记录与对象引用映射层、系统API层和内核层中，进程检查点实现方法如下：

进程启动执行时，执行检查点初始化例程，完成系统API截获，即系统API调用重定向、检查点线程创建、检查点参数读取操作；该进程的进程检查点过程包括如下三个阶段：

1)使该进程的所有应用线程进入检查点就绪状态；该进程的检查点线程置位检查点标志，触发检查点中断信号；该进程的所有应用线程的执行将被中断，转去执行中断例程，在中断例程中，应用线程如果发现自己的执行位置标志在复位状态，则调用检查点例程；对执行位置标志为置位状态的应用线程，其执行从中断例程返回，并将移入应用线程检查点控制层，调用检查点例程；在检查点例程中，应用线程释放其拥有的所有同步对象，获取自身线程上下文，然后进入检查点就绪状态，等待进程状态快照完成；

2)进程状态快照获取：在该进程的所有应用线程进入检查点就绪状态后，该进程的检查点线程做进程状态快照，包括该进程的应用线程上下文、所有虚拟内核对象、应用线程栈，以及该进程中应用程序使用的堆、全局变量、申请的内存数据块；

3)执行恢复：进程状态快照完成后，该进程的检查点线程触发所有应用线程恢复执行：应用线程恢复拥有其在第一阶段释放的同步对象，然后等待检查点线程的通知，在所有应用线程都恢复拥有其同步对象之后，检查点线程触发所有应用线程恢复执行，运行态线程恢复其正常执行，等待态线程则重新调用等待API函数进入等待状态。

基于检查点的进程恢复执行过程如下：

进程重启执行时，主线程首先调用检查点初始化例程，然后检查是否为进程恢复。如果是，则执行恢复例程。在恢复例程中，主线程首先读取要恢复的检查点，然后基于检查点信息恢复所有虚拟内核对象，并通过系统API调用创建相应同步对象，将其状态设为相应虚拟内核对象的状态，再以线程上下文所在内存地址为传递参数创建子线程。子线程入口函数不是原有线程函数，而是一个只包含调用系统API函数siglongjmp()语句的函数。被创建的子线程一启动就使用传递参数调用系统API函数siglongjmp()恢复其线程上下文。主线程创建完子线程后，从检查点中读取自己栈指针值，然后调用一递归函数来减小自己栈指针，直至其小于检查点中保存的值，然后使用检查点数据，恢复进程用户空间状态，其中包括自己线程栈数据(从保存的栈指针至栈底这段内存中的数据)，子线程栈数据，堆，全局变量，以及应用申请的内存数据块。最后主线程调用系统API函数siglongjmp()恢复其线程上下文。在所有应用线程恢复了上下文之后，检查点线程触发所有应用线程恢复执行。应用线程恢复其原拥有的同步对象，然后等待检查点线程的通知。在所有应用线程都恢复拥有其同步对象之后，检查点线程触发所有应用线程恢复执行。运行态线程恢复其正常执行，等待态线程则重新调用等待API进入等待状态。至此，进程恢复完毕。

本发明的工作原理详细描述如下：

所述基于虚拟内核对象的Linux程序检查点用户级实现方法，在应用层与系统API层之间插入虚拟内核对象层(检查点层)，应用代码不再直接通过调用系统API去访问内核对象了，而是被重定向去访问对应的虚拟内核对象。对应用层请求的操作，虚拟内核对象再调用相应系统API来完成。这样，系统API层对应用层就不再可见(即透明)。虚拟内核对象跟踪记录相应内核对象的属性值，同时维护两个对象引用值：提供给应用层的虚拟对象引用值，相应内核对象的真实对象引用值。真实对象引用值只对虚拟内核对象可见，对应用层不可见。这样真实对象引用值在用户地址空间中的存储就具有了可管理性，检查点系统能够管理其内存存储地址。针对上述虚拟内核对象，须要对应用线程的检查点进行控制。对应用线程检查点的控制有两个要求：1)保证虚拟内核对象的属性值与相应内核对象的属性值完全一致；2)在用户空间状态中，真实对象引用值除了出现在对应虚拟内核对象的成员变量中外，不能出现在其它任何地方(例如线程栈中)。真实对象引用值出现在其他地方是完全可能的，例如，当虚拟内核对象调用系统API时，它将作为传递参数出现在线程栈中。

在本发明方法中，检查点层分成两层：应用线程检查点控制层和内核对象状态跟踪记录与对象引用映射层，应用线程检查点控制层控制其下的代码段就检查点而言以原子方式执行，即线程检查点不落入其中，以满足上述应用线程检查点控制要求。

具体的控制方法如下：程序启动执行时，主线程首先调用检查点初始化例程，完成系统API截获(系统API调用重定向)、检查点线程创建、检查点参数读取等操作。系统API截获的目的是在应用层与系统API层之间插入检查点层，也称之为虚拟内核对象层。检查点线程的功能是与应用线程协同来完成进程检查点和进程恢复。

上述系统API截获为已有技术，虚拟内核对象类的定义也可参照系统API确定。关键点是应用线程检查点的控制，其控制方法如下：

应用线程检查点控制层的开始操作就是宣布调用线程进入系统调用(给线程的执行位置标志置位)，结尾操作是宣布调用线程从系统调用返回(给线程的执行位置标志复位)。当要做检查点时，检查点线程设置检查点标志，触发检查点中断信号。在此时刻点，应用线程可分两类：1)其执行位置标志为复位状态；2)其执行位置标志为置位状态。任一应用线程只可能属于一类。执行位置标志为复位状态的线程肯定为运行态线程。而执行位置标志为置位状态的线程可能为运行态线程，也可能为等待态线程。在检查点线程触发检查点中断信号后，所有应用线程的执行将被中断，转去执行中断例程。在中断例程中，应用线程首先检查自己的执行位置标志，如果在复位状态，表明其中断点在应用层中，满足应用线程检查点控制的两个要求，于是调用检查点例程。如果执行位置标志在置位状态，表明其中断点不在应用层中，应用线程检查点控制的两个要求可能不能得到满足，因此不能调用检查点例程，只能从中断例程直接返回，继续执行。对运行态的应用线程，其执行将会迅速移入应用线程检查点控制层，调用检查点例程。运行态的线程在检查点例程中释放其拥有的同步对象，获取自身线程上下文，然后进入检查点就绪状态，等待进程状态快照的完成。等待态的应用线程从中断例程返回后继续处于等待态。不过当运行态的线程在检查点例程中释放其拥有的同步对象之后，等待态的应用线程会被唤醒，转为运行态，其执行也会移入应用线程检查点控制层，调用检查点例程，释放其拥有的同步对象，进入检查点就绪状态。因此这种策略能够保证所有应用线程都将调用检查点例程，而且其检查点不会落入内核对象状态跟踪记录与对象引用映射层、系统API层和内核层中，以满足线程检查点控制的两个要求。

为了做检查点，所有应用线程都释放了其拥有的同步对象，等待态的应用线程也转到了运行态。在做完了检查点之后，原有的状态必须得到恢复。因此恢复分两个阶段：1)所有应用线程恢复其在检查点标志被设置时刻点之前拥有的同步对象；2)运行态线程恢复其正常执行，而等待态线程则重新调用等待API进入等待状态。只有所有应用线程都完成第一阶段恢复之后，第二阶段才能开始，以保证应用线程之间的同步逻辑关系不被改变。

综上所述，本发明是一种捕获Linux应用程序进程状态，以及恢复进程状态使其继续执行的方法，在用户级为Linux应用程序进程在不同机器之间的迁移，为进程在动态环境下基于检查点的正确恢复提供支持，以实现负载平衡、系统容错、高效软件排错。

附图说明

图1是现有检查点实现方法示意图；

图2是本发明中进程状态耦合关系分解与一致性控制策略示意图；

图3是本发明中应用线程的检查点控制策略示意图；

图4是实施例中检查点线程与应用线程之间协同做进程检查点的时序图；

图5是实施例中进程从检查点状态恢复执行的时序图。

在附图3中中断例程①，应用线程检查点控制例程②和③，检查点例程④和⑤的具体内容分别如下：

中断例程(见图3①)：

如果检查点标志在置位状态，并且调用线程的执行位置标志在复位状态，

则调用检查点例程④；

应用线程检查点控制例程②(见图3②)：

置位调用线程的执行位置标志；

如果检查点标志在置位状态，则调用检查点例程④；

应用线程检查点控制例程③(见图3③)：

如果检查点标志在置位状态，则调用检查点例程⑤；

复位调用线程的执行位置标志；

检查点例程④(见图3④)：

(1)调用线程释放其持有的同步对象；

(2)调用线程获取其线程上下文；

(3)调用线程宣布其进入检查点就绪状态；

(4)调用线程等待进程状态快照的完成；

(5)调用线程恢复拥有其在(1)中释放的同步对象；

(6)调用线程宣布其进入检查点完成状态；

(7)调用线程等待恢复执行通知；

对pthread_mutex_lock之类的使线程进入等待态的同步系统API截获，其检查点例程⑤(见图3⑤)：

(1)调用线程释放刚才由此同步API返回而获得的同步对象；

(2)调用线程释放其已持有的同步对象；

(3)调用线程获取其线程上下文；

(4)调用线程宣布其进入检查点就绪状态

(5)调用线程等待进程状态快照的完成；

(6)调用线程恢复拥有其在(2)中释放的同步对象；

(7)调用线程宣布其进入检查点完成状态；

(8)调用线程等待恢复执行通知；

(9)调用线程调用对应同步API重新进入等待状态；

对非同步API的截获，其检查点例程⑤(见图3⑤)与上述检查点例程④相同。

具体实施方式

参照图4。该实施例中：在检查点时刻，进程中有三个线程：T1，T2，T3，有2个同步对象：互斥M1，M2。线程T1持有M1，在执行态；线程T2持有M2，它调用了pthread_mutex_lock()系统API，在等待态，进一步等待M1；线程T3调用了pthread_mutex_lock()系统API在等待态，等待M2。在检查点时刻，检查点线程置位检查点标志，并调用signal()给线程T1，T2，T3发送检查点中断信号。T1，T2，T3被中断，转去执行检查点中断例程。在检查点中断例程(见图3①)中，T1检查检查点标志在置位状态，并且自己的执行位置标志在复位状态，于是调用检查点例程④(见图3④)。T1在检查点例程④中，释放M1，调用sigsetjmp()系统API获取线程上下文，然后调用barrier()系统API等待进程检查点的完成。线程T2在检查点中断例程中，检查自己的执行位置标志在置位状态，于是直接返回，继续保持等待状态。在线程T1释放M1后，线程T2会被唤醒。当T2的执行前移至检查点控制代码③(见图3③)时，发现检查点标志在置位状态，于是调用检查点例程⑤(见图3⑤)。在检查点例程⑤中，T2先释放刚持有的M1，然后释放自己持有的M2，然后调用sigsetjmp()获取线程上下文，然后调用barrier()等待进程检查点的完成。T3和T2一样，在T2释放M2之后，结束等待状态，在检查点例程⑤中，释放刚持有的M2，然后调用sigsetjmp()获取线程上下文，然后调用barrier()等待进程检查点的完成。在所有应用线程(T1，T2，T3)都调用了barrier()之后，检查点线程被唤醒，它知道所有应用线程都进入了检查点就绪状态，于是捕获进程状态快照(包括所有应用线程栈中的数据，堆，全局数据区，应用申请的内存数据块，以及所有虚拟内核对象，各应用线程的线程上下文)并保存到可靠存储体上。做完进程状态快照之后，检查点线程调用barrier()恢复线程T1，T2，T3的执行。线程T1恢复对M1的持有后，调用barrier()进入同步状态。线程T2恢复对M2的持有后，也调用barrier()进入同步状态。在所有应用线程都恢复持有其同步对象之后，她们同步恢复执行。线程T1继续执行，线程T2调用pthread_mutex_lock()系统API重新等待M1，线程T3调用pthread_mutex_lock()系统API重新等待M2。所有线程都复原到检查点之前的状态。

图5为进程基于上述检查点的恢复执行时序过程。在进程恢复时，程序以恢复方式重新启动。主线程T1在检查点初始化中完成截获系统API和创建检查点线程后，读取要恢复的检查点，执行恢复例程。

在恢复例程中，主线程基于检查点信息恢复所有虚拟内核对象，创建同步对象(互斥M1和M2)，然后以线程上下文所在内存地址为传递参数创建子线程T2和T3。子线程入口函数不是原有线程函数，而是一个只包含调用siglongjmp()系统API语句的函数。被创建的子线程一启动就使用传递参数并调用siglongjmp()恢复其线程上下文。T2和T3上下文被恢复后，在检查点例程⑤(见图3⑤)中接着执行barrier()进入同步状态，等待恢复完成。

主线程从检查点中读取自己栈指针值，然后调用一递归函数来减小自己栈指针，在递归函数中，通过检查递归函数中的局部变量的内存地址来判断栈指针是否小于检查点中保存的栈指针值。如果小于，则说明自己的栈已经比检查点中的栈大，足以包容检查点中的栈数据。主线程基于检查点信息，恢复所有进程状态(包括自己线程栈数据(从保存的栈指针至栈底这段内存中的数据)，子线程栈数据，堆，全局变量，以及应用程序使用的内存数据块)。然后调用siglongjmp()恢复自己线程上下文。主线程上下文被恢复后，在检查点例程④(见图3④)中接着执行barrier()，进入同步状态，等待恢复。

一旦所有线程都调用barrier()后，他们便同步继续执行。它们执行检查点过程的第三阶段。主线程T1恢复对M1的持有，T2恢复对M2的持有。在持有关系全部恢复之后，它们同步恢复执行。T1恢复正常执行，T2和T3调用pthread_mutex_lock()系统API重新进入等待状态。进程状态恢复完毕。

Claims (1)

1、一种基于虚拟内核对象的Linux程序检查点用户级实现方法，其特征在于，在应用层与系统API层之间插入检查点层，其中检查点层包括应用线程检查点控制层和内核对象状态跟踪记录与对象引用映射层，应用层对系统API的调用被重定向到检查点层，对应用线程设置执行位置标志：当应用线程的执行从应用层移入检查点层时，置位其执行位置标志，当应用线程的执行从应用线程检查点控制层返回应用层时复位其执行位置标志；控制应用线程的检查点不落入内核对象状态跟踪记录与对象引用映射层、系统API层和内核层中，进程检查点实现方法如下：

进程启动执行时，执行检查点初始化例程，完成系统API截获、检查点线程创建、检查点参数读取操作；该进程的进程检查点过程包括如下三个阶段：

1)使该进程的所有应用线程进入检查点就绪状态；该进程的检查点线程置位检查点标志，触发检查点中断信号；该进程的所有应用线程的执行将被中断，转去执行中断例程，在中断例程中，应用线程如果发现自己的执行位置标志在复位状态，则调用检查点例程；对执行位置标志为置位状态的应用线程，其执行从中断例程返回，并将移入应用线程检查点控制层，调用检查点例程；在检查点例程中，应用线程释放其拥有的所有同步对象，获取自身线程上下文，然后进入检查点就绪状态，等待进程状态快照完成；

2)进程状态快照获取：在该进程的所有应用线程进入检查点就绪状态后，该进程的检查点线程做进程状态快照，内容包括该进程的应用线程上下文、所有虚拟内核对象、应用线程栈，以及该进程中应用程序使用的堆、全局变量、申请的内存数据块；

3)执行恢复：进程状态快照完成后，该进程的检查点线程触发所有应用线程恢复执行：应用线程恢复拥有其在第一阶段释放的同步对象，然后等待检查点线程的通知，在所有应用线程都恢复拥有其同步对象之后，检查点线程触发所有应用线程恢复执行，运行态线程恢复其正常执行，等待态线程则重新调用等待API函数进入等待状态。

Images