Service arbitration method and device, electronic equipment and storage medium

Abstract

The invention provides a service arbitration method and device, electronic equipment and a storage medium, and the method comprises the steps: obtaining a current call request, the call request has a priority, a control instruction and a service state control demand, and the service state control demand comprises an occupation demand or a release demand; the occupancy demand comprises a holding type occupancy demand or a non-holding type occupancy demand, comparing the current calling request with the calling requests in the execution queue, and updating the execution queue, so that the called service reads the calling request with the highest priority from the updated execution queue and executes the control instruction of the calling request, and the calling request is sent to the called service. According to the non-holding type occupancy demand or the holding type occupancy demand of the calling request, after it is determined that the control instruction of the calling request is executed, resources are released or the calling request continues to be in an occupancy state; on the premise of realizing the closed loop of service calling, the communication load is effectively reduced, the phenomenon of incoherent functions is avoided, the user experience is improved, and the development difficulty is low.

Description

Technical Field

[0001] The present application relates to the technical field of service arbitration, and particularly to a service arbitration method, apparatus, electronic device, and storage medium. Background Art

[0002] In recent years, with the rapid development of the automotive industry and the increasing diversification of user needs, the software functions of automobiles have become increasingly complex. To adapt to this trend, SOA (Service Orient Architecture) has been introduced into the automotive industry. By service-ifying the basic functions of automobiles and defining service interfaces, developers can rely on these service interfaces to implement the development of complex application functions, thereby achieving the goals of efficient development and rapid iteration of complex software. In the SOA solution, it is a common phenomenon that multiple application services call the basic service functions in the same call cycle. Therefore, how to effectively solve service call conflicts and achieve orderly and low-cost service arbitration has become the key to the SOA solution.

[0003] Currently, some service arbitration solutions determine which call requests have lower priorities, and then ask the application services whether to continue executing these lower-priority call requests through feedback information, and then judge whether to execute these lower-priority call requests based on the confirmation information of the application services. Although these arbitration solutions achieve a closed loop of service calls, they also cause a significant increase in communication load, and the re-trigger mechanism of feedback information will inevitably cause a blank period in the execution of basic service functions, and then there will be a phenomenon of discontinuous functions. For example, it may cause the headlights to flash when the scene is switched, affecting the user experience. In addition, to implement these arbitration solutions, it is necessary to design monitoring logic for service status for each application service, which not only increases the difficulty of application development but also runs counter to the goal of rapid development and iteration of SOA. Summary of the Invention

[0004] In view of the above-mentioned disadvantages of the prior art, the present application provides a service arbitration method, apparatus, electronic device, and storage medium to solve the technical problems of increased communication load, increased difficulty of application development, and discontinuous functions caused by the above service arbitration solutions.

[0005] The present application provides a service arbitration method, and the method includes: obtaining a current call request, where the call request has a corresponding priority, a control instruction of a caller, and a service status control requirement, and the service status control requirement includes an occupation requirement or a release requirement, and the occupation requirement includes a hold-type occupation requirement or a non-hold-type occupation requirement, and the hold-type occupation requirement is used for the caller to occupy the service until the caller actively releases it, and the non-hold-type occupation requirement is used for the caller to occupy the service until the control instruction of the caller is executed or the execution is aborted; by comparing the current call request with the call requests already added to the execution queue, updating the execution queue for the called service to read the call request with the highest priority from the updated execution queue, execute the control instruction of the call request with the highest priority, and determine to release the resources or continue to be in the occupied state after the control instruction of the call request with the highest priority is executed according to the non-hold-type occupation requirement or the hold-type occupation requirement of the call request with the highest priority, where updating the execution queue includes adding the current call request to the execution queue and / or deleting the call requests in the execution queue.

[0006] In an embodiment of the present application, updating the execution queue by comparing the current call request with the call requests already added to the execution queue includes: under the condition that the service status control requirement of the current call request is a hold-type occupation requirement, comparing the priority of the current call request with the call requests in the execution queue; if the priority of the current call request is higher than or equal to the priority of a call request in the execution queue, adding the current call request to the execution queue; if the priority of the current call request is lower than the priorities of all call requests in the execution queue, adding the current call request to the execution queue when there is remaining space in the execution queue.

[0007] In an embodiment of the present application, if the priority of the current call request is higher than or equal to the priority of a call request in the execution queue, adding the current call request to the execution queue includes: when the priority of the current call request is higher than or equal to the priority of the first call request in the execution queue, reading the service status control requirement of the first call request from the execution queue, where the first call request is the call request with the highest priority in the execution queue; if the service status control requirement of the first call request is a hold occupancy requirement, adding the current call request to the execution queue so that the called service pauses executing the control instruction of the first call request and starts to execute the control instruction of the current call request; if the service status control requirement of the first call request is a non-hold occupancy requirement, adding the current call request to the execution queue and deleting the first call request from the execution queue so that the called service terminates executing the control instruction of the first call request and starts to execute the control instruction of the current call request.

[0008] In an embodiment of the present application, the execution queue is updated by comparing the current call request with the call requests already added to the execution queue, including: under the condition that the service status control requirement of the current call request is a non-hold occupancy requirement, comparing the priority of the current call request with the call requests in the execution queue; if the priority of the current call request is higher than or equal to the priorities of all call requests in the execution queue, adding the current call request to the execution queue.

[0009] In an embodiment of the present application, if the priority of the current call request is higher than or equal to the priorities of all call requests in the execution queue, adding the current call request to the execution queue includes: reading the service status control requirement of the first call request from the execution queue, where the first call request is the call request with the highest priority in the execution queue; if the service status control requirement of the first call request is a hold occupancy requirement, adding the current call request to the execution queue so that the called service pauses executing the control instruction of the first call request and starts to execute the control instruction of the current call request; if the service status control requirement of the first call request is a non-hold occupancy requirement, adding the current call request to the execution queue and deleting the first call request from the execution queue so that the called service terminates executing the control instruction of the first call request and starts to execute the control instruction of the current call request.

[0010] In an embodiment of the present application, by comparing the current call request with the call requests already added to the execution queue, the execution queue is updated, including: under the condition that the service status control requirement of the current call request is a release requirement, comparing the call party identifiers of the current call request and the call requests in the execution queue, where the call request also has a corresponding call party identifier; if the call party identifier of a call request in the execution queue is the same as that of the current call request, then delete the call request from the execution queue.

[0011] In an embodiment of the present application, before comparing the priorities of the current call request and the call requests in the execution queue, the method includes: comparing the call party identifiers of the current call request and the call requests in the execution queue, where the call request also has a corresponding call party identifier; if the call party identifier of a call request in the execution queue is the same as that of the current call request, then delete the call request from the execution queue.

[0012] In an embodiment of the present application, there is also provided a service arbitration device, which includes: a data acquisition module for acquiring a current call request, where the call request has a corresponding priority, a control instruction of the call party, and a service status control requirement, and the service status control requirement includes an occupancy requirement or a release requirement, and the occupancy requirement includes a hold-type occupancy requirement or a non-hold-type occupancy requirement, and the hold-type occupancy requirement is used for the call party to occupy the service until the call party actively releases it, and the non-hold-type occupancy requirement is used for the call party to occupy the service until the control instruction of the call party is executed or the execution is aborted; an information processing module for updating the execution queue by comparing the current call request with the call requests already added to the execution queue, so that the called service reads the call request with the highest priority from the updated execution queue, executes the control instruction of the call request with the highest priority, and determines whether to release the resources or continue to be in the occupied state after the control instruction of the call request with the highest priority is executed according to the non-hold-type occupancy requirement or the hold-type occupancy requirement of the call request with the highest priority, where updating the execution queue includes adding the current call request to the execution queue and / or deleting the call requests in the execution queue.

[0013] In an embodiment of the present application, there is also provided an electronic device, which includes: one or more processors; a storage device for storing one or more programs, and when the one or more programs are executed by the one or more processors, the electronic device implements the service arbitration method as described above.

[0014] In an embodiment of the present application, a computer-readable storage medium is further provided, on which a computer program is stored. When the computer program is executed by a processor of a computer, the computer is caused to execute the service arbitration method as described above.

[0015] Advantages of the present invention: The present invention provides a service arbitration method, apparatus, electronic device, and storage medium. In this method, the occupation requirement or release requirement of the calling party for the called service is specified in the call request, and the occupation requirement is further divided into a hold-type occupation requirement and a non-hold-type occupation requirement, so that in the service arbitration process, it can be directly determined whether the current call request and the call requests in the execution queue need to be directly discarded based on the information in the call request to update the execution queue, without asking the calling party in the form of information feedback. On the premise of realizing the closed-loop of service calls, it can effectively reduce the communication load and avoid the phenomenon of discontinuous functions, improving the user experience. Moreover, the calling party does not need to design the monitoring logic for the called service, and the development difficulty is low, which meets the goal of rapid development and iteration of SOA. In addition, this method can also be applied to the function disabling scenario. The calling party only needs to set the priority of the call request to the highest and set the service status control requirement to the hold-type occupation requirement, and then the function can be disabled by continuously occupying the called service.

[0016] It should be understood that the above general description and subsequent detailed description are only exemplary and explanatory, and cannot limit the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 is a schematic diagram of a service call;

[0018] Figure 2 is a schematic diagram of the implementation environment of a service arbitration method shown in an exemplary embodiment of the present application;

[0019] Figure 3 is a flowchart of a service arbitration method shown in an exemplary embodiment of the present application;

[0020] Figure 4 is a storage and scheduling flowchart of a call request shown in a specific embodiment of the present application;

[0021] Figure 5 is a block diagram of a service arbitration apparatus shown in an exemplary embodiment of the present application;

[0022] Figure 6 shows a schematic structural diagram of a computer system of an electronic device suitable for implementing the embodiments of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0023] The following describes the implementation modes of the present application through specific examples. Those skilled in the art can easily understand the other advantages and effects of the present application from the content disclosed in this specification. The present application can also be implemented or applied through other different specific implementation modes. Various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present application. It should be noted that, without conflict, the following embodiments and the features in the embodiments can be combined with each other.

[0024] It should be noted that the diagrams provided in the following embodiments only illustrate the basic concept of the present application in a schematic manner. Therefore, only the components related to the present application are shown in the diagrams, rather than being drawn according to the number, shape, and size of the components in actual implementation. The type, quantity, and proportion of each component in actual implementation can be arbitrarily changed, and the component layout type may also be more complex.

[0025] It should be noted that in the present application, "first", "second", etc. are only used to distinguish similar objects, and are not used to limit the order or sequence of similar objects. The described "including", "having", etc. are deformations, indicating that the scope covered by the subject of the word is not exclusive except for the examples shown by the word.

[0026] It can be understood that the various numerical numbers, step numbers, etc. recorded in the present application are for the convenience of description and are not used to limit the scope of the present application. The size of the labels in the present application does not mean the sequence of execution. The execution sequence of each process should be determined by its function and internal logic.

[0027] In the following description, a large number of details are explored to provide a more thorough explanation of the embodiments of the present application. However, it is obvious to those skilled in the art that the embodiments of the present application can be implemented without these specific details. In other embodiments, well-known structures and devices are shown in the form of block diagrams rather than in detail to avoid making the embodiments of the present application difficult to understand.

[0028] Please refer to Figure 1 , Figure 1 which is a schematic diagram of service invocation. As Figure 1As shown, in the SOA solution, multiple applications (also known as application services) can initiate a require (request, i.e., a call request) to the same basic service during the same call cycle. Therefore, before the basic service executes the call request, it is necessary to perform service arbitration on each call request. How to handle service call conflicts well and achieve orderly and low-cost service arbitration is the key point of SOA. Currently, although some service arbitration solutions have achieved a closed loop of service calls through a re-trigger mechanism of feedback information, they have problems such as heavy communication load, discontinuous execution of basic service functions, and high difficulty in application development. Moreover, these solutions lack analysis of disabled situations, such as scenarios where locking operations are prohibited after a vehicle collision unlocks, or specified lights are disabled during the execution of a light dance.

[0029] To solve these problems, embodiments of the present application respectively propose a service arbitration method, a service arbitration device, an electronic device, a computer-readable storage medium, and a computer program product. The following will describe these embodiments in detail.

[0030] Please refer to Figure 2 , Figure 2 which is a schematic diagram of the implementation environment of a service arbitration method shown in an exemplary embodiment of the present application.

[0031] As Figure 2 shown, the implementation environment may include a caller 210, an arbitration module 220, and a called service 230. Among them, the caller 210 may be an application service, a basic service, or a front-end system, the called service 230 may be a basic service or an application service, the arbitration module 220 may be configured in the called service 230, or the arbitration module 220 may be independent of the called service 230 and installed in a computer device such as a microcomputer, an embedded computer, or a neural network computer. There is no limitation here. The caller 210 may send the current call request to the arbitration module 220 for the arbitration module 220 to compare the current call request with the call requests in the execution queue, and update the execution queue according to the comparison result for the called service 230 to execute the call requests in the execution queue.

[0032] Schematically, the arbitration module 220 obtains the current call request. Among them, the call request has a corresponding priority, the control instruction of the caller 210, and the service status control requirement. The service status control requirement includes an occupancy requirement or a release requirement. The occupancy requirement includes a hold-type occupancy requirement or a non-hold-type occupancy requirement. The hold-type occupancy requirement is used for the caller 210 to occupy the service until the caller 210 actively releases it. The non-hold-type occupancy requirement is used for the caller 210 to occupy the service until the control instruction of the caller 210 is executed or the execution is aborted. By comparing the current call request with the call requests already added to the execution queue, the execution queue is updated so that the called service 230 can read the call request with the highest priority from the updated execution queue, execute the control instruction of the call request with the highest priority, and determine that after the control instruction of the call request with the highest priority is executed, the resources are released or the occupied state is continued according to the non-hold-type occupancy requirement or the hold-type occupancy requirement of the call request with the highest priority. Among them, updating the execution queue includes adding the current call request to the execution queue and / or deleting the call requests in the execution queue. It can be seen that the technical solution of the embodiment of the present application clearly defines the occupancy requirement or release requirement of the caller for the called service in the call request, and divides the occupancy requirement into a hold-type occupancy requirement and a non-hold-type occupancy requirement, so that it can be directly judged whether the current call request and the call requests in the execution queue need to be directly discarded during the service arbitration process to update the execution queue, without asking the caller in the way of information feedback. On the premise of realizing the closed-loop of service calls, it can effectively reduce the communication load and avoid the phenomenon of discontinuous functions, improving the user experience. And, the caller does not need to design the monitoring logic for the called service, and the development difficulty is low, which meets the goal of rapid development and iteration of SOA. In addition, this solution can also be applied to the function disabling scenario. The caller only needs to set the priority of the call request to the highest and set the service status control requirement to the hold-type occupancy requirement, and the function can be disabled by continuously occupying the called service.

[0033] It should be noted that the service arbitration method provided by the embodiment of the present application can be specifically executed by a computer device equipped with an arbitration module 220. Correspondingly, the service arbitration device can be set in the computer device.

[0034] Please refer to Figure 3 , Figure 3 is a flowchart of a service arbitration method shown in an exemplary embodiment of the present application. This service arbitration method can be applied to Figure 2 the implementation environment shown. It should be understood that this service arbitration method can also be applicable to other exemplary implementation environments. This embodiment does not limit the implementation environment applicable to this service arbitration method.

[0035] Such as Figure 3As shown, in an exemplary embodiment, the service arbitration method at least includes steps S310 to S320, which are introduced in detail as follows:

[0036] Step S310, obtain the current call request.

[0037] In an embodiment of the present application, the arbitration module can receive in real time the call requests sent by each calling party for calling the called service, and the current call request refers to the call request currently received by the arbitration module. Among them, the arbitration module can be configured in the called service, or the arbitration module can be independent of the called service. The called service can be a basic service in SOA, and the corresponding calling party can be an application service in SOA or a basic service different from the called service. In addition, the called service can be an application service in SOA, and the corresponding calling party can be a front-end system or an application service different from the called service.

[0038] The call request has a corresponding priority, the control instruction of the calling party, and the service status control requirement. Among them, the numerical value of the priority reflects the priority of the calling party in preempting the called service. In the case of a call conflict, the called service usually gives priority to executing the call request with the highest priority; the control instruction is the specific instruction that the called service needs to execute when executing the call request, such as unlocking the car door, locking the car door, turning on the headlights, turning off the headlights, etc.; the service status control requirement includes an occupation requirement or a release requirement. The occupation requirement includes a hold-type occupation requirement or a non-hold-type occupation requirement. The hold-type occupation requirement is used for the calling party to occupy the service until the calling party actively releases it, and the non-hold-type occupation requirement is used for the calling party to occupy the service until the control instruction of the calling party is executed or the execution is aborted. Schematically, the calling party can actively release by sending a call request with a release requirement.

[0039] Generally in SOA, the state of the service includes an occupied state and an idle state. When the service is in the occupied state, it means that the service is being called and is busy, that is, the service is currently executing a call request, and a new call request needs to compete with the currently executing call request for control of the service. When the service is in the idle state, it means that the service is not currently being called and can be called immediately, that is, the service is not currently executing a call request, and the service appears to be in a controllable state. It should be noted that the service being in the idle state is not equivalent to the physical ability provided by the service being turned off. For example, the basic service of the low beam being in the idle state is not equivalent to the low beam being turned off.

[0040] To save communication resources, reduce communication load, and cover disabled function scenarios, this application divides the occupancy status of services into a maintained occupancy status and a non-maintained occupancy status, and makes the following parameter definitions for call requests used to invoke services. It is stipulated that in addition to control instructions and priorities, call requests should also include service status control requirements to represent the expected control status of the calling party for the called service, that is, the calling party expects or requests the called service to be in a maintained occupancy status, a non-maintained occupancy status, or an idle status. Schematically, the parameter of the service status control requirement in the call request Req_new can be expressed as:

[0041] Req_new.TarSt == Maintain occupancy || Non-Maintain occupancy || Release

[0042] Among them, Req_new.TarSt is the service status control requirement, that is, the expected control status of the service. Maintain occupancy is the maintained occupancy requirement, that is, the maintained occupancy status. Non-Maintain occupancy is the non-maintained occupancy requirement, that is, the non-maintained occupancy status. Release is the release requirement, that is, the idle status.

[0043] The release requirement indicates that the calling party expects or requests to control the called service to be in an idle status.

[0044] The retained occupancy requirement indicates that the caller expects to control the called service to be in the retained occupancy state. The service being in the retained occupancy state means that the service is continuously occupied by the caller, even after its control instruction has been executed, until the caller issues a call request containing a release requirement for active release, and then the service can clear the occupancy. Therefore, for a call request with a retained occupancy requirement, when it is the highest-priority call request, it will continuously occupy the called service until it receives a "release" call request from the same source, that is, a call request with a release requirement issued by the same caller; when it is interrupted by a call request with a higher priority, it can be memorized, and it will occupy the called service again when it becomes the highest-priority call request again. Therefore, its control instruction execution can be resumed after being aborted (paused). Call requests with a retained occupancy requirement can be applied to long-cycle execution instructions. After the execution of such instructions, the subsequent state needs to be concerned, and usually needs to be resumed after being interrupted. Taking the scenario of controlling a light with a physical switch as an example, after the switch is pressed, the application service can issue a call request with parameters "Req_new.TarSt == Maintain occupancy (the service status control requirement is a retained occupancy requirement), Req_new.Order == open (the control instruction is to turn on)"; when the switch is reset, the occupancy of the service needs to be released, and the application service can issue a call request with parameters "Req_new.TarSt == Release (the service status control requirement is a release requirement), Req_new.Order == close (the control instruction is to turn off)".

[0045] The non-retained occupancy requirement indicates that the caller expects to control the called service to be in the non-retained occupancy state. The service being in the non-retained occupancy state means that the service is occupied by the caller. When the caller's control instruction is executed or aborted, the service can automatically clear the occupancy without the caller having to issue a call request containing a release requirement again, reducing unnecessary communication. Therefore, for a call request with a non-retained occupancy requirement, when it is the highest-priority call request, it will occupy the called service until its control instruction is executed or aborted; when it is interrupted by a call request with a higher priority, it will be directly discarded, so its control instruction will not be resumed after being aborted. Call requests with a non-retained occupancy requirement can be applied to short-cycle execution instructions. After the execution of such instructions, the subsequent state is not concerned, and usually does not need to be resumed after being interrupted. Taking the scenario of unlocking the central control as an example, after the central control switch is pressed, the application service only needs to issue a call request with parameters "Req_new.TarSt == Non-Maintain occupancy (the service status control requirement is a non-retained occupancy requirement), Req_new.Order == unlock (the control instruction is to unlock)" once.

[0046] In addition, the call request may also have a corresponding caller identifier, and the caller identifier represents the identity information of the caller that issues the call request.

[0047] Step S320: Update the execution queue by comparing the current call request with the call requests already added to the execution queue, so that the called service reads the call request with the highest priority from the updated execution queue, executes the control instruction of the call request with the highest priority, and determines whether to release the resource or continue to be in the occupied state after the control instruction of the call request with the highest priority is executed according to the non-retainable occupancy requirement or the retainable occupancy requirement of the call request with the highest priority.

[0048] In an embodiment of the present application, an execution queue may be pre-set in the arbitration module, which is used for the arbitration module to store the call requests that need to be executed by the called service, so that the called service executes the call requests in the execution queue. By the arbitration module writing the call requests into the execution queue in the order of priority from high to low, and the called service executing the call requests in the execution queue in the order of the queue, the called service preferentially executes the call request with the highest priority in the execution queue is realized. Wherein, the called service executing the call request specifically includes: the called service executes the control instruction of the call request, and determines whether to release the resource or continue to be in the occupied state after the control instruction of the call request is executed according to the non-retainable occupancy requirement or the retainable occupancy requirement of the call request.

[0049] Determining whether to release the resource or continue to be in the occupied state after the control instruction of the call request is executed according to the non-retainable occupancy requirement or the retainable occupancy requirement of the call request includes: according to the non-retainable occupancy requirement of the call request, releasing the resource after the control instruction of the call request is executed, where releasing the resource specifically includes releasing the occupancy of the service and clearing the call request to which the control instruction that has been executed in the execution queue belongs, so as to execute the next call request in the order of the queue; or, according to the retainable occupancy requirement of the call request, continuing to be in the occupied state after the control instruction of the call request is executed, so that other call requests in the execution queue continue to wait for execution.

[0050] After receiving the current call request, the arbitration module compares the current call request with the call requests that have been added to the execution queue to update the execution queue according to the comparison result. Among them, the acquisition time or reception time of the call requests in the execution queue is earlier than the reception time or acquisition time of the current call request; comparing the current call request with the call requests in the execution queue may include comparing the priorities of the current call request and the call requests in the execution queue, and / or comparing the service status control requirements of the current call request and the call requests in the execution queue, and / or comparing the caller identifiers of the current call request and the call requests in the execution queue, which is not limited here; updating the execution queue includes adding the current call request to the execution queue and / or deleting the call requests in the execution queue.

[0051] During the execution of the call request, the called service also monitors the call requests in the execution queue. Once the call requests in the execution queue are updated, the called service will execute the call requests in the updated execution queue in the order of the queue. Since the arbitration module writes the call requests into the execution queue in the order of priority from high to low, and the called service executes the call requests in the execution queue in the order of the queue, the call request at the head of the execution queue is the call request with the highest priority, that is, the call request that the called service is currently executing. If the call request that the called service was originally executing is still at the head of the updated execution queue, the called service continues to execute the currently executing call request. If the currently executing call request is no longer at the head of the updated execution queue, the currently executing call request will be interrupted, and the called service will start executing the call request at the head of the updated execution queue.

[0052] It should be understood that after obtaining the current call request, if there is no call request in the execution queue, there is no need to compare the call requests, and the current call request can be directly added to the execution queue so that the called service can directly execute the current call request, including executing the control instructions in the current call request, and determining whether to release the resources or continue to be in the occupied state after the control instructions of the current call request are executed according to the release status, non-holding occupancy requirement or holding occupancy requirement of the current call request.

[0053] In an embodiment of the present application, the execution queue is updated by comparing the current call request with the call requests already added to the execution queue, including: under the condition that the service status control requirement of the current call request is a hold-type occupancy requirement, comparing the priorities of the current call request and the call requests in the execution queue; if the priority of the current call request is higher than or equal to the priority of a call request in the execution queue, adding the current call request to the execution queue; if the priority of the current call request is lower than the priorities of all call requests in the execution queue, adding the current call request to the execution queue when there is remaining space in the execution queue.

[0054] In this embodiment, if the service status control requirement of the current call request is a hold-type occupancy requirement, it means that the caller to which the current call request belongs expects to occupy the called service until the caller actively releases it. Based on this, the called service generally executes the current call request. Therefore, to reduce the computational amount, the priorities of the current call request and the call requests in the execution queue can be compared one by one in the order of priority until the priority of the current call request is higher than or equal to the priority of a certain call request in the execution queue, and then the current call request is added to the execution queue. Among them, if the priority of the current call request is equal to the priority of the call request with the lowest priority in the execution queue and the execution queue is full, the call request with the lowest priority is deleted from the execution queue, and the current call request is added to the execution queue.

[0055] If the priority of the current call request is lower than the priority of the call request with the lowest priority in the execution queue, due to the limited space of the execution queue, therefore, when the space of the execution queue is sufficient, the current call request can be added to the execution queue, and when the execution queue is full, the current call request can be discarded.

[0056] In a specific embodiment of the present application, if the call requests in the execution queue are stored in the order of priority from high to low, the arbitration module can compare the priorities of the current call request and each call request in the execution queue one by one from Ord[0] to Ord[n] in the order of the queue until the priority of the current call request is higher than or equal to the priority of a certain call request in the execution queue, which can be expressed as follows:

[0057] Req_new.Priority≥Ord[i].Priority

[0058] Among them, Req_new.Priority is the priority of the current call request, Ord[i].Priority is the priority of the call request at the i-th position in the execution queue, and i = 0, 1, 2,..., n.

[0059] At this time, the current call request can be added to the execution queue according to the order of priority. For example, the current call request can be inserted into the i-th position of the execution queue, and the call requests at the i-th position and after in the execution queue are shifted backward in sequence, and the overflow at the last position is discarded. The specific execution operation can be: Ord[i] = Req_new, Ord[i + 1] = Ord[i],..., Ord[n] = Ord[n - 1], where Req_new represents the current call request, and Ord[i] represents the call request at the i-th position in the execution queue, and i = 0, 1, 2,..., n.

[0060] If the priority of the current call request is lower than the priority of the call request at the last position in the execution queue, due to the limited space of the execution queue, therefore, when the space of the execution queue is sufficient, the current call request can be added to the position after the call request at the last position in the execution queue, and when the space of the execution queue is full, the current call request can be discarded.

[0061] In an embodiment of the present application, if the priority of the current call request is higher than or equal to the priority of a call request in the execution queue, adding the current call request to the execution queue includes: when the priority of the current call request is higher than or equal to the priority of the first call request in the execution queue, reading the service status control requirement of the first call request from the execution queue, where the first call request is the call request with the highest priority in the execution queue; if the service status control requirement of the first call request is a hold-type occupancy requirement, adding the current call request to the execution queue so that the called service pauses executing the control instruction of the first call request and starts to execute the control instruction of the current call request; if the service status control requirement of the first call request is a non-hold-type occupancy requirement, adding the current call request to the execution queue and deleting the first call request from the execution queue so that the called service terminates executing the control instruction of the first call request and starts to execute the control instruction of the current call request.

[0062] In this embodiment, since the first call request is the call request with the highest priority in the execution queue, therefore, the first call request is also the call request to which the control instruction currently executed by the called service belongs (that is, the call request currently executed by the called service). When the priority of the current call request is higher than or equal to the priority of the first call request, it means that the first call request no longer meets the condition of being executed because its priority is no longer the highest, and the execution of the first call request needs to be interrupted. At this time, it is necessary to further judge whether the first call request needs to continue to be executed according to the service status control requirement of the first call request.

[0063] If the service status control requirement of the first call request is a hold occupancy requirement, it means that the first call request needs to continue to be executed after being interrupted. Therefore, the current call request can be added to the execution queue, and the first call request in the execution queue is retained so that after the execution queue is updated, the called service pauses the execution of the first call request and starts to execute the current call request. Illustratively, the current call request can be added to the execution queue before the first call request.

[0064] If the service status control requirement of the first call request is a non-hold occupancy requirement, it means that the first call request does not need to continue to be executed after being interrupted. Therefore, the current call request can be added to the execution queue, and the first call request in the execution queue is deleted so that after the execution queue is updated, the called service terminates the execution of the first call request and starts to execute the current call request. Illustratively, the current call request can be added to the position of the first call request in the execution queue to overwrite the first call request.

[0065] In a specific embodiment of the present application, based on the arbitration module storing the call requests in the execution queue in the order of priority from high to low, and the called service executing the call requests in the execution queue in the order of the queue, the first call request is still the call request at the head of the execution queue, i.e., Ord[0]. Therefore, if the priority of the current call request is higher than or equal to the priority of the first call request, and the service status control requirement of the first call request is a hold occupancy requirement, the current call request can be inserted into the 0th position of the execution queue, and the call request Ord[0] at the original 0th position of the execution queue, i.e., the first call request, and the call requests after the 0th position are sequentially shifted backward, and the overflow at the end is discarded. The specific execution operation can be: Ord[0]=Req_new, Ord[1]=Ord[0], Ord[2]=Ord[1], …, Ord[i + 1]=Ord[i], …, Ord[n]=Ord[n - 1], where Req_new represents the current call request, Ord[i] represents the call request at the i-th position in the execution queue, i = 0, 1, 2, …, n, so as to realize adding the current call request to the execution queue in the order of priority from high to low. After the execution queue is updated, the first call request is located after the current call request. Based on the manner that the called service executes the call requests in the execution queue in the order of the queue, the called service will pause the execution of the first call request and start to execute the current call request.

[0066] If the priority of the current call request is higher than or equal to the priority of the first call request, and the service status control requirement of the first call request is a non-holding occupancy requirement, the current call request can be inserted into the 0th position of the execution queue, and the call request Ord[0] at the original 0th position in the execution queue, i.e., the first call request, can be overwritten. The positions of the call requests after the 0th position remain unchanged. The specific execution operation can be: Ord[0] = Req_new, Ord[1] = Ord[1], Ord[2] = Ord[2], …, Ord[i] = Ord[i], …, Ord[n] = Ord[n], where Req_new represents the current call request, Ord[i] represents the call request at the ith position in the execution queue, and i = 0, 1, 2, …, n, so as to add the current call request to the execution queue in the order of priority and delete the first call request from the execution queue. After the execution queue is updated, the first call request is no longer retained in the execution queue, and the called service will terminate the execution of the first call request and start to execute the current call request.

[0067] In another embodiment of the present application, the execution queue is updated by comparing the current call request with the call requests already added to the execution queue, including: under the condition that the service status control requirement of the current call request is a non-holding occupancy requirement, comparing the priority of the current call request with the call requests in the execution queue; if the priority of the current call request is higher than or equal to the priority of all call requests in the execution queue, the current call request is added to the execution queue.

[0068] In this embodiment, if the service status control requirement of the current call request is a non-holding occupancy requirement, it means that the calling party to which the current call request belongs only expects to occupy the called service until the control instruction of the calling party is executed or aborted. Based on this, the called service will execute the current call request only when the priority of the current call request is higher than all call requests in the execution queue. Therefore, to reduce the computational complexity, it is only necessary to compare the priority of the current call request with the call request with the highest priority in the execution queue. If the priority of the current call request is higher than or equal to the priority of the call request with the highest priority, it means that the priority of the current call request is higher than or equal to the priority of all call requests in the execution queue, and the current call request is added to the execution queue; otherwise, the current call request can be discarded.

[0069] In a specific embodiment of the present application, if the call requests in the execution queue are stored in the order of priority from high to low, the arbitration module can compare the priority of the current call request with the call request Ord[0] at the head of the execution queue, and determine whether the comparison result satisfies the following conditions:

[0070] Req_new.Priority ≥ Ord[0].Priority

[0071] Among them, Req_new.Priority is the priority of the current call request, and Ord[0].Priority is the priority of the call request at the 0th position in the execution queue. If satisfied, the current call request can be added to the execution queue in the order of priority from high to low. Otherwise, the current call request is discarded.

[0072] In an embodiment of the present application, if the priority of the current call request is higher than or equal to the priorities of all call requests in the execution queue, the current call request is added to the execution queue, including: reading the service status control requirement of the first call request from the execution queue, where the first call request is the call request with the highest priority in the execution queue; if the service status control requirement of the first call request is a hold occupancy requirement, the current call request is added to the execution queue so that the called service pauses executing the control instruction of the first call request and starts executing the control instruction of the current call request; if the service status control requirement of the first call request is a non-hold occupancy requirement, the current call request is added to the execution queue and the first call request is deleted from the execution queue so that the called service terminates executing the control instruction of the first call request and starts executing the control instruction of the current call request.

[0073] In this embodiment, when the priority of the current call request is higher than or equal to the priorities of all call requests in the execution queue, the priority of the current call request is also higher than or equal to the priority of the first call request in the execution queue. At this time, since the priority of the first call request is no longer the highest and no longer meets the condition of being executed, the execution of the first call request needs to be interrupted, and it is necessary to further determine whether the first call request needs to continue to be executed according to the service status control requirement of the first call request.

[0074] If the service status control requirement of the first call request is a hold occupancy requirement, it means that the first call request needs to continue to be executed after being interrupted. Therefore, the current call request can be added to the execution queue, and the first call request in the execution queue is retained so that after the execution queue is updated, the called service pauses executing the first call request and starts executing the current call request. Schematically, the current call request can be added before the first call request in the execution queue.

[0075] If the service status control requirement of the first call request is a non-retained occupancy requirement, it means that the first call request does not need to continue execution after being interrupted. Therefore, the current call request can be added to the execution queue, and the first call request in the execution queue can be deleted, so that after the execution queue is updated, the called service terminates the execution of the first call request and starts to execute the current call request. Schematically, the current call request can be added to the position of the first call request in the execution queue to overwrite the first call request.

[0076] In a specific embodiment of the present application, based on the condition that the arbitration module stores call requests in the execution queue in the order of priority from high to low, and the called service executes the call requests in the execution queue in the order of the queue, the first call request is still the call request at the head of the execution queue, that is, Ord[0]. Therefore, if the priority of the current call request is higher than or equal to the priority of the first call request, and the service status control requirement of the first call request is a retained occupancy requirement, the current call request can be inserted into the 0th position of the execution queue, and the call request Ord[0] at the original 0th position in the execution queue, that is, the first call request and the call requests after the 0th position, are shifted backward in sequence, and the overflow at the end is discarded. The specific execution operation can be: Ord[0]=Req_new, Ord[1]=Ord[0], Ord[2]=Ord[1], …, Ord[i + 1]=Ord[i], …, Ord[n]=Ord[n - 1], where Req_new represents the current call request, Ord[i] represents the call request at the ith position in the execution queue, i = 0, 1, 2, …, n, so as to add the current call request to the execution queue in the order of priority from high to low. After the execution queue is updated, the first call request is located after the current call request. Based on the way that the called service executes the call requests in the execution queue in the order of the queue, the called service will suspend the execution of the first call request and start to execute the current call request.

[0077] If the priority of the current call request is higher than or equal to the priority of the first call request, and the service state control requirement of the first call request is a non-holding occupation requirement, the current call request can be inserted into the 0th position of the execution queue, and overwrite the original 0th call request Ord[0] in the execution queue, that is, the first call request, and the position of the call request after the 0th position remains unchanged. The specific execution operation can be: Ord[0] = Req_new, Ord[1] = Ord[1], Ord[2] = Ord[2], ..., Ord[i] = Ord[i], ..., Ord[n] = Ord[n], where Req_new represents the current call request, Ord[i] represents the i-th call request in the execution queue, i = 0, 1, 2, ..., n, so as to add the current call request to the execution queue in the order of priority and delete the first call request from the execution queue. After the execution queue is updated, the first call request is no longer retained in the execution queue, and the called service will terminate the execution of the first call request and start executing the current call request.

[0078] In another embodiment of the present application, the execution queue is updated by comparing the current call request with the call requests that have been added to the execution queue, including: under the condition that the service status control requirement of the current call request is a release requirement, comparing the caller identification of the current call request with the call requests in the execution queue, wherein the call request also has a corresponding caller identification; if the caller identification of a call request in the execution queue is the same as the caller identification of the current call request, deleting the call request from the execution queue.

[0079] In this embodiment, if the service state control requirement of the current call request is a release requirement, it means that the caller to which the current call request belongs expects to release the occupation of the service. Based on this, the call request with the same caller identifier as the current call request can be matched from the execution queue by comparing the caller identifier as the same-source call request, and the same-source call request is deleted from the execution queue. This solution can be applied to the release scenario after the function is disabled. For example, after the caller continues to occupy the called service to achieve function disabling by issuing a call request with the highest priority and a retention type occupation requirement, it then issues a call request with a release requirement so that the arbitration module deletes the same-source call request in the execution queue to release the occupation of the called service and achieve the release of function disabling. Of course, this solution can also be applied to other scenarios, and the scenarios to which this solution can be applied are not limited here.

[0080] Schematically, taking the call request at the i-th position in the execution queue as a homologous call request, the deletion operation for it can be: Ord[0]=Ord[0], Ord[1]=Ord[1], …, Ord[i]=Ord[i + 1], Ord[i + 1]=Ord[i + 2], …, Ord[n]=default value, where Ord[i] represents the call request at the i-th position in the execution queue, and i = 0, 1, 2, …, n.

[0081] In an embodiment of the present application, if the caller identifier of a call request in the execution queue is the same as the caller identifier of the current call request, after deleting the call request from the execution queue, the method includes: if there is no call request in the execution queue, adding the current call request to the execution queue so that the called service executes the current call request, and determining to release resources after the control instruction of the current call request is executed according to the release requirement of the current call request; if there is still at least one call request in the execution queue, discarding the current call request.

[0082] In an embodiment of the present application, before comparing the priorities of the current call request and the call requests in the execution queue, the method includes: comparing the caller identifiers of the current call request and the call requests in the execution queue, where the call request also has a corresponding caller identifier; if the caller identifier of a call request in the execution queue is the same as the caller identifier of the current call request, deleting the call request from the execution queue.

[0083] This embodiment can ensure the freshness of the call requests issued by the same caller by clearing the homologous call requests in the execution queue whose caller identifiers are the same as those of the current call request, so as to ensure that the called service executes the latest call request of the same caller, thereby providing more timely and accurate services. The deletion operation of the homologous call request can refer to the description in the foregoing embodiment and will not be elaborated here.

[0084] In an embodiment of the present application, if the caller identifier of a call request in the execution queue is the same as the caller identifier of the current call request, after deleting the call request from the execution queue, the method includes: if there is no call request in the execution queue, adding the current call request to the execution queue so that the called service executes the current call request, and determining to release resources or continue to be in the occupied state after the control instruction of the current call request is executed according to the non-retained occupancy requirement or retained occupancy requirement of the current call request; if there is still at least one call request in the execution queue, comparing the priorities of the current call request and the call requests in the execution queue.

[0085] Based on the above embodiments, it can be understood that in addition to implementing the priority comparison of call requests, the arbitration module also adds two parts: call request storage and call request scheduling. By setting a multi-dimensional data queue with a length of n as the execution queue, the call requests of callers such as application services are stored in the execution queue. The call requests in the execution queue will be sorted from high to low according to the priority. The call request Ord[0] at the 0th position has the highest priority, indicating that the called service is currently executing this call request. The call requests after Ord[0] in the execution queue, namely Ord[1], Ord[2], …, Ord[n], are call requests to be executed by the called service. Please refer to Figure 4 , Figure 4 which is the storage and scheduling flowchart of call requests shown in a specific embodiment of the present application. As Figure 4 shown, the process of the arbitration module for storing and scheduling call requests is as follows:

[0086] Receive a new call request; determine whether the new call request is a release request, that is, determine whether the new call request is a call request with a release requirement; if the new call request is a release request, determine the homologous call request in the execution queue according to the caller identifier of the new call request and clear it; if the new call request is not a release request, determine whether there is a homologous call request in the execution queue according to the caller identifier of the new call request. If there is a homologous call request in the execution queue, first clear the homologous call request and then add the new call request to the execution queue. If there is no homologous call request in the execution queue, the new call request can be directly added to the execution queue.

[0087] Figure 4 For the detailed process of the specific embodiment shown, please refer to the descriptions in the foregoing embodiments, and details will not be repeated here.

[0088] The solution of the present application can be applied to basic services to arbitrate call requests to handle call conflicts of different application services in the same operation cycle, and can comprehensively cover the arbitration scenario, meeting special scenarios such as multi-application service same-cycle calls and function disabling. The solution of the present application will be described below through two specific application scenarios.

[0089] Scenario 1: Function Disabling. In the existing solutions, adding a disabling function requires modifying the logic of the underlying service and cannot be achieved only by extending the application. However, with this application, the calling party only needs to send a calling request with the highest priority and a hold-type occupancy requirement to maintain continuous occupancy of the called service, and then the function disabling can be realized. For example, if it is necessary to disable a certain light, the application service can send a calling request with parameters "Req_new.TarSt == Maintain occupancy (the service status control requirement is a hold-type occupancy requirement), Req_new.Order == close (the control instruction is to close), APP.ID == 0x1 (the calling party identifier is 0x1), APP.Priority == 0x10 (the priority is 0x10)" to the basic service. Any calling request with a priority lower than this calling request will not be executed, thus realizing the function disabling. Among them, the smaller the value of the priority, the higher the priority.

[0090] Scenario 2: Turn signal control. When the left turn signal function is triggered, the switch will not self-reset. Therefore, after such a call request is sent, it needs to continuously occupy the resource. Even if it is preempted by a call request with a higher priority, such as the hazard warning light, as long as the switch is not reset, the call request for the left turn signal needs to continue to be executed after the call request with the higher priority is completed. To handle this scenario, the existing solution requires designing a continuous monitoring logic for the basic service in the application service. After identifying that the basic service has completed the call request for the hazard warning light with a higher priority and the service is in an idle state, the application service then sends the call request for the turn signal. This approach not only increases the logical complexity of the application service development but also increases the communication load. To minimize the "idle window" of instruction switching, it is also required that the operating cycle of the application service be as small as possible, which in turn increases the controller load. However, with the solution of this application, the application service of the turn signal only needs to send a call request with parameters "Req_new.TarSt == Maintain occupancy (the service status control requirement is a maintained occupancy requirement), Req_new.Order == open (the control instruction is to turn on), APP.ID == 0x1 (the caller identifier is 0x1), APP.Priority == 0x100 (the priority is 0x100)" when the turn lever is turned to the left. When the lever is reset, the application service of the turn signal then sends a call request with parameters "Req_new.TarSt == Release (the service status control requirement is a release requirement), Req_new.Order == close (the control instruction is to turn off), APP.ID == 0x1 (the caller identifier is 0x1), APP.Priority == 0x100 (the priority is 0x100)". Therefore, application developers only need to focus on the function scenario itself and do not need to consider the coupling interaction with other functions, greatly reducing the development difficulty of the application function, saving communication overhead, and also enabling a "zero idle window" smooth transition of instructions.

[0091] Please refer to Figure 5 , Figure 5 which is a block diagram of a service arbitration device shown in an exemplary embodiment of this application. This device can be applied to Figure 2 the implementation environment shown, and is specifically configured in a computer device equipped with an arbitration module 220. This device can also be applicable to other exemplary implementation environments and is specifically configured in other devices. This embodiment does not limit the implementation environment applicable to this device.

[0092] As Figure 5As shown, the exemplary service arbitration device includes a data acquisition module 510 configured to obtain a current call request. The call request has a corresponding priority, a control instruction of the calling party, and a service status control requirement. The service status control requirement includes an occupation requirement or a release requirement. The occupation requirement includes a hold-type occupation requirement or a non-hold-type occupation requirement. The hold-type occupation requirement is for the calling party to occupy the service until the calling party actively releases it. The non-hold-type occupation requirement is for the calling party to occupy the service until the control instruction of the calling party is executed or the execution is aborted. An information processing module 520 is configured to update the execution queue by comparing the current call request with the call requests already added to the execution queue, so that the called service can read the call request with the highest priority from the updated execution queue, execute the control instruction of the call request with the highest priority, and determine whether to release the resources or continue to be in the occupied state after the control instruction of the call request with the highest priority is executed according to the non-hold-type occupation requirement or the hold-type occupation requirement of the call request with the highest priority. Updating the execution queue includes adding the current call request to the execution queue and / or deleting call requests in the execution queue.

[0093] In this embodiment, the data acquisition module 510 can be an in-vehicle communication device such as a data receiver or a T-Box. The information processing module 520 can be an MCU (Microcontroller Unit), an ECU (Electronic Control Unit), etc. In addition, the data acquisition module 510 can also be an input interface of the information processing module 520, and no limitation is imposed here. Schematically, the data acquisition module 510 and the information processing module 520 can be integrated in a chip such as an MCU or an ECU where the called service is located.

[0094] It should be noted that the service arbitration device provided in the above embodiment and the service arbitration method provided in the above embodiment belong to the same concept. The specific manners in which each module and unit perform operations have been described in detail in the method embodiment, and will not be elaborated here. In practical applications, the service arbitration device provided in the above embodiment can, according to needs, allocate the above functions to different functional modules, that is, divide the internal structure of the device into different functional modules to complete all or part of the functions described above. No limitation is imposed here either.

[0095] This embodiment also provides an electronic device, including: one or more processors; a storage device configured to store one or more programs. When the one or more programs are executed by the one or more processors, the electronic device implements the service arbitration method provided in each of the above embodiments.

[0096] Please refer to Figure 6 , Figure 6The figure shows a schematic structural diagram of a computer system of an electronic device suitable for implementing the embodiments of the present application. It should be noted that Figure 6 The computer system 600 of the shown electronic device is only an example and should not impose any limitations on the functions and usage scope of the embodiments of the present application.

[0097] As Figure 6 shown, the computer system 600 includes a central processing unit (CPU) 601, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 602 or the program loaded from the storage section 608 into the random access memory (RAM) 603, such as executing the method described in the above embodiments. In the RAM 603, various programs and data required for system operation are also stored. The CPU 601, ROM 602, and RAM 603 are connected to each other via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0098] The following components are connected to the input / output interface 605: an input section 606 including a keyboard, a mouse, etc.; an output section 607 including, for example, a cathode ray tube (CRT), a liquid crystal display (LCD), etc. and a speaker, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN (Local Area Network) card, a modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the input / output interface 605 as required. A removable medium 611, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 610 as required so that the computer program read from it can be installed into the storage section 608 as required.

[0099] Specifically, according to the embodiments of the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments of the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a computer program for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication section 609 and / or installed from the removable medium 611. When the computer program is executed by the central processing unit 601, various functions defined in the system of the present application are executed.

[0100] It should be noted that the computer-readable medium shown in the embodiments of the present application may be a computer-readable signal medium, a computer-readable storage medium, or any combination of the two. A computer-readable storage medium may be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the above. More specific examples of the computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, which carries a computer-readable computer program. Such a propagated data signal may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The computer program contained on the computer-readable medium may be transmitted by any appropriate medium, including but not limited to: wireless, wired, etc., or any suitable combination of the above.

[0101] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architectures, functions, and operations of systems, methods, and computer program products according to various embodiments of the present application. Among them, each block in the flowchart or block diagram may represent a module, a program segment, or a part of code, and the above module, program segment, or part of code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than marked in the accompanying drawings. For example, two consecutive blocks shown may actually be executed substantially in parallel, and they may sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each block in the block diagram or flowchart, and the combination of blocks in the block diagram or flowchart, may be implemented by a dedicated hardware-based system for performing the specified functions or operations, or may be implemented by a combination of dedicated hardware and computer instructions.

[0102] The units involved in the embodiments described in this application can be implemented in software or in hardware, and the described units can also be provided in a processor. Among them, the names of these units do not, in some cases, constitute a limitation on the units themselves.

[0103] Another aspect of this application also provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor of a computer, the computer is caused to execute the service arbitration method as described above. The computer-readable storage medium can be included in the electronic device described in the above embodiments, or can exist alone without being assembled into the electronic device.

[0104] Another aspect of this application also provides a computer program product or a computer program. The computer program product or the computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the service arbitration method provided in the above various embodiments.

[0105] The above embodiments are only used to exemplarily illustrate the principles and effects of this application, rather than to limit this application. Any person familiar with this technology can modify or change the above embodiments without departing from the spirit and scope of this application. Therefore, all equivalent modifications or changes completed by those with ordinary knowledge in the technical field without departing from the spirit and technical ideas disclosed in this application should still be covered by the claims of this application.

Claims

1. A service arbitration method, characterized in that: The method comprises: Obtaining a current call request, wherein the call request has a corresponding priority, a control instruction of the caller, and a service status control requirement, wherein the service status control requirement includes an occupation requirement or a release requirement, wherein the occupation requirement includes a retention type occupation requirement or a non-retention type occupation requirement, wherein the retention type occupation requirement is used for the caller to occupy the service until the caller actively releases the service, and the non-retention type occupation requirement is used for the caller to occupy the service until the control instruction of the caller is executed or the execution is terminated; By comparing the current call request with the call request that has been added to the execution queue, the execution queue is updated so that the called service can read the call request with the highest priority from the updated execution queue, execute the control instruction of the call request with the highest priority, and determine whether to release resources or continue to occupy them after the control instruction of the call request with the highest priority is executed based on the non-holding occupancy requirement or the holding occupancy requirement of the call request with the highest priority, wherein updating the execution queue includes adding the current call request to the execution queue and / or deleting the call request in the execution queue.

2. The service arbitration method according to claim 1, characterized in that: By comparing the current call request with the call requests that have been added to the execution queue, the execution queue is updated, including: Under the condition that the service state control requirement of the current call request is a holding type occupancy requirement, comparing the priority of the current call request with the call requests in the execution queue; If the priority of the current call request is higher than or equal to the priority of a call request in the execution queue, adding the current call request to the execution queue; If the priority of the current call request is lower than the priorities of all call requests in the execution queue, then if there is remaining space in the execution queue, the current call request is added to the execution queue.

3. The service arbitration method according to claim 2, characterized in that: If the priority of the current call request is higher than or equal to the priority of a call request in the execution queue, adding the current call request to the execution queue includes: When the priority of the current call request is higher than or equal to the priority of the first call request in the execution queue, reading the service state control requirement of the first call request from the execution queue, wherein the first call request is the call request with the highest priority in the execution queue; If the service state control requirement of the first call request is a hold type occupancy requirement, adding the current call request to the execution queue so that the called service suspends the execution of the control instructions of the first call request and starts to execute the control instructions of the current call request; If the service status control requirement of the first call request is a non-holding occupancy requirement, the current call request is added to the execution queue and the first call request is deleted from the execution queue, so that the called service terminates executing the control instructions of the first call request and starts executing the control instructions of the current call request.

4. The service arbitration method according to claim 1, characterized in that: By comparing the current call request with the call requests that have been added to the execution queue, the execution queue is updated, including: Under the condition that the service state control requirement of the current call request is a non-holding type occupation requirement, comparing the priority of the current call request with the call requests in the execution queue; If the priority of the current call request is higher than or equal to the priority of all call requests in the execution queue, the current call request is added to the execution queue.

5. The service arbitration method according to claim 4, characterized in that: If the priority of the current call request is higher than or equal to the priority of all call requests in the execution queue, adding the current call request to the execution queue includes: Reading the service state control requirement of the first call request from the execution queue, wherein the first call request is the call request with the highest priority in the execution queue; If the service state control requirement of the first call request is a hold type occupancy requirement, adding the current call request to the execution queue so that the called service suspends the execution of the control instructions of the first call request and starts to execute the control instructions of the current call request; If the service status control requirement of the first call request is a non-holding occupancy requirement, the current call request is added to the execution queue and the first call request is deleted from the execution queue, so that the called service terminates executing the control instructions of the first call request and starts executing the control instructions of the current call request.

6. The service arbitration method according to claim 1, characterized in that: By comparing the current call request with the call requests that have been added to the execution queue, the execution queue is updated, including: Under the condition that the service state control requirement of the current call request is a release requirement, comparing the caller identification of the current call request with the call requests in the execution queue, wherein the call request also has a corresponding caller identification; If the caller identifier of a call request in the execution queue is the same as the caller identifier of the current call request, the call request is deleted from the execution queue.

7. The service arbitration method according to any one of claims 2 or 4, characterized in that: Before comparing the priorities of the current call request and the call requests in the execution queue, the method includes: Comparing the caller identification of the current call request with the call requests in the execution queue, wherein the call request also has a corresponding caller identification; If the caller identifier of a call request in the execution queue is the same as the caller identifier of the current call request, the call request is deleted from the execution queue.

8. A service arbitration device, characterized in that: The device comprises: A data acquisition module is used to obtain a current call request, wherein the call request has a corresponding priority, a control instruction of the caller, and a service status control requirement, wherein the service status control requirement includes an occupation requirement or a release requirement, wherein the occupation requirement includes a retention type occupation requirement or a non-retention type occupation requirement, wherein the retention type occupation requirement is used for the caller to occupy the service until the caller actively releases it, and the non-retention type occupation requirement is used for the caller to occupy the service until the control instruction of the caller is executed or the execution is terminated; An information processing module is used to update the execution queue by comparing the current call request with the call request that has been added to the execution queue, so that the called service can read the call request with the highest priority from the updated execution queue, execute the control instruction of the call request with the highest priority, and determine whether to release resources or continue to be in an occupied state after the control instruction of the call request with the highest priority is executed according to the non-holding occupancy requirement or the holding occupancy requirement of the call request with the highest priority, wherein updating the execution queue includes adding the current call request to the execution queue and / or deleting the call request in the execution queue.

9. An electronic device, characterized in that: The electronic device comprises: one or more processors; A storage device for storing one or more programs, which, when executed by the one or more processors, enables the electronic device to implement the service arbitration method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: A computer program is stored thereon, and when the computer program is executed by a processor of a computer, the computer is caused to execute the service arbitration method according to any one of claims 1 to 7.

Images