CN104820622A - 一种共享内存锁管理控制方法及*** - Google Patents
一种共享内存锁管理控制方法及*** Download PDFInfo
- Publication number
- CN104820622A CN104820622A CN201510266134.2A CN201510266134A CN104820622A CN 104820622 A CN104820622 A CN 104820622A CN 201510266134 A CN201510266134 A CN 201510266134A CN 104820622 A CN104820622 A CN 104820622A
- Authority
- CN
- China
- Prior art keywords
- shared drive
- time
- drive lock
- management control
- deadlock
- 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.)
- Granted
Links
Landscapes
- Multi Processors (AREA)
Abstract
本发明提供一种共享内存锁管理控制方法及***，应用于多个进程访问共享内存的过程中，所述共享内存锁管理控制方法包括：根据各进程调用的接口函数确定区分各进程共享内存锁的获取方式；设定一个全局变量，根据进程的类型和***状态预设所述全局变量的值，通过所述全局变量的值来区分进程在死锁状态下的处理方式。本发明既可以保证各个进程间访问共享内存时的正确性，也可以在进程获取锁时采用不同的获取锁策略，而且可以有效的解决的由进程异常导致的死锁问题，并且在处理死锁的过程中也可以依据不同***状态来采用不同的处理方式，使得***更加灵活、可靠和稳定。
Description
技术领域
本发明涉及家庭网关技术领域，特别是涉及家庭网关设备中共享内存数据技术领域，具体为一种共享内存锁管理控制方法及***。
背景技术
共享内存是被多个进程共享的一部分物理内存。共享内存是进程间共享数据的一种最快的方法，一个进程向共享内存区域写入了数据，共享这个内存区域的所有进程就可以立刻看到其中的内容。目前linux嵌入式***中采用多进程设计，多进程之间采用共享内存进行通信。通信进程会将采集数据更新到共享内存，其它多个进程都需要从共享内存中读取数据。这样的“一个进程写、多个进程读”的模型，需要采用读写锁来提高访问效率。
在***运行过程中进程可以通过加锁和解锁的机制来实现保护共享内存中的数据不被破坏而导致***崩溃，但是某个进程对锁的错误操作后者本身的错误使得管理锁的机制出现异常，此时就需要设计出一种有效的防止和处理异常情况的共享内存锁管理机制。
现有的嵌入式linux***中共享内存锁的机制，允许进程在访问时对共享内存进行加锁和解锁的动作来获取访问权限和处理数据，造成的主要问题如下：
1、获取读写权限的超时周期固定，无法适应不同的进程；
2、某个进程在锁定并操作共享内存的过程中出现异常，导致死锁的问题，其他进程将无法访问，导致***瘫痪；
3、对共享内存进行锁操作时没有对***状态进行区分；
4、进程多且复杂度高的***稳定性不足。
如何解决进行再访问共享内存时面临的以上问题成为本领域技术人员亟待解决的问题。
发明内容
鉴于以上所述现有技术的缺点，本发明的目的在于提供一种共享内存锁管理控制方法及***，用于解决现有技术中进程在访问***的共享内存时容易导致***瘫痪、导致***不稳定的问题。
为实现上述目的及其他相关目的，本发明提供一种共享内存锁管理控制方法，应用于多个进程访问共享内存的过程中，所述共享内存锁管理控制方法包括：根据各进程调用的接口函数确定区分各进程共享内存锁的获取方式；设定一个全局变量，根据进程的类型和***状态预设所述全局变量的值，通过所述全局变量的值来区分进程在死锁状态下的处理方式。
作为本发明的一种优选方案，所述接口函数至少包括：提供进程在获取共享内存锁时进行超时计时且超时为第一预设时间时的第一函数接口；提供进程在获取共享内存锁时进行超时计时且超时为第二预设时间时的第二函数接口；提供进程在获取共享内存锁时进行超时计时且超时为第三预设时间时的第三函数接口；提供进程在获取共享内存锁时不进行超时计时的第四函数接口。
作为本发明的一种优选方案，所述第一预设时间的时间取值范围为1s～3s；所述第二预设时间的时间取值范围为4s～6s；所述第三预设时间的时间取值范围为7s～11s。
作为本发明的一种优选方案，所述全局变量的值为第一预设值时，进程在死锁状态下的处理方式为：判定进程死锁，将该进程强行停止。
作为本发明的一种优选方案，所述全局变量的值为第二预设值时，进程在死锁状态下的处理方式为：判定进程死锁，保留该进程。
为实现上述目的，本发明还提供一种共享内存锁管理控制***，应用于多个进程访问共享内存的过程中，所述共享内存锁管理控制***包括：内存锁的获取方式模块，用于根据各进程调用的接口函数确定区分各进程共享内存锁的获取方式；死锁状态处理模块，与所述内存锁的获取方式模块相连，用于设定一个全局变量，根据进程的类型和***状态预设所述全局变量的值，通过所述全局变量的值来区分进程在死锁状态下的处理方式。
作为本发明的一种优选方案，所述接口函数至少包括：提供进程在获取共享内存锁时进行超时计时且超时为第一预设时间时的第一函数接口；提供进程在获取共享内存锁时进行超时计时且超时为第二预设时间时的第二函数接口；提供进程在获取共享内存锁时进行超时计时且超时为第三预设时间时的第三函数接口；提供进程在获取共享内存锁时不进行超时计时的第四函数接口。
作为本发明的一种优选方案，所述第一预设时间的时间取值范围为1s～3s；所述第二预设时间的时间取值范围为4s～6s；所述第三预设时间的时间取值范围为7s～11s。
作为本发明的一种优选方案，所述全局变量的值为第一预设值时，进程在死锁状态下的处理方式为：判定进程死锁，将该进程强行停止。
作为本发明的一种优选方案，所述全局变量的值为第二预设值时，进程在死锁状态下的处理方式为：判定进程死锁，保留该进程。
如上所述，本发明的一种共享内存锁管理控制方法及***，具有以下有益效果：
本发明通过区分各进程共享内存锁的获取方式，既可以保证各个进程间访问共享内存时的正确性，也可以在进程获取锁时采用不同的获取锁策略，并通过全局变量的值来区分进程在死锁状态下的处理方式，可以有效的解决的由进程异常导致的死锁问题，并且在处理死锁的过程中也可以依据不同***状态来采用不同的处理方式，使得***更加灵活、可靠和稳定。
附图说明
图1显示为本发明的共享内存锁管理控制方法的流程示意图。
图2显示为本发明的共享内存锁管理控制***的结构示意图。
元件标号说明
1 共享内存锁管理控制***
11 内存锁的获取方式模块
12 死锁状态处理模块
S11～S12 步骤
具体实施方式
以下通过特定的具体实例说明本发明的实施方式，本领域技术人员可由本说明书所揭露的内容轻易地了解本发明的其他优点与功效。本发明还可以通过另外不同的具体实施方式加以实施或应用，本说明书中的各项细节也可以基于不同观点与应用，在没有背离本发明的精神下进行各种修饰或改变。
本发明的目的在于提供一种共享内存锁管理控制方法及***，用于解决现有技术中进程在访问***的共享内存时容易导致***瘫痪、导致***不稳定的问题。以下将详细阐述本发明的一种共享内存锁管理控制方法及***的原理及实施方式，使本领域技术人员不需要创造性劳动即可理解本发明的一种共享内存锁管理控制方法及***。
第一实施例
本实施例提供一种共享内存锁管理控制方法，本实施例涉及linux***的家庭网关产品，主要实现和改进了一种多进程访问共享内存的锁管理机制。
本实施例的主要功能是实现嵌入式无线家庭网关设备中不同进程访问***共享内存数据下锁的机制的改进和优化，基于现有网关实际使用过程中的操作和需求，以及现有的应用进程访问共享内存的管理机制，改进并设计了一套具有多进程访问共享内存时的保护锁的机制，同时又能防止和处理某些未知情况下导致锁获取失败和死锁的情况，通过区分不同的应用进程来实现共享内存锁的动态管理机制，实现了***的运行的稳定性和可靠性。
本实施例针对现有技术中管理共享内存锁机制的不足之处，考虑到当前嵌入式家庭网关设备的具体***和实际需求，设计并提出了一套改进的管理共享内存的锁机制，本实施例的主要目的是：
1、对进程获取锁的方式进行区分。
2、对进程异常导致的死锁问题进行了处理，避免***瘫痪。
3、区分不同***状态下死锁问题的处理方案。
4、提升***的可靠性和稳定性。
具体地，如图1所示，本实施例提供一种共享内存锁管理控制方法，应用于多个进程访问共享内存的过程中，所述共享内存锁管理控制方法包括以下步骤。
步骤S11，根据各进程调用的接口函数确定区分各进程共享内存锁的获取方式。嵌入式linux***由于多进程访问共享内存，且每个进程***中处于不同的层级和功能，因而获取锁的方式也要进行区分。
在本实施例中，具体地，所述接口函数至少包括：第一函数接口、第二函数接口、第三函数接口以及第四函数接口。
第一函数接口提供进程在获取共享内存锁时进行超时计时且超时为第一预设时间，其中，所述第一预设时间的时间取值范围为1s～3s，例如第一函数接口提供进程在获取共享内存锁时进行超时计时且超时为2s。
第二函数接口提供进程在获取共享内存锁时进行超时计时且超时为第二预设时间时，其中，所述第二预设时间的时间取值范围为4s～6s，例如第二函数接口提供进程在获取共享内存锁时进行超时计时且超时为5s。
第三函数接口提供进程在获取共享内存锁时进行超时计时且超时为第三预设时间，其中，所述第三预设时间的时间取值范围为7s～11s，例如第三函数接口提供进程在获取共享内存锁时进行超时计时且超时为10s。
第四函数接口提供进程在获取共享内存锁时不进行超时计时。
选择何种锁获取方式由各个进程在调用获取锁接口时自行决定，具体的获取锁策略的接口有以下几种方式：
获取锁方式的4种接口及函数：
1、没有超时功能的获取锁方式
第四函数接口：接口函数：void getLock()。
2、具有超时功能的获取锁方式，且超时时间为2s
第一函数接口：接口函数：void getLockWithTimeout1()。
3、具有超时功能的获取锁方式，且超时时间为5s
第二函数接口：接口函数：void getLockWithTimeout2()。
4、具有超时功能的获取锁方式，且超时时间为10s
第三函数接口：接口函数：void getLockWithTimeout3()。
以上4中不同的接口函数可以提供不同的获取锁的方式，第四种进程在获取锁时候不进行超时计时，即使此时共享内存被其他进程占用，其他三种接口提供了可以计时的获取锁方式，当获取锁的动作在到设定时间到期没有成功后，停止获取共享内存锁的动作，该超时时间可以为2s、5s、10s。
可见，本实施例通过区分不同进程，提供了更加灵活的获取锁接口。进程在调用访问共享内存锁接口成功后，在操作共享内存的过程中有可能出现异常，出现无法释放该共享内存锁的情况，导致其他进程无法调用锁接口，进而无法操作共享内存，出现***瘫痪，为了解决死锁的问题，采用对进程进行强制停止并释放共享内存的方式，但考虑到***运行过程中有不同的状态，某些特定状态下不能采用强行关闭掉死锁进程情况，本实施例提供根据***进程和死锁进程的动态解决方案，具体如步骤S12。
在步骤S12中，设定一个全局变量，根据进程的类型和***状态预设所述全局变量的值，通过所述全局变量的值来区分进程在死锁状态下的处理方式。
其中，所述全局变量的值为第一预设值(例如为1)时，进程在死锁状态下的处理方式为：判定进程死锁，将该进程强行停止。所述全局变量的值为第二预设值(例如为0)时，进程在死锁状态下的处理方式为：判定进程死锁，保留该进程。
具体实现方式如下：
首先进程在调用并获取到共享内存锁接口后，依据该进程的类型和***状态来判定死锁情况下的处理方式，通过设定全局变量failLockNeedKill来区分；
***分为2大状态：操作关键配置状态：wan、wifi；操作非关键配置及其他状态：other。
全局变量failLockNeedKill值的具体说明如下：
failLockNeedKill＝1：此时判断进程死锁，***可以将该进程强行停止。
failLockNeedKill＝0：此时判断进程死锁，***不作操作，保留该进程。
在进程开始管理共享内存的过程中，全局变量的值一开始就被确定为0或者1，之后当***判断进入死锁状态后，通过判断该全局变量的值的具体值，来进行死锁处理。
由上可见，本实施例通过提供了一套解决***死锁的处理机制，有效的避免的死锁引起的***瘫痪，本实施例考虑了***状态和获取锁进程，解决死锁问题的同时提高了***的稳定性；本实施例建立了一套动态的锁管理机制，更加适用于linux等较为复杂的多进程***。
第二实施例
为实现上述共享内存锁管理控制方法，本实施例对应提供提供一种共享内存锁管理控制***，本实施例涉及linux***的家庭网关产品，主要实现和改进了一种多进程访问共享内存的锁管理机制。
本实施例的主要功能是实现嵌入式无线家庭网关设备中不同进程访问***共享内存数据下锁的机制的改进和优化，基于现有网关实际使用过程中的操作和需求，以及现有的应用进程访问共享内存的管理机制，改进并设计了一套具有多进程访问共享内存时的保护锁的机制，同时又能防止和处理某些未知情况下导致锁获取失败和死锁的情况，通过区分不同的应用进程来实现共享内存锁的动态管理机制，实现了***的运行的稳定性和可靠性。
本实施例针对现有技术中管理共享内存锁机制的不足之处，考虑到当前嵌入式家庭网关设备的具体***和实际需求，设计并提出了一套改进的管理共享内存的锁机制，本实施例的主要目的是：
1、对进程获取锁的方式进行区分。
2、对进程异常导致的死锁问题进行了处理，避免***瘫痪。
3、区分不同***状态下死锁问题的处理方案。
4、提升***的可靠性和稳定性。
本实施例提供提供一种共享内存锁管理控制***，应用于多个进程访问共享内存的过程中，具体地，如图2所示，共享内存锁管理控制***1包括：内存锁的获取方式模块11和死锁状态处理模块12。
内存锁的获取方式模块11用于根据各进程调用的接口函数确定区分各进程共享内存锁的获取方式；嵌入式linux***由于多进程访问共享内存，且每个进程***中处于不同的层级和功能，因而获取锁的方式也要进行区分。
在本实施例中，具体地，所述接口函数至少包括：第一函数接口、第二函数接口、第三函数接口以及第四函数接口。
第一函数接口提供进程在获取共享内存锁时进行超时计时且超时为第一预设时间，其中，所述第一预设时间的时间取值范围为1s～3s，例如第一函数接口提供进程在获取共享内存锁时进行超时计时且超时为2s。
第二函数接口提供进程在获取共享内存锁时进行超时计时且超时为第二预设时间时，其中，所述第二预设时间的时间取值范围为4s～6s，例如第二函数接口提供进程在获取共享内存锁时进行超时计时且超时为5s。
第三函数接口提供进程在获取共享内存锁时进行超时计时且超时为第三预设时间，其中，所述第三预设时间的时间取值范围为7s～11s，例如第三函数接口提供进程在获取共享内存锁时进行超时计时且超时为10s。
第四函数接口提供进程在获取共享内存锁时不进行超时计时。
选择何种锁获取方式由各个进程在调用获取锁接口时自行决定，具体的获取锁策略的接口有以下几种方式：
获取锁方式的4种接口及函数：
1、没有超时功能的获取锁方式
第四函数接口：接口函数：void getLock()。
2、具有超时功能的获取锁方式，且超时时间为2s
第一函数接口：接口函数：void getLockWithTimeout1()。
3、具有超时功能的获取锁方式，且超时时间为5s
第二函数接口：接口函数：void getLockWithTimeout2()。
4、具有超时功能的获取锁方式，且超时时间为10s
第三函数接口：接口函数：void getLockWithTimeout3()。
以上4中不同的接口函数可以提供不同的获取锁的方式，第四种进程在获取锁时候不进行超时计时，即使此时共享内存被其他进程占用，其他三种接口提供了可以计时的获取锁方式，当获取锁的动作在到设定时间到期没有成功后，停止获取共享内存锁的动作，该超时时间可以为2s、5s、10s。
可见，本实施例通过区分不同进程，提供了更加灵活的获取锁接口。进程在调用访问共享内存锁接口成功后，在操作共享内存的过程中有可能出现异常，出现无法释放该共享内存锁的情况，导致其他进程无法调用锁接口，进而无法操作共享内存，出现***瘫痪，为了解决死锁的问题，采用对进程进行强制停止并释放共享内存的方式，但考虑到***运行过程中有不同的状态，某些特定状态下不能采用强行关闭掉死锁进程情况，本实施例提供根据***进程和死锁进程的动态解决方案。
死锁状态处理模块12与所述内存锁的获取方式模块11相连，用于设定一个全局变量，根据进程的类型和***状态预设所述全局变量的值，通过所述全局变量的值来区分进程在死锁状态下的处理方式。
其中，所述全局变量的值为第一预设值(例如为1)时，进程在死锁状态下的处理方式为：判定进程死锁，将该进程强行停止。所述全局变量的值为第二预设值(例如为0)时，进程在死锁状态下的处理方式为：判定进程死锁，保留该进程。
具体实现方式如下：
首先进程在调用并获取到共享内存锁接口后，依据该进程的类型和***状态来判定死锁情况下的处理方式，通过设定全局变量failLockNeedKill来区分；
***分为2大状态：操作关键配置状态：wan、wifi；操作非关键配置及其他状态：other。
全局变量failLockNeedKill值的具体说明如下：
failLockNeedKill＝1：此时判断进程死锁，***可以将该进程强行停止。
failLockNeedKill＝0：此时判断进程死锁，***不作操作，保留该进程。
在进程开始管理共享内存的过程中，全局变量的值一开始就被确定为0或者1，之后当***判断进入死锁状态后，通过判断该全局变量的值的具体值，来进行死锁处理。
由上可见，本实施例通过提供了一套解决***死锁的处理机制，有效的避免的死锁引起的***瘫痪，本实施例考虑了***状态和获取锁进程，解决死锁问题的同时提高了***的稳定性；本实施例建立了一套动态的锁管理机制，更加适用于linux等较为复杂的多进程***。
综上所述，本发明通过区分各进程共享内存锁的获取方式，既可以保证各个进程间访问共享内存时的正确性，也可以在进程获取锁时采用不同的获取锁策略，并通过全局变量的值来区分进程在死锁状态下的处理方式，可以有效的解决的由进程异常导致的死锁问题，并且在处理死锁的过程中也可以依据不同***状态来采用不同的处理方式，使得***更加灵活、可靠和稳定。所以，本发明有效克服了现有技术中的种种缺点而具高度产业利用价值。
上述实施例仅例示性说明本发明的原理及其功效，而非用于限制本发明。任何熟悉此技术的人士皆可在不违背本发明的精神及范畴下，对上述实施例进行修饰或改变。因此，举凡所属技术领域中具有通常知识者在未脱离本发明所揭示的精神与技术思想下所完成的一切等效修饰或改变，仍应由本发明的权利要求所涵盖。
Claims (10)
1.一种共享内存锁管理控制方法，应用于多个进程访问共享内存的过程中，其特征在于：所述共享内存锁管理控制方法包括：
根据各进程调用的接口函数确定区分各进程共享内存锁的获取方式；
设定一个全局变量，根据进程的类型和***状态预设所述全局变量的值，通过所述全局变量的值来区分进程在死锁状态下的处理方式。
2.根据权利要求1所述的共享内存锁管理控制方法，其特征在于：所述接口函数至少包括：
提供进程在获取共享内存锁时进行超时计时且超时为第一预设时间时的第一函数接口；
提供进程在获取共享内存锁时进行超时计时且超时为第二预设时间时的第二函数接口；
提供进程在获取共享内存锁时进行超时计时且超时为第三预设时间时的第三函数接口；
提供进程在获取共享内存锁时不进行超时计时的第四函数接口。
3.根据权利要求2所述的共享内存锁管理控制方法，其特征在于：所述第一预设时间的时间取值范围为1s～3s；所述第二预设时间的时间取值范围为4s～6s；所述第三预设时间的时间取值范围为7s～11s。
4.根据权利要求1所述的共享内存锁管理控制方法，其特征在于：所述全局变量的值为第一预设值时，进程在死锁状态下的处理方式为：判定进程死锁，将该进程强行停止。
5.根据权利要求1所述的共享内存锁管理控制方法，其特征在于：所述全局变量的值为第二预设值时，进程在死锁状态下的处理方式为：判定进程死锁，保留该进程。
6.一种共享内存锁管理控制***，应用于多个进程访问共享内存的过程中，其特征在于：所述共享内存锁管理控制***包括：
内存锁的获取方式模块，用于根据各进程调用的接口函数确定区分各进程共享内存锁的获取方式；
死锁状态处理模块，与所述内存锁的获取方式模块相连，用于设定一个全局变量，根据进程的类型和***状态预设所述全局变量的值，通过所述全局变量的值来区分进程在死锁状态下的处理方式。
7.根据权利要求6所述的共享内存锁管理控制***，其特征在于：所述接口函数至少包括：
提供进程在获取共享内存锁时进行超时计时且超时为第一预设时间时的第一函数接口；
提供进程在获取共享内存锁时进行超时计时且超时为第二预设时间时的第二函数接口；
提供进程在获取共享内存锁时进行超时计时且超时为第三预设时间时的第三函数接口；
提供进程在获取共享内存锁时不进行超时计时的第四函数接口。
8.根据权利要求7所述的共享内存锁管理控制***，其特征在于：所述第一预设时间的时间取值范围为1s～3s；所述第二预设时间的时间取值范围为4s～6s；所述第三预设时间的时间取值范围为7s～11s。
9.根据权利要求6所述的共享内存锁管理控制***，其特征在于：所述全局变量的值为第一预设值时，进程在死锁状态下的处理方式为：判定进程死锁，将该进程强行停止。
10.根据权利要求6所述的共享内存锁管理控制***，其特征在于：所述全局变量的值为第二预设值时，进程在死锁状态下的处理方式为：判定进程死锁，保留该进程。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201510266134.2A CN104820622B (zh) | 2015-05-22 | 2015-05-22 | 一种共享内存锁管理控制方法及*** |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201510266134.2A CN104820622B (zh) | 2015-05-22 | 2015-05-22 | 一种共享内存锁管理控制方法及*** |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN104820622A true CN104820622A (zh) | 2015-08-05 |
| CN104820622B CN104820622B (zh) | 2019-07-12 |
Family
ID=53730924
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201510266134.2A Active CN104820622B (zh) | 2015-05-22 | 2015-05-22 | 一种共享内存锁管理控制方法及*** |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN104820622B (zh) |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105740079A (zh) * | 2016-01-27 | 2016-07-06 | 浪潮(北京)电子信息产业有限公司 | 一种死锁处理方法与*** |
| CN107783844A (zh) * | 2017-10-13 | 2018-03-09 | 锐捷网络股份有限公司 | 一种计算机程序运行异常检测方法、装置和介质 |
| CN109408477A (zh) * | 2018-10-09 | 2019-03-01 | 郑州云海信息技术有限公司 | 一种设置集群文件锁的方法、***及相关组件 |
| CN110597640A (zh) * | 2019-08-29 | 2019-12-20 | 深圳市优必选科技股份有限公司 | 进程间的数据传输方法、装置、终端及计算机存储介质 |
| CN112256443A (zh) * | 2020-10-14 | 2021-01-22 | 杭州当虹科技股份有限公司 | 一种基于redis的动态集群锁*** |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101800763A (zh) * | 2009-02-05 | 2010-08-11 | 威睿公司 | 使用网络和基于碟片上的方案的混合锁定 |
| CN102831007A (zh) * | 2011-06-14 | 2012-12-19 | 中兴通讯股份有限公司 | 实时处理***中的共享资源访问方法和实时处理*** |
| CN103731328A (zh) * | 2014-01-02 | 2014-04-16 | 烽火通信科技股份有限公司 | 基于Linux共享内存实现家庭网关数据通信的***及方法 |
-
2015
- 2015-05-22 CN CN201510266134.2A patent/CN104820622B/zh active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101800763A (zh) * | 2009-02-05 | 2010-08-11 | 威睿公司 | 使用网络和基于碟片上的方案的混合锁定 |
| CN102831007A (zh) * | 2011-06-14 | 2012-12-19 | 中兴通讯股份有限公司 | 实时处理***中的共享资源访问方法和实时处理*** |
| CN103731328A (zh) * | 2014-01-02 | 2014-04-16 | 烽火通信科技股份有限公司 | 基于Linux共享内存实现家庭网关数据通信的***及方法 |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105740079A (zh) * | 2016-01-27 | 2016-07-06 | 浪潮(北京)电子信息产业有限公司 | 一种死锁处理方法与*** |
| CN107783844A (zh) * | 2017-10-13 | 2018-03-09 | 锐捷网络股份有限公司 | 一种计算机程序运行异常检测方法、装置和介质 |
| CN109408477A (zh) * | 2018-10-09 | 2019-03-01 | 郑州云海信息技术有限公司 | 一种设置集群文件锁的方法、***及相关组件 |
| CN110597640A (zh) * | 2019-08-29 | 2019-12-20 | 深圳市优必选科技股份有限公司 | 进程间的数据传输方法、装置、终端及计算机存储介质 |
| CN112256443A (zh) * | 2020-10-14 | 2021-01-22 | 杭州当虹科技股份有限公司 | 一种基于redis的动态集群锁*** |
| CN112256443B (zh) * | 2020-10-14 | 2024-02-06 | 杭州当虹科技股份有限公司 | 一种基于redis的动态集群锁*** |
Also Published As
| Publication number | Publication date |
|---|---|
| CN104820622B (zh) | 2019-07-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN104820622A (zh) | 一种共享内存锁管理控制方法及*** | |
| CN101477476B (zh) | 多操作***之间切换显示的控制方法和装置 | |
| CN102436559B (zh) | 一种状态切换方法及*** | |
| CN106055077A (zh) | 一种基于唤醒锁的处理方法及装置 | |
| US10303883B2 (en) | Firmware verification through data ports | |
| CN107403152B (zh) | 高通平台TrustZone指纹识别实现方法及*** | |
| CN107817981B (zh) | 一种嵌入式控制器的控制方法及电子设备 | |
| CN104391754A (zh) | 一种任务异常的处理方法及装置 | |
| CN103902383A (zh) | 一种基于继承机制的资源管理器设计方法 | |
| CN107526955B (zh) | 熄屏解锁方法和装置 | |
| WO2019028572A1 (zh) | 一种plc可信自动配置方法、装置及计算机可读存储介质 | |
| CN110554681B (zh) | 交通工具通信网络和方法 | |
| CN109279459B (zh) | 一种电梯物联网控制方法及*** | |
| CN107179911B (zh) | 一种重启管理引擎的方法和设备 | |
| EP4042306B1 (en) | Secure installation of baseboard management controller firmware via a physical interface | |
| CN115413337A (zh) | 电子装置、***级芯片和物理核分配方法 | |
| CN106933641A (zh) | 一种单片机软件自升级方法和*** | |
| CN103942503B (zh) | 一种安全状态切换***及切换方法 | |
| CN109179117B (zh) | 门锁短接的检测方法、装置、计算机设备及存储介质 | |
| CN102541673A (zh) | 一种cpu取指令异常的安全处理方法和电路 | |
| CN105893838A (zh) | 一种针对安卓操作***关键驱动程序的加固方法 | |
| CN108388481A (zh) | Olt设备基于cpld控制的智能看门狗电路*** | |
| CN103747335A (zh) | 一种智能电视模式的切换方法及装置 | |
| CN106101784A (zh) | 一种智能电视控制蓝牙芯片的复位方法及装置 | |
| CN108897629A (zh) | 一种ejb调用参数传递方法及相关装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| TR01 | Transfer of patent right | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20201113 Address after: Room 10242, No. 260, Jiangshu Road, Xixing street, Binjiang District, Hangzhou City, Zhejiang Province Patentee after: Hangzhou Jiji Intellectual Property Operation Co., Ltd Address before: 201616 Shanghai city Songjiang District Sixian Road No. 3666 Patentee before: Phicomm (Shanghai) Co.,Ltd. |
|
| TR01 | Transfer of patent right | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20210701 Address after: 100089 room s6306, 3rd floor, building 1, yard 33, Dijin Road, Haidian District, Beijing Patentee after: BEIJING ZHONGKE HAIXUN DIGITAL TECHNOLOGY Co.,Ltd. Address before: Room 10242, No. 260, Jiangshu Road, Xixing street, Binjiang District, Hangzhou City, Zhejiang Province Patentee before: Hangzhou Jiji Intellectual Property Operation Co., Ltd |