Method, electronic device and storage medium for determining request execution order

Abstract

The present application discloses a method, electronic device and storage medium for determining the order of execution of requests, relating to the field of computer technology, including: obtaining the target address, target operation type and range of data to be operated by parsing the target request of the target operation, and dynamically determining the execution priority of the target request and the existing first request to be executed based on this. It not only takes into account the basic attributes of the operation, but also deeply analyzes the specific requirements of the operation for other resources, realizes multi-dimensional consideration of the order of execution of requests, and thus can comprehensively judge which requests should be executed first. Therefore, the present application can dynamically adjust the execution order of requests in complex scenarios with multiple concurrent requests to ensure that key operations can be executed in a timely manner, solves the technical problem in related technologies that the order of execution of requests cannot be effectively determined, and achieves the technical effect of dynamically determining the order of execution of requests.

Description

Technical Field

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

[0002] When executing various services in the system, frequent interactions between multiple entities will be involved, which may cause the problem of triggering multiple requests in a short period of time. How to adjust the execution logic of these multiple requests to ensure the effective execution of various services is an urgent problem that needs to be solved.

[0003] For example, in the baseboard management controller (BMC) system architecture, the Inter-Integrated Circuit Bus (I²C) is a widely used communication protocol. It is the primary communication interface for connecting peripheral devices such as sensors, Electrically Erasable Programmable Read-Only Memory (EEPROM), and power management chips. It carries complex and diverse control and data exchange tasks such as temperature monitoring, firmware updates, and logging. However, as system complexity continues to increase, a major challenge facing BMCs is how to efficiently and orderly manage I²C bus access in a multi-tasking parallel environment to avoid resource conflicts and performance bottlenecks. In related technologies, solutions to the above problems mainly rely on a mutual exclusion lock mechanism to ensure that only one process accesses the I²C bus at a time. Although this mechanism guarantees orderly access to the I²C bus to a certain extent, in actual operation, the mutual exclusion lock forces tasks to queue up regardless of their urgency. This not only causes delays in critical operations but also exacerbates the additional scheduling delays caused by lock contention, seriously affecting the system's real-time responsiveness and overall performance.

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

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

[0006] The present application provides a method for determining a request execution order, comprising: upon receiving a target request for requesting execution of a target operation, and upon determining that a first request to be executed exists in a current target queue, parsing the target request to obtain a target address of a target device, a target type of a target operation, and a target range of data to be operated carried in the target request, wherein 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 a target queue, and determining a 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, wherein the target execution order is used to instruct a target controller to execute the target request and the first request in accordance with the target execution order.

[0007] The present application also provides a hardware access arbitration agent device, including: a parsing module, which is used to parse the target request upon receiving a target request for requesting execution of a target operation and, upon determining that a first request to be executed exists in a current target queue, obtain a target address of a target device, a target type of a target operation, and a target range of data to be operated carried in the target request, wherein 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, which is used to insert the target request into a target queue and determine, in the target queue, a target execution order of the target request and the first request based on the target address, target type, and target range, wherein the target execution order is used to instruct a 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 agent device, a sending end for initiating a target request, and a target controller.

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

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

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

[0012] Through this application, since the target request of the target operation is parsed to obtain the target address, target operation type and the range of the data to be operated, and based on this, the execution priority of the target request and the existing first request to be executed is dynamically determined, not only the basic attributes of the operation are considered, but also the specific requirements of the operation for other resources are deeply analyzed, and a multi-dimensional consideration of the request execution order is realized, so that it can be comprehensively judged which requests should be executed first. Therefore, this application can dynamically adjust the execution order of requests in complex scenarios with multiple concurrent requests to ensure that key operations can be executed in a timely manner, solve the technical problem in related technologies that the request execution order cannot be effectively determined, and achieve the technical effect of dynamically determining the request execution order. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0014] Figure 1 A hardware structure block diagram of a mobile terminal for a method of determining a request execution order provided in an embodiment of the present application;

[0015] Figure 2 This is a flowchart of a method for determining a request execution order according to an embodiment of the present application;

[0016] Figure 3 A schematic diagram of a method for determining a request execution order according to a specific embodiment of the present application;

[0017] Figure 4 This is a flowchart of a method for determining the order of request execution according to a specific embodiment of the present application;

[0018] Figure 5 A schematic diagram of the structure of a hardware access arbitration agent device provided in an embodiment of the present application;

[0019] Figure 6 A schematic structural diagram of a baseboard management controller system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0020] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

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

[0022] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

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

[0024] The method embodiments provided in the embodiments of the present application can be executed in a mobile terminal, a computer terminal or a similar computing device. Taking running on a mobile terminal as an example, Figure 1 A hardware structure block diagram of a mobile terminal for determining the request execution order provided in an embodiment of the present application. Figure 1 As shown, the mobile terminal may include one or more ( Figure 1 Only one is shown) a processor 102 (the processor 102 may include but is not limited to a microprocessor MCU or a programmable logic device FPGA and other processing devices) and a memory 104 for storing data. The mobile terminal may also include a transmission device 106 and an input / output device 108 for communication functions. It will be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the mobile terminal. Figure 1 More or fewer components than shown, or with Figure 1 Different configurations shown.

[0025] The memory 104 can be used to store computer programs, for example, software programs and modules of application software, such as a computer program corresponding to a method for determining the execution order of requests in an embodiment of the present application. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, that is, implementing the above 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 memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include a memory remotely located relative to the processor 102, and these remote memories may be connected to the mobile terminal via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0026] Transmission device 106 is used to receive or transmit data via a network. A specific example of the aforementioned network may include a wireless network provided by the mobile terminal's communications provider. In one embodiment, transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to enable communication with the Internet. In another embodiment, transmission device 106 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0027] The embodiment of the present application provides a method for determining the execution order of requests. Figure 2 This is a flow chart of a method for determining the order of request execution according to an embodiment of the present application. Figure 2 As shown, the process includes the following steps:

[0028] Step S202, when a target request for requesting execution of a target operation is received and when it is determined that there is a first request to be executed in the current target queue, the target request is parsed 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, wherein the target queue is used to store requests to be executed, and the target operation includes the operation performed on the target device.

[0029] Optionally, the initiator of the target request includes but is not limited to a user terminal, an application, an IoT device, and a BMC system. Taking the BMC system as an example, the target request may be initiated by an 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 to obtain data from the target device, write operations to send data to the target device, and combined read and write operations. For example, the firmware update service requires that the new firmware version be written to a specified location in the target device, and the power management service requests to read the current status of the target device and then write new configuration parameters. It should also be noted that the device that initiates the above target request may also be a hardware device that has a connection relationship with the BMC device, such as an external management device, an external monitoring device, etc. Who specifically initiates the above target request can be configured based on actual conditions.

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

[0031] Optionally, the target queue is a data structure used to store and manage all requests, sorting them by processing priority and time. The target queue is typically implemented using a max-heap algorithm, sorting by execution priority, with the highest priority request at the top of the heap, ensuring that high-priority requests are 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 a variety of different types of requests, including but not limited to device status read requests, configuration information write requests, firmware update requests, fault diagnosis requests, and log recording requests, wherein device status read requests include but are not limited to temperature sensor reading, power status query, and fan speed acquisition; configuration information write requests include but are not limited to updating configuration data in EEPROM, modifying hardware parameters, etc.; firmware update requests involve firmware upgrades of BMC or other key hardware components; fault diagnosis requests are requests for detecting and troubleshooting hardware or software faults; and log recording requests include but are not limited to recording device operation logs and system operation status. Taking the BMC system as an example, the first request can be initiated by an application process / service in the system, which can be initiated by the initiator that initiates the target request, or by other initiators, including but not limited to temperature monitoring services, firmware update services, logging services, system-built-in management modules, external management interfaces, and system-built-in task schedulers. Who specifically initiates the above-mentioned first request can be configured based on actual conditions.

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

[0034] Optionally, the target address identifies the target device on the I²C bus, 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 upper 7 or 10 bits identify the device type. For example, if the target device is a temperature sensor, its target address might be 0x48, which is 01001000 in binary.

[0035] Optionally, the target type of the target operation is used to indicate a 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 indicates 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 data read start address and read data length; for a write operation, the target range includes the data write start address and write data length. For example, for a read operation, the target range includes the data read start address and read end address; for a write operation, the target range includes the data write start address and 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, wherein 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.

[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 within the BMC, a processor within the BMC (e.g., an embedded processor), or a processor connected to the BMC via an external network interface. The execution entity of the above steps can also be a terminal, a server, a specific processor provided in a terminal or server, or a processor or processing device provided relatively independently of the terminal or server, but is not limited thereto.

[0039] Optionally, the present invention is described by taking the hardware access arbitration agent layer configured in the BMC system as an example in which the execution subject of the above steps is a hardware access arbitration agent layer configured in the BMC system. Figure 3As shown, an application process / service within the BMC system (such as temperature monitoring, firmware updates, and logging) initiates an I²C operation request (corresponding to the aforementioned target request) requesting a read or write operation, or both, to a peripheral device. This request is submitted directly to the hardware access arbitration agent layer within the BMC system. The hardware access arbitration agent layer receives all I²C operation requests, parses them, and obtains the device address, operation type (read / write), and data address range contained in the I²C operation request. The hardware access arbitration agent layer inserts the I²C operation request into the target queue and, based on the device address, operation type, and data address range, determines the execution order of the I²C operation request with other I²C operation requests (corresponding to the first request) in the target queue. After determining the execution order, the hardware layer accesses the peripheral device through the I²C controller interface (i.e., the target controller) to perform the read or write operation. The hardware layer is responsible for implementing the specific hardware access interface.

[0040] Through the embodiments of the present application, the target address, target operation type and range of the data to be operated are obtained by parsing the target request of the target operation, and the execution priority of the target request and the existing first request to be executed is dynamically determined based on this. Not only the basic properties of the operation are taken into account, but also the specific requirements of the operation for other resources are deeply analyzed, and a multi-dimensional consideration of the request execution order is achieved, so that it can be comprehensively judged which requests should be executed first. Therefore, in complex scenarios with multiple concurrent requests, the execution order of the requests can be dynamically adjusted to ensure that key operations can be executed in a timely manner, solving the technical problem in related technologies 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 a target request and a first request in a target queue based on a target address, a target type, and a target range includes: 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, and obtaining a determination result, wherein 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.

[0042] Optionally, the target address indicates the address of the target device identified in the target request. The first address indicates the address of another device identified in the second request in the target queue, where the other device is the target device. The target range indicates the data address range for performing the target operation on the target device. The first range indicates 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 has an overlapping data address range.

[0043] Optionally, a target conflict indicates that in the target queue, 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 the first range). This conflict may cause data tearing, device lockup, and other problems, and needs to be detected and processed before execution. For example, the target request is to read data from the EEPROM device with address 0x48, and the corresponding target operation is to read data from 0x00 to 0x01 from the EEPROM device with address 0x48. The first request includes a request to write data to the EEPROM device with address 0x48. The other operation corresponding to this request is to write data to the EEPROM device with address 0x48 to the address range 0x00 to 0x10. In other words, the 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] This embodiment uses the target address and target range to determine whether there is a target conflict, proactively identifying potentially interfering operation requests. This is particularly true when multiple processes are concurrently accessing the same device. This early conflict detection helps prevent data corruption, device status anomalies, and even hardware lockup, thereby improving the security and reliability of I²C bus access. Furthermore, the execution order within the target queue is determined based on the determination result (and target type), allowing for dynamic scheduling based on the nature and urgency of operations, thereby reducing the response time of critical operations and improving overall execution efficiency.

[0047] In an exemplary embodiment, determining whether a first request includes a second request that has a target conflict with a target request based on a target address and a target range includes: determining a target container corresponding to a target device from a plurality of pre-built containers, wherein 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 addresses of the included devices; and determining whether the first request includes the second request based on a storage status of the target container.

[0048] Optionally, a container is a software design structure that corresponds to one or more devices with the same address. Containers can be constructed using a chained address method, with each container corresponding to a linked list containing multiple nodes, each corresponding to a request. A container can be represented as a hash bucket. Containers are used to store requests by device address, with all requests for a device stored in the corresponding container. For example, there are four containers, each using a hash bucket array data structure. Each container corresponds to a linked list, one for each device, corresponding to the temperature sensor (address 0x48), EEPROM (address 0x50), power management chip (address 0x60), and fan controller (address 0x68). When multiple requests arrive, they are automatically stored in the corresponding container based on their respective device addresses.

[0049] Optionally, the storage status indicates the storage status of requests within the target container, including but not limited to the number of requests, 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 conflicts with the target request.

[0050] This embodiment can quickly locate the container related to the target request, i.e., the target container, by pre-classifying and storing requests into different containers according to device addresses. This means that when a new request comes in, it is only necessary to check the storage status of the container to immediately determine whether there is a second request that conflicts with it, without having to traverse the entire request queue. This mechanism significantly improves the speed and accuracy of conflict detection, especially in high-concurrency environments, and can identify and handle conflicts in real time, thereby avoiding data corruption or task execution failure due to detection delays.

[0051] In an exemplary embodiment, determining whether the first request includes the second request based on the storage status of the target container includes at least one of the following: determining that the first request does not include the second request 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 the 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, wherein the first request includes the third request; determining that the first request includes the second request when it is determined that the 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, wherein the second request includes the third request.

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

[0053] Alternatively, if no request is stored in the target container, it can be determined that no second request in the first request conflicts with the target request. For example, if the target request is to read a temperature sensor (address 0x48), and the target container is empty, this indicates that no other request is currently operating on the temperature sensor. Therefore, it is determined that the first request does not include a second request, and the target request can be safely executed.

[0054] Alternatively, although the target container contains a third request, the data address range for other operations (i.e., the second range) does not overlap with the target range. Similarly, it can be determined that the first request does not contain a second request that conflicts with the target request. For example, the target request is for a write operation to registers 0xA0 to 0xFF in the EEPROM (address 0x50). The target container already contains a third request that reads data from registers 0x00 to 0x01 in the EEPROM (address 0x50). Although the third request and the target request target the same device, their data address ranges do not overlap. Therefore, it is determined that the first request does not contain the second request, and the target request can be safely executed.

[0055] Optionally, when a third request stored in the target container and the target request target the same device operation and their data address ranges overlap, the first request is determined to contain a second request that conflicts with the target request. This third request is the second request. For example, a third request exists in the target container to read data from registers 0x00 to 0x02 of a temperature sensor (address 0x48), while the target request also targets the temperature sensor, but with a target range of 0x01 to 0x03. In this case, the data address ranges 0x00-0x02 and 0x01-0x03 of the two operations overlap. Therefore, the first request is determined to include the second request, and the second request includes the third request. The execution order of the target and third requests needs to be determined.

[0056] This embodiment can dynamically adjust the priority of requests based on the storage status analysis of the target container when multiple requests are accessed concurrently, thereby 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 there are multiple third requests, 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 in the target container; determining whether the target range overlaps with the second range carried in each third request in sequence according to the priority of the multiple third requests; and 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 chain address method, a container corresponds to a linked list. A linked list includes multiple nodes, and a node corresponds to a request. The information stored in the node includes but is not limited to the device address, operation type, and data address range of the request. The linked list nodes can be traversed by pointing to the linked list pointer, and it can be determined one by one whether the second range of the third request stored in the node overlaps with the target range of the target request. The method for determining the pointing of the linked list pointer includes but is not limited to storage time from first to last, priority from high to low, and remaining execution time from short to long. 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 to be executed of the request.

[0059] This embodiment determines the range overlap in sequence by the time sequence in which the third requests are stored in the target container, which can effectively implement the first-in-first-out strategy, ensure that each request is judged for conflicts in chronological order, avoid unreasonable priority of late requests, and thus improve the fairness of request processing. At the same time, by determining whether the target range overlaps with the second range of each third request through priority sorting, high-priority requests can be processed first, ensuring that critical tasks obtain priority execution 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 waiting time. By adopting any of the above methods, the scheduling logic for the third request can be simplified, and the complex comprehensive evaluation of multiple factors can be avoided, thereby achieving the purpose of reducing time complexity and delays 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, 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; and 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, a target fingerprint is an identifier used to represent a specific operation request on the I²C bus. It consists of three components: a first hash value, a second hash value, and a third hash value, corresponding to the target address, target type, and target range, respectively. By combining these three values, a highly unique identifier is generated, ensuring that each request can be accurately tracked and managed. For example, if a target request is to read registers 0x20-0x25 of a temperature sensor at address 0x48, the target fingerprint can be a unique value calculated by applying a specific hash algorithm to 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 an enumerated value or a bit code of the operation type, and the third hash value is generated by hashing the start address and the data length.

[0063] Optionally, to better manage and schedule I²C bus operation requests, the BMC system pre-creates a set of containers, each associated with a device or group of devices on the I²C bus. Each container stores all requests related to a specific device. This allows quick location of all pending requests for a specific device, improving resource scheduling efficiency. For example, container 1 manages all requests for the temperature sensor at address 0x48. Container 2 manages all requests for the EEPROM at address 0x50. Container 3 handles requests for the power management chip at address 0x60.

[0064] Optionally, to quickly locate the container associated with a request, a mapping relationship needs to be maintained, associating hash values ​​with containers. The hash value used to establish this association can be the hash value of the device address. This allows for a quick lookup of the corresponding container based on the device address's hash value when a new request is submitted, allowing for further conflict detection and priority arbitration. For example, in the mapping, 0x1A (the first hash value) corresponds to container 1, and 0x32 corresponds to container 2. When a new request with the first hash value 0x1A arrives, it is immediately known that it belongs to container 1, allowing subsequent request scheduling to proceed within this container.

[0065] This embodiment generates a target fingerprint of the target request, combines it with the pre-built container and the mapping relationship between the hash value and the container, and can efficiently and accurately identify and locate each request, thereby achieving the purpose of intelligent management of requests.

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

[0067] Optionally, bit concatenation combines different data blocks (such as device address, operation type, and data range) at the bit level into a larger data unit. This method effectively integrates various request parameters into a compact and information-rich data structure, facilitating subsequent processing and storage. For example, the device address 0x28 (8 bits) is converted to binary as: 00101000, the operation type WRITE (if represented as 8 bits, the specific value depends on the system settings): 00001010, and the data range (starting address 0x00 and ending address 0x0F, a total of 10 bits, starting 4 bits and ending 6 bits): starting address 0000, ending address 00001111. Concatenating these data bits, the target fingerprint high bits are: device address (8 bits) + operation type (8 bits), and the target fingerprint low bits are: data range (starting address 4 bits + ending address 6 bits).

[0068] Optionally, hash compression is the process of mapping arbitrary-length data to a fixed-length output (hash value). When generating a target fingerprint, the bit-joined data is compressed using a hash algorithm to produce a simplified, highly unique fingerprint value. Hash compression helps reduce the size of fingerprint data, making it easier to store and faster to compare.

[0069] This embodiment combines the target address, target type, and target range into a compact structure through bit splicing, simplifying the conflict detection logic. When a new request arrives, it only needs to compare the target fingerprint of the current request with the existing fingerprint set to determine whether there is a conflict, without having to check the address, type, and range item by item, thereby improving the conflict detection speed.

[0070] In an exemplary embodiment, 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 between the target range and the first range, and, based on the correspondence between the pre-configured overlap 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; wherein the first weight factor is used to indicate the probability of conflict 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 weighting factor is a numerical indicator used to quantify address conflicts. The value of the first weighting factor depends on the degree of overlap between the requested ranges and a pre-configured correspondence between the degree of overlap and the weighting factor. For example, if the target range completely overlaps with the first range, the first weighting factor is set to 100%. If there is partial overlap, the weighting factor is set based on the overlap ratio, such as 50%. If there is no overlap, the first weighting factor is set to 0%.

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

[0073] Optionally, methods for determining 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 include but are not limited to a weighted average method, a weight decay method, and a 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 policy.

[0075] In an exemplary embodiment, 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 the 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 the 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; 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 at 0, where the remaining execution time is the difference between the current time and the timestamp, and the timestamp is the time when the request is received.

[0077] Optionally, the third weight factor reflects the priority of the target device, which 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] This embodiment comprehensively considers the first weight factor (indicating the probability of address range conflicts between requests), the second weight factor (reflecting the risk of requests timing out), and the third weight factor (indicating the priority level of the device), thereby enabling more refined priority adjustments to be made to various types of requests. This allows critical tasks to automatically advance their position in the queue when facing conflicts, approaching timeouts, or involving high-priority devices, ensuring priority execution and achieving the purpose of improving bus bandwidth utilization.

[0080] In an exemplary embodiment, 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: determining the target priority information W by 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] Table 1 shows the priority arbitration factors and weight calculation model. The values ​​configured in Table 1 are examples and can be flexibly adjusted based on actual conditions in actual applications. For example, the weight values ​​for read operations can be set to 70, 60, etc., and the weight values ​​for write operations can be set to 90, 80, etc. When the remaining execution time accounts for ≤20% of the timeout threshold, the weight is increased by 20%.

[0083] Table 1

[0084]

[0085] For example, for the following request, the calculation result is priority information = 100 × (1 + 0.2 + 0.3) × (1 + 0.5) = 100 × 1.5 × 1.5 = 225, based on the values ​​configured in Table 1: Level 1 device (weight bonus + 50%), device type: temperature monitoring sensor (high real-time requirements, affecting system security), operation type: read and 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 the request indicating the following example, the calculation result is priority information = 90×(1+0)×(1+0.3)=90×1×1.3=117 based on the values ​​configured in Table 1: Level 2 device (weight bonus +30%), device type: configuration synchronization (affecting functional integrity), operation type: write operation (W 基础 =90), address conflict: no address overlap (α 地址冲突 =0), timeout risk: the timeout condition is not triggered (α 超时风险 =0).

[0087] For another example, for the request indicating the following example, the calculation result is the priority information = 80 × (1 + 0 + 0.3) × (1 + 0.1) = 80 × 1.3 × 1.1 = 114.4, using the values ​​configured in Table 1: Level 3 device (weight bonus + 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 operation order is: temperature monitoring sensor → configuration synchronization → log query module.

[0089] This embodiment uses the above formula to dynamically calculate and adjust request priority information, thereby improving bus bandwidth utilization and enhancing the intelligent adaptive capabilities of the BMC system when processing I²C bus access requests. Compared with traditional solutions, it supports concurrent management of more devices.

[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 the weight value corresponding to the target type to be a first weight value; when the target type indicates that the target operation is a write operation, determining the weight value corresponding to the target type to be a second weight value; when the target type indicates that the target operation is a read / write operation, determining the weight value corresponding to the target type to be a 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: setting a transaction lock before executing multiple fourth requests included in the target queue that need to be executed continuously, wherein after the transaction lock is set, suspending 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, a 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 request is an indivisible request. These requests are usually closely related and work together to complete a complex task, such as a request for writing to EEPROM or a request for firmware upgrade process. In the BMC system, when a group of continuous I²C access operations are required (i.e., multiple I²C operations need to be executed continuously), the transaction lock is used to ensure that a series of operations can be executed as a whole (atomic operation) without external interference. 2C requests), setting transaction locks ensures that these operations are not interrupted by other requests before completion, ensuring operational integrity and data consistency. For example, bus locking is implemented for critical operations such as EEPROM writes. Transaction locks are introduced at the hardware access arbitration agent layer to ensure that multiple operation sequences are inseparable. While the lock is held, the bus is exclusively occupied, and other requests enter the target queue and wait. When the transaction lock is released, other requests continue to execute according to priority order.

[0093] This embodiment sets a transaction lock to ensure that the bus control right is not preempted during the critical operation, and to ensure that the critical operation is not interrupted by other requests before completion, thereby achieving the purpose of ensuring operation integrity and data consistency.

[0094] In an exemplary embodiment, the method also 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, wherein the target interface is the interface of the target controller to access the device requested to be accessed by the fifth request; determining the execution result of the target controller executing the fifth request based on the return value; and triggering an operation corresponding to the execution result.

[0095] Optionally, a target controller is a hardware component within the BMC system responsible for managing and coordinating I²C bus access and performing actual bus access operations. The target controller follows specific arbitration and priority rules when processing requests to ensure orderly and efficient execution of operations. For example, in a server, the BMC baseboard management controller is the target controller, specifically an I²C controller. Based on received requests (such as sensor reads and EEPROM updates) and predefined priority rules, it controls data transfer on the I²C bus to ensure the execution of each operation.

[0096] Optionally, the target interface is a specific interface used by the target controller to communicate with devices on the I²C bus. It provides the necessary functions for accessing and reading from the device, such as setting the starting address, reading and writing data, and obtaining device responses. For example, when executing the fifth request to read temperature sensor data, the target interface might be a specific I²C interface for communicating with the temperature sensor, providing the ability to read sensor register data. The target interface's return value includes the execution result, indicating success or failure.

[0097] This embodiment obtains the return value of the target interface and determines the execution result based on it, thereby providing timely feedback on the execution result of the execution request. This enables the BMC system to quickly identify and respond to any abnormalities or failures in the device access process, thereby significantly improving system responsiveness and reliability.

[0098] In an exemplary embodiment, triggering an operation corresponding to the execution result includes at least one of the following: triggering the target controller to repeat the fifth request when the execution result indicates that a first degree of error has occurred; triggering the target controller to reset when the execution result indicates that a second degree of error has occurred, so that the target controller is reset and then the fifth request is re-executed.

[0099] Optionally, a first-degree error indicates a temporary error, typically minor, foreseeable, or temporarily resolvable. Such errors can often be corrected with simple actions or a retry mechanism. In I²C communication scenarios, common first-degree errors include, but are not limited to, temporary device unresponsiveness (hang state) and communication failures caused by minor interference on the bus. These errors often do not indicate a permanent failure of the device or communication line.

[0100] Optionally, a second-level error indicates a non-transient error, typically a more serious problem that may require more drastic action to resolve, such as a device lockup or a persistent bus failure to respond. Resetting the target controller effectively restarts the target controller, clearing its internal state and restoring its initial configuration. After resetting, the target controller reestablishes its connection to the I²C bus and re-executes the fifth request.

[0101] This embodiment ensures efficient use of resources and avoids the risk of long-term service interruption by distinguishing the degree of error and taking different responses, thereby achieving the goal of improving task execution efficiency as a whole.

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

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

[0104] This embodiment uses an I²C access process as an example for description. Figure 4 This is a flowchart of a method for determining the execution order of requests according to a specific embodiment of the present application. Figure 4 As shown, the following steps are included:

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

[0106] The application process submits an I²C operation request to the hardware access arbitration agent layer through the unified API interface i2cx_hal_request(). The hardware access arbitration agent layer injects the timestamp of the I²C operation request (x represents the I²C channel number). 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 and write operation

[0110] uint16_t read_reg_addr; / / read starting address

[0111] uint16_t read_length; / / read data length

[0112] uint16_t write_reg_addr; / / write starting 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 function is designed as follows:

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

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

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

[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] / / Operation type (second most significant 8 bits)

[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] S406, pre-check the address conflict, if there is a conflict, go to S408 for priority arbitration, if there is no conflict, go to S412 to join the scheduling queue (ie, the target queue).

[0136] Hardware operation fingerprints are stored in a fingerprint library for collision detection. The fingerprint library takes the form of an in-memory hash table. Chain addressing can be used to construct the hash table, accurately identifying overlapping address operations on the same device. The core structure of the hash table consists of a hash bucket array and linked list nodes. The hash bucket array is a fixed-size pointer array (the default is 256 buckets, but other numbers can be set. 256 is used here as an example). Each bucket corresponds to a linked list for hash collision resolution. Each node in the linked list stores information about the I²C operation request, including a fingerprint value, a 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 bits can also be set, for example, the fingerprint value can be set to a 32-bit hash value, or the fingerprint value can be set to a 128-bit hash value, etc.). It is generated by 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 chain structure.

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

[0138] a) Locating the target bucket: The bucket index corresponding to the fingerprint is calculated through a hash function. The hash function maps the upper 8 bits of the 64-bit fingerprint value (i.e., the device address) to the bucket index. The differences in device addresses naturally disperse requests, and the upper 8 bits are modulo the hash table size (256) to obtain the bucket index (0-255).

[0139] b) Traverse the linked list nodes: Check one by one whether the read and write address ranges of the nodes in the bucket overlap with the read and write address ranges of the I²C operation requests, including: read range conflicts and write range conflicts. Among them, if the read start address of the I²C operation request is less than the read end address of a 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 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 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 request stored in the node, it is a write range conflict.

[0140] c) Conflict determination: If the read or write address ranges of the same device overlap, it is determined to be a conflict; if the devices are different, there is no conflict even if the read or write address ranges are the same.

[0141] S408: The priority arbitration factors and weight calculation model are shown in Table 1:

[0142] Table 1

[0143]

[0144] The priority of a request (i.e., priority information) is calculated using the following formula:

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

[0146] S410 uses a max-heap to maintain the scheduling queue, sorted by execution priority, with the highest-priority request at the top of the heap. The core operations of the scheduling queue include insertion and extraction. For insertion requests, after priority calculation, the I²C operation request is placed at the last position in the heap (the end of the complete binary tree). The weight of the I²C operation request is compared with that of its parent node. If the child node's weight is greater than the parent's weight (higher priority), the two nodes are swapped and the process continues upward until the heap property (parent node > child node) is satisfied. For extraction requests, after popping the top request (the highest-priority request), the last node in the heap is moved to the top. The priorities of the new top node and its left and right child nodes are compared. If the parent node's priority is less than the priority of any child node, the node is swapped with the highest-priority child node. The process continues downward until the parent node's priority is greater than or equal to the priorities of all child nodes.

[0147] S412: Add the request to the scheduling queue, loop through the top request, and skip the timed-out tasks. The hardware layer's I²C controller executes the hardware operation corresponding to the I²C operation request, and upon completion, deletes the mapping relationship of the request from the hash table.

[0148] S414 implements bus locking for key operations such as EEPROM writing and introduces transaction locks in the hardware access arbitration agent layer to ensure that multiple operation sequences are inseparable. The bus is exclusively used while the lock is held, and other requests enter the target queue and wait. When the transaction lock is released, other requests continue to execute in order of priority.

[0149] S416, whether the execution is successful, if successful, go to S420, if unsuccessful, go to S418.

[0150] S418: After accessing the I²C device through the hardware-layer I²C controller interface, the I²C interface receives the execution result returned by the I²C interface. If the execution result indicates a temporary error (such as a negative acknowledgement), the I²C controller automatically retries three times. If the execution result indicates a serious error (such as an I²C bus lock), the I²C controller resets. After the reset, the I²C bus is reinitialized, locked requests are released, and scheduling is resumed based on priority. If failures persist after three resets, access to the device is disabled.

[0151] S420, the result is returned and recorded in the log.

[0152] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and 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 agent device, such as Figure 5 Shown, including:

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

[0155] Determination module 504 is used 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, wherein 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.

[0156] In an exemplary embodiment, the determination module 504 includes: a determination submodule, used to determine 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, and obtain a determination result, wherein 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; a determination submodule, used to determine 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.

[0157] In an exemplary embodiment, the determination submodule includes: a first determination unit, configured to determine a target container corresponding to a target device from a plurality of pre-built containers, wherein 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 addresses of the included devices; and a second determination unit, configured to determine whether the first request includes the second request based on a storage status 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 no request is stored 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 the target container has stored a third request and the target range does not overlap with the second range of the data to be operated carried in the third request, wherein the first request includes the third request; and a third determination subunit, configured to determine that the first request includes the second request when it is determined that the target container has stored the third request and the target range overlaps with the second range of the data to be operated carried in the third request, wherein the second request includes the third request.

[0159] 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 third determination sub-unit further includes at least one of the following: a first determination sub-unit, used to determine 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; a second determination sub-unit, used to determine whether the target range overlaps with the second range carried in each third request in sequence according to the priority of the multiple third requests; and a third determination sub-unit, used to determine 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.

[0160] In an exemplary embodiment, the determination submodule 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-built containers, 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; and 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 generating unit includes: a first generating sub-unit, configured to perform bit splicing and hash compression processing on a target address, a target type, and a target range to generate a target fingerprint.

[0162] In an exemplary embodiment, the determination submodule includes: a third determination unit, for determining the degree of overlap between the target range and the first range when the determination result indicates that the first request includes the second request, and, based on the correspondence between the pre-configured degree of overlap and the first weight factor, determining the value of the first weight factor; when 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 probability of conflict between the first request and the second request; a fourth determination unit, 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; and a fifth determination unit, for 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.

[0163] In an exemplary embodiment, the fourth determination unit includes: a fifth determination subunit, used to determine the remaining execution time of the target request, and to determine the value of the 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, used to determine the value of the 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; and a seventh determination subunit, used 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 determining subunit includes: determining the target priority information W by the following formula: 总 :W 总 =W 基础 ×(1+α 地址冲突 +α 超时风险 )×(1+α 设备优先级 )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 determination submodule also includes: a sixth determination unit for determining, 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, when the target type indicates that the target operation is a read operation, the weight value corresponding to the target type is a first weight value; a seventh determination unit for determining, when the target type indicates that the target operation is a write operation, the weight value corresponding to the target type is a second weight value; an eighth determination unit for determining, when the target type indicates that the target operation is a read or write operation, the weight value corresponding to the target type is a 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.

[0166] In an exemplary embodiment, the device also includes: a first setting module, which is used to set a transaction lock before executing multiple fourth requests included in the target queue that need to be executed continuously, wherein after the transaction lock is set, the operation of adjusting the execution order of the requests included in the target queue is suspended; and a first releasing module, which is used to release the transaction lock after completing the execution of the multiple fourth requests to continue the operation of adjusting the execution order of the requests included in the target queue.

[0167] In an exemplary embodiment, the device also includes: a first acquisition module, used to obtain the return value of the target interface when it is determined that the target controller has executed the fifth request included in the target queue, wherein the target interface is the interface of the device requested to be accessed by the target controller by the fifth request; a second determination module, used to determine the execution result of the target controller executing the fifth request based on the return value; and a first trigger module, used to trigger an operation corresponding to the execution result.

[0168] In an exemplary embodiment, the first trigger module includes at least one of the following: a first trigger submodule, used to trigger the target controller to repeat the fifth request when the execution result indicates that a first degree of error has occurred; and a second trigger submodule, used to trigger the target controller to reset when the execution result indicates that a second degree of error has occurred, so that the target controller re-executes the fifth request after the reset.

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

[0170] For descriptions of features in the embodiment corresponding to the hardware access arbitration agent device, reference may be made to the relevant descriptions of the embodiment corresponding to the method for determining the request execution order, which will not be described in detail here.

[0171] The embodiment of the present application also provides a baseboard management controller system, such as Figure 6 As shown, it includes a hardware access arbitration agent device, a sending end for initiating a target request, and a target controller.

[0172] An embodiment of the present application further provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the steps of any of the above-mentioned method embodiments for determining the request execution order.

[0173] An embodiment of the present application further provides a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps of any of the above-mentioned method embodiments for determining the request execution order when running.

[0174] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0175] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps of any of the above-mentioned method embodiments for determining the request execution order are implemented.

[0176] An embodiment of the present application also provides another computer program product, including a non-volatile computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the steps of any of the above-mentioned method embodiments for determining the request execution order.

[0177] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0178] The above is a detailed introduction to a method for determining the order of request execution provided by the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only intended to help understand the method and core ideas of the present application. It should be pointed out that, for those skilled in the art, without departing from the principles of the present application, several improvements and modifications may be made to the present application, and such improvements and modifications also fall within the scope of protection of the claims of the present application.

Claims

1. A method for determining the order in which requests are executed, characterized in that: include: Upon receiving a target request for requesting execution of a target operation and determining that a first request to be executed exists in a current target queue, parsing the target request to obtain a target address of a target device, a target type of the target operation, and a target range of data to be operated on, carried in the target request, wherein the target queue is used to store requests to be executed, and the target operation includes an operation to be executed on the target device; Inserting the target request into the target queue, and determining a 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, wherein the target execution order is used to instruct a target controller to execute the target request and the first request according to the target execution order; Determining, in the target queue, a target execution order of the target request and the first request based on the target address, the target type, and the target range includes: determining, based on the target address and the target range, whether the first request includes a second request that has a target conflict with the target request, and obtaining a determination result, wherein 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; determining, in the target queue, a target execution order of the target request and the first request 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 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 between the target range and the first range, and, based on the correspondence between the pre-configured overlap 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; wherein the first weight factor is used to indicate the probability of conflict 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.

2. The method according to claim 1, characterized in that 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-built containers, wherein different containers correspond to different devices, and each request included in the first request is stored in the plurality of containers according to the addresses of the included devices; It is determined whether the first request includes the second request based on a storage state of the target container.

3. The method according to claim 2, characterized in that 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: If it is determined that no request is stored in the target container, determining that the first request does not include the second request; If it is determined that the third request is already stored in the target container and the target range does not overlap with the second range of the data to be operated on carried in the third request, determining that the first request does not include the second request, wherein the first request includes the third request; When it is determined that the 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, it is determined that the first request includes the second request, wherein the second request includes the third request.

4. The method according to claim 3, characterized in that When it is determined that the target container has stored a third request, and the number of the third request is multiple, the method further includes at least one of the following: determining, in sequence according to the storage time of the plurality of third requests stored in the target container, whether the target range overlaps with the second range carried in each of the third requests; determining, in order according to the priorities of the plurality of third requests, whether the target range overlaps with the second range carried in each of the third requests; Whether the target range overlaps with the second range carried in each of the third requests is determined in sequence according to the remaining execution time of the plurality of third requests.

5. The method according to claim 2, characterized in that Before determining a target container corresponding to the target device from a plurality of pre-built 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 a target container corresponding to the target device from a plurality of pre-built containers includes: determining the target container corresponding to the first hash value based on a pre-configured mapping relationship between hash values ​​and containers.

6. The method according to claim 5, 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: Bit concatenation and hash compression are performed on the target address, the target type, and the target range to generate the target fingerprint.

7. The method according to claim 1, characterized in that 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 a remaining execution time of the target request, and determining a value of a second weighting factor based on the remaining execution time and a preset timeout threshold of the target request, wherein the second weighting factor is used to indicate a timeout risk of the target request; determining a value of a third weight factor based on the type of the target device, wherein the third weight factor is used to indicate a device priority of the target device; The target priority information of the target request is determined 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.

8. The method according to claim 7, characterized in that Determining the target priority information of the target request based on the value of the first weighting factor, the value of the second weighting factor, the value of the third weighting factor, and the weight value corresponding to the target type includes: The target priority information W is determined by the following formula 总 : W 总 =W 基础 ×(1+a 地址冲突 +a 超时风险 )×(1+a 设备优先级 ); 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.

9. The method according to claim 1, 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: In a case where the target type indicates that the target operation is a read operation, determining that a weight value corresponding to the target type is a first weight value; In a case where the target type indicates that the target operation is a write operation, determining that the weight value corresponding to the target type is a second weight value; In a case where the target type indicates that the target operation is a read / write operation, determining that the weight value corresponding to the target type is a third weight value; The first weight value is smaller than the second weight value, and the second weight value is smaller than the third weight value.

10. The method according to any one of claims 1 to 9, characterized in that The method further comprises: Before executing a plurality of fourth requests included in the target queue that need to be executed consecutively, setting a transaction lock, wherein after setting the transaction lock, suspending execution of an operation of adjusting the execution order of the requests included in the target queue; After completing the execution of the plurality of fourth requests, the transaction lock is released to continue the operation of adjusting the execution order of the requests included in the target queue.

11. The method according to any one of claims 1 to 9, characterized in that The method further comprises: When it is determined that the target controller has executed the fifth request included in the target queue, obtaining a return value of a target interface, wherein the target interface is an interface for the target controller to access the device requested to be accessed by the fifth request; determining, based on the return value, an execution result of the fifth request executed by the target controller; An operation corresponding to the execution result is triggered.

12. The method according to claim 11, characterized in that Triggering an operation corresponding to the execution result includes at least one of the following: When the execution result indicates that a first degree of error occurs, triggering the target controller to repeatedly execute the fifth request; When the execution result indicates that a second degree of error occurs, the target controller is triggered to reset, so that the target controller re-executes the fifth request after being reset.

13. The method according to claim 12, characterized in that After triggering the target controller to reset, the method further includes: In a case where the number of times the target controller is triggered to reset exceeds a preset number threshold, the target controller is prohibited from accessing the device requested to be accessed by the fifth request.

14. A hardware access arbitration agent device, characterized in that: include: a parsing module configured to, upon receiving a target request for requesting execution of a target operation and determining that a first request to be executed exists in a current target queue, parse the target request to obtain a target address of a target device, a target type of the target operation, and a target range of data to be operated on, carried in the target request, wherein the target queue is used to store requests to be executed, and the target operation includes an operation to be performed on the target device; a determination module, configured to insert the target request into the target queue, and determine a 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, wherein the target execution order is used to instruct a target controller to execute the target request and the first request according to the target execution order; The determination module includes: a determination submodule, configured to determine, based on the target address and the target range, whether the first request includes a second request that has a target conflict with the target request, and obtain a determination result, wherein 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 data to be operated carried in the second request; a determination submodule, configured to determine, in the target queue, a target execution order of the target request and the first request based on the determination result and the target type; The determination submodule includes: a third determination unit, used to determine the degree of overlap between the target range and the first range when it is determined that the determination result indicates that the first request includes the second request, and, based on the correspondence between the pre-configured degree of overlap and the first weight factor, determine 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, set the value of the first weight factor to 0; wherein the first weight factor is used to indicate the probability of conflict between the first request and the second request; a fourth determination unit, used to determine 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 fifth determination unit, used to determine 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.

15. A baseboard management controller system, characterized in that: include: The hardware access arbitration agent device according to claim 14 is used for initiating a sending end of a target request and a target controller.

16. An electronic device, characterized in that: include: Memory for storing computer programs; A processor, configured to implement the steps of the method for determining the request execution order according to any one of claims 1 to 13 when executing the computer program.

17. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, the steps of the method for determining the request execution order according to any one of claims 1 to 13 are implemented.

18. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method for determining the request execution order according to any one of claims 1 to 13 are implemented.

Images