CN101470627B - Method for implementing parallel multi-core configuration lock on MIPS platform - Google Patents
Method for implementing parallel multi-core configuration lock on MIPS platform Download PDFInfo
- Publication number
- CN101470627B CN101470627B CN200710304764XA CN200710304764A CN101470627B CN 101470627 B CN101470627 B CN 101470627B CN 200710304764X A CN200710304764X A CN 200710304764XA CN 200710304764 A CN200710304764 A CN 200710304764A CN 101470627 B CN101470627 B CN 101470627B
- Authority
- CN
- China
- Prior art keywords
- lock
- locks
- cpu
- application layer
- layer system
- 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
- Storage Device Security (AREA)
Abstract
The invention discloses an implementation method of an MIPS platform down parallel multinuclear allocation lock, which is used to solve the problem of lock reentrant in the prior art. The method comprises that: predefining a plurality of locks according to a basic lock which is provided by a system, and the locks comprise an application layer system calling adding lock, an application layer system calling releasing lock, an application layer system calling repeated adding lock, a timer lock, a timer unlock and a timer repeated adding lock. Redefining two locks which are an event response update lock and an event response recover lock according to the predefined locks. During the event response treatment process, when generating the problem that the lock is reentered, the event response update lock is called to add a lock or update to a new lock in an event response function, after the event response function finishes to be treated, the event response recover lock is called to release the lock or recover to a previous adding lock. Through the method, an operating system on a multinuclear architecture has excellent stability, robustness, expansibility, safety and parallelism.
Description
Technical field
The present invention relates to MIPS (Microprocessor without interlocked piped stages does not have inner interlocking pipelining-stage microprocessor) multi-core technology field, relate in particular to the implementation method of parallel multi-core configuration lock under a kind of MIPS platform.
Background technology
MIPS polycaryon processor based on the MIPS instruction set has occupied dominant position in embedded system.In set-top box, information terminal, network access device, occupy most of market at present, and entered into the Network Security Device field.On the framework of multi-core parallel concurrent, are gordian techniquies in the whole architecture for the concurrent access problem of some shared resources.
Linux system provides the most basic lock, comprising: read lock (read_lock): can go up a plurality of read locks simultaneously for same resource, thus can these codes of executed in parallel; Write lock (write_lock): can only go up one at one time for same resource and write lock, and the resource that can not concurrent access will protect; Spin lock (spin_lock):, just always wait, till the success of locking if it is unsuccessful to lock.
In the event response processing procedure, lock reentry phenomenon appears sometimes, and so-called lock reentry phenomenon is meant that a notifier handles in the function and triggered a notifier incident again; In existing lock technology, also do not solve the scheme of lock reentry problem.
Summary of the invention
The invention provides the implementation method of parallel multi-core configuration lock under a kind of MIPS platform, in order to solve the lock reentry problem that exists in the prior art.
The inventive method comprises:
Steps A: according to the basic lock that system provides, a plurality of locks of predefine comprise: the application layer system call locks, application layer system call release, application layer system call heavily lock, timer locks, the timer release, regularly think highly of and lock;
Step B: according to described predefined a plurality of locks, define two locks again: event response upgrades lock and event response recovers lock;
Step C: in the event response processing procedure, when lock reentry problem takes place, in the event response function, call event response and upgrade lock and lock or be updated to new lock; Described step C specifically comprises: the type of the lock that renewal CPU holds; Whether the type of judging CPU lock of holding and the lock that will upgrade is consistent, if consistent, directly return, otherwise judges whether CPU locks; If this CPU did not lock originally, timer locks or the application layer system call locks by calling, and directly adds configuration lock and chained list lock; If CPU has gone up lock, so just lock or the application layer system call heavily locks by calling regularly to think highly of, preserve the temporary variable of holding originally that is locked into, and then add the lock that will upgrade;
Step D: after the processing of event response function finishes, call event response and recover to lock release or return to the lock that adds in the past; Described step D specifically comprises: the type of the lock that recovery CPU holds; Whether the type of judging CPU lock of holding and the lock that will upgrade is consistent, if consistent, directly return, otherwise judges whether CPU locks; If CPU did not lock originally,, directly separate configuration lock and chained list lock so just by calling timer release or application layer system call release; If CPU has gone up lock, so just lock or the application layer system call heavily locks by calling regularly to think highly of, separate the lock that CPU will upgrade, and add the lock of holding originally.
Further, in the described steps A, be provided with two atomic counters during described application layer system call locks, then the process that locks of the described application layer system call of predefine specifically comprises:
Judge whether CPU has gone up lock, just withdraw from unusually if gone up lock, otherwise two atomic counters are added 1;
Attempt to add configuration lock, when confirming to add the configuration lock success, attempt to add the chained list lock;
When confirming that adding chained list locks successfully, the lock that lock that the preservation process is held and preservation CPU add also returns, otherwise separates configuration lock, and the retrial figure that lays equal stress on adds configuration lock.
Further, in the described steps A, described application layer system call release is provided with two atomic counters, and then the described application layer system call of predefine unlocking process specifically comprises:
Judge whether CPU locks, just withdraw from unusually if gone up lock, otherwise separate the chained list lock, atomic counters app_wrconfig_locks subtracts 1;
Separate configuration lock, and the lock that adds of the lock held of removing process and CPU;
Atomic counters app_locks subtracts 1.
Further, in the described steps A, the predefined process that described application layer system call heavily locks specifically comprises:
Judge whether CPU has gone up lock, just do not withdraw from unusually, otherwise successively the lock that has added is untied earlier, and then lock successively by new demand if do not lock.
Further, in the described steps A, the process that the described timer of predefine locks specifically comprises:
Atomic counters app_wrconfig_locks adds 1, guarantees that the lock of other low priorities can not obtain request;
Add configuration lock and chained list lock successively;
Atomic counters app_wrconfig_locks subtracts 1, preserves the lock that this CPU adds.
Further, in the described steps A, the described timer unlocking process of predefine specifically comprises:
At first separate the chained list lock, separate configuration lock then, remove the lock that CPU preserves at last.
Further, in the described steps A, the described timing of predefine is thought highly of the process that locks and is specifically comprised:
Judge whether CPU has gone up lock, if do not lock, just withdraw from unusually, otherwise untie the lock of going up successively earlier, and then add the lock of request successively, and preserve new lock.
In sum, the invention provides the implementation method of parallel multi-core configuration lock under a kind of MIPS platform, when lock reentry problem takes place when, at first calling notifier_upgrade_biglock_fun in the event response function locks and locks or be updated to new lock, after the processing of event response function finishes, call notifier_restore_biglock_fun and lock release or return to the lock that adds in the past.By the method for the invention, make the structural operating system of multi-core system can have good stable, robustness, extendability, security and concurrency.
Description of drawings
Fig. 1 is in the embodiment of the invention, the principle schematic of lock reentry problem;
Fig. 2 is in the embodiment of the invention, the schematic flow sheet that the system call of definition application layer locks;
Fig. 3 is in the embodiment of the invention, the schematic flow sheet of definition application layer system call release;
Fig. 4 is in the embodiment of the invention, the schematic flow sheet that the system call of definition application layer heavily locks;
Fig. 5 is in the embodiment of the invention, the schematic flow sheet that the definition timer locks;
Fig. 6 is in the embodiment of the invention, the schematic flow sheet of definition timer release;
Fig. 7 is in the embodiment of the invention, and the schematic flow sheet that locks is regularly thought highly of in definition;
Fig. 8 is in the embodiment of the invention, the schematic flow sheet of event response locking method;
Fig. 9 is in the embodiment of the invention, the schematic flow sheet of event response unlock method.
Figure 10 is in the embodiment of the invention, the schematic flow sheet of fast path locking method.
Figure 11 is in the embodiment of the invention, the schematic flow sheet of fast path unlock method.
Embodiment
Specifically describe preferential embodiment of the present invention below in conjunction with accompanying drawing, wherein, accompanying drawing constitutes the application's part, and is used from explaination principle of the present invention with embodiments of the invention one.
Core concept of the present invention is: when lock reentry problem occurring, in the process of locking, the lock that added in the past is updated to the lock of new request; In releasing process, separate the lock that newly adds earlier, again the lock that added is in the past recovered to add.In addition, the present invention has added atomic counters in self-defining lock, and realizes the priority of self-defining lock by atomic counters.
Below in conjunction with accompanying drawing the described method of the embodiment of the invention is described in detail.
Generally, on multi-core CPU, move different system/codes respectively, comprise TOS and fast_path two parts.They will visit firewall configuration and inner chained list resource by different interfaces.Wherein TOS will revise configuration and write lock more than the chained list resource institute, so and fast_path does not need the modification configuration only to go up the configuration read lock.Here TOS goes up latching segment complexity the most, comprises system_call (system call), schedule (process scheduling), timer (timer), hook (the HOOK point of processing data packets), notifier (event response).System_call (system call): the user revises configuration by user interface, at this moment needs to add to write lock; Schedule (process scheduling): system_call adds writes lock, and at this moment the process queue that may be scheduled out in the process of implementation needs first release, needs when scheduling is come in lock again again; Timer (timer): the timer among the TOS can be revised configuration and chained list, at this moment needs to add the read/write lock of configuration and chained list; Hook (the HOOK point of processing data packets): need read configuration and revise chained list the processing of each packet in the TOS system, at this moment need to add the configuration read lock, chained list is write lock; Notifier (event response): event response need be revised configuration and revise chained list, at this moment needs to add configurable write lock and chained list and writes lock.
Wherein, in the event response processing procedure, lock reentry phenomenon appears sometimes, so-called lock reentry phenomenon is meant that a notifier handles in the function and triggered a notifier incident again, and concrete principle as shown in Figure 1, that is, function has at first added lock when the configuration that visit needs protection; Deal with the work then, at this moment it might call this function itself again, at this moment just lock reentry problem occurred, and lock reentry problem is actually and is caused by recursive call.What we ran into here is the secondary recursive call, so here, we only handle the lock reentry problem that the secondary recursive call causes.
In order to solve lock reentry problem, the basic read lock that provides in system, write lock, on the basis of spin lock, a plurality of locks have been defined, comprise: app_enter_critical lock (the application layer system call locks), app_leave_critical release (application layer system call release), app_reenter_caitical lock (the application layer system call heavily locks), timer_enter_critical lock (timer) lock, timer_leave_critical release (timer release), timer_reenter_critical locks (regularly think highly of and lock), is illustrated respectively below.
As shown in Figure 2, Fig. 2 has defined an app_enter_critical and has locked, in this lock the inside 2 atomic counters app_locks and app_wrconfig_locks are arranged, these 2 atomic counters are to be used for the priority that realizes locking, wherein, app_locks is the priority between control application layer system call and the HOOK lock, and app_wrconfig_lock is the priority between control application layer system call and the fast path.
Detailed process comprises: judge at first whether this CPU has gone up lock, if having gone up lock just withdraws from unusually, otherwise 2 atomic counters are added 1, attempt to add configuration lock (promptly disposing the read/write lock), success just attempts to add chained list lock (being chained list read/write lock) if lock, the lock that success is held with regard to the preservation process if lock and preserve the lock that CPU adds, and return.This lock is a highest lock of priority.
As shown in Figure 3, Fig. 3 has defined an app_leave_critical release, in this lock the inside 2 atomic counters app_locks and app_wrconfig_locks is arranged also.Application layer system call release and application layer system call lock and use in pairs, its detailed process is opposite with process shown in Figure 2, comprise: judge at first whether this CPU locks, if having gone up lock just withdraws from unusually, otherwise separate chained list read/write lock, atomic counters app_wrconfig_locks subtracts 1; Separate configuration read/write lock then, and the lock that adds of the lock held of removing process and CPU, last atomic counters app_locks subtracts 1.
As shown in Figure 4, Fig. 4 has defined the app_reenter_caitical that an application layer system call locks again and has locked after obtaining to lock.This lock is with solving lock reentry problem.If judge that this CPU has added lock in a request of locking, we just call this lock so.This lock judges at first whether this CPU has gone up lock, does not just withdraw from unusually if do not lock.If this CPU has gone up lock, just successively the lock that has added is untied earlier, and then locked successively by new demand.
As shown in Figure 5, Fig. 5 has defined a timer_enter_critica and has locked.If a timer wants access configuration and chained list resource just need add this lock, its priority is medium.Concrete definition procedure can for: at first atomic counters app_wrconfig_locks is added 1, guarantees that the lock of other low priorities can not obtain request.Add configuration read/write lock then, add chained list read/write lock, app_wrconfig_locks subtracts 1 atomic counters, preserves the lock that this CPU adds.
As shown in Figure 6, Fig. 6 has defined a timer_leave_critica release.Concrete definition procedure can for: at first separate chained list read/write lock, separate configuration read/write lock then, remove the lock that CPU preserves at last.
As shown in Figure 7, Fig. 7 has defined the timer_reenter_critical that locks again after a timer has obtained to lock and has locked.It judges at first whether this CPU has gone up lock.If do not lock, just withdraw from unusually.Otherwise untie the lock of going up successively earlier,, and preserve new lock then at the lock that adds request successively.
Based on previously defined 6 locks, define two big locks again, a notifier_upgrade_biglock_fun lock (event response upgrades lock) and a notifier_restore_biglock_fun lock (event response recovers lock).
In the event response processing procedure, when lock reentry problem takes place when, at first calling notifer_upgrade_biglock_fun in the event response function locks and locks or be updated to new lock, after the processing of event response function finishes, call notifier_restore_biglock_fun and lock release or return to the lock that adds in the past.
Wherein, the concrete processing procedure that event response locks can may further comprise the steps as shown in Figure 8:
In event response locks processing procedure, owing to may occur locking the reentry problem, so when locking, at first to note the lock that each CPU holds, and upgrade the lock that this CPU holds.That is to say, in event response locks process, call event response and upgrade lock, at first need to upgrade the type of the lock that this CPU holds,, so just directly return if the lock that original CPU holds is consistent with the type of the lock that will upgrade now; Otherwise, judge whether CPU locks, if this CPU did not lock originally, so just timer_enter_critical locks or app_enter_critical locks by calling, and directly adds configuration and chained list lock; If this CPU has gone up lock, so just timer_reenter_critical heavily locks or app_reenter_critical heavily locks by calling, and preserves the temporary variable of holding originally that is locked into, and then adds the lock that will upgrade.
The concrete processing procedure of event response release can may further comprise the steps as shown in Figure 9:
In event response release processing procedure since before the reentry problem may appear locking, so when release will according to before the lock held of CPU of record make a decision.That is to say, in the event response releasing process, call event response and recover lock, need at first to judge whether the lock that CPU holds is consistent with the lock that will upgrade, if the lock that CPU held is consistent with the type of the lock that will upgrade, so just directly returns, otherwise judge whether CPU locks, if CPU did not lock originally,, directly separate configuration lock and chained list lock so just by calling time_leave_critical release or app_leave_critical release; Otherwise just timer_reente_critical heavily locks or app_reenter_critical heavily locks by calling, and separates the lock that this CPU will upgrade, and adds the lock of holding originally.
Implementation procedure to the priority of the configuration lock that relates in the embodiment of the invention describes below.
Figure 10 is the schematic flow sheet of the locking method after the fast path access configuration, because will wait until atomic counters app_wrconfig_locks before adding configuration lock 0 just can go to lock, if atomic counters app_wrconfig_locks is not 0, show that the CPU that other are arranged has added configuration lock, we just wait always like this.Just realized the priority of configuration lock by this method.
Be exactly specifically, when the application layer system call locks in Fig. 2, the app_wrconfig_locks atomic counters is added 1, if at this moment other fast path CPU will lock, so he whether at first survey the app_wrconfig_locks atomic counters be 0 (being 1 now), whether fast path in Figure 10 so to survey this counter be 0 always if just circulating with a while when locking.After that application layer system call release (Fig. 3), just app_wrconfig_locks is subtracted 1, just equal 0.This moment the fast path CPU among Figure 10 just to detect app_wrconfig_locks be 0, just continue locking of back.So just realized the priority of lock.
Figure 11 is the schematic flow sheet of the unlock method after the fast path access configuration, and is corresponding with the locking method of Figure 10, and release does not relate to the problem of priority.
The above is the preferred embodiments of the present invention, and here, the method for the invention can only be protected a kind of resource, perhaps the resource that will protect is subdivided into a plurality of resources, protects these resources with a plurality of locks then.In addition, the system that operates on the multi-core CPU may be different: the system/code segment that has more than 2 operates on the multi-core CPU, but they can some resources that will protect of concurrent access.
In sum, in the embodiment of the invention, when lock reentry problem takes place, lock and release by predefined notifier_upgrade_biglock_fun lock and notifier_restore_biglock_fun lock, in the process of locking, the lock that added in the past is updated to the lock of new request; In releasing process, separate the lock that newly adds earlier, again the lock that added is in the past recovered to add.In addition, the present invention has added atomic counters in self-defining lock, and realizes the priority of self-defining lock by atomic counters.By the described method of the embodiment of the invention, can make multisystem safety, stable operating on the multi-core platform, can make multisystem safety, fast, parallel access shared resources, can also make user's request guarantee in time to be responded by the high priority lock.
Obviously, those skilled in the art can carry out various changes and modification to the present invention and not break away from the spirit and scope of the present invention.Like this, if of the present invention these are revised and modification belongs within the scope of claim of the present invention and equivalent technologies thereof, then the present invention also is intended to comprise these changes and modification interior.
Claims (7)
1. the implementation method of parallel multi-core configuration lock under the MIPS platform is characterized in that, comprising:
Steps A: according to the basic lock that system provides, a plurality of locks of predefine comprise: the application layer system call locks, application layer system call release, application layer system call heavily lock, timer locks, the timer release, regularly think highly of and lock;
Step B: according to described predefined a plurality of locks, define two locks again: event response upgrades lock and event response recovers lock;
Step C: in the event response processing procedure, when lock reentry problem takes place, in the event response function, call event response and upgrade lock and lock or be updated to new lock; Described step C specifically comprises: the type of the lock that renewal CPU holds; Whether the type of judging CPU lock of holding and the lock that will upgrade is consistent, if consistent, directly return, otherwise judges whether CPU locks; If this CPU did not lock originally, timer locks or the application layer system call locks by calling, and directly adds configuration lock and chained list lock; If CPU has gone up lock, so just lock or the application layer system call heavily locks by calling regularly to think highly of, preserve the temporary variable of holding originally that is locked into, and then add the lock that will upgrade;
Step D: after the processing of event response function finishes, call event response and recover to lock release or return to the lock that adds in the past; Described step D specifically comprises: the type of the lock that recovery CPU holds; Whether the type of judging CPU lock of holding and the lock that will upgrade is consistent, if consistent, directly return, otherwise judges whether CPU locks; If CPU did not lock originally,, directly separate configuration lock and chained list lock so just by calling timer release or application layer system call release; If CPU has gone up lock, so just lock or the application layer system call heavily locks by calling regularly to think highly of, separate the lock that CPU will upgrade, and add the lock of holding originally.
2. method according to claim 1 is characterized in that, in the described steps A, is provided with two atomic counters during described application layer system call locks, and then the process that locks of the described application layer system call of predefine specifically comprises:
Judge whether CPU has gone up lock, just withdraw from unusually if gone up lock, otherwise two atomic counters are added 1;
Attempt to add configuration lock, when confirming to add the configuration lock success, attempt to add the chained list lock;
When confirming that adding chained list locks successfully, the lock that lock that the preservation process is held and preservation CPU add also returns, otherwise separates configuration lock, and the retrial figure that lays equal stress on adds configuration lock.
3. method according to claim 1 is characterized in that, in the described steps A, described application layer system call release is provided with two atomic counters, and then the described application layer system call of predefine unlocking process specifically comprises:
Judge whether CPU locks, just withdraw from unusually if gone up lock, otherwise separate the chained list lock, atomic counters app_wrconfig_locks subtracts 1;
Separate configuration lock, and the lock that adds of the lock held of removing process and CPU;
Atomic counters app_locks subtracts 1.
4. method according to claim 1 is characterized in that, in the described steps A, the predefined process that described application layer system call heavily locks specifically comprises:
Judge whether CPU has gone up lock, just do not withdraw from unusually, otherwise successively the lock that has added is untied earlier, and then lock successively by new demand if do not lock.
5. method according to claim 1 is characterized in that, in the described steps A, the process that the described timer of predefine locks specifically comprises:
Atomic counters app_wrconfig_locks adds 1, guarantees that the lock of other low priorities can not obtain request;
Add configuration lock and chained list lock successively;
Atomic counters app_wrconfig_locks subtracts 1, preserves the lock that this CPU adds.
6. method according to claim 1 is characterized in that, in the described steps A, the described timer unlocking process of predefine specifically comprises:
At first separate the chained list lock, separate configuration lock then, remove the lock that CPU preserves at last.
7. method according to claim 1 is characterized in that, in the described steps A, the described timing of predefine is thought highly of the process that locks and specifically comprised:
Judge whether CPU has gone up lock, if do not lock, just withdraw from unusually, otherwise untie the lock of going up successively earlier, and then add the lock of request successively, and preserve new lock.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200710304764XA CN101470627B (en) | 2007-12-29 | 2007-12-29 | Method for implementing parallel multi-core configuration lock on MIPS platform |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200710304764XA CN101470627B (en) | 2007-12-29 | 2007-12-29 | Method for implementing parallel multi-core configuration lock on MIPS platform |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN101470627A CN101470627A (en) | 2009-07-01 |
| CN101470627B true CN101470627B (en) | 2011-06-08 |
Family
ID=40828117
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN200710304764XA Active CN101470627B (en) | 2007-12-29 | 2007-12-29 | Method for implementing parallel multi-core configuration lock on MIPS platform |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN101470627B (en) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101719080B (en) * | 2009-12-25 | 2014-03-26 | 北京网御星云信息技术有限公司 | Multi-core timer implementing method and system |
| CN102355423B (en) * | 2011-10-19 | 2013-11-27 | 迈普通信技术股份有限公司 | Forwarded resource access method and routing system |
| US20150277914A1 (en) * | 2014-03-27 | 2015-10-01 | John H. Kelm | Lock elision with binary translation based processors |
| CN105550032A (en) * | 2015-10-27 | 2016-05-04 | 深圳市美贝壳科技有限公司 | CPU (Central Processing Unit) optimization method and system based on Android |
| CN106790694B (en) * | 2017-02-21 | 2020-04-14 | 广州爱九游信息技术有限公司 | Distributed system and scheduling method of target object in distributed system |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1740978A (en) * | 2004-08-23 | 2006-03-01 | 华为技术有限公司 | Method for realing sharing internal stored data base and internal stored data base system |
| CN1920780A (en) * | 2006-08-15 | 2007-02-28 | 杭州华为三康技术有限公司 | Method and system for accessing critical region |
| US20070067257A1 (en) * | 2005-09-22 | 2007-03-22 | Microsoft Corporation | Synchronizing shared resources in a collection |
-
2007
- 2007-12-29 CN CN200710304764XA patent/CN101470627B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1740978A (en) * | 2004-08-23 | 2006-03-01 | 华为技术有限公司 | Method for realing sharing internal stored data base and internal stored data base system |
| US20070067257A1 (en) * | 2005-09-22 | 2007-03-22 | Microsoft Corporation | Synchronizing shared resources in a collection |
| CN1920780A (en) * | 2006-08-15 | 2007-02-28 | 杭州华为三康技术有限公司 | Method and system for accessing critical region |
Also Published As
| Publication number | Publication date |
|---|---|
| CN101470627A (en) | 2009-07-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8239871B2 (en) | Managing timeout in a multithreaded system by instantiating a timer object having scheduled expiration time and set of timeout handling information | |
| CN101470627B (en) | Method for implementing parallel multi-core configuration lock on MIPS platform | |
| US8161481B2 (en) | Operating system providing a mutual exclusion mechanism | |
| CN105893120B (en) | A kind of acquisition methods and device of thread synchronization resource | |
| US9778962B2 (en) | Method for minimizing lock contention among threads when tasks are distributed in multithreaded system and apparatus using the same | |
| WO2018223677A1 (en) | Image resource-based automatic memory release method and system | |
| US9471399B2 (en) | Orderable locks for disclaimable locks | |
| CN101236515B (en) | Multi-core system single-core abnormity restoration method | |
| CN106598725A (en) | Android-based Handler memory leakage prevention device and method | |
| CN101477386B (en) | Timer implementing method and apparatus | |
| CN111414256A (en) | Application program process derivation method, system and medium based on kylin mobile operating system | |
| US11675622B2 (en) | Leader election with lifetime term | |
| US7418703B2 (en) | Parallel processing system by OS for single processor | |
| KR20150122119A (en) | System and method for using a sequencer in a concurrent priority queue | |
| US20150058862A1 (en) | High performance locks | |
| JP2015506027A (en) | Buffer resource management method and communication device | |
| CN101082870A (en) | Method for restricting parallel execution of shell script | |
| US20180004574A1 (en) | Averting Lock Contention Associated with Core-Based Hardware Threading in a Split Core Environment | |
| CN107305507B (en) | Deadlock control method and device | |
| CN102521547B (en) | Protecting system for access control system in virtual domain | |
| JP2010504581A (en) | Robust critical section design in multithreaded applications | |
| US7689992B2 (en) | Sharing lock mechanism between protocol layers | |
| CN115964180A (en) | Task scheduling method and device and electronic equipment | |
| CN113961364B (en) | Large-scale lock system implementation method and device, storage medium and server | |
| Quinton et al. | Formal analysis of sporadic bursts in real-time systems |
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 |