Priority transmission method, electronic device, and computer-readable storage medium

Abstract

The application provides a priority transmission method, an electronic device and a computer readable storage medium. In the method, when a high-priority process and a low-priority process in the electronic device perform cross-process communication and both need to use the same memory resource, the electronic device can transmit the priority of the high-priority process to the low-priority process. In this way, the computing resources of the low-priority process are not preempted by processes with intermediate priorities during the process in which the high-priority process waits for the low-priority process to release the memory resource, thereby avoiding the priority inversion situation in which the high-priority process needs to wait for the running of the process with the intermediate priority.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to priority passing methods, electronic devices, and computer-readable storage media. Background Technology

[0002] A process is the basic unit for resource allocation and scheduling in electronic devices. Electronic devices typically have multiple processes waiting to run at the same time, each capable of handling different tasks. To prioritize more important processes, electronic devices can assign different priorities to different processes. When multiple processes are waiting to run, the device can execute them sequentially from highest to lowest priority. However, in some situations, a high-priority process may have to wait for a lower-priority process to finish before it can run. This could cause tasks requiring rapid responses within the electronic device to remain unprocessed for an extended period, negatively impacting the user experience. Summary of the Invention

[0003] This application provides a priority passing method, an electronic device, and a computer-readable storage medium, which can solve the priority inversion problem when application processes query and call services.

[0004] In a first aspect, embodiments of this application provide a priority passing method applied to an electronic device. The software system of the electronic device includes a first application and a service manager. The method includes: the electronic device running the first application, the first application having a first priority higher than the service manager's second priority; the first application including code that calls a first service; the service manager registering one or more services for the application to call, the preconditions for the call including querying and obtaining the identifier of the first service from the service manager; when the electronic device runs the code that calls the first service, the electronic device queries the identifier of the first service from the service manager's second communication thread through the first application and passes the first application's first priority; the electronic device replacing the service manager's second priority with the first application's first priority; the electronic device blocking the first application and prioritizing the service manager, the electronic device querying the first service through the service manager and providing the first service's identifier to the first application; and the electronic device restoring the service manager's priority to the second priority and continuing to run the first application based on the first service.

[0005] In conjunction with the first aspect, in some embodiments, when the electronic device replaces the second priority of the service manager with the first priority of the first application, the method further includes: the electronic device setting a first flag bit for the second communication thread, the first flag bit being used to indicate that the thread of the service manager runs preferentially in a first thread set, the first thread set containing one or more threads with the same priority as the service manager.

[0006] In conjunction with the first aspect, in some embodiments, the electronic device queries a first service through a service manager and provides the identifier of the first service to a first application, including: the electronic device queries the identifier of the first service based on the name of the first service through the service manager; the electronic device sends a first reply signal to the inter-process communication driver through a second communication thread, the first reply signal including the identifier of the first service; the electronic device sends a second reply signal to the first communication thread through the inter-process communication driver, the second reply signal including the identifier of the first service, and the first communication thread is awakened from a dormant state after receiving the second reply signal.

[0007] In conjunction with the first aspect, in some embodiments, before the electronic device restores the priority of the service manager to the second priority, the method further includes: the electronic device sending a second acknowledgment signal to a second communication thread via an inter-process communication driver, the second acknowledgment signal being used to indicate that the inter-process driver has received the first reply signal, and the second communication thread entering a sleep state after receiving the second acknowledgment signal.

[0008] The service manager manages one or more services that applications can invoke. The first application first queries the service manager for the service identifier, and then invokes the service using the identifier. The first communication thread can be a thread in the first application that invokes one or more services via inter-process communication. The second communication thread can be a thread in the service manager that provides a second service via inter-process communication. The second service can provide functions for registering, querying, and invoking the aforementioned one or more services. The first communication thread is the initiator of inter-process communication, and the second communication thread is the receiver. When the first application needs to invoke the first service, it first queries the service manager's second communication thread for the service identifier. At this time, the first application can also pass its own priority (first priority) to the service manager. This ensures that the service manager's computing resources are not preempted by processes with a higher priority than the second priority but lower than the first priority during the service query process, thus avoiding long query times for the first application and improving the user experience. After the service manager finishes querying the first service, the electronic device can restore the service manager's priority, ensuring that the processor executes processes according to the original priority.

[0009] Threads within the same application typically have the same priority. When an electronic device passes the priority of the first application to the service manager, it also sets a first flag for the second communication thread. This ensures that when a thread with the same priority as the service manager (including other threads of the service manager) needs to use the processor's computing resources, the processor prioritizes running the second communication thread, thus avoiding excessive waiting time for cross-process communication in the first application.

[0010] In conjunction with the first aspect, in some embodiments, the electronic device continues to run the first application based on the first service, including: the electronic device sending one or more parameters and transmitting the first priority of the first application to the third communication thread of the second application through the first communication thread of the first application, the third communication thread being used to provide the first service through inter-process communication, the one or more parameters including parameters required to run the first service, the first priority of the first application being higher than the third priority of the second application; the electronic device replacing the third priority of the second application with the first priority of the first application; the electronic device blocking the first application and running the second application first, the electronic device running the first service through the second application based on one or more parameters; the electronic device returning the running result of the first service to the first application, and continuing to run the first application based on the running result.

[0011] In conjunction with the first aspect, in some embodiments, the electronic device blocks the first application, including: the electronic device sending a first acknowledgment signal to the first communication thread via an inter-process communication driver, the first acknowledgment signal indicating that the inter-process communication driver has received a first transaction signal; and the electronic device causing the first communication thread of the first application to sleep.

[0012] The second application provides the first service. After obtaining the identifier of the first service, the first application can invoke the first service using that identifier. The first application can send one or more parameters for using the first service to the third communication thread via the first communication thread. Simultaneously, the electronic device can pass the first application's first priority to the second application. The second application can run the first service based on one or more parameters and then return the result to the first application. During the second application's execution of the first service, its priority remains the first priority. This prevents processes with lower priorities than the first but higher than the third priority from preempting computing resources, which would cause the first application to wait a long time to obtain the first service, impacting the user experience. The electronic device can also pass a first flag bit to the third communication thread while passing the first priority. After the second application's third communication thread returns the result of the first service to the first application's first communication thread, the electronic device can restore the second application's priority and schedule processes according to the original priority.

[0013] In conjunction with the first aspect, in some embodiments, the software system of the electronic device further includes an inter-process communication driver. The electronic device queries the identifier of the first service and transmits the first priority of the first application to the second communication thread of the service manager through the first communication thread of the first application. This includes: the electronic device sending a first transaction signal to the inter-process communication driver through the first communication thread. The first transaction signal contains the name of the first service, which is used to query the identifier of the first service. The first transaction signal also indicates that the priority of the service manager be replaced with the first priority; the electronic device sending a second transaction signal to the second communication thread through the inter-process communication driver. The second transaction signal contains the name of the first service. The second communication thread is awakened from a dormant state after receiving the second transaction signal.

[0014] The first transaction signal can also be called the BC_TRANSACTION signal, see reference. Figure 6 In the illustrated embodiment, the first transaction signal includes multiple function calls. The electronic device can pass the name of the first service to the inter-process communication driver when transmitting the first transaction signal, and simultaneously replace the service manager's priority with the first priority. Then, the inter-process communication driver can pass the name of the first service to the second communication thread via the second transaction signal.

[0015] In conjunction with the first aspect, in some embodiments, when an electronic device sends a first transaction signal to an inter-process communication driver via a first communication thread, the method includes: the electronic device transmitting a first work item parameter, a first process parameter, and a first thread parameter to the inter-process communication driver via the first communication thread; the first work item parameter indicates a transaction querying an identifier of a first service; the first process parameter indicates a process for executing the first transaction; and the first thread parameter indicates a thread for executing the first transaction; if the electronic device determines that the first thread parameter is not null, the electronic device performs a first enqueue operation and a first priority passing operation; if the electronic device determines that the first thread parameter is null, the electronic device only performs the first priority passing operation; the first enqueue operation includes: adding the first transaction to a first queue of the thread indicated by the first thread parameter, and then replacing the priority of the process indicated by the first process parameter with the first priority; the first queue is used to store one or more transactions to be executed; the first priority passing operation includes: determining whether the process indicated by the first process parameter is a process of a service manager; if the process indicated by the first process parameter is a process of a service manager, the electronic device replaces the priority of the service manager with the first priority.

[0016] In this scenario, when the first application queries or invokes a service, the electronic device transmits the first process parameter and the first thread parameter in the first transaction signal via the first communication thread. The first work item can be used to indicate the work content, such as querying or invoking a service. The first process parameter specifies which process the first application should query or invoke the service from, and the first thread parameter specifies which thread the first application should query or invoke the service from. When the first application queries the service manager, the first thread parameter is null because the service manager does not distinguish between threads used to provide query services. However, in the scenario where the first application invokes a service, the first thread parameter must specify the thread corresponding to the service it wants to invoke, and in this case, the first thread parameter is not null. This is because when the first thread parameter is null, priority is passed to the service manager alone, while when the first thread parameter is not null, priority can be passed to other applications providing services. This ensures that priority can be successfully passed in both query and invoking scenarios, thus avoiding priority inversion.

[0017] In a second aspect, embodiments of this application provide an electronic device, which includes a memory and a processor coupled to the memory; the memory stores a computer program, and when the processor executes the computer program, the electronic device implements the method described in any one of the first aspects.

[0018] Thirdly, embodiments of this application provide a computer-readable storage medium storing a computer program or computer instructions, which are executed by a processor to implement the method described in any of the first aspects above.

[0019] Fourthly, embodiments of this application provide a computer program product, which, when executed by a processor, implements the method described in any of the first aspects above.

[0020] Fifthly, embodiments of this application provide a chip including a processor and a memory, wherein the memory is used to store computer programs or computer instructions, and the processor is used to execute the computer programs or computer instructions stored in the memory, causing the chip to perform the method described in any of the first aspects above.

[0021] The solutions provided in the second to fifth aspects above are used to implement or cooperate with the methods provided in the first aspect above, and therefore can achieve the same or corresponding beneficial effects as the methods in the first aspect, which will not be elaborated here. Attached Figure Description

[0022] Figure 1 This is a schematic diagram of the structure of the electronic device 100 provided in the embodiments of this application;

[0023] Figure 2 This is a software structure block diagram of the electronic device 100 according to an embodiment of this application;

[0024] Figure 3 This is a schematic diagram of an inter-process communication mechanism of an electronic device 100 provided in an embodiment of this application;

[0025] Figure 4 This is a schematic diagram illustrating a scenario where an electronic device experiences a priority flipping problem, as provided in an embodiment of this application.

[0026] Figure 5 This is a schematic diagram illustrating a scenario for prioritizing electronic devices, as provided in an embodiment of this application.

[0027] Figure 6 This is a schematic diagram illustrating the process by which the client process passes priority to the server process, as provided in an embodiment of this application.

[0028] Figure 7 This is a schematic diagram of the function call relationship of the binder_transaction function provided in an embodiment of this application;

[0029] Figure 8 This is a flowchart of the priority passing method provided in the embodiments of this application;

[0030] Figure 9 This is a schematic diagram of the structure of a priority transfer device 900 provided in an embodiment of this application;

[0031] Figure 10 This is a schematic diagram of the structure of a chip provided in an embodiment of this application. Detailed Implementation

[0032] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to and includes any or all possible combinations of one or more of the listed items.

[0033] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0034] Here, we first introduce the exemplary electronic device 100 provided in the embodiments of this application.

[0035] Figure 1 This is a schematic diagram of the structure of the electronic device 100 provided in the embodiments of this application.

[0036] The following description uses electronic device 100 as an example to illustrate the embodiment. It should be understood that electronic device 100 may have more than Figure 1 The more or fewer components shown can be combined into two or more components, or they can have different component configurations. Figure 1 The various components shown can be implemented in hardware, software, or a combination of hardware and software, including one or more signal processing and / or application-specific integrated circuits.

[0037] Electronic device 100 may include: processor 110, external memory interface 120, internal memory 130, pressure sensor 150, etc.

[0038] Processor 110 may include one or more processing units, such as: application processor (AP), modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, memory, video codec, digital signal processor (DSP), baseband processor, and / or neural network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0039] The controller can be the nerve center and command center of the electronic device 100. The controller can generate operation control signals according to the instruction opcode and timing signals to complete the control of fetching and executing instructions.

[0040] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0041] Electronic device 100 implements display functions through a GPU, display screen 140, and application processor. The GPU is a microprocessor for image processing, connected to the display screen 140 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering. Processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0042] Display screen 140 is used to display images, videos, etc. Display screen 140 includes a display panel. The display panel may be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a Mini LED, a MicroLED, a Micro-OLED, a quantum dot light-emitting diode (QLED), etc. In some embodiments, electronic device 100 may include one or N displays 140, where N is a positive integer greater than 1.

[0043] An NPU (Neural Processing Unit) is a computational processor for neural networks (NNs). By borrowing the structure of biological neural networks, such as the transmission patterns between neurons in the human brain, it can rapidly process input information and continuously learn on its own. NPUs enable intelligent cognitive applications in electronic devices, such as image recognition, facial recognition, speech recognition, and text understanding.

[0044] The external storage interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100. The external memory card communicates with the processor 110 through the external storage interface 120 to perform data storage functions. For example, music, video, and other files can be saved on the external memory card.

[0045] Internal memory 130 can be used to store computer executable program code, which includes instructions. Processor 110 executes various functional applications and data processing of electronic device 100 by running the instructions stored in internal memory 130. Internal memory 130 may include a program storage area and a data storage area. The program storage area may store the operating system, applications required for at least one function (such as facial recognition, fingerprint recognition, mobile payment, etc.). The data storage area may store data created during the use of electronic device 100 (such as facial information template data, fingerprint information templates, etc.). Furthermore, internal memory 130 may include high-speed random access memory and non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc.

[0046] Pressure sensor 150 is used to sense pressure signals and can convert the pressure signals into electrical signals. In some embodiments, pressure sensor 150 may be disposed on display screen 140. When a touch operation is applied to display screen 140, electronic device 100 detects the intensity of the touch operation based on pressure sensor 150. Electronic device 100 may also calculate the touch position based on the detection signal from pressure sensor 150.

[0047] Processor 110 can be used to run processes, where a process is a running activity of an application within electronic device 100 regarding one or more data sets, and is the basic unit for resource allocation and scheduling by electronic device 100. Each process has its own independent memory space. This memory space corresponds to a series of storage units in internal memory 130 or memory coupled to processor 110. The memory space can be used to store code, data, and stacks. To ensure the security and isolation of process execution, each process cannot directly access the memory space of another process, but needs to communicate or exchange data with other processes through inter-process communication (IPC) mechanisms. Inter-process communication can also be called inter-process communication. For ease of description and better understanding, subsequent embodiments of this application will describe an inter-process communication mechanism based on Binder. A description of the inter-process communication mechanism can be found in subsequent embodiments and will not be elaborated here.

[0048] A process can contain one or more threads. Each thread is an execution flow within a process, and is an actual unit of operation within the process. Threads within a process can share the process's memory space.

[0049] The electronic device can set a priority for each process. When there are multiple processes to be run, the processor 110 of the electronic device can run the processes in order of priority from high to low. That is, high-priority processes run first, and low-priority processes run after high-priority processes. This can ensure that some important processes or processes that need to respond quickly can obtain computing resources for processing as soon as possible.

[0050] Figure 2 This is a software structure block diagram of an electronic device 100 according to an embodiment of this application.

[0051] A layered architecture divides software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the system is divided into five layers, from top to bottom: the application layer, the application framework layer, the programming language interface layer, the native library layer, and the kernel layer.

[0052] The application layer can include a series of application packages, such as instant messaging applications, news applications, music applications, etc. (which can also be called applications).

[0053] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions.

[0054] like Figure 2 As shown, the application framework layer may include inter-process communication agents, service managers, and inter-process communication modules, etc.

[0055] The inter-process communication proxy provides an interface for client applications (i.e., applications that need to call services from the service manager) to communicate across processes with server applications (i.e., applications that provide services). The aforementioned client and server applications are not limited to application-layer applications; they can also be applications from other software layers, such as system applications. This application embodiment does not impose such limitations.

[0056] The ServiceManager in the application framework layer provides interfaces for upper-layer applications to register, query, and manage services. After the application calls these interfaces, the ServiceManager in the local library layer can implement the corresponding functionality.

[0057] Services provide specific functionalities. Services can be provided by internal system applications of the electronic device (such services can be called system-level services), or they can be provided by third-party applications. For example, system services included in an electronic device may include an ActivityManagerService, a WindowManagerService, an InputManagerService, etc. The ActivityManagerService can be used to manage the lifecycle of applications. The WindowManagerService can be used to manage windows, including their creation, display, hiding, and movement. Windows are used to host views, and the windows and the views within them together constitute the visual user interface. The InputManagerService is used to handle input events, such as processing user clicks on the display screen 140, etc.

[0058] The inter-process communication module provides an interface for server applications to communicate with client applications across processes.

[0059] The upper-layer application and the lower-layer native library are typically written in different types of code. The programming language interface layer provides an interface for interaction between the upper-layer application code and the lower-layer native code.

[0060] Taking the Android system as an example, the programming language interface layer, also known as the Java Native Interface (JNI) layer, allows Java applications to call native library code written in languages ​​such as C or C++ through the JNI layer. The JNI layer may include, for example, inter-process communication function libraries and the Android Runtime.

[0061] The inter-process communication function library is used to provide an interface for interaction between upper-layer applications and lower-layer clients, such as a communication proxy and an inter-process communication interface, thereby realizing inter-process communication.

[0062] The Android Runtime consists of core libraries and a virtual machine, which is responsible for system scheduling and management.

[0063] The core library consists of two parts: one part is the functionalities that the programming language (e.g., Java) needs to call, and the other part is the system's core library.

[0064] The application layer and application framework layer run in a virtual machine. The virtual machine executes the programming files (e.g., Java files) of the application layer and application framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

[0065] The native library layer can be used to access underlying hardware resources and manage files and memory. In this embodiment, the native library layer can be used to implement cross-process communication. The native library layer may include a client communication proxy, a server communication object, a cross-process communication interface, and a service manager.

[0066] A client communication proxy is used to implement communication with the server process. For example, a client communication proxy can be the BpBinder module.

[0067] The server-side communication object is used to implement communication with the client process. For example, the BBinder module can be used as a server-side communication object.

[0068] Cross-process communication interfaces are used to transmit the interaction content between the server-side communication object and the upper-level software layer. For example, a cross-process communication interface can be the JavaBBinder module.

[0069] The service manager is used to implement the registration, querying, and management of services.

[0070] The client communication proxy, server communication object, and service manager at the local library layer can communicate with the cross-process communication driver at the kernel layer through device control interface functions such as ioctl (input / output control).

[0071] The kernel layer is the layer between hardware and software. The kernel layer can include inter-process communication drivers.

[0072] A cross-process communication driver (Binderdriver) can be used to implement the transmission of data or instructions across processes.

[0073] Not limited to Figure 2 The software layer shown in the diagram, the electronic device 100 may contain more than Figure 2 This can refer to more or fewer software layers, or combinations of certain software layers, etc. For example, a hardware abstraction layer (HAL) can also be included between the kernel layer and the native library layer. The HAL provides an interface for upper-layer applications to operate the underlying hardware. This is not limited to... Figure 2 The software module shown, the electronic device 100 may also include more than Figure 2 The application framework layer can also include other software modules, such as a window manager, an activity manager, and so on. The window manager provides window management services, and the activity manager provides activity management services.

[0074] Figure 2 The software architecture shown can be used to implement the inter-process communication mechanism of electronic device 100. Applications of electronic device 100 can access memory spaces between processes through the inter-process communication mechanism, thereby enabling functions such as service registration, service querying, and service usage.

[0075] Figure 3 This is a schematic diagram of an inter-process communication mechanism for an electronic device 100 provided in an embodiment of this application. For example... Figure 3 As shown, the client can be an application seeking services. This application can be a system application, a third-party application, etc., and this embodiment does not impose any limitations on this. The client can run multiple threads, including threads responsible for handling the main application logic, threads responsible for handling inter-process communication (also known as Binder threads), etc. The server can be an application providing the services, which can be either a system application or a third-party application. The server can also run multiple threads, including threads for handling inter-process communication.

[0076] It should be noted that the applications within the electronic device 100 can play different roles in different inter-process communication processes. That is, the application can act as a client in some inter-process communication processes and as a server in others. Specifically, the application acts as a server when providing services to other applications, and as a client when using services from other applications.

[0077] The following section describes the cross-process communication mechanism of the electronic device 100 provided in this application embodiment, focusing on the three processes of registration service, query service, and usage service.

[0078] 1. Registration Service

[0079] In the server-side, the thread handling inter-process communication (or the server-side Binder thread) first communicates with the inter-process communication driver through modules such as the inter-process communication module, inter-process communication interface, and server-side communication proxy, initiating a service registration request to the driver. The inter-process communication driver then forwards the registration request to the service manager. The service manager maintains a service list (svcinfo), which may contain handles and service names of registered services. Upon receiving a service registration request from the server, the service manager adds the handle and name of the service provided by that server to the service list, thus completing the service registration. A handle is a reference to a service resource; it can be a pointer.

[0080] 2. Inquiry Service

[0081] When a client needs to invoke a service, its Binder thread can communicate with the inter-process communication (IPC) driver through modules such as the inter-process communication proxy and client communication proxy. The client sends a request to the IPC driver to retrieve the service, including the name of the service in the request. The IPC driver then forwards this request to the service manager. The service manager searches its service list for the service the client wants and, through the IPC driver, returns a handle to the service to the client. In this way, the client successfully retrieves the service it needs to invoke.

[0082] 3. Using the service

[0083] After obtaining a handle to the service it wants to invoke, the client can send a command to the inter-process communication (IPC) driver to invoke the target service. This command can include one or more parameters required to use the target service. The IPC driver can create a shared memory block to receive the parameters sent by the client; these parameters are copied into the shared memory. The IPC driver then instructs the server to run the target service based on these parameters and writes the results back to the shared memory. The IPC driver then instructs the client to retrieve the service results from the shared memory. This completes the client's invocation (or use) of the service.

[0084] Among them Figure 3 During the cross-process communication process shown, a priority inversion issue may occur when the client queries the service manager for services or when the client calls services provided by the server. Priority inversion means that a lower-priority process executes before a higher-priority process.

[0085] Figure 4 This is a schematic diagram illustrating a scenario where an electronic device experiences a priority flipping problem, as provided in an embodiment of this application.

[0086] like Figure 4 As shown, at time T0, the low-priority process 3 starts running first, and there are no processes preempting resources at this time.

[0087] At time T1, process 2 starts running. Since process 2 has a higher priority than process 3, the electronic device will determine whether to run process 2 first and block process 3 based on the priorities of process 2 and process 3.

[0088] At time T2, process 1 begins running. Process 1 has a higher priority than processes 2 and 3, but process 1 needs to use the same shared resource as process 3. Because process 3 is blocked by process 2, process 3 can neither release the shared resource nor continue running. This means that both process 1 and process 3 need to wait for process 2 to finish running before they can run.

[0089] If process 2 finishes running at time T3, the electronic device can continue running process 3.

[0090] At time T4, process 3 finishes running and releases shared resources, allowing the electronic device to run process 1.

[0091] As can be seen, in the above process, the higher-priority process 1 is run after the lower-priority process 2. This phenomenon can be called priority inversion.

[0092] In this scenario, process 1 might be the process of the client application querying the service, and process 3 might be the process of the service manager. When a higher-priority client application queries the service manager for a service, the lower priority of the service manager's process might lead to other processes preempting computing resources. This causes the client application and service manager to wait for other processes to finish running before they can continue, resulting in a longer wait time for the client application to retrieve the service. This is especially problematic during client application startup, where the client application needs to query and obtain services such as activity management and window management to create application activities and generate window interfaces. Priority flipping can then lead to longer client application startup times, negatively impacting the user experience.

[0093] Similarly, when process 1 is the process of the client application that is calling the service, and process 3 is the process of the server application that is providing the service, the above priority inversion problem may also occur, resulting in a poor user experience when using the client application.

[0094] To address the aforementioned problems, embodiments of this application provide a priority passing method, an electronic device, and a computer-readable storage medium. In this method, when a high-priority process and a low-priority process engage in cross-process communication and need to use the same shared resource, the electronic device can pass the priority of the high-priority process to the low-priority process, making the priority of the low-priority process consistent with that of the high-priority process. After the low-priority process finishes running, its priority is restored. This effectively prevents the computing resources of a low-priority process from being preempted by a process with intermediate priority, thus avoiding priority inversion.

[0095] For example, when an application with priority 70 queries a service manager with priority 30, the electronic device can pass priority 70 to the service manager, so that its process has a priority of 70 during the service manager's service query. When a process with priority 50 comes to run, the service manager's process priority is higher than 50, and the electronic device still prioritizes running the service manager and queries the service through it. After the service manager has queried the service, the electronic device restores the service manager's priority to 30. This avoids the priority inversion problem where a process with priority 70 has to wait for a process with priority 50 to run before it can run. The priority values ​​of the application and service manager described above are merely examples and do not constitute a limitation of the embodiments of this application.

[0096] Figure 5 This is a schematic diagram of a scenario for transmitting priority in an electronic device, provided in an embodiment of this application.

[0097] like Figure 5 As shown, process 1 has the highest priority, and process 3 has the lowest priority. At time T0, electronic device 100 is running process 3.

[0098] At time T1, the electronic device is running process 2, and at this time process 3 is blocked by process 2.

[0099] At time T2, the electronic device starts process 1. If process 1 and process 3 use the same shared resource (e.g., process 1 calls a service of process 3), the electronic device will pass the priority of process 1 to process 3, thus making process 3's priority higher than process 2's priority. Therefore, after time T2, the electronic device blocks the execution of process 2 and continues to run process 3.

[0100] At time T3, process 3 finishes running, and the electronic device can restore the priority of process 3 and continue running process 1. At this time, process 2 is still in a blocked state.

[0101] At time T4, process 1 of the electronic device ends, and process 2 of the electronic device begins.

[0102] As can be seen, after the electronic device transfers the priority of process 1 to process 3 at time T2, the execution of process 3 is no longer affected by process 2. This effectively avoids the situation where process 2, after starting, preempts the computing resources of process 3, causing both process 1 and process 3 to wait for process 2 to complete before they can continue running, thus avoiding the priority inversion problem.

[0103] The following section describes the process of a high-priority client process passing priority to a low-priority server process, using the example of cross-process communication between the client and server processes.

[0104] Figure 6 This is a schematic diagram illustrating the process of a client process passing priority to a server process, as provided in an embodiment of this application. Specifically, when the client process needs to query or register a service, the server process is the service manager process; when the client process needs to invoke a service, the server process is the application providing the service.

[0105] For ease of description and better understanding, Figure 6 The steps in this document use the example of the client process querying the server process (the process of the service manager) to illustrate the process of the client process passing priority to the server process.

[0106] like Figure 6 As shown, the process of a client process passing priority to a server process can involve, but is not limited to, the following steps:

[0107] S601, The client process sends a first transaction signal to the inter-process communication driver. The first transaction signal contains the name of the service to be queried.

[0108] The first transaction signal can be the BC_TRANSACTION signal. The binder thread in the client process, used for inter-process communication, can include the name of the service to be queried in the first transaction signal. When the client's binder thread sends the first transaction signal to the inter-process communication driver, it also transmits its own priority through the first transaction signal.

[0109] When a client binder thread calls a service from a server binder thread, the first transaction signal may contain a handle to the service to be called, as well as one or more parameters required to use the service.

[0110] An electronic device may contain code for the client binder thread to send a first transaction signal. This code may include calls to one or more functions. The electronic device can execute this code, enabling the client process to send a first transaction signal to the inter-process communication driver through the calls to one or more functions. For example, the function call process may include: first, calling the `binder_ioctl_write_read` function, which is used to implement inter-process communication with another process. When the client binder thread calls `binder_ioctl_write_read`, it passes the name of the service to be queried to the function. Then, within `binder_ioctl_write_read`, the `binder_thread_write` function is called. The `binder_thread_write` function is used to specifically send a message to the target binder thread (i.e., the server-side binder thread). `binder_thread_write` can encapsulate multiple parameters into a transaction, which may include, for example, a work item to be processed (`binder_work`), process information for processing the transaction (`binder_proc`), thread information for processing the transaction (`binder_thread`), etc. When a client binder thread queries a service manager, the service manager doesn't distinguish between threads handling transactions; it only needs to pass the service manager's process. In this case, the `binder_thread` parameter passed in the transaction is null. When a client binder thread calls a service from another application, the `binder_proc` parameter can be used to pass the application's process information (e.g., process ID), and the `binder_thread` parameter can be used to pass the binder thread information (e.g., thread ID) used by that application for handling inter-process communication. The `binder_thread_write` function can then call the `binder_transaction` function. The `binder_transaction` function can have different processing branches based on the signal type. Under the `BC_TRANSACTION` signal, the `binder_transaction` function can add the work item to the to-do queue of the process or thread that needs to process that work item. The binder function can call the `binder_set_priority_hook` and `binder_transaction_received_hook` functions respectively, where priority is passed.

[0111] Figure 7 This is a schematic diagram illustrating the function call relationship of the binder_transaction function provided in an embodiment of this application. For example... Figure 7 As shown, the `binder_transaction` function calls the `binder_proc_transaction` function. When calling `binder_transaction`, it passes the work item parameter `binder_work`, the process information parameter `binder_proc`, and the thread information parameter `binder_thread`, among others. The `binder_proc_transaction` function can be used to process transactions, which may include checking transaction validity, allocating memory, etc. The `binder_proc_transaction` function can determine whether the thread parameter of the transaction to be processed is null. It should be noted that the thread parameter of the transaction to be processed is null only when the service manager acts as the server. When other applications providing services act as the server, the thread parameter of the transaction to be processed contains information about the binder thread (such as the thread number) used by that application to handle inter-process communication. This is because other applications often contain multiple threads, which may include threads for handling the main application logic, threads for rendering the user interface, one or more binder threads for handling cross-process communication, etc. Therefore, only when an application other than the service manager acts as the server does it need to specify the binder thread used by that application to handle the transaction in the parameters. The service manager process does not contain multiple threads implementing different functions, so the above distinction is not necessary. When the thread parameter for the transaction to be processed is not null, the electronic device can add the work item to the thread of the transaction to be processed. The electronic device can then call the `binder_transaction_priority` function, and within it, call the `binder_set_priority_hook` function. This function passes the client's priority to the server process and sets the VIP flag for the server's binder thread. Setting the VIP flag indicates that the binder thread can run first among one or more threads with the same priority. In this way, the electronic device passes the client's priority to the application acting as the server. Since the `binder_transaction_priority` function is not executed when the service manager acts as the server, the electronic device can pass priority to the service manager separately in subsequent steps. This ensures that the electronic device can pass client priority to the server in different scenarios of querying and calling the service. Figure 7As shown, when the electronic device determines that the thread parameter of the transaction to be processed is null, it calls the `trace_android_vh_binder_proc_transaction_finish` function. Within this function, the electronic device can determine whether the process of the transaction passed to the `binder_transaction` function is the process of the service manager. If so, the electronic device can pass the priority of the client process to the service manager's process and the VIP flag to the service manager's binder thread. Finally, the electronic device can execute other function calls sequentially.

[0112] S602, the cross-process communication driver sends a first acknowledgment signal to the client process, the first acknowledgment signal indicating that the first transaction signal has been received.

[0113] The first acknowledgment signal can be the BR_TRANSACTION_COMPLETE signal. The BR_TRANSACTION_COMPLETE signal can be used by the inter-process communication driver to inform the client process that it has received the aforementioned BR_TRANSACTION signal. After receiving the BR_TRANSACTION_COMPLETE signal, the client process enters a sleep state. Once in a sleep state, the process must wait to be woken up before continuing execution by the processor.

[0114] S603, the inter-process communication driver sends a second transaction signal to the server process. The second transaction signal may contain the name of the service that the client process is querying.

[0115] The server-side binder thread can call the `binder_thread_read` function of the inter-process communication driver to check if there are any unprocessed work items in its to-do queue. If so, the inter-process communication driver can send a `BR_TRANSACTION` signal to the server process. The `BR_TRANSACTION` signal contains the work item `binder_work` that the inter-process communication driver retrieved from the to-do queue corresponding to the server-side binder thread. Upon receiving the second transaction signal, the server process is awakened from its sleep state. The server-side binder thread can then query the transaction corresponding to the work item `binder_work`, and read the parameters passed in the transaction, which may include the service name the client wants to query. The server process can then search for the service in the service list based on that service name.

[0116] Specifically, when the server-side binder thread calls the `binder_thread_read` function, if there are no unprocessed work items in the pending transaction queue, it will call the `binder_restore_priority_hook` function. This function restores the process's priority and cancels the process's VIP flag. Because the service manager does not distinguish between binder threads when acting as the server, even if the thread's pending transaction queue is empty, it does not guarantee that all transactions have been completed. If the service manager's priority is restored, the server may not have completed its service query and returned the results. Therefore, after the electronic device calls the `binder_restore_priority_hook` function, it needs to determine whether the server is the service manager. If so, the priority and VIP flag of the server-side thread will not be modified. This avoids the problem of priority inversion still occurring when the service manager, acting as the server, restores its priority and VIP flag too early.

[0117] S604. The server process sends a first reply signal to the inter-process communication driver. The first reply signal contains the service query result.

[0118] After the server process finds the service, it can return a first response signal to the inter-process communication driver. This first response signal can include, for example, the service query result, which may be a handle to the service queried by the client process. The client process can then use this handle to call the service; the handle can be, for example, a pointer. The first response signal can be the BC_REPLY signal.

[0119] In scenarios where a client process calls a service, the first response signal may include the service's execution result.

[0120] The process of the server process sending the first reply signal to the inter-process communication driver can involve multiple function calls. For example, it might include the `binder_ioctl_write_read` function, which in turn calls the `binder_thread_write` function. When the server process calls this function, it passes in the service query result, as well as the client's process and thread information. The `binder_thread_write` function then calls the `binder_transaction` function. The `binder_transaction` function instructs the inter-process communication driver to pass the work item to the specified binder thread on the client. Under the `BC_REPLY` signal, the `binder_transaction` function calls the `binder_restore_priority_hook` function, which restores the server process's priority and removes its VIP flag. The `binder_restore_priority_hook` function checks if the process whose priority is to be restored is the service manager's process; if so, it cancels the restoration. In other words, only in scenarios where the client process calls the service from the server process will the server process's priority be restored to its original priority and its VIP flag removed. In scenarios where a client process queries a server process for services, the service manager, acting as the server, will not restore its own priority at this point.

[0121] S605, the cross-process communication driver sends a second acknowledgment signal to the server process, the second acknowledgment signal indicating that the first reply signal has been received.

[0122] After the inter-process communication driver calls the `binder_thread_read` function to confirm that there are no work items in the pending transaction queue, it can send a second acknowledgment signal to the server process. This second acknowledgment signal could be, for example, the `BR_TRANSACTION_COMPLETE` signal. Upon receiving the second acknowledgment signal, the server process will revert from the running state to the sleeping state.

[0123] When the cross-process communication driver calls the binder_thread_read function, it checks whether the pending transaction queue is empty. If it is empty, it can execute the trace_android_vh_binder_transaction_received function. In this function, it can check whether the server process is the process of the service manager. If it is, it restores the process priority of the service manager and cancels its VIP identifier.

[0124] S606, the inter-process communication driver sends a second reply signal to the client process, the second reply signal containing the service query result.

[0125] The second response signal can be, for example, the BR_REPLY signal. This signal contains the service query result returned by the service manager, such as the service handle. Upon receiving this second response signal, the client binder thread can be awakened from its sleep state and continue running to invoke the service. The process of the client process invoking the service through the cross-process mechanism can be referenced from the client process querying the service process described above, and will not be repeated here.

[0126] It should be noted that, Figure 6 , Figure 7 In the function calls mentioned above, the function names are merely examples. These functions can also be other functions used to achieve the same functionality, or they can combine functions to achieve the same functionality, or they can be split into functions to achieve the same functionality. Furthermore, the function calls can also invoke other functions to achieve more functionalities; this application does not impose any limitations on this.

[0127] when Figure 6 When the process shown runs on the Android system, some of the function calls mentioned above, such as binder_set_priority_hook, binder_transaction_received_hook, binder_restore_priority_hook, and trace_android_vh_binder_transaction_received, can be functions provided by the Android system that allow modification of code logic, or hook points. These functions can be declared with the EXPORT_TRACE_POINT_SYMBOL_GPR attribute.

[0128] Figure 8 This is a flowchart of the priority passing method provided in the embodiments of this application. For example... Figure 8 As shown, this method may include, but is not limited to, the following steps:

[0129] S801. An electronic device runs a first application, the first application having a first priority higher than the service manager having a second priority. The first application includes code that calls a first service. The service manager is used to register one or more services for the application to call. The prerequisite for calling the service includes querying and obtaining the identifier of the first service from the service manager.

[0130] The first application can be, for example, the client application mentioned above, which is used to query and invoke services. The first application has the highest priority, and the service manager has the second highest priority. The first service can be a service that has been registered with the service manager. The first application has a higher priority than the service manager, meaning that when both the process of the first application and the process of the service manager are waiting for the processor to run, the processor running the process of the first application has a higher priority than the processor running the process of the service manager.

[0131] S802. When the electronic device runs to the code that calls the first service, the electronic device queries the identifier of the first service from the second communication thread of the service manager through the first communication thread of the first application and passes the first priority of the first application.

[0132] S803, the electronic device replaces the second priority of the service manager with the first priority of the first application.

[0133] The first communication thread can be used to invoke one or more services through inter-process communication, and it can be the client binder thread in the aforementioned embodiments. The second communication thread can be a thread used to provide a second service for inter-process communication, which is used to register and invoke the one or more services for application invocation. That is to say, the service registration and invocation functions provided by the service manager can also be regarded as services provided by the service manager. The service manager may contain a binder thread for inter-process communication, which can be called the second communication thread.

[0134] The prerequisite for the call is that the first application queries the service manager and obtains the identifier of the first service. Therefore, when the electronic device runs the code that calls the first service, the electronic device must first query the identifier of the first service from the second communication thread of the service manager through the first communication thread. The identifier of the first service can also be called the handle of the first service, which can be a pointer to the memory resource of the first service, etc.

[0135] The electronic device queries the identifier of a first service from the second communication thread of the service manager via the first communication thread of the first application and transmits the first priority of the first application. This includes: the electronic device sending a first transaction signal to the inter-process communication driver via the first communication thread. The first transaction signal contains the name of the first service, which is used to query the identifier of the first service. The first transaction signal also indicates that the priority of the service manager should be replaced with the first priority. The electronic device then sends a second transaction signal to the second communication thread via the inter-process communication driver. The second transaction signal contains the name of the first service. Upon receiving the second transaction signal, the second communication thread is awakened from a sleep state. The method for the first communication thread to query the identifier of the first service from the second communication thread can be found in [reference needed]. Figure 6 The descriptions of steps S601-S603 in the illustrated embodiment will not be repeated here.

[0136] When an electronic device sends a first transaction signal to an inter-process communication driver through a first communication thread, the method includes: the electronic device transmitting a first work item parameter, a first process parameter, and a first thread parameter to the inter-process communication driver through the first communication thread; the first work item parameter indicates a transaction querying the identifier of a first service; the first process parameter indicates the process used to execute the first transaction; and the first thread parameter indicates the thread used to execute the first transaction. If the electronic device determines that the first thread parameter is not null, the electronic device performs a first enqueue operation and a first priority passing operation; if the electronic device determines that the first thread parameter is null, the electronic device only performs the first priority passing operation. The first enqueue operation includes: adding the first transaction to the first queue of the thread indicated by the first thread parameter, and then replacing the priority of the process indicated by the first process parameter with the first priority. The first queue is used to store one or more transactions to be executed. The first priority passing operation includes: determining whether the process indicated by the first process parameter is the process of the service manager; if the process indicated by the first process parameter is the process of the service manager, the electronic device replaces the priority of the service manager with the first priority.

[0137] refer to Figure 7In the illustrated embodiment, the first work item parameter can be, for example, the work item parameter `binder_work` passed when the `binder_transaction` function calls the `binder_proc_transaction` function; the first process parameter can be, for example, the process information parameter `binder_proc`; and the first thread parameter can be, for example, the thread information parameter `binder_thread`. When the first thread parameter contains the thread information of the work item to be processed, the inter-process communication driver in the electronic device adds the work item to the pending transaction queue of that thread, i.e., performs the first enqueue operation. The server-side `binde` thread retrieves the work item from the queue for processing by calling the `binder_tread_read` function. During the first enqueue operation, the `binder_set_priority_hook` function is called, which is used to pass the priority and / or the first flag bit to processes outside the service manager. Since the service manager does not pass the first thread parameter when acting as a server, the first thread parameter is NULL, and the above first enqueue operation is not performed. Therefore, the electronic device determines whether the process indicated by the first process parameter is the process of the service manager. If so, the electronic device passes the priority and / or the first flag bit to the process of the service manager. This ensures that priority can be successfully passed to the server process in various scenarios.

[0138] In some embodiments, when the electronic device replaces the second priority of the service manager with the first priority of the first application, the method further includes: the electronic device setting a first flag bit for the service manager, the first flag bit being used to indicate that the threads of the service manager run preferentially in a first thread set, the first thread set containing one or more threads with the same priority as the service manager (including threads within the service manager). In this embodiment, the first flag bit may also be referred to as the VIP flag bit.

[0139] For example, after the service manager's priority is changed to first priority, if other first-priority processes are waiting to run, the electronic device will prioritize running the service manager's process or thread because the service manager's first flag is set. This avoids the situation where the first application has to wait for other processes or threads to run while waiting for the service manager to query services.

[0140] S804: The electronic device blocks the first application and prioritizes the operation of the service manager. The electronic device queries the first service through the service manager and provides the identifier of the first service to the first application.

[0141] refer to Figure 6The following describes steps S601-S606 in the illustrated embodiment. After the process of the first application (i.e., the client process) sends a first transaction signal to the service manager (i.e., the server process), the inter-process communication driver sends a first confirmation signal to the client process. Upon receiving the first confirmation signal, the client process enters a sleep state, meaning the first application is blocked. Then, the inter-process communication driver sends a second transaction signal to the server process, which wakes up the server process, i.e., the process that prioritizes the service manager (specifically, a binder thread of the service manager). The electronic device can then query the first service through the service manager and provide the identifier of the first service to the first application via the first and second reply signals.

[0142] The electronic device queries a first service through a service manager and provides the identifier of the first service to a first application, including: the electronic device queries the identifier of the first service based on the name of the first service through the service manager; the electronic device sends a first reply signal to the inter-process communication driver through a second communication thread, the first reply signal including the identifier of the first service; the electronic device sends a second reply signal to the first communication thread through the inter-process communication driver, the second reply signal including the identifier of the first service, and the first communication thread is awakened from a sleep state after receiving the second reply signal.

[0143] S805, the electronic device restores the priority of the service manager to the second priority and continues to run the first application based on the first service.

[0144] After the electronic device returns the query results of the first service to the first application through the service manager, it can restore the original priority of the service manager. If the electronic device has set a first flag for the service manager, it will also remove the first flag from the service manager when restoring the original priority of the server.

[0145] In some embodiments, the electronic device continues to run the first application based on the first service, including: the electronic device sending one or more parameters and transmitting the first priority of the first application to the third communication thread of the second application through the first communication thread of the first application, the third communication thread being used to provide the first service through inter-process communication, the one or more parameters including parameters required to run the first service, the first priority of the first application being higher than the third priority of the second application; the electronic device replacing the third priority of the second application with the first priority of the first application; the electronic device blocking the first application and running the second application first, the electronic device running the first service through the second application based on one or more parameters; the electronic device returning the running result of the first service to the first application, and continuing to run the first application based on the running result.

[0146] The second application can be any application that provides the first service; it can be a third-party application, a system-level application, etc. After obtaining the identifier of the first service, the first application can invoke the first service through the second application. At this point... Figure 6 Taking the cross-process communication (CPC) process shown as an example, the process of the first application acts as the client process, and the process of the second application acts as the server process. The first communication thread of the first application (i.e., the binder thread of the first application) can send the identifier of the first service and one or more parameters for using the first service to the CPC driver. These identifiers and parameters can be carried in the BC_TRANSACTION signal. The CPC driver can then send this content to the third communication thread of the second application (i.e., the binder thread of the second application) via the BRTRANSACTION signal. The second application can run the first service based on one or more parameters and then return the result of the first service to the CPC driver via the BC_REPLY signal. The CPC driver can then return the result of the first service to the client's binder thread via the BR_REPLY signal. This process ensures the independence of the memory space of each application and provides an interface for applications to obtain one or more services, thereby helping applications to implement more functions and improving the user experience.

[0147] In some embodiments, before the electronic device restores the priority of the service manager to the second priority, the method further includes: the electronic device sending a second acknowledgment signal to a second communication thread through an inter-process communication driver, the second acknowledgment signal being used to indicate that the inter-process driver has received a first reply signal, and the second communication thread entering a sleep state after receiving the second acknowledgment signal.

[0148] refer to Figure 6 In the illustrated embodiment, after the inter-process communication driver executes step S605, the server process enters a sleep state. At this time, the inter-process communication driver calls `trace_android_vh_binder_transaction_received` to restore the priority of the service manager.

[0149] The apparatus for performing the above method provided in the embodiments of this application will now be described. Figure 9 As shown, Figure 9 This is a schematic diagram of a priority passing device 900 provided in an embodiment of this application. The priority passing device 900 may be an electronic device in the embodiments of this application, or a chip or chip system within an electronic device.

[0150] like Figure 9As shown, the priority transmission device 900 may include a control unit 901, a service acquisition unit 902, and a service management unit 903.

[0151] The control unit 901 is used to run the service acquisition unit 902, where the first priority of the service acquisition unit 902 is higher than the second priority of the service management unit 903. The service acquisition unit 902 includes code that calls a first service. The service management unit 903 is used to register one or more services for invocation, with the preconditions for invocation including querying and obtaining the identifier of the first service from the service management unit 903. When the control unit 901 runs the code that calls the first service, the service acquisition unit 902 queries the service management unit 903 for the identifier of the first service and transmits its first priority. The control unit 901 replaces the second priority of the service management unit 903 with the first priority of the service acquisition unit 902. The control unit 901 is also used to block the service acquisition unit 902 and prioritize the operation of the service management unit 903, which in turn queries the first service and provides the identifier of the first service to the service acquisition unit 902. The control unit 901 is also used to restore the priority of the service management unit 903 to its second priority and continue running the service acquisition unit 902 based on the first service.

[0152] In some embodiments, the control unit 901 is further configured to set a first flag bit on the service management unit 903 when the second priority of the service management unit 903 is replaced with the first priority of the service acquisition unit 902. The first flag bit is used to indicate that the service management unit 903 runs preferentially in a first set, the first set containing one or more processing units with the same priority as the service management unit 903.

[0153] In some embodiments, the priority transmission device 900 further includes a service providing unit 904. The control unit 901 continues to run the service acquisition unit 902 based on the first service, including: the service acquisition unit 902 sending one or more parameters to the service providing unit 904 and transmitting the first priority of the service acquisition unit 902; the service providing unit 904 providing the first service; the one or more parameters including parameters required to run the first service; the first priority of the service acquisition unit 902 being higher than the third priority of the service providing unit 904; the control unit 901 replacing the third priority of the service providing unit 904 with the first priority of the service acquisition unit 902; the control unit 901 blocking the service acquisition unit 902 and prioritizing the service providing unit 904; the service providing unit 904 running the first service based on one or more parameters; the service providing unit 904 returning the running result of the first service to the service acquisition unit 902; and the control unit 901 continuing to run the service acquisition unit 902 based on the running result.

[0154] Figure 10 This is a schematic diagram of the structure of a chip provided in an embodiment of this application. For example... Figure 10 As shown, chip 1000 includes one or more (including two) processors 1001, communication lines 1002 and communication interfaces 1003. Optionally, chip 1000 also includes a memory 1004.

[0155] In some implementations, memory 1004 stores elements such as executable modules or data structures, or subsets thereof, or extended sets thereof.

[0156] The methods described in the embodiments of this application can be applied to or implemented by the processor 1001. The processor 1001 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuit in the hardware of the processor 1001 or by instructions in the form of software. The processor 1001 may be a general-purpose processor (e.g., a microprocessor or conventional processor), a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gates, transistor logic devices, or discrete hardware components. The processor 1001 can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application.

[0157] The steps of the method disclosed in the embodiments of this application can be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software modules can be located in mature storage media in the art, such as random access memory, read-only memory, programmable read-only memory, or electrically erasable programmable read-only memory (EEPROM). This storage medium is located in memory 1004, and processor 1001 reads information from memory 1004 and, in conjunction with its hardware, completes the steps of the above method.

[0158] The processor 1001, memory 1004 and communication interface 1003 can communicate with each other via communication line 1002.

[0159] In the above embodiments, the instructions stored in the memory for execution by the processor can be implemented in the form of a computer program product. This computer program product can be pre-written into the memory, or it can be downloaded and installed into the memory as software.

[0160] This application also provides a computer program product comprising one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a server or data center that integrates one or more available media. For example, available media may include magnetic media (e.g., floppy disk, hard disk, or magnetic tape), optical media (e.g., digital versatile disc (DVD)), or semiconductor media (e.g., solid-state disk (SSD)).

[0161] This application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program or instructions. When the computer program or instructions are executed by a processor, they implement the methods described above. The methods described in the above embodiments can be implemented wholly or partially by software, hardware, firmware, or any combination thereof. If implemented in software, the functionality can be stored as one or more instructions or code on or transmitted over the computer-readable medium. The computer-readable medium can include computer storage media and communication media, and can also include any medium that can transfer a computer program from one place to another. The storage medium can be any target medium accessible by a computer.

[0162] As one possible design, computer-readable media may include compact disc read-only memory (CD-ROM), RAM, ROM, EEPROM, or other optical disc storage; computer-readable media may include disk storage or other disk storage devices. Furthermore, any connecting cable may also be appropriately referred to as computer-readable media. For example, if software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave, then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of media. As used herein, disks and optical discs include optical discs (CD), laser discs, optical discs, DVDs, floppy disks, and Blu-ray discs, where disks typically reproduce data magnetically, while optical discs optically reproduce data using lasers. Combinations of the above should also be included within the scope of computer-readable media.

[0163] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0164] As used in the above embodiments, depending on the context, the term "when..." can be interpreted as meaning "if...", "after...", "in response to determining...", or "in response to detecting...". Similarly, depending on the context, the phrase "when determining..." or "if (the stated condition or event) is interpreted as meaning "if determining...", "in response to determining...", "when (the stated condition or event) is detected", or "in response to detecting (the stated condition or event)".

[0165] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0166] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A priority passing method, characterized in that, The method is applied to an electronic device, the software system of which includes a first application and a service manager, and the method includes: The electronic device runs the first application, the first application has a first priority higher than the service manager's second priority, the first application includes code that calls a first service, the service manager is used to register one or more services for the application to call, and the precondition for the call includes querying and obtaining the identifier of the first service from the service manager; When the electronic device runs to the code that calls the first service, the electronic device queries the second communication thread of the service manager through the first communication thread of the first application for the identifier of the first service and passes the first priority of the first application. The electronic device replaces the second priority of the service manager with the first priority of the first application; The electronic device blocks the first application and prioritizes running the service manager. The electronic device queries the first service through the service manager and provides the first service's identifier to the first application. The electronic device restores the service manager's priority to the second priority and continues to run the first application based on the first service.

2. The method according to claim 1, characterized in that, The first communication thread is used to invoke one or more services through cross-process communication.

3. The method according to claim 1 or 2, characterized in that, The second communication thread is used to provide a second service through inter-process communication, and the second service is used to register, query and invoke one or more services that can be invoked by the application.

4. The method according to any one of claims 1-3, characterized in that, When the electronic device replaces the second priority of the service manager with the first priority of the first application, the method further includes: The electronic device sets a first flag bit for the service manager. The first flag bit is used to indicate that the second communication thread runs preferentially in a first thread set, which contains one or more threads with the same priority as the service manager.

5. The method according to any one of claims 1-4, characterized in that, The electronic device continues to run the first application based on the first service, including: The electronic device sends one or more parameters and transmits the first priority of the first application to the third communication thread of the second application through the first communication thread of the first application. The third communication thread is used to provide the first service through inter-process communication. The one or more parameters include parameters required to run the first service. The first priority of the first application is higher than the third priority of the second application. The electronic device replaces the third priority of the second application with the first priority of the first application; The electronic device blocks the first application and prioritizes the second application. The electronic device then runs the first service through the second application based on one or more parameters. The electronic device returns the running result of the first service to the first application, and continues to run the first application based on the running result.

6. The method according to any one of claims 1-5, characterized in that, The software system of the electronic device also includes an inter-process communication driver, wherein the electronic device queries the identifier of the first service from the second communication thread of the service manager through the first communication thread of the first application and passes the first priority of the first application, including: The electronic device sends a first transaction signal to the inter-process communication driver through the first communication thread. The first transaction signal contains the name of the first service, which is used to query the identifier of the first service. The first transaction signal also indicates that the priority of the service manager be replaced with the first priority. The electronic device sends a second transaction signal to the second communication thread through the inter-process communication driver. The second transaction signal contains the name of the first service. The second communication thread is awakened from a dormant state after receiving the second transaction signal.

7. The method according to claim 6, characterized in that, When the electronic device sends a first transaction signal to the inter-process communication driver through the first communication thread, the method includes: The electronic device transmits a first work item parameter, a first process parameter, and a first thread parameter to the inter-process communication driver through the first communication thread. The first work item parameter indicates a transaction that queries the identifier of the first service, the first process parameter indicates a process for executing the first transaction, and the first thread parameter indicates a thread for executing the first transaction. If the electronic device determines that the first thread parameter is not null, the electronic device performs the first enqueue operation and the first priority passing operation; if the electronic device determines that the first thread parameter is null, the electronic device only performs the first priority passing operation. The first enqueue operation includes: adding the first transaction to the first queue of the thread indicated by the first thread parameter, and then replacing the priority of the process indicated by the first process parameter with the first priority, wherein the first queue is used to store one or more transactions to be executed; The first priority transfer operation includes: determining whether the process indicated by the first process parameter is the process of the service manager; if the process indicated by the first process parameter is the process of the service manager, then the electronic device replaces the priority of the service manager with the first priority.

8. The method according to claim 6 or 7, characterized in that, The electronic device blocks the first application, including: The electronic device sends a first confirmation signal to the first communication thread through the inter-process communication driver. The first confirmation signal is used to indicate that the inter-process communication driver has received the first transaction signal. The electronic device causes the first communication thread of the first application to sleep.

9. The method according to claim 8, characterized in that, The electronic device queries the first service through the service manager and provides the identifier of the first service to the first application, including: The electronic device queries the identifier of the first service based on the name of the first service through the service manager; The electronic device sends a first reply signal to the inter-process communication driver through the second communication thread, and the first reply signal includes the identifier of the first service. The electronic device sends a second reply signal to the first communication thread through the inter-process communication driver. The second reply signal includes the identifier of the first service. The first communication thread is awakened from a sleep state after receiving the second reply signal.

10. The method according to claim 9, characterized in that, Before the electronic device restores the service manager's priority to the second priority, the method further includes: The electronic device sends a second confirmation signal to the second communication thread through the inter-process communication driver. The second confirmation signal is used to indicate that the inter-process driver has received the first reply signal. After receiving the second confirmation signal, the second communication thread enters a sleep state.

11. An electronic device, characterized in that, The electronic device includes: a display screen, a memory, and a processor coupled to the memory; the display screen is used to display a user interface, the memory stores a computer program, and the processor executes the computer program to cause the electronic device to implement the method as described in any one of claims 1-10.

12. A computer-readable storage medium storing computer instructions, characterized in that, When the computer instructions are executed on the processor, they cause the method as described in any one of claims 1-10 to be performed.

13. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the method of any one of claims 1-10.

Images