CN101158920B - 一种检测操作系统故障的方法和装置 - Google Patents
一种检测操作系统故障的方法和装置 Download PDFInfo
- Publication number
- CN101158920B CN101158920B CN2007101779323A CN200710177932A CN101158920B CN 101158920 B CN101158920 B CN 101158920B CN 2007101779323 A CN2007101779323 A CN 2007101779323A CN 200710177932 A CN200710177932 A CN 200710177932A CN 101158920 B CN101158920 B CN 101158920B
- Authority
- CN
- China
- Prior art keywords
- value
- word
- shared drive
- state variable
- drive district
- 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
Landscapes
- Hardware Redundancy (AREA)
Abstract
本发明公开了一种检测操作系统故障的方法,应用于具有多核多系统的设备中。该方法包括:从内存中划分出用于实现故障检测的共享内存区;多核多系统中的第二OS在正常时将正常状态字写入所述共享内存区中;多核多系统中的第一OS判断是否能够从所述共享内存区中读取到正常状态字,如果否,则确定第二OS故障。本发明还公开了一种检测操作系统故障的装置,包括共享内存区、多核多系统中的第一OS和第二OS。本发明能够实现对多核多系统中OS故障的检测。
Description
技术领域
本发明涉及通信技术,特别是涉及一种检测操作系统(OS,OperatingSystem)故障的方法和装置。
背景技术
目前,微处理器技术得到了飞速的发展,出现了多核处理器。简单说来,多核处理器就是在同一个硅晶片上集成了多个独立物理核心,在实际工作中,多颗核心能够分别独立完成工作,从而达到了性能倍增的目的。
基于多核处理器具有多个核心,每个核心能够分别独立完成工作的特点,在具有多核处理器的设备上运行多个操作系统则成为了可能。图1是现有技术中多核双系统的结构示意图。参见图1,以目前出现的一种多核双系统(MCDS,Multi-Core Dual-System)为例,设备中配置有多核处理器,多核处理器中的一部分核运行OS1,另一部分核运行OS2,比如OS1为防火墙处理所对应的操作系统,OS2为防病毒处理所对应的操作系统,这样,运行OS1的核和运行OS2的核则可以分别完成对应的防火墙和防病毒的业务处理,从而使得设备不仅能够因为具有多核处理器而极大地提高其处理性能,而且还能够因为具有双操作系统而完成多种业务处理,极大地提高了设备的处理性能。
诸如多核双系统的多核多系统中包括多个OS,每一个OS独立运行互不干扰,分别实现各自的业务处理功能。当其中任意一个OS发生故障无法运行时,其对应的功能则无法实现。这样,为了保证业务处理功能的正常实现,则要求能够检测出OS的故障,以便于采取对应的故障恢复措施。然而,诸如多核双系统的多核多系统是一种新出现的技术,目前还没有一种检测多核多系统中OS故障的方法。
由此可见,提供一种检测多核多系统中OS故障的方案已经成为了目前亟待解决的问题。
发明内容
有鉴于此,本发明的目的在于提供一种检测OS故障的方法和装置,以便于检测出多核多系统中OS的故障。
为了达到上述目的,本发明的技术方案是这样实现的:
一种检测操作系统故障的方法,应用于具有多核多系统的设备中,该方法包括:
从内存中划分出用于实现故障检测的共享内存区,在所述共享内存区中定义取值包括正常状态字和故障状态字的状态变量,并将所述状态变量的初始值设置为故障状态字;
多核多系统中的第二OS初始化完成后,如果正常则每当到达第二定时器的定时时间后访问共享内存区中的状态变量,将所述状态变量的值设置为正常状态字;
多核多系统中的第一OS初始化完成后,每当到达第一定时器的定时时间后访问共享内存区中的状态变量,判断所述状态变量的值是否为正常状态字,如果否,则确定第二OS故障;如果是,则第一OS将共享内存区中状态变量的值设置为故障状态字。
一种检测操作系统故障的装置,包括:共享内存区、多核多系统中的第一OS和第二OS,其中,
所述共享内存区中定义有取值包括正常状态字和故障状态字的状态变量,所述状态变量的初始值为故障状态字;
第一OS,用于在初始化完成后每当到达第一定时器的定时时间后访问共享内存区中的状态变量,判断所述状态变量的值是否为正常状态字,如果否,则确定第二OS故障;如果是,则将该状态变量的值设置为故障状态字;
第二OS,用于在初始化完成后,如果正常则每当到达第二定时器的定时时间后访问共享内存区中的状态变量,将该状态变量的值设置为正常状态字。
由此可见,在本发明中,多核多系统中的一个OS能够利用共享内存区来检测另一个OS是否故障,因此,提供了有效地检测多核多系统中OS故障的方案。
附图说明
图1是现有技术中多核双系统的结构示意图。
图2是在本发明一个实施例中检测OS故障的流程图。
图3A是在本发明实施例中多核双系统的结构示意图。
图3B是在本发明一个实施例中OS的状态迁移图。
图4是在本发明一个实施例中检测OS故障的装置结构示意图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚,下面结合附图及具体实施例对本发明作进一步地详细描述。
在多核多系统中,没有实际的物理通道,因此,不同OS之间无法通过发送消息的方式来实现OS故障的检测。而对多核多系统的特点进行分析可知,为了保证每一个OS的正常工作,每一个OS都拥有独立的内存区,都需要对内存进行访问。比如图1中,OS1和OS2分别需要访问其独享的内存区。
利用每一个OS都需要访问内存的特点,本发明提出了一种检测OS故障的方法。在该方法中,从内存中划分出用于实现故障检测的共享内存区;多核多系统中的第一OS将正常状态字写入所述共享内存区中;多核多系统中的第二OS判断是否能够从所述共享内存区中读取到正常状态字,如果是,则确定第一OS正常,否则,确定第一OS故障。
图2是在本发明一个实施例中检测OS故障的流程图。参见图1和图2,以多核双系统为例,本发明一个实施例检测该多核双系统中OS故障的过程具体包括以下步骤:
步骤201:预先从内存中划分出用于实现故障检测的共享内存区。
在划分内存区时,不仅需要在内存中为每一个OS划分其独享的内存区,保证每一个OS可以分别完成其业务处理功能,而且,为了保证后续OS故障的检测,还需要从内存中划分出用于实现故障检测的共享内存区。对于该共享内存区,每一个OS均可以访问。
此时,多核双系统的结构可以参见图3A所示。
步骤202:预先定义OS的运行状态。
这里,为了更好地在后续过程中区分出OS的具体故障情况,比如是初始启动时故障还是运行过程中故障,则需要通过本步骤的处理来定义出OS的运行状态。
本步骤中定义的OS的运行状态具体可以包括:初始态、初始化故障态、运行态和运行故障态。
步骤203:根据预先定义的OS工作状态,定义共享内存区中的状态变量及其对应的状态字。
由于OS的工作状态具体可以包括初始态、初始化故障态、运行态和运行故障态,因此,在后续过程中写入共享内存区的变量的状态字需要反映该四种工作状态。
在本步骤中,共享内存区中的状态变量记为ulHeartFlag,定义ulHeartFlag包括Bit0和Bit1两个比特位,其中,Bit0可以有0或1两种状态字,0为故障状态字,1为正常状态字;Bit1也有0或1两种状态字,0为初始态状态字,1为运行态状态字。这样,在后续过程中,通过状态变量ulHeartFlag的Bit0和Bit1两个比特位的状态字的不同组合,则可以分别表示OS的四种运行状态。
在本步骤中,设置ulHeartFlag的Bit1的初始值为0,Bit0的初始值为0。
在实际的实现中,可以定义一个枚举变量来表示OS2的四种工作状态,其数据结构可以设计为:
typedef enum tagMCDSOS2State
{
DRV_MCDS_HEART_OS2_INITIALING, /*OS2处于初始态*/
DRV_MCDS_HEART_OS2_INITIAL_FAIL,/*OS2处于初始故障态*/
DRV_MCDS_HEART_OS2_RUN, /*OS2处于运行态*/
DRV_MCDS_HEART_OS2_BLOCK, /*OS2处于运行故障态*/
DRV_MCDS_HEART_OS2_BUTT
}MCDS_OS2_STATE_E;
步骤204:预先定义共享内存区中的自旋锁变量及其变量值。
由于在后续过程中,OS1和OS2都会访问共享内存区,因此,为了避免出现OS1和OS2同时访问共享内存区同时进行读和写状态变量ulHeartFlag的操作,在本步骤中,需要定义出自旋锁变量记为ulHeartLock,并定义出ulHeartLock的值包括锁定状态字比如为1,锁定状态字表示有OS正在访问共享内存区,ulHeartLock的值还包括解锁状态字比如为0,解锁状态字表示没有OS访问共享内存区。
自旋锁变量ulHeartLock的初始值设置为解锁状态字0。
图3B是在本发明一个实施例中OS的状态迁移图。下述过程的处理可以参考图3B所示的状态迁移图。
另外,为便于描述,以下过程中以OS1正常初始化后正常运行,并检测OS2是否发生故障的过程为例进行说明。
步骤205:多核双系统中的OS1和OS2上电,进行初始化过程,处于初始态。
步骤206:在OS2初始化过程中,如果OS2初始化失败,那么,OS2进入初始化故障态,转向步骤216,如果OS2初始化完成,则执行步骤207。
这里,由于共享内存区中状态变量ulHeartFlag的Bit1和Bit0以及自旋锁变量ulHeartLock的初始值均为0,因此,如果OS2进入初始化故障态,则无法对共享内存区中的ulHeartFlag和ulHeartLock进行写操作,那么,共享内存区中ulHeartFlag的Bit1和Bit0的值以及ulHeartLock的值将始终保持为0。
步骤207:OS2初始化完成后,进入运行态。
步骤208:OS2访问共享内存区,首先将共享内存区中ulHeartLock的值置为1,然后将ulHeartFlag的Bit1的值置为1,在将Bit1的值置为1之后,重新将共享内存区中ulHeartLock的值置为0。
在本步骤中,由于OS2需要对共享内存区中的ulHeartFlag进行写操作,因此,为了避免OS1同时对共享内存区进行访问来对ulHeartFlag进行读操 作,需要首先将ulHeartLock值置为1,以表示共享内存区处于锁定状态。
另外,由于OS2已经初始化成功,因此,需要将共享内存区中ulHeartFlag的Bit1置为1,从而表示其已经从初始态进入了运行态。
在将Bit1置为1之后,需要重新将ulHeartLock的值置为0,以便此时OS1可以读取共享内存区中ulHeartFlag的Bit1的值。
步骤209:OS2将共享内存区中ulHeartLock的值置为1,然后将共享内存区中ulHeartFlag的Bit0的值置为1,并启动预先设置的1秒定时器。
这里,由于OS2当前处于正常,未发生故障,因此,需要将共享内存区中的Bit0置为1,从而表示其当前正常运行。
在实际的实现中,实现本步骤的程序可以设计为:
void OS2SetHeartFlagTimer(void)
{
if(获取自旋锁ulHeartLock成功)
{
将共享内存区的ulHeartFlag Bit0置1;
释放自旋锁ulHeartLock;
}
return;
}
步骤210:OS2将共享内存区中ulHeartLock值置为0。
在本步骤中,由于OS2已经完成对共享内存区中的ulHeartFlag进行写操作的处理,因此,为了保证OS1在后续过程中能够对共享内存区进行访问来对ulHeartFlag进行读操作,本步骤中需要将ulHeartLock值置为0,以表示共享内存区处于解锁状态。
步骤211:OS2处于运行态时,如果正常运行,那么,在检测到1秒定时器的定时时间到达后返回步骤209,如果发生故障,则执行步骤220。
步骤212:OS1正常初始化运行后,启动预先设置的3秒定时器。
在上述步骤209和步骤212中,定时器的定时时间可以根据实际检测的灵敏度需求来进行灵活设定,但是需要保证OS1使用的定时器的定时时间长度大于等于OS2使用的定时器的定时时间长度。
步骤213:在到达3秒定时器的定时时间后,OS1访问共享内存区,判断共享内存区中ulHeartLock的值是否为0,如果是,则执行步骤214,否则,启动3秒定时器,然后返回步骤213。
这里,如果自旋锁变量ulHeartLock的值为0则表示当前OS2没有对共享内存区进行访问,因此,OS1可以执行后续步骤中的访问共享内存区的处理。
步骤214:OS1将ulHeartLock的值置为1,然后判断共享内存区中ulHeartFlag的Bit1的值为1还是0,如果是0,则执行步骤215,如果是1,则执行步骤217。
这里,OS1首先将ulHeartLock的值置为1,是为了在对共享内存区进行访问的过程中,将共享内存区处于锁定状态,避免OS2同时对共享内存区进行访问。
步骤215:OS1判断已连续检测到Bit1的值为0的次数是否达到预先设定的次数阈值,如果是,则执行步骤216,否则,将ulHeartLock的值置为0,并启动3秒定时器,然后返回步骤213。
这里,由于在上述过程中如果OS2初始化成功,则会主动将Bit1的值置为1,如果OS2初始化失败,Bit1的值将保持为0,因此,如果OS1检测预先设定的次数阈值后(比如为100次,即5分钟),均检测到Bit1的值为0,那么,则可以确定OS2已经在初始化过程中发生了故障。
步骤216:OS1确定OS2处于初始化故障态,并向管理人员进行提示,结束当前流程。
这里,管理人员确定OS2发生初始化故障后,可以对OS2进行重启,参见图3B,使得OS2重新进入初始态。
步骤217:OS1判断共享内存区中ulHeartFlag的Bit0的值为1还是0, 如果是1,则执行步骤218,如果是0,则执行步骤219。
这里,如果OS1判断出Bit0的值为1,则可以确定OS2当前处于正常状态,未发生故障,继续执行后续重复检测的过程,而如果Bit0的值为0,则表示OS2当前发生故障。
步骤218:OS1将共享内存区中ulHeartFlag的Bit0的值置0,然后将共享内存区中ulHeartLock的值置为0,启动3秒定时器,返回步骤213。
步骤219:OS1判断已连续检测到Bit0的值为0的次数是否达到预先设定的次数阈值,如果是,则执行步骤220,否则,将共享内存区中ulHeartLock的值置为0,启动3秒定时器,返回步骤213。
这里,由于在上述过程中如果OS2正常运行,则会主动将Bit0的值置为1,如果OS2故障,Bit0的值将会保持为0,因此,如果OS1检测预先设定的次数阈值后(比如为3次,即9秒),均检测到Bit0的值为0,那么,则可以确定OS2已经在运行过程中发生了故障。
步骤220:OS1确定OS2处于运行故障态,并向管理人员进行提示。
这里,管理人员确定OS2在运行中发生故障后,可以对OS2进行重启,参见图3B,使得OS2重新进入初始态。
实现步骤212至步骤220的程序可以设计为:
unsigned long OS1 GetOS2StateTimer(void)
{
static unsigned long ulInitCnt=0;
static unsigned long ulHeartCnt=0;
unsigned long ulState=DRV_MCDS_HEART_OS2_RUN;
if(调用函数OS1GetHeartFlagBit1()返回0)
{
ulInitCnt++
if(ulInitCnt==100)
{
ulState=DRV_MCDS_HEART_OS2_INITIAL_FAIL;
}
else
{
ulState=DRV_MCDS_HEART_OS2_INITIALING;
}
return ulState;
}
if(调用函数OS1 GetHeartFlagBit0()返回0)
{
ulHeartCnt++;
if(ulHeartCnt==3)
{
ulState=DRV_MCDS_HEART_OS2_BLOCK;
}
}
else
{
ulHeartCnt=0;
将ulHeartFlag的Bit0清零;
}
return ulState;
}
unsigned long O S1 GetHeartFlagBit0(void)
{
if(获取自旋锁ulHeartLock成功)
{
if(共享内存区的ulHeartFlag Bit0为1)
{
释放自旋锁ulHeartLock;
return 1;
}
else
{
释放自旋锁ulHeartLock;
}
}
return 0;
}
unsigned long OS1 GetHeartFlagBit1(void)
{
if(获取自旋锁ulHeartLock成功)
{
if(共享内存区的ulHeartFlag Bit1为1)
{
释放自旋锁ulHeartLock;
return 1;
}
else
{
释放自旋锁ulHeartLock;
}
}
return 0;
}
需要说明的是,上述步骤206至步骤211的过程与步骤212至步骤220的过程是同时进行的,并无执行上的先后顺序。
还需要说明的是,在上述图2所示过程中,是以多核双系统为例来说明检测OS故障的过程。对于其他的多核多系统,比如多核3系统,其实现检测任意一个OS故障的过程与上述图2所示过程相同。
另外,根据业务发展的需要,在多核多系统中,很可能会有一个OS为主控OS,其他OS均为受控OS,这样,在本发明实施例的实现过程中,可以是由主控OS作为上述图2所示过程中的OS1,来对其他任意一个作为OS2的受控OS进行故障检测。此时,在上述步骤216和步骤220中,当主控的OS1检测出受控的OS2故障时,也可以由主控OS1主动对OS2进行重启处理,使得OS2重新进入初始态。
另外,本发明还提出了一种检测OS故障的装置。图4是在本发明一个实施例中检测OS故障的装置结构示意图。参见图4,该装置包括:共享内存区、多核多系统中的第一OS和第二OS,其中,
第一OS,用于判断是否能够从共享内存区中读取到正常状态字,如果否,则确定第二OS故障;
第二OS,用于在正常时将正常状态字写入所述共享内存区中。
在本发明装置中,利用共享内存区实现第二OS故障检测的一种具体实现方式可以为:
所述共享内存区中包括状态变量ulHeartFlag,并且,ulHeartFlag中包括比特位Bit0,Bit0的值包括正常状态字和故障状态字,Bit0的初始值为故障状态字;
所述第二OS,用于在初始化完成后,如果正常则每当到达第二定时器的定时时间后访问共享内存区中的状态变量ulHeartFlag,将比特位Bit0的值置为正常状态字;
所述第一OS,用于在初始化完成后,每当到达第一定时器的定时时间后访问共享内存区中的状态变量ulHeartFlag,判断比特位Bit0的值是否为 正常状态字,如果否,则确定第二OS故障,如果是,则将比特位Bit0的值置为故障状态字。
较佳地,在本发明装置中,所述共享内存区中的状态变量ulHeartFlag中进一步包括比特位Bit1,Bit1的值包括初始态状态字和运行态状态字,Bit1的初始值为初始态状态字;
所述第二OS,进一步用于在初始化完成后,访问共享内存区中的状态变量ulHeartFlag,将比特位Bit1的值置为运行态状态字;
所述第一OS,进一步用于在判断共享内存区中状态变量ulHeartFlag的比特位Bit0的值是否为正常状态字之前,判断比特位Bit1的值是否为初始态状态字,如果是,则直接确定第二OS处于初始化故障态,结束本次访问共享内存区的处理,否则,继续执行所述的判断共享内存区中状态变量ulHeartFlag的比特位Bit0的值是否为正常状态字的处理,并且,如果Bit0的值不为正常状态字,则确定第二OS为运行故障态。
较佳地,在本发明装置中,所述共享内存区中包括自旋锁变量ulHeartLock,ulHeartLock的值包括锁定状态字和解锁状态字,ulHeartLock的初始值为解锁状态字;
所述第一OS和第二OS,均进一步用于在每次访问共享内存区中状态变量ulHeartFlag之前,判断共享内存区中自旋锁变量ulHeartLock的值是否为解锁状态字,如果是,则将ulHeartLock的值置为锁定状态字,并继续执行所述的访问共享内存区中的状态变量ulHeartFlag的处理,并在每次对共享内存区访问完毕后,将自旋锁变量ulHeartLock的值置为解锁状态字。
在本发明装置中,所述第一OS可以为多核多系统中的主控OS,所述第二OS可以为多核多系统中的任意一个受控OS。
总之,以上所述仅为本发明的较佳实施例而已,并非用于限定本发明的保护范围。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (12)
1.一种检测操作系统故障的方法,应用于具有多核多系统的设备中,其特征在于,该方法包括:
从内存中划分出用于实现故障检测的共享内存区,在所述共享内存区中定义取值包括正常状态字和故障状态字的状态变量,并将所述状态变量的初始值设置为故障状态字;
多核多系统中的第二OS初始化完成后,如果正常则每当到达第二定时器的定时时间后访问共享内存区中的状态变量,将所述状态变量的值设置为正常状态字;
多核多系统中的第一OS初始化完成后,每当到达第一定时器的定时时间后访问共享内存区中的状态变量,判断所述状态变量的值是否为正常状态字,如果否,则确定第二OS故障;如果是,则第一OS将共享内存区中状态变量的值设置为故障状态字。
2.根据权利要求1所述的方法,其特征在于,所述在共享内存区中定义的状态变量为包括比特位Bit0的状态变量ulHeartFlag,并且,定义Bit0的值包括正常状态字和故障状态字;
所述将状态变量的初始值设置为故障状态字为:将Bit0的初始值设置为故障状态字;
所述第二OS访问共享内存区中的状态变量,将所述状态变量的值设置为正常状态字为:第二OS访问共享内存区中的状态变量ulHeartFlag,将比特位Bit0的值置为正常状态字;
所述第一OS访问共享内存区中的状态变量,判断所述状态变量的值是否为正常状态字为:第一OS访问共享内存区中的状态变量ulHeartFlag,判断比特位Bit0的值是否为正常状态字;
所述第一OS将共享内存区中状态变量的值设置为故障状态字为:第一OS将共享内存区中状态变量ulHeartFlag的比特位Bit0的值置为故障状态字。
3.根据权利要求2所述的方法,其特征在于,在第一OS判断出比特位Bit0的值不是正常状态字之后,并在确定第二OS故障之前,进一步包括:第一OS判断已连续检测到比特位Bit0的值不是正常状态字的次数是否达到预先设定的次数阈值,如果是,则继续执行所述的确定第二OS故障的步骤,否则,返回执行所述的每当到达第一定时器的定时时间后访问共享内存区中的状态变量ulHeartFlag的步骤。
4.根据权利要求2所述的方法,其特征在于,该方法进一步包括:定义状态变量ulHeartFlag中包括比特位Bit1,并且,定义Bit1的值包括初始态状态字和运行态状态字,并将Bit1的初始值设置为初始态状态字;第二OS如果初始化完成,则访问共享内存区中的状态变量ulHeartFlag,将比特位Bit1的值置为运行态状态字;
在到达第一定时器的定时时间之后,并在判断比特位Bit0的值是否为正常状态字之前,进一步包括:第一OS判断共享内存区中状态变量ulHeartFlag的比特位Bit1的值是否为初始态状态字,如果是,则直接确定第二OS处于初始化故障态,结束当前流程,否则,继续执行所述的判断比特位Bit0的值是否为正常状态字的步骤;
则,所述的确定第二OS故障为确定第二OS为运行故障态。
5.根据权利要求4所述的方法,其特征在于,在第一OS判断出比特位Bit1的值为初始态状态字之后,并在确定第二OS处于初始化故障态之前,进一步包括:
第一OS判断已连续检测到比特位Bit1的值为初始态状态字的次数是否达到预先设定的次数阈值,如果是,则继续执行所述的确定第二OS处于初始化故障态的步骤,否则,返回执行所述的每当到达第一定时器的定时时间后访问共享内存区中的状态变量ulHeartFlag的步骤。
6.根据权利要求1至5中任意一项所述的方法,其特征在于,该方法进一步包括:在共享内存区中定义自旋锁变量ulHeartLock,并且,定义ulHeartLock的值包括锁定状态字和解锁状态字,并将ulHeartLock的初始值设置为解锁状态字;
在第一OS和第二OS每次访问共享内存区中的状态变量ulHeartFlag之前,进一步包括:判断共享内存区中自旋锁变量ulHeartLock的值是否为解锁状态字,如果是,则将ulHeartLock的值置为锁定状态字,并继续执行所述的访问共享内存区中的状态变量ulHeartFlag的步骤;
在第一OS和第二OS每次对共享内存区访问完毕后,进一步包括:将共享内存区中自旋锁变量ulHeartLock的值置为解锁状态字。
7.根据权利要求1至5中任意一项所述的方法,其特征在于,所述第一OS为多核多系统中的主控OS,所述第二OS为多核多系统中的任意一个受控OS。
8.一种检测操作系统故障的装置,其特征在于,包括:共享内存区、多核多系统中的第一OS和第二OS,其中,
所述共享内存区中定义有取值包括正常状态字和故障状态字的状态变量,所述状态变量的初始值为故障状态字;
第一OS,用于在初始化完成后每当到达第一定时器的定时时间后访问共享内存区中的状态变量,判断所述状态变量的值是否为正常状态字,如果否,则确定第二OS故障;如果是,则将该状态变量的值设置为故障状态字;
第二OS,用于在初始化完成后,如果正常则每当到达第二定时器的定时时间后访问共享内存区中的状态变量,将该状态变量的值设置为正常状态字。
9.根据权利要求8所述的装置,其特征在于,所述共享内存区中定义的状态变量为状态变量ulHeartFlag,并且,ulHeartFlag中包括比特位Bit0,Bit0的值包括正常状态字和故障状态字,Bit0的初始值为故障状态字;
所述第二OS访问共享内存区中的状态变量,将所述状态变量的值设置为正常状态字为:访问共享内存区中的状态变量ulHeartFlag,将比特位Bit0的值置为正常状态字;
所述第一OS访问共享内存区中的状态变量,判断所述状态变量的值是否为正常状态字为:访问共享内存区中的状态变量ulHeartFlag,判断比特位Bit0的值是否为正常状态字;
所述第一OS将共享内存区中状态变量的值设置为故障状态字为:将共享内存区中状态变量ulHeartFlag的比特位Bit0的值置为故障状态字。
10.根据权利要求9所述的装置,其特征在于,所述共享内存区中的状态变量ulHeartFlag中进一步包括比特位Bit1,Bit1的值包括初始态状态字和运行态状态字,Bit1的初始值为初始态状态字;
所述第二OS,进一步用于在初始化完成后,访问共享内存区中的状态变量ulHeartFlag,将比特位Bit1的值置为运行态状态字;
所述第一OS,进一步用于在判断共享内存区中状态变量ulHeartFlag的比特位Bit0的值是否为正常状态字之前,判断比特位Bit1的值是否为初始态状态字,如果是,则直接确定第二OS处于初始化故障态,结束本次访问共享内存区的处理,否则,继续执行所述的判断共享内存区中状态变量ulHeartFlag的比特位Bit0的值是否为正常状态字的处理,并且,如果Bit0的值不为正常状态字,则确定第二OS为运行故障态。
11.根据权利要求8、9或10所述的装置,其特征在于,所述共享内存区中包括自旋锁变量ulHeartLock,ulHeartLock的值包括锁定状态字和解锁状态字,ulHeartLock的初始值为解锁状态字;
所述第一OS和第二OS,均进一步用于在每次访问共享内存区中状态变量ulHeartFlag之前,判断共享内存区中自旋锁变量ulHeartLock的值是否为解锁状态字,如果是,则将ulHeartLock的值置为锁定状态字,并继续执行所述的访问共享内存区中的状态变量ulHeartFlag的处理,并在每次对共享内存区访问完毕后,将自旋锁变量ulHeartLock的值置为解锁状态字。
12.根据权利要求8、9或10所述的装置,其特征在于,所述第一OS为为多核多系统中的主控OS,所述第二OS为多核多系统中的任意一个受控OS。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2007101779323A CN101158920B (zh) | 2007-11-22 | 2007-11-22 | 一种检测操作系统故障的方法和装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2007101779323A CN101158920B (zh) | 2007-11-22 | 2007-11-22 | 一种检测操作系统故障的方法和装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101158920A CN101158920A (zh) | 2008-04-09 |
CN101158920B true CN101158920B (zh) | 2011-02-16 |
Family
ID=39307027
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2007101779323A Active CN101158920B (zh) | 2007-11-22 | 2007-11-22 | 一种检测操作系统故障的方法和装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101158920B (zh) |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE102013217601A1 (de) * | 2013-09-04 | 2015-03-05 | Robert Bosch Gmbh | Verfahren zum Notbetrieb eines Multicore-Prozessors eines Steuergeräts eines Kraftfahrzeugs |
CN104503892B (zh) * | 2014-12-19 | 2018-07-24 | 宇龙计算机通信科技(深圳)有限公司 | 终端异常的处理方法、处理装置和终端 |
CN105204952B (zh) * | 2015-08-21 | 2018-03-09 | 北京控制工程研究所 | 一种多核操作系统容错管理方法 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1349627A (zh) * | 2000-03-08 | 2002-05-15 | 三菱电机株式会社 | 处理器的省电控制方法、记录媒体、以及处理器的省电控制装置 |
CN1904873A (zh) * | 2005-07-28 | 2007-01-31 | 大唐移动通信设备有限公司 | 嵌入式实时操作系统中多核处理器的核间通信方法及装置 |
DE102006012042A1 (de) * | 2006-03-16 | 2007-09-20 | Kuka Roboter Gmbh | Steuervorrichtung zur fehlersicheren Steuerung einer Maschine |
-
2007
- 2007-11-22 CN CN2007101779323A patent/CN101158920B/zh active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1349627A (zh) * | 2000-03-08 | 2002-05-15 | 三菱电机株式会社 | 处理器的省电控制方法、记录媒体、以及处理器的省电控制装置 |
CN1904873A (zh) * | 2005-07-28 | 2007-01-31 | 大唐移动通信设备有限公司 | 嵌入式实时操作系统中多核处理器的核间通信方法及装置 |
DE102006012042A1 (de) * | 2006-03-16 | 2007-09-20 | Kuka Roboter Gmbh | Steuervorrichtung zur fehlersicheren Steuerung einer Maschine |
Also Published As
Publication number | Publication date |
---|---|
CN101158920A (zh) | 2008-04-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN100582799C (zh) | 电子设备诊断方法和系统 | |
US8601493B2 (en) | Application controlling apparatus and storage medium which stores software for the apparatus | |
CN1316362C (zh) | 重定位在多线程计算机中共享的计算机数据的设备和方法 | |
CN109670319B (zh) | 一种服务器flash安全管理方法及其系统 | |
WO2013094048A1 (ja) | 試験サーバ、情報処理システム、試験プログラムおよび試験方法 | |
EP2095231A2 (en) | Computer system and method of control thereof | |
CN108984349B (zh) | 主节点选举方法及装置、介质和计算设备 | |
CN112199240B (zh) | 一种节点故障时进行节点切换的方法及相关设备 | |
CN101216792B (zh) | 实时操作系统的任务管理方法、装置 | |
CN113064748B (zh) | 进程接替的方法、装置、电子设备及存储介质 | |
EP1943593B1 (en) | Methods and apparatus for automatically multi-booting a computer system | |
CN100538644C (zh) | 执行计算机程序的方法、计算设备 | |
CN107783844A (zh) | 一种计算机程序运行异常检测方法、装置和介质 | |
US8321608B2 (en) | Pool I/O device operation confirmation method and computer system | |
CN101158920B (zh) | 一种检测操作系统故障的方法和装置 | |
CN103631591A (zh) | 符合民用飞机不同软件等级要求的软件运行控制系统与方法 | |
CN106909382B (zh) | 输出不同类型系统启动信息的方法及装置 | |
CN106547606B (zh) | 堆栈自检方法及装置 | |
CN100511165C (zh) | 执行计算机程序的方法、操作系统以及计算设备 | |
CN111858187A (zh) | 一种电子设备及业务切换方法、装置 | |
US20110154349A1 (en) | Resource fault management for partitions | |
CN115145381A (zh) | 一种远程重置bmc芯片的方法、系统、存储介质及设备 | |
US20040246894A1 (en) | Ineligible group member status | |
CN103186403A (zh) | 节点置换处理方法与使用该方法的服务器系统 | |
JPH0766368B2 (ja) | ブ−トプロセツサ決定方式 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CP03 | Change of name, title or address |
Address after: 310052 Binjiang District Changhe Road, Zhejiang, China, No. 466, No. Patentee after: Xinhua three Technology Co., Ltd. Address before: 310053 Hangzhou hi tech Industrial Development Zone, Zhejiang province science and Technology Industrial Park, No. 310 and No. six road, HUAWEI, Hangzhou production base Patentee before: Huasan Communication Technology Co., Ltd. |
|
CP03 | Change of name, title or address |