CN107122251B - 一种业务子卡管理方法及装置 - Google Patents
一种业务子卡管理方法及装置 Download PDFInfo
- Publication number
- CN107122251B CN107122251B CN201710245415.9A CN201710245415A CN107122251B CN 107122251 B CN107122251 B CN 107122251B CN 201710245415 A CN201710245415 A CN 201710245415A CN 107122251 B CN107122251 B CN 107122251B
- Authority
- CN
- China
- Prior art keywords
- thread
- card
- configuration
- service
- sub
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/542—Event management; Broadcasting; Multicasting; Notifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
Abstract
本发明公开了一种业务子卡管理方法及装置,包括:子卡管理状态线程、子卡配置线程、子卡业务管理线程确定自身的执行状态;各线程根据自身的执行状态进行通信,其中,子卡管理状态线程与子卡配置线程和子卡业务管理线程之间分别采用事件形式进行线程间通信,子卡配置线程与子卡管理状态线程和子卡业务管理线程之间分别采用消息进行线程间通信,子卡业务管理线程与子卡配置线程之间采用消息进行线程间通信。采用本发明,能够有效的预防了管理系统挂死,大幅提高了业务子卡管理的运行效率,有利于配置下发失败以及配置不成功问题的定位。
Description
技术领域
本发明涉及通信技术领域,特别涉及一种业务子卡管理方法及装置。
背景技术
接入层的分布式设备通常是一个具有多个槽位的机框式设备,由业务子卡槽位和主控盘槽位组成。每个业务子卡槽位是一个独立的个体,用于承载各自的接入层业务;主控盘通常占据一个固定的槽位,用来实现对各业务子卡槽位的集中管理,并将管理者的操作转换为对业务子卡的控制,从而实现对业务的配置和管理。
为了实现对分布式业务子卡的集中网管,在主控盘上会有一个子卡管理模块,该模块负责对业务子卡的状态获取和配置下发。现有技术中,对分布式业务子卡的管理目前是采用的单一线程管理方式。
现有技术的不足在于,在单一管理线程的场景下,当状态或配置的任一环节出现问题时就会导致主控盘系统的挂死。
发明内容
本发明提供了一种业务子卡管理方法及装置,用以解决现有业务子卡在状态或配置的任一环节出现问题时就会导致主控盘系统的挂死的问题。
本发明实施例中提供了一种业务子卡管理方法,包括:
子卡管理状态线程、子卡配置线程、子卡业务管理线程确定自身的执行状态,其中,子卡管理状态线程用于根据业务子卡工作状态来维护业务子卡的使用情况,子卡配置线程用于实现业务子卡的配置恢复和配置保存,子卡业务管理线程用于维护业务子卡的业务数据;
各线程根据自身的执行状态进行通信。
较佳地,子卡管理状态线程与子卡配置线程和子卡业务管理线程之间分别采用事件形式进行线程间通信,子卡配置线程与子卡管理状态线程和子卡业务管理线程之间分别采用消息进行线程间通信,子卡业务管理线程与子卡配置线程之间采用消息进行线程间通信。
较佳地,子卡管理状态线程与子卡配置线程之间进行线程间通信,包括如下方式之一或者其组合:
系统启动后,在子卡配置线程将配置加载完毕后通知子卡管理状态线程启动;
在子卡管理状态线程检测到有业务子卡插入,且业务子卡需要恢复配置时,通知子卡配置线程配置恢复事件;
在子卡配置线程执行配置恢复完成后,向子卡管理状态线程返回配置恢复结束消息;
在子卡管理状态线程检测到业务子卡拔出时,通知子卡配置线程子卡配置隐藏事件;
在子卡配置线程收到配置隐藏事件后,获取业务子卡的运行配置并在保存完毕后,向子卡管理状态线程返回配置获取结束消息;
当业务子卡需要恢复配置时,子卡管理状态线程通知子卡配置线程将业务子卡的配置下发给子卡业务管理线程,由子卡业务管理线程最终下发给物理业务子卡。
较佳地,子卡业务管理线程与子卡配置线程之间进行线程间通信,包括如下方式之一或者其组合:
子卡配置线程在配置恢复时,将内存中该业务子卡的配置,以消息形式发送给子卡业务管理线程;
子卡配置线程在配置保存时,给子卡业务管理线程下发配置保存消息;子卡业务管理线程收到配置保存消息后,通过物理通道获取业务子卡的运行配置,以消息形式发送给子卡配置线程,子卡配置线程收到该配置后,将该配置保存到内存。
较佳地,子卡业务管理线程与子卡管理状态线程之间进行线程间通信,包括如下方式之一或者其组合:
子卡管理状态线程检测到有业务子卡插入之后,通知子卡业务管理线程创建该业务子卡的业务数据资源和实例;
当业务子卡需要恢复配置时,子卡管理状态线程通知子卡配置线程将业务子卡的配置下发给子卡业务管理线程,由子卡业务管理线程最终下发给物理业务子卡;
在业务子卡正常工作时,如果用户执行业务子卡的配置动作,子卡管理状态线程截获该配置,并将该配置下发给子卡业务管理线程,由子卡业务管理线程最终下发给物理业务子卡;
在业务子卡正常工作时,如果用户执行业务子卡的状态查询动作,子卡管理状态线程截获该动作,并发送给子卡业务管理线程;
当子卡管理状态线程检测到业务子卡拔出,通知子卡业务管理线程删除该业务子卡已经创建的实例和业务数据资源。
较佳地,在业务子卡插入时,各线程根据自身的执行状态进行通信,包括:
子卡管理状态线程检测到有业务子卡插入后,迁移到power状态;
以事件形式通知子卡业务管理线程动态创建该业务子卡相应的资源。
较佳地,在恢复业务子卡配置时,各线程根据自身的执行状态进行通信,包括:
子卡管理状态线程以事件形式通知子卡配置线程;
子卡配置线程在接收到通知后,从内存中取得该业务子卡的配置,以消息形式发送给子卡业务管理线程;
子卡业务管理线程接收配置,并在将业务子卡配置保存到为该业务子卡创建的资源和实例中后通知子卡配置线程;
子卡配置线程收到通知后,以消息形式通知子卡状态管理线程配置恢复完毕。
较佳地,在拔出业务子卡时,各线程根据自身的执行状态进行通信,包括:
子卡管理状态线程在检测到业务子卡拔出时,以事件1形式通知子卡配置线程该业务子卡的配置需要隐藏;
子卡配置线程收到事件1之后,以消息1形式通知子卡业务管理线程上传业务子卡的运行配置;
子卡业务管理线程获取当前业务子卡的运行配置,并保存在该业务子卡的资源和实例中后,将该业务子卡的运行配置全部发送给子卡配置线程;
子卡配置线程获取到业务子卡的运行配置,并将其保存到内存后,以消息2形式通知子卡管理状态线程该业务子卡的运行配置获取完毕;
子卡管理状态线程收到消息2后,以事件2形式通知子卡业务管理线程删除该业务子卡的资源和实例。
较佳地,在带有业务子卡的整机启动时,各线程根据自身的执行状态进行通信,包括:
在带有业务子卡的整机启动后,子卡管理状态线程和子卡配置线程分别启动,其中,子卡管理状态线程启动后等待子卡配置线程消息;
子卡配置线程完成配置加载后,以消息形式通知子卡管理线程子卡配置线程准备完毕;
子卡管理状态线程收到消息后,开始处理后续业务。
本发明实施例中提供了一种业务子卡管理装置,包括:
线程状态确定模块,用于使子卡管理状态线程、子卡配置线程、子卡业务管理线程确定自身的执行状态,其中,子卡管理状态线程用于根据业务子卡工作状态来维护业务子卡的使用情况,子卡配置线程用于实现业务子卡的配置恢复和配置保存,子卡业务管理线程用于维护业务子卡的业务数据;
线程管理模块,用于使各线程根据自身的执行状态进行通信。
较佳地,线程管理模块进一步用于在使各线程根据自身的执行状态进行通信时,子卡管理状态线程与子卡配置线程和子卡业务管理线程之间分别采用事件形式进行线程间通信,子卡配置线程与子卡管理状态线程和子卡业务管理线程之间分别采用消息进行线程间通信,子卡业务管理线程与子卡配置线程之间采用消息进行线程间通信。
较佳地,线程管理模块进一步用于在子卡管理状态线程与子卡配置线程之间进行线程间通信时,采用包括如下方式之一或者其组合的方式:
系统启动后,在子卡配置线程将配置加载完毕后通知子卡管理状态线程启动;
在子卡管理状态线程检测到有业务子卡插入,且业务子卡需要恢复配置时,通知子卡配置线程配置恢复事件;
在子卡配置线程执行配置恢复完成后,向子卡管理状态线程返回配置恢复结束消息;
在子卡管理状态线程检测到业务子卡拔出时,通知子卡配置线程子卡配置隐藏事件;
在子卡配置线程收到配置隐藏事件后,获取业务子卡的运行配置并在保存完毕后,向子卡管理状态线程返回配置获取结束消息;
当业务子卡需要恢复配置时,子卡管理状态线程通知子卡配置线程将业务子卡的配置下发给子卡业务管理线程,由子卡业务管理线程最终下发给物理业务子卡。
较佳地,线程管理模块进一步用于在子卡业务管理线程与子卡配置线程之间进行线程间通信时,采用包括如下方式之一或者其组合的方式:
子卡配置线程在配置恢复时,将内存中该业务子卡的配置,以消息形式发送给子卡业务管理线程;
子卡配置线程在配置保存时,给子卡业务管理线程下发配置保存消息;
子卡业务管理线程收到配置保存消息后,通过物理通道获取业务子卡的运行配置,以消息形式发送给子卡配置线程,子卡配置线程收到该配置后,将该配置保存到内存。
较佳地,线程管理模块进一步用于在子卡业务管理线程与子卡管理状态线程之间进行线程间通信时,采用包括如下方式之一或者其组合的方式:
子卡管理状态线程检测到有业务子卡插入之后,通知子卡业务管理线程创建该业务子卡的业务数据资源和实例;
当业务子卡需要恢复配置时,子卡管理状态线程通知子卡配置线程将业务子卡的配置下发给子卡业务管理线程,由子卡业务管理线程最终下发给物理业务子卡;
在业务子卡正常工作时,如果用户执行业务子卡的配置动作,子卡管理状态线程截获该配置,并将该配置下发给子卡业务管理线程,由子卡业务管理线程最终下发给物理业务子卡;
在业务子卡正常工作时,如果用户执行业务子卡的状态查询动作,子卡管理状态线程截获该动作,并发送给子卡业务管理线程;
当子卡管理状态线程检测到业务子卡拔出,通知子卡业务管理线程删除该业务子卡已经创建的实例和业务数据资源。
较佳地,线程管理模块进一步用于在业务子卡插入时,使各线程根据自身的执行状态进行通信,包括:
子卡管理状态线程检测到有业务子卡插入后,迁移到power状态;
以事件形式通知子卡业务管理线程动态创建该业务子卡相应的资源。
较佳地,线程管理模块进一步用于在恢复业务子卡配置时,使各线程根据自身的执行状态进行通信,包括:
子卡管理状态线程以事件形式通知子卡配置线程;
子卡配置线程在接收到通知后,从内存中取得该业务子卡的配置,以消息形式发送给子卡业务管理线程;
子卡业务管理线程接收配置,并在将业务子卡配置保存到为该业务子卡创建的资源和实例中后通知子卡配置线程;
子卡配置线程收到通知后,以消息形式通知子卡状态管理线程配置恢复完毕。
较佳地,线程管理模块进一步用于在拔出业务子卡时,使各线程根据自身的执行状态进行通信,包括:
子卡管理状态线程在检测到业务子卡拔出时,以事件1形式通知子卡配置线程该业务子卡的配置需要隐藏;
子卡配置线程收到事件1之后,以消息1形式通知子卡业务管理线程上传业务子卡的运行配置;
子卡业务管理线程获取当前业务子卡的运行配置,并保存在该业务子卡的资源和实例中后,将该业务子卡的运行配置全部发送给子卡配置线程;
子卡配置线程获取到业务子卡的运行配置,并将其保存到内存后,以消息2形式通知子卡管理状态线程该业务子卡的运行配置获取完毕;
子卡管理状态线程收到消息2后,以事件2形式通知子卡业务管理线程删除该业务子卡的资源和实例。
较佳地,线程管理模块进一步用于在带有业务子卡的整机启动时,使各线程根据自身的执行状态进行通信,包括:
在带有业务子卡的整机启动后,子卡管理状态线程和子卡配置线程分别启动,其中,子卡管理状态线程启动后等待子卡配置线程消息;
子卡配置线程完成配置加载后,以消息形式通知子卡管理线程子卡配置线程准备完毕;
子卡管理状态线程收到消息后,开始处理后续业务。
本发明有益效果如下:
在本发明实施例提供的技术方案中,采用了多线程机制,将单一的管理线程从功能上分解为多个相对独立的线程:子卡管理状态线程、子卡配置线程、子卡业务管理线程,各线程之间采用事件通知和消息通知的方式进行通信。由于解耦了各模块之间的过多的耦合交叉,在很大程度上降低了因业务子卡配置内存错误引起系统挂死的可能,因此能够有效的预防了管理系统挂死。
进一步的,分线程后,在物理通道下发配置或获取业务子卡状态时,由于多线程方式显著减少了等待物理通道I/O操作的时间,不会再因频繁的I/O操作降低系统的运行效率,因此大幅提高了业务子卡管理的运行效率。
进一步的,多线程处理,更有利于配置下发失败以及配置不成功问题的定位。
更进一步的:
由于业务子卡的整个管理流程分成三个线程后,减小了业务子卡管理状态流程与业务子卡配置之间耦合,子卡管理状态线程的处理流程不再依赖于业务子卡的具体配置,个别配置场景下的内存或信号量错误,因此不会影响其他线程。
由于业务子卡的真正配置下发、获取单独出来后,即使用户操作导致软件错误,也不会再造成系统性的异常;而且分线程之后,对定位配置错误和配置不生效等错误的定位更加清晰便捷。
由于子卡业务管理线程负责与业务子卡物理实体之间的交互,独立成线程之后,不会再因为物理通道的超时或异常,造成整个系统的锁死。由于子卡业务管理线程涉及实际物理通道之间的I/O操作,分线程后子卡管理状态线程、子卡配置线程无需等待I/O,整个系统效率显著提高了。
附图说明
此处所说明的附图用来提供对本发明的进一步理解,构成本发明的一部分,本发明的示意性实施例及其说明用于解释本发明,并不构成对本发明的不当限定。在附图中:
图1为本发明实施例中业务子卡管理方法实施流程示意图;
图2为本发明实施例中线程划分及关系示意图;
图3为本发明实施例中状态切换交互事件示意图;
图4为本发明实施例中配置的交互处理示意图;
图5为本发明实施例中子卡业务管理操作示意图;
图6为本发明实施例中业务子卡插入和配置恢复流程示意图;
图7为本发明实施例中业务子卡的拔出流程实施示意图;
图8为本发明实施例中带业务子卡整机启动流程实施示意图;
图9为本发明实施例中业务子卡管理装置结构示意图。
具体实施方式
发明人在发明过程中注意到:
为了实现对分布式业务子卡的集中网管,在主控盘上会有一个子卡管理模块,该模块负责对业务子卡的状态获取和配置下发。目前,在现有技术中,对分布式业务子卡的管理目前是采用的单一线程管理方式,单一管理线程,是指状态获取和配置下发都在同一个线程内完成。
在该方式下,如果在状态或配置时存在内存越界,这个单一的线程就会死掉,然而,由于主控盘只有这一个线程,因此主控盘也会死掉。如果线程在进行子卡的配置下发或状态获取,而该线程要需要与实际硬件进行交互的,因此这种交互操作比较耗时,那么在这个时候,如果有紧急的配置或者告警,则就只能等到交互完了之后才能处理。
因此,对于现有技术而言,其不足在于,在单一管理线程的场景下,当状态或配置的任一环节出现问题时就会导致主控盘系统的挂死;
而进一步的,当有业务子卡的紧急消息发生时,在单一管理线程模式下也无法做到该紧急消息的及时处理。
本发明实施例提供的技术方案中,将采用多线程机制,将单一的管理线程从功能上分解为多个相对独立的线程,各线程之间采用事件通知和消息的方式进行线程状态的切换。解耦了各模块之间的过多的耦合交叉,从而能够有效的预防了管理系统挂死。同时多线程方式显著减少了等待物理通道I/O操作的时间,大幅提高了业务子卡管理的运行效率。下面结合附图对本发明的具体实施方式进行说明。
图1为业务子卡管理方法实施流程示意图,如图所示,可以包括:
步骤101、子卡管理状态线程、子卡配置线程、子卡业务管理线程确定自身的执行状态,其中,子卡管理状态线程用于根据业务子卡工作状态来维护业务子卡的使用情况,子卡配置线程用于实现业务子卡的配置恢复和配置保存,子卡业务管理线程用于维护业务子卡的业务数据;
步骤102、各线程根据自身的执行状态进行通信。
实施中,子卡管理状态线程与子卡配置线程和子卡业务管理线程之间分别采用事件形式进行线程间通信,子卡配置线程与子卡管理状态线程和子卡业务管理线程之间分别采用消息进行线程间通信,子卡业务管理线程与子卡配置线程之间采用消息进行线程间通信。
图2为线程划分及关系示意图,如图所示,业务子卡管理分为子卡管理状态线程、子卡配置线程、子卡业务管理线程。其中,子卡管理状态线程与子卡配置线程和子卡业务管理线程均采用事件形式进行线程间通信,实现线程间的同步;子卡配置线程与子卡管理状态线程和子卡业务管理线程均采用消息进行线程间通信,实现线程的同步和信息传递;子卡业务管理线程与子卡配置线程也采用消息实现通信。
具体实施中,分类线程是用以达到有效管理业务子卡的目的,例如:能够及时处理紧急消息;在配置出现问题时不会导致系统崩溃;无需等待I/O,整个系统效率显著提高等,具体如何实现该目的将会在下面线程的具体实施中进行说明。
实施中,对于线程之间的通信有下面的几种方法实现这种通信方式:使用全局变量、使用事件对象、使用消息。这里主要介绍后两种方式。
1、使用消息实现通信。
消息队列:接收消息的线程负责定义消息队列,包括消息队列的名称、每条消息的固定格式、消息队列能存储的最大消息数目;并实现消息的接收和消息的处理函数、消息的发送函数供消息发送线程使用。
2使用事件实现线程间通信。
接收事件的线程负责定义事件,包括事件的类型和枚举,并实现事件的接收和处理函数,事件的发送函数供事件发生线程使用。
下面再对子卡管理状态线程、子卡配置线程、子卡业务管理线程进行说明。
1、子卡管理状态线程。
子卡管理状态线程用于根据业务子卡工作状态来维护业务子卡的使用情况。
具体的,该线程根据业务子卡工作状态的角度来维护业务子卡的基本使用情况,其工作状态可以包括子卡在位(power)、恢复中(cfgrestore)、正常工作(working)、不在位(offline)、空状态(null),共5个状态。
子卡管理状态线程是主动线程,不停的周期性检测业务子卡的在位情况,维护业务子卡的工作状态,并与其他线程进行信息交互,共同维护业务子卡业务正常运行。
2、子卡配置线程。
子卡配置线程用于实现业务子卡的配置恢复和配置保存。
具体的,该线程实现业务子卡的配置恢复和配置保存:整机启动时,该线程首先执行业务子卡的配置加载,将业务子卡配置从FLASH加载到内存;当业务子卡有配置恢复需求时,将业务子卡的配置通过消息发送给子卡业务管理线程,实现配置恢复;当业务子卡拔出时,从子卡业务管理线程获取业务子卡的配置保存下来,以便后续恢复。
该线程是阻塞性被动线程,在配置加载前该线程创建,完成配置加载后,该线程阻塞性被动等待子卡管理状态线程的事件和子卡业务管理线程的消息,一旦有事件或消息产生,线程停止阻塞开始执行,执行完成后继续阻塞。
3、子卡业务管理线程。
子卡业务管理线程用于维护业务子卡的业务数据。
具体的,该线程维护业务子卡的业务数据,其中业务数据包括业务子卡的业务工作状态和业务配置,实现将业务子卡物理实体的真实状态更新到业务子卡业务状态、业务子卡业务配置下发到业务子卡物理实体,以及业务子卡业务配置保存到子卡配置线程。
该线程是非阻塞式半被动线程,一方面子卡管理状态线程和子卡配置线程通过事件或消息推动该线程运行,另一方面该线程周期性主动更新业务子卡物理实体状态到线程的资源和实例、真正下发业务子卡的配置到业务子卡物理实体。
待子卡管理状态线程中该业务子卡状态处于正常工作态之后,子卡业务管理线程即可处理用户配置和查询操作。
下面对三个线程之间各自的交互关系进行说明。
1、子卡管理状态线程与子卡配置线程。
子卡管理状态线程与子卡配置线程之间进行线程间通信,包括如下方式之一或者其组合:
系统启动后,在子卡配置线程将配置加载完毕后通知子卡管理状态线程启动;
在子卡管理状态线程检测到有业务子卡插入,且业务子卡需要恢复配置时,通知子卡配置线程配置恢复事件;
在子卡配置线程执行配置恢复完成后,向子卡管理状态线程返回配置恢复结束消息;
在子卡管理状态线程检测到业务子卡拔出时,通知子卡配置线程子卡配置隐藏事件;
在子卡配置线程收到配置隐藏事件后,获取业务子卡的运行配置并在保存完毕后,向子卡管理状态线程返回配置获取结束消息;
当业务子卡需要恢复配置时,子卡管理状态线程通知子卡配置线程将业务子卡的配置下发给子卡业务管理线程,由子卡业务管理线程最终下发给物理业务子卡。
下面以实例进行说明。
图3为状态切换交互事件示意图,如图所示,交互可以如下:
系统启动后,子卡配置线程先进行配置加载,将系统保存的配置文件加载到内存以备后用,配置加载完毕后该线程方可对外提供服务,同时通知子卡管理状态线程启动。
(1)、子卡管理状态线程启动后,不间断检测是否有业务子卡存在,当检测到有业务子卡则迁移到power状态。如果业务子卡需要恢复配置,则继续迁移到cfgrestore配置恢复状态,并通知子卡配置线程配置恢复事件,通知后便等待子卡配置线程完成业务子卡的配置恢复。
(2)、子卡配置线程执行配置恢复,完成后返回子卡管理状态线程配置恢复结束消息,子卡管理状态线程收到该消息后,迁移到正常工作working状态。
(3)、当子卡管理状态线程,检测到业务子卡拔出时,迁移到offline状态,并通知子卡配置线程业务子卡配置隐藏事件。
(4)、子卡配置线程收到该事件后,去获取业务子卡的运行配置并进行保存。子卡配置线程完成全部保存完毕后,返回子卡管理状态线程配置获取结束消息,子卡管理状态线程收到该消息后,迁移到null状态。
由于业务子卡的整个管理流程分成两个线程后,减小了业务子卡管理状态流程与业务子卡配置之间耦合,子卡管理状态线程的处理流程不再依赖于业务子卡的具体配置,个别配置场景下的内存或信号量错误,因此不会影响其他线程。
2、子卡配置线程与子卡业务管理线程。
子卡业务管理线程与子卡配置线程之间进行线程间通信,包括如下方式之一或者其组合:
子卡配置线程在配置恢复时,将内存中该业务子卡的配置,以消息形式发送给子卡业务管理线程;
子卡配置线程在配置保存时,给子卡业务管理线程下发配置保存消息;
子卡业务管理线程收到配置保存消息后,通过物理通道获取业务子卡的运行配置,以消息形式发送给子卡配置线程,子卡配置线程收到该配置后,将该配置保存到内存。
真正的业务子卡配置下发和获取业务子卡配置的源头,都是在子卡业务管理线程实现的,这个线程是一个物理层线程,它维护业务子卡的业务数据,实现用户业务配置到物理业务子卡实体的下发、实现业务配置从物理业务子卡实体的获取。下面以实例进行说明。
图4为配置的交互处理示意图,如图所示,交互可以如下:
(1)、子卡配置线程在配置恢复时,将内存中该业务子卡的配置,通过消息发送给子卡业务管理线程。子卡业务管理线程将业务配置通过物理通道最终下发到业务子卡物理实体,完成真正业务配置的下发。
(2)、子卡配置线程在配置保存时,下发给子卡业务管理线程配置保存消息,等待业务配置数据。
(3)、子卡业务管理线程收到消息后,通过物理通道获取业务子卡的运行配置,以消息形式发送给子卡配置线程。子卡配置线程收到该配置后,将该配置保存到内存。
由于业务子卡的真正配置下发、获取单独出来后,一旦用户操作导致软件错误,比如操作非法内存或越限配置造成,不会再造成系统性的异常。而且分线程之后,对定位配置错误和配置不生效等错误到底出现在哪个环节更加清晰便捷,如果配置线程收到的配置是正确的,但真正业务子卡生效的不对,那就是子卡业务管理线程配置下发出错了,反之亦然。
3、子卡管理状态线程与子卡业务管理线程。
子卡业务管理线程与子卡管理状态线程之间进行线程间通信,包括如下方式之一或者其组合:
子卡管理状态线程检测到有业务子卡插入之后,通知子卡业务管理线程创建该业务子卡的业务数据资源和实例;
当业务子卡需要恢复配置时,子卡管理状态线程通知子卡配置线程将业务子卡的配置下发给子卡业务管理线程,由子卡业务管理线程最终下发给物理业务子卡;
在业务子卡正常工作时,如果用户执行业务子卡的配置动作,子卡管理状态线程截获该配置,并将该配置下发给子卡业务管理线程,由子卡业务管理线程最终下发给物理业务子卡;
在业务子卡正常工作时,如果用户执行业务子卡的状态查询动作,子卡管理状态线程截获该动作,并发送给子卡业务管理线程;
当子卡管理状态线程检测到业务子卡拔出,通知子卡业务管理线程删除该业务子卡已经创建的实例和业务数据资源。
子卡业务管理线程维护业务子卡业务数据,包括状态和配置,真正与业务子卡物理实体进行数据交互,与业务子卡实体间通过物理通道实现业务子卡的状态和配置获取,以及业务配置到业务子卡实体的下发。下面以实例进行说明。
图5为子卡业务管理操作示意图,如图所示,管理操作可以如下:
(1)、子卡管理状态线程发现业务子卡存在之后,通知子卡业务管理线程创建该业务子卡的业务数据资源和实例。
(2)、当业务子卡需要恢复配置时,子卡管理状态线程,通知子卡配置线程将业务子卡配置下发给子卡业务管理线程,由子卡业务管理线程最终下发给物理业务子卡。
(3)、在业务子卡正常工作时,如果用户执行业务子卡的配置动作,子卡管理状态线程截获该配置,并将该配置下发给子卡业务管理线程,由子卡业务管理线程最终下发给物理业务子卡。
(4)、在业务子卡正常工作时,如果用户执行业务子卡的状态查询动作,子卡管理状态线程截获该动作,并发送给子卡业务管理线程。子卡业务管理线程通过物理通道获取业务子卡的最新运行状态,并将该新状态呈现给用户。
(5)、当子卡管理状态线程发现存在的业务子卡消失,通知子卡业务管理线程删除该业务子卡已经创建的实例和业务数据资源。
由于子卡业务管理线程负责与业务子卡物理实体之间的交互,独立成线程之后,不会再因为物理通道的超时或异常,造成整个系统的锁死。由于子卡业务管理线程涉及实际物理通道之间的I/O操作,分线程后子卡管理状态线程、子卡配置线程无需等待I/O,整个系统效率显著提高了。
下面结合具体的典型的业务场景使用进行说明。
1、业务子卡插入和配置恢复流程。
(1)在业务子卡插入时,各线程根据自身的执行状态进行通信,包括:
子卡管理状态线程检测到有业务子卡插入后,迁移到power状态;
以事件形式通知子卡业务管理线程动态创建该业务子卡相应的资源。
(2)在恢复业务子卡配置时,各线程根据自身的执行状态进行通信,包括:
子卡管理状态线程以事件形式通知子卡配置线程;
子卡配置线程在接收到通知后,从内存中取得该业务子卡的配置,以消息形式发送给子卡业务管理线程;
子卡业务管理线程接收配置,并在将业务子卡配置保存到为该业务子卡创建的资源和实例中后通知子卡配置线程;
子卡配置线程收到通知后,以消息形式通知子卡状态管理线程配置恢复完毕。
下面以实例进行说明。
图6为业务子卡插入和配置恢复流程示意图,如图所示,可以包括如下流程:
子卡管理状态线程在检测到有业务子卡插入后,迁移到power状态,并产生事件1,通知子卡业务管理线程动态创建该业务子卡相应的资源。
如果业务子卡需要由主控恢复配置,则子卡管理状态线程产生事件2,通知子卡配置线程。子卡配置线程从内存中取得该业务子卡的配置,通过消息1发送给子卡业务管理线程,子卡业务管理线程全部接收了配置,并将业务子卡配置保存到业务子卡创建的资源或实例中,之后知会子卡配置线程。子卡配置线程收到知会后,给子卡状态管理线程发送消息2,通知其配置恢复完毕。子卡业务管理线程将该业务子卡的配置打包成业务子卡可以识别的专属格式,在线程的主动执行周期内,通过物理通道发送给对应的业务子卡。
2、业务子卡的拔出流程。
在拔出业务子卡时,各线程根据自身的执行状态进行通信,包括:
子卡管理状态线程在检测到业务子卡拔出时,以事件1形式通知子卡配置线程该业务子卡的配置需要隐藏;
子卡配置线程收到事件1之后,以消息1形式通知子卡业务管理线程上传业务子卡的运行配置;
子卡业务管理线程获取当前业务子卡的运行配置,并保存在该业务子卡的资源和实例中后,将该业务子卡的运行配置全部发送给子卡配置线程;
子卡配置线程获取到业务子卡的运行配置,并将其保存到内存后,以消息2形式通知子卡管理状态线程该业务子卡的运行配置获取完毕;
子卡管理状态线程收到消息2后,以事件2形式通知子卡业务管理线程删除该业务子卡的资源和实例。
下面以实例进行说明。
图7为业务子卡的拔出流程实施示意图,如图所示,可以包括如下步骤:
首先子卡管理状态线程检测到有存在的业务子卡被拔出,产生事件1通知子卡配置线程该业务子卡的配置需要隐藏。子卡配置线程收到事件1之后,发送消息1通知子卡业务管理线程上传业务子卡的运行配置。子卡业务管理线程通过物理通道实时获取当前业务子卡的运行配置,保存在业务子卡资源实例中。之后将业务子卡的配置全部发送给子卡配置线程。子卡配置线程再获取到业务子卡的运行配置之后,将其保存到内存,并发送消息2通知子卡管理状态线程业务子卡配置获取完毕。
子卡管理状态线程收到业务子卡配置获取完毕消息后,产生事件2,通知子卡业务管理线程删除业务子卡的资源和实例。至此业务子卡拔出流程处理完毕,业务子卡动态创建的资源全部释放。
3、带业务子卡整机启动流程。
在带有业务子卡的整机启动时,各线程根据自身的执行状态进行通信,包括:
在带有业务子卡的整机启动后,子卡管理状态线程和子卡配置线程分别启动,其中,子卡管理状态线程启动后等待子卡配置线程消息;
子卡配置线程完成配置加载后,以消息形式通知子卡管理线程子卡配置线程准备完毕;
子卡管理状态线程收到消息后,开始处理后续业务。
上述两个流程均为子卡配置线程正常启动后,进入可对外提供服务的servicing态之后,又有业务子卡插入或拔出的处理流程。
下面以实例进行说明。
本例中,整个机框主控盘和业务子卡先插好,整机启动且业务子卡需要恢复配置,图8为带业务子卡整机启动流程实施示意图,如图所示,可以包括如下步骤:
整机启动后,子卡管理状态线程和子卡配置线程分别启动,其中子卡管理状态线程启动后需要等待子卡配置线程,将配置从FLASH全部加载到内存之后,开始处理业务子卡插入动作。从图8可以看出,子卡管理状态线程对检测到的前两次业务子卡插入动作(1)和(2)并没有处理。
子卡配置线程完成配置加载后,产生消息1,通知子卡管理线程子卡配置线程准备完毕。子卡管理状态线程收到消息1之后,就可以正常处理后续的业务子卡插入动作了。比如业务子卡插入动作(3),触发子卡管理状态线程产生事件1,通知子卡业务管理线程创建业务子卡需要的资源和实例。
因为业务子卡需要配置恢复,子卡管理状态线程产生事件2,通知子卡配置线程为业务子卡恢复配置。子卡配置恢复线程通过消息2为业务子卡下发待恢复的配置,配置恢复完毕后通过消息3通知子卡状态管理线程配置恢复结束,业务子卡可以开始正常工作。
基于同一发明构思,本发明实施例中还提供了一种业务子卡管理装置,由于该装置解决问题的原理与一种业务子卡管理方法相似,因此该装置的实施可以参见方法的实施,重复之处不再赘述。
图9为业务子卡管理装置结构示意图,如图所示,可以包括:
线程状态确定模块901,用于使子卡管理状态线程、子卡配置线程、子卡业务管理线程确定自身的执行状态,其中,子卡管理状态线程用于根据业务子卡工作状态来维护业务子卡的使用情况,子卡配置线程用于实现业务子卡的配置恢复和配置保存,子卡业务管理线程用于维护业务子卡的业务数据;
线程管理模块902,用于使各线程根据自身的执行状态进行通信。
实施中,线程管理模块还可以进一步用于在使各线程根据自身的执行状态进行通信时,子卡管理状态线程与子卡配置线程和子卡业务管理线程之间分别采用事件形式进行线程间通信,子卡配置线程与子卡管理状态线程和子卡业务管理线程之间分别采用消息进行线程间通信,子卡业务管理线程与子卡配置线程之间采用消息进行线程间通信。
实施中,线程管理模块进一步用于在子卡管理状态线程与子卡配置线程之间进行线程间通信时,采用包括如下方式之一或者其组合的方式:
系统启动后,在子卡配置线程将配置加载完毕后通知子卡管理状态线程启动;
在子卡管理状态线程检测到有业务子卡插入,且业务子卡需要恢复配置时,通知子卡配置线程配置恢复事件;
在子卡配置线程执行配置恢复完成后,向子卡管理状态线程返回配置恢复结束消息;
在子卡管理状态线程检测到业务子卡拔出时,通知子卡配置线程子卡配置隐藏事件;
在子卡配置线程收到配置隐藏事件后,获取业务子卡的运行配置并在保存完毕后,向子卡管理状态线程返回配置获取结束消息;
当业务子卡需要恢复配置时,子卡管理状态线程通知子卡配置线程将业务子卡的配置下发给子卡业务管理线程,由子卡业务管理线程最终下发给物理业务子卡。
实施中,线程管理模块进一步用于在子卡业务管理线程与子卡配置线程之间进行线程间通信时,采用包括如下方式之一或者其组合的方式:
子卡配置线程在配置恢复时,将内存中该业务子卡的配置,以消息形式发送给子卡业务管理线程;
子卡配置线程在配置保存时,给子卡业务管理线程下发配置保存消息;
子卡业务管理线程收到配置保存消息后,通过物理通道获取业务子卡的运行配置,以消息形式发送给子卡配置线程,子卡配置线程收到该配置后,将该配置保存到内存。
实施中,线程管理模块进一步用于在子卡业务管理线程与子卡管理状态线程之间进行线程间通信时,采用包括如下方式之一或者其组合的方式:
子卡管理状态线程检测到有业务子卡插入之后,通知子卡业务管理线程创建该业务子卡的业务数据资源和实例;
当业务子卡需要恢复配置时,子卡管理状态线程通知子卡配置线程将业务子卡的配置下发给子卡业务管理线程,由子卡业务管理线程最终下发给物理业务子卡;
在业务子卡正常工作时,如果用户执行业务子卡的配置动作,子卡管理状态线程截获该配置,并将该配置下发给子卡业务管理线程,由子卡业务管理线程最终下发给物理业务子卡;
在业务子卡正常工作时,如果用户执行业务子卡的状态查询动作,子卡管理状态线程截获该动作,并发送给子卡业务管理线程;
当子卡管理状态线程检测到业务子卡拔出,通知子卡业务管理线程删除该业务子卡已经创建的实例和业务数据资源。
实施中,线程管理模块进一步用于在业务子卡插入时,使各线程根据自身的执行状态进行通信,包括:
子卡管理状态线程检测到有业务子卡插入后,迁移到power状态;
以事件形式通知子卡业务管理线程动态创建该业务子卡相应的资源。
实施中,线程管理模块进一步用于在恢复业务子卡配置时,使各线程根据自身的执行状态进行通信,包括:
子卡管理状态线程以事件形式通知子卡配置线程;
子卡配置线程在接收到通知后,从内存中取得该业务子卡的配置,以消息形式发送给子卡业务管理线程;
子卡业务管理线程接收配置,并在将业务子卡配置保存到为该业务子卡创建的资源和实例中后通知子卡配置线程;
子卡配置线程收到通知后,以消息形式通知子卡状态管理线程配置恢复完毕。
实施中,线程管理模块进一步用于在拔出业务子卡时,使各线程根据自身的执行状态进行通信,包括:
子卡管理状态线程在检测到业务子卡拔出时,以事件1形式通知子卡配置线程该业务子卡的配置需要隐藏;
子卡配置线程收到事件1之后,以消息1形式通知子卡业务管理线程上传业务子卡的运行配置;
子卡业务管理线程获取当前业务子卡的运行配置,并保存在该业务子卡的资源和实例中后,将该业务子卡的运行配置全部发送给子卡配置线程;
子卡配置线程获取到业务子卡的运行配置,并将其保存到内存后,以消息2形式通知子卡管理状态线程该业务子卡的运行配置获取完毕;
子卡管理状态线程收到消息2后,以事件2形式通知子卡业务管理线程删除该业务子卡的资源和实例。
实施中,线程管理模块进一步用于在带有业务子卡的整机启动时,使各线程根据自身的执行状态进行通信,包括:
在带有业务子卡的整机启动后,子卡管理状态线程和子卡配置线程分别启动,其中,子卡管理状态线程启动后等待子卡配置线程消息;
子卡配置线程完成配置加载后,以消息形式通知子卡管理线程子卡配置线程准备完毕;
子卡管理状态线程收到消息后,开始处理后续业务。
为了描述的方便,以上所述装置的各部分以功能分为各种模块或单元分别描述。当然,在实施本发明时可以把各模块或单元的功能在同一个或多个软件或硬件中实现。
综上所述,在本发明提供的技术方案中,将单一的线程分解为功能相对独立的多个线程,解耦了紧密联系的功能模块,在很大程度上降低了因业务子卡配置内存错误引起系统挂死的可能。
分线程后,在物理通道下发配置或获取业务子卡状态时,不会再因频繁的I/O操作降低系统的运行效率。
多线程处理,更有利于配置下发失败以及配置不成功问题的定位。
本领域内的技术人员应明白,本发明的实施例可提供为方法、系统、或计算机程序产品。因此,本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
显然,本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样,倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内,则本发明也意图包含这些改动和变型在内。
Claims (16)
1.一种业务子卡管理方法,其特征在于,包括:
子卡管理状态线程、子卡配置线程、子卡业务管理线程确定自身的执行状态,其中,子卡管理状态线程用于根据业务子卡工作状态来维护业务子卡的使用情况,子卡配置线程用于实现业务子卡的配置恢复和配置保存,子卡业务管理线程用于维护业务子卡的业务数据;
各线程根据自身的执行状态进行通信;
其中,在带有业务子卡的整机启动时,各线程根据自身的执行状态进行通信,包括:
在带有业务子卡的整机启动后,子卡管理状态线程和子卡配置线程分别启动,其中,子卡管理状态线程启动后等待子卡配置线程消息;
子卡配置线程完成配置加载后,以消息形式通知子卡管理状态线程子卡配置线程准备完毕;
子卡管理状态线程收到消息后,开始处理后续业务。
2.如权利要求1所述的方法,其特征在于,子卡管理状态线程与子卡配置线程、子卡管理状态线程与子卡业务管理线程之间分别采用事件形式进行线程间通信,子卡配置线程与子卡管理状态线程、子卡配置线程与子卡业务管理线程之间分别采用消息进行线程间通信,子卡业务管理线程与子卡配置线程之间采用消息进行线程间通信。
3.如权利要求1或2所述的方法,其特征在于,子卡管理状态线程与子卡配置线程之间进行线程间通信,包括如下方式之一或者其组合:
系统启动后,在子卡配置线程将配置加载完毕后通知子卡管理状态线程启动;
在子卡管理状态线程检测到有业务子卡插入,且业务子卡需要恢复配置时,通知子卡配置线程配置恢复事件;在子卡配置线程执行配置恢复完成后,向子卡管理状态线程返回配置恢复结束消息;
在子卡管理状态线程检测到业务子卡拔出时,通知子卡配置线程子卡配置隐藏事件;在子卡配置线程收到配置隐藏事件后,获取业务子卡的运行配置并在保存完毕后,向子卡管理状态线程返回配置获取结束消息;
当业务子卡需要恢复配置时,子卡管理状态线程通知子卡配置线程将业务子卡的配置下发给子卡业务管理线程,由子卡业务管理线程最终下发给物理业务子卡。
4.如权利要求1或2所述的方法,其特征在于,子卡业务管理线程与子卡配置线程之间进行线程间通信,包括如下方式之一或者其组合:
子卡配置线程在配置恢复时,将内存中该业务子卡的配置,以消息形式发送给子卡业务管理线程;
子卡配置线程在配置保存时,给子卡业务管理线程下发配置保存消息;子卡业务管理线程收到配置保存消息后,通过物理通道获取业务子卡的运行配置,以消息形式发送给子卡配置线程,子卡配置线程收到该配置后,将该配置保存到内存。
5.如权利要求1或2所述的方法,其特征在于,子卡业务管理线程与子卡管理状态线程之间进行线程间通信,包括如下方式之一或者其组合:
子卡管理状态线程检测到有业务子卡插入之后,通知子卡业务管理线程创建该业务子卡的业务数据资源和实例;
当业务子卡需要恢复配置时,子卡管理状态线程通知子卡配置线程将业务子卡的配置下发给子卡业务管理线程,由子卡业务管理线程最终下发给物理业务子卡;
在业务子卡正常工作时,如果用户执行业务子卡的配置动作,子卡管理状态线程截获该配置,并将该配置下发给子卡业务管理线程,由子卡业务管理线程最终下发给物理业务子卡;
在业务子卡正常工作时,如果用户执行业务子卡的状态查询动作,子卡管理状态线程截获该动作,并发送给子卡业务管理线程;
当子卡管理状态线程检测到业务子卡拔出,通知子卡业务管理线程删除该业务子卡已经创建的实例和业务数据资源。
6.如权利要求1或2所述的方法,其特征在于,在业务子卡插入时,各线程根据自身的执行状态进行通信,包括:
子卡管理状态线程检测到有业务子卡插入后,迁移到power状态;
以事件形式通知子卡业务管理线程动态创建该业务子卡相应的资源。
7.如权利要求1或2所述的方法,其特征在于,在恢复业务子卡配置时,各线程根据自身的执行状态进行通信,包括:
子卡管理状态线程以事件形式通知子卡配置线程;
子卡配置线程在接收到通知后,从内存中取得该业务子卡的配置,以消息形式发送给子卡业务管理线程;
子卡业务管理线程接收配置,并在将业务子卡配置保存到为该业务子卡创建的资源和实例中后通知子卡配置线程;
子卡配置线程收到通知后,以消息形式通知子卡状态管理线程配置恢复完毕。
8.如权利要求1或2所述的方法,其特征在于,在拔出业务子卡时,各线程根据自身的执行状态进行通信,包括:
子卡管理状态线程在检测到业务子卡拔出时,以事件1形式通知子卡配置线程该业务子卡的配置需要隐藏;
子卡配置线程收到事件1之后,以消息1形式通知子卡业务管理线程上传业务子卡的运行配置;
子卡业务管理线程获取当前业务子卡的运行配置,并保存在该业务子卡的资源和实例中后,将该业务子卡的运行配置全部发送给子卡配置线程;
子卡配置线程获取到业务子卡的运行配置,并将其保存到内存后,以消息2形式通知子卡管理状态线程该业务子卡的运行配置获取完毕;
子卡管理状态线程收到消息2后,以事件2形式通知子卡业务管理线程删除该业务子卡的资源和实例。
9.一种业务子卡管理装置,其特征在于,包括:
线程状态确定模块,用于使子卡管理状态线程、子卡配置线程、子卡业务管理线程确定自身的执行状态,其中,子卡管理状态线程用于根据业务子卡工作状态来维护业务子卡的使用情况,子卡配置线程用于实现业务子卡的配置恢复和配置保存,子卡业务管理线程用于维护业务子卡的业务数据;
线程管理模块,用于使各线程根据自身的执行状态进行通信;
其中,在带有业务子卡的整机启动时,各线程根据自身的执行状态进行通信,包括:
在带有业务子卡的整机启动后,子卡管理状态线程和子卡配置线程分别启动,其中,子卡管理状态线程启动后等待子卡配置线程消息;
子卡配置线程完成配置加载后,以消息形式通知子卡管理状态线程子卡配置线程准备完毕;
子卡管理状态线程收到消息后,开始处理后续业务。
10.如权利要求9所述的装置,其特征在于,线程管理模块进一步用于在使各线程根据自身的执行状态进行通信时,子卡管理状态线程与子卡配置线程、子卡管理状态线程与子卡业务管理线程之间分别采用事件形式进行线程间通信,子卡配置线程与子卡管理状态线程、子卡配置线程与子卡业务管理线程之间分别采用消息进行线程间通信,子卡业务管理线程与子卡配置线程之间采用消息进行线程间通信。
11.如权利要求9或10所述的装置,其特征在于,线程管理模块进一步用于在子卡管理状态线程与子卡配置线程之间进行线程间通信时,采用包括如下方式之一或者其组合的方式:
系统启动后,在子卡配置线程将配置加载完毕后通知子卡管理状态线程启动;
在子卡管理状态线程检测到有业务子卡插入,且业务子卡需要恢复配置时,通知子卡配置线程配置恢复事件;
在子卡配置线程执行配置恢复完成后,向子卡管理状态线程返回配置恢复结束消息;
在子卡管理状态线程检测到业务子卡拔出时,通知子卡配置线程子卡配置隐藏事件;
在子卡配置线程收到配置隐藏事件后,获取业务子卡的运行配置并在保存完毕后,向子卡管理状态线程返回配置获取结束消息;
当业务子卡需要恢复配置时,子卡管理状态线程通知子卡配置线程将业务子卡的配置下发给子卡业务管理线程,由子卡业务管理线程最终下发给物理业务子卡。
12.如权利要求9或10所述的装置,其特征在于,线程管理模块进一步用于在子卡业务管理线程与子卡配置线程之间进行线程间通信时,采用包括如下方式之一或者其组合的方式:
子卡配置线程在配置恢复时,将内存中该业务子卡的配置,以消息形式发送给子卡业务管理线程;
子卡配置线程在配置保存时,给子卡业务管理线程下发配置保存消息;
子卡业务管理线程收到配置保存消息后,通过物理通道获取业务子卡的运行配置,以消息形式发送给子卡配置线程,子卡配置线程收到该配置后,将该配置保存到内存。
13.如权利要求9或10所述的装置,其特征在于,线程管理模块进一步用于在子卡业务管理线程与子卡管理状态线程之间进行线程间通信时,采用包括如下方式之一或者其组合的方式:
子卡管理状态线程检测到有业务子卡插入之后,通知子卡业务管理线程创建该业务子卡的业务数据资源和实例;
当业务子卡需要恢复配置时,子卡管理状态线程通知子卡配置线程将业务子卡的配置下发给子卡业务管理线程,由子卡业务管理线程最终下发给物理业务子卡;
在业务子卡正常工作时,如果用户执行业务子卡的配置动作,子卡管理状态线程截获该配置,并将该配置下发给子卡业务管理线程,由子卡业务管理线程最终下发给物理业务子卡;
在业务子卡正常工作时,如果用户执行业务子卡的状态查询动作,子卡管理状态线程截获该动作,并发送给子卡业务管理线程;
当子卡管理状态线程检测到业务子卡拔出,通知子卡业务管理线程删除该业务子卡已经创建的实例和业务数据资源。
14.如权利要求9或10所述的装置,其特征在于,线程管理模块进一步用于在业务子卡插入时,使各线程根据自身的执行状态进行通信,包括:
子卡管理状态线程检测到有业务子卡插入后,迁移到power状态;
以事件形式通知子卡业务管理线程动态创建该业务子卡相应的资源。
15.如权利要求9或10所述的装置,其特征在于,线程管理模块进一步用于在恢复业务子卡配置时,使各线程根据自身的执行状态进行通信,包括:
子卡管理状态线程以事件形式通知子卡配置线程;
子卡配置线程在接收到通知后,从内存中取得该业务子卡的配置,以消息形式发送给子卡业务管理线程;
子卡业务管理线程接收配置,并在将业务子卡配置保存到为该业务子卡创建的资源和实例中后通知子卡配置线程;
子卡配置线程收到通知后,以消息形式通知子卡状态管理线程配置恢复完毕。
16.如权利要求9或10所述的装置,其特征在于,线程管理模块进一步用于在拔出业务子卡时,使各线程根据自身的执行状态进行通信,包括:
子卡管理状态线程在检测到业务子卡拔出时,以事件1形式通知子卡配置线程该业务子卡的配置需要隐藏;
子卡配置线程收到事件1之后,以消息1形式通知子卡业务管理线程上传业务子卡的运行配置;
子卡业务管理线程获取当前业务子卡的运行配置,并保存在该业务子卡的资源和实例中后,将该业务子卡的运行配置全部发送给子卡配置线程;
子卡配置线程获取到业务子卡的运行配置,并将其保存到内存后,以消息2形式通知子卡管理状态线程该业务子卡的运行配置获取完毕;
子卡管理状态线程收到消息2后,以事件2形式通知子卡业务管理线程删除该业务子卡的资源和实例。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710245415.9A CN107122251B (zh) | 2017-04-14 | 2017-04-14 | 一种业务子卡管理方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710245415.9A CN107122251B (zh) | 2017-04-14 | 2017-04-14 | 一种业务子卡管理方法及装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN107122251A CN107122251A (zh) | 2017-09-01 |
CN107122251B true CN107122251B (zh) | 2020-04-10 |
Family
ID=59725310
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201710245415.9A Active CN107122251B (zh) | 2017-04-14 | 2017-04-14 | 一种业务子卡管理方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN107122251B (zh) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110719198B (zh) * | 2019-09-30 | 2022-04-19 | 瑞斯康达科技发展股份有限公司 | Otn网元管理gcc的方法、管理卡、子卡及存储介质 |
CN112732343B (zh) * | 2020-12-31 | 2022-04-22 | 中国电子科技网络信息安全有限公司 | 一种堆叠设备中业务子母板卡加载的方法 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105700938A (zh) * | 2016-01-15 | 2016-06-22 | 浪潮通用软件有限公司 | 一种多线程处理数据的方法及装置 |
CN105786603A (zh) * | 2016-02-29 | 2016-07-20 | 青岛海尔智能家电科技有限公司 | 一种基于分布式的高并发业务处理系统及方法 |
CN105791419A (zh) * | 2016-04-15 | 2016-07-20 | 北京思特奇信息技术股份有限公司 | 一种分布式通讯系统及对应的分布式通讯方法 |
-
2017
- 2017-04-14 CN CN201710245415.9A patent/CN107122251B/zh active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105700938A (zh) * | 2016-01-15 | 2016-06-22 | 浪潮通用软件有限公司 | 一种多线程处理数据的方法及装置 |
CN105786603A (zh) * | 2016-02-29 | 2016-07-20 | 青岛海尔智能家电科技有限公司 | 一种基于分布式的高并发业务处理系统及方法 |
CN105791419A (zh) * | 2016-04-15 | 2016-07-20 | 北京思特奇信息技术股份有限公司 | 一种分布式通讯系统及对应的分布式通讯方法 |
Also Published As
Publication number | Publication date |
---|---|
CN107122251A (zh) | 2017-09-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN106790694B (zh) | 分布式系统及分布式系统中目标对象的调度方法 | |
CN105812169B (zh) | 一种主备机切换方法及装置 | |
CN106201690A (zh) | 应用运行控制方法及装置 | |
CN107122251B (zh) | 一种业务子卡管理方法及装置 | |
CN103761260B (zh) | 处理数据库互斥锁的方法和装置以及分布式系统 | |
CN110611707A (zh) | 一种任务调度的方法及装置 | |
CN105589756A (zh) | 批处理集群系统以及方法 | |
CN113448712A (zh) | 任务调度执行方法及装置 | |
CN104793992A (zh) | 一种基于任务分解的并行任务处理方法 | |
US20060288199A1 (en) | Watchdog system in a distributed computerized application environment | |
CN117130730A (zh) | 面向联邦Kubernetes集群的元数据管理方法 | |
CN109495528A (zh) | 分布式锁所有权调度方法和装置 | |
CN111078463B (zh) | 数据备份的方法、装置和系统 | |
CN111897626A (zh) | 一种面向云计算场景的虚拟机高可靠系统和实现方法 | |
CN111614702A (zh) | 一种边缘计算方法以及边缘计算系统 | |
CN111427259A (zh) | 一种机框插槽式的主备切换方法、智能设备及存储介质 | |
CN111400097A (zh) | 数据的备份方法、装置、系统和计算机可读存储介质 | |
CN111767122A (zh) | 分布式任务调度管理方法和装置 | |
CN112131188B (zh) | 批量文件分发处理方法及装置 | |
CN112835692B (zh) | 一种日志消息驱动任务方法、系统、存储介质及设备 | |
CN112612604B (zh) | 基于Actor模型的任务调度方法、装置 | |
CN110569115B (zh) | 多点部署的进程管理方法及进程的争夺方法 | |
CN103441872A (zh) | 一种用户侧设备的故障恢复方法、装置和通信系统 | |
US11518035B2 (en) | Method and apparatus for controlling robot, method and apparatus for providing service, and electronic device | |
CN114090211A (zh) | 协调单任务主从程序的方法、装置和相关多服务器系统 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
CB02 | Change of applicant information | ||
CB02 | Change of applicant information |
Address after: 100094 First to Fifth Floors of Building 11, East Yard, No. 10 Wangdong Road, Northwest Haidian District, Beijing Applicant after: Raisecom Technology Inc. Address before: 100085 No. 2 Building, No. 28 Shangdi Sixth Street, Haidian District, Beijing Applicant before: Raisecom Technology Inc. |
|
GR01 | Patent grant | ||
GR01 | Patent grant |