Method for determining request execution sequence, electronic equipment and storage medium

Abstract

The invention discloses a method for determining a request execution sequence, electronic equipment and a storage medium, and relates to the technical field of computers, and the method comprises the steps: obtaining a target address, a target operation type and a range of to-be-operated data by analyzing a target request of a target operation, according to the method, the target request and the execution priority of the existing to-be-executed first request are dynamically determined on the basis, basic attributes of the operation are considered, specific requirements of the operation for other resources are further deeply analyzed, multi-dimensional consideration of the request execution sequence is achieved, and therefore which requests should be executed preferentially can be comprehensively judged, and the execution efficiency of the target request is improved. According to the method and the device, the execution sequence of the requests can be dynamically adjusted in a complex scene of multi-request concurrence, key operation can be ensured to be executed in time, the technical problem that the request execution sequence cannot be effectively determined in related technologies is solved, and the technical effect of dynamically determining the request execution sequence is achieved.

Description

Technical Field

[0001] The present application relates to the field of computer technologies, and in particular, to a method, an electronic device, and a storage medium for determining the execution order of requests. Background Art

[0002] When various services are executed in a system, frequent interactions among multiple entities will be involved, and thus the problem of multiple requests being triggered within a short period may occur. How to adjust the execution logic of these multiple requests to ensure the effective execution of various services is an urgent problem to be solved currently.

[0003] For example, in the Baseboard Management Controller (BMC) system architecture, the Inter-Integrated Circuit Bus (I²C bus) is a widely used communication protocol and is the main communication interface connecting peripheral devices such as sensors, Electrically Erasable Programmable Read-Only Memory (EEPROM), and power management chips. It undertakes various control and data exchange tasks such as temperature monitoring, firmware update, and logging. However, with the continuous improvement of system complexity, a major challenge faced by BMC is how to efficiently and orderly manage I²C bus access in a multi-task parallel environment to avoid resource conflicts and performance bottlenecks. In related technologies, the solutions to the above problems mainly rely on the mutex mechanism to ensure that only one process accesses the I²C bus at the same time. Although this mechanism guarantees the orderly access of the I²C bus to a certain extent, in actual operation, the mutex forces tasks to queue up regardless of their urgency, which not only causes delays in critical operations but also exacerbates the additional scheduling delays caused by lock competition, seriously affecting the real-time response ability and overall performance of the system.

[0004] Therefore, there is a technical problem in related technologies that the execution order of requests cannot be effectively determined. Summary of the Invention

[0005] The present application provides a method, an electronic device, and a storage medium for determining the execution order of requests, so as to at least solve the technical problem in related technologies that the execution order of requests cannot be effectively determined, and achieve the technical effect of dynamically determining the execution order of requests.

[0006] The present application provides a method for determining the request execution order, including: when receiving a target request for requesting to execute a target operation and determining that there is a first request to be executed in the current target queue, parsing the target request to obtain the target address of the target device, the target type of the target operation, and the target range of the data to be operated carried in the target request, where the target queue is used to store requests to be executed, and the target operation includes operations performed on the target device; inserting the target request into the target queue, and determining the target execution order of the target request and the first request in the target queue based on the target address, target type, and target range, where the target execution order is used to instruct the target controller to execute the target request and the first request in accordance with the target execution order.

[0007] The present application further provides a hardware access arbitration proxy device, including: a parsing module, configured to parse a target request when receiving a target request for requesting to execute a target operation and determining that there is a first request to be executed in the current target queue, to obtain the target address of the target device, the target type of the target operation, and the target range of the data to be operated carried in the target request, where the target queue is used to store requests to be executed, and the target operation includes operations performed on the target device; a determining module, configured to insert the target request into the target queue, and determine the target execution order of the target request and the first request in the target queue based on the target address, target type, and target range, where the target execution order is used to instruct the target controller to execute the target request and the first request in accordance with the target execution order.

[0008] An embodiment of the present application further provides a baseboard management controller system, including a hardware access arbitration proxy device, a sending end for initiating a target request, and a target controller.

[0009] The present application further provides an electronic device, including: a memory for storing a computer program; a processor for implementing the steps of any of the above methods for determining the request execution order when executing the computer program.

[0010] The present application further provides a computer-readable storage medium, in which a computer program is stored, where the computer program implements the steps of any of the above methods for determining the request execution order when executed by a processor.

[0011] The present application further provides a computer program product, including a computer program, where the computer program implements the steps of any of the above methods for determining the request execution order when executed by a processor.

[0012] Through this application, by parsing the target request of the target operation to obtain the target address, the target operation type, and the range of data to be operated on, and dynamically determining the execution priority of the target request and the first request to be executed that already exists based on this, not only considering the basic attributes of the operation, but also deeply analyzing the specific requirements of the operation for other resources, a multi-dimensional consideration of the request execution order is achieved. Thus, it is possible to comprehensively judge which requests should be given priority in execution. Therefore, this application can dynamically adjust the execution order of requests in a complex scenario with multiple requests concurrent, ensuring that critical operations can be executed in a timely manner, solving the technical problem in the related art of being unable to effectively determine the request execution order, and achieving the technical effect of dynamically determining the request execution order. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] To more clearly illustrate the embodiments of this application, the following will briefly introduce the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of this application. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0014] Figure 1 Hardware structure block diagram of a mobile terminal for a method of determining request execution order provided by an embodiment of this application;

[0015] Figure 2 Flowchart of a method of determining request execution order provided by an embodiment of this application;

[0016] Figure 3 Schematic diagram of a method of determining request execution order in a specific embodiment of this application;

[0017] Figure 4 Flowchart of a method of determining request execution order in a specific embodiment of this application;

[0018] Figure 5 Schematic diagram of the structure of a hardware access arbitration proxy device provided by an embodiment of this application;

[0019] Figure 6 Schematic diagram of the structure of a baseboard management controller system provided by an embodiment of this application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0020] The following will clearly and completely describe the technical solutions in the embodiments of this application with reference to the drawings in the embodiments of this application. Obviously, the described embodiments are only some, not all, of the embodiments of this application. Based on the embodiments in this application, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the scope of protection of this application.

[0021] It should be noted that in the description of this application, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements not only includes those elements, but also includes other elements not explicitly listed, or further includes elements inherent to such process, method, article or device. The terms "first", "second", etc. in this application are used to distinguish similar objects, rather than to describe a specific order or sequence.

[0022] To enable those skilled in the art of this technology to better understand the solution of this application, the following further detailed description of this application will be given in conjunction with the accompanying drawings and specific embodiments.

[0023] Combined with a specific application environment architecture or a specific hardware architecture on which the execution of a method for determining the request execution order depends, the specific application environment architecture or the specific hardware architecture will be described herein.

[0024] The method embodiments provided in the embodiments of this application can be executed on a mobile terminal, a computer terminal or a similar computing device. Taking running on a mobile terminal as an example, Figure 1 This is a hardware structure block diagram of a mobile terminal for a method of determining the request execution order provided in the embodiments of this application. As Figure 1 shown, the mobile terminal may include one or more ( Figure 1 only one is shown in Figure 1 a) processor 102 (the processor 102 may include, but is not limited to, a processing device such as a microprocessor MCU or a programmable logic device FPGA) and a memory 104 for storing data. Among them, the above mobile terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those of ordinary skill in the art can understand that Figure 1 the structure shown in Figure 1 is only schematic and does not limit the structure of the above mobile terminal. For example, the mobile terminal may further include more or fewer components than

[0025] The memory 104 can be used to store computer programs, such as software programs and modules of application software, such as the computer program corresponding to a method for determining the execution order of requests in the embodiments of the present application. The processor 102 executes various functional applications and data processing by running the computer programs stored in the memory 104, that is, implements the above-mentioned method. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memories, or other non-volatile solid-state memories. In some instances, the memory 104 may further include a memory remotely provided with respect to the processor 102, and these remote memories can be connected to the mobile terminal through a network. Examples of the above-mentioned network include but are not limited to the Internet, an enterprise intranet, a local area network, a mobile communication network, and combinations thereof.

[0026] The transmission device 106 is used to receive or send data via a network. Specific examples of the above-mentioned network may include a wireless network provided by a communication provider of the mobile terminal. In one instance, the transmission device 106 includes a network adapter (abbreviated as NIC for Network Interface Controller), which can be connected to other network devices through a base station and thus can communicate with the Internet. In one instance, the transmission device 106 can be a radio frequency (abbreviated as RF) module, which is used to communicate with the Internet wirelessly.

[0027] Embodiments of the present application provide a method for determining the execution order of requests. Figure 2 It is a flowchart of a method for determining the execution order of requests in an embodiment of the present application, as Figure 2 shown, and the process includes the following steps:

[0028] Step S202, when receiving a target request for requesting to execute a target operation and determining that there is a first request to be executed in the current target queue, parse the target request to obtain the target address of the target device, the target type of the target operation, and the target range of the data to be operated carried in the target request, where the target queue is used to store requests to be executed, and the target operation includes operations performed on the target device.

[0029] Optionally, the initiator of the target request includes, but is not limited to, user terminals, application programs, Internet of Things devices, and BMC systems. Taking the BMC system as an example, the target request can be initiated by a certain application process or service in the BMC system, and is used to request instructions for performing specific operations on a specific peripheral device through the I²C bus, including but not limited to read operations for obtaining data from the target device, write operations for sending data to the target device, and combined read and write operations. For example, the firmware update service requires writing a new firmware version to a specified location in the target device, and the power management service requests to read the current state of the target device and then write new configuration parameters. It should also be noted that the device initiating the above target request can also be a hardware device having a connection relationship with the BMC device, such as an external management device, an external monitoring device, etc. Specifically, who initiates the above target request can be configured based on the actual situation.

[0030] Optionally, the target request is used to indicate a request initiated by an application process or service (such as temperature monitoring, firmware update service) in the BMC system for performing read and write operations on a certain target device on the I²C bus, including but not limited to I²C operation requests.

[0031] Optionally, the target queue is a data structure used to store and manage all requests, sorted according to the processing priority and time sequence of the requests. The target queue is usually implemented through the maximum heap algorithm, sorted by execution priority, with the top of the heap being the highest priority request, ensuring that high-priority requests can be executed first.

[0032] Optionally, the first request is used to indicate the request to be executed in the target queue. The first request can be various different types of requests, and the types of the first request include but are not limited to device status read requests, configuration information write requests, firmware update requests, fault diagnosis requests, and log record requests. Among them, the device status read requests include but are not limited to temperature sensor reading, power status query, and fan speed acquisition; the configuration information write requests include but are not limited to updating configuration data in the EEPROM, modifying hardware parameters, etc.; the firmware update requests involve firmware upgrades of the BMC or other key hardware components; the fault diagnosis requests are used to detect and troubleshoot hardware or software faults; the log record requests include but are not limited to recording device operation logs and system running status. Taking the BMC system as an example, the first request can be initiated by an application process / service in the system, can be initiated by the initiator of the target request, or can be initiated by other initiators, etc., including but not limited to temperature monitoring services, firmware update services, log record services, system-built management modules, external management interfaces, and system-built task schedulers. Specifically, who initiates the above first request can be configured based on the actual situation.

[0033] Optionally, the target device is used to indicate peripheral devices on the I²C bus, including but not limited to temperature sensors, EEPROMs, and power management chips. The target device is the object of the target request operation. In a BMC system, multiple target devices may be connected via the same I²C bus.

[0034] Optionally, the target address is used to indicate the identity of the target device on the I²C bus and is used to determine which device to operate on. The target address can be a 7-bit or 10-bit binary number. According to the I²C protocol, the high 7 bits or high 10 bits are the device type identifier. For example, when the target device is a temperature sensor, its target address may be 0x48, which is 01001000 in binary.

[0035] Optionally, the target type of the target operation is used to indicate the specific type of operation required to be performed in the target request, including but not limited to read operations and write operations.

[0036] Optionally, the target range of the data to be operated on is used to indicate the data address range for the target operation on the target device. It defines the specific location and data length of the target operation. For example, for a read operation, the target range includes the read start address and the read data length; for a write operation, the target range includes the write start address and the write data length. For example, for a read operation, the target range includes the read start address and the read end address; for a write operation, the target range includes the write start address and the write end address.

[0037] Step S204, insert the target request into the target queue, and determine the target execution order of the target request and the first request in the target queue based on the target address, target type, and target range, where the target execution order is used to indicate that the target controller executes the target request and the first request according to the target execution order.

[0038] In this embodiment, the execution entity of the above steps can be a hardware or software processor, proxy device, management device, etc. When the above method is applied to a BMC system, the execution entity can be a process or service inside the BMC, or a processor inside the BMC (for example, an embedded processor), or a processor connected to the BMC through an external network interface, etc. The manifestation form of the execution entity of the above steps can also be a terminal, a server, a specific processor set in the terminal or server, or a processor or processing device set independently of the terminal or server, but is not limited thereto.

[0039] Optionally, the present invention is described by taking the execution entity of the above steps as the hardware access arbitration proxy layer configured in the BMC system as an example, as Figure 3As shown, application processes / services within the BMC system (such as temperature monitoring, firmware update, logging, etc.) initiate I²C operation requests (corresponding to the aforementioned target requests), requesting read operations, write operations, or read-write operations to peripheral devices. This request is directly submitted to the hardware access arbitration proxy layer in the BMC system. The hardware access arbitration proxy layer receives all I²C operation requests, parses the I²C operation requests, and obtains the device address, operation type (read operation / write operation), and data address range carried in the I²C operation requests. The hardware access arbitration proxy layer inserts the I²C operation requests into the target queue and determines the execution order of the I²C operation requests and other I²C operation requests (corresponding to the aforementioned first requests) in the target queue based on the device address, operation type, and data address range. After determining the execution order, it accesses the peripheral device through the I²C controller (i.e., the target controller) interface of the hardware layer to perform read operations or write operations, where the hardware layer is used to execute specific hardware access interfaces.

[0040] Through the embodiments of the present application, by parsing the target requests of the target operations to obtain the target address, target operation type, and the range of data to be operated on, and dynamically determining the execution priorities of the target requests and the existing first requests to be executed based on this, not only considering the basic attributes of the operations, but also deeply analyzing the specific requirements of the operations for other resources, achieving multi-dimensional consideration of the request execution order. Thus, it can comprehensively judge which requests should be given priority in execution. Therefore, in a complex scenario with multiple requests concurrent, it can dynamically adjust the execution order of the requests to ensure that critical operations can be executed in a timely manner, solving the technical problem in the related art that the request execution order cannot be effectively determined and achieving the technical effect of dynamically determining the request execution order.

[0041] In an exemplary embodiment, determining the target execution order of the target requests and the first requests in the target queue based on the target address, target type, and target range includes: determining whether there is a second request in the first requests that has a target conflict with the target requests based on the target address and the target range, obtaining a determination result, where the target conflict is used to indicate that the target address is the same as the first address of the device carried in the second request, and the target range overlaps with the first range of the data to be operated on carried in the second request; determining the target execution order of the target requests and the first requests in the target queue based on the determination result and the target type.

[0042] Optionally, the target address is used to indicate the address of the target device identified in the target request. The first address is used to indicate the address of other devices identified in the second request in the target queue, where the other devices are the target device. The target range is used to indicate the data address range for performing the target operation on the target device. The first range is used to indicate the data address range for performing other operations on the target device. The second request is a request in the first request that has the same device address as the target request and an overlapping data address range for the operation.

[0043] Optionally, target conflict is used to indicate a situation in the target queue where two or more requests target the same device address (the target address is the same as the first address) and the address ranges of the data operations overlap (the target range overlaps with the first range). Such conflicts may cause problems such as data tearing and device locking, and need to be detected and processed before execution. For example, the target request is to request to read data from an EEPROM device with an address of 0x48, and the corresponding target operation is to read data from 0x00 to 0x01 from the EEPROM device with an address of 0x48. The first request includes a request to write data to the EEPROM device with the same address of 0x48, and the corresponding other operation is to write data to the address range of 0x00 to 0x10 in the EEPROM device with an address of 0x48, that is, the determination result is that this request is the second request in the first request that has a target conflict with the target request.

[0044] Optionally, the determination result is used to determine whether there is a second request in the target queue that conflicts with the target request. If there is a conflict, the determination result will indicate the existence of the conflict; if there is no conflict, the determination result will indicate that the request can be safely executed.

[0045] Optionally, the target execution order is the order of request execution determined after conflict detection, which can ensure that the operations corresponding to the requests can be executed efficiently without causing system conflicts or data corruption.

[0046] In this embodiment, by judging whether there is a target conflict through the target address and the target range, it is possible to actively identify those operation requests that may interfere with each other. Especially when multiple processes access the same device concurrently, this early conflict detection helps to avoid problems such as data tearing, abnormal device status, and even hardware locking, achieving the purpose of improving the security and reliability of I²C bus access. At the same time, based on the determination result and the target type, the execution order in the target queue is determined, and dynamic scheduling can be performed according to the nature and urgency of the operations, achieving the purpose of reducing the response time of critical operations and improving the overall execution efficiency of the operations.

[0047] In an exemplary embodiment, determining whether the first request includes a second request that has a target conflict with the target request based on the target address and the target range includes: determining a target container corresponding to the target device from a plurality of pre-constructed containers, where different containers correspond to different devices, and each request included in the first request has been stored in the plurality of containers according to the address of the device it includes; determining whether the first request includes a second request based on the storage status of the target container.

[0048] Optionally, a container is a software design structure. One container corresponds to one or more devices with the same address. The containers can be constructed using the chaining method. One container corresponds to one linked list, and one linked list includes multiple nodes, and one node corresponds to one request. Among them, the manifestation form of the container can be a hash bucket. The container is used to classify and store the requests according to the addresses of the devices, and all requests for the device will be stored in the corresponding container. For example, there are four containers, and the four containers adopt the data structure of a hash bucket array. Each container corresponds to a linked list, and one linked list corresponds to one device, corresponding to a temperature sensor (address 0x48), an EEPROM (address 0x50), a power management chip (address 0x60), and a fan controller (address 0x68) respectively. When multiple requests arrive, they will be automatically stored in the corresponding containers according to their respective device addresses.

[0049] Optionally, the storage status is used to indicate the storage situation of the requests inside the target container, including but not limited to the number of requests present, the operation type of each request, and the data address range. The storage status is used for conflict detection to determine whether the first request includes a second request that has a target conflict with the target request.

[0050] In this embodiment, by pre-classifying and storing the requests into different containers according to the device addresses in advance, it is possible to quickly locate the container related to the target request, that is, the target container. This means that when a new request enters, it is only necessary to check the storage status of the container to immediately determine whether there is a second request in conflict with it, without having to traverse the entire request queue. This mechanism significantly improves the speed and accuracy of conflict detection. Especially in a high-concurrency environment, it can identify and handle conflicts in real time, achieving the purpose of avoiding data corruption or task execution failure caused by detection delay.

[0051] In an exemplary embodiment, determining whether the first request includes the second request based on the storage state of the target container includes at least one of the following: when it is determined that no request is stored in the target container, determining that the first request does not include the second request; when it is determined that a third request is stored in the target container and the target range does not overlap with the second range of the data to be operated carried in the third request, determining that the first request does not include the second request, where the first request includes the third request; when it is determined that a third request is stored in the target container and the target range overlaps with the second range of the data to be operated carried in the third request, determining that the first request includes the second request, where the second request includes the third request.

[0052] Optionally, the second range is used to indicate the data address range for performing other operations on the target device.

[0053] Optionally, when no request is stored in the target container, it can be directly determined that there is no second request conflicting with the target request in the first request. For example, the target request is for a read operation on a temperature sensor (address 0x48). At this time, the target container is empty, indicating that there are no other requests currently operating on the temperature sensor. Therefore, it is determined that the first request does not include the second request, and the target request can be safely executed.

[0054] Optionally, although there is a third request stored in the target container, the data address range for performing other operations (i.e., the second range) does not overlap with the target range. Similarly, it can be determined that there is no second request conflicting with the target request in the first request. For example, the target request is for a write operation on 0xA0 to 0xFF in the EEPROM (address 0x50). There is already a third request in the target container, which is to read the data of register 0x00 to 0x01 in the EEPROM (address 0x50). Although the third request and the target request operate on the same device, the data address ranges of the operations do not overlap. Therefore, it is determined that the first request does not include the second request, and the target request can be safely executed.

[0055] Optionally, when the third request stored in the target container and the target request operate on the same device and the data address ranges of the operations overlap, it will be determined that there is a second request conflicting with the target request in the first request, and this third request is the second request. For example, there is already a third request in the target container to read the data of register 0x00 to 0x02 in the temperature sensor (address 0x48), and the target request is also for the temperature sensor, but the target range is 0x01 to 0x03. At this time, the data address ranges of the two operations, 0x00 - 0x02 and 0x01 - 0x03, overlap. Therefore, it is determined that the first request includes the second request, where the second request includes the third request, and it is necessary to determine the execution order of the target request and the third request.

[0056] In this embodiment, when multiple requests are accessed concurrently, based on the analysis of the storage status of the target container, the priority of the requests can be dynamically adjusted, achieving the purpose of ensuring that critical tasks or high-priority operations can be executed first and are not affected by lower-priority requests.

[0057] In an exemplary embodiment, when it is determined that a third request has been stored in the target container and the number of third requests is multiple, the method further includes at least one of the following: determining whether the target range overlaps with the second range carried in each third request in sequence according to the storage time of the multiple third requests stored in the target container; determining whether the target range overlaps with the second range carried in each third request in sequence according to the priorities of the multiple third requests; determining whether the target range overlaps with the second range carried in each third request in sequence according to the remaining execution time of the multiple third requests.

[0058] Optionally, a container is a software design structure. When a container is constructed using the chaining method, one container corresponds to one linked list, one linked list includes multiple nodes, one node corresponds to one request, and the information stored in the node includes but is not limited to the device address of the request, the operation type, and the data address range. The linked list nodes can be traversed through the pointing of the linked list pointer to determine whether the second range of the third request stored in each node overlaps with the target range of the target request. Among them, the determination method of the linked list pointer pointing includes but is not limited to from the earliest to the latest storage time, from the highest to the lowest priority, and from the least to the most remaining execution time. The storage time is used to indicate the time when the request is stored in the target container, the priority is used to indicate the execution priority of the request, and the remaining execution time is used to indicate the time remaining for the request to be executed.

[0059] In this embodiment, by determining the range overlap in the order of the storage time of the third requests stored in the target container, the first-in-first-out strategy can be effectively implemented, ensuring that each request performs a conflict judgment in chronological order, avoiding the unreasonable priority of later requests, and thus improving the fairness of request processing. At the same time, by sorting the priorities to determine whether the target range overlaps with the second range of each third request, high-priority requests can be processed first, ensuring that critical tasks obtain the priority execution right and are not affected by low-priority requests. At the same time, by determining the overlapping range based on the remaining execution time of the third request, requests with shorter remaining execution time can be scheduled first, which helps to reduce the waiting time. By adopting any of the above methods, the scheduling logic for the third requests can be simplified, avoiding complex comprehensive evaluations of multiple factors, achieving the purpose of reducing the time complexity and reducing the delay in the scheduling process.

[0060] In an exemplary embodiment, before determining a target container corresponding to a target device from a plurality of pre-built containers, the method further includes: generating a target fingerprint for identifying a target request based on a target address, a target type, and a target range, where the target fingerprint includes a first hash value for identifying the target address, a second hash value for identifying the target type, and a third hash value for identifying the target range; determining a target container corresponding to the target device from the plurality of pre-built containers includes: determining a target container corresponding to the first hash value based on a pre-configured mapping relationship between hash values and containers.

[0061] Optionally, the target fingerprint is an identifier for representing a specific operation request on the I²C bus, mainly including three components: a first hash value, a second hash value, and a third hash value, corresponding to the target address, the target type, and the target range respectively. By combining these three values, a highly unique identification code can be generated to ensure that each request can be accurately tracked and managed. For example, a target request is to perform a read operation on registers 0x20 - 0x25 of a temperature sensor with an address of 0x48. The target fingerprint can be a unique value calculated by a specific hash algorithm for the device address (0x48), the operation type (read), and the data range (0x20 - 0x25), such as fingerprint123456.

[0062] Optionally, the first hash value is generated by hashing the target address. The second hash value is generated by hashing the enumeration value or bit encoding of the operation type. The third hash value is generated by hashing the start address and the data length.

[0063] Optionally, to better manage and schedule operation requests on the I²C bus, the BMC system will pre-create a set of containers, and each container is associated with one or a group of devices on the I²C bus. Each container is responsible for storing all requests related to a specific device. In this way, all pending requests for a specific device can be quickly located, improving the efficiency of resource scheduling. For example, Container 1: is responsible for managing all requests for the temperature sensor with an address of 0x48. Container 2: manages all requests for the EEPROM with an address of 0x50. Container 3: processes requests for the power management chip with an address of 0x60.

[0064] Optionally, in order to quickly locate the container related to the request, a mapping relationship needs to be maintained, which can associate the hash value with the container. Among them, the hash value for establishing the association can be the hash value of the device address. In this way, when a new request is submitted, the corresponding container can be quickly found according to the hash value of the device address for further conflict detection and priority arbitration. For example, in the mapping relationship, 0x1A (the first hash value) corresponds to container 1, and 0x32 corresponds to container 2. When a new request with the first hash value of 0x1A arrives, it can be immediately known that it belongs to container 1, and subsequent request scheduling work can be carried out in this container.

[0065] In this embodiment, by generating the target fingerprint of the target request and combining the pre-constructed mapping relationship between the container and the hash value and the container, each request can be efficiently and accurately identified and located, achieving the purpose of intelligent request management.

[0066] In an exemplary embodiment, generating a target fingerprint for identifying a target request based on a target address, a target type, and a target range includes: performing bit concatenation and hash compression processing on the target address, the target type, and the target range to generate the target fingerprint.

[0067] Optionally, bit concatenation means merging different data blocks (such as device address, operation type, data range) at the bit level into a larger data unit. This method can effectively integrate various request parameters to form a compact and information-rich data structure, which is convenient for subsequent processing and storage. For example, the device address 0x28 (8 bits) is converted to binary: 00101000, the operation type WRITE (represented by 8 bits, and the specific value depends on the system setting): 00001010, the data range (starting address 0x00 and ending address 0x0F, a total of 10 bits, 4 bits for the start and 6 bits for the end): starting address 0000, ending address 00001111. Concatenate the above data bits. The high bits of the target fingerprint: device address (8 bits) + operation type (8 bits), and the low bits of the target fingerprint: data range (4 bits of the starting address + 6 bits of the ending address).

[0068] Optionally, hash compression processing refers to the process of mapping data of any length to a fixed-length output (hash value). When generating the target fingerprint, the data after bit concatenation will be compressed by a hash algorithm to produce a simplified and highly unique fingerprint value. Hash compression helps reduce the volume of fingerprint data, which is convenient for storage and quick comparison.

[0069] In this embodiment, the target address, target type, and target range are combined into a compact structure through bit concatenation, which can simplify the logic of conflict detection. When a new request arrives, it is only necessary to compare the target fingerprint of the current request with the existing fingerprint set to determine whether there is a conflict, rather than checking the address, type, and range item by item, achieving the purpose of improving the conflict detection speed.

[0070] In an exemplary embodiment, based on the determination result and the target type, determining the target execution order of the target request and the first request in the target queue includes: when it is determined that the determination result indicates that the first request includes the second request, determining the overlap degree between the target range and the first range, and based on the pre-configured correspondence between the overlap degree and the first weight factor, determining the value of the first weight factor; when it is determined that the determination result indicates that the first request does not include the second request, setting the value of the first weight factor to 0; where the first weight factor is used to indicate the conflict probability between the first request and the second request; determining the target priority information of the target request based on the value of the first weight factor and the weight value corresponding to the target type; and determining the target execution order of the target request and the first request in the target queue based on the target priority information and the first priority information of the first request.

[0071] Optionally, the first weight factor is a numerical index used to quantify address conflicts, and the value of this weight factor depends on the degree of overlap of the request ranges and the pre-configured correspondence between the overlap degree and the weight factor. For example, if the target range completely overlaps with the first range, the first weight factor is set to 100%; if there is partial overlap, the weight factor is set according to the overlap ratio. For example, if the overlap is 50%, the weight factor is 50%; if there is no overlap, the value of the first weight factor is set to 0%.

[0072] Optionally, the weight value of the target type is predefined and used to reflect the priorities of different categories of operation requests. For example, reading sensor data may be given a lower weight, while a firmware update operation may have a higher weight value.

[0073] Optionally, the method for determining the target priority information of the target request based on the value of the first weight factor and the weight value corresponding to the target type includes, but is not limited to, the weighted average method, the weight decay method, and the priority conversion method.

[0074] This embodiment determines the execution order of the target request and the first request in the target queue based on the determination result and the target type. By quantifying the conflict probability and dynamically adjusting the priority information, it achieves the purpose of effectively managing I²C bus conflicts, optimizing resource allocation, and enhancing the flexibility of the scheduling strategy.

[0075] In an exemplary embodiment, determining the target priority information of a target request based on the value of a first weight factor and the weight value corresponding to the target type includes: determining the remaining execution time of the target request, and determining the value of a second weight factor based on the remaining execution time and a preset timeout threshold of the target request, where the second weight factor is used to indicate the timeout risk of the target request; determining the value of a third weight factor based on the type of the target device, where the third weight factor is used to indicate the device priority of the target device; determining the target priority information of the target request based on the value of the first weight factor, the value of the second weight factor, the value of the third weight factor, and the weight value corresponding to the target type.

[0076] Optionally, the second weight factor is calculated based on the remaining execution time of the target request and a preset timeout threshold, and is used to indicate the execution timeout risk of the request. If the remaining execution time of the request is lower than a certain percentage of the preset timeout threshold, the second weight factor will increase; otherwise, it will decrease or remain 0, where the remaining execution time is the difference between the current time and the timestamp, and the timestamp is the reception time of the request.

[0077] Optionally, the third weight factor reflects the priority of the target device and is determined based on the type of the device. Different types of devices and services may have different priorities. For example, a temperature monitoring sensor has a higher priority because it is directly related to the stability and security of the system.

[0078] Optionally, the method for determining the target priority information of the target request based on the value of the first weight factor, the value of the second weight factor, the value of the third weight factor, and the weight value corresponding to the target type includes, but is not limited to, the weighted summation method, the weighted product method, and the piecewise linear function method.

[0079] In this embodiment, by comprehensively considering the first weight factor (indicating the probability of address range conflict between requests), the second weight factor (reflecting the risk degree of the request approaching timeout), and the third weight factor (representing the priority level of the device), more refined priority adjustment can be performed on various requests, allowing critical tasks to automatically elevate their positions in the queue when facing conflicts, approaching timeouts, or involving high-priority devices, ensuring priority execution, and achieving the purpose of improving the bus bandwidth utilization rate.

[0080] In an exemplary embodiment, determining the target priority information of a target request based on the value of the first weight factor, the value of the second weight factor, the value of the third weight factor, and the weight value corresponding to the target type includes: determining the target priority information W through the following formula 总 :

[0081] W 总 =W 基础 ×(1 + α地址冲突 +α 超时风险 ) × (1 + α 设备优先级 ), where W 基础 is the weight value corresponding to the target type, α 地址冲突 is the value of the first weight factor, α 超时风险 is the value of the second weight factor, and α 设备优先级 is the value of the third weight factor.

[0082] The priority arbitration elements and the weight calculation model are shown in Table 1. Among them, the values configured in Table 1 are all examples and can be flexibly adjusted based on the actual situation in practical applications. For example, the weight value of the read operation can be set to 70, 60, etc., the weight value of the write operation can be set to 90, 80, etc., and when the ratio of the remaining execution time to the timeout threshold ≤ 20%, the weight is increased by 20%.

[0083] Table 1

[0084]

[0085] For example, for a request indicating the following example, calculated with the values configured in Table 1, its calculation result is priority information = 100 × (1 + 0.2 + 0.3) × (1 + 0.5) = 100 × 1.5 × 1.5 = 225: primary device (weight addition +50%), device type: temperature monitoring sensor (high real-time requirement, affecting system security), operation type: read-write operation (W 基础 = 100), address conflict: address range overlap (α 地址冲突 = 0.2), timeout risk: remaining execution time ≤ 30% of the timeout threshold (α 超时风险 = 0.3).

[0086] For another example, for a request indicating the following example, calculated with the values configured in Table 1, its calculation result is priority information = 90 × (1 + 0) × (1 + 0.3) = 90 × 1 × 1.3 = 117: secondary device (weight addition +30%), device type: configuration synchronization (affecting functional integrity), operation type: write operation (W 基础 = 90), address conflict: no address overlap (α 地址冲突 = 0), timeout risk: timeout condition not triggered (α 超时风险 = 0).

[0087] For another example, for a request indicating the following example, calculated with the values configured in Table 1, its calculation result is priority information = 80 × (1 + 0 + 0.3) × (1 + 0.1) = 80 × 1.3 × 1.1 = 114.4: tertiary device (weight addition +10%), device type: log query module (non-real-time auxiliary task), operation type: read operation (W基础 = 80), Address conflict: no address overlap (α 地址冲突 = 0), Timeout risk: remaining execution time ≤ 30% of the timeout threshold (α 超时风险 = 0.3).

[0088] Based on the above three device types, the running order is: temperature monitoring sensor → configuration synchronization → log query module.

[0089] In this embodiment, through the above formula, the priority information of the request is dynamically calculated and adjusted, improving the utilization rate of the bus bandwidth, achieving the purpose of improving the intelligent adaptive ability of the BMC system when processing I²C bus access requests, and supporting concurrent management of more devices compared with traditional solutions.

[0090] In an exemplary embodiment, before determining the target priority information of the target request based on the value of the first weight factor and the weight value corresponding to the target type, the method further includes: when the target type indicates that the target operation is a read operation, determining that the weight value corresponding to the target type is the first weight value; when the target type indicates that the target operation is a write operation, determining that the weight value corresponding to the target type is the second weight value; when the target type indicates that the target operation is a read-write operation, determining that the weight value corresponding to the target type is the third weight value; wherein, the first weight value is less than the second weight value, and the second weight value is less than the third weight value. In this embodiment, the weight value of the read operation can be set to 70, 60, etc., and the weight value of the write operation can be set to 90, 80, etc.

[0091] In an exemplary embodiment, the method further includes: before executing multiple fourth requests included in the target queue that need to be continuously executed, setting a transaction lock, wherein after setting the transaction lock, pausing the operation of adjusting the execution order of the requests included in the target queue; after completing the execution of the multiple fourth requests, releasing the transaction lock to continue the operation of adjusting the execution order of the requests included in the target queue.

[0092] Optionally, the transaction lock is a mechanism used to ensure that a series of operations can be executed as a whole (atomic operation) without external interference. The fourth requests are requests that cannot be executed separately, and these requests are usually closely related and jointly complete a composite task, such as requests for EEPROM writing, requests in the firmware upgrade process, etc. In the BMC system, when a set of continuous I²C access operations are required (i.e., multiple I 2(C request), by setting a transaction lock, it can be ensured that these operations will not be interrupted by other requests before completion, ensuring the integrity of the operations and the consistency of the data. For example, for critical operations such as writing to the EEPROM, a bus lock is implemented. A transaction lock is introduced at the hardware access arbitration agent layer to ensure that multiple operation sequences are indivisible. During the holding of the lock, the bus is exclusive, and other requests enter the target queue to wait. When the transaction lock is released, other requests continue to execute in the order of priority.

[0093] In this embodiment, by setting a transaction lock, it is ensured that the bus control right is not preempted during the operation of critical operations, and it is guaranteed that critical operations will not be interrupted by other requests before completion, achieving the purpose of ensuring the integrity of operations and data consistency.

[0094] In an exemplary embodiment, the method further includes: when it is determined that the target controller has executed the fifth request included in the target queue, obtaining the return value of the target interface, where the target interface is the interface through which the target controller accesses the device requested by the fifth request; determining the execution result of the target controller's execution of the fifth request based on the return value; triggering an operation corresponding to the execution result.

[0095] Optionally, the target controller is a hardware component in the BMC system responsible for managing and coordinating I²C bus access and is responsible for the actual bus access operation. The target controller follows certain arbitration and priority rules when processing requests to ensure the orderly and efficient execution of operations. For example, in a server, the BMC baseboard management controller is the target controller, which can specifically be an I²C controller. It controls the data transmission on the I²C bus according to the received requests (such as sensor readings, EEPROM updates, etc.) and the set priority rules to ensure the execution of various operations.

[0096] Optionally, the target interface is the specific interface through which the target controller communicates with the device on the I²C bus. It provides the necessary functions required for accessing and reading and writing the device, such as setting the start address, reading and writing data, and obtaining the device response. For example, when executing the fifth request to read the temperature sensor data, the target interface may be a specific I²C interface used to communicate with the temperature sensor, providing the function of reading the data in the sensor register. The return value of the target interface includes the execution result, whether it is successful or failed.

[0097] In this embodiment, by obtaining the return value of the target interface and determining the execution result based on this, the execution result of the execution request can be fed back in a timely manner, enabling the BMC system to quickly identify and handle any abnormalities or failures during device access, achieving the purpose of significantly improving the system responsiveness and reliability.

[0098] In an exemplary embodiment, triggering an operation corresponding to an execution result includes at least one of the following: when the execution result is used to indicate an error of a first degree, triggering the target controller to repeatedly execute the fifth request; when the execution result is used to indicate an error of a second degree, triggering the target controller to reset so that after the target controller resets, it re-executes the fifth request.

[0099] Optionally, the error of the first degree is used to indicate a temporary error, usually a minor, foreseeable or temporarily resolvable error, and such errors can often be corrected through simple operations or retry mechanisms. In the I²C communication scenario, common errors of the first degree include, but are not limited to, the device not responding temporarily (suspended state), communication failures caused by mild interference on the bus, etc. Most of these errors do not mean that the device or the communication line has a permanent failure.

[0100] Optionally, the error of the second degree is used to indicate a non-temporary error, usually a more serious problem that may require more drastic measures to solve. For example, the device is locked up, and the bus continuously fails to respond. Resetting the target controller is equivalent to restarting the target controller, clearing its internal state, and restoring its initial configuration. After resetting, the target controller will re-establish a connection with the I²C bus and re-execute the fifth request.

[0101] This embodiment ensures the effective utilization of resources and avoids the risk of long-term service interruption by distinguishing the degree of errors and taking different responses, thereby achieving the purpose of overall improving the task execution efficiency.

[0102] In an exemplary embodiment, after triggering the target controller to reset, the method further includes: when the number of times of triggering the target controller to reset exceeds a preset number threshold, prohibiting the target controller from accessing the device requested by the fifth request.

[0103] The present invention will be described below in conjunction with specific embodiments:

[0104] This embodiment is described by taking an I²C access process as an example. Figure 4 It is a flowchart of a method for determining the execution order of requests in a specific embodiment of the present application. As Figure 4 shown, it includes the following steps:

[0105] S402, request submission and proxy (entry of the hardware access arbitration proxy layer):

[0106] Encapsulate the request. The application process submits an I²C operation request to the hardware access arbitration proxy layer through the unified API interface i2cx_hal_request(). The hardware access arbitration proxy layer injects the timestamp of the I²C operation request (x represents which I²C channel). The parameters carried in the I²C operation request include the following fields:

[0107] typedef struct {

[0108] uint16_t slave_addr;

[0109] i2c_op_type_t op_type; / / Read operation, write operation, read-write operation

[0110] uint16_t read_reg_addr; / / Read start address

[0111] uint16_t read_length; / / Read data length

[0112] uint16_t write_reg_addr; / / Write start address

[0113] uint16_t write_length; / / Write data length

[0114] uint8_t *read_buf; / / Read data buffer pointer

[0115] uint8_t *write_buf; / / Write data buffer pointer

[0116] }i2c_msg_t ;

[0117] The interface functions are designed as follows:

[0118] int i2c_halx_request(const i2c_msg_t *msg, uint32_t timeout_ms);

[0119] S404, the hardware access arbitration proxy layer parses the parameters carried in the I²C operation request and generates a hardware operation fingerprint (i.e., the target fingerprint). Among them, the hardware operation fingerprint is a 64-bit fingerprint value that uniquely identifies the I²C operation request generated by bit concatenation and hash compression. The code example is as follows:

[0120] / / Example: Generation of 64-bit hardware operation fingerprint:

[0121] uint64_t generate_fingerprint(const i2c_msg_t *msg) {

[0122] uint64_t fp = 0;

[0123] / / Device address (8 bits)

[0124] fp |= (uint64_t)msg->slave_addr << 56;

[0125] / / Secondary high 8 bits for operation type

[0126] fp |= (uint64_t)msg->op_type << 48;

[0127] / / Read operation range (middle 24 bits: 16-bit address + 8-bit length compression)

[0128] fp |= (uint64_t)(msg->read_reg_addr & 0xFFFF) << 32;

[0129] fp |= (uint64_t)(msg->read_length & 0xF) << 24;

[0130] / / Write operation range (lower 24 bits: 16-bit address + 8-bit length compression)

[0131] fp |= (uint64_t)(msg->write_reg_addr & 0xFFFF) << 8;

[0132] fp |= (uint64_t)(msg->write_length & 0xF);

[0133] return fp;

[0134] }

[0135] In S406, perform a pre-check for address conflicts. If a conflict exists, transfer to S408 for priority arbitration. If no conflict exists, transfer to S412 to join the scheduling queue (i.e., the target queue).

[0136] Store the hardware operation fingerprints in the fingerprint database for conflict detection. The fingerprint database is in the form of an in-memory hash table, and the hash table can be constructed using the chaining method to accurately identify address overlapping operations of the same device. The core structure of the hash table includes: an array of hash buckets and linked list nodes. The array of hash buckets is an array of pointers of a fixed size (256 buckets by default. Of course, other numbers of buckets can also be set. Here, 256 is used as an example). Each bucket corresponds to a linked list for handling hash conflicts. Each node in the linked list stores information about the I²C operation request, including: fingerprint value, read / write address range, and a linked list pointer. The fingerprint value is a 64-bit hash value that uniquely identifies the I²C operation request (of course, hash values of other bit lengths can also be set. For example, the fingerprint value can be set as a 32-bit hash value, or the fingerprint value can be set as a 128-bit hash value, etc.), which is generated from the device address, operation type, and read / write operation range. The read / write address range is used to record the start and end addresses of the read operation (read_start to read_end), and the start and end addresses of the write operation (write_start to write_end). The linked list pointer points to the next node in the same bucket, forming a chained structure.

[0137] When inserting an I²C operation request, it is necessary to traverse the linked list of the target bucket to check whether the address range conflicts with the existing requests. The specific steps are as follows:

[0138] a) Locate the target bucket: Calculate the bucket index corresponding to the fingerprint through the hash function. The hash function maps the high 8 bits (i.e., the device address) of the 64-bit fingerprint value to the bucket index, and uses the difference of the device addresses to naturally disperse the requests. Take the modulo of the high 8-bit value with the size of the hash table (256) to obtain the bucket index (0 - 255).

[0139] b) Traverse the linked list nodes: Check one by one whether the read / write address range of the nodes in the bucket overlaps with the read / write address range of the I²C operation request, including: read range conflict and write range conflict. If the read start address of the I²C operation request is less than the read end address of a certain request stored in a node, and the read end address of the I²C operation request is greater than the read start address of a certain request stored in the node, it is a read range conflict; if the write start address of the I²C operation request is less than the write end address of a certain request stored in a node, and the write end address of the I²C operation request is greater than the write start address of a certain request stored in the node, it is a write range conflict.

[0140] c) Conflict determination: If there is an overlap in the read or write address range of the same device, it is determined as a conflict; if the devices are different, even if the read or write address ranges are the same, it is regarded as non-conflicting.

[0141] S408, the priority arbitration elements and weight calculation model are shown in Table 1:

[0142] Table 1

[0143]

[0144] The calculation formula for the requested priority (i.e., priority information) is as follows:

[0145] Priority information = W 基础 ×(1 + α 地址冲突 + α 超时风险 )×(1 + α 设备优先级 ).

[0146] S410. Use a max heap to maintain the scheduling queue, sort it according to the execution priority, with the top of the heap being the request with the highest priority. The core operations of the scheduling queue include insertion and extraction operations. Insert a request: After calculating the priority, place the I²C operation request at the last position of the heap (the end of the complete binary tree), compare the weight of the I²C operation request with that of its parent node. If the weight of the child node > the weight of the parent node (higher priority), then swap their positions and repeat the floating up until the heap property is satisfied (parent node > child node). Extract a request: After popping the top request of the heap (the request with the highest priority), move the last node of the heap to the top of the heap, and compare the priority of the new top of the heap with that of its left and right child nodes. If the priority of the parent node < the priority of any child node, swap positions with the largest child node. Repeat the sinking until the priority of the parent node ≥ the priority of all child nodes.

[0147] S412. Add it to the scheduling queue, repeatedly extract the top request of the heap in a loop, and skip the tasks that have timed out. Execute the hardware operation corresponding to the I²C operation request through the I²C controller at the hardware layer. After completion, delete the mapping relationship of this request in the hash table.

[0148] S414. Implement bus locking for critical operations such as writing to the EEPROM. Introduce a transaction lock at the hardware access arbitration agent layer to ensure that multiple operation sequences are indivisible. During the holding of the lock, the bus is exclusive, and other requests enter the target queue to wait. When the transaction lock is released, other requests continue to execute in the order of priority.

[0149] S416. Check whether the execution is successful. If successful, go to S420; if not, go to S418.

[0150] S418. After accessing the I²C device through the I²C controller interface at the hardware layer, obtain the execution result returned by the I²C interface. If the execution result indicates a temporary error (such as NACK), automatically retry 3 times; if the execution result indicates a serious error (such as I²C bus lock-up), trigger the reset of the I²C controller. After the reset, re-initialize the I²C bus, release the locked requests, and resume scheduling according to the priority. If it still fails after 3 resets, disable the access to this device.

[0151] S420, Result return, log record.

[0152] Through the description of the above embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be implemented by means of software plus a necessary general hardware platform. Of course, it can also be implemented by hardware, but in many cases, the former is a better implementation method.

[0153] The embodiment of the present application also provides a hardware access arbitration proxy device, such as Figure 5 shown, including:

[0154] A parsing module 502, configured to parse a target request when receiving a target request for requesting to execute a target operation and determining that there is a first request to be executed in the current target queue, so as to obtain a target address of a target device carried in the target request, a target type of the target operation, and a target range of data to be operated, where the target queue is used to store requests to be executed, and the target operation includes an operation performed on the target device;

[0155] A determining module 504, configured to insert the target request into the target queue, and determine an execution order of the target request and the first request in the target queue based on the target address, the target type, and the target range, where the execution order is used to instruct the target controller to execute the target request and the first request according to the execution order.

[0156] In an exemplary embodiment, the determining module 504 includes: a determining sub-module, configured to determine whether there is a second request in the first request that has a target conflict with the target request based on the target address and the target range, so as to obtain a determination result, where the target conflict is used to indicate that the target address is the same as a first address of a device carried in the second request, and the target range overlaps with a first range of data to be operated carried in the second request; a determining sub-module, configured to determine an execution order of the target request and the first request in the target queue based on the determination result and the target type.

[0157] In an exemplary embodiment, the determining sub-module includes: a first determining unit, configured to determine a target container corresponding to the target device from a plurality of pre-constructed containers, where different containers correspond to different devices, and each request included in the first request has been stored in the plurality of containers according to the address of the device included; a second determining unit, configured to determine whether the first request includes a second request based on the storage state of the target container.

[0158] In an exemplary embodiment, the second determination unit includes at least one of the following: a first determination subunit, configured to determine that the first request does not include the second request when it is determined that there is no stored any request in the target container; a second determination subunit, configured to determine that the first request does not include the second request when it is determined that a third request is stored in the target container and the target range does not overlap with a second range of the to-be-operated data carried in the third request, where the first request includes the third request; a third determination subunit, configured to determine that the first request includes the second request when it is determined that a third request is stored in the target container and the target range overlaps with a second range of the to-be-operated data carried in the third request, where the second request includes the third request.

[0159] In an exemplary embodiment, when it is determined that a third request is stored in the target container and the number of the third requests is multiple, the third determination subunit further includes at least one of the following: a first determination subordinate subunit, configured to sequentially determine whether the target range overlaps with the second range carried in each third request according to the storage time of the multiple third requests stored in the target container; a second determination subordinate subunit, configured to sequentially determine whether the target range overlaps with the second range carried in each third request according to the priorities of the multiple third requests; a third determination subordinate subunit, configured to sequentially determine whether the target range overlaps with the second range carried in each third request according to the remaining execution time of the multiple third requests.

[0160] In an exemplary embodiment, the determination sub-module further includes: a first generation unit, configured to generate a target fingerprint for identifying a target request based on a target address, a target type, and a target range before determining a target container corresponding to a target device from a plurality of pre-constructed containers, where the target fingerprint includes a first hash value for identifying the target address, a second hash value for identifying the target type, and a third hash value for identifying the target range; the first determination unit includes: a fourth determination subunit, configured to determine a target container corresponding to the first hash value based on a pre-configured mapping relationship between hash values and containers.

[0161] In an exemplary embodiment, the first generation unit includes: a first generation subunit, configured to perform bit splicing and hash compression processing on the target address, the target type, and the target range to generate the target fingerprint.

[0162] In an exemplary embodiment, the determination sub-module includes: a third determination unit configured to determine the overlap degree between a target range and a first range when it is determined that the determination result indicates that a second request is included in a first request, and determine the value of a first weight factor based on a corresponding relationship between the overlap degree and the first weight factor pre-configured; when it is determined that the determination result indicates that the second request is not included in the first request, set the value of the first weight factor to 0; wherein, the first weight factor is used to indicate the conflict probability between the first request and the second request; a fourth determination unit configured to determine the target priority information of a target request based on the value of the first weight factor and the weight value corresponding to the target type; a fifth determination unit configured to determine the target execution order of the target request and the first request in a target queue based on the target priority information and the first priority information of the first request.

[0163] In an exemplary embodiment, the fourth determination unit includes: a fifth determination subunit configured to determine the remaining execution time of the target request, and determine the value of a second weight factor based on the remaining execution time and a preset timeout threshold of the target request, wherein the second weight factor is used to indicate the timeout risk of the target request; a sixth determination subunit configured to determine the value of a third weight factor based on the type of the target device, wherein the third weight factor is used to indicate the device priority of the target device; a seventh determination subunit configured to determine the target priority information of the target request based on the value of the first weight factor, the value of the second weight factor, the value of the third weight factor, and the weight value corresponding to the target type.

[0164] In an exemplary embodiment, the seventh determination subunit includes: determining the target priority information W through the following formula 总 : W 总 = W 基础 × (1 + α 地址冲突 + α 超时风险 ) × (1 + α 设备优先级 ) where W 基础 is the weight value corresponding to the target type, α 地址冲突 is the value of the first weight factor, α 超时风险 is the value of the second weight factor, and α 设备优先级 is the value of the third weight factor.

[0165] In an exemplary embodiment, the determining sub-module further includes: a sixth determining unit, configured to determine that the weight value corresponding to the target type is a first weight value when the target type indicates that the target operation is a read operation, before determining the target priority information of the target request based on the value of the first weight factor and the weight value corresponding to the target type; a seventh determining unit, configured to determine that the weight value corresponding to the target type is a second weight value when the target type indicates that the target operation is a write operation; an eighth determining unit, configured to determine that the weight value corresponding to the target type is a third weight value when the target type indicates that the target operation is a read-write operation; wherein, the first weight value is less than the second weight value, and the second weight value is less than the third weight value.

[0166] In an exemplary embodiment, the device further includes: a first setting module, configured to set a transaction lock before executing a plurality of fourth requests included in the target queue, wherein, after setting the transaction lock, the operation of adjusting the execution order of the requests included in the target queue is suspended; a first releasing module, configured to release the transaction lock after completing the execution of the plurality of fourth requests, so as to continue to execute the operation of adjusting the execution order of the requests included in the target queue.

[0167] In an exemplary embodiment, the device further includes: a first obtaining module, configured to obtain the return value of the target interface when it is determined that the target controller has executed a fifth request included in the target queue, wherein the target interface is the interface of the device that the target controller accesses for the fifth request; a second determining module, configured to determine the execution result of the target controller's execution of the fifth request based on the return value; a first triggering module, configured to trigger an operation corresponding to the execution result.

[0168] In an exemplary embodiment, the first triggering module includes at least one of the following: a first triggering sub-module, configured to trigger the target controller to repeatedly execute the fifth request when the execution result is used to indicate an error of a first degree; a second triggering sub-module, configured to trigger the target controller to reset when the execution result is used to indicate an error of a second degree, so that after the target controller is reset, the fifth request is re-executed.

[0169] In an exemplary embodiment, the first triggering module further includes: a first prohibiting sub-module, configured to prohibit the target controller from accessing the device requested by the fifth request when the number of times of triggering the target controller to reset exceeds a preset number threshold after triggering the target controller to reset.

[0170] For the description of the features corresponding to the embodiments of the hardware access arbitration proxy device, reference may be made to the relevant description of the embodiments corresponding to the method for determining the execution order of requests, which will not be elaborated here one by one.

[0171] Embodiments of the present application further provide a baseboard management controller system, such as Figure 6 shown, including a hardware access arbitration proxy device, a sender for initiating a target request, and a target controller.

[0172] Embodiments of the present application further provide an electronic device, including a memory and a processor. A computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any of the above method embodiments for determining the execution order of requests.

[0173] Embodiments of the present application further provide a computer-readable storage medium, in which a computer program is stored. The computer program is configured to execute the steps in any of the above method embodiments for determining the execution order of requests when running.

[0174] In an exemplary embodiment, the above computer-readable storage medium may include, but is not limited to: USB flash drives, read-only memories (ROMs), random access memories (RAMs), mobile hard disks, magnetic disks, or optical discs, etc., various media that can store computer programs.

[0175] Embodiments of the present application further provide a computer program product. The above computer program product includes a computer program, and when the computer program is executed by a processor, it implements the steps in any of the above method embodiments for determining the execution order of requests.

[0176] Embodiments of the present application further provide another computer program product, including a non-volatile computer-readable storage medium. The non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, it implements the steps in any of the above method embodiments for determining the execution order of requests.

[0177] Those skilled in the art can further realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of the two. To clearly illustrate the interchangeability of hardware and software, the components and steps of each example have been generally described according to their functions in the above description. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Skilled professionals can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present application.

[0178] The above has introduced in detail a method for determining the execution order of requests. Specific examples are used in this article to elaborate on the principle and implementation manner of this application. The description of the above embodiments is only used to help understand the method of this application and its core idea. It should be noted that for those of ordinary skill in the art of this technology, without departing from the principle of this application, several improvements and modifications can still be made to this application, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method for determining the execution order of requests, characterized in that, Including: When receiving a target request for requesting to execute a target operation and determining that there is a first request to be executed in the current target queue, parsing the target request to obtain the target address of the target device carried in the target request, the target type of the target operation, and the target range of the data to be operated, where the target queue is used to store requests to be executed, and the target operation includes an operation performed on the target device; Inserting the target request into the target queue, and determining the target execution order of the target request and the first request in the target queue based on the target address, the target type, and the target range, where the target execution order is used to instruct the target controller to execute the target request and the first request according to the target execution order.

2. The method according to claim 1, characterized in that Determining the target execution order of the target request and the first request in the target queue based on the target address, the target type, and the target range includes: Determining whether there is a second request in the first request that has a target conflict with the target request based on the target address and the target range, to obtain a determination result, where the target conflict is used to indicate that the target address is the same as the first address of the device carried in the second request, and the target range overlaps with the first range of the data to be operated carried in the second request; Determining the target execution order of the target request and the first request in the target queue based on the determination result and the target type.

3. The method according to claim 2, wherein Determining whether there is a second request in the first request that has a target conflict with the target request based on the target address and the target range includes: Determining a target container corresponding to the target device from a plurality of pre-constructed containers, where different containers correspond to different devices, and each request included in the first request has been stored in the plurality of containers according to the address of the device it includes; Determining whether the first request includes the second request based on the storage state of the target container.

4. The method according to claim 3, wherein Determining whether the first request includes the second request based on the storage state of the target container includes at least one of the following: When determining that no request is stored in the target container, determining that the first request does not include the second request; When determining that a third request is stored in the target container and the target range does not overlap with the second range of the data to be operated carried in the third request, determining that the first request does not include the second request, where the first request includes the third request; When determining that a third request is stored in the target container and the target range overlaps with the second range of the data to be operated carried in the third request, determining that the first request includes the second request, where the second request includes the third request.

5. The method according to claim 4, wherein When determining that a third request is stored in the target container and the number of the third requests is multiple, the method further includes at least one of the following: Determine whether the target range overlaps with the second range carried in each of the multiple third requests in sequence according to the storage time of the multiple third requests stored in the target container; Determine whether the target range overlaps with the second range carried in each of the multiple third requests in sequence according to the priorities of the multiple third requests; Determine whether the target range overlaps with the second range carried in each of the multiple third requests in sequence according to the remaining execution times of the multiple third requests.

6. The method according to claim 3, wherein, Before determining the target container corresponding to the target device from a plurality of pre-constructed containers, the method further includes: generating a target fingerprint for identifying the target request based on the target address, the target type, and the target range, wherein the target fingerprint includes a first hash value for identifying the target address, a second hash value for identifying the target type, and a third hash value for identifying the target range; Determining the target container corresponding to the target device from a plurality of pre-constructed containers includes: determining the target container corresponding to the first hash value based on a pre-configured mapping relationship between hash values and containers.

7. The method according to claim 6, characterized in that, Generating a target fingerprint for identifying the target request based on the target address, the target type, and the target range includes: Performing bit splicing and hash compression processing on the target address, the target type, and the target range to generate the target fingerprint.

8. The method according to claim 2, characterized in that Determining the target execution order of the target request and the first request in the target queue based on the determination result and the target type includes: When it is determined that the determination result indicates that the first request includes the second request, determining the overlap degree between the target range and the first range, and determining the value of the first weight factor based on a pre-configured correspondence between the overlap degree and the first weight factor; when it is determined that the determination result indicates that the first request does not include the second request, setting the value of the first weight factor to 0; wherein the first weight factor is used to indicate the conflict probability between the first request and the second request; Determining the target priority information of the target request based on the value of the first weight factor and the weight value corresponding to the target type; Determining the target execution order of the target request and the first request in the target queue based on the target priority information and the first priority information of the first request.

9. The method according to claim 8, wherein Determining the target priority information of the target request based on the value of the first weight factor and the weight value corresponding to the target type includes: Determining the remaining execution time of the target request, and determining the value of a second weight factor based on the remaining execution time and a preset timeout threshold of the target request, wherein the second weight factor is used to indicate the timeout risk of the target request; Determining the value of a third weight factor based on the type of the target device, wherein the third weight factor is used to indicate the device priority of the target device; Determine the target priority information of the target request based on the value of the first weight factor, the value of the second weight factor, the value of the third weight factor, and the weight value corresponding to the target type.

10. The method according to claim 9, wherein Determining the target priority information of the target request based on the value of the first weight factor, the value of the second weight factor, the value of the third weight factor, and the weight value corresponding to the target type includes: Determine the target priority information W through the following formula 总 :[[-END]] W 总 =W 基础 ×(1 + α 地址冲突 + α 超时风险 )×(1 + α 设备优先级 ); Among them, W 基础 is the weight value corresponding to the target type, α 地址冲突 is the value of the first weight factor, α 超时风险 is the value of the second weight factor, and, α 设备优先级 is the value of the third weight factor.

11. The method according to claim 8, characterized in that, Before determining the target priority information of the target request based on the value of the first weight factor and the weight value corresponding to the target type, the method further includes: When the target type indicates that the target operation is a read operation, determine that the weight value corresponding to the target type is the first weight value; When the target type indicates that the target operation is a write operation, determine that the weight value corresponding to the target type is the second weight value; When the target type indicates that the target operation is a read-write operation, determine that the weight value corresponding to the target type is the third weight value; Wherein, the first weight value is less than the second weight value, and the second weight value is less than the third weight value.

12. The method according to any one of claims 1 to 11, characterized in that, The method further includes: Before executing a plurality of fourth requests included in the target queue that need to be continuously executed, set a transaction lock. After setting the transaction lock, suspend the operation of adjusting the execution order of the requests included in the target queue; After completing the execution of the plurality of fourth requests, release the transaction lock to continue the operation of adjusting the execution order of the requests included in the target queue.

13. The method according to any one of claims 1 to 11, characterized in that, The method further includes: When it is determined that the target controller has executed a fifth request included in the target queue, obtain the return value of the target interface, where the target interface is the interface through which the target controller accesses the device requested by the fifth request; Determine the execution result of the target controller executing the fifth request based on the return value; Trigger an operation corresponding to the execution result.

14. The method according to claim 13, wherein Triggering an operation corresponding to the execution result includes at least one of the following: When the execution result is used to indicate an error of the first degree, trigger the target controller to repeat the execution of the fifth request; When the execution result is used to indicate an error of the second degree, trigger the target controller to reset so that after the target controller resets, re-execute the fifth request.

15. The method according to claim 14, wherein After triggering the target controller to reset, the method further includes: When the number of times the target controller is triggered to reset exceeds a preset number threshold, prohibit the target controller from accessing the device requested by the fifth request.

16. A hardware access arbitration proxy device, characterized in that Includes: A parsing module, configured to, when receiving a target request for requesting to execute a target operation and determining that there is a first request to be executed in the current target queue, parse the target request to obtain the target address of the target device carried in the target request, the target type of the target operation, and the target range of the data to be operated, where the target queue is used to store requests to be executed, and the target operation includes an operation performed on the target device; A determination module, configured to insert the target request into the target queue, and determine an execution order of the target request and the first request in the target queue based on the target address, the target type, and the target range, where the execution order is used to instruct the target controller to execute the target request and the first request according to the execution order.

17. A baseboard management controller system, characterized in that, Comprising: The hardware access arbitration proxy device according to claim 16, which is a sending end for initiating a target request and a target controller.

18. An electronic device, characterized in that, Comprising: A memory, configured to store a computer program; A processor, configured to implement the steps of the method for determining an execution order of a request according to any one of claims 1 to 15 when executing the computer program.

19. A computer-readable storage medium, characterized in that, A computer program is stored in the computer-readable storage medium, where the computer program implements the steps of the method for determining an execution order of a request according to any one of claims 1 to 15 when being executed by a processor.

20. A computer program product, comprising a computer program, characterized in that, The computer program implements the steps of the method for determining an execution order of a request according to any one of claims 1 to 15 when being executed by a processor.

Images