CN101470627B - 一种mips平台下并行多核配置锁的实现方法 - Google Patents

Abstract

本发明公开了一种MIPS平台下并行多核配置锁的实现方法，用以解决现有技术中的锁重入问题。所述方法包括：根据系统提供的基本的锁，预定义多个锁，包括：应用层系统调用加锁、应用层系统调用解锁、应用层系统调用重加锁、定时器加锁、定时器解锁、定时器重加锁；根据所述预定义的多个锁，再定义两个锁：事件响应更新锁和事件响应恢复锁；在事件响应处理过程中，当发生锁重入问题时，在事件响应函数中调用事件响应更新锁来加锁或者更新到新的锁；在事件响应函数处理结束后，调用事件响应恢复锁来解锁或者恢复到以前加的锁。通过本发明所述方法，使得多核体系结构上的操作系统具有良好的稳定性、健壮性、扩展性、安全性和并行性。

Description

一种MIPS平台下并行多核配置锁的实现方法

技术领域

本发明涉及MIPS(Microprocessor without interlocked piped stages，无内部互锁流水级微处理器)多核技术领域，尤其涉及一种MIPS平台下并行多核配置锁的实现方法。

背景技术

基于MIPS指令集的MIPS多核处理器在嵌入式系统中占据了主流地位。目前在机顶盒、信息终端、网络连接设备中占有大部分市场，而且已经进入到网络安全设备领域。在多核并行的框架上，对于一些共享资源的并行访问问题是整个体系结构中的关键技术。

Linux系统提供了最基本的锁，包括：读锁(read_lock)：对于同一资源可以同时上多个读锁，从而可以并行执行这些代码；写锁(write_lock)：对于同一资源在同一时间只能上一个写锁，且不能并行访问要保护的资源；自旋锁(spin_lock)：如果上锁不成功，就一直等下去，直到上锁成功为止。

在事件响应处理过程中，有时会出现锁重入现象，所谓锁重入现象是指，一个notifier处理函数中又触发了一个notifier事件；在现有的锁技术中，还没有解决锁重入问题的方案。

发明内容

本发明提供一种MIPS平台下并行多核配置锁的实现方法，用以解决现有技术中存在的锁重入问题。

本发明方法包括：

步骤A：根据系统提供的基本的锁，预定义多个锁，包括：应用层系统调用加锁、应用层系统调用解锁、应用层系统调用重加锁、定时器加锁、定时器解锁、定时器重加锁；

步骤B：根据所述预定义的多个锁，再定义两个锁：事件响应更新锁和事件响应恢复锁；

步骤C：在事件响应处理过程中，当发生锁重入问题时，在事件响应函数中调用事件响应更新锁来加锁或者更新到新的锁；所述步骤C具体包括：更新CPU持有的锁的类型；判断CPU持有的锁和要更新的锁的类型是否一致，如果一致，直接返回，否则判断CPU是否上锁；如果这个CPU原来没有上锁，通过调用定时器加锁或应用层系统调用加锁，直接加配置锁和链表锁；如果CPU已经上了锁，那么就通过调用定时器重加锁或应用层系统调用重加锁，保存原来持有的锁到临时变量，然后再加要更新的锁；

步骤D：在事件响应函数处理结束后，调用事件响应恢复锁来解锁或者恢复到以前加的锁；所述步骤D具体包括：恢复CPU持有的锁的类型；判断CPU持有的锁和要更新的锁的类型是否一致，如果一致，直接返回，否则判断CPU是否上锁；如果CPU原来没有锁，那么就通过调用定时器解锁或应用层系统调用解锁，直接解配置锁和链表锁；如果CPU已经上了锁，那么就通过调用定时器重加锁或应用层系统调用重加锁，解CPU要更新的锁，并且加原来持有的锁。

进一步地，所述步骤A中，所述应用层系统调用加锁中设置有两个原子计数器，则预定义所述应用层系统调用加锁的过程具体包括：

判断CPU是否上了锁，如果已经上了锁就异常退出，否则把两个原子计数器加1；

试图加配置锁，当确认加配置锁成功时，试图加链表锁；

当确认加链表锁成功时，保存进程持有的锁和保存CPU加的锁并返回，否则解配置锁，并重复试图加配置锁。

进一步地，所述步骤A中，所述应用层系统调用解锁设置有两个原子计数器，则预定义所述应用层系统调用解锁的过程具体包括：

判断CPU是否上锁，如果已经上了锁就异常退出，否则解链表锁，原子计数器app_wrconfig_locks减1；

解配置锁，并清除进程持有的锁和CPU加的锁；

原子计数器app_locks减1。

进一步地，所述步骤A中，所述应用层系统调用重加锁的预定义过程具体包括：

判断CPU是否已经上了锁，如果没加锁就异常退出，否则先依次把已经加的锁解开，然后再按新的需求依次加锁。

进一步地，所述步骤A中，预定义所述定时器加锁的过程具体包括：

原子计数器app_wrconfig_locks加1，保证其他低优先级的锁不能获得请求；

依次加配置锁和链表锁；

原子计数器app_wrconfig_locks减1，保存该CPU加的锁。

进一步地，所述步骤A中，预定义所述定时器解锁的过程具体包括：

首先解链表锁，然后解配置锁，最后清除CPU保存的锁。

进一步地，所述步骤A中，预定义所述定时器重加锁的过程具体包括：

判断CPU是否已经上了锁，如果没上锁，就异常退出，否则先依次解开已经上的锁，然后再依次加上请求的锁，并保存新的锁。

综上所述，本发明提供了一种MIPS平台下并行多核配置锁的实现方法，当发生锁重入问题时，在事件响应函数中首先调用notifier_upgrade_biglock_fun锁来加锁或者更新到新的锁，在事件响应函数处理结束后，调用notifier_restore_biglock_fun锁来解锁或者恢复到以前加的锁。通过本发明所述方法，使得多核体系结构上的操作系统能够具有良好的稳定性、健壮性、扩展性、安全性和并行性。

附图说明

图1为本发明实施例中，锁重入问题的原理示意图；

图2为本发明实施例中，定义应用层系统调用加锁的流程示意图；

图3为本发明实施例中，定义应用层系统调用解锁的流程示意图；

图4为本发明实施例中，定义应用层系统调用重加锁的流程示意图；

图5为本发明实施例中，定义定时器加锁的流程示意图；

图6为本发明实施例中，定义定时器解锁的流程示意图；

图7为本发明实施例中，定义定时器重加锁的流程示意图；

图8为本发明实施例中，事件响应加锁方法的流程示意图；

图9为本发明实施例中，事件响应解锁方法的流程示意图。

图10为本发明实施例中，快速路径加锁方法的流程示意图。

图11为本发明实施例中，快速路径解锁方法的流程示意图。

具体实施方式

下面结合附图来具体描述本发明的优先实施例，其中，附图构成本申请一部分，并与本发明的实施例一起用于阐释本发明的原理。

本发明的核心思想是：当出现锁重入问题时，在加锁过程中，把以前加的锁更新到新请求的锁；在解锁过程中，先解新加的锁，再把以前加的锁恢复加上。另外，本发明在自定义的锁中加了原子计数器，并通过原子计数器来实现自定义的锁的优先级。

下面结合附图对本发明实施例所述方法进行详细阐述。

通常情况下，在多核CPU上分别运行不同的系统/代码，包括TOS和fast_path两部分。他们将通过不同的接口来访问防火墙配置和内部链表资源。其中TOS要修改配置和链表资源所以上写锁，而fast_path不需要修改配置所以只上配置读锁。这里TOS上锁部分最为复杂，包括system_call(系统调用)、schedule(进程调度)、timer(定时器)、hook(数据包处理的HOOK点)、notifier(事件响应)。system_call(系统调用)：用户通过用户接口来修改配置，这时需要加写锁；schedule(进程调度)：system_call加的写锁，在执行过程中可能被调度出进程队列，这时需要先解锁，调度进来时需要再重新加锁；timer(定时器)：TOS中的定时器会修改配置和链表，这时需要加配置和链表的读/写锁；hook(数据包处理的HOOK点)：TOS系统中对每个数据包的处理需要读配置和修改链表，这时需要加配置读锁，链表写锁；notifier(事件响应)：事件响应需要修改配置和修改链表，这时需要加配置写锁和链表写锁。

其中，事件响应处理过程中，有时会出现锁重入现象，所谓锁重入现象是指，一个notifier处理函数中又触发了一个notifier事件，具体原理如图1所示，即，函数在访问需要保护的配置时，首先加了锁；然后进行处理工作，这时它有可能又调用了这个函数本身，这时就出现了锁重入问题，锁重入问题实际上是由递归调用引起的。这里我们遇到的是二次递归调用，所以在这里，我们只处理二次递归调用引起的锁重入问题。

为了解决锁重入问题，在系统提供的基本的读锁、写锁、自旋锁的基础上，定义了多个锁，包括：app_enter_critical加锁(应用层系统调用加锁)、app_leave_critical解锁(应用层系统调用解锁)、app_reenter_caitical加锁(应用层系统调用重加锁)、timer_enter_critical加锁(定时器)加锁、timer_leave_critical解锁(定时器解锁)、timer_reenter_critical加锁(定时器重加锁)，下面分别予以说明。

如图2所示，图2定义了一个app_enter_critical加锁，在这个锁里面有2个原子计数器app_locks和app_wrconfig_locks，这2个原子计数器是用来实现锁的优先级的，其中，app_locks是控制应用层系统调用和HOOK锁之间的优先级的，而app_wrconfig_lock是控制应用层系统调用和快速路径之间的优先级的。

具体过程包括：首先判断这个CPU是否上了锁，如果已经上了锁就异常退出，否则把2个原子计数器加1，试图加配置锁(即配置读/写锁)，如果加锁成功就试图加链表锁(即链表读/写锁)，如果加锁成功就保存进程持有的锁和保存CPU加的锁，并返回。这个锁是一个优先级最高的锁。

如图3所示，图3定义了一个app_leave_critical解锁，在这个锁里面也有2个原子计数器app_locks和app_wrconfig_locks。应用层系统调用解锁与应用层系统调用加锁成对使用，其具体过程与图2所示的过程相反，包括：首先判断这个CPU是否上锁，如果已经上了锁就异常退出，否则解链表读/写锁，原子计数器app_wrconfig_locks减1；然后解配置读/写锁，并清除进程持有的锁和CPU加的锁，最后原子计数器app_locks减1。

如图4所示，图4定义了一个应用层系统调用在已经获得锁后又要加锁的app_reenter_caitical加锁。这个锁是用来解决锁重入问题的。在一个加锁请求中判断如果这个CPU已经加了锁，那么我们就调用这个锁。这个锁首先判断这个CPU是否已经上了锁，如果没加锁就异常退出。如果这个CPU上了锁，就先依次把已经加的锁解开，然后再按新的需求依次加锁。

如图5所示，图5定义了一个timer_enter_critica加锁。如果一个定时器要访问配置和链表资源就需要加这个锁，它的优先级中等。具体定义过程可以为：首先把原子计数器app_wrconfig_locks加1，保证其他低优先级的锁不能获得请求。然后加配置读/写锁，加链表读/写锁，把原子计数器app_wrconfig_locks减1，保存这个CPU加的锁。

如图6所示，图6定义了一个timer_leave_critica解锁。具体定义过程可以为：首先解链表读/写锁，然后解配置读/写锁，最后清除CPU保存的锁。

如图7所示，图7定义了一个定时器已经获得锁后又要加锁的timer_reenter_critical加锁。它首先判断这个CPU是否已经上了锁。如果没上锁，就异常退出。否则先依次解开已经上的锁，然后在依次加上请求的锁，并保存新的锁。

以前面定义的6个锁为基础，再定义两个大锁，一个notifier_upgrade_biglock_fun锁(事件响应更新锁)和一个notifier_restore_biglock_fun锁(事件响应恢复锁)。

在事件响应处理过程中，当发生锁重入问题时，在事件响应函数中首先调用notifer_upgrade_biglock_fun锁来加锁或者更新到新的锁，在事件响应函数处理结束后，调用notifier_restore_biglock_fun锁来解锁或者恢复到以前加的锁。

其中，事件响应加锁的具体处理过程如图8所示，可以包括以下步骤：

在事件响应加锁处理过程中，由于可能出现锁重入问题，所以在加锁时首先要记录下每个CPU持有的锁，并且更新这个CPU所持有的锁。也就是说，在事件响应加锁过程中，调用事件响应更新锁，首先需要更新这个CPU持有的锁的类型，如果原来CPU持有的锁和现在要更新的锁的类型一致，那么就直接返回；否则，判断CPU是否上锁，如果这个CPU原来没有锁，那么就通过调用timer_enter_critical加锁或app_enter_critical加锁，直接加配置和链表锁；如果这个CPU已经上了锁，那么就通过调用timer_reenter_critical重加锁或app_reenter_critical重加锁，保存原来持有的锁到临时变量，然后再加要更新的锁。

事件响应解锁的具体处理过程如图9所示，可以包括以下步骤：

在事件响应解锁处理过程中，由于之前可能出现锁重入问题，所以在解锁时要根据之前记录的CPU持有的锁来做判断。也就是说，在事件响应解锁过程中，调用事件响应恢复锁，首先需要判断CPU持有的锁和要更新的锁是否一致，如果CPU所持有的锁和要更新的锁的类型一致，那么就直接返回，否则判断CPU是否上锁，如果CPU原来没有锁，那么就通过调用time_leave_critical解锁或app_leave_critical解锁，直接解配置锁和链表锁；否则，就通过调用timer_reente_critical重加锁或app_reenter_critical重加锁，解这个CPU要更新的锁，并且加原来持有的锁。

下面对本发明实施例中涉及到的配置锁的优先级的实现过程进行说明。

图10是快速路径访问配置后的加锁方法的流程示意图，因为在加配置锁之前要等到原子计数器app_wrconfig_locks为0才能去加锁，如果原子计数器app_wrconfig_locks不为0，表明有其他的CPU已经加了配置锁，这样我们就一直等下去。通过这种方法就实现了配置锁的优先级。

具体的说就是，在图2中应用层系统调用加锁时，把app_wrconfig_locks原子计数器加1，这时如果其他的快速路径CPU要加锁，那么他首先探测app_wrconfig_locks原子计数器是否为0(现在为1)，那么在图10中快速路径在加锁时就用一个while循环一直探测这个计数器是否为0。当那个应用层系统调用解锁后(图3)，就把app_wrconfig_locks减1，就等于0了。此时图10中的快速路径CPU就探测到app_wrconfig_locks为0，就继续后面的加锁。这样就实现了锁的优先级。

图11是快速路径访问配置后的解锁方法的流程示意图，与图10的加锁方法相对应，解锁不涉及优先级的问题。

以上所述为本发明的优选实施例，这里，本发明所述方法可以只保护一种资源，或者把要保护的资源细分成多个资源，然后用多个锁保护这些资源。另外，运行在多核CPU上的系统可能不同：可能有多于2个的系统/代码段运行在多核CPU上，但他们可以并行访问一些要保护的资源。

综上所述，本发明实施例中，当发生锁重入问题时，通过预定义的notifier_upgrade_biglock_fun锁和notifier_restore_biglock_fun锁进行加锁和解锁，在加锁过程中，把以前加的锁更新到新请求的锁；在解锁过程中，先解新加的锁，再把以前加的锁恢复加上。另外，本发明在自定义的锁中加了原子计数器，并通过原子计数器来实现自定义的锁的优先级。通过本发明实施例所述方法，可以使多系统安全、稳定的运行在多核平台上，可以使多系统安全、快速、并行的访问共享资源，还可以使用户的请求由高优先级锁保证得到及时响应。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (7)

1.一种MIPS平台下并行多核配置锁的实现方法，其特征在于，包括：

步骤A：根据系统提供的基本的锁，预定义多个锁，包括：应用层系统调用加锁、应用层系统调用解锁、应用层系统调用重加锁、定时器加锁、定时器解锁、定时器重加锁；

步骤B：根据所述预定义的多个锁，再定义两个锁：事件响应更新锁和事件响应恢复锁；

步骤C：在事件响应处理过程中，当发生锁重入问题时，在事件响应函数中调用事件响应更新锁来加锁或者更新到新的锁；所述步骤C具体包括：更新CPU持有的锁的类型；判断CPU持有的锁和要更新的锁的类型是否一致，如果一致，直接返回，否则判断CPU是否上锁；如果这个CPU原来没有上锁，通过调用定时器加锁或应用层系统调用加锁，直接加配置锁和链表锁；如果CPU已经上了锁，那么就通过调用定时器重加锁或应用层系统调用重加锁，保存原来持有的锁到临时变量，然后再加要更新的锁；

步骤D：在事件响应函数处理结束后，调用事件响应恢复锁来解锁或者恢复到以前加的锁；所述步骤D具体包括：恢复CPU持有的锁的类型；判断CPU持有的锁和要更新的锁的类型是否一致，如果一致，直接返回，否则判断CPU是否上锁；如果CPU原来没有锁，那么就通过调用定时器解锁或应用层系统调用解锁，直接解配置锁和链表锁；如果CPU已经上了锁，那么就通过调用定时器重加锁或应用层系统调用重加锁，解CPU要更新的锁，并且加原来持有的锁。

2.根据权利要求1所述的方法，其特征在于，所述步骤A中，所述应用层系统调用加锁中设置有两个原子计数器，则预定义所述应用层系统调用加锁的过程具体包括：

判断CPU是否上了锁，如果已经上了锁就异常退出，否则把两个原子计数器加1；

试图加配置锁，当确认加配置锁成功时，试图加链表锁；

当确认加链表锁成功时，保存进程持有的锁和保存CPU加的锁并返回，否则解配置锁，并重复试图加配置锁。

3.根据权利要求1所述的方法，其特征在于，所述步骤A中，所述应用层系统调用解锁设置有两个原子计数器，则预定义所述应用层系统调用解锁的过程具体包括：

判断CPU是否上锁，如果已经上了锁就异常退出，否则解链表锁，原子计数器app_wrconfig_locks减1；

解配置锁，并清除进程持有的锁和CPU加的锁；

原子计数器app_locks减1。

4.根据权利要求1所述的方法，其特征在于，所述步骤A中，所述应用层系统调用重加锁的预定义过程具体包括：

判断CPU是否已经上了锁，如果没加锁就异常退出，否则先依次把已经加的锁解开，然后再按新的需求依次加锁。

5.根据权利要求1所述的方法，其特征在于，所述步骤A中，预定义所述定时器加锁的过程具体包括：

原子计数器app_wrconfig_locks加1，保证其他低优先级的锁不能获得请求；

依次加配置锁和链表锁；

原子计数器app_wrconfig_locks减1，保存该CPU加的锁。

6.根据权利要求1所述的方法，其特征在于，所述步骤A中，预定义所述定时器解锁的过程具体包括：

首先解链表锁，然后解配置锁，最后清除CPU保存的锁。

7.根据权利要求1所述的方法，其特征在于，所述步骤A中，预定义所述定时器重加锁的过程具体包括：

判断CPU是否已经上了锁，如果没上锁，就异常退出，否则先依次解开已经上的锁，然后再依次加上请求的锁，并保存新的锁。

Images