CN110196777B - Method for avoiding non-real-time Binder competition in real-time android operating system through real-time Binder processing - Google Patents
Method for avoiding non-real-time Binder competition in real-time android operating system through real-time Binder processing Download PDFInfo
- Publication number
- CN110196777B CN110196777B CN201910356823.0A CN201910356823A CN110196777B CN 110196777 B CN110196777 B CN 110196777B CN 201910356823 A CN201910356823 A CN 201910356823A CN 110196777 B CN110196777 B CN 110196777B
- Authority
- CN
- China
- Prior art keywords
- binder
- real
- time
- request
- ipcthreadstate
- 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
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Multimedia (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
The invention discloses a method for avoiding non-real-time Binder competition in real-time Binder processing in a real-time android operating system, which is characterized by comprising the following steps of: s1: judging whether the property of the Binder request belongs to a real-time Binder request or a common Binder request, and if the property of the Binder request belongs to the real-time Binder request, executing the step S2; s2, the Binder driver requests a thread from the IPCThreadState class example, a SPAWN generates a hard real-time or soft real-time thread for processing the real-time Binder request, and S3, the Binder driver treats all real-time Binders fairly or inserts the real-time Binder request into a queue orderly.
Description
Technical Field
The invention relates to the technical field of communication data processing, in particular to a method for avoiding non-real-time Binder competition in real-time Binder processing in a real-time android operating system.
Background
With the continuous development of the SOC (System On Chip) technology, the embedded System is more and more widely applied in various aspects of people production and life, such as aerospace, smart phones, smart watches and the like, and is ubiquitous. Due to the particularity of the operation, many embedded devices require that the response of the system to external events must be completed within a time limit range set for implementation, so that the system has predictability, and therefore a real-time operating system must be used.
Common embedded real-time operating systems include VxWorks, QNX, uCOSII and the like in hard time, and WinCE and the like in soft time. Such as VxWorks, QNX and uCOSII are closed operating systems with relatively simple functions. As the current system becomes more complex, more and more general time-sharing operating systems with perfect ecological chain are required, such as: linux, windows and the like are transformed into real-time operating systems, so that the universal requirements and the special requirements can be met. Due to the open source characteristic of Linux, there are some good solutions in this aspect, such as: RTLinux, RTAI, montavista, etc.
The increasingly widely used google Android (Android) operating system is also a universal time-sharing operating system with a perfect ecological chain, and is based on a Linux kernel. The most important interprocess communication mechanism in the Android operating system is the Binder mechanism. The Binder mechanism can be said to be ubiquitous in the Android operating system. The common Binder mechanism is used to handle non-real-time logic and does not introduce the concept of priority. The Binder mechanism can be used in the real-time android operating system (RTAndroid) to handle real-time logic. However, there is a problem that must be solved when the Binder mechanism is used for processing real-time logic, because the Binder mechanism is said to be ubiquitous in an Android (Android) operating system, in the same process, when processing a non-real-time Binder request, because a todo linked list in a Binder driver is locked, the real-time Binder can be processed only after the non-real-time Binder request is processed, which is obviously inconsistent with the design principle of a real-time system. Specifically, the existing Binder communication mechanism is that after a user process initiates a Binder request, a Binder service class and an interface class are reached first, then a Binder core class is reached, then an IPCThreadState class is reached, and finally a Binder driver operating in a kernel space is reached. The results of the request are returned to the user process in the reverse route. The IPCThreadState class is responsible for communicating with the Binder driver and maintains the Binder thread pool. In android today's design, there is only one instance of the IPCThreadState class in each user process. In addition, the android system has a special Binder service ServiceManager, which provides name service for the Binder mechanism. The Binder driver maintains a data structure of Binder _ proc for each process, and a wait queue is also included on the Binder _ proc so that Binder threads can sleep on it. In addition, a FIFO queue is also maintained on binder _ proc to buffer the binder to drive all unprocessed work on a process. In addition, the binder driver also maintains locks to synchronize concurrent binder requests on the same process.
In real-time android operating system (RTandroid), the Binder mechanism is also used to handle the cross-process delivery requirements of real-time events or requests, since Binder mechanism is an efficient and programmatically flexible cross-process communication mechanism. From the above analysis, if the Binder mechanism of android native is not improved, the Binder processing of real-time events or requests is not treated differently, when the non-real-time Binder requests in the system are frequent and busy, the real-time events or requests will be delayed a lot, and the real-time performance will not be guaranteed.
Disclosure of Invention
The invention aims to provide a method for avoiding non-real-time Binder competition in real-time Binder processing in a real-time android operating system, which is realized based on the real-time android operating system, is suitable for modifying the android operating system into the real-time android operating system and is also suitable for any real-time operating system using a Binder mechanism to avoid the competition problem of non-real-time Binder requests during real-time Binder processing.
In order to achieve the purpose, the invention adopts the following technical scheme:
a method for avoiding non-real-time Binder competition in real-time android operating system by real-time Binder processing is characterized by comprising the following steps:
s1: judging whether the property of the Binder request belongs to a real-time Binder request or a common Binder request, and executing the step S2 if the property of the Binder request belongs to the real-time Binder request or the common Binder request;
s2, the Binder driver requests a thread from the IPCThreadState class example, and the SPAWN generates a hard real-time or soft real-time thread for processing a real-time Binder request;
and S3, the Binder driver treats all the real-time binders fairly or inserts the real-time Binder requests into a queue in order.
As a preferred technical scheme, the method comprises a mode separated from a common Binder mechanism and/or a mode embedded in a common Binder;
the mode separated from the common Binder mechanism means that two Binder drives and corresponding equipment files are arranged in the system, namely a native Binder drive and a real-time Binder drive; two IPCThreadState class instances exist in a user process, namely a common IPCThreadState class instance and a real-time IPCThreadState class instance, and the operation of the user process comprises the following steps:
s1a: the upper layer of Binder service class and interface class, and Binder core class can distinguish Binder request property, if real-time Binder request, find real-time IPCThreadState class example, if ordinary Binder request, find ordinary IPCThreadState class example;
s2a: the real-time Binder request sends the request to a real-time Binder driver through a real-time IPCThreadState class instance; the real-time Binder drive requests the real-time IPCThreadState class instance SPAWN to generate hard real-time or soft real-time threads for processing the real-time Binder requests;
s3a: the real-time Binder driver treats all real-time Binder requests fairly or inserts the real-time Binder requests into FIFO queues of one or more corresponding processes in order according to priority;
in the mode embedded in the ordinary Binder, only one Binder driver is stored in the system, each user process only has one IPCThreadState class instance, and the Binder library has an interface specific to the real-time Binder request or an interface additional parameter to distinguish the real-time Binder request from the ordinary Binder request, and the operation of the method comprises the following processes:
s1b, a special interface or interface parameters in a Binder library indicate that a Binder request is a real-time Binder request;
s2b, when the Binder driver requests the SPAWN thread from the IPCThreadState class instance, the thread to be created is indicated to be a hard real-time or soft real-time thread through a specific parameter or a specific command in a Binder protocol, and the IPCThreadState class instance creates a corresponding thread to process the real-time Binder request in the thread;
sb3: in the Binder _ proc structure corresponding to each user process, a waiting queue rt _ wait _ queue of the real-time Binder and an FIFO queue rt _ todo _ list of the real-time Binder are specially maintained for the real-time Binder request.
As a preferred technical scheme, when the system configures the two modes simultaneously, software calls a specific interface to select one of the two modes, and if the two modes are not called, the mode separated from the ordinary Binder is selected by default.
As a preferred technical solution, before running a mode separated from the ordinary Binder mechanism or a mode embedded in the ordinary Binder mechanism, the following process is further included:
reading the configuration or obtaining which mode the user selects by an interface called by the user, and if the mode separated from the ordinary Binder mechanism is selected, operating the mode separated from the ordinary Binder mechanism; and if the mode embedded in the common Binder mechanism is selected, the mode embedded in the common Binder mechanism operates.
As a preferred technical scheme, under the mode separated from the ordinary Binder, the competition among different real-time Binder requests has two processing modes, wherein the first mode is that all real-time Binder requests are treated fairly, and the second mode is that the real-time Binder requests are sorted according to the priority; two ways a user can select through a specific configuration or a specific interface; in the second mode, the priority is set as the thread priority of hard real time or soft real time by default, when a Binder request is initiated, the real-time Binder drive is reached, and the Binder request is inserted into the corresponding position of the FIFO queue according to the priority sequence without interrupting the currently processed Binder request.
As a preferred technical scheme, in the mode separated from the ordinary Binder, one or two servicemanagers exist in the system;
when two servicemanagers exist, one is a native ServiceManager, the other is a ServiceManager specially serving the real-time Binder, and the Binder library distinguishes which IPCThreadState class instance is, so that the corresponding ServiceManager can be accessed to obtain correct service;
when only one ServiceManager exists, the real-time Binder driver finds an instance of the IPCThreadState class of the ordinary Binder through a set special interface when the ServiceManager needs the service, and thus accesses the ordinary Binder driver to obtain the service.
As a preferred solution, the FIFO queue of the real-time Binder has a flag in its data structure to indicate whether it is from a real-time Binder request.
Compared with the prior art, the invention has the following beneficial effects:
by separating from any one of the mode of the common Binder and the mode embedded in the common Binder (for a single real-time Binder request), the possibility and the time delay of the competition of the common Binder request for the real-time Binder request are reduced to the minimum, and the performance of cross-process transmission of real-time events or requests through a Binder mechanism is ensured. In both modes, the real-time Binder request can be processed in hard real-time or soft real-time threads, and the efficiency is improved. Wherein the mode separated from the general Binder minimizes the possibility of competition.
Detailed Description
Examples
A method for avoiding non-real-time Binder competition in real-time android operating system real-time Binder processing comprises a mode separated from a common Binder and/or a mode embedded in the common Binder, wherein only one mode can be configured to work through software, the two modes can also exist simultaneously, the software calls a specific interface to select one of the two modes, and if the software does not call, the default selection is separated from the mode of the common Binder.
The mode separated from the ordinary Binder means that besides the Binder driver and the corresponding device file of android native, another Binder driver and the corresponding device file specially serving the real-time Binder request exist in the system. The Binder service class and the interface class in the corresponding device file-Binder library and the Binder core class basically keep the same with the native class, and the purpose of doing so is to keep the real-time Binder upper layer application compatible with the design of android native as much as possible.
In the mode separated from the ordinary Binder, two IPCThreadState class instances are in the same user process, namely an ordinary IPCThreadState class instance and a real-time IPCThreadState class instance. One instance communicates with a common Binder driver and the other instance communicates with a real-time Binder driver. The upper layer Binder service class and interface class, and the Binder core class can distinguish whether it is a normal Binder request or a real-time Binder request, so as to find out the corresponding IPCThreadState class. The two instances can be located in two different Binder libraries, or can be located in the same Binder library, and the specific interface is added to distinguish the instances of IPCThreadState class to be accessed.
The thread in the thread pool maintained by the instance of the normal IPCThreadState class is a normal android Binder thread, and the thread in the thread pool maintained by the instance of the real-time IPCThreadState class is a hard real-time thread or a soft real-time thread, so that the efficiency of processing a real-time Binder request can be improved. Since the real-time Binder requests are all served by the real-time Binder driver, and the real-time Binder driver does not serve the ordinary Binder requests, the real-time Binder requests are not contended by the ordinary Binder requests, and the contention exists only among different real-time Binder requests, so that the problem that the real-time Binder requests are delayed due to the contention of the ordinary Binder is solved. The competition among different real-time Binder requests has two processing modes, wherein the first mode is that all real-time Binder requests are treated fairly, and the second mode is that the real-time Binder requests are sorted according to the priority. Both ways the user can select through a particular configuration or a particular interface. For the second way, it should be noted that the priority is set as the thread priority of hard real-time or soft real-time by default, but the user can also modify the priority of the Binder request through a specific interface, when a certain Binder request is initiated, the real-time Binder driver is reached, and the Binder request is inserted into the corresponding position of the FIFO queue (to-do list) according to the priority order without interrupting the Binder request being processed, and the inserted Binder request is a set of Binder requests, possibly in the FIFO queues (to-do list) of multiple processes. The time of insertion is essentially performed according to the native Binder protocol.
In the mode separated from the ordinary Binder, since there are two Binder drivers, the ServiceManager is also a special Binder service and needs to communicate with the Binder driver. There are therefore two designs, the first having a ServiceManager that serves exclusively for real-time Binder, the Binder library only distinguishing which IPCThreadState class is an example. The corresponding ServiceManager can be accessed to obtain the correct service, and in this design, there are two servicemanagers in the system. The second is that only one ServiceManager exists in the system, and when the real-time Binder needs the service of the ServiceManager, the real-time Binder finds the instance of the IPCThreadState class of the ordinary Binder through a special interface, thereby accessing the ordinary Binder driver to obtain the service. Since the services of the ServiceManager are only called when the Binder interface is initialized, this design also has substantially no impact on the real-time performance.
In the mode embedded in the common Binder, only one Binder driver exists in the system, and each user process also has only one IPCThreadState class instance. The Binder library has an interface specific to the real-time Binder request or an interface-attached parameter to distinguish whether it is a real-time Binder request or a normal Binder request. When the Binder driver requests a SPAWN thread from an IPCThreadState class instance, indicating whether the thread to be created is a hard real-time or soft real-time thread, either by a specific argument or a specific command in the Binder protocol, the IPCThreadState class instance will create the corresponding thread to handle the real-time Binder request in such a thread. In the Binder drive, in a Binder _ proc structure corresponding to each user process, a waiting queue rt _ wait _ queue of the real-time Binder and a FIFO queue rt _ todo _ list of the real-time Binder are specially maintained for a real-time Binder request. In addition, the data structure of the FIFO queue of the real-time Binder also has a flag to indicate whether it is from a real-time Binder request. By this design, the possibility that the real-time Binder request is contended by the non-real-time Binder request is reduced. Although the schema embedded in the normal Binder is not completely separated from the schema of the normal Binder, it has the advantage that there is only one Binder driver in the system and only one instance of IPCThreadState class in one process.
In this embodiment, taking an example that a mode separated from a general Binder and a mode embedded in the general Binder are configured in a system at the same time, the following steps are performed for each Binder request:
step S1, reading configuration or obtaining which mode is selected by a user through an interface called by the user, executing step S2-1 if a mode separated from a common Binder is selected, and executing step S3-1 if a mode embedded in the common Binder is selected;
step S2-1: the upper layer of Binder service class and interface class, and Binder core class can distinguish Binder request property, if real-time Binder request, find real-time IPCThreadState class example, if ordinary Binder request, find ordinary IPCThreadState class example;
step S2-2: the real-time Binder request sends the request to a real-time Binder driver through a real-time IPCThreadState class instance; the IPCThreadState class instance SPAWN of the real-time Binder driving request real-time generates a hard real-time or soft real-time thread for processing the real-time Binder request;
step S2-3: the real-time Binder driver treats all real-time Binder requests in a fair way or inserts the real-time Binder requests into FIFO queues of one or more corresponding processes in order according to the priority;
s3-1, a special interface or interface parameters in a Binder library indicate that a Binder request is a real-time Binder request;
s3-2, when the Binder driver requests the SPAWN thread from the IPCThreadState class instance, the thread to be created is indicated to be a hard real-time or soft real-time thread through a specific parameter or a specific command in a Binder protocol, and the IPCThreadState class instance creates a corresponding thread to process the real-time Binder request in the thread;
s3-3: in the Binder _ proc structure corresponding to each user process, a waiting queue rt _ wait _ queue of the real-time Binder and a FIFO queue rt _ todo _ list of the real-time Binder are specially maintained for the real-time Binder request.
The invention is well implemented in accordance with the above-described embodiments. It should be noted that, based on the above structural design, in order to solve the same technical problems, even if some insubstantial modifications or colorings are made on the present invention, the adopted technical solution is still the same as the present invention, and therefore, the technical solution should be within the protection scope of the present invention.
Claims (6)
1. A method for avoiding non-real-time Binder competition in real-time android operating system by real-time Binder processing is characterized by comprising the following steps:
s1: judging whether the property of the Binder request belongs to a real-time Binder request or a common Binder request, and executing the step S2 if the property of the Binder request belongs to the real-time Binder request or the common Binder request;
s2, the Binder driver requests a thread from the IPCThreadState class example, and the SPAWN generates a hard real-time or soft real-time thread for processing a real-time Binder request;
s3, the Binder driver fairly treats all real-time Binders or inserts real-time Binder requests into a queue in order;
the mode separated from the ordinary Binder mechanism and/or the mode embedded in the ordinary Binder mechanism are/is also included;
the mode separated from the common Binder mechanism means that the system has two Binder drives and corresponding equipment files, namely a native Binder drive and a real-time Binder drive; two IPCThreadState class instances exist in a user process, namely a common IPCThreadState class instance and a real-time IPCThreadState class instance, and the operation of the user process comprises the following steps:
s1a: the upper layer of Binder service class and interface class, and Binder core class can distinguish Binder request property, if real-time Binder request, find real-time IPCThreadState class example, if ordinary Binder request, find ordinary IPCThreadState class example;
s2a: the real-time Binder request sends the request to a real-time Binder driver through a real-time IPCThreadState class instance; the IPCThreadState class instance SPAWN of the real-time Binder driving request real-time generates a hard real-time or soft real-time thread for processing the real-time Binder request;
s3a: the real-time Binder driver treats all real-time Binder requests fairly or inserts the real-time Binder requests into FIFO queues of one or more corresponding processes in order according to priority;
in the mode embedded in the ordinary Binder, only one Binder driver is stored in the system, each user process only has one IPCThreadState class instance, and the Binder library has an interface specific to the real-time Binder request or an interface additional parameter to distinguish the real-time Binder request from the ordinary Binder request, and the operation of the method comprises the following processes:
s1b, a special interface or interface parameters in a Binder library indicate that a Binder request is a real-time Binder request;
s2b, when the Binder driver requests the SPAWN thread from the IPCThreadState class instance, the thread to be created is indicated to be a hard real-time or soft real-time thread through a specific parameter or a specific command in a Binder protocol, and the IPCThreadState class instance creates a corresponding thread to process the real-time Binder request in the thread;
sb3: in the Binder _ proc structure corresponding to each user process, a waiting queue rt _ wait _ queue of the real-time Binder and an FIFO queue rt _ todo _ list of the real-time Binder are specially maintained for the real-time Binder request.
2. The method of claim 1, wherein when the system configures the two modes simultaneously, the software calls a specific interface to select one of the two modes, and if not, the default selects the mode separate from the normal Binder mode.
3. The method of claim 2, wherein the real-time Binder processing avoids non-real-time Binder contention, and further comprises the following steps before running a mode separate from the normal Binder mechanism or a mode embedded in the normal Binder mechanism:
reading the configuration or obtaining which mode the user selects by an interface called by the user, and if the mode separated from the common Binder mechanism is selected, operating in the mode separated from the common Binder mechanism; and if the mode embedded in the common Binder mechanism is selected, the mode embedded in the common Binder mechanism operates.
4. The method of claim 3, wherein in a mode separate from normal Binder, there are two ways of dealing with competition between different real-time Binder requests, the first, where all real-time Binder requests are treated fairly, and the second, where the real-time Binder requests are sorted according to priority; two ways a user can select through a specific configuration or a specific interface; in the second mode, the priority is set as the thread priority of hard real time or soft real time by default, when a Binder request is initiated, the real-time Binder drive is reached, and the Binder request is inserted into the corresponding position of the FIFO queue according to the priority sequence without interrupting the currently processed Binder request.
5. The method of claim 1, wherein in a mode separate from a normal Binder, there is one ServiceManager or two servicemanagers in the system;
when two servicemanagers exist, one is a native ServiceManager, the other is a ServiceManager specially serving the real-time Binder, and the Binder library distinguishes which IPCThreadState class instance is, so that the corresponding ServiceManager can be accessed to obtain correct service;
when only one ServiceManager exists, the real-time Binder driver finds an instance of the IPCThreadState class of the ordinary Binder through a set special interface when the ServiceManager needs the service, and thus accesses the ordinary Binder driver to obtain the service.
6. The method of claim 1, wherein a flag is set in the data structure of the FIFO queue of the real-time Binder to indicate whether it is from a real-time Binder request.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910356823.0A CN110196777B (en) | 2019-04-29 | 2019-04-29 | Method for avoiding non-real-time Binder competition in real-time android operating system through real-time Binder processing |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910356823.0A CN110196777B (en) | 2019-04-29 | 2019-04-29 | Method for avoiding non-real-time Binder competition in real-time android operating system through real-time Binder processing |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110196777A CN110196777A (en) | 2019-09-03 |
| CN110196777B true CN110196777B (en) | 2023-01-24 |
Family
ID=67752235
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910356823.0A Active CN110196777B (en) | 2019-04-29 | 2019-04-29 | Method for avoiding non-real-time Binder competition in real-time android operating system through real-time Binder processing |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110196777B (en) |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20150075499A (en) * | 2013-12-26 | 2015-07-06 | 한국전자통신연구원 | Apparatus and method for optimizing system performance of multi-core system |
| CN109117278A (en) * | 2018-06-29 | 2019-01-01 | Oppo（重庆）智能科技有限公司 | A kind of mobile terminal and its method for limiting, the storage medium of interprocess communication |
-
2019
- 2019-04-29 CN CN201910356823.0A patent/CN110196777B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20150075499A (en) * | 2013-12-26 | 2015-07-06 | 한국전자통신연구원 | Apparatus and method for optimizing system performance of multi-core system |
| CN109117278A (en) * | 2018-06-29 | 2019-01-01 | Oppo（重庆）智能科技有限公司 | A kind of mobile terminal and its method for limiting, the storage medium of interprocess communication |
Non-Patent Citations (1)
| Title |
|---|
| "Android HIDL 官方文档（六）—— 使用 Binder 进程间通信机制（Using Binder IPC）";StoneDemo;《 https://blog.csdn.net/qq_16775897/article/details/78407667 》;20171031;第1-6页 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN110196777A (en) | 2019-09-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20070074214A1 (en) | Event processing method in a computer system | |
| US9588808B2 (en) | Multi-core system performing packet processing with context switching | |
| CN100347676C (en) | PowerPC processor based vehicular operating system interrupt management method | |
| CN106502773B (en) | Data asynchronous processing method and module with synchronous callback information function | |
| CN107203428B (en) | Xen-based VCPU multi-core real-time scheduling algorithm | |
| CN1702623A (en) | Task level resource administration method for micro-kernel embedded real-time operation systems | |
| CN111026768A (en) | Data synchronization method and device capable of realizing rapid loading of data | |
| CN103412755A (en) | Hardware real-time operation system | |
| CN105389207A (en) | Adaptive data request processing method and apparatus, task scheduler and adaptive data request processing system | |
| KR100617228B1 (en) | method for implementation of transferring event in real-time operating system kernel | |
| CN111427686B (en) | Multithreading concurrency method for processors | |
| CN110866262A (en) | Asynchronous encryption and decryption system and method with cooperative work of software and hardware | |
| CN103488504A (en) | Method and device for loading data | |
| CN110196777B (en) | Method for avoiding non-real-time Binder competition in real-time android operating system through real-time Binder processing | |
| CN103677959A (en) | Virtual machine cluster migration method and system based on multicast | |
| JPH02300939A (en) | Semaphore operation system | |
| CN109710399B (en) | DSP communication task scheduling system and method | |
| CN204302959U (en) | A kind of hardware real-time operation system | |
| CN101976206A (en) | Interrupt handling method and device | |
| CN112714492B (en) | UWB data packet processing method, system, electronic device and storage medium thereof | |
| US10949367B2 (en) | Method for handling kernel service request for interrupt routines in multi-core environment and electronic device thereof | |
| EP1365322A1 (en) | Improvements relating to computer programs | |
| CN103150162B (en) | Improve the method for embedded software code degree of share | |
| CN114513383A (en) | Real-time Ethernet field bus data packet processing method based on original socket | |
| CN110519390A (en) | A kind of low-power consumption bluetooth controller link layer implementation method |
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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |