一种获得传统操作系统动态更新时间点的方法

技术领域

本发明主要涉及到计算机操作系统软件领域，特指一种获得传统操作系统动态更新时间点的方法。

背景技术

操作系统动态更新是指在操作系统运行过程中动态修复操作系统内部缺陷，而无需重启计算机即可实现修复生效。操作系统的动态更新技术可以有效提高系统的可用性。

绝大多数缺陷修复都涉及到将当前内核的一部分功能实现体(以下称旧实现体)，替换成新的实现体(以下称新实现体)。功能替换一般通过为内核增加新实现体，并将对于旧实现体的调用重定向到新实现体上来完成。

在有任务正在执行旧实现体对应的代码时，将对于旧实现体的调用重定向到新实现体上可能会造成有的任务执行旧实现体，而与此同时有的任务在执行新实现体的情形。由于新旧实现体可能采取不同的方式对系统状态进行修改，两种实现体同时运行很可能会造成系统状态被破坏。

有的操作系统动态更新机制支持在有任务正在使用旧实现体的代码时就进行动态更新。为了避免出现上述系统状态因两个新旧实现体同时运行而被破坏的问题，这类方法会动态为新旧实现体创建各自的系统状态，并通过内存的写保护机制维护这两份系统状态的一致性。这种方式的缺陷为：1)需要同步的系统状态因具体的动态更新补丁而异，因而需要具体的补丁手工编写相应的状态同步算法；2)由于采用了写保护机制，这种方式的运行时开销相当大。

有的操作系统动态更新机制支持进行新旧实现体执行现场的转换，在进行动态更新时，若发现某任务正在执行旧实现体代码，系统可以动态将其转换为正在执行新实现体代码。由于动态更新可能在任意时刻发生，需要设计一个支持将任意执行现场状态转换为动态更新后对应现场状态的转换机制。这种转换机制的设计难度相当大。

大多数的操作系统动态更新机制要求只有在内核处于新旧实现体替换不会影响系统正常运行的时间窗口内(下文称作动态更新安全点)时才能实施动态更新。此类机制一般将旧实现体代码处于静默状态视作内核处于动态更新安全点。代码处于静默状态的判断标准为：当前没有任何任务执行旧实现体代码。具体判断方法为扫描所有任务的内核栈，查看其栈上是否包含旧实现体对应的虚地址段。若旧实现体对应的虚地址不在任何任务的内核栈中出现，就认为当前旧实现体处于静默状态。

当动态更新包含对多个功能实现体的替换时，上述更新时间点安全性检查的判断方法可能会因为忽略了功能体执行的上下文而出现问题。比如假设某个动态更新要求同时更新func_A和func_B两个功能，且某个任务会先后执行这两个功能，但在动态更新发生时，该任务处于“已执行完成func_A，但未开始执行func_B”的状态。传统的安全点检查方法认为可以进行动态更新，但这会造成更新的非原子性：该任务执行了旧实现体的func_A，却执行了新实现体的func_B。若新版本func_B是上下文相关的，系统就会因为执行了旧 版本的func_A之后执行新版本的func_B而出现错误。

由于存在上述多个功能实现体之间的上下文相关性，当动态更新涉及到不止一个功能实现体时，“旧实现体处于静默状态”并不一定意味着“系统处于动态更新安全点”。一种简单的解决方法是要求更多的代码处于静默状态。具体的说，是要求整个内核代码都处于静默状态。此时，不可能出现一次系统调用中既使用旧实现体，又使用新实现体，从而保证了更新的原子性。K42就采用了这样的方法。

在K42系统的动态更新实现中，当准备进行动态更新时，用户任务从用户态转到内核态执行的请求会被阻塞，等已在内核态执行的任务退出内核态后，就进行动态更新。对于传统操作系统而言，由于用户任务之间可能具有依赖关系(如某个已在内核的用户任务可能等待另外一个用户任务唤醒)，这种不加区分阻塞用户任务的方法会导致有些情况下永远不能进行动态更新。另外，这种方法没有考虑某些内核任务永远不会从内核态退出的情形。

为了防止在内核中睡眠的任务阻碍整个内核进入静默状态，在有的操作系统动态更新机制中，在实施动态更新时，所有正在使用内核的任务将被杀死。由于无法区分任务对于用户的重要程度，此方法可能会导致对用户至关重要任务被杀死，从而影响系统持续为用户提供服务的能力。

在基于动态更新安全点的动态更新技术中，传统方法的缺点是：1)反复检查当前是否处于静默状态的方法可能延迟较大，且最终不一定能获得更新时机；2)当动态更新包含对多个功能实现体的替换时，通过扫描所有任务的内核栈，查看其栈上是否包含旧实现体对应的虚地址段的方法获得的更新时机可能会造成更新后状态的不一致；3)通过杀死任务来获得更新时机的方法会影响用户应用运行。

发明内容

本发明要解决的问题在于：为传统操作系统提供一种通用的动态更新安全点的获取方法。

为此本发明提出一种基于任务阻塞和唤醒机制的操作系统动态更新安全点获取方法。

该方法要求外部环境必须支持以下能力：1)操作系统实时维护当前系统中存在的用户态任务总数和内核态任务总数；2)操作系统应对外暴露某用户态任务是否会因内核设计原因在未来解除操作系统对另外某些用户态任务的阻塞。

当内核态任务可能会在非动态更新安全点被阻塞时，该方法要求外部环境必须具有以下能力：操作系统对外暴露各个内核态任务是否处于安全更新点的状态。在本发明中，若某任务的当前状态可以不经专门的状态转换即可运行于动态更新后的系统，则认为该任务处于安全更新点状态。

当内核态任务可能会在非动态更新安全点被阻塞时，若操作系统具有如下能力，该方法可以更快的到可对操作系统实施动态更新的安全点：1)操作系统对外暴露内核态任务之间的同步通信关系；2)操作系统可对外暴露所有支持“中间状态恢复”的内核态任务：一个内核任务支持中间状态恢复，当且仅当该任务可在睡眠中被杀死，并支持重启后继续进行被杀死时正在提供的服务。

当动态更新工具支持如下能力时，该方法可以更快的发现可对操作系统实施动态更新的安全点：1)动态更新工具支持对某些被阻塞任务的执行现场进行转换，使得这些任务可以在动态更新完成后继续正常运行。

在本发明中，内核与操作系统含义相同。

在决定进行动态更新后，该方法开始工作，其过程如下：

1)设定当前要进行动态更新；2)向所有用户任务注入用于防止其在内核中无限期睡眠的异步事件。内核对该异步事件的处理方法应与用户任务所能接收到的普通异步事件相似，但效果为导致用户任务重新请求当前被中断的内核服务；3)当发现用户任务task请求系统服务时，若内核未被设计为task未来一定会解除内核对其它某任务的阻塞，则在为其服务前将其阻塞，且该阻塞方法不可被异步事件唤醒；4)杀死所有(本发明自身所需的任务除外)当前未处于安全更新点、支持中间状态恢复的内核任务；5)当运行优先权最低的任务发现所有的用户任务(本发明自身所需任务除外)都因步骤3)规定的动作所阻塞、且所有的内核任务(本发明自身所需任务除外)都处于安全更新点时，实施动态更新；6)动态更新完成后，设定当前不处于动态更新状态；7)重启被杀死的内核任务，唤醒因步骤3)被阻塞的所有任务。

由于动态更新时必须保证所有的CPU都处于动态更新安全点，而多处理器核心有时使得系统很难到一个全局更新安全点。如：即使运行在CPU0上的最低优先权任务发现CPU1也正在运行同样的最低优先权任务，它也不能断定当前可安全实施动态更新：因为CPU1当前可能正在运行中断处理例程。为了解决此问题，本发明采取了基于在线控制CPU是否参与运行的方法来加速更新点的发现过程，其特征在于利用操作系统的CPU在线控制机制，在准备进行动态更新前，将多处理器或多核系统降级为单处理器核心系统，然后实施动态更新，最后将系统恢复为动态更新前系统具有的处理器核心数量。

在大部分情况下，可在决定进行动态更新后即对系统进行处理器核心数量降级，这样可以简化本发明中相关算法的设计，并可快速到动态更新的安全点。但开发人员也可将降级的时机选取为处理器核心空闲时，即：在决定进行动态更新后若某CPU空闲了，则该CPU将被在线禁止参与运行，除非它不能被禁止参与运行，或本身是最后一个活跃的CPU。虽然后一种在线降级的方法通常性能较差，但因其实现比较复杂，故本发明将针对后者进行说明。

如图1所示，本发明内容为安全点监测模块M10，其运行依赖于传统动态更新机制模块M20、启动实施动态更新的工具模块M40，被更新的操作系统内核为模块M30。其中安全点监测模块M10内部包括初始化子模块M100、事件注入子模块M101、安全点生成子模块M102、系统服务接口子模块M103、安全点创建子模块M104。本发明提出的安全点监测模块M10用于发现可使用传统动态更新机制M20获取对操作系统内核M30安全进行动态更新的时机。

安全点监测模块M10的各个组成部分功能如下：

初始化子模块M100

当用户通过动态更新的工具M40发出动态更新请求时，初始化子模块M100开始执行，其流程为：

步骤1：将当前系统降级为单处理器核心系统；

初始化子模块M100可通过调用操作系统内核M30的“系统处理器核心数量在线降级”功能，将当前系统在线降级为单处理器核心的系统。安全点监测模块M10的开发人员也可以选择在初始化子模块M100中不执行此步骤，而是将在线降级留到安全点生成子模块M102中实现。

步骤2：标记系统当前处于STATE状态；

STATE状态指示当前准备对操作系统内核M30进行动态更新，且动态更新尚未完成。步骤3：令所有的CPU都运行事件注入子模块M101；

步骤4：安装安全点创建模块M104；

当安全点生成子模块M102以用户任务形式运行时，需要在内核安装安全点创建子模块M104，供安全点生成子模块M102调用使用。当安全点生成子模块M102本身就在内核态运行时，不需要本步骤。

事件注入子模块M101

事件注入子模块M101的作用是使那些“可能会在操作系统内核M30中阻塞、但可通过异步事件解除阻塞的用户任务”能尽快从内核离开，而不会在操作系统内核M30中被无限期阻塞。在实现操作系统内核M30时，事先可以知道某些系统调用可能会被异步事件中断，如在Linux中，内核在执行“从文件中读取数据”的系统调用时可能会因该任务接收到信号而从内核返回用户态。向执行此种类型系统调用的用户任务注入异步事件可以确保该用户任务在任何情况下都可以从内核离开，而不会阻塞在内核中。事件注入子模块M101对于解除用户任务之间的运行依赖关系至关重要。

例如对于任务A通过管道向任务B传递数据的情形。当管道空时，任务B执行对管道的“阻塞式读取”系统调用(即：若管道为空，将任务B阻塞，直到管道变为非空，返回读取的数据)将导致其被阻塞。将任务A阻塞会导致其不能向管道写入数据，从而造成任务B一直被阻塞在内核中，所以无法到动态更新的安全点。

在本发明中，事件注入子模块M101向任务B注入异步事件，可保证即使任务A被阻塞，任务B也可以离开内核。

事件注入子模块M101实现为系统内具有最高运行优先权的先进先出型实时任务，其主体执行流程如下：

步骤1：忙等待所有CPU都执行到此处；

步骤2：屏蔽外部中断；

步骤3：针对本CPU负责检查的每个用户任务，注入异步事件Signal。

理论上，只需向“通过可被异步事件中断的系统调用进入操作系统内核M30的”用户任务注入动态更新唤醒异步事件即可。但也可要求操作系统内核M30在具体处理异步事件时对对应任务做如下两个检查：a)是通过系统调用进入操作系统内核M30；b)该系统调用可以被异步事件中断。若某任务不能通过a)b)两个检查，则操作系统内核M30就丢弃该异步事件，从而可将事件注入简单实现为“向所有的用户任务都注入此异步事件”。

对于只向通过可被异步事件中断的系统调用进入内核的用户任务注入异步事件的情形，可通过检查任务内核栈的方法来获取该任务的系统调用信息。事件注入子模块M101开发者可通过查看手册或系统调用实现体的源代码来获得所有可被异步事件中断的系统调用。

步骤4：忙等待，直到所有的CPU都执行到此处；

步骤5：开放外部中断。

步骤1、2、4的用途是用来保证在执行步骤3时，本CPU负责检查的用户任务不会发生变化，否则可能会因任务迁移而导致漏掉对某些用户任务注入异步事件Signal。若操作系统内核M30保证在执行步骤3期间，任务不会从待检查任务列表中迁出，则步骤1、2、4、5是不必要的。

系统服务接口子模块M103

为了能够安全实施对于操作系统内核M30的动态更新，需让所有的任务都离开操作系统内核M30中可能会影响动态更新安全性的代码。由于处理用户任务的系统调用或异常可能会执行影响动态更新安全性的代码，为此应尽量阻止用户任务通过系统调用或异常从用户态进入内核。

但在有些时候，内核被设计为用户任务之间一定会存在某种运行依赖关系，如要求用户任务T必须在用户任务TS请求了某种内核服务之后才能运行。以Linux中通过vfork创建的子线程为例。在Linux中，线程T通过vfork创建子线程TS时，线程T将被阻塞，直到线程TS执行execve或exit系统调用时才被唤醒。

此时，若传统动态更新机制模块M20支持进行动态更新前后任务T执行现场的转换，则系统可以忽略这种依赖关系，将T视作进入了不影响动态更新安全性的状态；若传统动态更新机制模块模块M20不支持对任务T进行动态更新前后执行现场的转换，则需要对任务TS做特殊的处理，防止它在“解除系统对任务T的阻塞“之前被阻塞。本发明支持上述两种情形。不过由于在设计内核时很少人为引入这种任务间的运行依赖关系，建议传统动态更新机制模块M20的开发者根据需要开发任务T的执行现场转换功能。

在本发明中，系统服务接口子模块M103用来实现上述对于用户任务的系统调用和异常处理的选择性阻塞，其流程如下：

步骤1：保存现场，切换到内核代码执行环境

步骤2：若当前不处于STATE状态，则转到步骤7，否则继续执行

步骤3：若操作系统内核M30期望当前任务TS在未来解除“内核对另外某任务T的阻塞”，则继续执行，否则转到步骤6

此步骤要求内核M30提供对“任务TS未来是否会解除对其它任务的阻塞”的查询支持。步骤4：若传统动态更新机制模块M20无法将任务T的执行现场转换为动态更新实施后的新状态，则转到步骤7，否则继续执行，此步骤要求操作系统内核M30提供对“依赖于任务TS解除阻塞的任务及其依赖原因”的查询支持。若操作系统内核M30不提供此支持，则视作应转到步骤7的情形；

此步骤要求传统动态更新机制模块M20支持对特定场景进行动态更新前后状态转换，若不支持针对操作系统内核M30报告的依赖场景进行转换，则视作应转到步骤7的情形。

步骤5：不影响动态更新安全性的用户任务数加1，将任务T添加到待转换执行现场的任务列表

步骤6：不影响动态更新安全性的用户任务数加1，睡眠等待系统不处于STATE状态

在本步骤中，需要操作系统内核M30保证异步事件Signal不会唤醒在本步骤中睡眠的任务。

在执行本步骤时，若当前系统中只有一个在线的处理器核心(如：初始化子模块M100已将当前系统降级为单处理器情形)，且当前任务是最后一个需被安全点监测模块M10阻塞的用户任务，则也可以不令本任务进入睡眠等待状态，而是执行子安全点生成模块M102。此时安全点生成子模块M102将作为系统服务接口系统服务接口子模块M103的一个组成部分获得执行权。

步骤7：执行相应的系统调用服务处理函数

步骤8：恢复现场，返回到用户态代码执行环境

步骤7和步骤8的实现流程与传统操作系统的实现相同。

安全点生成子模块M102

若可保证在运行系统服务接口子模块M103时系统内只有一个在线的处理器核心(如在初始化子模块M100中已对系统的处理器核心数进行了在线降级)，则可在系统服务接口子模块M103发现当前任务是最后一个需被安全点监测模块M10阻塞的用户任务时执行安全点生成子模块M102；也可将安全点生成子模块M102作为一个具有最低运行优先权的任务运行。若在动态更新前未将系统降级为单处理器核心情形，则本发明要求每个处理器核心在其空闲时都要运行安全点生成子模块M102。下面以每个处理器核心都要在空闲时运行安全点生成子模块M102的情形介绍M102的流程，其它的情形时的处理流程可以通过对下述流程进行简化获得。

安全点生成子模块M102的主要功能是检查操作系统内核M30是否在所有的CPU上都处于静默状态，若是则实施动态更新。由于其它CPU可能在接收中断，故即使本CPU上的安全点生成子模块M102发现其它CPU都在执行安全点生成子模块M102，也不代表当前所有的CPU都处于静默状态。为了简化系统的设计，本发明采取了处理器数量动态降级的方法。具体的说，当某个CPU执行安全点生成子模块M102时，它将退出参与运行，从而可保证在动态更新完成前，该CPU一定不会再执行动态更新之外的内核代码。当系统降级为单处理器核心情形后，操作系统内核代码在本CPU上处于静默状态就代表了在所有CPU上都处于静默状态。

安全点生成子模块M102的主要流程为：

步骤1：若本CPU必须要参与运行，则转到步骤3，否则继续执行；

在有些操作系统中，有的处理器是不能退出参与运行的。

步骤2：若本CPU不是最后一个活跃CPU，则令本CPU退出参与运行；

CPU退出参与运行将导致其在被允许再次加入运行之前再也不能修改内核状态，操作系统内核M30也不再期望该CPU会对系统提供计算服务。

在有的系统中，这可通过调用操作系统内核M30的在线删除CPU的功能实现。

步骤3：循环：主动释放CPU，直到当前只有一个活跃CPU；

本模块可根据操作系统内核M30提供的查询当前在线处理器核心数量的机制获得当前的处理器核心数。

步骤4：关闭外部中断；

当安全点生成子模块M102以内核态任务形态运行时执行此步骤。若安全点生成 子模块M102以用户态任务形态运行时，不执行此步骤。

步骤5：若所有的用户任务都不影响动态更新的安全性，则继续执行，否则转到步骤18；

以下两种类型的任务被认为不影响动态更新的安全性：1)在执行系统服务接口子模块M103时被阻塞的任务；2)传统动态更新机制模块M20支持进行执行现场转换的任务。

当不影响动态更新安全性的用户任务数与当前系统中存在的用户任务数相等时，表明所有的用户任务都不影响动态更新的安全性。注意：安全点监测模块模块M10自身所创建的用户任务被视作不影响动态更新的安全性。

步骤6：若所有的内核任务都不影响动态更新的安全性，则继续执行，则转到步骤18；

以下三种类型的内核任务被任务不影响动态更新的安全性：1)操作系统内核M30认为该任务处于更新安全点；2)操作系统内核M30认为该任务可安全杀死；3)传统动态更新机制模块M20支持可对该任务的执行现场进行转换。注意：安全点监测模块M10自身所创建的内核任务被视作不影响动态更新的安全性。

一个内核任务是可安全杀死的是指若该任务在内核中睡眠时被杀死，操作系统内核M30支持以后通过某种方式恢复该任务的运行，使得使用此内核任务提供服务的任务不受此内核任务曾经被杀死的影响。

操作系统内核M30可对安全点生成子模块M102提供信息，供后者判断不处于安全点的任务是否是可安全杀死的。此时安全点生成子模块M102认为满足如下条件的内核任务是可安全杀死的：1)所有与该任务进行同步通信的内核任务都是可安全杀死的；2)该任务自身被实现为支持从中间状态恢复运行。

一个内核任务是可安全转换的是指若该任务在内核中睡眠，传统动态更新机制模块M20支持将其执行现场转换为实施更新后的对应现场。此时，传统动态更新机制模块M20需要针对具体的每个内核任务开发相应的执行现场转换功能，而且有些转换功能的实现还与具体的动态更新补丁相关。

步骤7：杀死所有可安全杀死的内核任务；

步骤8：若本子模块以内核态任务形态运行，则继续执行，否则转到步骤16；

步骤9：调用传统动态更新机制模块M20实施动态更新；

在传统动态更新机制模块M20实施动态更新时，进行新旧功能体的替换，也会转换可安全转换的任务现场，也为待转换执行现场列表中的所有用户任务转换现场。

步骤10：恢复在步骤7被杀死的内核任务；

步骤11：开放外部中断；

当本子模块以内核态任务形态运行时执行此步骤。若本子模块以用户态任务形态运行时，不执行此步骤。

步骤12：令所有在步骤2退出参与运行的CPU重新参与运行；

此步骤将导致在步骤2退出的那些CPU重新为操作系统内核M30提供计算服务。在有的系统中，这可通过调用操作系统内核M30的在线添加CPU功能实现。

步骤13：设置系统不再处于STATE状态；

步骤14：唤醒所有因执行系统服务接口子模块M103而被阻塞的任务；

步骤15：处理结束；

步骤16：触发导致安全点创建子模块M104执行的异常，并接收异常处理的处理结果；

步骤17：若异常处理返回值指示处理成功，则转到步骤10，否则继续执行；

步骤18：开放中断；

当本子模块以内核态任务形态运行时执行此步骤。若本子模块以用户态任务形态运行时，不执行此步骤。

步骤19：主动释放CPU；

步骤20：转到步骤4。

安全点创建子模块M104

本子模块仅当安全点生成子模块M102以用户态任务形式运行时才需要。其处理流程为：

步骤1：若所有的用户任务都不影响动态更新的安全性，则继续执行，否则返回失败；

以下两种类型的任务被认为不影响动态更新的安全性：1)在执行系统服务接口子模块M103时被阻塞的任务；2)传统动态更新机制模块M20支持进行执行现场转换的任务。

当不影响动态更新安全性的用户任务数与当前系统中存在的用户任务数相等时，表明所有的用户任务都不影响动态更新的安全性。注意：安全点监测模块M10自身所创建的用户任务被视作不影响动态更新的安全性。

步骤2：若可安全进行动态更新，则继续执行，否则返回失败；

如果内核任务都属于以下两种类型之一，则认为当前可安全进行动态更新：1)操作系统内核M30认为该任务处于更新安全点；2)传统动态更新机制模块M20支持可对该任务的执行现场进行转换。注意：安全点监测模块M10自身所创建的内核任务被视作不影响动态更新的安全性。

步骤3：调用传统动态更新机制模块M20实施动态更新；

在传统动态更新机制模块M20实施动态更新时，将转换可安全转换的任务现场，也为待转换执行现场列表中的所有用户任务转换现场。

步骤4：返回成功。

本发明的优点为对于任意类型的操作系统动态更新请求，都能快速的到可对内核实施动态更新的安全点，且不会影响用户任务的正常运行。

首先，本发明可保证到的动态更新点绝对安全。本发明发现的动态更新点具有如下特征：所有的用户任务都没有在内核态运行；所有的内核态任务都处于动态更新安全点，或者动态更新机制支持对其执行现场进行转换；在实施动态更新时没有任何内核代码在运行。

其次，本发明可以快速到动态更新安全点。首先，系统服务接口子模块M103将绝大多数用户任务都阻挡在了内核代码之外；其次，事件注入子模块M101将绝大多数在内核中睡眠等待事件的用户任务都赶出了内核，并防止了因为阻塞用户任务进入内核而导致 某些在内核的任务永远没有机会从内核退出的情况；最后，选择性杀死内核任务可加快内核处于静默状态的速度。

最后，本发明不会影响用户任务的正常运行。在寻动态更新安全点的过程中，本发明没有杀死任何用户任务，且对注入异步事件的处理对于用户任务透明。

附图说明

图1为系统的总体结构图

图2为系统的总体流程

图3为子模块M100的流程图

图4为子模块M101的流程图

图5为子模块M103的流程图

图6为子模块M102以运行优先权仅高于系统内空闲任务的任务的流程图

图7为子模块M104当子模块M102以用户态任务形式运行时的流程图

具体实施方式

图1为系统的总体结构图。本发明内容为安全点监测模块M10，它包括初始化子模块M100、事件注入子模块M101、安全点生成子模块M102、系统服务接口子模块M103、安全点创建子模块M104。模块M40为实施动态更新的工具，内核M30为欲实施更新的操作系统内核，模块M20为传统的动态更新机制，本发明提出的模块M10用于获取对内核M30安全进行动态更新的时机。

根据是否事先对系统处理器核心数量进行在线降级，可以将本发明的实施方法划分为两类，一类为在初始化子模块M100中进行处理器核心数量的在线降级，另外一类为在安全点生成子模块M102中进行处理器核心数量的在线降级。一般说来，前一类实施方法比较简单，而且可以较快的发现动态更新的安全点。但由于通过后一类实施方法可以很容易得到前一类实施方法，故下文以后一类实施方法为例进行说明。

图2为本发明工作时的主要流程。当用户通过实施动态更新的工具模块M40请求进行动态更新时，初始化子模块M100被执行，后者导致每个在线CPU都运行事件注入子模块M101。子模块M101可能会通过操作系统内核M30的任务控制功能对某些任务注入异步事件Signal。

当用户任务通过系统调用或异常进入内核时，系统服务接口子模块M103被运行。后者可能通过操作系统内核M30的任务控制功能将当前的用户任务阻塞。

当系统处于空闲时，安全点生成子模块M102被执行，它通过操作系统内核M30的CPU在线配置功能将系统中参与运行的CPU核心数量减小到1，然后再确认当前处于动态更新安全点后，调用模块M20实施更新，之后通过内核M30的CPU在线配置功能恢复参与运行的CPU数量。当子模块M102以用户态任务形式实现时，子模块M102要通过子模块M104调用模块M20。子模块M102最后通过内核M30的任务控制功能唤醒因执行子模块M103而被阻塞的用户任务。

本发明需要对内核M30的任务创建与删除、异步事件的处理等机制进行少量修改。为了方便系统较快的到动态更新安全点，最好也在编写内核任务的过程中考虑到对 于动态更新的支持间题。

以下对各个组成部分的工作流程进行详细说明。

本发明中，由模块M40启动对内核M30的动态更新，模块M40的启动动作将导致初始化子模块M100被执行，该模块执行如下步骤，如图3所示：

1标记系统处于STATE状态

2令所有的CPU都运行子模块M101

3在内核中安装安全点创建子模块M104

当安全点生成子模块M102以用户任务形式运行时，需要在内核安装安全点创建子模块M104，供子模块M102调用使用。当子模块M102本身就在内核态运行时，不需要本步骤。

在实现中，初始化子模块M101作为系统内具有最高运行优先权的实时、先进先出型任务(下称为任务T101)被执行。任务T101的个数与当前在线的总处理器核心数相同，且与各个处理器核心具有一一绑定关系。在有的实现中，任务T101由模块M10事先创建，此时子模块M100的步骤2为“唤醒所有的T101任务”；在有的实现中，M100的步骤2动态创建并运行任务T101。

对于任务T101由模块M10事先创建的情形，子模块M101的流程如图4所示：

1睡眠，等待被唤醒

2忙等待所有的CPU都执行到此处

3关闭外部中断

4对于本CPU负责检查的用户任务，注入异步事件Signal

5忙等待，直到所有的CPU都执行到此处

6开放外部中断

7转到步骤1

当任务T101由初始化子模块M100创建时，其流程为上述步骤2到步骤6。

对于步骤4，在一种实现中，由一个CPU负责向所有的用户任务注入异步事件；在另外一种实现中，所有的CPU都参与异步事件的注入工作。

步骤2、3、5的用途是用来保证在执行步骤4时，本CPU负责检查的用户任务不会发生变化，否则可能会因任务迁移而导致漏掉对某些用户任务注入异步事件Signal。若内核M30保证在执行步骤4期间，任务不会从待检查任务列表中迁出，则步骤2、3、5、6是不必要的。

当任务通过系统调用或异常进入内核时，执行系统服务接口子模块M103，其流程如图5所示：

1保存现场，切换到内核代码执行环境

2若当前不处于STATE状态，则转到步骤7，否则继续执行

3若内核期望当前任务TS在未来解除内核对另外某任务T的阻塞，则继续执行，否则转到步骤6

此步骤要求内核M30提供对“任务TS未来是否会解除对其它任务的阻塞”的查询支持。

4若模块M20无法将任务T的执行现场转换为动态更新实施后的新状态，则转到步 骤7，否

则继续执行

此步骤要求内核M30提供对“依赖于任务TS解除阻塞的任务及其依赖原因”的查询支持。若M30不提供此支持，则视作应转到步骤7的情形。

此步骤要求模块M20支持对特定场景进行动态更新前后状态转换，若不支持对M30报告的依赖场景进行转换，则视作应转到步骤7的情形。

5不影响动态更新安全性的用户任务数加1，将任务T添加到待转换执行现场的任务列表

6不影响动态更新安全性的用户任务数加1，睡眠等待系统不处于STATE状态

在本步骤中，需要保证异步事件Signal不会唤醒在本步骤中睡眠的任务。

在执行本步骤时，若当前系统中只有一个在线的处理器核心(如：子模块M100已将当前系统降级为单处理器情形)，且当前任务是最后一个需被模块M10阻塞的用户任务，则也可以不令本任务进入睡眠等待状态，而是执行子模块M102。此时子模块M102将作为子模块M103的一个组成部分获得执行权。

7执行相应的系统调用服务处理函数

8恢复现场，返回到用户态代码执行环境

步骤7和步骤8的实现流程与传统操作系统的实现相同。

安全点生成子模块M102

在一种实现中，子模块M102以运行优先权仅高于系统内空闲任务的任务(称作任务T102)运行，此时，任务T102的数量与在线处理器核心的数量相同，且与在线的处理器核心具有一一绑定关系；在另外的实现中，子模块M102本身作为系统内空闲任务(idle任务)的一部分参与运行。图6以第一种情形来说明其流程，对于第二种情形，可将空闲任务的空闲循环体进行修改，使之在系统处于STATE状态时执行下述流程即可。

步骤1：若本CPU必须要参与运行，则转到步骤3，否则继续执行；

在有些操作系统中，有的处理器是不能退出参与运行的。

步骤2：若本CPU不是最后一个活跃CPU，则令本CPU退出参与运行；

CPU退出参与运行将导致其在被允许再次加入运行之前再也不能修改内核M30的状态，内核M30也不再期望该CPU会对自身提供计算服务。

在有的系统中，这可通过调用内核M30的在线删除CPU功能实现。

步骤3：循环：主动释放CPU，直到当前只有一个活跃CPU；

本模块可根据内核M30提供的“当前在线处理器核心数量获取机制”获得当前的处理器核心数。

步骤4：关闭外部中断；

步骤5：若所有的用户任务都不影响动态更新的安全性，则继续执行，否则转到步骤16；

当不影响动态更新安全性的用户任务数与当前系统中存在的用户任务数相等时，表明所有的用户任务都不影响动态更新的安全性。注意：模块M10自身所创建的用户任务被视作不影响动态更新的安全性。

步骤6：若所有的内核任务都不影响动态更新的安全性，则继续运行，否则转到步 骤16；

当系统中所有不处于更新安全点的内核任务都是可安全杀死的或可安全转换的，则认为所有的内核任务都不影响动态更新的安全性。注意：模块M10自身所创建的内核任务被视作不影响动态更新的安全性。

一个内核任务是可安全杀死的，当且仅当若该任务在内核中睡眠时被杀死后，内核M30支持以后通过某种方式恢复该任务的运行，且使用此内核任务提供服务的任务不受此内核任务曾经被杀死的影响。

内核M30可对子模块M102提供信息，供后者判断不处于安全点的任务是否是可安全杀死的。此时子模块M102认为满足如下条件的内核任务是可安全杀死的：1)所有与该任务进行同步通信的内核任务都是可安全杀死的；2)该任务自身被实现为支持从中间状态恢复运行。

一个内核任务是可安全转换的，当且仅当若该任务在内核中睡眠，模块M20支持将其执行现场转换为实施更新后的对应现场。此时，模块M20需针对具体的每个内核任务开发相应的执行现场转换功能，且有些转换功能的实现还与具体的动态更新补丁相关。

步骤7：解决不处于更新安全点的内核任务使用内核代码的问题；

此步骤要杀死可安全杀死的内核任务，转换可安全转换的内核任务。

步骤8；若本子模块以内核态任务形态运行，则继续执行，否则转到步骤16；

步骤9：调用模块M20实施动态更新；

在M20实施动态更新时，进行新旧功能体的替换，也会转换可安全转换的任务现场，也为待转换执行现场列表中的所有用户任务转换现场。

步骤10：恢复在步骤7被杀死的内核任务；

步骤11：开放外部中断；

当本子模块以内核态任务形态运行时执行此步骤。若本子模块以用户态任务形态运行时，不执行此步骤。

步骤12：令所有在步骤2退出参与运行的CPU重新参与运行；

此步骤将导致在步骤2退出的那些CPU重新为内核M30提供计算服务。在有的系统中，这可通过调用内核M30的在线添加CPU功能实现。

步骤13：设置系统不再处于STATE状态；

步骤14：唤醒所有因执行子模块M103而被阻塞的任务；

步骤15：处理结束；

步骤16；触发导致子模块M104执行的异常，并接收异常处理的处理结果；

步骤17：若异常处理返回值指示处理成功，则转到步骤10，否则继续执行；

步骤18：开放中断；

当本子模块以内核态任务形态运行时时执行此步骤。若本子模块以用户态任务形态运行时，不执行此步骤。

步骤19：主动释放CPU；

步骤20：转到步骤4。

安全点创建子模块M104

本子模块仅当安全点生成子模块M102以用户态任务形式运行时才需要。它是异 常处理例程，图7为其处理流程：

1若所有的用户任务都不影响动态更新的安全性，则继续执行，否则返回失败

以下两种类型的任务被认为不影响动态更新的安全性：1)在执行子模块M103时被阻塞的任务；2)模块M20支持进行执行现场转换的任务。

当不影响动态更新安全性的用户任务数与当前系统中存在的用户任务数相等时，表明所有的用户任务都不影响动态更新的安全性。注意：模块M10自身所创建的用户任务被视作不影响动态更新的安全性。

2若可安全进行动态更新，则继续执行，否则返回失败

如果内核任务都属于以下两种类型之一，则认为当前可安全进行动态更新：1)内核M30认为该任务处于更新安全点；2)模块M20支持可对该任务的执行现场进行转换。注意：模块M10自身所创建的内核任务被视作不影响动态更新的安全性。

3调用模块M20实施动态更新

在M20实施动态更新时，将转换可安全转换的任务现场，也为待转换执行现场列表中的所有用户任务转换现场。

4返回成功

对操作系统内核M30的修改

为保证本发明的实施，需要对操作系统内核M30进行修改，使其满足：1)实时维护当前系统中存在的用户态任务总数和内核态任务总数；2)对外暴露内核态任务之间的同步通信关系；3)对外暴露各个内核态任务是否处于安全更新点的状态；4)对外暴露所有的可中断恢复的内核态任务；5)对外暴露用户态任务之间的运行依赖关系。另外，还需要为操作系统内核M30增添一种新型的异步事件Signal及其处理机制。具体修改内容如下：

1、实时维护当前系统中存在的用户态任务和内核态任务情况

一般来说，操作系统内核M30已有机制向外界提供当前系统存在的任务信息，但操作系统内核M30的开发者可对操作系统内核M30进行少量修改，使得模块M10可以更容易实现。如：操作系统内核M30可增加用于反映当前内核中存在的用户任务的内存变量，使得模块M10可利用该内存变量直接获得当前系统中的用户任务数量。

2、对外暴露内核态任务之间的同步通信关系

内核任务之间的同步通信关系是模块M10用来判断内核任务是否可安全杀死的依据之一。内核M30的开发者需要在编写内核任务时，说明内核任务之间的同步通信关系，并支持外界获取任务间的同步通信关系。

3、对外暴露各个内核态任务是否处于安全更新点的状态；

如果某个内核任务在实施内核动态更新后可以不经专门的执行现场转换就可继续正常运行，则该任务被认为是处于安全更新点。内核M30的开发者可以根据潜在的动态更新范围，确定当任务运行哪部分代码时可被认为是处于安全更新点，并在这些代码段的开始和结束位置设置模块M10可见的标记。

一般说来，一个内核任务在执行“判断是否有请求需要处理，若无则睡眠等待”这样代码时就可以认为是处于安全更新点。

4、对外暴露所有可中断恢复的内核任务

有些内核任务在开发过程中可能已考虑了对动态更新的支持问题。如：内核M30 为这些任务提供“暂停”和“继续”接口，使得模块M10可以在动态更新前将这些任务暂停，在动态更新完成后使用“继续”功能使内核任务继续工作。在实现上，一种简单的方法是将任务编写为启动后检测上次退出情况，若发现有以前的中间状态则接着上次的现场运行。

5、对外暴露用户态任务是否被其它任务依赖

内核M30需要记录“因内核设计原因，哪些用户任务未来将解除内核对另外某些任务的运行阻塞”，并对模块M10暴露此信息的访问接口。

如对于Linux系统中的线程数据结构中的vfork_done数据结构可对外界指示该线程是否会解除内核对于父线程的阻塞。

6、异步事件Signal的处理

需为内核M30增添一种新的异步事件Signal，用于防止某些用户任务因为“其它用户任务在执行子模块M103时被阻塞”而在内核中阻塞。内核M30对于异步事件Signal的处理方法为：查询该用户任务进入内核的原因，若它是通过“可被异步事件中断的系统调用”进入内核，则要求该任务重新执行本次系统调用(该系统调用会导致此用户任务在执行子模块M103时被阻塞)；否则仅是简单将此事件清除。